From owner-ipsec Sun Mar 1 01:04:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA10351 for ipsec-outgoing; Sun, 1 Mar 1998 01:00:22 -0500 (EST) Message-Id: <199803010614.BAA15513@relay.rv.tis.com> Date: Sun, 1 Mar 98 1:05:09 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Draft versions -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Sorry to bother you with this, but some of the comments we've received have been for the November drafts and relate to issues/typos/etc that have been addressed in the new February drafts. Of course some of the problems pointed out with the November drafts were ones that may still apply to the February ones, so the effort/feedback isn't wasted. But just to minimize efforts... please be sure you're reviewing the most recent drafts. As of this Saturday evening (2/28), a) The recently submitted February version of the Architecture draft had not yet been posted to the internet-drafts directory. Please use the version we sent to the mailing list and the IETF secretariat on 2/20. Please let me know if you want me to send you a copy (prior to its being posted to the drafts directory): draft-ietf-ipsec-arch-sec-03.txt b) There are 2 versions of the AH draft in the internet-drafts directory: draft-ietf-ipsec-esp-v2-02.txt draft-ietf-ipsec-esp-v2-03.txt (the latest version) c) There are 2 versions of the ESP draft in the internet-drafts directory: draft-ietf-ipsec-auth-header-03.txt draft-ietf-ipsec-auth-header-04.txt (the latest version) Thank you, Karen PS I'm not sure why there are 2 versions of the AH and ESP drafts, though it does make it easier to compare them. Also, we pinged the secretariat and they're planning to post the Arch document either this weekend or Monday. I have the impression they're just swamped, etc. From owner-ipsec Sun Mar 1 02:18:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA10742 for ipsec-outgoing; Sun, 1 Mar 1998 02:15:21 -0500 (EST) Message-Id: <199803010726.XAA11797@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: hugh@mimosa.com ("D. Hugh Redelmeier") Cc: ipsec@tis.com, gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: Re: comments on draft-ietf-ipsec-isakmp-oakley-06.txt In-Reply-To: Your message of "Mon, 23 Feb 1998 22:34:18 EST." <199802240334.WAA11835@mimosa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Feb 1998 23:26:41 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > The table of contents does not give the full names of the sections > within 5. Each says what phase it is part of, and I would have found > that useful in the TOC. ok. > The TOC entries for Appendices should have mentioned what was in each. ok. > Section 1, in describing SKEME says: > > [Kra96] (SKEME) describes a versatile key exchange technique which > provides anonymity, repudiability, and quick key refreshment. > > I don't know SKEME, but claiming repudiability seems odd. Perhaps > "non-repudiability" is meant. No, it really means "repudiability". Perhaps you didn't read far enough into the document. Section 5.2 explains this concept, as does the SKEME paper itself and I recommend you read it as well (check out the references). > Section 3.2 describes notation: > > IDx is the identity payload for "x". x can be: "ii" or "ir" for > the ISAKMP initiator and responder respectively during phase one > negotiation; or "ui" or "ur" for the user initiator and responder > respectively during phase two. The ID payload format for the > Internet DOI is defined in [Pip97]. > > I have posted notes about Identification Payload issues. The correct > term appears to be "Identification Payload", not identity payload. ok. > I think that the definition in the ISAKMP draft [MSST97] applies > simultaneously (in the IPsec DOI) or only (in the ISAKMP DOI). The > term "Internet DOI" seems misleading; I'd use "IPsec DOI". I don't understand what you mean by "the definition in the ISAKMP draft applies simultaneously". > Section 5.5 describes how to cook up more keying material, if it is > needed: > > For situations where the amount of keying material desired is greater > than that supplied by the prf, KEYMAT is expanded by feeding the > results of the prf back into itself and concatenating results until > the required keying material has been reached. In other words, > > I'm not a cryptographer, but... This sounds like something for > nothing. What are the cryptographic implications of generating extra > keying material this way? I think that the document should address > this question. Your not getting something for nothing. You're just getting the amount of keying material you need. I'm not a cryptographer either but cryptographers have looked at this technique and not raised any red flags. This does not lessen or weaken the keying material (nor does it strengthen it) but it does impose strong mixing requirements on the prf. Which reminds me: 11.3 should mention that requirement when requests for magic numbers for hash or prf are made. > Appendix A, under group description: > > - Group Description > default 768-bit MODP group (section 6.1) 1 > > alternate 1024-bit MODP group (section 6.2) 2 > .sp > EC2N group on GP[2^155] (section 6.3) 3 > .sp > EC2N group on GP[2^185] (section 6.4) 4 > > values 5-32767 are reserved to IANA. Values 32768-65535 are for > private use among mutually consenting parties. > > Indented troff commands don't work. Well, actually, it's nroff but that in no way excuses its lackadaisical attitude toward productive labor. I'll raise this with its representitive at the International Brotherhood of Document Formatters. Dan. From owner-ipsec Sun Mar 1 20:37:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16604 for ipsec-outgoing; Sun, 1 Mar 1998 20:31:21 -0500 (EST) Date: Sun, 1 Mar 1998 20:40:46 -0500 (EST) From: "M.C.Nelson" To: Robert Moskowitz cc: Stephen Waters , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-Reply-To: <3.0.5.32.19980227102904.0099ade0@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 27 Feb 1998, Robert Moskowitz wrote: > At 03:28 PM 2/26/98 -0000, Stephen Waters wrote: > > > >Does IPSEC tunnel mean I can forget about Mobile IP? > > IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and > pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, > or conference LAN does not need Mobile IP, only IPsec. > I once again don't understand this. To me the difference between a mobil user and other uses of IP, as far as the protocols are concerned, is that the mobile user is likely to have a different IP address from one instance to the next, and is likely to be routed differently from one instance to the next. In a public network, the two may often go together. In a private network, including "tanks, soldiers, etc.", this may actually not be the case as often. So it seems to me that tanks and soldiers actually could conceivably look more like the non-mobile case as far as the network protocols are concerned, at least more often than does the salesman in his hotel room, unless the salesman always dials into the same service point and always gets the same address. It seems to me that the real challenge presented by mobile IP, and also by many office LANS, is the dynamic IP address. Will the present protocols accomodate dynamic IP and NFS on a multi-user host? Is there a scalable key infrastructure that will accomodate this? Regards, Mitch Nelson From owner-ipsec Mon Mar 2 07:10:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20673 for ipsec-outgoing; Mon, 2 Mar 1998 07:10:22 -0500 (EST) Message-ID: <19980228064347.55404@hazel> Date: Sat, 28 Feb 1998 06:43:47 -0500 From: Raul Miller To: ipsec@tis.com, Alex Alten Cc: Henry Spencer Subject: Re: IPSEC WORKING GROUP LAST CALL Mail-Followup-To: ipsec@tis.com, Alex Alten , Henry Spencer References: <3.0.3.32.19980227225721.00973710@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <3.0.3.32.19980227225721.00973710@netcom.com>; from Alex Alten on Fri, Feb 27, 1998 at 10:57:21PM -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten wrote: > My view is that it's just another tool to be used to solve certain > types of problems. Whether you realize it or not, we have been > outmaneuvered by other communities with different desires. Their > position is now being reinforced by members of the industry who are > coming up with solutions meeting this requirement. Irrelevant. However, bringing up this point strikes me more as a "delay the process by introducing flamage" attempt than anything else. > Well, let's agree to disagree. My contention is that the establishment > of this pattern of trust is equally difficult for PK and symmetric > type of ciphers, regardless of whether we are talking about intra- or > inter- organization communications. Technically or Philosophically? Barring design weaknesses, this is a ludicrous statement technically. And this is the wrong point in the design cycle to introduce "back to the drawing board" philosophical arguments. Those would be better handled by introduction of a new design effort (e.g. by some other group, or -- if this group -- at some other time). This group has already spent years on public key and privacy issues. Don't you think it's at least a tiny bit arrogant to ask everyone to not publish the resulting specifications? -- Raul From owner-ipsec Mon Mar 2 07:10:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20646 for ipsec-outgoing; Mon, 2 Mar 1998 07:07:22 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'ipsec'" Subject: FW: IPSEC WORKING GROUP LAST CALL Date: Fri, 27 Feb 1998 14:57:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Mark help me understand what is in the latest documents on the issues I had raised and I appreciate him sending it to me in a private mail. I am forwarding it to the mailist list for everyone's benefit. Once again, thanks Mark. Baiju > -----Original Message----- > From: mark@mentat.com [SMTP:mark@mentat.com] > Sent: Friday, February 27, 1998 12:26 PM > To: baiju.v.patel@intel.com > Subject: RE: IPSEC WORKING GROUP LAST CALL > > Baiju, > > I'm sending this just to you, not the list.... Please read the specs > more carefully to answer your very basic questions, see my comments > below for clues. > > > Transform ID Value > > ------------ ----- > > RESERVED 0-1 > > AH_MD5 2 > > AH_SHA 3 > > AH_DES 4. > > > > I do not see an AH NULL here. > > Correct. We're talking about AH, not ESP there. It is not allowed to > have a NULL or no authentication with the authentication header (AH), > thats > its purpose in life! > > > > > ESP specs to not have authentication data optional. therefore, we > do > > need this field. If we indeed managed to specify null > authentication > > what will be the length of this field and what would we put there. > > Please read draft-ietf-ipsec-esp-v2-03.txt and note in particular the > following section. There are also numerous references throughout the > document to this issue of ESP without authentication. > > 2.7 Authentication Data > > The Authentication Data is a variable-length field containing an > Integrity Check Value (ICV) computed over the ESP packet minus > the > Authentication Data. The length of the field is specified by the > authentication function selected. The Authentication Data field > is > optional, and is included only if the authentication service has > been > selected for the SA in question. The authentication algorithm > specification MUST specify the length of the ICV and the > comparison > rules and processing steps for validation. > > > Also, note the following text from section 4.5 of the document > draft-ietf-ipsec-ipsec-doi-07.txt. This explains how to have ESP > negotiated without an authentication algorithm. > > There is no default value for Auth Algorithm, as it must be > specified to correctly identify the applicable AH or ESP > transform, except in the following case. > > When negotiating ESP without authentication, the Auth > Algorithm attribute MUST NOT be included in the proposal. > > > > Hope this helps! Perhaps once you're re-read these documents > carefully > you'll see how to use AH+ESP effectively or perhaps decide ESP alone > is sufficient, perhaps in tunnel mode. > > > -- Marc -- From owner-ipsec Mon Mar 2 07:11:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20717 for ipsec-outgoing; Mon, 2 Mar 1998 07:11:22 -0500 (EST) Message-ID: <19980228095813.12847@hazel> Date: Sat, 28 Feb 1998 09:58:13 -0500 From: Raul Miller To: Stephen Waters Cc: ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP Mail-Followup-To: Stephen Waters , ipsec@tis.com References: <250F9C8DEB9ED011A14D08002BE4F64C011D5A91@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C011D5A91@wade.reo.dec.com>; from Stephen Waters on Sat, Feb 28, 1998 at 12:59:02PM -0000 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > ... but what is the IPSEC response to encapsulating bridged traffic > and insuring there is no reordering? [opinion:] Of course, tcp deals with this. It might be nice to have a protocol designed to provide a udp-style interface, which uses tcp-like state except that it is willing to discard packets whose latency is too far above the mean. But this is hardly essential. Using a transport layer for network is presumably not as ultimately efficient in terms of bandwidth as a purely internetwork solution, but it seems very efficient in terms of design resources. I think that it's currently outside the scope of this group to bring tcp's semantics into the ip layer. As I see it, this kind of configuration involves two logical interfaces at the endpoint (one for the tunnel, one for the traffic) with logically distinct key management. -- Raul From owner-ipsec Mon Mar 2 08:29:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA21700 for ipsec-outgoing; Mon, 2 Mar 1998 08:27:21 -0500 (EST) Message-Id: <3.0.3.32.19980302083402.009f3b90@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 02 Mar 1998 08:34:02 -0500 To: "M.C.Nelson" From: Stuart Jacobs Subject: Re: IPSEC tunnels and Mobile IP Cc: ipsec@tis.com In-Reply-To: References: <3.0.5.32.19980227102904.0099ade0@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:40 PM 3/1/98 -0500, you wrote: > > >On Fri, 27 Feb 1998, Robert Moskowitz wrote: > >> At 03:28 PM 2/26/98 -0000, Stephen Waters wrote: >> > >> >Does IPSEC tunnel mean I can forget about Mobile IP? >> >> IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and >> pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, >> or conference LAN does not need Mobile IP, only IPsec. >> > >I once again don't understand this. To me the difference between >a mobil user and other uses of IP, as far as the protocols are concerned, >is that the mobile user is likely to have a different IP address from one >instance to the next, and is likely to be routed differently from one >instance to the next. The Mobile IP user always has a permanent IP address (that IP address he/she uses in their home subnet). When the mobile IP user roams from the home subnet, the user is issued a temporary IP address (which is mapped by the home and foreign agents to the roaming user's permanent IP address) for use in the visited subnet. All other nodes which send packets to the roaming node can still use the roaming node's permanent IP address whithout having any apriori knowledge of the roaming node's current subnet location. Namely a roaming Mobile IP equipped node never loses it's home IP identity, it can always be addressed by its home subnet IP address. The only routing changes that predictably occur when a mobile IP node roams, is the tunnel from the node's home agent to the foreign agent serving the subnet currently being visited by the mobile IP node >In a public network, the two may often go together. >In a private network, including "tanks, soldiers, etc.", this may actually >not be the case as often. So it seems to me that tanks and soldiers >actually could conceivably look more like the non-mobile case as far >as the network protocols are concerned, at least more often than does the >salesman in his hotel room, unless the salesman always dials into the >same service point and always gets the same address. > >It seems to me that the real challenge presented by mobile IP, and also >by many office LANS, is the dynamic IP address. Will the present >protocols accomodate dynamic IP and NFS on a multi-user host? Mobile IP does not prevent the use of NFS even if the exported file systems are on a roaming mobile IP equipped node. >Is there a scalable key infrastructure that will accomodate this? For Mobile IP to become more than a lab proof-of-concept protocol, it needs to be adopted by packet service carriers (Cellular Phone companies, ..) and included in shrink-wrapped desk-top computer operating systems (Win95, NT, Solaris, Linux, ...) as a standard component. For customers to see any advantage to using Mobile IP away from their home subnet, using Mobile IP must be transparent to the user. This means that many network operators in a metropolitan area needs to provide Mobile IP support. Consequently Mobile IP must work acroaa many operator domains and yet provide a common SCALEABLE security/authentication mechanism. I contend that Mobile IP's authentication must be public key based so it can scale to 10,000s of users. This approach must also include cross-CA certificate validation since it is Very unlikely that the different service providers in an area will subscribe to the same CA. I see the following as a very typical scenario in a few years: "You are busy in your office checking out the new corporate web pages you just finished for a major customer across town when you get a phone call. The call is from the CIO of this customer and he wants a meeting in his office in one hour to review your progress. So you shut down your laptop, moving it from its docking station to your briefcase and head to you car. When you get stuck in a traffic jam half way across town, you boot the laptop, bring up your email and send the CIO a high priority email that you will be 30 minutes late to the meeting. After the jam clears, you continue heading to the customers location. Upon arriving you head to the CIO's office. During the meeting you find that a key web page was left on another computer back at work. So you boot up your laptop and retrieve the needed page allowing you to continue your presentation. After the meeting, before leaving the parking lot to return to your office, you decide to check your email and find an emergency message for you to go home. After getting home and resolving the emergency, you decide to continue working from home rather than bucking the rush hour traffic back to the office. So you boot the laptop and start checking on the status of another project your involved with." Widely available Mobile IP, with scaleable authentication (and billing capabilities) can make the above work. > > >Regards, >Mitch Nelson > > > ========================== Stuart Jacobs CISSP Network Security GTE Laboratories 40 Sylvan Road Waltham, MA 02254 USA telephone: (781) 466-3076 fax: (781) 466-2838 ========================== From owner-ipsec Mon Mar 2 09:36:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22293 for ipsec-outgoing; Mon, 2 Mar 1998 09:35:23 -0500 (EST) Date: Mon, 2 Mar 1998 09:48:35 -0500 Message-Id: <9803021448.AA28240@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@cisco.com Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL References: <3.0.3.32.19980227225721.00973710@netcom.com> <199802280707.XAA11273@dharkins-ss20.cisco.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Daniel" == Daniel Harkins writes: >> >>>>1. No data recovery of an encrypted IP datagram payload. >> >>>This is a feature, not a bug, by strong consensus... >> >>I >> understand this. I am certain that this requirement will not >> change for >>the forseeable future, regardless of our consensus. >> I am also certain that >>this requirement can be met, in a manner >> that would satisfy our community... > >A significant fraction of >> the community will not be satisfied by any >protocol which >> incorporates key recovery. The objection is not to the >technical >> details of key recovery, but to its presence in any form. > >> >> My view is that it's just another tool to be used to solve certain >> types of problems. Whether you realize it or not, we have been >> outmaneuvered by other communities with different desires. Daniel> It's not really "outmaneuvered"; it's more like conceding the Daniel> low-ground. The only justification for key recovery in a Daniel> communications product (as opposed to a stored-data product) Daniel> is to facillitate evesdropping. We don't want to "solve" that Daniel> problem-- and in fact don't view lack of key recovery as a Daniel> problem in the first place! I agree. We should strive to keep IPSec useful. RFC 1984 is worth reading in this context. paul From owner-ipsec Mon Mar 2 11:14:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23124 for ipsec-outgoing; Mon, 2 Mar 1998 11:13:32 -0500 (EST) Message-ID: <34FADD6C.F26@toast.net> Date: Mon, 02 Mar 1998 10:25:16 -0600 From: Pat Calhoun Reply-To: pcalhoun@toast.net Organization: Sun Microsystems X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Stuart Jacobs CC: Hilarie Orman , rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: <3.0.3.32.19980227154932.00a2d100@pophost.gte.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stuart Jacobs wrote: > > The only way Mobile IP will get out of the lab and into commercial products > and service offerings is by allowing service providers the ability to > generate revenues necessitating scaleable, robust authentication and access > control for billing purposes. I am addressing this issue as we type. PatC Sun From owner-ipsec Mon Mar 2 11:14:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23123 for ipsec-outgoing; Mon, 2 Mar 1998 11:13:28 -0500 (EST) Message-ID: <34FADD78.20B5@toast.net> Date: Mon, 02 Mar 1998 10:25:28 -0600 From: Pat Calhoun Reply-To: pcalhoun@toast.net Organization: Sun Microsystems X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: "Michael C. Richardson" CC: Stuart Jacobs , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: <199802280115.UAA09853@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I find, without ubiquitous IPsec to give me that constant IP in the tunnel, > that my NetBSD notebook is for all intensive purposes mobile: it does DHCP on > any network I plug it into (or detects the default routers on networks that > don't have DHCP), and my TCP sessions are generally short enough (POP over > SSH, SMTP, HTTP) that I never worry about keeping the same IP address. I would prefer to call it portable, not mobile. I agree with you that the need for Mobility in early 1998 is limited, but I am convinced that this will change within the next 2 years as technologies such as GSM (among others) become ubiquitous. Many predict that everyone will have GSM to their homes instead of land lines. Once this occurs, the need for Mobility will become much more obvious. If we ignore the need for Mobility and simple abuse an already complicated protocol, we will simply make integration of mobility into everyone's lives much more complicated. PatC From owner-ipsec Mon Mar 2 11:15:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23163 for ipsec-outgoing; Mon, 2 Mar 1998 11:15:29 -0500 (EST) Message-ID: <34FADD75.3EF3@toast.net> Date: Mon, 02 Mar 1998 10:25:25 -0600 From: Pat Calhoun Reply-To: pcalhoun@toast.net Organization: Sun Microsystems X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Raul Miller CC: Stephen Waters , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: <250F9C8DEB9ED011A14D08002BE4F64C011D5A72@wade.reo.dec.com> <19980226165832.22709@hazel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Raul Miller wrote: > > Client should have at least two ip addresses for Mobile IP under IPSEC. > One is a fixed address and is used inside the client's tunnel. The other > may vary with location and would be used to establish the client's > tunnel. The Client can use the Foreign Agent's Care-of-address, which would allows the client to only use it's static IP address (one address only). > > You still need something like the NAS for a remote machine to hook up > with the current instance of the client's tunnel. A NAS can easily integrate the Foreign Agent functionality. From owner-ipsec Mon Mar 2 11:15:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23162 for ipsec-outgoing; Mon, 2 Mar 1998 11:15:29 -0500 (EST) Message-ID: <34FADD6E.DDB@toast.net> Date: Mon, 02 Mar 1998 10:25:18 -0600 From: Pat Calhoun Reply-To: pcalhoun@toast.net Organization: Sun Microsystems X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Stephen Waters CC: Steve Bellovin , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: <250F9C8DEB9ED011A14D08002BE4F64C011D5A91@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > > 1) What is happening now. Client-based L2 tunnel (PPTP, L2TP soon) seem > to rule the waves at the moment. No support is needed from the VPN > carriers. I know there are problems with this model, but it is > available and it is simple. IPSEC Clients are offered by some (NewOak, > Ascend, others?), and I'm sure they are just as flexible, more > scalable, and have less bandwidth overhead. I guess I've talked my self > out of that one then! L2TP has alot of momentum at this time. Support from Carriers is really required at this time since most L2TP implementations exist in either NAS' and LNS'. There are very few client implementations (if any) at this time. Yes, the overhead is enormous. This is especially true for what is commonly called Voluntary Tunneling, which allows the 'PPP' client to setup its own L2TP tunnel to the LNS. In this case, the protocol headers look like PPP|IP|UDP|PPP|IP. > > 2) ISP-based model for L2TP. This seems to offer some advantage over > the client-based option. It 'hides' the client from non-tunnel > traffic; the client does not have a global IP address (saving on > addresses); the client does not need to know the tunnel-server address; > Dial-media information present at the NAS/LAC can be forwarded to the > LNS; and PPP is more suitable for multi-protocol support (e.g. bridged > LANs). I can think of ways that all these services could be resolved > for IPSEC (filtering, NAT, PPP IPCP, DNS), but what services are offered > by VPN carriers? Well, the saving of addresses is a moot point. ISPs allocate blocks of addresses equal to the number of ports on their NASes to ensure that all dial-in clients get access. Although many would prefer to disagree, multi-protocol is very valuable. This is where TEP comes into play. It provides the same functionality as MobileIP, but also provides Multi-Protocol support (among other features). > > 3) General LAN-to-LAN problem. The L2TP spec spends a bit of time > discussing the problems with protocols that dislike reordering > (LAN-based protocols) and protocols that dislike packet loss (standard > PPP compression/encryption) by suggesting that Reliable PPP and L2TP > reordering could be used. IPSEC/IPCOMP fixes the packet-loss issue > (although block-mode encryption and compression is more crackable/less > efficient that history-mode), but what is the IPSEC response to > encapsulating bridged traffic and insuring there is no reordering? The > conclusion I have come to at the moment is that I either invent some way > of injecting a reliable data-link into my IPSEC tunnel, or I just wait > for the VPN carriers to offer me a better service for LAN-to-LAN > requirements. I suppose I see things differently. I would prefer the application to handle retransmission. This allows real time protocols to work better in "tunneled" scenarios. > > 4) Throughput monitoring. While I'm waiting for VPN carriers to support > an 'SVC' QOS, it is tempting to think of a high-speed Internet pipe > (Cable Modem/xDSL) as a very good value for money LAN-to-LAN pipe WHEN I > CAN GET GOOD QOS. As a remote worker (Home Office), I have tried to use > the Internet to connect to work, but the performance can drop-off > alarming at times, so instead, I dial direct with ISDN. What I really > want is a smart SOHO router that can detect when things are going > pair-shaped (big drop in QOS) on the VPN tunnel, shut the tunnel down > for awhile, and dial direct - all without me lifting a finger. The base > problem is knowing how much of the data you pump into the VPN tunnel > actually gets to the peer tunnel end-point! If my SOHO router could > monitor that dynamically with reference to some 'Minimum Throughput' > setting, I'd be in with a shout. For Bridged LANs, the problem is worse > - I need to know how much of the data got to the peer without getting > reordered. The only way I can see to fix both of these problems is to > either run RPPP (for L2TP case) or squeeze a TCP header into the IPSEC > tunnel (not a popular concept, I know). Studies I have seen seem to show that VPNs over the Internet will NOT happen until QOS is widely deployed. The functionality you are suggesting is interesting, but it assumes that the SOHO router understands the type of traffic being tunneled in order to know when data loss occurs. PatC Sun From owner-ipsec Mon Mar 2 12:26:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23906 for ipsec-outgoing; Mon, 2 Mar 1998 12:25:28 -0500 (EST) From: Vach Kompella To: Subject: IPSec policy Message-ID: <5040200012314815000002L052*@MHS> Date: Mon, 2 Mar 1998 12:39:39 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk It looks like the policy descriptors have been designed from the initiator perspective, rather than the responder perspective. When the initiator wants to figure out the policy, it goes to the policy database, and grabs the appropriate proposals, etc. When the responder gets this incoming request, it should also go to its own policy database. The proposal, from a responder perspective, can be lined up along side the initiator proposal, and somehow you figure out which is the most appropriate (I say that somehow you figure it out because the results could change depending on whether you consider the initiator proposal to take precendence over the responder or not: is this worth standardizing?). Anyway, it's highly unlikely that the proposal will match, down to exact expiry values. I think the responder proposal must have a range for attributes that are "rangeable." E.g., it may make sense to have a policy that says the RC5 encryption alg will be accepted with any key size between 512 and 1024, rather than code up a separate proposal for each acceptable key length value. The responder proposal is obviously useful only for responding. The initiator proposal does not have a place for ranges in the format of the proposal. Vach Kompella IBM Corp. Network Security Product Development kompella@us.ibm.com Ph.: (919) 254-7281 Fax: (919) 254-4239 From owner-ipsec Mon Mar 2 12:33:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24082 for ipsec-outgoing; Mon, 2 Mar 1998 12:33:28 -0500 (EST) Message-Id: <199803021719.MAA06987@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-arch-sec-03.txt Date: Mon, 02 Mar 1998 12:19:19 -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) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-03.txt Pages : 65 Date : 27-Feb-98 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-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-arch-sec-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: <19980227151432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980227151432.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 2 12:33:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24083 for ipsec-outgoing; Mon, 2 Mar 1998 12:33:28 -0500 (EST) Message-Id: <199803021719.MAA06968@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org From: Internet-Drafts@ns.ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-05.txt Date: Mon, 02 Mar 1998 12:19:15 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, B. Phan, C. Metz Filename : draft-mcdonald-pf-key-v2-05.txt Pages : 70 Date : 27-Feb-98 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a,HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-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-mcdonald-pf-key-v2-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: <19980227145100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980227145100.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 2 14:02:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24988 for ipsec-outgoing; Mon, 2 Mar 1998 14:01:30 -0500 (EST) Message-ID: <34FB0512.41C6@cs.umass.edu> Date: Mon, 02 Mar 1998 14:14:26 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: "Clark, Cynthia" Subject: Re: I-D ACTION:draft-mcdonald-pf-key-v2-05.txt References: <199803021719.MAA06968@ns.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Internet-Drafts@ns.ietf.org wrote: > Title : PF_KEY Key Management API, Version 2 > Author(s) : D. McDonald, B. Phan, C. Metz > Filename : draft-mcdonald-pf-key-v2-05.txt [...] > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-05.txt ds.internic.net still only seems to have the -04 version, not -05. However (for example) ftp://ftp.ietf.org/internet-drafts/draft-mcdonald-pf-key-v2-05.txt exists. -L From owner-ipsec Mon Mar 2 14:02:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25031 for ipsec-outgoing; Mon, 2 Mar 1998 14:02:30 -0500 (EST) Message-Id: <199803021915.OAA10105@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Mar 1998 14:13:19 -0500 To: ipsec@tis.com From: Matt Thomas Subject: Another slicing and dicing issue. In-Reply-To: <34FADD78.20B5@toast.net> References: <199802280115.UAA09853@istari.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In DOI-07 the Key Length attribute does not state what units (bits or octets) it represents. Assuming it's bits (for the following argument), when someone negotiates a key length that's not a multiple of 8 (say for CAST or Blowfish), when the key material that IKE provides is sliced and diced, should the amount of key-material for non-octet sized keys be rounded to next octet boundary? (Whew!) For example, I negotiate a 123 bit key length for CAST with HMAC-SHA1. When slicing the key material up, should CAST be 128 bits (while dropping the 5 least significant bits) and the remainder for HMAC-SHA1 or 123 bits for CAST and the rest (appropriately shifted to compensate for the 5 bits in the middle octet not used by CAST)? I think the former would be simplier (when slicing and dicing, and therefore when generating key material, each slice needs to rounds to the octet boundary) and should be specified in the cipher document. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Mon Mar 2 21:06:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA27889 for ipsec-outgoing; Mon, 2 Mar 1998 21:00:29 -0500 (EST) Date: Mon, 2 Mar 1998 21:13:24 -0500 (EST) From: "M.C.Nelson" To: Stuart Jacobs cc: ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-Reply-To: <3.0.3.32.19980302083402.009f3b90@pophost.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 2 Mar 1998, Stuart Jacobs wrote: > The Mobile IP user always has a permanent IP address (that IP address > he/she uses in their home subnet). When the mobile IP user roams from the > home subnet, the user is issued a temporary IP address (which is mapped by > the home and foreign agents to the roaming user's permanent IP address) for > use in the visited subnet. All other nodes which send packets to the > roaming node can still use the roaming node's permanent IP address whithout > having any apriori knowledge of the roaming node's current subnet location. > Namely a roaming Mobile IP equipped node never loses it's home IP identity, > it can always be addressed by its home subnet IP address. The only routing > changes that predictably occur when a mobile IP node roams, is the tunnel > from the node's home agent to the foreign agent serving the subnet > currently being visited by the mobile IP node > Is this scheme and its terminology specifically defined in a Standard anywhere? It sounds to me to be in the category of legal uses of the protocol. But it doesn't answer the question and it doesn't address the way I and many others use the protocol, including dynamic IP, NFS, and multi-user hosts. Mitch Nelson From owner-ipsec Tue Mar 3 00:07:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA29038 for ipsec-outgoing; Tue, 3 Mar 1998 00:05:30 -0500 (EST) Message-ID: <71F9F43682B7D011BDA20020C5E2CCB31456C1@FTP> From: Titus Peedikayil To: "'ipsec@tis.com'" Subject: IPsec SA establishment through ISAKMP Date: Mon, 2 Mar 1998 21:18:29 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like some clarification on the following thoughts. I have assumed that each host has seperate OUTBOUND and INBOUND SADs. They also have seperate OUTBOUND and INBOUND SPDs. i) When a host A sends an ISAKMP proposal payload to host B, would not the proposals be based on the INBOUND IPsec policy (SPD) on host A (since IPsec SAs are receiver-oriented)? And since the SPIs for the proposals are determined by the protocols supported on host A, the tuple will be unique on host A. ii) If (i) is correct, then B chooses a proposal based on the OUTBOUND IPsec policy (SPD) and returns it in its reply (proposal payload). This proposal represents the IPsec processing (or transforms) that B applies when it sends data packets to A. So B would create an SA with the selected proposal in the OUTBOUND SAD. iii) If (i) is correct, then steps (i) and (ii) only achieves secure communication from B to A. If B too were to initiate a proposal payload, then communication could be secured from A to B also just like in (i) and (ii). But if the ISAKMP on B does not initiate a proposal payload, is there some way for A to force it? Thanks Titus. From owner-ipsec Tue Mar 3 07:53:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02281 for ipsec-outgoing; Tue, 3 Mar 1998 07:50:31 -0500 (EST) Message-ID: <34FBFF86.4C9B@toast.net> Date: Tue, 03 Mar 1998 07:03:02 -0600 From: Pat Calhoun Reply-To: pcalhoun@toast.net Organization: Sun Microsystems X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: "M.C.Nelson" CC: Stuart Jacobs , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk M.C.Nelson wrote: > > Is this scheme and its terminology specifically defined in a Standard > anywhere? It sounds to me to be in the category of legal uses of the > protocol. But it doesn't answer the question and it doesn't address the > way I and many others use the protocol, including dynamic IP, NFS, and > multi-user hosts. > Yes it is. You can read RFC2002 for more information. Charles Perkins also has a good book on Mobility and Mobile IP as does Jim Solomon. PatC From owner-ipsec Tue Mar 3 09:50:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03101 for ipsec-outgoing; Tue, 3 Mar 1998 09:49:35 -0500 (EST) Message-Id: <3.0.1.32.19980303181657.00688284@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 03 Mar 1998 18:16:57 +0500 To: ipsec@tis.com From: rohit Subject: Proxy Key Exchange Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, What is the meaning of Proxy Key Exchange ??, and where i will get info regarding that. Thanks In Advance Rohit ******************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ******************************************************************* From owner-ipsec Tue Mar 3 10:52:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03602 for ipsec-outgoing; Tue, 3 Mar 1998 10:50:37 -0500 (EST) Message-Id: <34FC1F6C.A44EEBE8@ericsson.com> Date: Tue, 03 Mar 1998 17:19:08 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab, 02420 Jorvas, Finland X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.4 sun4m) Mime-Version: 1.0 To: pcalhoun@toast.net, ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP References: <199802280115.UAA09853@istari.sandelman.ottawa.on.ca> <34FADD78.20B5@toast.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Pat Calhoun wrote: >I would prefer to call it portable, not mobile. I agree with you that >the need for Mobility in early 1998 is limited, but I am convinced that >this will change within the next 2 years as technologies such as GSM >(among others) become ubiquitous. That's right, by this definition, mobile means "does not need to be booted after moving from one place to another". I think an important observation is that mobility could be handled by different levels in the protocol stack. In the case of circuit switched GSM, for instance, the GSM system has its own mechanisms for handling mobility - the other end of a call is always attached to your ISP's modem pool while your end moves around. While I think that the GSM packet switched standards are not completely ready, I believe that there are similar mechanisms in there as well. This makes mobile IP only useful in cases where you switch between media (office LAN to GSM). (I'm not a true GSM expert; it is possible that there are also some exceptional cases such as moving from one country to another which may not be supported by all versions of the underlying mobile network mechanism.) /Jari P.S. I happen to live in a country where mobility already is ubiquitous: in Finland 40% of _all_ people have a mobile phone :-) ------------------------------------------------------------------------- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2992634. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com WWW: http://www.iki.fi/jar. Standard disclaimers apply. From owner-ipsec Tue Mar 3 12:45:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04697 for ipsec-outgoing; Tue, 3 Mar 1998 12:43:38 -0500 (EST) Message-Id: <199803031743.MAA04697@portal.ex.tis.com> To: ipsec@tis.com Subject: Quick Mode client IDs From: Shawn Mamros Date: Tue, 03 Mar 1998 12:30:17 EST Sender: owner-ipsec@ex.tis.com Precedence: bulk One issue which has been raised here at the IPSec interoperability workshop is the usage of client IDs in IKE Quick Mode, and what should be assumed if they are not specified. To help resolve this, we have come up with some (hopefully) clarifying text, which is proposed to replace the current fourth paragraph of section 5.5 of the IKE draft (draft-ietf-ipsec-isakmp-oakley-06.txt): The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18), followed by an acceptable pair of client identifiers, in two ID payloads (IDci followed by IDcr) SHOULD be sent. Questions and comments welcome... -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Tue Mar 3 14:31:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05552 for ipsec-outgoing; Tue, 3 Mar 1998 14:29:39 -0500 (EST) Message-Id: <199803031929.OAA05552@portal.ex.tis.com> Date: Tue, 3 Mar 1998 14:33:22 -0500 (EST) From: Jorg Liebeherr To: tccc@ieee.org Subject: CFP - Special Issue - Multimedia Collaborative Environments - March 15, 1998 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk ----------------------------------------------------------- >>>>> Submission deadline: March 15, 1998 <<< ----------------------------------------------------------- *********** CALL FOR PAPERS ****************** CLUSTER COMPUTING: Networks, Software Tools, and Applications (Publisher: Baltzer Science) Special Issue on MULTIMEDIA COLLABORATIVE ENVIRONMENTS The emerging high-performance network infrastructure will be able to deliver data, video, and audio, and will support new multimedia applications, such as interactive telecollaboration tools, immersive visualization, and virtual environments. The objective of this special issue is to present the state-of-the-art of the research on multimedia computing, collaborative environment, and related areas. Topics of Interest: - Virtual Environments - Tele-Presence Applications - Collaboration Tools - Distance Learning Systems - Media Servers - Multimedia Networks - Multimedia Delivery - Multimedia Models - Security - Wireless Multimedia Important Dates: Submission deadline: March 15, 1998 Notification of acceptance: May 15, 1998 Publication Date: 4th Quarter 1998 Submission Guidelines: Authors are requested to submit by March 15, 1998, five copies of a manuscript (max. 25 pages) to: Prof. Jorg Liebeherr Polytechnic University Department of Electrical Engineering 6 MetroTech Center Brooklyn, NY 11201 Phone: +1-718-260-3493 Fax: +1-718-260-3074 E-mail: jorg@catt.poly.edu ******** A PDF version of this CFP can be obtained from ************ ******** http://aida.poly.edu/~jorg/Cluster-CFP.html ************ From owner-ipsec Tue Mar 3 15:02:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05800 for ipsec-outgoing; Tue, 3 Mar 1998 15:01:40 -0500 (EST) Date: Tue, 3 Mar 1998 15:14:09 -0500 Message-Id: <9803032014.AA02055@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smamros@BayNetworks.COM Cc: ipsec@tis.com Subject: Re: Quick Mode client IDs References: <199803031743.MAA04697@portal.ex.tis.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Shawn" == Shawn Mamros writes: Shawn> One issue which has been raised here at the IPSec Shawn> interoperability workshop is the usage of client IDs in IKE Shawn> Quick Mode, and what should be assumed if they are not Shawn> specified. To help resolve this, we have come up with some Shawn> (hopefully) clarifying text, which is proposed to replace the Shawn> current fourth paragraph of section 5.5 of the IKE draft Shawn> (draft-ietf-ipsec-isakmp-oakley-06.txt): Shawn> The identities of the SAs negotiated in Quick Mode are Shawn> implicitly assumed to be the IP addresses of the ISAKMP peers, Shawn> without any implied constraints on the protocol or port Shawn> numbers allowed, unless client identifiers are specified in Shawn> Quick Mode. If ISAKMP is acting as a client negotiator on Shawn> behalf of another party, the identities of the parties MUST be Shawn> passed as IDci and then IDcr. Local policy will dictate Shawn> whether the proposals are acceptable for the identities Shawn> specified. If the client identities are not acceptable to the Shawn> Quick Mode responder (due to policy or other reasons), a Shawn> Notify payload with Notify Message Type INVALID-ID-INFORMATION Shawn> (18), followed by an acceptable pair of client identifiers, in Shawn> two ID payloads (IDci followed by IDcr) SHOULD be sent. That sounds right -- except that I'm not sure about the last sentence. Suppose I have an ISAKMP SA identified by my IP address, and policy says that IPSEC SAs must be identified with usernames. How would I construct "an acceptable pair of client identifiers"? And what is the intended interpretation of that information? I suppose I could send back a pair of names like "foo@bar.com" which the other end is expected to interpret as "send me something that looks like this pattern". Is that the intent? paul From owner-ipsec Tue Mar 3 21:15:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA08290 for ipsec-outgoing; Tue, 3 Mar 1998 21:10:43 -0500 (EST) From: Will Fiveash Message-Id: <199803040223.UAA28502@vulcan.austin.ibm.com> Subject: Re: I-D ACTION:draft-mcdonald-pf-key-v2-05.txt In-Reply-To: <34FB0512.41C6@cs.umass.edu> from Lewis McCarthy at "Mar 2, 98 02:14:26 pm" To: lmccarth@cs.umass.edu (Lewis McCarthy) Date: Tue, 3 Mar 1998 20:23:28 -0600 (CST) Cc: ipsec@tis.com, cclark@ietf.org X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy wrote: > Hi, > > Internet-Drafts@ns.ietf.org wrote: > > Title : PF_KEY Key Management API, Version 2 > > Author(s) : D. McDonald, B. Phan, C. Metz > > Filename : draft-mcdonald-pf-key-v2-05.txt > [...] > > A URL for the Internet-Draft is: > > ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-05.txt > > ds.internic.net still only seems to have the -04 version, not -05. > > However (for example) > ftp://ftp.ietf.org/internet-drafts/draft-mcdonald-pf-key-v2-05.txt > exists. I just tried to get internet-drafts/draft-mcdonald-pf-key-v2-05.txt and /internet-drafts/draft-ietf-ipsec-arch-sec-03.txt from mailserv@ds.internic.net to no avail (files not found). Any idea when these documents will be available via ds.internic.net? BTW, here is my .mailcap entry for auto-generating the email request from the I-D ACTION notices: # for IETF IPSEC Draft Notifications message/external-body; grep -v '^Content' %s | mail %{server} ; \ test=test %{access-type} = mail-server; \ description="Request doc from mailserv@ds.internic.net?" -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Tue Mar 3 22:04:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA08743 for ipsec-outgoing; Tue, 3 Mar 1998 22:03:44 -0500 (EST) Date: Tue, 3 Mar 1998 22:16:15 -0500 (EST) From: "M.C.Nelson" To: Pat Calhoun cc: Stuart Jacobs , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-Reply-To: <34FBFF86.4C9B@toast.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Thank you. The point I was clumsily trying to make is that this ("Mobile IP") seems to be an application and as such, does not appear to be something that should really have much do with the IP layer itself, except as being a legitimate use of it. Meanwhile there appear to be other problems associated with what other people think of when they use the word "mobile", and these problems really do have some connection to elements already defined in the IP layer and could be exacerbated by new elements which would be introduced by IPSEC. Again, I am quite curious to hear how one would handle a dynamic IP multi-user host that uses NFS. I don't think that it is impossible within a certain set of cases, but I'd like to see a general solution. Mitch Nelson From owner-ipsec Wed Mar 4 11:59:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14244 for ipsec-outgoing; Wed, 4 Mar 1998 11:54:48 -0500 (EST) From: Kai Martius Organization: Uniklinik TUD To: Titus Peedikayil , ipsec Date: Wed, 4 Mar 1998 17:55:02 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IPsec SA establishment through ISAKMP Reply-to: kai@imib.med.tu-dresden.de In-reply-to: <71F9F43682B7D011BDA20020C5E2CCB31456C1@FTP> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <218BAE62187@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Titus Peedikayil > To: "'ipsec@tis.com'" > Subject: IPsec SA establishment through ISAKMP > Date: Mon, 2 Mar 1998 21:18:29 -0800 > I would like some clarification on the following thoughts. I have > assumed that each host has seperate OUTBOUND and INBOUND SADs. They also > have seperate OUTBOUND and INBOUND SPDs. > > i) When a host A sends an ISAKMP proposal payload to host B, would not > the proposals be based on the INBOUND IPsec policy (SPD) on host A > (since IPsec SAs are receiver-oriented)? And since the SPIs for the > proposals are determined by the protocols supported on host A, the tuple > will be unique on host A. > > ii) If (i) is correct, then B chooses a proposal based on the OUTBOUND > IPsec policy (SPD) and returns it in its reply (proposal payload). This > proposal represents the IPsec processing (or transforms) that B applies > when it sends data packets to A. So B would create an SA with the > selected proposal in the OUTBOUND SAD. > > iii) If (i) is correct, then steps (i) and (ii) only achieves secure > communication from B to A. If B too were to initiate a proposal payload, > then communication could be secured from A to B also just like in (i) > and (ii). But if the ISAKMP on B does not initiate a proposal payload, > is there some way for A to force it? I also stumbled over this question some weeks ago. I think the current situation is, that we have different keys and SPIs after the exchange, but the SA is applied in both directions, that is, INCOMING and OUTGOING rules are updated. To use these "asymmetric" channels, either the IKE-exchange is to be declared unidirectional (I mean SA is only used as described in the question) or there must be a way for B to inform A about it's own requirements for the current SA request, which could easily be done by an own SA proposal of B in the first IKE message to A. A replies in the third message (But this would be a quite great change to IKE we don't need at this point, I think..., may be IKE V.2) (everything applies to SAs exchanged under phase II) However, I wasn't at this list from the beginning, so I would be interested if this issue was discussed earlier? (May be, the question first arises with SAD / SPD definitions in architecture document). Regards Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # available at http://www.imib.med.tu-dresden.de/imib/personal/kai.html # # # # See our project (and me) at CeBit'98 fair Hannover/Germany 19-25.3.98 # # Infos: http://www.inf.tu-dresden.de/~hf2/cebit98 # From owner-ipsec Thu Mar 5 01:05:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA19657 for ipsec-outgoing; Thu, 5 Mar 1998 01:00:03 -0500 (EST) Date: Thu, 5 Mar 98 05:58:47 GMT Standard Time From: Ran Atkinson Subject: Re: Proxy Key Exchange To: ipsec@tis.com, rohit X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19980303181657.00688284@192.9.200.10> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Rohit, I'd suggest reading the RFC on the DNS Key Exchanger record for information on some possible scenarios with IPsec and Proxy Key Management. The PF_KEYv2 Internet-Draft might also have information on Proxy Key Management. If there are questions after studying both of those, specific questions could go to this list or I'd be happy to have a unicast email exchange (thus sparing the rest of the list). Truth is, I should have written an Informational RFC on this in 1995. However, I haven't yet done so... Sorry. Ran rja@inet.org From owner-ipsec Thu Mar 5 02:06:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA20049 for ipsec-outgoing; Thu, 5 Mar 1998 02:05:01 -0500 (EST) Message-Id: <199803050545.AAA10925@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com cc: wdm@tycho.ncsc.mil Subject: Notify message types Date: Thu, 05 Mar 1998 00:45:19 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- There was a brief discussion at the IPsec workshop on end client issues, specifically relating to configuration. One issue that came up was that it is difficult to report errors to the user in a reasonable way. Notifies carry no information text, and do not indicate which payload was at fault. I volunteered to write some text for the DOI that describes the DOI-defined notification data field. I will post my minutes from that meeting. Perhaps someone else will also do that. Questions: 1. why does the notify message space define a DOI specified status types, but no DOI specified error types? 2. ipsec-doi-07.txt reserves one of the private use numbers (8192) as being "RESERVED"... why? Is it historical? A proposal for the upcoming isakmp-09 document: I'd like to suggest that the Notify types be reworked to say: 3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size !A|R|F| Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Yes, Doug, can we *please* number the bits based on their network byte order significance, with the significance of the bits being their 2^x value] A - abort bit, R is registry bit, F tells me which "file" (aka document) to look in. {Abort, Retry, Fail?} It would be *nice* to simplify it to: A = 0 - errors that cause the negotiation to be (A)borted A = 1 - errors that don't cause the negotiation to be (A)borted R = 0 - registered (standards document defined) values R = 1 - private use values F = 0 - ISAKMP defined values F = 1 - DOI defined values This results in: 0b000xxxxxxxxxxxxx 0-8191 - ISAKMP error codes 0b001xxxxxxxxxxxxx 8192-16383 - DOI error codes 0b010xxxxxxxxxxxxx 16384-24575 - private use ISAKMP error codes 0b011xxxxxxxxxxxxx 24576-32767 - private use DOI error codes 0b100xxxxxxxxxxxxx 32768-40959 - ISAKMP status codes 0b101xxxxxxxxxxxxx 40960-49151 - DOI status codes 0b110xxxxxxxxxxxxx 49152-57343 - private use ISAKMP status codes 0b111xxxxxxxxxxxxx 57344-65535 - private use DOI status codes Unfortunately, that results in changes to bits on the wire. Specifically, it moves msg before after CONNECTED 16384 32768 RESPONDER-LIFETIME 24576 40960 REPLAY-STATUS 24577 40961 INITIAL-CONTACT 24578 40962 Note, the DOI's RESERVED moves into the newly created DOI error codes section, but doesn't change value. So, after some thought, I swapped the bits around: 3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size !R|A|F| Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RAF 0b000xxxxxxxxxxxxx 0-8191 - ISAKMP error codes 0b001xxxxxxxxxxxxx 8192-16383 - DOI error codes 0b010xxxxxxxxxxxxx 16384-24575 - ISAKMP status codes 0b011xxxxxxxxxxxxx 24576-32767 - DOI status codes 0b100xxxxxxxxxxxxx 32768-40959 - private use ISAKMP error codes 0b101xxxxxxxxxxxxx 40960-49151 - private use DOI error codes 0b110xxxxxxxxxxxxx 49152-57343 - private use ISAKMP status codes 0b111xxxxxxxxxxxxx 57344-65535 - private use DOI status codes I think that this maintains all the current numbers, moving only the private use values around. Can someone verify my belief? Thus, no bits on the wire change unless someone has already started to use some of the private use error codes. This now tells me what to do with notify types that I don't understand. Status codes one can ignore, errors cause the negotiation to fail. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNP475x4XQavxnHg9AQFXwQH/THjgn5FnAZwT5OvzqHntlZAjqQbgPWw+ 1zdji3NPnz3FCF3qWliAs3Cr4c8+fDDLnx2HAqnElBUg3B829x3y9Q== =2BsN -----END PGP SIGNATURE----- From owner-ipsec Thu Mar 5 02:06:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA20036 for ipsec-outgoing; Thu, 5 Mar 1998 02:04:02 -0500 (EST) Message-Id: <199803050558.AAA12821@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: my minutes from the end client tunnel config discussion Date: Thu, 05 Mar 1998 00:58:45 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [please post your own view] Pertinent issues that are important to get working road warrior/gateway tunnels: 1. end client has no permanent IP address. The ID payload will therefore be FQDN or user@FQDN. 2. due to #1, and the fact that the ID payload is not sent until the third exchange, a road warrior can not use pre-shared-keys for ISAKMP using main mode. The right pre-shared-key can not be selected. Section 5.4 of isakmp-oakley-06.txt mentions this. Agressive mode can be used, but obviously, it does not provide identity protection. 3. a way is needed to configure the road warrior's inner tunnel address. Roy Pereira's isakmp-mode-cfg is an initial attempt. 4. we need some textual information in the nofity messages. MCR will be writing a document. 5. the bootstrap problem was declared out of scope for IPsecond. 6. we need to define *exactly* what goes into certificates used on road warrior nodes. Rodney has a document in preperation that addresses this for both end node and gateways. 7. we discussed whether or not policy configuration should be in scope for IPsecond. ] IPsec testing workshop #5, Raleigh, NC. I love airports | 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 iQBVAwUBNP4/Ch4XQavxnHg9AQHiRAH9Erme7GDeRnO49eAL/hrvmnpEGYyPORJE iNBRpCaynmsQsYKlH6/qyBrx/oW7YT2eAtgJltO8VImaljyF0IY8uA== =YaDy -----END PGP SIGNATURE----- From owner-ipsec Thu Mar 5 07:13:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22117 for ipsec-outgoing; Thu, 5 Mar 1998 07:12:03 -0500 (EST) Message-Id: <199803051226.HAA07188@relay.rv.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Thu, 5 Mar 1998 12:23:24 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: IPsec DOI v7 - comment CC: ddp@network-alchemy.com X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 4.4.1 of ipsec-doi-v7 states :- The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. It is a host policy decision as to what protocol suites might be negotiated together. The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI. Protocol ID Value RESERVED 0 PROTO-ISAKMP 1 PROTO-IPSEC-AH 2 PROTO-IPSEC-ESP 3 PROTO-IPCOMP 4 Q. When is it possible to negotiate a PROTO-ISAKMP SA AND PROTO-IPSEC-* SA "at the same time" Is it not the case that : PROTO-ISAKMP is negotiated in phase 1 ONLY and PROTO-IPSEC-* negotiated in phase 2 ONLY - Elfed **************************************************** "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 Thu Mar 5 09:01:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23043 for ipsec-outgoing; Thu, 5 Mar 1998 08:59:04 -0500 (EST) Message-Id: <199803051425.GAA28762@relay.la.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Thu, 5 Mar 1998 14:10:54 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ISAKMP Cert Req Processing CC: wdm@epoch.ncsc.mil X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk In section 5.8 of ISAKMP v8 When Cert Req payload is received ...... 2. Determine if the Certificate types are supported. If ANY of the certificate types are not supported, the message is discarded and the following actions taken ........ Q. This (IMHO) implies that an entity must support all certificate types is this the case ? - Elfed **************************************************** "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 Thu Mar 5 09:57:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23490 for ipsec-outgoing; Thu, 5 Mar 1998 09:57:06 -0500 (EST) Message-Id: <199803051511.KAA15708@relay.rv.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: wdm@epoch.ncsc.mil (W. Douglas Maughan) Date: Thu, 5 Mar 1998 15:09:33 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Certificate Requesting CC: ipsec@tis.com In-reply-to: <9802241154.AA00793@dolphin.ncsc.mil> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk There appears to be plenty of opportunity for a responder (even more for the initiator) to send a Cert Req in both the Identity Protect Exchange and in the Aggressive Exchange to support the timely exchange of Certs. As for extending an Exchange (?) is there any real need :- Generally Phase1 will be followed directly by a Phase 2, the first phase 2 message effectively completeing the Phase 1 exchange - no need for a notify i.e. to extend the exchange. In the case where a Phase 1 ISAKMP-SA is about to expire and the entities wish to maintain a secure ISAKMP channel between them - but do not intend to establish a security protocol SA immediately - then would it not be more efficient to establish an ISAKMP-SA under the protection of the existing one. If done this way no certificates have to be exchanged, PFS would not be a problem since new DH values would still be exchanged as defined. As for the Quick Mode exchange, the initiator (if it wishes) has enough opportunity to request and receive a Cert. The Responder on the otherhand only has the opportunity to request and receive the Cert but not to acknowledge that it accepted the Cert and the SA has been established. I dont see this as a problem for Host implementations - they have ID'd and Auth'd themselves in Phase1. However, if proxying different Certs will need to be exchanged. If the responder Cert processing fails the Responder should trash the SA, then either send no notify or notify the proxying agent (under the protection of the ISAKMP-SA) that a phase 2 SA with Message ID = x failed. No need to extend the Exchange here either. It seems a simple modification of text, as suggested by wdm below, is adequate when combined with some text stating that exchanges MUST not be extended under any circumstances. > Date: Tue, 24 Feb 98 06:54:15 EST > From: wdm@epoch.ncsc.mil (W. Douglas Maughan) > To: rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, > tytso@MIT.EDU, kivinen@ssh.fi > Subject: RE: Certificate Requesting > Cc: ipsec@tis.com, wdm@epoch.ncsc.mil > All, > > Let me try to clear up the whole issue surrounding ISAKMP and > Certificate Requesting. > > It was initially added for the purpose the text in section 3.10 > states: > > "Certificate Request payloads SHOULD be included in an exchange > whenever an appropriate directory service (e.g. Secure DNS > [DNSSEC]) is not available to distribute certificates" > > It's inclusion was a "poor man's" certificate retrieval approach (to be > used until such time as directories, etc. were available). It was never > meant to be a "fully functional" certificate management component. > > However, the text in section 3.10 is unclear. Ted was correct in his > interpretation of the text and effectively a CertReq payload could be > sent by the responder in the last message of the exchange, thus, > extending the exchange. It was NEVER intended to be used in this > manner. Tero has captured the problem with the "never-ending" > certificate request message exchanges example. > > As stated previously, the initial intent was to have the CertReq > payload within the context of the given exchanges (not including the > last message from the responder). The reason, from a security > standpoint, is captured by Dan in his message below. That having been > said, I'm willing to: > > (a) write clarifying text to make sure there is no misunderstanding > about when a CertReq payload is included in the exchange (i.e. anytime > before the last message from the responder). NOTE: This is my > preference and we can state that a Key Exchange (IKE, et. al.) can > extend the exchange model if they so desire. > > OR > > (b) change to the text to include the capability to continually extend > the exchange (which I don't really like). > > OR > > (c) something different. > > What say ye?? > > Doug > > > > > > Roy Pereira writes: > > > The additional exchange scenario that you do not agree with only happens > > > if the initiator does not send a certificate and the responder does not > > > have it. The responder will then append a CertReq payload to the ISAKMP > > > message. If the initiator receives the CertReq in the sixth message of > > > MainMode (RSA_SIG), then he must reply back with his certificate in a > > > MainMode message. He may also append a CertReq to that message if the > > > responder did not include a certificate in the sixth message and he does > > > not have it. This would force the responder to reply back with his > > > certificate. > > > > Tero Kivinen writes: > > And if responder again includes certificate request (it can, there is > > no limitation that there must be only one of certificate request) the > > initiator must again reply to it and so on. Is there any limit for > > this? > > > > I can see that someone might want to use this kind of system when they > > don't want the other end even to know what CA's they need. They could > > first ask can you provide certificate for this CA, and if so they know > > OK, now it is ok to ask next level of CA etc. > > > > I really don't like the exchange to be extended this way. I would > > really like to explicitly say that certificate requests are only > > allowed if the other end is going to reply this message anyway. You > > can also expand the exchange from normal six or three messages if you > > set commit bit. > > > > > This scenario was brought forth by a rather large software corporation > > > since this is what they do in their IPSec implementation. > > > > Is there really any real use for this? It makes the state machine even > > more complicated than it is now, and the there are quite a lot of > > different stuff there already given all the different authentications, > > aggressive/main mode, commit bit etc. > > > > > > Dan Harkins writes: > > Perhaps I'm missing something here but you're asking for the cert's > > too late. You need them to verify the signature but you're not asking > > for them until you've already, presumably, authenticated your security > > association by checking the peer's signature. > > > > >> Initiator Responder > > >> ---------- ----------- > > >> HDR, SA --> > > >> <-- HDR, SA > > >> HDR, KE, Ni --> > > >> <-- HDR, KE, Nr > > >> HDR*, IDii, [ CERT, ] SIG_I --> > > >> <-- HDR*, IDir, [ CERT, ] SIG_R[, > > >>CERTREQ > > >> [ HDR*, CERT [, CERTREQ] --> > > >> [<-- HDR*, CERT ] ] ] > > >> > > > > If the Initiator didn't send his cert in his 3rd message then the > > responder wouldn't be able to verify his signature and would abort > > the communication. Why not send a CERTREQ in the 2nd messages. That > > way you're still keeping a modicum of identity protection (sending it > > in the 1st messages requires the other party to respond with his cert > > in the clear). > > > > At the point you're sending the KE and nonce payloads you know what your > > authentication method is. If it's signature based and you don't have a > > cert for the peer (granted it's tough to know if you do since all you have > > to go on at that point is IP address and not everyone will be encoding an > > IP address in their certs) send the CERTREQ then. > > > > Why the need for the extra round trip? And the suspension of authentication > > and retention of state? Am I missing something here? > > > > > > > Greg Carter writes: > > >---------- > > >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] > > >Sent: Monday, February 23, 1998 12:51 PM > > >To: Greg Carter > > >Cc: 'Theodore Y. Ts'o'; 'IPSEC Mailing List'; 'Dan Harkins'; 'RoyPereira' > > >Subject: Re: Certificate Requesting > > > > > > From: Greg Carter > > > Date: Sun, 22 Feb 1998 14:51:49 -0500 > > > > > > I would not interpret this to mean that I can arbitrarily extend the > > > exchange. There is plenty of opportunity to send the cert request during > > > the defined exchange. > > > > > >The text I quoted is from the ISAKMP document; within the context of > > >ISAKMP, there can be an arbitrary number of round-trips. IKE rides on > > > > Hi Ted, > > Can you point me to where in ISAKMP that it states arbitrary number of > > round trips are allowed? All I could find was text to the contrary. > > > > >From Section 2.1 > > > > Exchange Type - An exchange type is a specification of the number of > > messages in an ISAKMP exchange, and the payload types that are contained > > in each of those messages. > > > > What's the purpose of specifying the number of messages in an exchange > > if the number can be arbitrarily modified? > > **************************************************** "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 Thu Mar 5 10:18:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23623 for ipsec-outgoing; Thu, 5 Mar 1998 10:17:07 -0500 (EST) Message-ID: <34FEC444.C805AA2A@tiac.net> Date: Thu, 05 Mar 1998 10:27:00 -0500 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: VPN tunnel management bof 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 was wondering whether there will be a VPN tunnel management BOF at the March IETF meeting? I remember this notion being discussed earlier but I wasn't sure whether this will actually transpire. Also, does anyone know the agenda for the IPSec working group at the IETF meeting? Thank you in advance for your response sincerely Michael Giniger Assured Digital, Inc. From owner-ipsec Thu Mar 5 10:38:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23797 for ipsec-outgoing; Thu, 5 Mar 1998 10:38:07 -0500 (EST) From: Kai Martius Organization: Uniklinik TUD To: ipsec Date: Thu, 5 Mar 1998 16:39:51 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: I-D: Extended Key exchange protocol Reply-to: kai@imib.med.tu-dresden.de X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <22F7A41476D@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I have written a draft on an "Extended Key Exchange Protocol" in a very first version. In short, it describes an extended protocol (E-IKE) based on IKE which allows involving more than two parties in the authentication process and key exchange. It supports extended SA management / ~ establishment by applying security policies of the involved parties during the protocol (I've appended the TOC for a short overview) Feel free to get a copy from http://www.imib.med.tu-dresden.de/imib/Internet/index.html I would appreciate discussion on this with interested people. (I'll be in L.A., so also a -hopefully positive ;-)- personal communication will be possible...) Thanks, Kai ***** Table of Contents 1. ABSTRACT 2 2. DISCUSSION 2 3. TERMS AND DEFINITIONS 3 4. THE PROTOCOL 4 4.1 DESIGN OBJECTIVES 4 4.2 INITIAL MESSAGE ROUTING 4 4.3 PROTOCOL USING COMPLETE IKE EXCHANGES 5 4.4 PROTOCOL USING A IKE-SECURED CHANNEL 6 4.5 MESSAGE FORMAT 7 4.5.1 Message Blocks / Message Matrixes 7 4.5.2 Authentication fields / Authentication Methods 8 4.6 MESSAGE FLOW 10 4.7 MESSAGE MATRIX 15 4.8 RESTRICTIONS 16 4.9 KEY GENERATION 17 4.10 COMPARISON 17 5. LOCAL SA MANAGEMENT 19 5.1 SA BUNDLING 19 5.2 ASYMMETRIC SAS 20 6. SECURITY POLICY MANAGEMENT ON GATEWAYS AND END NODES 20 7 SECURITY CONSIDERATIONS 22 APPENDIX A.1 - SYMBOLIC FUNCTIONS USED 22 APPENDIX A.2 - FIRST PROTOCOL APPROACH 24 APPENDIX A.3 - SECOND APPROACH 26 APPENDIX B - EXAMPLES 38 B.1 REMOTE ACCESS 38 B.2 VPN # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # available at http://www.imib.med.tu-dresden.de/imib/personal/kai.html # # # # See our project (and me) at CeBit'98 fair Hannover/Germany 19-25.3.98 # # Infos: http://www.inf.tu-dresden.de/~hf2/cebit98 # From owner-ipsec Thu Mar 5 11:21:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24260 for ipsec-outgoing; Thu, 5 Mar 1998 11:19:11 -0500 (EST) Message-Id: <199803051629.LAA10841@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Thu, 5 Mar 1998 16:30:16 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ISAKMP - Vendor ID Payload CC: wdm@epoch.ncsc.mil X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk Is this extension to ISAKMP really necessary. It sounds to me that what it is meant to achieve can be achieved by defining a vendor specific DOI - based primarily on the Internet DOI. Having a DOI ID in, SA Payload, Notification Payload and the Delete Payload should support use of a different DOI in Phase 2 even if Phase 1 was established using the Internet DOI. Adding extra payloads at this stage in the standardisation process is only opening us up to additional delays - you can bet your bottom dollar that once you get it in the draft someone will want to change something ! If it can be worked around using another DOI ID then do that, please (personally I'm getting quite fed-up with having to read endless documents that only have minor (non-critical) tweaks in them since the last version) - Elfed **************************************************** "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 Thu Mar 5 12:00:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24687 for ipsec-outgoing; Thu, 5 Mar 1998 11:58:09 -0500 (EST) Message-Id: <199803051712.MAA27860@relay.rv.tis.com> To: Michael Richardson cc: ipsec@tis.com, wdm@tycho.ncsc.mil Subject: Re: Notify message types In-reply-to: Your message of "Thu, 05 Mar 1998 00:45:19 EST." <199803050545.AAA10925@morden.sandelman.ottawa.on.ca> Date: Thu, 05 Mar 1998 09:11:28 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >1. why does the notify message space define a DOI specified status >types, but no DOI specified error types? My interpretation of the ISAKMP draft is that 8192 was the start of the DOI-specific error range. >2. ipsec-doi-07.txt reserves one of the private use >numbers (8192) as being "RESERVED"... why? Is it historical? I just plopped in RESERVED to denote the start of the error range. There's no reason for it. I like your proposal. Derrell From owner-ipsec Thu Mar 5 12:02:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24740 for ipsec-outgoing; Thu, 5 Mar 1998 12:02:08 -0500 (EST) Message-Id: <199803051712.MAA13179@relay.hq.tis.com> To: "Elfed T. Weaver" cc: ipsec@tis.com Subject: Re: IPsec DOI v7 - comment In-reply-to: Your message of "Thu, 05 Mar 1998 12:23:24 GMT." Date: Thu, 05 Mar 1998 09:14:32 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Q. When is it possible to negotiate a PROTO-ISAKMP SA AND >PROTO-IPSEC-* SA "at the same time" It's not, I'll fix the text. Of course it's trying to state that multiple protocols can be negotiated simultaneously in Phase 2. Thanks! Derrell From owner-ipsec Thu Mar 5 12:44:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25189 for ipsec-outgoing; Thu, 5 Mar 1998 12:43:07 -0500 (EST) Message-ID: <34FEE11B.5A8B1172@BayNetworks.com> Date: Thu, 05 Mar 1998 12:30:03 -0500 From: Shawn Mamros X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Paul Koning CC: ipsec@tis.com Subject: Re: Quick Mode client IDs X-Priority: 3 (Normal) References: <199803031743.MAA04697@portal.ex.tis.com> <9803032014.AA02055@kona.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I originally wrote: >> The identities of the SAs negotiated in Quick Mode are >> implicitly assumed to be the IP addresses of the ISAKMP peers, >> without any implied constraints on the protocol or port >> numbers allowed, unless client identifiers are specified in >> Quick Mode. If ISAKMP is acting as a client negotiator on >> behalf of another party, the identities of the parties MUST be >> passed as IDci and then IDcr. Local policy will dictate >> whether the proposals are acceptable for the identities >> specified. If the client identities are not acceptable to the >> Quick Mode responder (due to policy or other reasons), a >> Notify payload with Notify Message Type INVALID-ID-INFORMATION >> (18), followed by an acceptable pair of client identifiers, in >> two ID payloads (IDci followed by IDcr) SHOULD be sent. and then Paul Koning replied: > That sounds right -- except that I'm not sure about the last sentence. That last sentence was written as a replacement for what's currently the last sentence in the fourth paragraph of section 5.5 of the IKE draft, which reads: [...] If an ID range (see Appendix A of [Pip97]) is not acceptable (for example, the specified subnet is too large) a INVALID-ID-INFORMATION notify message (18) followed by an acceptible ID range, in an ID payload, SHOULD be sent. This sentence has a number of problems - for starters, there is no longer an Appendix A in the DOI draft (which is what [Pip97] refers to). Second, because there are two client ID payloads sent in Quick Mode, it would be difficult to determine whether the one being sent back corresponds to IDci or IDcr. My intention was to try and replace this sentence with one that would, ideally, satisfy the intent of the original but state it in a way that (hopefully) made more sense. I did show it to some folks for review before I sent it out; they had no objections. If someone would like to propose alternate text, or thinks the whole notion of providing a "hint" as to what is acceptable back to the Quick Mode initiator should be removed altogether, that's fine by me... Any opinions (esp. from the draft authors) on what should be done here? -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Thu Mar 5 13:54:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25926 for ipsec-outgoing; Thu, 5 Mar 1998 13:53:14 -0500 (EST) Date: Thu, 5 Mar 1998 14:07:08 -0500 Message-Id: <199803051907.OAA20538@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: wdm@epoch.ncsc.mil, ipsec@tis.com In-Reply-To: Elfed T. Weaver's message of Thu, 5 Mar 1998 15:09:33 +0000, <199803051511.KAA15708@relay.rv.tis.com> Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I had a telephone conversation with Dan Harkins Monday night while he was at the interoperabilty conference, and it appears that most implementations do assume that IKE takes exactly three round trips, and the strategy for handling failures such as not having right certificates is to abort the IKE exchange and retry using knowledge gained from the previous exchange to do the right thing (such as, sending the CERTREQ this time around.) Accordingly, Dan was going to modify the IKE spec to remove this point of ambiguity by stating that within the IKE DOI, implementations are not allowed to send a CERTREQ if doing so would extend the number of messages beyond the six specified by the IKE. If either side doesn't have a certificate, they can send a notify message and abort the exchange. If we assume this strategy, the only thing we are missing is to have the ISAKMP spec define a notify message which is "MISSING CERTIFICATE", with the data field having the same information as is contained in the CERTREQ message. Notify messages are optional to implement, so implementations wouldn't have to do this; however, smart implementations would be able note this information and then send the appropriate certificate when they retry the IKE negotiation. Doug, is this something you can add to the ISAKMP draft? I believe this approach is one for which we can achieve rough consensus. Remember, at this stage of the game the important thing is that we choose *one* way of doing things, so that we interoperate, and then document it so we can get the specs nailed down and done. Just as a reminder, the internet drafts deadline is March 13 at 1700 EST. Due to the last-minute rush nature of things, we should aim to get things done by, say, the Wednesday the 11th, so that we have some room for slop. - Ted From owner-ipsec Thu Mar 5 20:33:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA28513 for ipsec-outgoing; Thu, 5 Mar 1998 20:31:18 -0500 (EST) From: Will Fiveash Message-Id: <199803060143.TAA37364@vulcan.austin.ibm.com> Subject: Question about SAs and draft-ietf-ipsec-isakmp-oakley-06 To: ipsec@tis.com (IETF IPSEC) Date: Thu, 5 Mar 1998 19:43:59 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Can someone clear up some confusion I have? In the draft-ietf-ipsec-isakmp-oakley-06.txt (section 5.5) I see: "A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA." In draft-ietf-ipsec-arch-sec-03.txt (section 4.1) I see: "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." Now a single ISAKMP Phase 2 SA negotiation can contain a proposal that specifies both AH and ESP protocols. So shouldn't a single Phase 2 SA negotiation result in four SAs (SA-AH-In, SA-AH-Out, SA-ESP-In, SA-ESP-Out) not two as stated in draft-ietf-ipsec-isakmp-oakley-06.txt? -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Fri Mar 6 03:09:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00985 for ipsec-outgoing; Fri, 6 Mar 1998 03:05:12 -0500 (EST) From: "Alexei V. Vopilov" To: "Will Fiveash" , "IETF IPSEC" Subject: Re: Question about SAs and draft-ietf-ipsec-isakmp-oakley-06 Date: Fri, 6 Mar 1998 11:17:03 +0300 Message-ID: <01bd48d8$3e7f2e20$d5253ac3@ppalx> 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 : :Now a single ISAKMP Phase 2 SA negotiation can contain a proposal that :specifies both AH and ESP protocols. So shouldn't a single Phase 2 SA :negotiation result in four SAs (SA-AH-In, SA-AH-Out, SA-ESP-In, SA-ESP-Out) :not two as stated in draft-ietf-ipsec-isakmp-oakley-06.txt? Ipsec arch document just states that _logically_ one SA corresponds to exactly one IPsec protocol (ESP or AH) and exactly one SPI value being choosen by the traffic receiver. ISAKMP documents states that (due to the protocol design and it SA payload format) single phase 2 SA negotiation results, at minimum, to two SAs - one inbound and one outbound. However, if a proposal includes both ESP and AH protocols, then each would require separate SA and _due to_ ISAKMP design both inbound and outbound SAs will be negotiated at the same time. Each will have own SPI! (ESP+AH)*(inbound+outbout)=(1+1)*(1+)=4 ;-))) I understand you confusion, because during ISKAMP design time the was an attepmt to minimize the computation overhead required for establishment of bi-directional secured channel, which is most common in the current internetworking. The ISKAMP authors just, IMO,unreasonably excluded a possibility to negotiate exactly one _unidirectional_ SA. That would lead to problems later when implementing, say, different policies for inbound and out bound traffic. : :-- :Will Fiveash :IBM AIX System Development Internet: will@austin.ibm.com :11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet :Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 : --Alexei From owner-ipsec Fri Mar 6 05:24:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA01719 for ipsec-outgoing; Fri, 6 Mar 1998 05:21:12 -0500 (EST) Message-Id: <199803061048.CAA18000@relay.la.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Fri, 6 Mar 1998 10:31:22 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Vendor ID Paylod X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk > >>>>> "Elfed" == Elfed T Weaver writes: > Elfed> Is this extension to ISAKMP really necessary. It sounds to > Elfed> me that what it is meant to achieve can be achieved by > Elfed> defining a vendor specific DOI - based primarily on the > Elfed> Internet DOI. > > If I offer a new DOI, and the other end doesn't like it, what do I > do? How I register the new DOI number? How do I find out what bugs in > my previous versions I need to work around? > If its Vendor specific then I assume the vendor will load images into their kit that support the functionality they wish to test ? Bug reports, if Doug Maughan had suggested that we support such flexibility in ISAKMP 2 years ago the ipsec WG would have erupted with hoots of SPOOK ! ;-) ;-) - Elfed **************************************************** "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 Mar 6 15:14:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05905 for ipsec-outgoing; Fri, 6 Mar 1998 15:10:20 -0500 (EST) Message-Id: <199803062023.PAA15057@tecumseh.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Mar 1998 15:19:27 -0500 To: ipsec@tis.com From: Matt Thomas Subject: Revised Pre-Shared and Public Key Sig modes?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The Main Mode exchanges for Pre-Shared keys (HASH_x) or Public Key Signatures (SIG_x) are: Initiator Responder HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [HASH_I | SIG_I] --> <-- HDR*, IDir, [HASH_R | SIG_R] Is there any reason why 1/2 a round trip could be not eliminated by having Revised versions of these modes such that): HDR, SA --> <-- HDR, SA, KE, Nr HDR, KE, Ni --> <-- HDR*, IDir, [HASH_R | SIG_R] HDR*, IDii, [HASH_I | SIG_I] --> Since the responder has selected a single proposal, he knows what Diffie-Hellman group is being used so he can generate the correct Diffie-Hellman payload and it does cut out 1/2 a round trip. I'll write up a draft add these as new authentication methods unless someone convinces me this would be a bad idea. -- Matt Thomas Internet: matt@ljo.dec.com AltaVista Internet Software WWW URL: Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Fri Mar 6 15:33:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06103 for ipsec-outgoing; Fri, 6 Mar 1998 15:33:16 -0500 (EST) From: Will Fiveash Message-Id: <199803062045.OAA31438@vulcan.austin.ibm.com> Subject: Re: Question about SAs and draft-ietf-ipsec-isakmp-oakley-06 In-Reply-To: <01bd48d8$3e7f2e20$d5253ac3@ppalx> from "Alexei V. Vopilov" at "Mar 6, 98 11:17:03 am" To: alx@elnet.msk.ru (Alexei V. Vopilov) Date: Fri, 6 Mar 1998 14:45:58 -0600 (CST) Cc: will@austin.ibm.com, ipsec@tis.com X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'll stop beating this horse after this but I just want to be clear. the Quick Mode exchange is as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> Is the SA above considered a single SA negotiation as specified in the following sentence?: A single SA negotiation results in two security assocations-- one inbound and one outbound. Or does the SA payload contain multiple SA negotiations (one for AH and another for ESP)? Or do I have to use (note the seperate SA payloads): Initiator Responder ----------- ----------- HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> to negotiate and create a IPSec tunnel that uses AH and ESP? If a single SA payload can only negotiate for one protocol then this needs to be clearly stated in the isakmp-oakley draft. Alexei V. Vopilov wrote: > : > :Now a single ISAKMP Phase 2 SA negotiation can contain a proposal that > :specifies both AH and ESP protocols. So shouldn't a single Phase 2 SA > :negotiation result in four SAs (SA-AH-In, SA-AH-Out, SA-ESP-In, SA-ESP-Out) > :not two as stated in draft-ietf-ipsec-isakmp-oakley-06.txt? > > > Ipsec arch document just states that _logically_ one SA corresponds to > exactly one IPsec protocol (ESP or AH) and exactly one SPI value being > choosen by the traffic receiver. > > ISAKMP documents states that (due to the protocol design and it SA payload > format) > single phase 2 SA negotiation results, at minimum, to two SAs - one inbound and > one outbound. However, if a proposal includes both ESP and AH protocols, > then each would require separate SA and _due to_ ISAKMP design both inbound > and outbound SAs will be negotiated at the same time. Each will have own SPI! > (ESP+AH)*(inbound+outbout)=(1+1)*(1+)=4 ;-))) Does this mean SA0, SA1 payloads need to be created individually and can only contain 1 protocol in their respective proposals? > I understand you confusion, because during ISKAMP design time > the was an attepmt to minimize the computation overhead required for > establishment of bi-directional secured channel, which is most common > in the current internetworking. > > The ISKAMP authors just, IMO,unreasonably excluded a possibility to negotiate > exactly one _unidirectional_ SA. That would lead to problems later when > implementing, say, different policies for inbound and out bound traffic. > > :-- > :Will Fiveash > > --Alexei -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Fri Mar 6 15:57:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06261 for ipsec-outgoing; Fri, 6 Mar 1998 15:57:18 -0500 (EST) Message-Id: <199803062109.QAA01110@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Proposal to formalize the Notification Data field Date: Fri, 06 Mar 1998 16:09:56 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Many discussions this week in NC, and two weeks ago in Boston revealed that many want more information in the notification messages. Specificially, which payload failed, and where the problem is (in the case of bad protocols or transforms within an SA payload). At meeting on Tuesday (for which I posted some notes) I volunteered to write some text. I have sent it to a couple of people, and gotten some oral and email feedback. Here is it for everyone to mull over. Although this changes bits on the wire, it changes bits that were up to this point undefined, and compliant implementations should have been ignoring if they failed to understand it. I am undecided if, given my proposals to identify some bits in the Notification Type if we need rfc821 style result codes or not as well. I have included them here. I have not made any attempt to define them better. I am not attached to them, but was discussed on Tuesday. As Ted points out, we need to add an additional Notify. I had called it REQUESTED-CERT-UNAVAILABLE. Ted called it something else. With ISAKMP-09 (expected today, right Doug?), cert request payloads contain only a single request. If multiple certs are desired, or permitted, then multiple payloads can be included. If no cert of the desired type is available, a notify with REQUESTED-CERT-UNAVAILABLE is returned (rather than silence as before), and the cert request is included to inform the sender which cert was unavailable. The severity field would indicate permanent (e.g. doesn't exist) or temporary (e.g. LDAP server down). ipsec-doi-07 changes: 4.6.3 IPSEC Notify Message Types ISAKMP defines eight blocks of Notify Message codes with sections for errors and status codes. ISAKMP reserves two blocks for itself, four blocks for private use, and asks the DOI to define error and a status blocks. Notify Messages - Error Types Value ----------------------------- ----- RESERVED 8192 Notify Messages - Status Types Value ------------------------------ ----- RESPONDER-LIFETIME 24576 REPLAY-STATUS 24577 INITIAL-CONTACT 24578 REQUESTED-CERT-UNAVAILABLE 24579 Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in any Quick Mode exchange. These messages MUST NOT be sent in Aggressive Mode exchanges unless the authentication mode is RSA Encryption, since Aggressive Mode does not otherwise provide the necessary protection to bind the Notify Status Message to the exchange. Implementation Note: the ISAKMP protocol does not guarantee delivery of Notification Status messages when sent in an ISAKMP Informational Exchange. To ensure receipt of any particular message, the sender SHOULD include a Notification Payload in a defined Main Mode, Quick Mode, or Aggressive exchange which is protected by a retransmission timer. ISAKMP also defines a notification data area for the DOI to define. The IPsec DOI defines the following structure to contain it results. Note: this structure is used for both ISAKMP defined notify types and for IPSEC DOI defined notify types when the notify message payload indicates the IPSEC DOI. 3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! bad-prot-id ! RESERVED ! faulty payload length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! RESERVED ! offset of fault ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ payload at fault ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! severity code! module code ! error num ! ascii space ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ error text ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o bad-prot-id (1 octet) - Identifier for the payload type of the payload that was at fault. This is a payload type as defined in section 3.1 of [ISAKMP] for the following messages: INVALID-PAYLOAD-TYPE PAYLOAD-MALFORMED INVALID-KEY-INFORMATION INVALID-ID-INFORMATION INVALID-CERT-ENCODING INVALID-CERTIFICATE BAD-CERT-REQUEST-SYNTAX INVALID-CERT-AUTHORITY INVALID-HASH-INFORMATION INVALID-TRANSFORM-ID INVALID-PROTOCOL-ID DOI-NOT-SUPPORTED SITUATION-NOT-SUPPORTED INVALID-SIGNATURE INVALID-SPI No payload should be included for the following notify types. The payload length should be zero, and the bad-prot-id should be zero. INVALID-COOKIE INVALID-MAJOR-VERSION INVALID-MINOR-VERSION INVALID-EXCHANGE-TYPE INVALID-FLAGS INVALID-MESSAGE-ID INVALID-PROTOCOL-ID INITIAL-CONTACT The following messages have not yet been categorized. AUTHENTICATION-FAILED ADDRESS-NOTIFICATION ATTRIBUTES-NOT-SUPPORTED NO-PROPOSAL-CHOSEN BAD-PROPOSAL-SYNTAX The following messages have notification data which is defined elsewhere in this document: RESPONDER-LIFETIME REPLAY-STATUS o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the included faulty payload, including the faulty payloads' generic payload header, the bad-prot-id, RESERVED, this field, and the fault offset. o Fault offset (2 octets) - offset from the beginning of the payload at which the fault was found. o faulty payload (variable number of octets) - a copy of the payload which caused the notify to be sent. The payload MAY be truncated after the section pointed to by the fault offset. This is useful when large payloads have faults near the beginning, but the payload is large. An implementation MUST send at least 8 bytes past the fault offset, and SHOULD send the entire faulty payload, truncating only at the next generic header (e.g next transform in a SA proposal) o severity code (1 octets) - an integer encoded as a single ascii value. See RFC821, appendix E. "1" Positive Preliminary reply "2" Positive Completion reply "3" Positive Intermediate reply "4" Transient Negative Completion reply "5" Permanent Negative Completion reply o module code - identifies which subsystem is involved (to be defined!) o error code - number. o space - The ASCII space value, integer 32. o error text - a human readable message, encoded in UTF8. One "line" of text only. Suggested limit is 77 glyphs. ] At cottage, to clean up trees broken by ice: things okay tho | 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 iQBVAwUBNQBmIR4XQavxnHg9AQHWIQH/az/kCRe3a2+wdl9FQ7gvPNRoGgfXoLdH ME1vu3tWgaNDmVGzQTZUP6ETxGYojFDov6IudPJ7D9k1psxuB87iqg== =+7E0 -----END PGP SIGNATURE----- From owner-ipsec Fri Mar 6 17:31:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA06838 for ipsec-outgoing; Fri, 6 Mar 1998 17:29:19 -0500 (EST) From: pau@watson.ibm.com Date: Fri, 6 Mar 1998 17:39:42 -0500 Message-Id: <9803062239.AA22620@secpwr.watson.ibm.com> To: matt@ljo.dec.com Subject: Re: Revised Pre-Shared and Public Key Sig modes?? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: ab7DxCakKXi5NtcDbIFXaQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > The Main Mode exchanges for Pre-Shared keys (HASH_x) or Public Key > Signatures (SIG_x) are: Matt, IMHO : I have not considered if the proposed xchg has any security holes. But I think it has one drawback : It breaks the ISAKMP framework by introduce yet another new exchange types and saves only one msg. I am not sure if it is worthwhile at this stage of standarization. Pau-Chen > Initiator Responder > > HDR, SA --> > <-- HDR, SA > HDR, KE, Ni --> > <-- HDR, KE, Nr > HDR*, IDii, [HASH_I | SIG_I] --> > <-- HDR*, IDir, [HASH_R | SIG_R] > > Is there any reason why 1/2 a round trip could be not eliminated by > having Revised versions of these modes such that): > > HDR, SA --> > <-- HDR, SA, KE, Nr > HDR, KE, Ni --> > <-- HDR*, IDir, [HASH_R | SIG_R] > HDR*, IDii, [HASH_I | SIG_I] --> > > Since the responder has selected a single proposal, he knows what > Diffie-Hellman group is being used so he can generate the correct > Diffie-Hellman payload and it does cut out 1/2 a round trip. > > I'll write up a draft add these as new authentication methods > unless someone convinces me this would be a bad idea. > -- > Matt Thomas Internet: matt@ljo.dec.com > AltaVista Internet Software WWW URL: > Digital Equipment Corporation Disclaimer: This message reflects my own > Littleton, MA warped views, etc. > From owner-ipsec Fri Mar 6 17:45:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA06960 for ipsec-outgoing; Fri, 6 Mar 1998 17:44:21 -0500 (EST) From: "Alexei V. Vopilov" To: "Will Fiveash" Cc: , Subject: Re: Question about SAs and draft-ietf-ipsec-isakmp-oakley-06 Date: Sat, 7 Mar 1998 01:57:00 +0300 Message-ID: <01bd4953$2c0b6760$95883ac0@alx-home> 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 [. . . ] :Is the SA above considered a single SA negotiation as specified in the :following sentence?: : : A single SA negotiation results in two security assocations-- one : inbound and one outbound. At least two, depending on 'Proposal' payloads contents. If two proposals with the same number exist, then more SAs would be negotiated. :Or does the SA payload contain multiple SA negotiations (one for AH and :another for ESP)? SA payload is followed by proposal payload(s), the latests are responsible for actual SAs creation, since carry reservation for SPI values. :Or do I have to use (note the seperate SA payloads): : : Initiator Responder : ----------- ----------- : HDR*, HASH(1), SA0, SA1, Ni, : [, KE ] [, IDci, IDcr ] --> : <-- HDR*, HASH(2), SA0, SA1, Nr, : [, KE ] [, IDci, IDcr ] : HDR*, HASH(3) --> : :to negotiate and create a IPSec tunnel that uses AH and ESP? OOPS, the above case corresponds to whatever called a SA bundle. SA bundle is used for negotiating SAs overlapped by lifetime. Thus when SA0 get expired, SA1 is ready to be used without additional negotiations. :If a single :SA payload can only negotiate for one protocol then this needs to be :clearly stated in the isakmp-oakley draft. For example, one can send proposal of form (ESP and AH) or (AH) or (ESP). So a question to you: how many SAs would be finally negotiated, having in mind that responder has to answer only with one of above proposals being enclosed in brackets. ? ;-) [. . .] --Alexei From owner-ipsec Fri Mar 6 23:07:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA08887 for ipsec-outgoing; Fri, 6 Mar 1998 23:03:22 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: RE: Certificate Requesting Date: Fri, 6 Mar 1998 23:13:53 -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 Sounds good to me. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com >---------- >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] >Sent: Thursday, March 05, 1998 2:07 PM >To: wdm@epoch.ncsc.mil; ipsec@tis.com >Subject: Re: Certificate Requesting > > >Accordingly, Dan was going to modify the IKE spec to remove this point >of ambiguity by stating that within the IKE DOI, implementations are not >allowed to send a CERTREQ if doing so would extend the number of >messages beyond the six specified by the IKE. If either side doesn't >have a certificate, they can send a notify message and abort the >exchange. > >If we assume this strategy, the only thing we are missing is to have the >ISAKMP spec define a notify message which is "MISSING CERTIFICATE", >with the data field having the same information as is contained in the >CERTREQ message. Notify messages are optional to implement, so >implementations wouldn't have to do this; however, smart implementations >would be able note this information and then send the appropriate >certificate when they retry the IKE negotiation. Doug, is this >something you can add to the ISAKMP draft? > > From owner-ipsec Sat Mar 7 10:50:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA12256 for ipsec-outgoing; Sat, 7 Mar 1998 10:45:23 -0500 (EST) Date: Sat, 7 Mar 1998 10:58:26 -0500 (EST) Message-Id: <199803071558.KAA24402@picu.morningstar.com> From: Leonard Samuelson To: Jari Arkko Cc: pcalhoun@toast.net, ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-Reply-To: <34FC1F6C.A44EEBE8@ericsson.com> References: <199802280115.UAA09853@istari.sandelman.ottawa.on.ca> <34FC1F6C.A44EEBE8@ericsson.com> Reply-To: leonard_samuelson@Ascend.COM (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: bulk 40% of _everyone_? Is Finland rich or merely full of early adopters? Or perhaps it's a pain in the neck to wire everything... Jari Arkko writes: > > P.S. I happen to live in a country where mobility already is ubiquitous: > in Finland 40% of _all_ people have a mobile phone :-) -- Leonard Samuelson, Ascend Communications, Inc. 614-760-4024 From owner-ipsec Sat Mar 7 13:32:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13147 for ipsec-outgoing; Sat, 7 Mar 1998 13:31:22 -0500 (EST) Date: Sat, 7 Mar 1998 20:50:22 +0200 (EET) From: "Pekka Riikonen [Adm]" To: Len Samuelson cc: Jari Arkko , pcalhoun@toast.net, ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-Reply-To: <199803071558.KAA24402@picu.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk : 40% of _everyone_? Is Finland rich or merely full of early adopters? Or : perhaps it's a pain in the neck to wire everything... : Yep, Finland's population is about 5 million and we have over 1 million GSM phones + other mobile phones (NMT) probably hundreds of thousands. :) Well, rich and rich... We have the Nokia and for some reason finn's has adopted this mobility of phones very well. :) : Jari Arkko writes: : > : > P.S. I happen to live in a country where mobility already is ubiquitous: : > in Finland 40% of _all_ people have a mobile phone :-) Pekka __________________________________________________________________ Pekka Riikonen Email: priikone@fenix.pspt.fi PSPT/Department of Computer Science and Information Technology From owner-ipsec Sat Mar 7 20:59:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16008 for ipsec-outgoing; Sat, 7 Mar 1998 20:58:27 -0500 (EST) Date: Sat, 7 Mar 1998 21:10:57 -0500 (EST) Message-Id: <199803080210.VAA01968@carp.morningstar.com> From: Ben Rogers To: "Elfed T. Weaver" Cc: ipsec@tis.com, ddp@network-alchemy.com Subject: IPsec DOI v7 - comment In-Reply-To: <199803051226.HAA07188@relay.rv.tis.com> References: <199803051226.HAA07188@relay.rv.tis.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Elfed T. Weaver writes: > Protocol ID Value > RESERVED 0 > PROTO-ISAKMP 1 > PROTO-IPSEC-AH 2 > PROTO-IPSEC-ESP 3 > PROTO-IPCOMP 4 > > Q. When is it possible to negotiate a PROTO-ISAKMP SA AND > PROTO-IPSEC-* SA "at the same time" > > > Is it not the case that : > PROTO-ISAKMP is negotiated in phase 1 ONLY and > PROTO-IPSEC-* negotiated in phase 2 ONLY Or alternatively that the IKE draft provides (in addition to a generic Key Exchange method) a phase 1 DOI? It would be nice if we could (perhaps for IPsecond) sit down and clean up these drafts, splitting the IKE draft into logically unrelated IKE and Oakley-DOI documents. ben From owner-ipsec Sun Mar 8 14:03:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21047 for ipsec-outgoing; Sun, 8 Mar 1998 13:56:23 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John O Goyo" To: ipsec@tis.com Message-ID: <852565C1.0067F0A7.00@domino_c02.certicom.com> Date: Sun, 8 Mar 1998 14:05:52 -0400 Subject: [IPsec] ANSI X9.62 Groups Sender: owner-ipsec@ex.tis.com Precedence: bulk >---Lewis wrote: > I'm in favor of adding curves over field sizes of 163 and 239. > However I oppose including the specific curves defined in ANSI. > (Are these defns. from NCITS, or X9.62, or some other group?) > Those curves already present relatively rich targets for > precomputation attacks by virtue of their inclusion in an ANSI > standard. Let's put the IPSEC eggs in separate baskets by > generating some fresh curves for IKE with the requisite field sizes. The curves found in X9.62 are examples listed in an informative appendix. The curves that I posted earlier are none of these. Thank you. jog -------------------------------------------------------- john o goyo, mts jgoyo@certicom.com Certicom Corp. Suite 103, 200 Matheson Blvd. West Mississauga, Ontario, Canada L5R 3L7 +1.905.507.4220 (vox) +1.905.507.4230 (fax) -------------------------------------------------------- From owner-ipsec Mon Mar 9 07:25:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27294 for ipsec-outgoing; Mon, 9 Mar 1998 07:20:31 -0500 (EST) Date: Mon, 9 Mar 98 07:30:25 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803091230.AA05340@dolphin.ncsc.mil> To: mcr@sandelman.ottawa.on.ca Subject: ISAKMP-09 diagrams Cc: ipsec@tis.com, scottg@ftm.disa.mil Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, > Can we *please* change the bit numbering in the diagrams. It is just > very confusing for people that don't know better. Put bit 0 on the > right, in network byte order. > I'm willing to change the diagrams, but there are documents that describe the current format as the correct one. As an example, look at section 3 of draft-ietf-stdguide-ops-05.txt. IPSEC-ers, what say ye? Doug From owner-ipsec Mon Mar 9 07:39:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27496 for ipsec-outgoing; Mon, 9 Mar 1998 07:36:30 -0500 (EST) Date: Mon, 9 Mar 98 07:43:56 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803091243.AA05346@dolphin.ncsc.mil> To: ipsec@tis.com, tytso@MIT.EDU Subject: Re: Certificate Requesting Cc: jburke@cylink.com, kivinen@ssh.fi, angelos@dsl.cis.upenn.edu, mcr@sandelman.ottawa.on.ca Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > I had a telephone conversation with Dan Harkins Monday night while he > was at the interoperabilty conference, and it appears that most > implementations do assume that IKE takes exactly three round trips, and > the strategy for handling failures such as not having right certificates > is to abort the IKE exchange and retry using knowledge gained from the > previous exchange to do the right thing (such as, sending the CERTREQ > this time around.) > > Accordingly, Dan was going to modify the IKE spec to remove this point > of ambiguity by stating that within the IKE DOI, implementations are not > allowed to send a CERTREQ if doing so would extend the number of > messages beyond the six specified by the IKE. If either side doesn't > have a certificate, they can send a notify message and abort the > exchange. > > If we assume this strategy, the only thing we are missing is to have the > ISAKMP spec define a notify message which is "MISSING CERTIFICATE", > with the data field having the same information as is contained in the > CERTREQ message. Notify messages are optional to implement, so > implementations wouldn't have to do this; however, smart implementations > would be able note this information and then send the appropriate > certificate when they retry the IKE negotiation. Doug, is this > something you can add to the ISAKMP draft? Section 4.1 of ISAKMP states that Information Exchanges MUST be implemented. Notify Payloads are sent via an Informational Exchange, so implementations must handle the Notify messages, including those that say MISSING CERTIFICATE or REQUESTED-CERT-UNAVAILABLE (Michael Richardson's wording). I'm willing to add this as an additional Notify Message Type as long as we believe we have *rough* consensus. > I believe this approach is one for which we can achieve rough > consensus. Remember, at this stage of the game the important thing is > that we choose *one* way of doing things, so that we interoperate, and > then document it so we can get the specs nailed down and done. This is in agreement with the following e-mails: Angelos Keromytis - 2 Mar 98 Tero Kivinen - 3 Mar 98 Michael Richardson - 6 Mar 98 This is not in complete agreement with the following e-mail: John Burke - 27 Feb 98 Everyone OK with this approach? Doug From owner-ipsec Mon Mar 9 09:25:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28316 for ipsec-outgoing; Mon, 9 Mar 1998 09:21:32 -0500 (EST) Date: Mon, 9 Mar 1998 16:33:50 +0200 (EET) Message-Id: <199803091433.QAA02408@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson Cc: ipsec@tis.com Subject: Proposal to formalize the Notification Data field In-Reply-To: <199803062109.QAA01110@morden.sandelman.ottawa.on.ca> References: <199803062109.QAA01110@morden.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 25 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson writes: > Notification Status Messages MUST be sent under the protection of an > ISAKMP SA: either as a payload in the last Main Mode exchange; in a The last payload in the Main Mode exchange is NOT protected by ISAKMP SA. It is only encrypted but there is not message authentication code in the payload. The hash only protects g^xi, g^xr, cookies, SA and ID payload. If there are any other payloads (Notify, certificate, or certificate request payload) they are not protected by hash, and they can be modified. Modifying encrypted data is hard, but you can easily corrupt data thus causing certificates to be invalid or the other end not to understand the notification payload received. > separate Informational Exchange after Main Mode or Aggressive Mode > processing is complete; or as a payload in any Quick Mode exchange. > These messages MUST NOT be sent in Aggressive Mode exchanges unless > the authentication mode is RSA Encryption, since Aggressive Mode does > not otherwise provide the necessary protection to bind the Notify > Status Message to the exchange. Aggressive mode using RSA Encryption doesn't say anything whether the other payloads in the packet should be encrypted or not. Now it just lists that ID and Nonce must be encrypted. In the Revised RSA Encryption mode the draft says that at least the certificates sent in the same packet must be encrypted, but it doesn't say anything about notify payloads. > 3 2 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! bad-prot-id ! RESERVED ! faulty payload length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! RESERVED ! offset of fault ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ payload at fault ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! severity code! module code ! error num ! ascii space ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ error text ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The following messages have not yet been categorized. > ATTRIBUTES-NOT-SUPPORTED This is from transform payload. > NO-PROPOSAL-CHOSEN > BAD-PROPOSAL-SYNTAX These are from SA-payload. > o Payload Length (2 octets) - Length in octets of the included faulty ^^^^^^^^^^^^^^ Faulty Payload Length. > o severity code (1 octets) - an integer encoded as a single ascii > value. See RFC821, appendix E. > "1" Positive Preliminary reply > "2" Positive Completion reply > "3" Positive Intermediate reply > "4" Transient Negative Completion reply > "5" Permanent Negative Completion reply Why ascii values? All the other numbers are simple numbers, not ascii characters. > o module code - identifies which subsystem is involved (to be defined!) > o error code - number. Are these ascii numbers also? > o space - The ASCII space value, integer 32. > o error text - a human readable message, encoded in UTF8. One "line" of > text only. Suggested limit is 77 glyphs. Why 77? Why not 75 (3 digits + space + 75 glyphs = 79 == less than line). I assume there is no nul character at the end. I assume the ascii stuff is so you can just print the data from the payload? It just limits the number of error codes from 16777216 to 1000, and I think that is quite big restriction. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Mon Mar 9 10:21:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28837 for ipsec-outgoing; Mon, 9 Mar 1998 10:19:35 -0500 (EST) Message-Id: <98Mar9.103336est.11653@janus.tor.securecomputing.com> To: wdm@epoch.ncsc.mil (W. Douglas Maughan) cc: mcr@sandelman.ottawa.on.ca, ipsec@tis.com, scottg@ftm.disa.mil Subject: Re: ISAKMP-09 diagrams References: <9803091230.AA05340@dolphin.ncsc.mil> In-reply-to: wdm's message of "Mon, 09 Mar 1998 07:30:25 -0500". <9803091230.AA05340@dolphin.ncsc.mil> From: "C. Harald Koch" Date: Mon, 9 Mar 1998 10:32:31 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9803091230.AA05340@dolphin.ncsc.mil>, W. Douglas Maughan writes: > > I'm willing to change the diagrams, but there are documents that > describe the current format as the correct one. As an example, look at > section 3 of draft-ietf-stdguide-ops-05.txt. > > IPSEC-ers, what say ye? It's nice that someone is writing such a "how to write standards" document. A quick search through the Internet Standards archive shows that numbering from 0 on the left, to 31 on the right, is how most (all?) current documents are written. In other words, the ISAKMP doc is correct. -- Harald From owner-ipsec Mon Mar 9 15:12:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01746 for ipsec-outgoing; Mon, 9 Mar 1998 15:05:44 -0500 (EST) Date: Mon, 9 Mar 1998 15:18:07 -0500 Message-Id: <199803092018.PAA22201@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: wdm@epoch.ncsc.mil Cc: ipsec@tis.com, jburke@cylink.com, kivinen@ssh.fi, angelos@dsl.cis.upenn.edu, mcr@sandelman.ottawa.on.ca In-Reply-To: W. Douglas Maughan's message of Mon, 9 Mar 98 07:43:56 EST, <9803091243.AA05346@dolphin.ncsc.mil> Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 9 Mar 98 07:43:56 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Section 4.1 of ISAKMP states that Information Exchanges MUST be implemented. Notify Payloads are sent via an Informational Exchange, so implementations must handle the Notify messages, including those that say MISSING CERTIFICATE or REQUESTED-CERT-UNAVAILABLE (Michael Richardson's wording). I'm willing to add this as an additional Notify Message Type as long as we believe we have *rough* consensus. Surely handling Informational Exchanges is different from requiring that *all* notify payloads must be implemented. Suppose we define new payloads in the future; existing implementations wouldn't considered non-compliant because they failed to anticipate the specification of a new notify payload. In any case, my understanding is that this notify message is provides a message of an informational nature, and so an implementation is allowed to ignore the message if it so chooses. In bureaucratese, this gets roughly translated as "taking the information under advisement". :-) (Of course, it shouldn't make like an NT workstation after seeing an illegally fragmented UDP packet! That would be Bad.) - Ted From owner-ipsec Mon Mar 9 15:55:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02161 for ipsec-outgoing; Mon, 9 Mar 1998 15:53:47 -0500 (EST) Message-Id: <3.0.5.32.19980309160301.009675f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 09 Mar 1998 16:03:01 -0500 To: Michael Giniger , ipsec@tis.com From: Robert Moskowitz Subject: Re: VPN tunnel management bof In-Reply-To: <34FEC444.C805AA2A@tiac.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:27 AM 3/5/98 -0500, Michael Giniger wrote: > >I was wondering whether there will be a VPN tunnel management BOF at the >March IETF meeting? I remember this notion being discussed earlier but >I wasn't sure whether this will actually transpire. There will not be a VPN BOF, as we could not work out a consensus on a manageable discussion :) IPsec tunnel management will be part of the IPsecond discussion in the IPsec meeting. >Also, does anyone know the agenda for the IPSec working group at the >IETF meeting? In progress. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Mar 9 20:04:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03825 for ipsec-outgoing; Mon, 9 Mar 1998 20:00:47 -0500 (EST) Message-Id: <199803100113.RAA18361@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Michael Richardson Cc: ipsec@tis.com Subject: Re: my minutes from the end client tunnel config discussion In-Reply-To: Your message of "Thu, 05 Mar 1998 00:58:45 EST." <199803050558.AAA12821@morden.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Mar 1998 17:13:28 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Pertinent issues that are important to get working road > warrior/gateway tunnels: > 1. end client has no permanent IP address. The ID payload > will therefore be FQDN or user@FQDN. Or ID_DER_ASN1_DN-- the DER encoding of the DN of the certificate. > 2. due to #1, and the fact that the ID payload is not sent > until the third exchange, a road warrior can not use > pre-shared-keys for ISAKMP using main mode. The right > pre-shared-key can not be selected. Section 5.4 of > isakmp-oakley-06.txt mentions this. Agressive mode can be > used, but obviously, it does not provide identity protection. This is mitigated by the use of the ID_KEY_ID type. From the DOI: 4.6.2.12 ID_KEY_ID The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre- shared key should be used to authenticate Aggressive mode negotiations. This way a peer's ability to pass an ID of, say, "skdruhfak" and an associated pre-shared key of, say, "jlkert6y9e4h" would authenticate the peer without leaking its real identity. Note that this type has to be in the group of DOI=0 ID types that Doug is putting in the base ISAKMP document. > 3. a way is needed to configure the road warrior's inner > tunnel address. Roy Pereira's isakmp-mode-cfg is an initial attempt. > 4. we need some textual information in the nofity > messages. MCR will be writing a document. I like this very much. > 5. the bootstrap problem was declared out of scope for > IPsecond. > 6. we need to define *exactly* what goes into certificates > used on road warrior nodes. Rodney has a document in > preperation that addresses this for both end node and > gateways. > 7. we discussed whether or not policy configuration should > be in scope for IPsecond. Dan. From owner-ipsec Mon Mar 9 22:39:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04843 for ipsec-outgoing; Mon, 9 Mar 1998 22:37:46 -0500 (EST) From: phuong@raleigh.ibm.com Date: Mon, 9 Mar 1998 22:50:38 -0500 (EST) To: ipsec@tis.com Subject: [?] changes for Ipsec Arch. ??? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there any change for IPsec Architecture draft since IPsec bakeoff in Raleigh ? Thanks, Phuong From owner-ipsec Tue Mar 10 07:01:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA07757 for ipsec-outgoing; Tue, 10 Mar 1998 06:59:45 -0500 (EST) Date: Tue, 10 Mar 98 07:09:43 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803101209.AA05773@dolphin.ncsc.mil> To: weaver@hydra.dra.hmg.gb Subject: Re: ISAKMP Cert Req Processing Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Elfed, > In section 5.8 of ISAKMP v8 > > When Cert Req payload is received ...... > > 2. Determine if the Certificate types are supported. If ANY of the > certificate types are not supported, the message is discarded and the > following actions taken ........ > > Q. This (IMHO) implies that an entity must support all certificate > types is this the case ? > This section is changing in the next version. However, it is still based on the list of certificate types found in section 3.9 (Certificate Payload). This does not imply that an entity must support all certificate types. It just means you check to see if you support the certificate requested. If you do, then proceed, if you don't then you'll do something else. The something else is what Ted and Michael have been asking about on the list, i.e. a Notify message that the certificate is missing, unavailable, or not supported. The question is: should there be more than one message? Missing, Unavailable, and Not Supported are a little different. I think Missing and Unavailable can be put into the same group and satisfied with a single Notify message. Not Supported is entirely different and would allow a responder to convey some information to the initiator. Hope this helps. Cheers, Doug From owner-ipsec Tue Mar 10 07:52:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA08219 for ipsec-outgoing; Tue, 10 Mar 1998 07:51:46 -0500 (EST) Date: Tue, 10 Mar 1998 14:02:02 +0100 (MET) From: Christophe Gouault To: ipsec@tis.com Subject: Question about draft-ietf-ipsec-arch-sec-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello IPsec Folks, I have a question concerning draft-ietf-ipsec-arch-sec-03.txt. Here is the text about processing of inbound packets : ==== 5.2 Processing Inbound IP Traffic [...] 5.2.1 Selecting and Using an SA or SA Bundle [...] 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. ==== I wonder why INBOUND SPD entries are not ordered, as opposed to outbound's. IMHO, ordering policies is much more practical : e.g. I wish to declare the following policies : 1/ for hosts from net 137.37 policy is P1 2/ for hosts from subnet 137.37.2 policy is P2 (stronger than P1) 3/ for host 137.37.2.105 policy is P3 (stronger than P2) 4/ for host 137.37.4.203 policy is P4 (stronger than P1) I think it's a classical case. To obtain what I want, if SPD is ordered, I declare 4/ then 3/ 2/ and 1/. Without ordering policies, it is impossible to declare easily such policies. Since addresses declaration types are a single addr, a range or a wildcard address, I can't declare "host from net 137.37 except subnet 137.37.2", hence I'm compelled to make roughly such a declaration : hosts in range 137.37.0.0 - 137.37.1.255 policy P1 hosts in range 137.37.3.0 - 137.37.4.202 policy P1 hosts in range 137.37.4.203 - 137.37.255.255 policy P1 hosts in range 137.37.2.0 - 137.37.2.104 policy P2 hosts in range 137.37.2.106 - 137.37.2.255 policy P2 host 137.37.2.105 policy P3 host 137.37.4.203 policy P4 If a new (differently secured) host is added on this net, the declaration changes radically. For outbound policies, there is no problem since policies are ordered. Why are inbound policies unordered ? I'm sure there is a good reason, but I can't find which one. Could somebody help me ? Chris. From owner-ipsec Tue Mar 10 10:39:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09587 for ipsec-outgoing; Tue, 10 Mar 1998 10:37:58 -0500 (EST) Date: Tue, 10 Mar 1998 10:50:28 -0500 (EST) Message-Id: <199803101550.KAA08137@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: doi-07/interoperability questions Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk At the bakeoff, we ran into the small problem of some recent changes to the DOI document which caused many machines to be un-interoperable. Namely, the AH Transform types have changed, and the attribute requirements for AH transform payloads has also changed. This caused a problem because very few vendors (~3 or 4?) had actually implemented the current draft while the interoperable majority was still working with older code. I hope someone can confirm that support for the new document will be included in all production loads meeting the 15. March deadline. My other question centers on the use of Encapsulation Mode attributes in combined (AND) proposal transforms. Namely, it seems obvious that we should support the case where both are transport mode (Case 1.3 in section 4.5 of arch-sec), and not support the case where both are tunnel (probably returning a BAD-PROPSAL-SYNTAX). However, I'm not too clear as to whether I should support mixed proposals. My opinion is that it makes sense to support AH (transport) and ESP (tunnel) with the following encapsulation: [IP2][AH][ESP][IP1][upper] and to not support AH (tunnel) and ESP (transport). Does anyone else have any feelings on this matter? Whatever we choose probably ought to be added as clarifying text to [IPDOI]. ben From owner-ipsec Tue Mar 10 11:52:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10416 for ipsec-outgoing; Tue, 10 Mar 1998 11:47:59 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: draft-ietf-ipsec-ciph-cbc-02.txt Date: Tue, 10 Mar 1998 12:28:43 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft R. Adams Expires in six months Cisco Systems Inc. March 10, 1998 The ESP CBC-Mode Cipher Algorithms Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or 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. Abstract This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. R. Pereira, R. Adams [Page 1] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 Table of Contents 1. Introduction...................................................2 1.1 Specification of Requirements...............................2 2. Cipher Algorithms..............................................3 2.1 Mode........................................................3 2.2 Key Size....................................................3 2.3 Weak Keys...................................................4 2.4 Block Size and Padding......................................6 2.5 Rounds......................................................6 2.6 Backgrounds.................................................6 2.7 Performance.................................................9 3. ESP Payload...................................................10 3.1 ESP Environmental Considerations...........................10 3.2 Keying Material............................................10 4. Security Considerations.......................................11 5. References....................................................11 6. Acknowledgments...............................................12 7. Editors' Addresses............................................13 1. Introduction The Encapsulating Security Payload (ESP) [Kent98] provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of CBC-mode cipher algorithms. While this document does not describe the use of the default cipher algorithm DES, the reader should be familiar with that document. [Madson98] It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP Encapsulating Security Payload (ESP)" [Kent98] documents. Furthermore, this document is a companion to [Kent98] and MUST be read in its context. 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. R. Pereira, R. Adams [Page 2] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2. Cipher Algorithms All symmetric block cipher algorithms share common characteristics and variables. These include mode, key size, weak keys, block size, and rounds. All of which will be explained below. While this document illustrates certain cipher algorithms such as Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai], and RC5 [Baldwin96], any other block cipher algorithm may be used with ESP if all of the variables described within this document are clearly defined. 2.1 Mode All symmetric block cipher algorithms described or insinuated within this document use Cipher Block Chaining (CBC) mode. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's blocksize. The IV is XOR'd with the first plaintext block, before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted. More information on CBC mode can be obtained in [Schneier95]. 2.2 Key Size Some cipher algorithms allow for variable sized keys, while others only allow a specific key size. The length of the key correlates with the strength of that algorithm, thus larger keys are always harder to break than shorter ones. This document stipulates that all key sizes MUST be a multiple of 8 bits. This document does specify the default key size for each cipher algorithm. This size was chosen by consulting experts on the algorithm and by balancing strength of the algorithm with performance. R. Pereira, R. Adams [Page 3] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 +==============+==================+=================+==========+ | Algorithm | Key Sizes (bits) | Popular Sizes | Default | +==============+==================+=================+==========+ | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | +--------------+------------------+-----------------+----------+ | RC5 | 40 to 2040 | 40, 128, 160 | 128 | +--------------+------------------+-----------------+----------+ | IDEA | 128 | 128 | 128 | +--------------+------------------+-----------------+----------+ | Blowfish | 40 to 448 | 128 | 128 | +--------------+------------------+-----------------+----------+ | 3DES [2] | 192 | 192 | 192 | +--------------+------------------+-----------------+----------+ Notes: [1] With CAST-128, keys less than 128 bits MUST be padded with zeros in the rightmost, or least significant, positions out to 128 bits since the CAST-128 key schedule assumes an input key of 128 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', it would be padded to produce a key with a size of 128 bits '3B5D831CFE000000'. [2] The first 3DES key is taken from the first 64 bits, the second from the next 64 bits, and the third from the last 64 bits. Implementations MUST take into consideration the parity bits when initially accepting a new set of keys. The reader should note that the minimum key size for all of the above cipher algorithms is 40 bits, and that the authors strongly advise that implementations do NOT use key sizes smaller than 40 bits. 2.3 Weak Keys Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested. Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature. CAST-128: No known weak keys. R. Pereira, R. Adams [Page 4] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 RC5: No known weak keys when used with 16 rounds. IDEA: IDEA has weak keys of the following form [Crypto93]: 0000,0000,0x00,0000,0000,000x,xxxx,x000 where "x" can be any hexadecimal number. Keys of this form guarantee the value of bit-wise XOR of resultant ciphertext pairs from the bit-wise XOR of certain plaintext pairs. Blowfish: Weak keys for Blowfish have been discovered. Weak keys are keys that produce the identical entries in a given S-box. Unfortunately, there is no way to test for weak keys before the S- box values are generated. However, the chances of randomly generating such a key are small. 3DES: DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible. For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys. However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property. R. Pereira, R. Adams [Page 5] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2.4 Block Size and Padding All of the algorithms described in this document use a block size of eight octets (64 bits). Padding is used to align the payload type and pad length octets as specified in [Kent98]. Padding must be sufficient to align the data to be encrypted to an eight octet (64 bit) boundary. 2.5 Rounds This variable determines how many times a block is encrypted. While this variable MAY be negotiated, a default value MUST always exist when it is not negotiated. +====================+============+======================+ | Algorithm | Negotiable | Default Rounds | +====================+============+======================+ | CAST-128 | No | key<=80 bits, 12 | | | | key>80 bits, 16 | +--------------------+------------+----------------------+ | RC5 | No | 16 | +--------------------+------------+----------------------+ | IDEA [1] | 4, 8 | 8 | +--------------------+------------+----------------------+ | Blowfish | No | 16 | +--------------------+------------+----------------------+ | 3DES | No | 48 (16x3) | +--------------------+------------+----------------------+ Notes: [1] Although there are no known attacks against four round IDEA, those choosing to use four round IDEA for performance reasons may wish to use a shorter key lifetime (presumably via site specific policy). 2.6 Backgrounds CAST-128: The CAST design procedure was originally developed by Carlisle Adams and Stafford Travares at Queen's University, Kingston, Ontario, Canada. Subsequent enhancements have been made over the years by Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 is the result of applying the CAST Design Procedure as outlined in [Adams97]. R. Pereira, R. Adams [Page 6] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 RC5: The RC5 encryption algorithm was developed by Ron Rivest for RSA Data Security Inc. in order to address the need for a high- performance software and hardware ciphering alternative to DES. IDEA: Xuejia Lai and James Massey developed the IDEA (International Data Encryption Algorithm) algorithm. The algorithm is described in detail in [Lai] and [Schneier]. The IDEA algorithm is patented in Europe and in the United States with patent application pending in Japan. Licenses are required for commercial uses of IDEA. For patent and licensing information, contact: Ascom Systec AG, Dept. CMVV Gewerbepark, CH-5506 Magenwil, Switzerland Phone: +41 64 56 59 83 Fax: +41 64 56 59 90 idea@ascom.ch http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html Blowfish: Bruce Schneier of Counterpane Systems developed the Blowfish block cipher algorithm. The algorithm is described in detail in [Schneier93], [Schneier95] and [Schneier]. 3DES: This DES variant, colloquially known as "Triple DES" or as DES- EDE3, processes each block three times, each time with a different key. This technique of using more than one DES operation was proposed in [Tuchman79]. R. Pereira, R. Adams [Page 7] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 P1 P2 Pi | | | IV->->(X) +>->->->(X) +>->->->(X) v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k1->| E | ^ k1->| E | ^ k1->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k2->| D | ^ k2->| D | ^ k2->| D | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k3->| E | ^ k3->| E | ^ k3->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | +>->->+ +>->->+ +>->-> | | | C1 C2 Ci The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algorithm [FIPS-46]. The "outer" chaining technique is used. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 byte) plaintext block (P1). The keyed DES function is iterated three times, an encryption (Ek1) followed by a decryption (Dk2) followed by an encryption (Ek3), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3. For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES-EDE3 encryption function generates the ciphertext (Ci) for that block. To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR the previous ciphertext block. Note that when all three keys (k1, k2 and k3) are the same, DES- EDE3-CBC is equivalent to DES-CBC. This property allows the DES- EDE3 hardware implementations to operate in DES mode without modification. For more explanation and implementation information for Triple DES, see [Schneier95]. R. Pereira, R. Adams [Page 8] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2.7 Performance For a comparison table of the speed of any of these and other cipher algorithms, please see [Schneier97]. CAST-128: CAST runs approximately 3 times faster than a highly optimized DES implementation and runs 5-6 times faster than the DES implementations found in typical applications. This is based on a non-optimized C++ implementation of CAST-128. It can therefore be tuned to give even higher performance, if this is required. RC5: Benchmark numbers from RSA Data Security suggest that RC5-CBC runs about twice as fast as Eric Young's DES-CBC implementation from SSLeay on the popular 32-bit CPUs. IDEA: Normal eight round IDEA is approximately twice as fast as DES on 386 and 486 processors. However on a Pentium, both eight round IDEA and 56 bit key, 16 round DES require about the same number of clock cycles per byte encrypted. Four round IDEA is twice as fast as eight round IDEA. Blowfish: Blowfish is designed to encrypt data very efficiently on 32 bit processors. Although setting up the keys for Blowfish is complex and time consuming, actual encryption is efficient. Sixteen round Blowfish uses only 18 clock cycles per byte encrypted on a Pentium versus 45 clock cycles for 16 round DES with a 56 bit key, and 108 for 48 round Triple-DES. 3DES: Triple DES is approximately 2.5 times slower than "single" DES (rather than 3 times), because inner permutations may be removed. Phil Karn has tuned DES-EDE3-CBC software to achieve very fast performance. Other DES speed estimates may be found at [Schneier, page 279]. R. Pereira, R. Adams [Page 9] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 3. ESP Payload The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [Kent98], is broken down according to the following diagram: +---------------+---------------+---------------+---------------+ | | + Initialization Vector (8 octets) + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (variable length) ~ | | +---------------------------------------------------------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The IV field MUST be same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random. Common practice is to use random data for the first IV and the last block of encrypted data from an encryption process as the IV for the next encryption process. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. 3.1 ESP Environmental Considerations Currently, there are no known issues regarding interactions between these algorithms and other aspects of ESP, such as use of certain authentication schemes. 3.2 Keying Material The minimum number of bits sent from the key exchange protocol to this ESP algorithm must be greater or equal to the key size. The cipher's encryption and decryption key is taken from the first bits of the keying material, where represents the required key size. R. Pereira, R. Adams [Page 10] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 4. Security Considerations Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. The case for using random values for IVs has been refined with the following summary provided by Steve Bellovin. Refer to [Bell97] for further information. For further security considerations, the reader is encouraged to read the documents that describe the actual cipher algorithms. 5. References [Adams97] C. Adams, "The CAST-128 Encryption Algorithm", RFC2144, 1997. [Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-03 [Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC- Pad, and RC5-CTS Algorithms", RFC2040, October 1996 [Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}). [Bradner97] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997 [Crypto93] J. Daeman, R. Govaerts, J. Vandewalle, "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, pp. 224-230. [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v2-03 R. Pereira, R. Adams [Page 11] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 [Lai] X. Lai, "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. [Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", draft-ietf-ipsec-ciph- des-expiv-02 [Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471- 12845-7 [Schneier93]B. Schneier, "Description of a New Variable-Length Key, 64-Bit Block Cipher", from "Fast Software Encryption, Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, pp. 191-204. http://www.counterpane.com/bfsverlag.html [Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One Year Later", Dr. Dobb's Journal, September 1995, http://www.counterpane.com/bfdobsoyl.html [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", draft-ietf-ipsec-doc-roadmap-02 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 6. Acknowledgments This document is a merger of most of the ESP cipher algorithm documents. This merger was done to facilitate greater understanding of the commonality of all of the ESP algorithms and to further the development of these algorithm within ESP. The content of this document is based on suggestions originally from Stephen Kent and subsequent discussions from the IPSec mailing list as well as other IPSec drafts. For CAST, special thanks to Carlisle Adams and Paul Van Oorschot both of Entrust Technologies who provided input and review. For 3DES, thanks to all of the editors of the previous ESP 3DES documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. R. Pereira, R. Adams [Page 12] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 For RC5, thanks to Brett Howard from TimeStep for his original work. 7. Editors' Addresses Roy Pereira TimeStep Corporation +1 (613) 599-3610 x 4808 Rob Adams Cisco Systems Inc. +1 (408) 457-5397 Contributors: Robert W. Baldwin or RSA Data Security, Inc. +1 (415) 595-8782 Greg Carter Entrust Technologies +1 (613) 763-1358 Rodney Thayer rodney@sabletech.com Sable Technology Corporation +1 (617) 332-7292 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira, R. Adams [Page 13] From owner-ipsec Tue Mar 10 13:03:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11051 for ipsec-outgoing; Tue, 10 Mar 1998 13:02:02 -0500 (EST) Message-Id: <3.0.5.32.19980310130827.00996d60@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Mar 1998 13:08:27 -0500 To: phuong@raleigh.ibm.com, ipsec@tis.com From: Robert Moskowitz Subject: Re: [?] changes for Ipsec Arch. ??? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:50 PM 3/9/98 -0500, phuong@raleigh.ibm.com wrote: > >Is there any change for IPsec Architecture draft since >IPsec bakeoff in Raleigh ? > Architecture says that ESP gives confidentuality. With Null ESP, that needs some word smithing,,,, COrrect Steve? Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Mar 10 13:47:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11358 for ipsec-outgoing; Tue, 10 Mar 1998 13:46:58 -0500 (EST) Message-Id: <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Mar 1998 13:54:54 -0500 To: ben@Ascend.COM (Ben Rogers), ipsec@tis.com From: Robert Moskowitz Subject: Re: doi-07/interoperability questions In-Reply-To: <199803101550.KAA08137@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:50 AM 3/10/98 -0500, Ben Rogers wrote: I believe you are talking about where the transforms all end at the same system not the case where the transport is end to end and the tunnel is gateway to gateway. >My other question centers on the use of Encapsulation Mode attributes in >combined (AND) proposal transforms. Namely, it seems obvious that we >should support the case where both are transport mode (Case 1.3 in >section 4.5 of arch-sec), and not support the case where both are tunnel >(probably returning a BAD-PROPSAL-SYNTAX). However, I'm not too clear >as to whether I should support mixed proposals. My opinion is that it >makes sense to support AH (transport) and ESP (tunnel) with the >following encapsulation: > >[IP2][AH][ESP][IP1][upper] > >and to not support AH (tunnel) and ESP (transport). Does anyone else >have any feelings on this matter? Whatever we choose probably ought to >be added as clarifying text to [IPDOI]. > > >ben > > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Mar 10 14:09:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11563 for ipsec-outgoing; Tue, 10 Mar 1998 14:08:01 -0500 (EST) Date: Tue, 10 Mar 1998 14:20:47 -0500 (EST) Message-Id: <199803101920.OAA08417@carp.morningstar.com> From: Ben Rogers To: Robert Moskowitz Cc: ipsec@tis.com Subject: Re: doi-07/interoperability questions In-Reply-To: <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> References: <199803101550.KAA08137@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes. In fact, I was thinking specifically about gateway to gateway configurations using both AH and ESP. Robert Moskowitz writes: > At 10:50 AM 3/10/98 -0500, Ben Rogers wrote: > > I believe you are talking about where the transforms all end at the same > system not the case where the transport is end to end and the tunnel is > gateway to gateway. > > >My other question centers on the use of Encapsulation Mode attributes in > >combined (AND) proposal transforms. Namely, it seems obvious that we > >should support the case where both are transport mode (Case 1.3 in > >section 4.5 of arch-sec), and not support the case where both are tunnel > >(probably returning a BAD-PROPSAL-SYNTAX). However, I'm not too clear > >as to whether I should support mixed proposals. My opinion is that it > >makes sense to support AH (transport) and ESP (tunnel) with the > >following encapsulation: > > > >[IP2][AH][ESP][IP1][upper] > > > >and to not support AH (tunnel) and ESP (transport). Does anyone else > >have any feelings on this matter? Whatever we choose probably ought to > >be added as clarifying text to [IPDOI]. > > > > > >ben > > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Mar 10 14:15:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11625 for ipsec-outgoing; Tue, 10 Mar 1998 14:15:00 -0500 (EST) Message-Id: <199803101925.OAA14019@relay.hq.tis.com> To: ben@Ascend.COM (Ben Rogers) cc: ipsec@tis.com Subject: Re: doi-07/interoperability questions In-reply-to: Your message of "Tue, 10 Mar 1998 10:50:28 EST." <199803101550.KAA08137@carp.morningstar.com> Date: Tue, 10 Mar 1998 11:27:07 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >At the bakeoff, we ran into the small problem of some recent changes to >the DOI document which caused many machines to be un-interoperable. The change to use an attribute to fully identify the appropriate AH transform occured in the Version 3 DOI, which was submitted to the ID on July 31, 1997. That was eight months and four drafts ago. I'm sorry you missed it. It's release might simply predate your participation on this list. I think your characterization of this change as being both unexpected and recent is at odds with the facts. I also think your assertion that "very few vendors had actually implemented this" is grossly inaccurate as well. Derrell From owner-ipsec Tue Mar 10 14:29:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11763 for ipsec-outgoing; Tue, 10 Mar 1998 14:29:01 -0500 (EST) Date: Tue, 10 Mar 1998 14:41:39 -0500 (EST) Message-Id: <199803101941.OAA08443@carp.morningstar.com> From: Ben Rogers To: "Derrell D. Piper" Cc: ipsec@tis.com Subject: Re: doi-07/interoperability questions In-Reply-To: <199803101927.LAA06845@drawbridge.ascend.com> References: <199803101550.KAA08137@carp.morningstar.com> <199803101927.LAA06845@drawbridge.ascend.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper writes: > Ben, > > >At the bakeoff, we ran into the small problem of some recent changes to > >the DOI document which caused many machines to be un-interoperable. > > The change to use an attribute to fully identify the appropriate AH transform > occured in the Version 3 DOI, which was submitted to the ID on July 31, 1997. > That was eight months and four drafts ago. I'm sorry you missed it. It's > release might simply predate your participation on this list. > > I think your characterization of this change as being both unexpected and > recent is at odds with the facts. I also think your assertion that "very few > vendors had actually implemented this" is grossly inaccurate as well. I'm not complaining about the current draft. In fact, I have implemented it. However, I found that sending either an AH-MD5 or an AH-SHA1 with the corresponding HMAC-MD5 or HMAC-SHA1 attribute was not accepted by many implementations, and only 3 or 4 others actually sent these transform payloads with the correct auth attribute. Perhaps I just had bad luck with the people I tried to interoperate with. ben From owner-ipsec Tue Mar 10 14:32:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11800 for ipsec-outgoing; Tue, 10 Mar 1998 14:31:59 -0500 (EST) Message-Id: <3.0.5.32.19980310143859.009e6660@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Mar 1998 14:38:59 -0500 To: ben@Ascend.COM (Ben Rogers) From: Robert Moskowitz Subject: Re: doi-07/interoperability questions Cc: ipsec@tis.com In-Reply-To: <199803101920.OAA08417@carp.morningstar.com> References: <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> <199803101550.KAA08137@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:20 PM 3/10/98 -0500, Ben Rogers wrote: > >Yes. In fact, I was thinking specifically about gateway to gateway >configurations using both AH and ESP. In that case... >> >as to whether I should support mixed proposals. My opinion is that it >> >makes sense to support AH (transport) and ESP (tunnel) with the >> >following encapsulation: >> > >> >[IP2][AH][ESP][IP1][upper] >> > >> >and to not support AH (tunnel) and ESP (transport). Does anyone else This feels right to me. What you are saying is that the gateways are maintaining a secure tunnel, which is separately authenticated. (I think :). So you want the tunneled IP datagram in one piece. The AH (transport) and ESP (tunnel) delivers this. The AH (tunnel) and ESP (transport) breaks the IP datagram. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Mar 10 16:50:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12679 for ipsec-outgoing; Tue, 10 Mar 1998 16:46:59 -0500 (EST) Message-Id: <3505B97B.E28DAEF4@zk3.dec.com> Date: Tue, 10 Mar 1998 17:06:51 -0500 From: "Eric L. Wong" X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Ben Rogers Cc: Robert Moskowitz , ipsec@tis.com Subject: Re: doi-07/interoperability questions References: <199803101550.KAA08137@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> <199803101920.OAA08417@carp.morningstar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sounds to me you are suggesting the following changes to the arch spec in section 4.5 Case 1. ] ] 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] ] Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] (remove)4. [IP2][AH][IP1][upper] (remove)2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] (add)6. [IP2][AH][ESP][IP1][upper] Is this correct? I think it is ok to remove 4, it really doesn't buy you much. I think we should keep 2. This new one for tunnel mode seem to make sense. Now, should we restrict 6 to just gateway-to- gateway? /eric Ben Rogers wrote: > > Yes. In fact, I was thinking specifically about gateway to gateway > configurations using both AH and ESP. > > Robert Moskowitz writes: > > At 10:50 AM 3/10/98 -0500, Ben Rogers wrote: > > > > I believe you are talking about where the transforms all end at the same > > system not the case where the transport is end to end and the tunnel is > > gateway to gateway. > > > > >My other question centers on the use of Encapsulation Mode attributes in > > >combined (AND) proposal transforms. Namely, it seems obvious that we > > >should support the case where both are transport mode (Case 1.3 in > > >section 4.5 of arch-sec), and not support the case where both are tunnel > > >(probably returning a BAD-PROPSAL-SYNTAX). However, I'm not too clear > > >as to whether I should support mixed proposals. My opinion is that it > > >makes sense to support AH (transport) and ESP (tunnel) with the > > >following encapsulation: > > > > > >[IP2][AH][ESP][IP1][upper] > > > > > >and to not support AH (tunnel) and ESP (transport). Does anyone else > > >have any feelings on this matter? Whatever we choose probably ought to > > >be added as clarifying text to [IPDOI]. > > > > > > > > >ben > > > > > > > > Robert Moskowitz > > ICSA > > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Mar 10 17:13:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12922 for ipsec-outgoing; Tue, 10 Mar 1998 17:13:00 -0500 (EST) Date: Tue, 10 Mar 1998 17:23:44 -0500 (EST) Message-Id: <199803102223.RAA09766@carp.morningstar.com> From: Ben Rogers To: "Eric L. Wong" Cc: Robert Moskowitz , ipsec@tis.com Subject: Re: doi-07/interoperability questions In-Reply-To: <3505B97B.E28DAEF4@zk3.dec.com> References: <199803101550.KAA08137@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> <199803101920.OAA08417@carp.morningstar.com> <3505B97B.E28DAEF4@zk3.dec.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric L. Wong writes: > Sounds to me you are suggesting the following changes to the arch spec > in section 4.5 Case 1. > ] > ] 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] > ] > > Transport Tunnel > ----------------- --------------------- > 1. [IP1][AH][upper] (remove)4. [IP2][AH][IP1][upper] > (remove)2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] > 3. [IP1][AH][ESP][upper] (add)6. [IP2][AH][ESP][IP1][upper] > > Is this correct? Nope. All I'm suggesting is that we have a way to negotiate 5 followed by 1 in ISAKMP. The net result being: [IP1][upper] [IP2][ESP][IP1][upper] [IP2][AH][ESP][IP1][upper] I used to think that 6 was necessary, but was convinced this was not a valid combination by Stephen Kent at the December IETF (AH is no longer in tunnel mode). You can, however, emulate it using the 5+1 combination. This was what I was suggesting in the AH (transport) + ESP (tunnel) proposal. ben From owner-ipsec Tue Mar 10 18:09:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13244 for ipsec-outgoing; Tue, 10 Mar 1998 18:07:57 -0500 (EST) Message-Id: <98Mar10.182152est.11654@janus.tor.securecomputing.com> To: ben@Ascend.COM (Ben Rogers) cc: "Derrell D. Piper" , ipsec@tis.com Subject: Re: doi-07/interoperability questions References: <199803101550.KAA08137@carp.morningstar.com> <199803101927.LAA06845@drawbridge.ascend.com> <199803101941.OAA08443@carp.morningstar.com> In-reply-to: ben's message of "Tue, 10 Mar 1998 14:41:39 -0500". <199803101941.OAA08443@carp.morningstar.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 10 Mar 1998 18:20:38 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199803101941.OAA08443@carp.morningstar.com>, Ben Rogers writes: > > I'm not complaining about the current draft. In fact, I have > implemented it. However, I found that sending either an AH-MD5 or an > AH-SHA1 with the corresponding HMAC-MD5 or HMAC-SHA1 attribute was > not accepted by many implementations, and only 3 or 4 others actually > sent these transform payloads with the correct auth attribute. I saw this too. In fact, we had to relax our policy configuration code to interoperate with several other vendors for this exact reason. I agree with Derrell that the standard is explicit on this. However, many vendors are getting it wrong... -- Harald From owner-ipsec Tue Mar 10 18:44:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13477 for ipsec-outgoing; Tue, 10 Mar 1998 18:44:00 -0500 (EST) Date: Tue, 10 Mar 98 18:54:11 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803102354.AA06291@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP-09 Changes Sender: owner-ipsec@ex.tis.com Precedence: bulk I have submitted a revised version of the ISAKMP Internet-Draft (ISAKMP-09) to the WG chairs and the Internet-Drafts folks. I expect it will show up whenever they get around to it. I will send additional e-mails to the IPSEC list containing the PostScript and ASCII Text versions. In the meantime, the changes made are as follows: ISAKMP - Changes made from 08 to 09 ----------------------------------- NOTE: All of the following changes were made with an attempt to not cause significant changes to current ISAKMP implementations. If any of these changes impact you adversely, please post your complaints to the IPSEC list and let's get them cleared up as soon as possible. Section 1 --------- 1.1 Removed requirements terminology; Point to RFC 2119 1.5 Addition of clarifying text associated with passwords Rationale: Result of IAB Security Architecture Workshop (David Jablon - 22 Mar 97 e-mail) 1.7.1 Additional text to clarify denial of service protection (Angelos Keromytis - 4 Mar 98 e-mail) Section 2 --------- 2.2 Addition of Key Exchange Definition to ISAKMP Relationships Diagram Rationale: Clarity and completeness 2.2 Addition of API to ISAKMP Relationships Diagram Rationale: Clarity and completeness 2.4 Clarification of location of SPI field It's in the Proposal payload, not in the ISAKMP Header (Eric Wong - 23 Jan 98 e-mail) Section 3 --------- 3.1 Addition of Vendor ID Payload Type (More detail below under section 3.16) 3.1 Addition of text to Flags field description Remaining bits MUST be set to zero Rationale: Processing Efficiency; Clarity (Richard Waterhouse - 27 Aug 97 e-mail) 3.1 Addition of Authentication Bit to Flags field of ISAKMP Header Rationale: Use with Info Exch - Notify without encryption (Discussed at Munich IETF) 3.1 Clarifying text to the Message-ID field in the event of collisions (Robert Tashjian - 10 Oct 97 e-mail - raised issue) (Roy Shamir - 12 Oct 97 e-mail) (Dan Harkins - 13 Oct 97, 14 Oct 97 e-mails) (Shin Yoshida - 14 Oct 97 e-mail) 3.1 Added pointer to IKE for discussion about encryption expansion (Ben Rogers - 12 Sep 97 e-mail) 3.3 Clarification of Attribute Type field of Data Attributes (Tero Kivinen - 3 Mar 98 e-mail) 3.3 Removal of requirement for byte alignment of Attribute Value field (Matt Thomas - 18 Feb 98 e-mail) (John Burke - 19 Feb 98 e-mail) (Matt Thomas - 2 Mar 98 e-mail) (Tero Kivinen - 3 Mar 98 e-mail) 3.4 Clarifying text about the presence of the DOI and Situation field They MUST be present in all SA payloads. Rationale: Processing efficiency; Clarity; Remove possible complexity (Richard Waterhouse - 27 Aug 97 e-mail) 3.4 Additional text in DOI field description about IANA values Rationale: Clarify who assigns value and how they do it (Ran Atkinson - 17 Sep 97 e-mail) 3.4 Additional text in DOI field description for Generic ISAKMP SAs DOI value of 0 = Generic ISAKMP SA, DOI value of 1 = IPSEC SA Rationale: Provides for Generic and Specific ISAKMP SA and will allow future inclusion of other protocol-specific SAs (Ben Rogers - 14 Oct 97 e-mail) (ISAKMP_IKE+DOI Reading Party comments - 11 Dec 97 e-mail) (Dan Harkins - 23 Dec 97 e-mail) (Dan Harkins - 18 Feb 98 e-mail) 3.5 Additional text to describe the Payload Length of Proposal Payload Rationale: Clarity about what goes into this field (Hugh Redelmeier - 23 Feb 98 e-mail) 3.5 Clarification of SPI Size field of Proposal payload Rationale: Clarify the value of field in Phase 1 and Phase 2 (John Burke - 10 Sep 97 e-mail) (Dan Harkins - 11 Sep 97 e-mail) 3.6 Clarification of Transform payload description (Matt Thomas - 29 Sep 97 e-mail) 3.8 Changed RESERVED2 field to be DOI specific ID data Rationale: Maps to IPSEC DOI and future DOIs (Hugh Redelmeier - 23 Feb 98 e-mail) 3.9 Added X.509 Attribute Certificate Type for Certificate payload (David Kemp - 8 Oct 97 e-mail - requesting change) (Roy Pereira - 8 Oct 97 e-mail - agreed with addition) (Greg Carter - 8 Oct 97 e-mail - also agreed with addition) 3.10 Clarifying text and change of payload format for the Certificate Request payload. Rationale: Improve parsing and clarity of payload use (Discussed at Munich IETF) (Tyler Allison - 14 Jan 98 e-mail) (Tero Kivinen - 19 Feb 98 e-mail) 3.14 Clarification on alignment of SPI w/respect to Notification Data SPI is not 4-octet boundary aligned. (Matt Thomas - 29 Sep 97 e-mail) 3.14 Clarification of values for DOI field of Notify Payload Rationale: Clarity and completeness (Hugh Redelmeier - 23 Feb 98 e-mail) 3.14 Clarification of values for SPI Size field of Notify Payload Rationale: Clarity (John Burke - 19 Feb 98 e-mail) 3.14.1 Notify Message Types - Added NOTIFY-SA-LIFETIME notify message Rationale: Used to inform peer of different SA lifetime value (John Burke - 30 Sep 97 e-mail - agreed to adding Notify code) (Derrell Piper - 30 Sep 97 e-mail) (Dan Harkins - 11 Nov 97 e-mail) 3.14.1 Notify Message Type Codes Changed to be consistent with DOI (John Burke - 19 Feb 98 e-mail) 3.14.1 Notify Message Type Codes - Certificate Request related Added (28) and changed (21) Notify message Type codes (Tero Kivinen - 3 Mar 98 e-mail) (Elfed Weaver - 5 Mar 98 e-mail) (Michael Richardson - 4 Mar & 6 Mar 98 e-mails) 3.15 Clarification of values for DOI field of Delete Payload Rationale: Clarity and completeness (Hugh Redelmeier - 23 Feb 98 e-mail) 3.16 New Section - Vendor ID Payload (Dan Harkins - 1 Oct 97 e-mail) (Michael Richardson - 13 Oct 97 e-mail - THANKS for the text!) (Dan Harkins - 18 Feb 98, 22 Feb 98 e-mails) (Tero Kivinen - 19 Feb 98 e-mail) (Derrell Piper - 20 Feb 98 e-mail) Section 4 --------- 4 Moved 4.3 to 4.1, 4.1 to 4.2, 4.2 to 4.3 (This was done to provide a better ordering of things) 4.1 Added clarifying text to the ordering of payloads (new) (Ben Rogers - 11 Sep 97 e-mail - requested mandating) (Dan Harkins - 11 Sep 97 e-mail - agreed with mandating) (Tero Kivinen - 12 Sep 97 e-mail - won't make a difference) (Greg Carter - 12 Sep 97 e-mail - doesn't matter) (John Burke - 12 Sep 97 e-mail - think before acting) (Ben Rogers - 12 Sep 97 e-mail - reduce processing/complexity) (John Burke - 1 Oct 97 e-mail) 4.2 Added clarifying text to end of first paragraph about the (new) relationship between the SA, Proposal, and Transform payloads. ISAKMP will remain flexible in its expression of these payloads, while IKE and other "users" of ISAKMP can constrain as desired. Rationale: ISAKMP is the framework protocol and as such will remain as flexible as possible for both phases of negotiation. (Alexei Vopilov - 22 Dec 97 e-mail) (John Burke - 23 Dec 97 e-mail) (Dan Harkins - 30 Dec 97 e-mail) 4.3 Added clarifying text to Modification of a Protocol SA (phase 2) (new) Rationale: Unclear wording on how to handle traffic on an old SA (Scott Kelly - 8 Jan 98 e-mail) 4.7 Clarification of Proposal and Transform payloads sent in an Aggressive Exchange 4.8 Added clarifying text for IVs w/respect to Info Exchange Ensures independence of Info Exchange IV and other IVs (Discussed at Munich IETF) (Ruth Taylor{NSA} - personal communication) (Greg Carter - 28 Sep 97 e-mail) (Tylor Allison - 15 Jan 98 e-mail) Section 5 --------- 5 (all) Clarification of wording associated with logging events to the appropriate system audit file, i.e. is logged --> MAY be logged 5 (all) Clarification of when a message is discarded and when only a payload is discarded (Tero Kivinen - 3 Mar 98 e-mail) 5.4 Moved 5.4.1 to 5.5 and 5.4.2 to 5.6; all other sections of 5 are increased by 2, i.e. 5.X = 5.X+2 for X > 4 5.6 Clarification of Transform Processing - Invalid vs. Unknown (new) (Matt Thomas - 29 Sep 97 e-mail) 5.10 Changed payload processing wording to match new payload format Added 1 and changed 1 Notify message (Tero Kivinen - 3 Mar 98 e-mail) (Elfed Weaver - 5 Mar 98 e-mail) (Michael Richardson - 6 Mar 98 e-mail) 5.14 Clarification of transmission of Notify Payload in an (new) Informational Exchange rather than appended to an existing exchange (Tylor Allison - 15 Jan 98 e-mail) 5.14 Addition of text clarifying processing of Notify Payload when (new) protected using the Authentication Only Bit (Tom Markham - 2 Mar 98 e-mail) Appendix A ---------- A Sections renumbered - A.2 deleted, A.2.1 -> A.2, A.2.2 -> A.3 and A.4 is new Rationale: Separation of information into different sections A.3 Clarification on security protocols values and IANA assignment (new) Rationale: Correct number space assignment (Ran Atkinson - 17 Sep 97 e-mail) A.4 Inclusion of values for ID Types for a Generic ISAKMP SA Taken from DOI section 4.6.2.* - Thanks Derrell (See third 3.4 change section above for contributors) IANA Considerations ------------------- Added new section to conform to requirements of IESG Bibliography ------------ Updated reference to DNSSEC Added reference to IAB Security Architecture Workshop Updated reference to IPSEC DOI Changed IO-RES to IKE; Updated reference to IKE (throughout document) Added reference to RFC-2119 Addresses of Authors -------------------- Changed Jeff Turner's address information From owner-ipsec Tue Mar 10 19:34:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA13837 for ipsec-outgoing; Tue, 10 Mar 1998 19:32:58 -0500 (EST) Message-Id: <9803110045.AA14142@hpcc103.corp.hp.com> To: ipsec@tis.com Subject: Re: doi-07/interoperability questions In-Reply-To: Your message of Tue, 10 Mar 1998 17:06:51 -0500. <3505B97B.E28DAEF4@zk3.dec.com> Date: Tue, 10 Mar 1998 16:45:49 -0800 From: Yan-Fa LI Sender: owner-ipsec@ex.tis.com Precedence: bulk If this assertion is correct, as a customer not a developer, I see a use for option 4 and would ask you not to remove it. Crypto arguments aside, there are three uses for this within the organization I work for. One, is the obvious situation where I have no other option, because of regulatory reasons, but I want improved IP where privacy is less important than integrity. For example, managing someone elses network across a less trusted network, note this managed network could even have non-publically routable address space. This would be end-to-edge. Two, improving leased line security from business partners, in an end-to-edge situation. Privacy is outweighed by authentication and integrity requirements with less client and gateway processing. This would be aided and abetted by simple firewall processing at the end of the tunnel on the edge hardware. Three, some xDSL providers are offering backhaul connections to corporate networks. Supposedly the traffic is across ATM VCs and so is as private as leased lines are today, questionable security premise I know. If we decided that privacy were not an issue, then it would fall back to authentication and authorization issues. AH, in tunnel mode, would suffice for this purpose, without the overhead for encryption; would this be worse or better from a client standpoint than ESP 56bit w/ HMAC and replay with SHA-1 ? I'd love to hear more expert opinion about this issue. Yes this is all end-to-edge centric. I'm thinking clients to gateways not gateway to gateway as yet. That's phase II ;) my $0.02 Y > Sounds to me you are suggesting the following changes to the arch spec > in section 4.5 Case 1. > ] > ] 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] > ] > > Transport Tunnel > ----------------- --------------------- > 1. [IP1][AH][upper] (remove)4. [IP2][AH][IP1][upper] > (remove)2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] > 3. [IP1][AH][ESP][upper] (add)6. [IP2][AH][ESP][IP1][upper] > > Is this correct? > > I think it is ok to remove 4, it really doesn't buy you much. > I think we should keep 2. This new one for tunnel mode seem > to make sense. Now, should we restrict 6 to just gateway-to- > gateway? > > /eric From owner-ipsec Wed Mar 11 07:23:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18303 for ipsec-outgoing; Wed, 11 Mar 1998 07:20:01 -0500 (EST) Date: Tue, 10 Mar 98 18:58:17 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803102358.AA06309@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP-09 .txt Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 4 As promised, ISAKMP-09 ASCII Text. Doug ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: draft-ietf-ipsec-isakmp-09.txt X-Sun-Content-Lines: 4927 IPSEC Working Group Douglas Maughan, Mark Schertler INTERNET-DRAFT Mark Schneider, Jeff Turner draft-ietf-ipsec-isakmp-09.txt, .ps March 10, 1998 Internet Security Association and Key Management Protocol (ISAKMP) Abstract This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and crypto- graphic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mecha- nisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicat- ing peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to es- tablish and maintain secure communications (via IP Security Ser- vice or any other security protocol) in an Internet environment. Status of this memo This document is being submitted to the IETF Internet Protocol Security (IPSEC) Working Group for consideration as a method for the establishment and management of security associations and their appropriate security at- tributes. Additionally, this document proposes a method for key manage- ment to support IPSEC and IPv6. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments are solicited and should be addressed to the authors and/or the IPSEC working group mailing list at ipsec@tis.com. 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-DRAFT ISAKMP March 10, 1998 Internet Drafts are draft documents valid for a maximum of six 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 ``working draft'' or ``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 Di- rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Maughan, Schertler, Schneider, Turner ISAKMP [Page 2] INTERNET-DRAFT ISAKMP March 10, 1998 Contents 1 Introduction 6 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 7 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . . . . 7 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . . . . . 7 1.4 Security Associations and Management . . . . . . . . . . . . . . 8 1.4.1Security Associations and Registration . . . . . . . . . . . . 8 1.4.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 9 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 10 1.5.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 12 1.6.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 12 1.6.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 13 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 13 1.7.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 14 1.7.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 14 1.8 Multicast Communications . . . . . . . . . . . . . . . . . . . . 14 2 Terminology and Concepts 15 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . . . . 18 2.4 Identifying Security Associations . . . . . . . . . . . . . . . . 19 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21 3 ISAKMP Payloads 22 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 27 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 30 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 31 3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 32 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 33 3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 35 3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 37 3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 38 3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 40 3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.16Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 43 4 ISAKMP Exchanges 45 Maughan, Schertler, Schneider, Turner ISAKMP [Page 3] INTERNET-DRAFT ISAKMP March 10, 1998 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 45 4.1.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2 Security Association Establishment . . . . . . . . . . . . . . . 46 4.2.1Security Association Establishment Examples . . . . . . . . . 48 4.3 Security Association Modification . . . . . . . . . . . . . . . . 50 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 52 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 53 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 54 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 56 5 ISAKMP Payload Processing 56 5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 57 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 57 5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 59 5.4 Security Association Payload Processing . . . . . . . . . . . . . 60 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . . . . 62 5.6 Transform Payload Processing . . . . . . . . . . . . . . . . . . 63 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 64 5.8 Identification Payload Processing . . . . . . . . . . . . . . . . 65 5.9 Certificate Payload Processing . . . . . . . . . . . . . . . . . 66 5.10Certificate Request Payload Processing . . . . . . . . . . . . . 67 5.11Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 68 5.12Signature Payload Processing . . . . . . . . . . . . . . . . . . 69 5.13Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 70 5.14Notification Payload Processing . . . . . . . . . . . . . . . . . 71 5.15Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 73 6 Conclusions 75 A ISAKMP Security Association Attributes 76 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 76 A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . . . . 76 A.3 Supported Security Protocols . . . . . . . . . . . . . . . . . . 76 A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . . . . 77 A.4.1ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.4.2ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 A.4.3ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.4.4ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 B Defining a new Domain of Interpretation 78 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 79 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 79 B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 79 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 79 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 79 Maughan, Schertler, Schneider, Turner ISAKMP [Page 4] INTERNET-DRAFT ISAKMP March 10, 1998 List of Figures 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 17 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 23 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 27 5 Security Association Payload . . . . . . . . . . . . . . . . . . 28 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 29 7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 30 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 32 9 Identification Payload Format . . . . . . . . . . . . . . . . . . 33 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 34 11 Certificate Request Payload Format . . . . . . . . . . . . . . . 35 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 36 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 37 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 38 15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 39 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 42 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . 44 Maughan, Schertler, Schneider, Turner ISAKMP [Page 5] INTERNET-DRAFT ISAKMP March 10, 1998 1 Introduction This document describes an Internet Security Association and Key Manage- ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- tication, key management, and security associations to establish the re- quired security for government, commercial, and private communications on the Internet. The Internet Security Association and Key Management Protocol (ISAKMP) de- fines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). SAs contain all the information re- quired for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsula- tion), transport or application layer services, or self-protection of ne- gotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism. ISAKMP is distinct from key exchange protocols in order to cleanly sepa- rate the details of security association management (and key management) from the details of key exchange. There may be many different key ex- change protocols, each with different security properties. However, a common framework is required for agreeing to the format of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP serves as this common framework. Separating the functionality into three parts adds complexity to the se- curity analysis of a complete ISAKMP implementation. However, the sep- aration is critical for interoperability between systems with differing security requirements, and should also simplify the analysis of further evolution of a ISAKMP server. ISAKMP is intended to support the negotiation of SAs for security proto- cols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, etc.). By centralizing the management of the security associations, ISAKMP reduces the amount of duplicated functionality within each security protocol. ISAKMP can also reduce connection setup time, by negotiating a whole stack of services at once. The remainder of section 1 establishes the motivation for security nego- tiation and outlines the major components of ISAKMP, i.e. Security As- sociations and Management, Authentication, Public Key Cryptography, and Miscellaneous items. Section 2 presents the terminology and concepts as- sociated with ISAKMP. Section 3 describes the different ISAKMP payload formats. Section 4 describes how the payloads of ISAKMP are composed to- gether as exchange types to establish security associations and perform key exchanges in an authenticated manner. Additionally, security as- sociation modification, deletion, and error notification are discussed. Section 5 describes the processing of each payload within the context of Maughan, Schertler, Schneider, Turner ISAKMP [Page 6] INTERNET-DRAFT ISAKMP March 10, 1998 ISAKMP exchanges, including error handling and associated actions. The appendices provide the attribute values necessary for ISAKMP and require- ment for defining a new Domain of Interpretation (DOI) within ISAKMP. 1.1 Requirements Terminology 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]. 1.2 The Need for Negotiation ISAKMP extends the assertion in [DOW92] that authentication and key ex- changes must be combined for better security to include security associa- tion exchanges. The security services required for communications depends on the individual network configurations and environments. Organizations are setting up Virtual Private Networks (VPN), also known as Intranets, that will require one set of security functions for communications within the VPN and possibly many different security functions for communications outside the VPN to support geographically separate organizational compo- nents, customers, suppliers, sub-contractors (with their own VPNs), gov- ernment, and others. Departments within large organizations may require a number of security associations to separate and protect data (e.g. per- sonnel data, company proprietary data, medical) on internal networks and other security associations to communicate within the same department. Nomadic users wanting to ``phone home'' represent another set of secu- rity requirements. These requirements must be tempered with bandwidth challenges. Smaller groups of people may meet their security require- ments by setting up ``Webs of Trust''. ISAKMP exchanges provide these assorted networking communities the ability to present peers with the se- curity functionality that the user supports in an authenticated and pro- tected manner for agreement upon a common set of security attributes, i.e. an interoperable security association. 1.3 What can be Negotiated? Security associations must support different encryption algorithms, au- thentication mechanisms, and key establishment algorithms for other secu- rity protocols, as well as IP Security. Security associations must also support host-oriented certificates for lower layer protocols and user- oriented certificates for higher level protocols. Algorithm and mecha- nism independence is required in applications such as e-mail, remote lo- gin, and file transfer, as well as in session oriented protocols, routing protocols, and link layer protocols. ISAKMP provides a common security Maughan, Schertler, Schneider, Turner ISAKMP [Page 7] INTERNET-DRAFT ISAKMP March 10, 1998 association and key establishment protocol for this wide range of security protocols, applications, security requirements, and network environments. ISAKMP is not bound to any specific cryptographic algorithm, key gener- ation technique, or security mechanism. This flexibility is beneficial for a number of reasons. First, it supports the dynamic communications environment described above. Second, the independence from specific secu- rity mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are devel- oped or new attacks against current encryption algorithms, authentica- tion mechanisms and key exchanges are discovered, ISAKMP will allow the updating of the algorithms and mechanisms without having to develop a com- pletely new KMP or patch the current one. ISAKMP has basic requirements for its authentication and key exchange com- ponents. These requirements guard against denial of service, replay / re- flection, man-in-the-middle, and connection hijacking attacks. This is important because these are the types of attacks that are targeted against protocols. Complete Security Association (SA) support, which provides mechanism and algorithm independence, and protection from protocol threats are the strengths of ISAKMP. 1.4 Security Associations and Management A Security Association (SA) is a relationship between two or more entities that describes how the entities will utilize security services to communi- cate securely. This relationship is represented by a set of information that can be considered a contract between the entities. The information must be agreed upon and shared between all the entities. Sometimes the information alone is referred to as an SA, but this is just a physical in- stantiation of the existing relationship. The existence of this relation- ship, represented by the information, is what provides the agreed upon se- curity information needed by entities to securely interoperate. All enti- ties must adhere to the SA for secure communications to be possible. When accessing SA attributes, entities use a pointer or identifier refered to as the Security Parameter Index (SPI). [RFC-1825] provides details on IP Security Associations (SA) and Security Parameter Index (SPI) definitions. 1.4.1 Security Associations and Registration The SA attributes required and recommended for the IP Security (AH, ESP) are defined in [RFC-1825]. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent secu- rity MUST define their requirements for SA attributes. The separation of ISAKMP from a specific SA definition is important to ensure ISAKMP can es- Maughan, Schertler, Schneider, Turner ISAKMP [Page 8] INTERNET-DRAFT ISAKMP March 10, 1998 tablish SAs for all possible security protocols and applications. NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- ered when defining a security protocol or application. In order to facilitate easy identification of specific attributes (e.g. a specific encryption algorithm) among different network entites the at- tributes must be assigned identifiers and these identifiers must be reg- istered by a central authority. The Internet Assigned Numbers Authority (IANA) provides this function for the Internet. 1.4.2 ISAKMP Requirements Security Association (SA) establishment MUST be part of the key manage- ment protocol defined for IP based networks. The SA concept is required to support security protocols in a diverse and dynamic networking envi- ronment. Just as authentication and key exchange must be linked to pro- vide assurance that the key is established with the authenticated party [DOW92], SA establishment must be linked with the authentication and the key exchange protocol. ISAKMP provides the protocol exchanges to establish a security association between negotiating entities followed by the establishment of a security association by these negotiating entities in behalf of some protocol (e.g. ESP/AH). First, an initial protocol exchange allows a basic set of secu- rity attributes to be agreed upon. This basic set provides protection for subsequent ISAKMP exchanges. It also indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol. If a basic set of security attributes is already in place between the ne- gotiating server entities, the initial ISAKMP exchange may be skipped and the establishment of a security association can be done directly. After the basic set of security attributes has been agreed upon, initial iden- tity authenticated, and required keys generated, the established SA can be used for subsequent communications by the entity that invoked ISAKMP. The basic set of SA attributes that MUST be implemented to provide ISAKMP interoperability are defined in Appendix A. 1.5 Authentication A very important step in establishing secure network communications is au- thentication of the entity at the other end of the communication. Many authentication mechanisms are available. Authentication mechanisms fall into two catagories of strength - weak and strong. Sending cleartext keys or other unprotected authenticating information over a network is weak, due to the threat of reading them with a network sniffer. Additionally, sending one-way hashed poorly-chosen keys with low entropy is also weak, due to the threat of brute-force guessing attacks on the sniffed mes- Maughan, Schertler, Schneider, Turner ISAKMP [Page 9] INTERNET-DRAFT ISAKMP March 10, 1998 sages. While passwords can be used for establishing identity, they are not considered in this context because of recent statements from the In- ternet Architecture Board [IAB]. Digital signatures, such as the Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are public key based strong authentication mechanisms. When using pub- lic key digital signatures each entity requires a public key and a pri- vate key. Certificates are an essential part of a digital signature au- thentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or application) to its public keys and pos- sibly other security-related information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a trusted third party or certificate authority to create, sign and properly distribute certificates. For more detailed information on digital signa- tures, such as DSS and RSA, and certificates see [Schneier]. 1.5.1 Certificate Authorities Certificates require an infrastructure for generation, verification, re- vocation, management and distribution. The Internet Policy Registration Authority (IPRA) [RFC-1422] has been established to direct this infras- tructure for the IETF. The IPRA certifies Policy Certification Authori- ties (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [DNSSEC] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide X.509 certificates to users. The U.S. Post Office is devel- oping a (CA) hierarchy. The NIST Public Key Infrastructure Working Group has also been doing work in this area. The DOD Multi Level Information System Security Initiative (MISSI) program has begun deploying a certifi- cate infrastructure for the U.S. Government. Alternatively, if no infras- tructure exists, the PGP Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other. 1.5.2 Entity Naming An entity's name is its identity and is bound to its public keys in cer- tificates. The CA MUST define the naming semantics for the certificates it issues. See the UNINETT PCA Policy Statements [Berge] for an example of how a CA defines its naming policy. When the certificate is verified, the name is verified and that name will have meaning within the realm of that CA. An example is the DNS security extensions which make DNS servers CAs for the zones and nodes they serve. Resource records are provided for public keys and signatures on those keys. The names associated with the keys are IP addresses and domain names which have meaning to entities ac- Maughan, Schertler, Schneider, Turner ISAKMP [Page 10] INTERNET-DRAFT ISAKMP March 10, 1998 cessing the DNS for this information. A Web of Trust is another example. When webs of trust are set up, names are bound with the public keys. In PGP the name is usually the entity's e-mail address which has meaning to those, and only those, who understand e-mail. Another web of trust could use an entirely different naming scheme. 1.5.3 ISAKMP Requirements Strong authentication MUST be provided on ISAKMP exchanges. Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect. Without authentication you are unable to trust an entity's identification, which makes access control questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will protect subsequent communications from passive eavesdroppers, without au- thentication it is possible that the SA and key may have been established with an adversary who performed an active man-in-the-middle attack and is now stealing all your personal data. A digital signature algorithm MUST be used within ISAKMP's authentication component. However, ISAKMP does not mandate a specific signature algo- rithm or certificate authority (CA). ISAKMP allows an entity initiating communications to indicate which CAs it supports. After selection of a CA, the protocol provides the messages required to support the actual au- thentication exchange. The protocol provides a facility for identifica- tion of different certificate authorities, certificate types (e.g. X.509, PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certifi- cates identified. ISAKMP utilizes digital signatures, based on public key cryptography, for authentication. There are other strong authentication systems available, which could be specified as additional optional authentication mechanisms for ISAKMP. Some of these authentication systems rely on a trusted third party called a key distribution center (KDC) to distribute secret session keys. An example is Kerberos, where the trusted third party is the Ker- beros server, which holds secret keys for all clients and servers within its network domain. A client's proof that it holds its secret key pro- vides authenticaton to a server. The ISAKMP specification does not specify the protocol for communicating with the trusted third parties (TTP) or certificate directory services. These protocols are defined by the TTP and directory service themselves and are outside the scope of this specification. The use of these addi- tional services and protocols will be described in a Key Exchange specific document. Maughan, Schertler, Schneider, Turner ISAKMP [Page 11] INTERNET-DRAFT ISAKMP March 10, 1998 1.6 Public Key Cryptography Public key cryptography is the most flexible, scalable, and efficient way for users to obtain the shared secrets and session keys needed to support the large number of ways Internet users will interoperate. Many key gen- eration algorithms, that have different properties, are available to users (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection. NOTE: Cryptographic keys can protect information for a considerable length of time. However, this is based on the assumption that keys used for pro- tection of communications are destroyed after use and not kept for any reason. 1.6.1 Key Exchange Properties Key Establishment (Key Generation / Key Transport): The two common methods of using public key cryptography for key establishment are key transport and key generation. An example of key transport is the use of the RSA al- gorithm to encrypt a randomly generated session key (for encrypting subse- quent communications) with the recipient's public key. The encrypted ran- dom key is then sent to the recipient, who decrypts it using his private key. At this point both sides have the same session key, however it was created based on input from only one side of the communications. The ben- efit of the key transport method is that it has less computational over- head than the following method. The Diffie-Hellman (D-H) algorithm il- lustrates key generation using public key cryptography. The D-H algorithm is begun by two users exchanging public information. Each user then math- ematically combines the other's public information along with their own secret information to compute a shared secret value. This secret value can be used as a session key or as a key encryption key for encrypting a randomly generated session key. This method generates a session key based on public and secret information held by both users. The benefit of the D-H algorithm is that the key used for encrypting messages is based on information held by both users and the independence of keys from one key exchange to another provides perfect forward secrecy. Detailed descrip- tions of these algorithms can be found in [Schneier]. There are a number of variations on these two key generation schemes and these variations do not necessarily interoperate. Key Exchange Authentication: Key exchanges may be authenticated during the protocol or after protocol completion. Authentication of the key exchange during the protocol is provided when each party provides proof it has the secret session key before the end of the protocol. Proof can be provided by encrypting known data in the secret session key during the protocol ex- change. Authentication after the protocol must occur in subsequent commu- Maughan, Schertler, Schneider, Turner ISAKMP [Page 12] INTERNET-DRAFT ISAKMP March 10, 1998 nications. Authentication during the protocol is preferred so subsequent communications are not initiated if the secret session key is not estab- lished with the desired party. Key Exchange Symmetry: A key exchange provides symmetry if either party can initiate the exchange and exchanged messages can cross in transit without affecting the key that is generated. This is desirable so that computation of the keys does not require either party to know who initi- ated the exchange. While key exchange symmetry is desirable, symmetry in the entire key management protocol may provide a vulnerablity to reflec- tion attacks. Perfect Forward Secrecy: As described in [DOW92], an authenticated key ex- change protocol provides perfect forward secrecy if disclosure of long- term secret keying material does not compromise the secrecy of the ex- changed keys from previous communications. The property of perfect for- ward secrecy does not apply to key exchange without authentication. 1.6.2 ISAKMP Requirements An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD choose additional key establishment algorithms based on their require- ments. ISAKMP does not specify a specific key exchange. However, [IKE] describes a proposal for using the Oakley key exchange [Oakley] in con- junction with ISAKMP. Requirements that should be evaluated when choosing a key establishment algorithm include establishment method (generation vs. transport), perfect forward secrecy, computational overhead, key escrow, and key strength. Based on user requirements, ISAKMP allows an entity initiating communications to indicate which key exchanges it supports. After selection of a key exchange, the protocol provides the messages re- quired to support the actual key establishment. 1.7 ISAKMP Protection 1.7.1 Anti-Clogging (Denial of Service) Of the numerous security services available, protection against denial of service always seems to be one of the most difficult to address. A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the com- puting resources from attack without spending excessive CPU resources to determine its authenticity. An exchange prior to CPU-intensive public key operations can thwart some denial of service attempts (e.g. simple flood- ing with bogus IP source addresses). Absolute protection against denial of service is impossible, but this anti-clogging token provides a tech- Maughan, Schertler, Schneider, Turner ISAKMP [Page 13] INTERNET-DRAFT ISAKMP March 10, 1998 nique for making it easier to handle. The use of an anti-clogging token was introduced by Karn and Simpson in [Karn]. It should be noted that in the exchanges shown in section 4, the anti- clogging mechanism should be used in conjuction with a garbage-state col- lection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti-clogging only phase, as was done in [Karn]. 1.7.2 Connection Hijacking ISAKMP prevents connection hijacking by linking the authentication, key exchange and security association exchanges. This linking prevents an attacker from allowing the authentication to complete and then jumping in and impersonating one entity to the other during the key and security association exchanges. 1.7.3 Man-in-the-Middle Attacks Man-in-the-Middle attacks include interception, insertion, deletion, and modification of messages, reflecting messages back at the sender, re- playing old messages and redirecting messages. ISAKMP features prevent these types of attacks from being successful. The linking of the ISAKMP exchanges prevents the insertion of messages in the protocol exchange. The ISAKMP protocol state machine is defined so deleted messages will not cause a partial SA to be created, the state machine will clear all state and return to idle. The state machine also prevents reflection of a mes- sage from causing harm. The requirement for a new cookie with time vari- ant material for each new SA establishment prevents attacks that involve replaying old messages. The ISAKMP strong authentication requirement pre- vents an SA from being established with anyone other than the intended party. Messages may be redirected to a different destination or modified but this will be detected and an SA will not be established. The ISAKMP specification defines where abnormal processing has occurred and recom- mends notifying the appropriate party of this abnormality. 1.8 Multicast Communications It is expected that multicast communications will require the same secu- rity services as unicast communications and may introduce the need for additional security services. The issues of distributing SPIs for mul- ticast traffic are presented in [RFC-1825]. Multicast security issues are also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will Maughan, Schertler, Schneider, Turner ISAKMP [Page 14] INTERNET-DRAFT ISAKMP March 10, 1998 support multicast key distribution. For an introduction to the issues re- lated to multicast security, consult the Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's research in this area. 2 Terminology and Concepts 2.1 ISAKMP Terminology Security Protocol: A Security Protocol consists of an entity at a single point in the network stack, performing a security service for network com- munication. For example, IPSEC ESP and IPSEC AH are two different secu- rity protocols. TLS is another example. Security Protocols may perform more than one service, for example providing integrity and confidentiality in one module. Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a pro- tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security pro- tocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole. Security Association (SA): A Security Association is a security-protocol- specific set of parameters that completely defines the services and mech- anisms necessary to protect traffic at that security protocol location. These parameters can include algorithm identifiers, modes, cryptographic keys, etc. The SA is referred to by its associated security protocol (for example, ``ISAKMP SA'', ``ESP SA'', ``TLS SA''). ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs. Security Parameter Index (SPI): An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. The uniqueness of the SPI is implementation dependent, but could be based per system, per protocol, or other options. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. The DOI will also determine which SPIs (i.e. initiator's or re- sponder's) are sent during communication. Maughan, Schertler, Schneider, Turner ISAKMP [Page 15] INTERNET-DRAFT ISAKMP March 10, 1998 Domain of Interpretation: A Domain of Interpretation (DOI) defines payload formats, exchange types, and conventions for naming security-relevant in- formation such as security policies or cryptographic algorithms and modes. A Domain of Interpretation (DOI) identifier is used to interpret the pay- loads of ISAKMP payloads. A system SHOULD support multiple Domains of In- terpretation simultaneously. The concept of a DOI is based on previous work by the TSIG CIPSO Working Group, but extends beyond security label interpretation to include naming and interpretation of security services. A DOI defines: o A ``situation'': the set of information that will be used to determine the required security services. o The set of security policies that must, and may, be supported. o A syntax for the specification of proposed security services. o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities. o The specific formats of the various payload contents. o Additional exchange types, if required. The rules for the IETF IP Security DOI are presented in [IPDOI]. Speci- fications of the rules for customized DOIs will be presented in separate documents. Situation: A situation contains all of the security-relevant information that a system considers necessary to decide the security services required to protect the session being negotiated. The situation may include ad- dresses, security classifications, modes of operation (normal vs. emer- gency), etc. Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable to protect traffic under a given situation. Payload: ISAKMP defines several types of payloads, which are used to transfer information such as security association data, or key exchange data, in DOI-defined formats. A payload consists of a generic payload header and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and interpret these payloads. Mul- tiple payloads can be sent in a single ISAKMP message. See section 3 for more details on the payload types, and [IPDOI] for the formats of the IETF Maughan, Schertler, Schneider, Turner ISAKMP [Page 16] INTERNET-DRAFT ISAKMP March 10, 1998 IP Security DOI payloads. Exchange Type: An exchange type is a specification of the number of mes- sages in an ISAKMP exchange, and the payload types that are contained in each of those messages. Each exchange type is designed to provide a par- ticular set of security services, such as anonymity of the participants, perfect forward secrecy of the keying material, authentication of the par- ticipants, etc. Section 4.1 defines the default set of ISAKMP exchange types. Other exchange types can be added to support additional key ex- changes, if required. 2.2 ISAKMP Placement Figure 1 is a high level view of the placement of ISAKMP within a system context in a network architecture. An important part of negotiating secu- rity services is to consider the entire ``stack'' of individual SAs as a unit. This is referred to as a ``protection suite''. +------------+ +--------+ +--------------+ ! DOI ! ! ! ! Application ! ! Definition ! <----> ! ISAKMP ! ! Process ! +------------+ --> ! ! !--------------! +--------------+ ! +--------+ ! Appl Protocol! ! Key Exchange ! ! ^ ^ +--------------+ ! Definition !<-- ! ! ^ +--------------+ ! ! ! ! ! ! !----------------! ! ! v ! ! +-------+ v v ! API ! +---------------------------------------------+ +-------+ ! Socket Layer ! ! !---------------------------------------------! v ! Transport Protocol (TCP / UDP) ! +----------+ !---------------------------------------------! ! Security ! <----> ! IP ! ! Protocol ! !---------------------------------------------! +----------+ ! Link Layer Protocol ! +---------------------------------------------+ Figure 1: ISAKMP Relationships Maughan, Schertler, Schneider, Turner ISAKMP [Page 17] INTERNET-DRAFT ISAKMP March 10, 1998 2.3 Negotiation Phases ISAKMP offers two ``phases'' of negotiation. In the first phase, two en- tities (e.g. ISAKMP servers) agree on how to protect further negotiation traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to protect the negotiations for the Protocol SA being requested. Two entities (e.g. ISAKMP servers) can negotiate (and have active) multi- ple ISAKMP SAs. The second phase of negotiation is used to establish security associations for other security protocols. This second phase can be used to estab- lish many security associations. The security associations established by ISAKMP during this phase can be used by a security protocol to protect many message/data exchanges. While the two-phased approach has a higher start-up cost for most simple scenarios, there are several reasons that it is beneficial for most cases. First, entities (e.g. ISAKMP servers) can amortize the cost of the first phase across several second phase negotiations. This allows multiple SAs to be established between peers over time without having to start over for each communication. Second, security services negotiated during the first phase provide secu- rity properties for the second phase. For example, after the first phase of negotiation, the encryption provided by the ISAKMP SA can provide iden- tity protection, potentially allowing the use of simpler second-phase ex- changes. On the other hand, if the channel established during the first phase is not adequate to protect identities, then the second phase must negotiate adequate security mechanisms. Third, having an ISAKMP SA in place considerably reduces the cost of ISAKMP management activity - without the ``trusted path'' that an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have to go through a complete re-authentication for each error notification or deletion of an SA. Negotiation during each phase is accomplished using ISAKMP-defined ex- changes (see section 4) or exchanges defined for a key exchange within a DOI. Note that security services may be applied differently in each negotiation phase. For example, different parties are being authenticated during each of the phases of negotiation. During the first phase, the parties being authenticated may be the ISAKMP servers/hosts, while during the second phase, users or application level programs are being authenticated. Maughan, Schertler, Schneider, Turner ISAKMP [Page 18] INTERNET-DRAFT ISAKMP March 10, 1998 2.4 Identifying Security Associations While bootstrapping secure channels between systems, ISAKMP cannot assume the existence of security services, and must provide some protections for itself. Therefore, ISAKMP considers an ISAKMP Security Association to be different than other types, and manages ISAKMP SAs itself, in their own name space. ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI field in the Proposal payload are used during SA establishment to identify the SA for other security protocols. The interpretation of these four fields is dependent on the operation taking place. The following table shows the presence or absence of several fields during SA establishment. The following fields are necessary for various opera- tions associated with SA establishment: cookies in the ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in the Proposal payload. An 'X' in the column means the value MUST be present. An 'NA' in the col- umn means a value in the column is Not Applicable to the operation. __#_____________Operation____________I-Cookie__R-Cookie__Message_ID__SPI_ (1) Start ISAKMP SA negotiation X 0 0 0 (2) Respond ISAKMP SA negotiation X X 0 0 (3) Init other SA negotiation X X X X (4) Respond other SA negotiation X X X X (5) Other (KE, ID, etc.) X X X/0 NA (6) Security Protocol (ESP, AH) NA NA NA X In the first line (1) of the table, the initiator includes the Initiator Cookie field in the ISAKMP Header, using the procedures outlined in sec- tions 2.5.3 and 3.1. In the second line (2) of the table, the responder includes the Initia- tor and Responder Cookie fields in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged between ISAKMP peers, depending on the ISAKMP exchange type used during the phase 1 negotiation. Once the phase 1 exchange is completed, the Ini- tiator and Responder cookies are included in the ISAKMP Header of all sub- sequent communications between the ISAKMP peers. During phase 1 negotiations, the initiator and responder cookies deter- mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie. In the third line (3) of the table, the initiator associates a Message ID with the Protocols contained in the SA Proposal. This Message ID and the initiator's SPI(s) to be associated with each protocol in the Proposal are Maughan, Schertler, Schneider, Turner ISAKMP [Page 19] INTERNET-DRAFT ISAKMP March 10, 1998 sent to the responder. The SPI(s) will be used by the security protocols once the phase 2 negotiation is completed. In the fourth line (4) of the table, the responder includes the same Mes- sage ID and the responder's SPI(s) to be associated with each protocol in the accepted Proposal. This information is returned to the initiator. In the fifth line (5) of the table, the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in-progress protocol negotiation. This is only applicable for a phase 2 exchange and the value SHOULD be 0 for a phase 1 exchange because the combined cook- ies identify the ISAKMP SA. The SPI field in the Proposal payload is not applicable because the Proposal payload is only used during the SA negoti- ation message exchange (steps 3 and 4). In the sixth line (6) of the table, the phase 2 negotiation is complete. The security protocols use the SPI(s) to determine which security services and mechanisms to apply to the communication between them. The SPI value shown in the sixth line (6) is not the SPI field in the Proposal payload, but the SPI field contained within the security protocol header. During the SA establishment, a SPI MUST be generated. ISAKMP is designed to handle variable sized SPIs. This is accomplished by using the SPI Size field within the Proposal payload during SA establishment. Handling of SPIs will be outlined by the DOI specification (e.g. [IPDOI]). When a security association (SA) is initially established, one side as- sumes the role of initiator and the other the role of responder. Once the SA is established, both the original initiator and responder can initiate a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirec- tional in nature. Additionally, ISAKMP allows both initiator and responder to have some con- trol during the negotiation process. While ISAKMP is designed to allow an SA negotiation that includes multiple proposals, the initiator can main- tain some control by only making one proposal in accordance with the ini- tiator's local security policy. Once the initiator sends a proposal con- taining more than one proposal (which are sent in decreasing preference order), the initiator relinquishes control to the responder. Once the re- sponder is controlling the SA establishment, the responder can make its policy take precedence over the initiator within the context of the multi- ple options offered by the initiator. This is accomplished by selecting the proposal best suited for the responder's local security policy and re- turning this selection to the initiator. Maughan, Schertler, Schneider, Turner ISAKMP [Page 20] INTERNET-DRAFT ISAKMP March 10, 1998 2.5 Miscellaneous 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP us- ing the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbered Authority (IANA). Im- plementations MAY additionally support ISAKMP over other transport proto- cols or over IP itself. 2.5.2 RESERVED Fields The existence of RESERVED fields within ISAKMP payloads are used strictly to preserve byte alignment. All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value and discard the packet if other values are found. 2.5.3 Anti-Clogging Token (``Cookie'') Creation The details of cookie generation are implementation dependent, but MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]): 1. The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with Diffie- Hellman requests from randomly chosen IP addresses or ports. 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie. 3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources. Karn's suggested method for creating the cookie is to perform a fast hash (e.g. MD5) over the IP Source and Destination Address, the UDP Source and Destination Ports and a locally generated secret random value. ISAKMP re- Maughan, Schertler, Schneider, Turner ISAKMP [Page 21] INTERNET-DRAFT ISAKMP March 10, 1998 quires that the cookie be unique for each SA establishment to help pre- vent replay attacks, therefore, the date and time MUST be added to the in- formation hashed. The generated cookies are placed in the ISAKMP Header (described in section 3.1) Initiator and Responder cookie fields. These fields are 8 octets in length, thus, requiring a generated cookie to be 8 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are uni-directional transmissions and are done under the protection of an ex- isting ISAKMP SA, thus, not requiring the generation of a new cookie. One exception to this is the transmission of a Notify message during a Phase 1 exchange, prior to completing the establishment of an SA. Sections 3.14 and 4.8 provide additional details. 3 ISAKMP Payloads ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- changes (see Section 4) are shown using network octet ordering. Addition- ally, all ISAKMP messages MUST be aligned at 4-octet multiples. 3.1 ISAKMP Header Format An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, pro- viding the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks. The ISAKMP Header fields are defined as follows: o Initiator Cookie (8 octets) - Cookie of entity that initiated SA establishment, SA notification, or SA deletion. o Responder Cookie (8 octets) - Cookie of entity that is responding to Maughan, Schertler, Schneider, Turner ISAKMP [Page 22] INTERNET-DRAFT ISAKMP March 10, 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ISAKMP Header Format an SA establishment request, SA notification, or SA deletion. o Next Payload (1 octet) - Indicates the type of the first payload in the message. The format for each payload is defined in sections 3.4 through 3.16. The processing for the payloads is defined in section 5. _____Next_Payload_Type_______Value____ NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14 - 127 Private USE 128 - 255 o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations Maughan, Schertler, Schneider, Turner ISAKMP [Page 23] INTERNET-DRAFT ISAKMP March 10, 1998 based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than its own. o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical. o Exchange Type (1 octet) - indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges. ____Exchange_Type______Value___ NONE 0 Base 1 Identity Protection 2 Authentication Only 3 Aggressive 4 Informational 5 ISAKMP Future Use 6 - 31 DOI Specific Use 32 - 255 o Flags (1 octet) - indicates specific options that are set for the ISAKMP exchange. The flags listed below are specified in the Flags field beginning with the least significant bit, i.e the Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags field, and the Authentication Only bit is bit 2 of the Flags field. The remaining bits of the Flags field MUST be set to 0 prior to transmission. -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie. It is RECOMMENDED that encryption of communications be done as soon as possible between the peers. For all ISAKMP exchanges described in section 4.1, the encryption SHOULD begin after both parties have exchanged Key Exchange payloads. If the E(ncryption Bit) is not set (0), the payloads are not encrypted. -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Maughan, Schertler, Schneider, Turner ISAKMP [Page 24] INTERNET-DRAFT ISAKMP March 10, 1998 Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation. If set(1), the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the en- tity which set the Commit Bit. This indicates that the SA estab- lishment was successful and either entity can now proceed with en- crypted traffic communication. In addition to synchronizing key ex- change, the Commit Bit can be used to protect against loss of trans- missions over unreliable networks and guard against the need for mul- tiple retransmissions. NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negoti- ation message following a Phase 1 exchange or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the re- ceived message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final mes- sage. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established. -- A(uthentication Only Bit) (1 bit) - This bit is intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption (e.g. "emergency mode"). Section 4.8 states that a Phase 2 Informational Exchange MUST be sent under the protection of an ISAKMP SA. This is the only exception to that policy. If the Authentication Only bit is set (1), only authentication security services will be applied to the entire Notify payload of the Informational Exchange and the payload will not be encrypted. o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. o Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. Maughan, Schertler, Schneider, Turner ISAKMP [Page 25] INTERNET-DRAFT ISAKMP March 10, 1998 3.2 Generic Payload Header Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a generic header, shown in Figure 3, which provides a payload "chaining" capability and clearly defines the boundaries of a payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Generic Payload Header The Generic Payload Header fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. 3.3 Data Attributes There are several instances within ISAKMP where it is necessary to repre- sent Data Attributes. An example of this is the Security Association (SA) Attributes contained in the Transform payload (described in section 3.6). These Data Attributes are not an ISAKMP payload, but are contained within ISAKMP payloads. The format of the Data Attributes provides the flexibil- ity for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data At- tributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described below. Specific in- formation about the attributes for each domain will be described in a DOI document, e.g. IPSEC DOI [IPDOI]. The Data Attributes fields are defined as follows: o Attribute Type (2 octets) - Unique identifier for each type of attribute. These attributes are defined as part of the DOI-specific Maughan, Schertler, Schneider, Turner ISAKMP [Page 26] INTERNET-DRAFT ISAKMP March 10, 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Attribute Type ! AF=0 Attribute Length ! !F! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AF=0 Attribute Value . . AF=1 Not Transmitted . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Data Attributes information. The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form. o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present. o Attribute Value (variable length) - Value of the attribute associated with the DOI-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. 3.4 Security Association Payload The Security Association Payload is used to negotiate security attributes and to indicate the Domain of Interpretation (DOI) and Situation under which the negotiation is taking place. Figure 5 shows the format of the Security Association payload. The Security Association Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field MUST NOT contain the values for the Proposal or Transform payloads as they are considered part of the security association negotiation. For example, this Maughan, Schertler, Schneider, Turner ISAKMP [Page 27] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Security Association Payload field would contain the value "10" (Nonce payload) in the first message of a Base Exchange (see Section 4.4) and the value "0" in the first message of an Identity Protect Exchange (see Section 4.5). o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this negotiation is taking place. The DOI is a 32-bit unsigned integer. A DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be used for any protocol during the Phase 2 exchange. The necessary SA Attributes are defined in A.4. A DOI value of 1 is assigned to the IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for future use. IANA will not normally assign a DOI value without referencing some public specification, such as an Internet RFC. Other DOI's can be defined using the description in appendix B. This field MUST be present within the Security Association payload. o Situation (variable length) - A DOI-specific field that identifies the situation under which this negotiation is taking place. The Situation is used to make policy decisions regarding the security attributes being negotiated. Specifics for the IETF IP Security DOI Situation are detailed in [IPDOI]. This field MUST be present within the Security Association payload. The payload type for the Security Association Payload is one (1). Maughan, Schertler, Schneider, Turner ISAKMP [Page 28] INTERNET-DRAFT ISAKMP March 10, 1998 3.5 Proposal Payload The Proposal Payload contains information used during Security Associa- tion negotiation. The proposal consists of security mechanisms, or trans- forms, to be used to secure the communications channel. Figure 6 shows the format of the Proposal Payload. A description of its use can be found in section 4.2. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (variable) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Proposal Payload Format The Proposal Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "2" or "0". If there are additional Proposal payloads in the message, then this field will be 2. If the current Proposal payload is the last within the security association proposal, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including generic payload header, the Proposal payload, and all Transform payloads associated with this proposal. In the event there are multiple proposals with the same proposal number (see section 4.2), the Payload Length field only applies to the current Proposal payload and not to all Proposal payloads. o Proposal # (1 octet) - Identifies the Proposal number for the current payload. A description of the use of this field is found in section 4.2. o Protocol-Id (1 octet) - Specifies the protocol identifier for the current negotiation. Examples might include IPSEC ESP, IPSEC AH, OSPF, TLS, etc. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Maughan, Schertler, Schneider, Turner ISAKMP [Page 29] INTERNET-DRAFT ISAKMP March 10, 1998 Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. If the SPI Size is not a multiple of 4 octets it will have some impact on the SPI field and the alignment of all payloads in the message. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. o # of Transforms (1 octet) - Specifies the number of transforms for the Proposal. Each of these is contained in a Transform payload. o SPI (variable) - The sending entity's SPI. In the event the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload, however, it can be applied at the end of the message. The payload type for the Proposal Payload is two (2). 3.6 Transform Payload The Transform Payload contains information used during Security Associa- tion negotiation. The Transform payload consists of a specific security mechanism, or transforms, to be used to secure the communications chan- nel. The Transform payload also contains the security association at- tributes associated with the specific transform. These SA attributes are DOI-specific. Figure 7 shows the format of the Transform Payload. A de- scription of its use can be found in section 4.2. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform # ! Transform-Id ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ SA Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Transform Payload Format The Transform Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next Maughan, Schertler, Schneider, Turner ISAKMP [Page 30] INTERNET-DRAFT ISAKMP March 10, 1998 payload in the message. This field MUST only contain the value "3" or "0". If there are additional Transform payloads in the proposal, then this field will be 3. If the current Transform payload is the last within the proposal, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes. o Transform # (1 octet) - Identifies the Transform number for the current payload. If there is more than one transform proposed for a specific protocol within the Proposal payload, then each Transform payload has a unique Transform number. A description of the use of this field is found in section 4.2. o Transform-Id (1 octet) - Specifies the Transform identifier for the protocol within the current proposal. These transforms are defined by the DOI and are dependent on the protocol being negotiated. o RESERVED2 (2 octets) - Unused, set to 0. o SA Attributes (variable length) - This field contains the security association attributes as defined for the transform given in the Transform-Id field. The SA Attributes SHOULD be represented using the Data Attributes format described in section 3.3. If the SA Attributes are not aligned on 4-byte boundaries, then subsequent payloads will not be aligned and any padding will be added at the end of the message to make the message 4-octet aligned. The payload type for the Transform Payload is three (3). 3.7 Key Exchange Payload The Key Exchange Payload supports a variety of key exchange techniques. Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload. The Key Exchange Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. Maughan, Schertler, Schneider, Turner ISAKMP [Page 31] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Exchange Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Key Exchange Payload Format o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Key Exchange Data (variable length) - Data required to generate a session key. The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm. This field may also contain pre-placed key indicators. The payload type for the Key Exchange Payload is four (4). 3.8 Identification Payload The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authen- ticity of information. Figure 9 shows the format of the Identification Payload. The Identification Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o ID Type (1 octet) - Specifies the type of Identification being used. Maughan, Schertler, Schneider, Turner ISAKMP [Page 32] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! DOI Specific ID Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Identification Payload Format This field is DOI-dependent. o DOI Specific ID Data (3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0. o Identification Data (variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by the ID Type field. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI]. The payload type for the Identification Payload is five (5). 3.9 Certificate Payload The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload. NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types. The Certificate Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the Maughan, Schertler, Schneider, Turner ISAKMP [Page 33] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Encoding ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Certificate Payload Format message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. _________Certificate_Type____________Value____ NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255 o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. The payload type for the Certificate Payload is six (6). Maughan, Schertler, Schneider, Turner ISAKMP [Page 34] INTERNET-DRAFT ISAKMP March 10, 1998 3.10 Certificate Request Payload The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory ser- vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- cates. The Certificate Request payload MUST be accepted at any point dur- ing the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert. Type ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Authority ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Certificate Request Payload Format The Certificate Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Certificate Type (1 octet) - Contains an encoding of the type of certificate requested. Acceptable values are listed in section 3.9. o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how Maughan, Schertler, Schneider, Turner ISAKMP [Page 35] INTERNET-DRAFT ISAKMP March 10, 1998 much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included. The payload type for the Certificate Request Payload is seven (7). 3.11 Hash Payload The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating en- tities. Figure 12 shows the format of the Hash Payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Hash Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Hash Payload Format The Hash Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Hash Data (variable length) - Data that results from applying the hash routine to the ISAKMP message and/or state. The payload type for the Hash Payload is eight (8). Maughan, Schertler, Schneider, Turner ISAKMP [Page 36] INTERNET-DRAFT ISAKMP March 10, 1998 3.12 Signature Payload The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non- repudiation services. Figure 13 shows the format of the Signature Pay- load. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Signature Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Signature Payload Format The Signature Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Signature Data (variable length) - Data that results from applying the digital signature function to the ISAKMP message and/or state. The payload type for the Signature Payload is nine (9). 3.13 Nonce Payload The Nonce Payload contains random data used to guarantee liveness dur- ing an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key ex- change, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a Maughan, Schertler, Schneider, Turner ISAKMP [Page 37] INTERNET-DRAFT ISAKMP March 10, 1998 separate payload. However, this is defined by the key exchange, not by ISAKMP. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Nonce Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Nonce Payload Format The Nonce Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Nonce Data (variable length) - Contains the random data generated by the transmitting entity. The payload type for the Nonce Payload is ten (10). 3.14 Notification Payload The Notification Payload can contain both ISAKMP and DOI-specific data and is used to transmit informational data, such as error conditions, to an ISAKMP peer. It is possible to send multiple Notification payloads in a single ISAKMP message. Figure 15 shows the format of the Notification Payload. Notification which occurs during, or is concerned with, a Phase 1 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected. Maughan, Schertler, Schneider, Turner ISAKMP [Page 38] INTERNET-DRAFT ISAKMP March 10, 1998 Notification which occurs during, or is concerned with, a Phase 2 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current nego- tiation. One example for this type of notification is to indicate why a proposal was rejected. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Notification Payload Format The Notification Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this notification is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. o Protocol-Id (1 octet) - Specifies the protocol identifier for the current notification. Examples might include ISAKMP, IPSEC ESP, IPSEC AH, OSPF, TLS, etc. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Maughan, Schertler, Schneider, Turner ISAKMP [Page 39] INTERNET-DRAFT ISAKMP March 10, 1998 Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. o Notify Message Type (2 octets) - Specifies the type of notification message (see section 3.14.1). Additional text, if specified by the DOI, is placed in the Notification Data field. o SPI (variable length) - Security Parameter Index. The receiving entity's SPI. The use of the SPI field is described in section 2.4. The length of this field is determined by the SPI Size field and is not necessarily aligned to a 4 octet boundary. o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are DOI-specific. The payload type for the Notification Payload is eleven (11). 3.14.1 Notify Message Types Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. For example, a secure front end or security gateway may use the Notify message to syn- chronize SA communication. The table below lists the Nofitication mes- sages and their corresponding values. Values in the Private Use range are expected to be DOI-specific values. Maughan, Schertler, Schneider, Turner ISAKMP [Page 40] INTERNET-DRAFT ISAKMP March 10, 1998 NOTIFY MESSAGES - ERROR TYPES __________Errors______________Value_____ INVALID-PAYLOAD-TYPE 1 DOI-NOT-SUPPORTED 2 SITUATION-NOT-SUPPORTED 3 INVALID-COOKIE 4 INVALID-MAJOR-VERSION 5 INVALID-MINOR-VERSION 6 INVALID-EXCHANGE-TYPE 7 INVALID-FLAGS 8 INVALID-MESSAGE-ID 9 INVALID-PROTOCOL-ID 10 INVALID-SPI 11 INVALID-TRANSFORM-ID 12 ATTRIBUTES-NOT-SUPPORTED 13 NO-PROPOSAL-CHOSEN 14 BAD-PROPOSAL-SYNTAX 15 PAYLOAD-MALFORMED 16 INVALID-KEY-INFORMATION 17 INVALID-ID-INFORMATION 18 INVALID-CERT-ENCODING 19 INVALID-CERTIFICATE 20 CERT-TYPE-UNSUPPORTED 21 INVALID-CERT-AUTHORITY 22 INVALID-HASH-INFORMATION 23 AUTHENTICATION-FAILED 24 INVALID-SIGNATURE 25 ADDRESS-NOTIFICATION 26 NOTIFY-SA-LIFETIME 27 CERTIFICATE-UNAVAILABLE 28 RESERVED (Future Use) 29 - 8191 Private Use 8192 - 16383 NOTIFY MESSAGES - STATUS TYPES _________Status_____________Value______ CONNECTED 16384 RESERVED (Future Use) 16385 - 24575 DOI-specific codes 24576 - 32767 Private Use 32768 - 40959 RESERVED (Future Use) 40960 - 65535 3.15 Delete Payload The Delete Payload contains a protocol-specific security association iden- tifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 16 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload, Maughan, Schertler, Schneider, Turner ISAKMP [Page 41] INTERNET-DRAFT ISAKMP March 10, 1998 however, each SPI MUST be for the same protocol. Mixing of Protocol Iden- tifiers MUST NOT be performed with the Delete payload. Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id of ISAKMP and the SPIs are the initiator and responder cookies from the ISAKMP Header. Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s). NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-Id ! SPI Size ! # of SPIs ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index(es) (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Delete Payload Format The Delete Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this deletion is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. o Protocol-Id (1 octet) - ISAKMP can establish security associations Maughan, Schertler, Schneider, Turner ISAKMP [Page 42] INTERNET-DRAFT ISAKMP March 10, 1998 for various protocols, including ISAKMP and IPSEC. This field identi- fies which security association database to apply the delete request. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted. o # of SPIs (2 octets) - The number of SPIs contained in the Delete payload. The size of each SPI is defined by the SPI Size field. o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. Values for this field are DOI and protocol specific. The length of this field is determined by the SPI Size and # of SPIs fields. The payload type for the Delete Payload is twelve (12). 3.16 Vendor ID Payload The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. This is not a general extension facility of ISAKMP. Figure 17 shows the format of the Vendor ID Payload. The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An imple- mentation is NOT REQUIRED to understand any Vendor ID payloads. An imple- mentation is NOT REQUIRED to send any Vendor ID payload at all. If a pri- vate payload was sent without prior agreement to send it, a compliant im- plementation may reject a proposal with a notify message of type INVALID- PAYLOAD-TYPE. If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negoti- ation. Reception of a familiar Vendor ID payload in the Phase 1 negotia- tion allows an implementation to make use of Private USE payload numbers (128-255), described in section 3.1 for vendor specific extensions during Phase 2 negotiations. The definition of "familiar" is left to implementa- tions to determine. Some vendors may wish to implement another vendor's extension prior to standardization. However, this practice SHOULD not be widespread and vendors should work towards standardization instead. The vendor defined constant MUST be unique. The choice of hash and text to hash is left to the vendor to decide. As an example, vendors could Maughan, Schertler, Schneider, Turner ISAKMP [Page 43] INTERNET-DRAFT ISAKMP March 10, 1998 generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product. A hash is used instead of a vendor registry to avoid local cryptographic policy problems with having a list of "approved" products, to keep away from maintaining a list of vendors, and to allow classified products to avoid having to appear on any list. For instance: "Example Company IPsec. Version 97.1" (not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include all of the hash, or just a portion of it, as the payload length will bound the data. There are no security implications of this hash, so its choice is arbitrary. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Vendor ID (VID) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Vendor ID Payload Format The Vendor ID Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Vendor ID (variable length) - Hash of the vendor string plus version (as described above). The payload type for the Vendor ID Payload is thirteen (13). Maughan, Schertler, Schneider, Turner ISAKMP [Page 44] INTERNET-DRAFT ISAKMP March 10, 1998 4 ISAKMP Exchanges ISAKMP supplies the basic syntax of a message exchange. The basic build- ing blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA establishment and SA mod- ification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these ad- ditions. 4.1 ISAKMP Exchange Types ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material. There are currently five default Ex- change Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers. Most exchanges will include all the basic payload types - SA, KE, ID, SIG - and may include others. The pri- mary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOM- MENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5. Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has hap- pened after each message exchange. None of the examples include any "op- tional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (con- taining initiator and responder cookies) which would provide protection against clogging (see section 2.5.3). The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI require- ments, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols. As discussed above, these exchange types can be used in either phase of Maughan, Schertler, Schneider, Turner ISAKMP [Page 45] INTERNET-DRAFT ISAKMP March 10, 1998 negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation. 4.1.1 Notation The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated pay- loads: HDR is an ISAKMP header whose exchange type defines the payload orderings SA is an SA negotiation payload with one or more Proposal and Transform payloads. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one. KE is the key exchange payload. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, or x can be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), for the user initiator and responder, respectively. HASH is the hash payload. SIG is the signature payload. The data to sign is exchange-specific. AUTH is a generic authentication mechanism, such as HASH or SIG. NONCE is the nonce payload. '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted. => signifies "initiator to responder" communication <= signifies "responder to initiator" communication 4.2 Security Association Establishment The Security Association, Proposal, and Transform payloads are used to build ISAKMP messages for the negotiation and establishment of SAs. An SA establishment message consists of a single SA payload followed by at least one, and possibly many, Proposal payloads and at least one, and pos- sibly many, Transform payloads associated with each Proposal payload. Be- cause these payloads are considered together, the SA payload will point to any following payloads and not to the Proposal payload included with the SA payload. The SA Payload contains the DOI and Situation for the pro- posed SA. Each Proposal payload contains a Security Parameter Index (SPI) and ensures that the SPI is associated with the Protocol-Id in accordance with the Internet Security Architecture [RFC-1825]. Proposal payloads may or may not have the same SPI, as this is implementation dependent. Each Maughan, Schertler, Schneider, Turner ISAKMP [Page 46] INTERNET-DRAFT ISAKMP March 10, 1998 Transform Payload contains the specific security mechanisms to be used for the designated protocol. It is expected that the Proposal and Transform payloads will be used only during SA establishment negotiation. The cre- ation of payloads for security association negotiation and establishment described here in this section are applicable for all ISAKMP exchanges de- scribed later in sections 4.4 through 4.8. The examples shown in 4.2.1 contain only the SA, Proposal, and Transform payloads and do not contain other payloads that might exist for a given ISAKMP exchange. The Proposal payload provides the initiating entity with the capability to present to the responding entity the security protocols and associated security mechanisms for use with the security association being negoti- ated. If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Pro- posal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. The use of the same Proposal number in mul- tiple Proposal payloads provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads each with a monoton- ically increasing Proposal number. The different proposals MUST be pre- sented in the initiator's preference order. The use of different Proposal numbers in multiple Proposal payloads provides a logical OR operation, i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one protocol. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload (if it exists). The existence of a Proposal payload implies the existence of one or more Transform payloads. The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform pay- load allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with mono- tonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform num- ber in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below shows one transform for AH AND one transform for ESP OR two trans- forms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals. When responding to a Security Association payload, the responder MUST send Maughan, Schertler, Schneider, Turner ISAKMP [Page 47] INTERNET-DRAFT ISAKMP March 10, 1998 a Security Association payload with the selected proposal, which may con- sist of multiple Proposal payloads and their associated Transform pay- loads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison di- rectly and quickly. The initiator MUST verify that the Security Associa- tion payload received from the responder matches one of the proposals sent initially. 4.2.1 Security Association Establishment Examples This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a sin- gle transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms pro- posed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Nonce ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SA Pay ! Domain of Interpretation (DOI) ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! Situation ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maughan, Schertler, Schneider, Turner ISAKMP [Page 48] INTERNET-DRAFT ISAKMP March 10, 1998 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Maughan, Schertler, Schneider, Turner ISAKMP [Page 49] INTERNET-DRAFT ISAKMP March 10, 1998 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Security Association Modification Security Association modification within ISAKMP is accomplished by cre- ating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Dele- tion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. The procedure for creating new SAs is outlined in section 4.2. The procedure for deleting SAs is outlined in section 5.15. Modification of an ISAKMP SA (phase 1 negotiation) follows the same proce- dure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3. Modification of a Protocol SA (phase 2 negotiation) follows the same pro- cedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Proto- col SAs. A protocol implementation SHOULD begin using the newly created Maughan, Schertler, Schneider, Turner ISAKMP [Page 50] INTERNET-DRAFT ISAKMP March 10, 1998 SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy. 4.4 Base Exchange The Base Exchange is designed to allow the Key Exchange and Authentica- tion related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity pro- tection. Identity protection is not provided because identities are ex- changed before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange. BASE EXCHANGE _#______Initiator____Direction_____Responder______________________NOTE____________________ (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE Basic SA agreed upon (3) HDR; KE; => IDii; AUTH Key Generated (by responder) Initiator Identity Verified by Responder (4) <= HDR; KE; IDir; AUTH Responder Identity Verified by Initiator Key Generated (by initiator) SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also trans- mitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information Maughan, Schertler, Schneider, Turner ISAKMP [Page 51] INTERNET-DRAFT ISAKMP March 10, 1998 provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local secu- rity policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third (3) and fourth (4) messages, the initiator and responder, re- spectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these mes- sages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.5 Identity Protection Exchange The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the ex- pense of two additional messages. Identities are exchanged under the pro- tection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange. IDENTITY PROTECTION EXCHANGE _#_______Initiator_____Direction______Responder_____NOTE________________________________________ (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA Basic SA agreed upon (3) HDR; KE; NONCE => (4) <= HDR; KE; NONCE Key Generated (by Initiator and Responder) (5) HDR*; IDii; AUTH => Initiator Identity Verified by Responder (6) <= HDR*; IDir; AUTH Responder Identity Verified by Initiator SA established In the first message (1), the initiator generates a proposal it consid- ers adequate to protect traffic for the given situation. The Security As- sociation, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Maughan, Schertler, Schneider, Turner ISAKMP [Page 52] INTERNET-DRAFT ISAKMP March 10, 1998 In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the trans- mission of a Notify payload as part of an Informational Exchange. In the third (3) and fourth (4) messages, the initiator and responder, re- spectively, exchange keying material used to arrive at a common shared se- cret and random information which is used to guarantee liveness and pro- tect against replay attacks. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the ac- tion if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the fifth (5) and sixth (6) messages, the initiator and responder, re- spectively, exchange identification information and the results of the agreed upon authentication function. This information is transmitted un- der the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One pos- sible action is the transmission of a Notify payload as part of an Infor- mational Exchange. 4.6 Authentication Only Exchange The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational ex- pense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negoti- ated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authenti- cation only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible pay- loads sent in each message and notes for an example of the Authentication Only Exchange. Maughan, Schertler, Schneider, Turner ISAKMP [Page 53] INTERNET-DRAFT ISAKMP March 10, 1998 AUTHENTICATION ONLY EXCHANGE _#______Initiator_____Direction_____Responder_______________________NOTE____________________ (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE; IDir; AUTH Basic SA agreed upon Responder Identity Verified by Initiator (3) HDR; IDii; AUTH => Initiator Identity Verified by Responder SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also trans- mitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this infor- mation is transmitted under the protection of the agreed upon authentica- tion function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third message (3), the initiator transmits identification informa- tion. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.7 Aggressive Exchange The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication- related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is Maughan, Schertler, Schneider, Turner ISAKMP [Page 54] INTERNET-DRAFT ISAKMP March 10, 1998 not provided because identities are exchanged before a common shared se- cret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to es- tablish all security relevant information in a single exchange. The fol- lowing diagram shows the messages with possible payloads sent in each mes- sage and notes for an example of the Aggressive Exchange. AGGRESSIVE EXCHANGE _#_____Initiator___Direction______Responder________________________NOTE____________________ (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation NONCE; IDii and Key Exchange (2) <= HDR; SA; KE; NONCE; IDir; AUTH Initiator Identity Verified by Responder Key Generated Basic SA agreed upon (3) HDR*; AUTH => Responder Identity Verified by Initiator SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). There can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work. Keying material used to arrive at a common shared se- cret and random information which is used to guarantee liveness and pro- tect against replay attacks are also transmitted. Random information pro- vided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the initiator transmits identification information. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is trans- mitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. Maughan, Schertler, Schneider, Turner ISAKMP [Page 55] INTERNET-DRAFT ISAKMP March 10, 1998 In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted un- der the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One pos- sible action is the transmission of a Notify payload as part of an Infor- mational Exchange. 4.8 Informational Exchange The Informational Exchange is designed as a one-way transmittal of infor- mation that can be used for security association management. The follow- ing diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange. INFORMATIONAL EXCHANGE __#___Initiator__Direction_Responder_______________NOTE_______________ (1) HDR*; N/D => Error Notification or Deletion In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete payload. If the Informational Exchange occurs prior to the exchange of keying me- terial during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. All exchanges are similar in that with the beginning of any exchange cryp- tographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Initial- ization Vector (IV) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informa- tional Exchange will be processed correctly. 5 ISAKMP Payload Processing Section 3 describes the ISAKMP payloads. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI. This section describes the processing for each of the payloads. This section suggests the logging of events to a system au- dit file. This action is controlled by a system security policy and is, Maughan, Schertler, Schneider, Turner ISAKMP [Page 56] INTERNET-DRAFT ISAKMP March 10, 1998 therefore, only a suggested action. 5.1 General Message Processing Every ISAKMP message has basic processing applied to insure protocol re- liability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Set a timer and initialize a retry counter. 2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE. 5.2 ISAKMP Header Processing When creating an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Create the respective cookie. See section 2.5.3 for details. 2. Determine the relevant security characteristics of the session (i.e. DOI and situation). 3. Construct an ISAKMP Header with fields as described in section 3.1. 4. Construct other ISAKMP payloads, depending on the exchange type. 5. Transmit the message to the destination host as described in section 5.1. When an ISAKMP message is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 57] INTERNET-DRAFT ISAKMP March 10, 1998 1. Verify the Initiator and Responder ``cookies''. If the cookie validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID COOKIE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Check the Major and Minor Version fields to confirm they are correct. If the Version field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID ISAKMP VERSION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 4. Check the Exchange Type field to confirm it is valid. If the Exchange Type field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-EXCHANGE-TYPE message type MAY be sent to the Maughan, Schertler, Schneider, Turner ISAKMP [Page 58] INTERNET-DRAFT ISAKMP March 10, 1998 transmitting entity. This action is dictated by a system security policy. 5. Check the Flags field to ensure it contains correct values. If the Flags field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID FLAGS, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-FLAGS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 6. Check the Message ID field to ensure it contains correct values. If the Message ID validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID MESSAGE ID, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-MESSAGE-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 7. Processing of the ISAKMP message continues using the value in the Next Payload field. 5.3 Generic Payload Header Processing When creating any of the ISAKMP Payloads described in sections 3.4 through 3.15 a Generic Payload Header is placed at the beginning of these pay- loads. When creating the Generic Payload Header, the transmitting entity (initiator or responder) MUST do the following: 1. Place the value of the Next Payload in the Next Payload field. These values are described in section 3.1. 2. Place the value zero (0) in the RESERVED field. 3. Place the length (in octets) of the payload in the Payload Length field. Maughan, Schertler, Schneider, Turner ISAKMP [Page 59] INTERNET-DRAFT ISAKMP March 10, 1998 4. Construct the payloads as defined in the remainder of this section. When any of the ISAKMP Payloads are received, the receiving entity (ini- tiator or responder) MUST do the following: 1. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Verify the RESERVED field contains the value zero. If the value in the RESERVED field is not zero, the message is discarded and the following actions are taken: (a) The event, INVALID RESERVED FIELD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads as defined by the Next Payload field. 5.4 Security Association Payload Processing When creating a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Domain of Interpretation for which this negotiation is being performed. 2. Determine the situation within the determined DOI for which this negotiation is being performed. Maughan, Schertler, Schneider, Turner ISAKMP [Page 60] INTERNET-DRAFT ISAKMP March 10, 1998 3. Determine the proposal(s) and transform(s) within the situation. These are described, respectively, in sections 3.5 and 3.6. 4. Construct a Security Association payload. 5. Transmit the message to the receiving entity as described in section 5.1. When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Determine if the given situation can be protected. If the Situation determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID SITUATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads (i.e. Proposal, Transform) of the Security Association Payload. If the Security Association Proposal (as described in sections 5.5 and 5.6) is not accepted, then the following actions are taken: (a) The event, INVALID PROPOSAL, MAY be logged in the appropriate system audit file. Maughan, Schertler, Schneider, Turner ISAKMP [Page 61] INTERNET-DRAFT ISAKMP March 10, 1998 (b) An Informational Exchange with a Notification payload containing the NO-PROPOSAL-CHOSEN message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.5 Proposal Payload Processing When creating a Proposal Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Protocol for this proposal. 2. Determine the number of proposals to be offered for this protocol and the number of transforms for each proposal. Transforms are described in section 3.6. 3. Generate a unique pseudo-random SPI. 4. Construct a Proposal payload. When a Proposal payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Protocol is supported. If the Protocol-ID field is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID PROTOCOL, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PROTOCOL-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. Maughan, Schertler, Schneider, Turner ISAKMP [Page 62] INTERNET-DRAFT ISAKMP March 10, 1998 (b) An Informational Exchange with a Notification payload containing the INVALID-SPI message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Ensure the Proposals are presented according to the details given in section 3.5 and 4.2. If the proposals are not formed correctly, the following actions are taken: (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 4. Process the Proposal and Transform payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. 5.6 Transform Payload Processing When creating a Transform Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Transform # for this transform. 2. Determine the number of transforms to be offered for this proposal. Transforms are described in sections 3.6. 3. Construct a Transform payload. When a Transform payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Transform is supported. If the Transform-ID field contains an unknown or unsupported value, then that Transform payload MUST be ignored and MUST NOT cause the generation of an INVALID TRANSFORM event. If the Transform-ID field is invalid, the payload is discarded and the following actions are taken: Maughan, Schertler, Schneider, Turner ISAKMP [Page 63] INTERNET-DRAFT ISAKMP March 10, 1998 (a) The event, INVALID TRANSFORM, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-TRANSFORM-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Ensure the Transforms are presented according to the details given in section 3.6 and 4.2. If the transforms are not formed correctly, the following actions are taken: (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID ATTRIBUTES, are logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT- SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the subsequent Transform and Proposal payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. 5.7 Key Exchange Payload Processing When creating a Key Exchange Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Key Exchange to be used as defined by the DOI. 2. Determine the usage of the Key Exchange Data field as defined by the DOI. 3. Construct a Key Exchange payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Key Exchange payload is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 64] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Key Exchange is supported. If the Key Exchange determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID KEY INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-KEY-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.8 Identification Payload Processing When creating an Identification Payload, the transmitting entity (initia- tor or responder) MUST do the following: 1. Determine the Identification information to be used as defined by the DOI (and possibly the situation). 2. Determine the usage of the Identification Data field as defined by the DOI. 3. Construct an Identification payload. 4. Transmit the message to the receiving entity as described in section 5.1. When an Identification payload is received, the receiving entity (initia- tor or responder) MUST do the following: 1. Determine if the Identification Type is supported. This may be based on the DOI and Situation. If the Identification determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID ID INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-ID-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 65] INTERNET-DRAFT ISAKMP March 10, 1998 5.9 Certificate Payload Processing When creating a Certificate Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Certificate Encoding to be used. This may be specified by the DOI. 2. Ensure the existence of a certificate formatted as defined by the Certificate Encoding. 3. Construct a Certificate payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Certificate payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Process the Certificate Data field. If the Certificate Data is invalid or improperly formatted, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERTIFICATE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 66] INTERNET-DRAFT ISAKMP March 10, 1998 5.10 Certificate Request Payload Processing When creating a Certificate Request Payload, the transmitting entity (ini- tiator or responder) MUST do the following: 1. Determine the type of Certificate Encoding to be requested. This may be specified by the DOI. 2. Determine the name of an acceptable Certificate Authority which is to be requested (if applicable). 3. Construct a Certificate Request payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Certificate Request payload is received, the receiving entity (ini- tiator or responder) MUST do the following: 1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken: (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the CERT-TYPE-UNSUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 67] INTERNET-DRAFT ISAKMP March 10, 1998 2. Determine if the Certificate Authority is supported for the specified Certificate Encoding. If the Certificate Authority is invalid or improperly formatted, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-AUTHORITY message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the Certificate Request. If a requested Certificate Type with the specified Certificate Authority is not available, then the payload is discarded and the following actions are taken: (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the CERTIFICATE-UNAVAILABLE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.11 Hash Payload Processing When creating a Hash Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Determine the Hash function to be used as defined by the SA negotiation. 2. Determine the usage of the Hash Data field as defined by the DOI. 3. Construct a Hash payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Hash payload is received, the receiving entity (initiator or re- sponder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 68] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Hash is supported. If the Hash determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-HASH-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Perform the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the Hash function fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH VALUE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.12 Signature Payload Processing When creating a Signature Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Signature function to be used as defined by the SA negotiation. 2. Determine the usage of the Signature Data field as defined by the DOI. 3. Construct a Signature payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Signature payload is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 69] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Signature is supported. If the Signature determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-SIGNATURE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If the Signature function fails, the message is discarded and the following actions are taken: (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.13 Nonce Payload Processing When creating a Nonce Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Create a unique random value to be used as a nonce. 2. Construct a Nonce payload. 3. Transmit the message to the receiving entity as described in section 5.1. When a Nonce payload is received, the receiving entity (initiator or re- sponder) MUST do the following: 1. There are no specific procedures for handling Nonce payloads. The procedures are defined by the exchange types (and possibly the DOI and Key Exchange descriptions). Maughan, Schertler, Schneider, Turner ISAKMP [Page 70] INTERNET-DRAFT ISAKMP March 10, 1998 5.14 Notification Payload Processing During communications it is possible that errors may occur. The Infor- mational Exchange with a Notify Payload provides a controlled method of informing a peer entity that errors have occurred during protocol process- ing. It is RECOMMENDED that Notify Payloads be sent in a separate Infor- mational Exchange rather than appending a Notify Payload to an existing exchange. When creating a Notification Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the DOI for this Notification. 2. Determine the Protocol-ID for this Notification. 3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 4. Determine the Notify Message Type based on the error or status message desired. 5. Determine the SPI which is associated with this notification. 6. Determine if additional Notification Data is to be included. This is additional information specified by the DOI. 7. Construct a Notification payload. 8. Transmit the message to the receiving entity as described in section 5.1. Because the Informational Exchange with a Notification payload is a uni- directional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro- priate system audit file by the receiving entity. If the Informational Exchange occurs prior to the exchange of keying ma- terial during an ISAKMP Phase 1 negotiation there will be no protection provided for the Informational Exchange. Once the keying material has been exchanged or the ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. When a Notification payload is received, the receiving entity (initiator Maughan, Schertler, Schneider, Turner ISAKMP [Page 71] INTERNET-DRAFT ISAKMP March 10, 1998 or responder) MUST do the following: 1. Determine if the Informational Exchange has any protection applied to it by checking the Encryption Bit and the Authentication Only Bit in the ISAKMP Header. If the Encryption Bit is set, i.e. the Informa- tional Exchange is encrypted, then the message MUST be decrypted using the (in-progress or completed) ISAKMP SA. Once the decryption is complete the processing can continue as described below. If the Authentication Only Bit is set, then the message MUST be authenti- cated using the (in-progress or completed) ISAKMP SA. Once the authentication is completed, the processing can continue as described below. If the Informational Exchange is not encrypted or authentica- tion, the payload processing can continue as described below. 2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. 3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file. 4. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following action is taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. 5. Determine if the Notify Message Type is valid. If the Notify Message Type is invalid, the payload is discarded and the following action is taken: (a) The event, INVALID MESSAGE TYPE, MAY be logged in the appropriate system audit file. 6. Process the Notification payload, including additional Notification Maughan, Schertler, Schneider, Turner ISAKMP [Page 72] INTERNET-DRAFT ISAKMP March 10, 1998 Data, and take appropriate action, according to local security policy. 5.15 Delete Payload Processing During communications it is possible that hosts may be compromised or that information may be intercepted during transmission. Determining whether this has occurred is not an easy task and is outside the scope of this Internet-Draft. However, if it is discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA. The Informational Exchange with a Delete Payload provides a controlled method of informing a peer entity that the transmitting entity has deleted the SA(s). Deletion of Security Associations MUST always be performed un- der the protection of an ISAKMP SA. The receiving entity SHOULD clean up its local SA database. However, upon receipt of a Delete message the SAs listed in the Security Parameter Index (SPI) field of the Delete payload cannot be used with the transmitting entity. The SA Establishment proce- dure must be invoked to re-establish secure communications. When creating a Delete Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Determine the DOI for this Deletion. 2. Determine the Protocol-ID for this Deletion. 3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 4. Determine the # of SPIs to be deleted for this protocol. 5. Determine the SPI(s) which is (are) associated with this deletion. 6. Construct a Delete payload. 7. Transmit the message to the receiving entity as described in section 5.1. Because the Informational Exchange with a Delete payload is a unidirec- tional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in the appropriate system au- Maughan, Schertler, Schneider, Turner ISAKMP [Page 73] INTERNET-DRAFT ISAKMP March 10, 1998 dit file by the receiving entity. As described above, the Informational Exchange with a Delete payload MUST be transmitted under the protection provided by an ISAKMP SA. When a Delete payload is received, the receiving entity (initiator or re- sponder) MUST do the following: 1. Because the Informational Exchange is protected by some security service (e.g. authentication for an Auth-Only SA, encryption for other exchanges), the message MUST have these security services applied using the ISAKMP SA. Once the security service processing is complete the processing can continue as described below. Any errors that occur during the security service processing will be evident when checking information in the Delete payload. The local security policy SHOULD dictate any action to be taken as a result of security service processing errors. 2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. 3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file. 4. Determine if the SPI is valid for each SPI included in the Delete payload. For each SPI that is invalid, the following action is taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. 5. Process the Delete payload and take appropriate action, according to local security policy. As described above, one appropriate action SHOULD include cleaning up the local SA database. Maughan, Schertler, Schneider, Turner ISAKMP [Page 74] INTERNET-DRAFT ISAKMP March 10, 1998 6 Conclusions The Internet Security Association and Key Management Protocol (ISAKMP) is a well designed protocol aimed at the Internet of the future. The mas- sive growth of the Internet will lead to great diversity in network uti- lization, communications, security requirements, and security mechanisms. ISAKMP contains all the features that will be needed for this dynamic and expanding communications environment. ISAKMP's Security Association (SA) feature coupled with authentication and key establishment provides the security and flexibility that will be needed for future growth and diversity. This security diversity of multi- ple key exchange techniques, encryption algorithms, authentication mecha- nisms, security services, and security attributes will allow users to se- lect the appropriate security for their network, communications, and secu- rity needs. The SA feature allows users to specify and negotiate security requirements with other users. An additional benefit of supporting multi- ple techniques in a single protocol is that as new techniques are devel- oped they can easily be added to the protocol. This provides a path for the growth of Internet security services. ISAKMP supports both publicly or privately defined SAs, making it ideal for government, commercial, and private communications. ISAKMP provides the ability to establish SAs for multiple security proto- cols and applications. These protocols and applications may be session- oriented or sessionless. Having one SA establishment protocol that sup- ports multiple security protocols eliminates the need for multiple, nearly identical authentication, key exchange and SA establishment protocols when more than one security protocol is in use or desired. Just as IP has pro- vided the common networking layer for the Internet, a common security es- tablishment protocol is needed if security is to become a reality on the Internet. ISAKMP provides the common base that allows all other security protocols to interoperate. ISAKMP follows good security design principles. It is not coupled to other insecure transport protocols, therefore it is not vulnerable or weakened by attacks on other protocols. Also, when more secure transport protocols are developed, ISAKMP can be easily migrated to them. ISAKMP also provides protection against protocol related attacks. This protec- tion provides the assurance that the SAs and keys established are with the desired party and not with an attacker. ISAKMP also follows good protocol design principles. Protocol specific information only is in the protocol header, following the design prin- ciples of IPv6. The data transported by the protocol is separated into functional payloads. As the Internet grows and evolves, new payloads to support new security functionality can be added without modifying the en- tire protocol. Maughan, Schertler, Schneider, Turner ISAKMP [Page 75] INTERNET-DRAFT ISAKMP March 10, 1998 A ISAKMP Security Association Attributes A.1 Background/Rationale As detailed in previous sections, ISAKMP is designed to provide a flexible and extensible framework for establishing and managing Security Associa- tions and cryptographic keys. The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner. The definition of mechanisms and their application is the purview of individual Domains of Interpretation (DOIs). This section describes the ISAKMP values for the Internet IP Security DOI, supported security protocols, and identification values for ISAKMP Phase 1 negotiations. The Internet IP Security DOI is MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, in detail, the mechanisms and their application for establishing and managing Security Associations and cryptographic keys for IP Security. A.2 Internet IP Security DOI Assigned Value As described in [IPDOI], the Internet IP Security DOI Assigned Number is one (1). A.3 Supported Security Protocols Values for supported security protocols are specified in the most recent ``Assigned Numbers'' RFC [STD-2]. Presented in the following table are the values for the security protocols supported by ISAKMP for the Internet IP Security DOI. _Protocol_Assigned_Value__ RESERVED 0 ISAKMP 1 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security protocols within that DOI will be numbered accordingly. Security protocol values 2-15359 are reserved to IANA for future use. Values 15360-16383 are permanently reserved for private use amongst mu- Maughan, Schertler, Schneider, Turner ISAKMP [Page 76] INTERNET-DRAFT ISAKMP March 10, 1998 tually consenting implementations. Such private use values are unlikely to be interoperable across different implementations. A.4 ISAKMP Identification Type Values The following table lists the assigned values for the Identification Type field found in the Identification payload during a generic Phase 1 ex- change, which is not for a specific protocol. ______ID_Type_______Value_ ID_IPV4_ADDR 0 ID_IPV4_ADDR_SUBNET 1 ID_IPV6_ADDR 2 ID_IPV6_ADDR_SUBNET 3 A.4.1 ID_IPV4_ADDR The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. A.4.2 ID_IPV4_ADDR_SUBNET The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, repre- sented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. A.4.3 ID_IPV6_ADDR The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address. A.4.4 ID_IPV6_ADDR_SUBNET The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, repre- sented by two sixteen (16) octet values. The first value is an IPv6 ad- dress. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. Maughan, Schertler, Schneider, Turner ISAKMP [Page 77] INTERNET-DRAFT ISAKMP March 10, 1998 B Defining a new Domain of Interpretation The Internet DOI may be sufficient to meet the security requirements of a large portion of the internet community. However, some groups may have a need to customize some aspect of a DOI, perhaps to add a different set of cryptographic algorithms, or perhaps because they want to make their security-relevant decisions based on something other than a host id or user id. Also, a particular group may have a need for a new exchange type, for example to support key management for multicast groups. This section discusses guidelines for defining a new DOI. The full speci- fication for the Internet DOI can be found in [IPDOI]. Defining a new DOI is likely to be a time-consuming process. If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable. If a designer chooses to start from scratch, the following MUST be de- fined: o A ``situation'': the set of information that will be used to determine the required security services. o The set of security policies that must be supported. o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, etc. o A syntax for the specification of proposed security services, attributes, and certificate authorities. o The specific formats of the various payload contents. o Additional exchange types, if required. B.1 Situation The situation is the basis for deciding how to protect a communications channel. It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate. These additional security attributes would be included in the situation. Maughan, Schertler, Schneider, Turner ISAKMP [Page 78] INTERNET-DRAFT ISAKMP March 10, 1998 B.2 Security Policies Security policies define how various types of information must be cate- gorized and protected. The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation, and will protect information appropriately, both in transit and in storage. In a corporate setting, for example, both parties in a negotiation must agree to the meaning of the term ``propri- etary information'' before they can negotiate how to protect it. Note that including the required security policies in the DOI only speci- fies that the participating hosts understand and implement those policies in a full system context. B.3 Naming Schemes Any DOI must define a consistent way to name cryptographic algorithms, certificate authorities, etc. This can usually be done by using IANA nam- ing conventions, perhaps with some private extensions. B.4 Syntax for Specifying Security Services In addition to simply specifying how to name entities, the DOI must also specify the format for complete proposals of how to protect traffic under a given situation. B.5 Payload Specification The DOI must specify the format of each of the payload types. For several of the payload types, ISAKMP has included fields that would have to be present across all DOI (such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload). B.6 Defining new Exchange Types If the basic exchange types are inadequate to meet the requirements within a DOI, a designer can define up to thirteen extra exchange types per DOI. The designer creates a new exchange type by choosing an unused exchange type value, and defining a sequence of messages composed of strings of the ISAKMP payload types. Maughan, Schertler, Schneider, Turner ISAKMP [Page 79] INTERNET-DRAFT ISAKMP March 10, 1998 Note that any new exchange types must be rigorously analyzed for vulner- abilities. Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary. Maughan, Schertler, Schneider, Turner ISAKMP [Page 80] INTERNET-DRAFT ISAKMP March 10, 1998 Security Considerations Cryptographic analysis techniques are improving at a steady pace. The continuing improvement in processing power makes once computationally pro- hibitive cryptographic attacks more realistic. New cryptographic algo- rithms and public key generation techniques are also being developed at a steady pace. New security services and mechanisms are being developed at an accelerated pace. A consistent method of choosing from a variety of security services and mechanisms and to exchange attributes required by the mechanisms is important to security in the complex structure of the Internet. However, a system that locks itself into a single cryptographic algorithm, key exchange technique, or security mechanism will become in- creasingly vulnerable as time passes. UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- troduces a number of security considerations. Since UDP is unreliable, but a key management protocol must be reliable, the reliability is built into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it doesn't rely on any UDP information (e.g. checksum, length) for its pro- cessing. Another issue that must be considered in the development of ISAKMP is the effect of firewalls on the protocol. Many firewalls filter out all UDP packets, making reliance on UDP questionable in certain environments. A number of very important security considerations are presented in [RFC-1825]. One bears repeating. Once a private session key is created, it must be safely stored. Failure to properly protect the private key from access both internal and external to the system completely nullifies any protection provided by the IP Security services. IANA Considerations This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign addi- tional numbers in each of these lists. Domain of Interpretation The Domain of Interpretation (DOI) is a 32-bit field which identifies the domain under which the security association negotiation is taking place. Requests for assignments of new DOIs must be accompanied by a standards- track RFC which describes the specific domain. Maughan, Schertler, Schneider, Turner ISAKMP [Page 81] INTERNET-DRAFT ISAKMP March 10, 1998 Supported Security Protocols ISAKMP is designed to provide security association negotiation and key management for many security protocols. Requests for identifiers for ad- ditional security protocols must be accompanied by a standards-track RFC which describes the security protocol and its relationship to ISAKMP. Acknowledgements Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided design assistance with the protocol and coordination for the [IKE] and [IPDOI] documents. Hilarie Orman, via the Oakley key exchange protocol, has significantly influenced the design of ISAKMP. Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided significant input and review to this document. Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the ISAKMP prototype. Jeff Turner and Steve Smalley contributed to the prototype development and integration with ESP and AH. Mike Oehler and Pete Sell performed interoperability testing with other ISAKMP implementors. Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. Maughan, Schertler, Schneider, Turner ISAKMP [Page 82] INTERNET-DRAFT ISAKMP March 10, 1998 References [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services Industry -- Establishment of Symmetric Algorithm Keys Using Diffie-Hellman, Working Draft, April 19, 1996. [BC] Ballardie, A. and J. Crowcroft, Multicast-specific Security Threats and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks & Distributed Systems Security, pp. 17-30, Internet Society, San Diego, CA, February 1995. [Berge] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work in progress, November, 1995. [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and Military Computer Security Policies, Proceedings of the IEEE Symposium on Security & Privacy, Oakland, CA, 1987, pp. 184-193. [DNSSEC] D. Eastlake III, Domain Name System Protocol Security Extensions, Internet-Draft: draft-ietf-dnssec-secext2-03.txt, Work in Progress, January 1998. [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 107-125, Kluwer Academic Publishers, 1992. [IAB] Bellovin, S., Report of the IAB Security Architecture Workshop, Internet-Draft: draft-iab-secwks-report-00.txt, Work in Progress, November 1997. [IKE] Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), Internet-Draft: draft-ietf-ipsec-isakmp-oakley-06.txt, Work in Progress, February 1998. [IPDOI] Derrell Piper, The Internet IP Security Domain of Interpretation for ISAKMP, Internet-Draft: draft-ietf-ipsec-ipsec-doi-07.txt, Work in Progress, February 1998. [Karn] Karn, P. and B. Simpson, Photuris: Session Key Management Protocol, Internet-Draft: draft-simpson-photuris-15.txt, Work in Progress, July 1997. [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 1994. [Oakley] H. K. Orman, The Oakley Key Determination Protocol, Internet- Draft: draft-ietf-ipsec-oakley-02.txt, Work in Progress, July 1997. [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, February 1993. Maughan, Schertler, Schneider, Turner ISAKMP [Page 83] INTERNET-DRAFT ISAKMP March 10, 1998 [RFC-1825] Randall Atkinson, Security Architecture for the Internet Protocol, RFC-1825, August, 1995. [RFC-1949] A. Ballardie, Scalable Multicast Key Distribution, RFC-1949, May 1996. [RFC-2093] Harney, H. and C. Muckenhirn, Group Key Management Protocol (GKMP) Specification, SPARTA, Inc., RFC-2093, July 1997. [RFC-2094] Harney, H. and C. Muckenhirn, Group Key Management Protocol (GKMP) Architecture, SPARTA, Inc., RFC-2094, July 1997. [RFC-2119] S. Bradner, Key Words for use in RFCs to Indicate Requirement Levels, Harvard University, RFC-2119, March 1997. [Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, and Source Code in C (Second Edition), John Wiley & Sons, Inc., 1996. [STD-2] Reynolds, J. and J. Postel, Assigned Numbers, STD 2, October, 1994. Maughan, Schertler, Schneider, Turner ISAKMP [Page 84] INTERNET-DRAFT ISAKMP March 10, 1998 Addresses of Authors The authors can be contacted at: Douglas Maughan Phone: 301-688-0847 E-mail:wdm@tycho.ncsc.mil Mark Schneider Phone: 301-688-0851 E-mail:mss@tycho.ncsc.mil National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000 Mark Schertler Terisa Systems, Inc. 4984 El Camino Real Los Altos, CA. 94022 Phone: 650-919-1773 E-mail:mjs@terisa.com Jeff Turner RABA Technologies, Inc. 10500 Little Patuxent Parkway Columbia, MD. 21044 Phone: 410-715-9399 E-mail:jeff.turner@raba.com Maughan, Schertler, Schneider, Turner ISAKMP [Page 85] From owner-ipsec Wed Mar 11 09:30:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19338 for ipsec-outgoing; Wed, 11 Mar 1998 09:28:01 -0500 (EST) Message-Id: <199803111425.JAA25835@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-02.txt Date: Wed, 11 Mar 1998 09:25:11 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP CBC-Mode Cipher Algorithms Author(s) : R. Adams, R. Pereira Filename : draft-ietf-ipsec-ciph-cbc-02.txt Pages : 13 Date : 10-Mar-98 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-cbc-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980310141702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310141702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Mar 11 09:57:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19563 for ipsec-outgoing; Wed, 11 Mar 1998 09:57:00 -0500 (EST) Message-Id: <199803111425.JAA25835@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-02.txt Date: Wed, 11 Mar 1998 09:25:11 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP CBC-Mode Cipher Algorithms Author(s) : R. Adams, R. Pereira Filename : draft-ietf-ipsec-ciph-cbc-02.txt Pages : 13 Date : 10-Mar-98 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-cbc-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980310141702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310141702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Mar 11 10:12:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA19717 for ipsec-outgoing; Wed, 11 Mar 1998 10:12:02 -0500 (EST) From: Jackie Wilson Message-Id: <199803111525.JAA25344@jhwilson.austin.ibm.com> Subject: date on draft-ietf-ipsec-ipsec-doi-07.txt To: ipsec@tis.com Date: Wed, 11 Mar 1998 09:25:29 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I was checking to see if I had pulled down the latest drafts and noticed the date on draft-ietf-ipsec-ipsec-doi-07.txt is February 13, 1997. I think this needs to get fixed, it's pretty confusing. ---- Jackie -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec Wed Mar 11 11:21:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA20195 for ipsec-outgoing; Wed, 11 Mar 1998 11:20:02 -0500 (EST) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44097E85@scc-server3.semaphorecom.com> From: CJ Gibson To: "'Eric L. Wong'" , Ben Rogers Cc: Robert Moskowitz , ipsec@tis.com Subject: RE: doi-07/interoperability questions Date: Wed, 11 Mar 1998 08:47:13 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't believe we should delete either 2 or 4 but I didn't think that's what Ben meant by "not support AH (tunnel) and ESP (transport)". I assumed this meant "not support [these] together on the same packet. You aren't seriously advocating the removal of AH-tunnel mode, are you? I also don't see the use of adding 6. --CJ -----Original Message----- From: Eric L. Wong [SMTP:ewong@zk3.dec.com] Sent: Tuesday, March 10, 1998 2:07 PM To: Ben Rogers Cc: Robert Moskowitz; ipsec@tis.com Subject: Re: doi-07/interoperability questions Sounds to me you are suggesting the following changes to the arch spec in section 4.5 Case 1. ] ] 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] ] Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] (remove)4. [IP2][AH][IP1][upper] (remove)2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] (add)6. [IP2][AH][ESP][IP1][upper] Is this correct? I think it is ok to remove 4, it really doesn't buy you much. I think we should keep 2. This new one for tunnel mode seem to make sense. Now, should we restrict 6 to just gateway-to- gateway? /eric Ben Rogers wrote: > > Yes. In fact, I was thinking specifically about gateway to gateway > configurations using both AH and ESP. > > Robert Moskowitz writes: > > At 10:50 AM 3/10/98 -0500, Ben Rogers wrote: > > > > I believe you are talking about where the transforms all end at the same > > system not the case where the transport is end to end and the tunnel is > > gateway to gateway. > > > > >My other question centers on the use of Encapsulation Mode attributes in > > >combined (AND) proposal transforms. Namely, it seems obvious that we > > >should support the case where both are transport mode (Case 1.3 in > > >section 4.5 of arch-sec), and not support the case where both are tunnel > > >(probably returning a BAD-PROPSAL-SYNTAX). However, I'm not too clear > > >as to whether I should support mixed proposals. My opinion is that it > > >makes sense to support AH (transport) and ESP (tunnel) with the > > >following encapsulation: > > > > > >[IP2][AH][ESP][IP1][upper] > > > > > >and to not support AH (tunnel) and ESP (transport). Does anyone else > > >have any feelings on this matter? Whatever we choose probably ought to > > >be added as clarifying text to [IPDOI]. > > > > > > > > >ben > > > > > > > > Robert Moskowitz > > ICSA > > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Mar 11 11:33:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA20326 for ipsec-outgoing; Wed, 11 Mar 1998 11:33:02 -0500 (EST) Message-Id: <3506C162.CA24FDC2@zk3.dec.com> Date: Wed, 11 Mar 1998 11:52:50 -0500 From: "Eric L. Wong" X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: CJ Gibson Cc: Ben Rogers , Robert Moskowitz , ipsec@tis.com Subject: Re: doi-07/interoperability questions References: <0171F2F8F9E5D011A4D10060B03CFB44097E85@scc-server3.semaphorecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk No, I am not advocating such at all. I mis-interpreted the original post. I get the picture now, as explained by Ben. /eric CJ Gibson wrote: > > I don't believe we should delete either 2 or 4 but I didn't think that's > what Ben meant by "not support AH (tunnel) and ESP (transport)". I > assumed this meant "not support [these] together on the same packet. > You aren't seriously advocating the removal of AH-tunnel mode, are you? > I also don't see the use of adding 6. > > --CJ > ======= Ben Rogers wrote: > > Is this correct? > > Nope. All I'm suggesting is that we have a way to negotiate 5 followed > by 1 in ISAKMP. The net result being: > > [IP1][upper] > [IP2][ESP][IP1][upper] > [IP2][AH][ESP][IP1][upper] > > I used to think that 6 was necessary, but was convinced this was not a > valid combination by Stephen Kent at the December IETF (AH is no longer > in tunnel mode). You can, however, emulate it using the 5+1 > combination. This was what I was suggesting in the AH (transport) + ESP > (tunnel) proposal. > > > ben > > From owner-ipsec Wed Mar 11 11:36:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA20348 for ipsec-outgoing; Wed, 11 Mar 1998 11:36:02 -0500 (EST) Date: Wed, 11 Mar 1998 11:48:23 -0500 Message-Id: <9803111648.AA01684@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: Looking for statement of patent issues re ISAKMP/Oakley X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk I was putting together a memo on licensing needs for IPSec products, and looked in the various drafts for guidance. From what I understand, IETF standards-track documents are supposed to contain a section discussing any patent issues that may pertain to the technology in question. A number of the transform specs contain such sections (e.g., DES and IDEA). Somewhat to my surprise, the ISAKMP/Oakley documents do not. I also looked in other places (specifically, Scheier) for input. It mentioned the well-known fact that RSA is subject to patents and licenses. No confusion there. Scheier also discussed the situation for DSS. As I read it, it sounds like the patent situation there is muddled. In particular, he mentions a U.S. Government patent (D. Kravitz) supposedly generally licensed at no cost -- but also mentions that claims have been made that the Schorr patent applies as well. Question: Does anyone have any further insight on this topic? And could this be added to the document? paul -- !----------------------------------------------------------------------- ! Paul Koning, NI1D, C-24183 ! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA ! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090 ! email: pkoning@xedia.com ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75 !----------------------------------------------------------------------- ! "The only purpose for which power can be rightfully exercised over ! any member of a civilized community, against his will, is to prevent ! harm to others. His own good, either physical or moral, is not ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859 From owner-ipsec Wed Mar 11 12:26:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20706 for ipsec-outgoing; Wed, 11 Mar 1998 12:24:01 -0500 (EST) Message-ID: <6236E58EC451D1119E80006097040ED9214075@lobester.rsa.com> From: Bob Baldwin To: "'Paul Koning'" , ipsec@tis.com Subject: RE: Looking for statement of patent issues re ISAKMP/Oakley Date: Wed, 11 Mar 1998 09:38:31 -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 Paul, RSA Data Security owns exclusive rights to the Schnorr patent and RSA's lawyers claim that any implementation of DSS would infringe this patent. The US government disagrees with this interpretation. The issue has not been tested in court. The current shipping version of BSAFE (3.0) from RSA contains an implementation of DSS. The BSAFE 4.0 release, which is currently in beta, contains all the extra algorithms needed to fully comply with the FIPS that defines DSS. For example, BSAFE 4.0 includes the SHA1 based random number generator described in the FIPS document. Most vendors of IPSec products have already licensed BSAFE, so the possible patent issues are not a problem. --Bob Baldwin Technical Director E-Commerce RSA Data Security P.S. For all of you who want to flame me or RSA for having patents or for having lawyers, go ahead. After my first year at RSA I got used to being flamed whenever I post. > -----Original Message----- > From: Paul Koning [SMTP:pkoning@xedia.com] > Sent: Wednesday, March 11, 1998 8:48 AM > To: ipsec@tis.com > Subject: Looking for statement of patent issues re ISAKMP/Oakley > > I was putting together a memo on licensing needs for IPSec products, > and looked in the various drafts for guidance. From what I > understand, IETF standards-track documents are supposed to contain a > section discussing any patent issues that may pertain to the > technology in question. > > A number of the transform specs contain such sections (e.g., DES and > IDEA). Somewhat to my surprise, the ISAKMP/Oakley documents do not. > > I also looked in other places (specifically, Scheier) for input. It > mentioned the well-known fact that RSA is subject to patents and > licenses. No confusion there. > > Scheier also discussed the situation for DSS. As I read it, it sounds > like the patent situation there is muddled. In particular, he > mentions a U.S. Government patent (D. Kravitz) supposedly generally > licensed at no cost -- but also mentions that claims have been made > that the Schorr patent applies as well. > > Question: Does anyone have any further insight on this topic? And > could this be added to the document? > > paul > > -- > !--------------------------------------------------------------------- > -- > ! Paul Koning, NI1D, C-24183 > ! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA > ! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090 > ! email: pkoning@xedia.com > ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75 > !--------------------------------------------------------------------- > -- > ! "The only purpose for which power can be rightfully exercised over > ! any member of a civilized community, against his will, is to > prevent > ! harm to others. His own good, either physical or moral, is not > ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859 From owner-ipsec Wed Mar 11 13:36:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21202 for ipsec-outgoing; Wed, 11 Mar 1998 13:34:02 -0500 (EST) Message-Id: <3.0.32.19980311095711.00723b14@sc-mail2.corpwest.baynetworks.com> X-Sender: kdurazzo@sc-mail2.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 11 Mar 1998 09:57:16 -0800 To: Bob Baldwin , "'Paul Koning'" , ipsec@tis.com From: Kenneth_Durazzo@BayNetworks.COM (Kenneth Durazzo) Subject: RE: Looking for statement of patent issues re ISAKMP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, No flame.. it would just be nice to be able to implement good technology for use in the public domain without "paying through the nose" for it (read: standardization) which would be good for all. I do understand however that money is money (business is business) and RSA could not continue to exist without having someone pay for their services. Good Day, Ken Durazzo Systems Engineer - Bay Networks "Where information flows" At 09:38 AM 3/11/98 -0800, Bob Baldwin wrote: >Paul, > RSA Data Security owns exclusive rights to the >Schnorr patent and RSA's lawyers claim that any implementation >of DSS would infringe this patent. The US government >disagrees with this interpretation. The issue has not >been tested in court. > The current shipping version of BSAFE (3.0) from RSA >contains an implementation of DSS. The BSAFE 4.0 release, >which is currently in beta, contains all the extra >algorithms needed to fully comply with the FIPS that defines >DSS. For example, BSAFE 4.0 includes the SHA1 based random >number generator described in the FIPS document. > Most vendors of IPSec products have already licensed >BSAFE, so the possible patent issues are not a problem. > --Bob Baldwin > Technical Director E-Commerce > RSA Data Security > >P.S. For all of you who want to flame me or RSA for having >patents or for having lawyers, go ahead. After my first >year at RSA I got used to being flamed whenever I post. > >> -----Original Message----- >> From: Paul Koning [SMTP:pkoning@xedia.com] >> Sent: Wednesday, March 11, 1998 8:48 AM >> To: ipsec@tis.com >> Subject: Looking for statement of patent issues re ISAKMP/Oakley >> >> I was putting together a memo on licensing needs for IPSec products, >> and looked in the various drafts for guidance. From what I >> understand, IETF standards-track documents are supposed to contain a >> section discussing any patent issues that may pertain to the >> technology in question. >> >> A number of the transform specs contain such sections (e.g., DES and >> IDEA). Somewhat to my surprise, the ISAKMP/Oakley documents do not. >> >> I also looked in other places (specifically, Scheier) for input. It >> mentioned the well-known fact that RSA is subject to patents and >> licenses. No confusion there. >> >> Scheier also discussed the situation for DSS. As I read it, it sounds >> like the patent situation there is muddled. In particular, he >> mentions a U.S. Government patent (D. Kravitz) supposedly generally >> licensed at no cost -- but also mentions that claims have been made >> that the Schorr patent applies as well. >> >> Question: Does anyone have any further insight on this topic? And >> could this be added to the document? >> >> paul >> >> -- >> !--------------------------------------------------------------------- >> -- >> ! Paul Koning, NI1D, C-24183 >> ! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA >> ! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090 >> ! email: pkoning@xedia.com >> ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75 >> !--------------------------------------------------------------------- >> -- >> ! "The only purpose for which power can be rightfully exercised over >> ! any member of a civilized community, against his will, is to >> prevent >> ! harm to others. His own good, either physical or moral, is not >> ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859 > From owner-ipsec Wed Mar 11 17:36:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23052 for ipsec-outgoing; Wed, 11 Mar 1998 17:33:21 -0500 (EST) Message-Id: <199803112246.RAA07999@jekyll.piermont.com> To: Kenneth_Durazzo@BayNetworks.COM (Kenneth Durazzo) cc: Bob Baldwin , "'Paul Koning'" , ipsec@tis.com Subject: Re: Looking for statement of patent issues re ISAKMP/Oakley In-reply-to: Your message of "Wed, 11 Mar 1998 09:57:16 PST." <3.0.32.19980311095711.00723b14@sc-mail2.corpwest.baynetworks.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Mar 1998 17:46:00 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Kenneth Durazzo writes: > No flame.. it would just be nice to be able to implement good technology > for use in the public domain without "paying through the nose" for it > (read: standardization) which would be good for all. Well, I'll point out that Diffie-Hellman itself, and Diffie-Hellman based keying (i.e. El Gamal) are both out of patent these days. Also, the RSA patent is expiring in about 700 days if I'm not mistaken. Perry From owner-ipsec Wed Mar 11 20:09:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24027 for ipsec-outgoing; Wed, 11 Mar 1998 20:08:21 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Adel Jaber" To: Kenneth_Durazzo@BayNetworks.COM cc: baldwin@RSA.COM, pkoning@xedia.com, ipsec@tis.com Message-ID: <882565C4.007917C0.00@domino_c02.certicom.com> Date: Wed, 11 Mar 1998 14:14:34 -0700 Subject: RE: Looking for statement of patent issues re ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > No flame.. it would just be nice to be able to implement good > technology for use in the public domain without "paying through > the nose" for it (read: standardization) which would be good for > all. I do understand however that money is money (business is > business) and RSA could not continue to exist without having > someone pay for their services. > > Good Day, Certicom prides itself for developing of the most efficient Public-Key Cryptosystem i.e. the Elliptic Curve Public-Key Cryptosystem (ECC). Besides the outstanding technology Certicom offers EXCELLENT Licensing terms which are good for ALL. We hope you will support the effort to help standardize the use of ECC in this Working Group and others which will be good for ALL. Adel Jaber/ Market Research Manager-Information Security Certicom Corp. San Mateo California WWW.Certicom.COM > Ken Durazzo > Systems Engineer - Bay Networks "Where information flows" From owner-ipsec Wed Mar 11 20:52:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24345 for ipsec-outgoing; Wed, 11 Mar 1998 20:51:23 -0500 (EST) Message-Id: <199803120203.VAA14703@postal.research.att.com> To: "Adel Jaber" cc: Kenneth_Durazzo@BayNetworks.COM, baldwin@RSA.COM, pkoning@xedia.com, ipsec@tis.com Subject: Re: Looking for statement of patent issues re ISAKMP/Oakley Date: Wed, 11 Mar 1998 21:03:24 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me refer folks to RFC 2026. Here's a relevant excerpt: (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification. 10.3.3 Determination of Reasonable and Non-discriminatory Terms The IESG will not make any explicit determination that the assurance of reasonable and non-discriminatory terms for the use of a technology has been fulfilled in practice. It will instead use the normal requirements for the advancement of Internet Standards to verify that the terms for use are reasonable. If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved the assumption is that the terms must be reasonable and to some degree, non-discriminatory. This assumption may be challenged during the Last-Call period. From owner-ipsec Thu Mar 12 00:38:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA25561 for ipsec-outgoing; Thu, 12 Mar 1998 00:36:28 -0500 (EST) Message-Id: <199803120549.VAA22271@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Paul Koning Cc: ipsec@tis.com Subject: Re: Looking for statement of patent issues re ISAKMP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Mar 1998 21:49:48 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk There are no patents on IKE itself and to my knowledge there are none on the protocols it's based on. All of the mandatory-to-implement options-- DES, SHA or MD5, Diffie-Hellman over modp groups using pre-shared keys-- are free of patent claims. RSA (and their lawyers) may claim that DSS infringes on one of their patents but that's a disputed subject and many choose to simply ignore them. You can get a royalty free-- for commercial and non-commercial use-- copy of DSS as part of the IKE reference implementation by pointing your favorite browser to http://www.cisco.com/public/library/isakmp/disclaimer.html and following the hotlinks. This is an up-to-date implementation (ISAKMP v8 and IKE v6) which interoperates with other implementations (e.g. cisco IOS and SSH) to the extent possible (it is tied to a PF_KEYv1 version of the NRL IPSec code and doesn't have any mechanism in place to express IPSec policy). US patent 5548646 ("System for signatureless transmission and reception of data packets between computer networks") sounds alot like tunnel mode IPSec between gateways. That was the subject of considerable debate on this list some time ago. I don't recall what if anything was resolved though. Perhaps someone with a better memory than mine remembers. Dan. > I was putting together a memo on licensing needs for IPSec products, > and looked in the various drafts for guidance. From what I > understand, IETF standards-track documents are supposed to contain a > section discussing any patent issues that may pertain to the > technology in question. > > A number of the transform specs contain such sections (e.g., DES and > IDEA). Somewhat to my surprise, the ISAKMP/Oakley documents do not. > > I also looked in other places (specifically, Scheier) for input. It > mentioned the well-known fact that RSA is subject to patents and > licenses. No confusion there. > > Scheier also discussed the situation for DSS. As I read it, it sounds > like the patent situation there is muddled. In particular, he > mentions a U.S. Government patent (D. Kravitz) supposedly generally > licensed at no cost -- but also mentions that claims have been made > that the Schorr patent applies as well. > > Question: Does anyone have any further insight on this topic? And > could this be added to the document? From owner-ipsec Thu Mar 12 07:55:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28609 for ipsec-outgoing; Thu, 12 Mar 1998 07:53:30 -0500 (EST) Date: Tue, 10 Mar 98 18:58:17 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803102358.AA06309@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP-09 .txt Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 4 As promised, ISAKMP-09 ASCII Text. Doug ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: draft-ietf-ipsec-isakmp-09.txt X-Sun-Content-Lines: 4927 IPSEC Working Group Douglas Maughan, Mark Schertler INTERNET-DRAFT Mark Schneider, Jeff Turner draft-ietf-ipsec-isakmp-09.txt, .ps March 10, 1998 Internet Security Association and Key Management Protocol (ISAKMP) Abstract This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and crypto- graphic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mecha- nisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicat- ing peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to es- tablish and maintain secure communications (via IP Security Ser- vice or any other security protocol) in an Internet environment. Status of this memo This document is being submitted to the IETF Internet Protocol Security (IPSEC) Working Group for consideration as a method for the establishment and management of security associations and their appropriate security at- tributes. Additionally, this document proposes a method for key manage- ment to support IPSEC and IPv6. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments are solicited and should be addressed to the authors and/or the IPSEC working group mailing list at ipsec@tis.com. 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-DRAFT ISAKMP March 10, 1998 Internet Drafts are draft documents valid for a maximum of six 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 ``working draft'' or ``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 Di- rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Maughan, Schertler, Schneider, Turner ISAKMP [Page 2] INTERNET-DRAFT ISAKMP March 10, 1998 Contents 1 Introduction 6 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 7 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . . . . 7 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . . . . . 7 1.4 Security Associations and Management . . . . . . . . . . . . . . 8 1.4.1Security Associations and Registration . . . . . . . . . . . . 8 1.4.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 9 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 10 1.5.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 12 1.6.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 12 1.6.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 13 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 13 1.7.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 14 1.7.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 14 1.8 Multicast Communications . . . . . . . . . . . . . . . . . . . . 14 2 Terminology and Concepts 15 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . . . . 18 2.4 Identifying Security Associations . . . . . . . . . . . . . . . . 19 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21 3 ISAKMP Payloads 22 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 27 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 30 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 31 3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 32 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 33 3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 35 3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 37 3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 38 3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 40 3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.16Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 43 4 ISAKMP Exchanges 45 Maughan, Schertler, Schneider, Turner ISAKMP [Page 3] INTERNET-DRAFT ISAKMP March 10, 1998 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 45 4.1.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2 Security Association Establishment . . . . . . . . . . . . . . . 46 4.2.1Security Association Establishment Examples . . . . . . . . . 48 4.3 Security Association Modification . . . . . . . . . . . . . . . . 50 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 52 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 53 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 54 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 56 5 ISAKMP Payload Processing 56 5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 57 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 57 5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 59 5.4 Security Association Payload Processing . . . . . . . . . . . . . 60 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . . . . 62 5.6 Transform Payload Processing . . . . . . . . . . . . . . . . . . 63 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 64 5.8 Identification Payload Processing . . . . . . . . . . . . . . . . 65 5.9 Certificate Payload Processing . . . . . . . . . . . . . . . . . 66 5.10Certificate Request Payload Processing . . . . . . . . . . . . . 67 5.11Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 68 5.12Signature Payload Processing . . . . . . . . . . . . . . . . . . 69 5.13Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 70 5.14Notification Payload Processing . . . . . . . . . . . . . . . . . 71 5.15Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 73 6 Conclusions 75 A ISAKMP Security Association Attributes 76 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 76 A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . . . . 76 A.3 Supported Security Protocols . . . . . . . . . . . . . . . . . . 76 A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . . . . 77 A.4.1ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.4.2ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 A.4.3ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.4.4ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 B Defining a new Domain of Interpretation 78 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 79 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 79 B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 79 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 79 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 79 Maughan, Schertler, Schneider, Turner ISAKMP [Page 4] INTERNET-DRAFT ISAKMP March 10, 1998 List of Figures 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 17 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 23 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 27 5 Security Association Payload . . . . . . . . . . . . . . . . . . 28 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 29 7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 30 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 32 9 Identification Payload Format . . . . . . . . . . . . . . . . . . 33 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 34 11 Certificate Request Payload Format . . . . . . . . . . . . . . . 35 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 36 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 37 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 38 15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 39 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 42 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . 44 Maughan, Schertler, Schneider, Turner ISAKMP [Page 5] INTERNET-DRAFT ISAKMP March 10, 1998 1 Introduction This document describes an Internet Security Association and Key Manage- ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- tication, key management, and security associations to establish the re- quired security for government, commercial, and private communications on the Internet. The Internet Security Association and Key Management Protocol (ISAKMP) de- fines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). SAs contain all the information re- quired for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsula- tion), transport or application layer services, or self-protection of ne- gotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism. ISAKMP is distinct from key exchange protocols in order to cleanly sepa- rate the details of security association management (and key management) from the details of key exchange. There may be many different key ex- change protocols, each with different security properties. However, a common framework is required for agreeing to the format of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP serves as this common framework. Separating the functionality into three parts adds complexity to the se- curity analysis of a complete ISAKMP implementation. However, the sep- aration is critical for interoperability between systems with differing security requirements, and should also simplify the analysis of further evolution of a ISAKMP server. ISAKMP is intended to support the negotiation of SAs for security proto- cols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, etc.). By centralizing the management of the security associations, ISAKMP reduces the amount of duplicated functionality within each security protocol. ISAKMP can also reduce connection setup time, by negotiating a whole stack of services at once. The remainder of section 1 establishes the motivation for security nego- tiation and outlines the major components of ISAKMP, i.e. Security As- sociations and Management, Authentication, Public Key Cryptography, and Miscellaneous items. Section 2 presents the terminology and concepts as- sociated with ISAKMP. Section 3 describes the different ISAKMP payload formats. Section 4 describes how the payloads of ISAKMP are composed to- gether as exchange types to establish security associations and perform key exchanges in an authenticated manner. Additionally, security as- sociation modification, deletion, and error notification are discussed. Section 5 describes the processing of each payload within the context of Maughan, Schertler, Schneider, Turner ISAKMP [Page 6] INTERNET-DRAFT ISAKMP March 10, 1998 ISAKMP exchanges, including error handling and associated actions. The appendices provide the attribute values necessary for ISAKMP and require- ment for defining a new Domain of Interpretation (DOI) within ISAKMP. 1.1 Requirements Terminology 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]. 1.2 The Need for Negotiation ISAKMP extends the assertion in [DOW92] that authentication and key ex- changes must be combined for better security to include security associa- tion exchanges. The security services required for communications depends on the individual network configurations and environments. Organizations are setting up Virtual Private Networks (VPN), also known as Intranets, that will require one set of security functions for communications within the VPN and possibly many different security functions for communications outside the VPN to support geographically separate organizational compo- nents, customers, suppliers, sub-contractors (with their own VPNs), gov- ernment, and others. Departments within large organizations may require a number of security associations to separate and protect data (e.g. per- sonnel data, company proprietary data, medical) on internal networks and other security associations to communicate within the same department. Nomadic users wanting to ``phone home'' represent another set of secu- rity requirements. These requirements must be tempered with bandwidth challenges. Smaller groups of people may meet their security require- ments by setting up ``Webs of Trust''. ISAKMP exchanges provide these assorted networking communities the ability to present peers with the se- curity functionality that the user supports in an authenticated and pro- tected manner for agreement upon a common set of security attributes, i.e. an interoperable security association. 1.3 What can be Negotiated? Security associations must support different encryption algorithms, au- thentication mechanisms, and key establishment algorithms for other secu- rity protocols, as well as IP Security. Security associations must also support host-oriented certificates for lower layer protocols and user- oriented certificates for higher level protocols. Algorithm and mecha- nism independence is required in applications such as e-mail, remote lo- gin, and file transfer, as well as in session oriented protocols, routing protocols, and link layer protocols. ISAKMP provides a common security Maughan, Schertler, Schneider, Turner ISAKMP [Page 7] INTERNET-DRAFT ISAKMP March 10, 1998 association and key establishment protocol for this wide range of security protocols, applications, security requirements, and network environments. ISAKMP is not bound to any specific cryptographic algorithm, key gener- ation technique, or security mechanism. This flexibility is beneficial for a number of reasons. First, it supports the dynamic communications environment described above. Second, the independence from specific secu- rity mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are devel- oped or new attacks against current encryption algorithms, authentica- tion mechanisms and key exchanges are discovered, ISAKMP will allow the updating of the algorithms and mechanisms without having to develop a com- pletely new KMP or patch the current one. ISAKMP has basic requirements for its authentication and key exchange com- ponents. These requirements guard against denial of service, replay / re- flection, man-in-the-middle, and connection hijacking attacks. This is important because these are the types of attacks that are targeted against protocols. Complete Security Association (SA) support, which provides mechanism and algorithm independence, and protection from protocol threats are the strengths of ISAKMP. 1.4 Security Associations and Management A Security Association (SA) is a relationship between two or more entities that describes how the entities will utilize security services to communi- cate securely. This relationship is represented by a set of information that can be considered a contract between the entities. The information must be agreed upon and shared between all the entities. Sometimes the information alone is referred to as an SA, but this is just a physical in- stantiation of the existing relationship. The existence of this relation- ship, represented by the information, is what provides the agreed upon se- curity information needed by entities to securely interoperate. All enti- ties must adhere to the SA for secure communications to be possible. When accessing SA attributes, entities use a pointer or identifier refered to as the Security Parameter Index (SPI). [RFC-1825] provides details on IP Security Associations (SA) and Security Parameter Index (SPI) definitions. 1.4.1 Security Associations and Registration The SA attributes required and recommended for the IP Security (AH, ESP) are defined in [RFC-1825]. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent secu- rity MUST define their requirements for SA attributes. The separation of ISAKMP from a specific SA definition is important to ensure ISAKMP can es- Maughan, Schertler, Schneider, Turner ISAKMP [Page 8] INTERNET-DRAFT ISAKMP March 10, 1998 tablish SAs for all possible security protocols and applications. NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- ered when defining a security protocol or application. In order to facilitate easy identification of specific attributes (e.g. a specific encryption algorithm) among different network entites the at- tributes must be assigned identifiers and these identifiers must be reg- istered by a central authority. The Internet Assigned Numbers Authority (IANA) provides this function for the Internet. 1.4.2 ISAKMP Requirements Security Association (SA) establishment MUST be part of the key manage- ment protocol defined for IP based networks. The SA concept is required to support security protocols in a diverse and dynamic networking envi- ronment. Just as authentication and key exchange must be linked to pro- vide assurance that the key is established with the authenticated party [DOW92], SA establishment must be linked with the authentication and the key exchange protocol. ISAKMP provides the protocol exchanges to establish a security association between negotiating entities followed by the establishment of a security association by these negotiating entities in behalf of some protocol (e.g. ESP/AH). First, an initial protocol exchange allows a basic set of secu- rity attributes to be agreed upon. This basic set provides protection for subsequent ISAKMP exchanges. It also indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol. If a basic set of security attributes is already in place between the ne- gotiating server entities, the initial ISAKMP exchange may be skipped and the establishment of a security association can be done directly. After the basic set of security attributes has been agreed upon, initial iden- tity authenticated, and required keys generated, the established SA can be used for subsequent communications by the entity that invoked ISAKMP. The basic set of SA attributes that MUST be implemented to provide ISAKMP interoperability are defined in Appendix A. 1.5 Authentication A very important step in establishing secure network communications is au- thentication of the entity at the other end of the communication. Many authentication mechanisms are available. Authentication mechanisms fall into two catagories of strength - weak and strong. Sending cleartext keys or other unprotected authenticating information over a network is weak, due to the threat of reading them with a network sniffer. Additionally, sending one-way hashed poorly-chosen keys with low entropy is also weak, due to the threat of brute-force guessing attacks on the sniffed mes- Maughan, Schertler, Schneider, Turner ISAKMP [Page 9] INTERNET-DRAFT ISAKMP March 10, 1998 sages. While passwords can be used for establishing identity, they are not considered in this context because of recent statements from the In- ternet Architecture Board [IAB]. Digital signatures, such as the Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are public key based strong authentication mechanisms. When using pub- lic key digital signatures each entity requires a public key and a pri- vate key. Certificates are an essential part of a digital signature au- thentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or application) to its public keys and pos- sibly other security-related information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a trusted third party or certificate authority to create, sign and properly distribute certificates. For more detailed information on digital signa- tures, such as DSS and RSA, and certificates see [Schneier]. 1.5.1 Certificate Authorities Certificates require an infrastructure for generation, verification, re- vocation, management and distribution. The Internet Policy Registration Authority (IPRA) [RFC-1422] has been established to direct this infras- tructure for the IETF. The IPRA certifies Policy Certification Authori- ties (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [DNSSEC] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide X.509 certificates to users. The U.S. Post Office is devel- oping a (CA) hierarchy. The NIST Public Key Infrastructure Working Group has also been doing work in this area. The DOD Multi Level Information System Security Initiative (MISSI) program has begun deploying a certifi- cate infrastructure for the U.S. Government. Alternatively, if no infras- tructure exists, the PGP Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other. 1.5.2 Entity Naming An entity's name is its identity and is bound to its public keys in cer- tificates. The CA MUST define the naming semantics for the certificates it issues. See the UNINETT PCA Policy Statements [Berge] for an example of how a CA defines its naming policy. When the certificate is verified, the name is verified and that name will have meaning within the realm of that CA. An example is the DNS security extensions which make DNS servers CAs for the zones and nodes they serve. Resource records are provided for public keys and signatures on those keys. The names associated with the keys are IP addresses and domain names which have meaning to entities ac- Maughan, Schertler, Schneider, Turner ISAKMP [Page 10] INTERNET-DRAFT ISAKMP March 10, 1998 cessing the DNS for this information. A Web of Trust is another example. When webs of trust are set up, names are bound with the public keys. In PGP the name is usually the entity's e-mail address which has meaning to those, and only those, who understand e-mail. Another web of trust could use an entirely different naming scheme. 1.5.3 ISAKMP Requirements Strong authentication MUST be provided on ISAKMP exchanges. Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect. Without authentication you are unable to trust an entity's identification, which makes access control questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will protect subsequent communications from passive eavesdroppers, without au- thentication it is possible that the SA and key may have been established with an adversary who performed an active man-in-the-middle attack and is now stealing all your personal data. A digital signature algorithm MUST be used within ISAKMP's authentication component. However, ISAKMP does not mandate a specific signature algo- rithm or certificate authority (CA). ISAKMP allows an entity initiating communications to indicate which CAs it supports. After selection of a CA, the protocol provides the messages required to support the actual au- thentication exchange. The protocol provides a facility for identifica- tion of different certificate authorities, certificate types (e.g. X.509, PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certifi- cates identified. ISAKMP utilizes digital signatures, based on public key cryptography, for authentication. There are other strong authentication systems available, which could be specified as additional optional authentication mechanisms for ISAKMP. Some of these authentication systems rely on a trusted third party called a key distribution center (KDC) to distribute secret session keys. An example is Kerberos, where the trusted third party is the Ker- beros server, which holds secret keys for all clients and servers within its network domain. A client's proof that it holds its secret key pro- vides authenticaton to a server. The ISAKMP specification does not specify the protocol for communicating with the trusted third parties (TTP) or certificate directory services. These protocols are defined by the TTP and directory service themselves and are outside the scope of this specification. The use of these addi- tional services and protocols will be described in a Key Exchange specific document. Maughan, Schertler, Schneider, Turner ISAKMP [Page 11] INTERNET-DRAFT ISAKMP March 10, 1998 1.6 Public Key Cryptography Public key cryptography is the most flexible, scalable, and efficient way for users to obtain the shared secrets and session keys needed to support the large number of ways Internet users will interoperate. Many key gen- eration algorithms, that have different properties, are available to users (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection. NOTE: Cryptographic keys can protect information for a considerable length of time. However, this is based on the assumption that keys used for pro- tection of communications are destroyed after use and not kept for any reason. 1.6.1 Key Exchange Properties Key Establishment (Key Generation / Key Transport): The two common methods of using public key cryptography for key establishment are key transport and key generation. An example of key transport is the use of the RSA al- gorithm to encrypt a randomly generated session key (for encrypting subse- quent communications) with the recipient's public key. The encrypted ran- dom key is then sent to the recipient, who decrypts it using his private key. At this point both sides have the same session key, however it was created based on input from only one side of the communications. The ben- efit of the key transport method is that it has less computational over- head than the following method. The Diffie-Hellman (D-H) algorithm il- lustrates key generation using public key cryptography. The D-H algorithm is begun by two users exchanging public information. Each user then math- ematically combines the other's public information along with their own secret information to compute a shared secret value. This secret value can be used as a session key or as a key encryption key for encrypting a randomly generated session key. This method generates a session key based on public and secret information held by both users. The benefit of the D-H algorithm is that the key used for encrypting messages is based on information held by both users and the independence of keys from one key exchange to another provides perfect forward secrecy. Detailed descrip- tions of these algorithms can be found in [Schneier]. There are a number of variations on these two key generation schemes and these variations do not necessarily interoperate. Key Exchange Authentication: Key exchanges may be authenticated during the protocol or after protocol completion. Authentication of the key exchange during the protocol is provided when each party provides proof it has the secret session key before the end of the protocol. Proof can be provided by encrypting known data in the secret session key during the protocol ex- change. Authentication after the protocol must occur in subsequent commu- Maughan, Schertler, Schneider, Turner ISAKMP [Page 12] INTERNET-DRAFT ISAKMP March 10, 1998 nications. Authentication during the protocol is preferred so subsequent communications are not initiated if the secret session key is not estab- lished with the desired party. Key Exchange Symmetry: A key exchange provides symmetry if either party can initiate the exchange and exchanged messages can cross in transit without affecting the key that is generated. This is desirable so that computation of the keys does not require either party to know who initi- ated the exchange. While key exchange symmetry is desirable, symmetry in the entire key management protocol may provide a vulnerablity to reflec- tion attacks. Perfect Forward Secrecy: As described in [DOW92], an authenticated key ex- change protocol provides perfect forward secrecy if disclosure of long- term secret keying material does not compromise the secrecy of the ex- changed keys from previous communications. The property of perfect for- ward secrecy does not apply to key exchange without authentication. 1.6.2 ISAKMP Requirements An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD choose additional key establishment algorithms based on their require- ments. ISAKMP does not specify a specific key exchange. However, [IKE] describes a proposal for using the Oakley key exchange [Oakley] in con- junction with ISAKMP. Requirements that should be evaluated when choosing a key establishment algorithm include establishment method (generation vs. transport), perfect forward secrecy, computational overhead, key escrow, and key strength. Based on user requirements, ISAKMP allows an entity initiating communications to indicate which key exchanges it supports. After selection of a key exchange, the protocol provides the messages re- quired to support the actual key establishment. 1.7 ISAKMP Protection 1.7.1 Anti-Clogging (Denial of Service) Of the numerous security services available, protection against denial of service always seems to be one of the most difficult to address. A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the com- puting resources from attack without spending excessive CPU resources to determine its authenticity. An exchange prior to CPU-intensive public key operations can thwart some denial of service attempts (e.g. simple flood- ing with bogus IP source addresses). Absolute protection against denial of service is impossible, but this anti-clogging token provides a tech- Maughan, Schertler, Schneider, Turner ISAKMP [Page 13] INTERNET-DRAFT ISAKMP March 10, 1998 nique for making it easier to handle. The use of an anti-clogging token was introduced by Karn and Simpson in [Karn]. It should be noted that in the exchanges shown in section 4, the anti- clogging mechanism should be used in conjuction with a garbage-state col- lection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti-clogging only phase, as was done in [Karn]. 1.7.2 Connection Hijacking ISAKMP prevents connection hijacking by linking the authentication, key exchange and security association exchanges. This linking prevents an attacker from allowing the authentication to complete and then jumping in and impersonating one entity to the other during the key and security association exchanges. 1.7.3 Man-in-the-Middle Attacks Man-in-the-Middle attacks include interception, insertion, deletion, and modification of messages, reflecting messages back at the sender, re- playing old messages and redirecting messages. ISAKMP features prevent these types of attacks from being successful. The linking of the ISAKMP exchanges prevents the insertion of messages in the protocol exchange. The ISAKMP protocol state machine is defined so deleted messages will not cause a partial SA to be created, the state machine will clear all state and return to idle. The state machine also prevents reflection of a mes- sage from causing harm. The requirement for a new cookie with time vari- ant material for each new SA establishment prevents attacks that involve replaying old messages. The ISAKMP strong authentication requirement pre- vents an SA from being established with anyone other than the intended party. Messages may be redirected to a different destination or modified but this will be detected and an SA will not be established. The ISAKMP specification defines where abnormal processing has occurred and recom- mends notifying the appropriate party of this abnormality. 1.8 Multicast Communications It is expected that multicast communications will require the same secu- rity services as unicast communications and may introduce the need for additional security services. The issues of distributing SPIs for mul- ticast traffic are presented in [RFC-1825]. Multicast security issues are also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will Maughan, Schertler, Schneider, Turner ISAKMP [Page 14] INTERNET-DRAFT ISAKMP March 10, 1998 support multicast key distribution. For an introduction to the issues re- lated to multicast security, consult the Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's research in this area. 2 Terminology and Concepts 2.1 ISAKMP Terminology Security Protocol: A Security Protocol consists of an entity at a single point in the network stack, performing a security service for network com- munication. For example, IPSEC ESP and IPSEC AH are two different secu- rity protocols. TLS is another example. Security Protocols may perform more than one service, for example providing integrity and confidentiality in one module. Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a pro- tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security pro- tocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole. Security Association (SA): A Security Association is a security-protocol- specific set of parameters that completely defines the services and mech- anisms necessary to protect traffic at that security protocol location. These parameters can include algorithm identifiers, modes, cryptographic keys, etc. The SA is referred to by its associated security protocol (for example, ``ISAKMP SA'', ``ESP SA'', ``TLS SA''). ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs. Security Parameter Index (SPI): An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. The uniqueness of the SPI is implementation dependent, but could be based per system, per protocol, or other options. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. The DOI will also determine which SPIs (i.e. initiator's or re- sponder's) are sent during communication. Maughan, Schertler, Schneider, Turner ISAKMP [Page 15] INTERNET-DRAFT ISAKMP March 10, 1998 Domain of Interpretation: A Domain of Interpretation (DOI) defines payload formats, exchange types, and conventions for naming security-relevant in- formation such as security policies or cryptographic algorithms and modes. A Domain of Interpretation (DOI) identifier is used to interpret the pay- loads of ISAKMP payloads. A system SHOULD support multiple Domains of In- terpretation simultaneously. The concept of a DOI is based on previous work by the TSIG CIPSO Working Group, but extends beyond security label interpretation to include naming and interpretation of security services. A DOI defines: o A ``situation'': the set of information that will be used to determine the required security services. o The set of security policies that must, and may, be supported. o A syntax for the specification of proposed security services. o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities. o The specific formats of the various payload contents. o Additional exchange types, if required. The rules for the IETF IP Security DOI are presented in [IPDOI]. Speci- fications of the rules for customized DOIs will be presented in separate documents. Situation: A situation contains all of the security-relevant information that a system considers necessary to decide the security services required to protect the session being negotiated. The situation may include ad- dresses, security classifications, modes of operation (normal vs. emer- gency), etc. Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable to protect traffic under a given situation. Payload: ISAKMP defines several types of payloads, which are used to transfer information such as security association data, or key exchange data, in DOI-defined formats. A payload consists of a generic payload header and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and interpret these payloads. Mul- tiple payloads can be sent in a single ISAKMP message. See section 3 for more details on the payload types, and [IPDOI] for the formats of the IETF Maughan, Schertler, Schneider, Turner ISAKMP [Page 16] INTERNET-DRAFT ISAKMP March 10, 1998 IP Security DOI payloads. Exchange Type: An exchange type is a specification of the number of mes- sages in an ISAKMP exchange, and the payload types that are contained in each of those messages. Each exchange type is designed to provide a par- ticular set of security services, such as anonymity of the participants, perfect forward secrecy of the keying material, authentication of the par- ticipants, etc. Section 4.1 defines the default set of ISAKMP exchange types. Other exchange types can be added to support additional key ex- changes, if required. 2.2 ISAKMP Placement Figure 1 is a high level view of the placement of ISAKMP within a system context in a network architecture. An important part of negotiating secu- rity services is to consider the entire ``stack'' of individual SAs as a unit. This is referred to as a ``protection suite''. +------------+ +--------+ +--------------+ ! DOI ! ! ! ! Application ! ! Definition ! <----> ! ISAKMP ! ! Process ! +------------+ --> ! ! !--------------! +--------------+ ! +--------+ ! Appl Protocol! ! Key Exchange ! ! ^ ^ +--------------+ ! Definition !<-- ! ! ^ +--------------+ ! ! ! ! ! ! !----------------! ! ! v ! ! +-------+ v v ! API ! +---------------------------------------------+ +-------+ ! Socket Layer ! ! !---------------------------------------------! v ! Transport Protocol (TCP / UDP) ! +----------+ !---------------------------------------------! ! Security ! <----> ! IP ! ! Protocol ! !---------------------------------------------! +----------+ ! Link Layer Protocol ! +---------------------------------------------+ Figure 1: ISAKMP Relationships Maughan, Schertler, Schneider, Turner ISAKMP [Page 17] INTERNET-DRAFT ISAKMP March 10, 1998 2.3 Negotiation Phases ISAKMP offers two ``phases'' of negotiation. In the first phase, two en- tities (e.g. ISAKMP servers) agree on how to protect further negotiation traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to protect the negotiations for the Protocol SA being requested. Two entities (e.g. ISAKMP servers) can negotiate (and have active) multi- ple ISAKMP SAs. The second phase of negotiation is used to establish security associations for other security protocols. This second phase can be used to estab- lish many security associations. The security associations established by ISAKMP during this phase can be used by a security protocol to protect many message/data exchanges. While the two-phased approach has a higher start-up cost for most simple scenarios, there are several reasons that it is beneficial for most cases. First, entities (e.g. ISAKMP servers) can amortize the cost of the first phase across several second phase negotiations. This allows multiple SAs to be established between peers over time without having to start over for each communication. Second, security services negotiated during the first phase provide secu- rity properties for the second phase. For example, after the first phase of negotiation, the encryption provided by the ISAKMP SA can provide iden- tity protection, potentially allowing the use of simpler second-phase ex- changes. On the other hand, if the channel established during the first phase is not adequate to protect identities, then the second phase must negotiate adequate security mechanisms. Third, having an ISAKMP SA in place considerably reduces the cost of ISAKMP management activity - without the ``trusted path'' that an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have to go through a complete re-authentication for each error notification or deletion of an SA. Negotiation during each phase is accomplished using ISAKMP-defined ex- changes (see section 4) or exchanges defined for a key exchange within a DOI. Note that security services may be applied differently in each negotiation phase. For example, different parties are being authenticated during each of the phases of negotiation. During the first phase, the parties being authenticated may be the ISAKMP servers/hosts, while during the second phase, users or application level programs are being authenticated. Maughan, Schertler, Schneider, Turner ISAKMP [Page 18] INTERNET-DRAFT ISAKMP March 10, 1998 2.4 Identifying Security Associations While bootstrapping secure channels between systems, ISAKMP cannot assume the existence of security services, and must provide some protections for itself. Therefore, ISAKMP considers an ISAKMP Security Association to be different than other types, and manages ISAKMP SAs itself, in their own name space. ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI field in the Proposal payload are used during SA establishment to identify the SA for other security protocols. The interpretation of these four fields is dependent on the operation taking place. The following table shows the presence or absence of several fields during SA establishment. The following fields are necessary for various opera- tions associated with SA establishment: cookies in the ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in the Proposal payload. An 'X' in the column means the value MUST be present. An 'NA' in the col- umn means a value in the column is Not Applicable to the operation. __#_____________Operation____________I-Cookie__R-Cookie__Message_ID__SPI_ (1) Start ISAKMP SA negotiation X 0 0 0 (2) Respond ISAKMP SA negotiation X X 0 0 (3) Init other SA negotiation X X X X (4) Respond other SA negotiation X X X X (5) Other (KE, ID, etc.) X X X/0 NA (6) Security Protocol (ESP, AH) NA NA NA X In the first line (1) of the table, the initiator includes the Initiator Cookie field in the ISAKMP Header, using the procedures outlined in sec- tions 2.5.3 and 3.1. In the second line (2) of the table, the responder includes the Initia- tor and Responder Cookie fields in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged between ISAKMP peers, depending on the ISAKMP exchange type used during the phase 1 negotiation. Once the phase 1 exchange is completed, the Ini- tiator and Responder cookies are included in the ISAKMP Header of all sub- sequent communications between the ISAKMP peers. During phase 1 negotiations, the initiator and responder cookies deter- mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie. In the third line (3) of the table, the initiator associates a Message ID with the Protocols contained in the SA Proposal. This Message ID and the initiator's SPI(s) to be associated with each protocol in the Proposal are Maughan, Schertler, Schneider, Turner ISAKMP [Page 19] INTERNET-DRAFT ISAKMP March 10, 1998 sent to the responder. The SPI(s) will be used by the security protocols once the phase 2 negotiation is completed. In the fourth line (4) of the table, the responder includes the same Mes- sage ID and the responder's SPI(s) to be associated with each protocol in the accepted Proposal. This information is returned to the initiator. In the fifth line (5) of the table, the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in-progress protocol negotiation. This is only applicable for a phase 2 exchange and the value SHOULD be 0 for a phase 1 exchange because the combined cook- ies identify the ISAKMP SA. The SPI field in the Proposal payload is not applicable because the Proposal payload is only used during the SA negoti- ation message exchange (steps 3 and 4). In the sixth line (6) of the table, the phase 2 negotiation is complete. The security protocols use the SPI(s) to determine which security services and mechanisms to apply to the communication between them. The SPI value shown in the sixth line (6) is not the SPI field in the Proposal payload, but the SPI field contained within the security protocol header. During the SA establishment, a SPI MUST be generated. ISAKMP is designed to handle variable sized SPIs. This is accomplished by using the SPI Size field within the Proposal payload during SA establishment. Handling of SPIs will be outlined by the DOI specification (e.g. [IPDOI]). When a security association (SA) is initially established, one side as- sumes the role of initiator and the other the role of responder. Once the SA is established, both the original initiator and responder can initiate a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirec- tional in nature. Additionally, ISAKMP allows both initiator and responder to have some con- trol during the negotiation process. While ISAKMP is designed to allow an SA negotiation that includes multiple proposals, the initiator can main- tain some control by only making one proposal in accordance with the ini- tiator's local security policy. Once the initiator sends a proposal con- taining more than one proposal (which are sent in decreasing preference order), the initiator relinquishes control to the responder. Once the re- sponder is controlling the SA establishment, the responder can make its policy take precedence over the initiator within the context of the multi- ple options offered by the initiator. This is accomplished by selecting the proposal best suited for the responder's local security policy and re- turning this selection to the initiator. Maughan, Schertler, Schneider, Turner ISAKMP [Page 20] INTERNET-DRAFT ISAKMP March 10, 1998 2.5 Miscellaneous 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP us- ing the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbered Authority (IANA). Im- plementations MAY additionally support ISAKMP over other transport proto- cols or over IP itself. 2.5.2 RESERVED Fields The existence of RESERVED fields within ISAKMP payloads are used strictly to preserve byte alignment. All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value and discard the packet if other values are found. 2.5.3 Anti-Clogging Token (``Cookie'') Creation The details of cookie generation are implementation dependent, but MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]): 1. The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with Diffie- Hellman requests from randomly chosen IP addresses or ports. 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie. 3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources. Karn's suggested method for creating the cookie is to perform a fast hash (e.g. MD5) over the IP Source and Destination Address, the UDP Source and Destination Ports and a locally generated secret random value. ISAKMP re- Maughan, Schertler, Schneider, Turner ISAKMP [Page 21] INTERNET-DRAFT ISAKMP March 10, 1998 quires that the cookie be unique for each SA establishment to help pre- vent replay attacks, therefore, the date and time MUST be added to the in- formation hashed. The generated cookies are placed in the ISAKMP Header (described in section 3.1) Initiator and Responder cookie fields. These fields are 8 octets in length, thus, requiring a generated cookie to be 8 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are uni-directional transmissions and are done under the protection of an ex- isting ISAKMP SA, thus, not requiring the generation of a new cookie. One exception to this is the transmission of a Notify message during a Phase 1 exchange, prior to completing the establishment of an SA. Sections 3.14 and 4.8 provide additional details. 3 ISAKMP Payloads ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- changes (see Section 4) are shown using network octet ordering. Addition- ally, all ISAKMP messages MUST be aligned at 4-octet multiples. 3.1 ISAKMP Header Format An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, pro- viding the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks. The ISAKMP Header fields are defined as follows: o Initiator Cookie (8 octets) - Cookie of entity that initiated SA establishment, SA notification, or SA deletion. o Responder Cookie (8 octets) - Cookie of entity that is responding to Maughan, Schertler, Schneider, Turner ISAKMP [Page 22] INTERNET-DRAFT ISAKMP March 10, 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ISAKMP Header Format an SA establishment request, SA notification, or SA deletion. o Next Payload (1 octet) - Indicates the type of the first payload in the message. The format for each payload is defined in sections 3.4 through 3.16. The processing for the payloads is defined in section 5. _____Next_Payload_Type_______Value____ NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14 - 127 Private USE 128 - 255 o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations Maughan, Schertler, Schneider, Turner ISAKMP [Page 23] INTERNET-DRAFT ISAKMP March 10, 1998 based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than its own. o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical. o Exchange Type (1 octet) - indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges. ____Exchange_Type______Value___ NONE 0 Base 1 Identity Protection 2 Authentication Only 3 Aggressive 4 Informational 5 ISAKMP Future Use 6 - 31 DOI Specific Use 32 - 255 o Flags (1 octet) - indicates specific options that are set for the ISAKMP exchange. The flags listed below are specified in the Flags field beginning with the least significant bit, i.e the Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags field, and the Authentication Only bit is bit 2 of the Flags field. The remaining bits of the Flags field MUST be set to 0 prior to transmission. -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie. It is RECOMMENDED that encryption of communications be done as soon as possible between the peers. For all ISAKMP exchanges described in section 4.1, the encryption SHOULD begin after both parties have exchanged Key Exchange payloads. If the E(ncryption Bit) is not set (0), the payloads are not encrypted. -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Maughan, Schertler, Schneider, Turner ISAKMP [Page 24] INTERNET-DRAFT ISAKMP March 10, 1998 Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation. If set(1), the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the en- tity which set the Commit Bit. This indicates that the SA estab- lishment was successful and either entity can now proceed with en- crypted traffic communication. In addition to synchronizing key ex- change, the Commit Bit can be used to protect against loss of trans- missions over unreliable networks and guard against the need for mul- tiple retransmissions. NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negoti- ation message following a Phase 1 exchange or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the re- ceived message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final mes- sage. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established. -- A(uthentication Only Bit) (1 bit) - This bit is intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption (e.g. "emergency mode"). Section 4.8 states that a Phase 2 Informational Exchange MUST be sent under the protection of an ISAKMP SA. This is the only exception to that policy. If the Authentication Only bit is set (1), only authentication security services will be applied to the entire Notify payload of the Informational Exchange and the payload will not be encrypted. o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. o Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. Maughan, Schertler, Schneider, Turner ISAKMP [Page 25] INTERNET-DRAFT ISAKMP March 10, 1998 3.2 Generic Payload Header Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a generic header, shown in Figure 3, which provides a payload "chaining" capability and clearly defines the boundaries of a payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Generic Payload Header The Generic Payload Header fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. 3.3 Data Attributes There are several instances within ISAKMP where it is necessary to repre- sent Data Attributes. An example of this is the Security Association (SA) Attributes contained in the Transform payload (described in section 3.6). These Data Attributes are not an ISAKMP payload, but are contained within ISAKMP payloads. The format of the Data Attributes provides the flexibil- ity for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data At- tributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described below. Specific in- formation about the attributes for each domain will be described in a DOI document, e.g. IPSEC DOI [IPDOI]. The Data Attributes fields are defined as follows: o Attribute Type (2 octets) - Unique identifier for each type of attribute. These attributes are defined as part of the DOI-specific Maughan, Schertler, Schneider, Turner ISAKMP [Page 26] INTERNET-DRAFT ISAKMP March 10, 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Attribute Type ! AF=0 Attribute Length ! !F! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AF=0 Attribute Value . . AF=1 Not Transmitted . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Data Attributes information. The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form. o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present. o Attribute Value (variable length) - Value of the attribute associated with the DOI-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. 3.4 Security Association Payload The Security Association Payload is used to negotiate security attributes and to indicate the Domain of Interpretation (DOI) and Situation under which the negotiation is taking place. Figure 5 shows the format of the Security Association payload. The Security Association Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field MUST NOT contain the values for the Proposal or Transform payloads as they are considered part of the security association negotiation. For example, this Maughan, Schertler, Schneider, Turner ISAKMP [Page 27] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Security Association Payload field would contain the value "10" (Nonce payload) in the first message of a Base Exchange (see Section 4.4) and the value "0" in the first message of an Identity Protect Exchange (see Section 4.5). o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this negotiation is taking place. The DOI is a 32-bit unsigned integer. A DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be used for any protocol during the Phase 2 exchange. The necessary SA Attributes are defined in A.4. A DOI value of 1 is assigned to the IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for future use. IANA will not normally assign a DOI value without referencing some public specification, such as an Internet RFC. Other DOI's can be defined using the description in appendix B. This field MUST be present within the Security Association payload. o Situation (variable length) - A DOI-specific field that identifies the situation under which this negotiation is taking place. The Situation is used to make policy decisions regarding the security attributes being negotiated. Specifics for the IETF IP Security DOI Situation are detailed in [IPDOI]. This field MUST be present within the Security Association payload. The payload type for the Security Association Payload is one (1). Maughan, Schertler, Schneider, Turner ISAKMP [Page 28] INTERNET-DRAFT ISAKMP March 10, 1998 3.5 Proposal Payload The Proposal Payload contains information used during Security Associa- tion negotiation. The proposal consists of security mechanisms, or trans- forms, to be used to secure the communications channel. Figure 6 shows the format of the Proposal Payload. A description of its use can be found in section 4.2. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (variable) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Proposal Payload Format The Proposal Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "2" or "0". If there are additional Proposal payloads in the message, then this field will be 2. If the current Proposal payload is the last within the security association proposal, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including generic payload header, the Proposal payload, and all Transform payloads associated with this proposal. In the event there are multiple proposals with the same proposal number (see section 4.2), the Payload Length field only applies to the current Proposal payload and not to all Proposal payloads. o Proposal # (1 octet) - Identifies the Proposal number for the current payload. A description of the use of this field is found in section 4.2. o Protocol-Id (1 octet) - Specifies the protocol identifier for the current negotiation. Examples might include IPSEC ESP, IPSEC AH, OSPF, TLS, etc. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Maughan, Schertler, Schneider, Turner ISAKMP [Page 29] INTERNET-DRAFT ISAKMP March 10, 1998 Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. If the SPI Size is not a multiple of 4 octets it will have some impact on the SPI field and the alignment of all payloads in the message. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. o # of Transforms (1 octet) - Specifies the number of transforms for the Proposal. Each of these is contained in a Transform payload. o SPI (variable) - The sending entity's SPI. In the event the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload, however, it can be applied at the end of the message. The payload type for the Proposal Payload is two (2). 3.6 Transform Payload The Transform Payload contains information used during Security Associa- tion negotiation. The Transform payload consists of a specific security mechanism, or transforms, to be used to secure the communications chan- nel. The Transform payload also contains the security association at- tributes associated with the specific transform. These SA attributes are DOI-specific. Figure 7 shows the format of the Transform Payload. A de- scription of its use can be found in section 4.2. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform # ! Transform-Id ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ SA Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Transform Payload Format The Transform Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next Maughan, Schertler, Schneider, Turner ISAKMP [Page 30] INTERNET-DRAFT ISAKMP March 10, 1998 payload in the message. This field MUST only contain the value "3" or "0". If there are additional Transform payloads in the proposal, then this field will be 3. If the current Transform payload is the last within the proposal, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes. o Transform # (1 octet) - Identifies the Transform number for the current payload. If there is more than one transform proposed for a specific protocol within the Proposal payload, then each Transform payload has a unique Transform number. A description of the use of this field is found in section 4.2. o Transform-Id (1 octet) - Specifies the Transform identifier for the protocol within the current proposal. These transforms are defined by the DOI and are dependent on the protocol being negotiated. o RESERVED2 (2 octets) - Unused, set to 0. o SA Attributes (variable length) - This field contains the security association attributes as defined for the transform given in the Transform-Id field. The SA Attributes SHOULD be represented using the Data Attributes format described in section 3.3. If the SA Attributes are not aligned on 4-byte boundaries, then subsequent payloads will not be aligned and any padding will be added at the end of the message to make the message 4-octet aligned. The payload type for the Transform Payload is three (3). 3.7 Key Exchange Payload The Key Exchange Payload supports a variety of key exchange techniques. Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload. The Key Exchange Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. Maughan, Schertler, Schneider, Turner ISAKMP [Page 31] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Exchange Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Key Exchange Payload Format o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Key Exchange Data (variable length) - Data required to generate a session key. The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm. This field may also contain pre-placed key indicators. The payload type for the Key Exchange Payload is four (4). 3.8 Identification Payload The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authen- ticity of information. Figure 9 shows the format of the Identification Payload. The Identification Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o ID Type (1 octet) - Specifies the type of Identification being used. Maughan, Schertler, Schneider, Turner ISAKMP [Page 32] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! DOI Specific ID Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Identification Payload Format This field is DOI-dependent. o DOI Specific ID Data (3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0. o Identification Data (variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by the ID Type field. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI]. The payload type for the Identification Payload is five (5). 3.9 Certificate Payload The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload. NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types. The Certificate Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the Maughan, Schertler, Schneider, Turner ISAKMP [Page 33] INTERNET-DRAFT ISAKMP March 10, 1998 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Encoding ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Certificate Payload Format message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. _________Certificate_Type____________Value____ NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255 o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. The payload type for the Certificate Payload is six (6). Maughan, Schertler, Schneider, Turner ISAKMP [Page 34] INTERNET-DRAFT ISAKMP March 10, 1998 3.10 Certificate Request Payload The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory ser- vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- cates. The Certificate Request payload MUST be accepted at any point dur- ing the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert. Type ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Authority ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Certificate Request Payload Format The Certificate Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Certificate Type (1 octet) - Contains an encoding of the type of certificate requested. Acceptable values are listed in section 3.9. o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how Maughan, Schertler, Schneider, Turner ISAKMP [Page 35] INTERNET-DRAFT ISAKMP March 10, 1998 much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included. The payload type for the Certificate Request Payload is seven (7). 3.11 Hash Payload The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating en- tities. Figure 12 shows the format of the Hash Payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Hash Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Hash Payload Format The Hash Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Hash Data (variable length) - Data that results from applying the hash routine to the ISAKMP message and/or state. The payload type for the Hash Payload is eight (8). Maughan, Schertler, Schneider, Turner ISAKMP [Page 36] INTERNET-DRAFT ISAKMP March 10, 1998 3.12 Signature Payload The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non- repudiation services. Figure 13 shows the format of the Signature Pay- load. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Signature Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Signature Payload Format The Signature Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Signature Data (variable length) - Data that results from applying the digital signature function to the ISAKMP message and/or state. The payload type for the Signature Payload is nine (9). 3.13 Nonce Payload The Nonce Payload contains random data used to guarantee liveness dur- ing an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key ex- change, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a Maughan, Schertler, Schneider, Turner ISAKMP [Page 37] INTERNET-DRAFT ISAKMP March 10, 1998 separate payload. However, this is defined by the key exchange, not by ISAKMP. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Nonce Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Nonce Payload Format The Nonce Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Nonce Data (variable length) - Contains the random data generated by the transmitting entity. The payload type for the Nonce Payload is ten (10). 3.14 Notification Payload The Notification Payload can contain both ISAKMP and DOI-specific data and is used to transmit informational data, such as error conditions, to an ISAKMP peer. It is possible to send multiple Notification payloads in a single ISAKMP message. Figure 15 shows the format of the Notification Payload. Notification which occurs during, or is concerned with, a Phase 1 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected. Maughan, Schertler, Schneider, Turner ISAKMP [Page 38] INTERNET-DRAFT ISAKMP March 10, 1998 Notification which occurs during, or is concerned with, a Phase 2 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current nego- tiation. One example for this type of notification is to indicate why a proposal was rejected. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Notification Payload Format The Notification Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this notification is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. o Protocol-Id (1 octet) - Specifies the protocol identifier for the current notification. Examples might include ISAKMP, IPSEC ESP, IPSEC AH, OSPF, TLS, etc. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Maughan, Schertler, Schneider, Turner ISAKMP [Page 39] INTERNET-DRAFT ISAKMP March 10, 1998 Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. o Notify Message Type (2 octets) - Specifies the type of notification message (see section 3.14.1). Additional text, if specified by the DOI, is placed in the Notification Data field. o SPI (variable length) - Security Parameter Index. The receiving entity's SPI. The use of the SPI field is described in section 2.4. The length of this field is determined by the SPI Size field and is not necessarily aligned to a 4 octet boundary. o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are DOI-specific. The payload type for the Notification Payload is eleven (11). 3.14.1 Notify Message Types Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. For example, a secure front end or security gateway may use the Notify message to syn- chronize SA communication. The table below lists the Nofitication mes- sages and their corresponding values. Values in the Private Use range are expected to be DOI-specific values. Maughan, Schertler, Schneider, Turner ISAKMP [Page 40] INTERNET-DRAFT ISAKMP March 10, 1998 NOTIFY MESSAGES - ERROR TYPES __________Errors______________Value_____ INVALID-PAYLOAD-TYPE 1 DOI-NOT-SUPPORTED 2 SITUATION-NOT-SUPPORTED 3 INVALID-COOKIE 4 INVALID-MAJOR-VERSION 5 INVALID-MINOR-VERSION 6 INVALID-EXCHANGE-TYPE 7 INVALID-FLAGS 8 INVALID-MESSAGE-ID 9 INVALID-PROTOCOL-ID 10 INVALID-SPI 11 INVALID-TRANSFORM-ID 12 ATTRIBUTES-NOT-SUPPORTED 13 NO-PROPOSAL-CHOSEN 14 BAD-PROPOSAL-SYNTAX 15 PAYLOAD-MALFORMED 16 INVALID-KEY-INFORMATION 17 INVALID-ID-INFORMATION 18 INVALID-CERT-ENCODING 19 INVALID-CERTIFICATE 20 CERT-TYPE-UNSUPPORTED 21 INVALID-CERT-AUTHORITY 22 INVALID-HASH-INFORMATION 23 AUTHENTICATION-FAILED 24 INVALID-SIGNATURE 25 ADDRESS-NOTIFICATION 26 NOTIFY-SA-LIFETIME 27 CERTIFICATE-UNAVAILABLE 28 RESERVED (Future Use) 29 - 8191 Private Use 8192 - 16383 NOTIFY MESSAGES - STATUS TYPES _________Status_____________Value______ CONNECTED 16384 RESERVED (Future Use) 16385 - 24575 DOI-specific codes 24576 - 32767 Private Use 32768 - 40959 RESERVED (Future Use) 40960 - 65535 3.15 Delete Payload The Delete Payload contains a protocol-specific security association iden- tifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 16 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload, Maughan, Schertler, Schneider, Turner ISAKMP [Page 41] INTERNET-DRAFT ISAKMP March 10, 1998 however, each SPI MUST be for the same protocol. Mixing of Protocol Iden- tifiers MUST NOT be performed with the Delete payload. Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id of ISAKMP and the SPIs are the initiator and responder cookies from the ISAKMP Header. Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s). NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-Id ! SPI Size ! # of SPIs ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index(es) (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Delete Payload Format The Delete Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this deletion is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. o Protocol-Id (1 octet) - ISAKMP can establish security associations Maughan, Schertler, Schneider, Turner ISAKMP [Page 42] INTERNET-DRAFT ISAKMP March 10, 1998 for various protocols, including ISAKMP and IPSEC. This field identi- fies which security association database to apply the delete request. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted. o # of SPIs (2 octets) - The number of SPIs contained in the Delete payload. The size of each SPI is defined by the SPI Size field. o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. Values for this field are DOI and protocol specific. The length of this field is determined by the SPI Size and # of SPIs fields. The payload type for the Delete Payload is twelve (12). 3.16 Vendor ID Payload The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. This is not a general extension facility of ISAKMP. Figure 17 shows the format of the Vendor ID Payload. The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An imple- mentation is NOT REQUIRED to understand any Vendor ID payloads. An imple- mentation is NOT REQUIRED to send any Vendor ID payload at all. If a pri- vate payload was sent without prior agreement to send it, a compliant im- plementation may reject a proposal with a notify message of type INVALID- PAYLOAD-TYPE. If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negoti- ation. Reception of a familiar Vendor ID payload in the Phase 1 negotia- tion allows an implementation to make use of Private USE payload numbers (128-255), described in section 3.1 for vendor specific extensions during Phase 2 negotiations. The definition of "familiar" is left to implementa- tions to determine. Some vendors may wish to implement another vendor's extension prior to standardization. However, this practice SHOULD not be widespread and vendors should work towards standardization instead. The vendor defined constant MUST be unique. The choice of hash and text to hash is left to the vendor to decide. As an example, vendors could Maughan, Schertler, Schneider, Turner ISAKMP [Page 43] INTERNET-DRAFT ISAKMP March 10, 1998 generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product. A hash is used instead of a vendor registry to avoid local cryptographic policy problems with having a list of "approved" products, to keep away from maintaining a list of vendors, and to allow classified products to avoid having to appear on any list. For instance: "Example Company IPsec. Version 97.1" (not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include all of the hash, or just a portion of it, as the payload length will bound the data. There are no security implications of this hash, so its choice is arbitrary. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Vendor ID (VID) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Vendor ID Payload Format The Vendor ID Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Vendor ID (variable length) - Hash of the vendor string plus version (as described above). The payload type for the Vendor ID Payload is thirteen (13). Maughan, Schertler, Schneider, Turner ISAKMP [Page 44] INTERNET-DRAFT ISAKMP March 10, 1998 4 ISAKMP Exchanges ISAKMP supplies the basic syntax of a message exchange. The basic build- ing blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA establishment and SA mod- ification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these ad- ditions. 4.1 ISAKMP Exchange Types ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material. There are currently five default Ex- change Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers. Most exchanges will include all the basic payload types - SA, KE, ID, SIG - and may include others. The pri- mary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOM- MENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5. Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has hap- pened after each message exchange. None of the examples include any "op- tional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (con- taining initiator and responder cookies) which would provide protection against clogging (see section 2.5.3). The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI require- ments, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols. As discussed above, these exchange types can be used in either phase of Maughan, Schertler, Schneider, Turner ISAKMP [Page 45] INTERNET-DRAFT ISAKMP March 10, 1998 negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation. 4.1.1 Notation The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated pay- loads: HDR is an ISAKMP header whose exchange type defines the payload orderings SA is an SA negotiation payload with one or more Proposal and Transform payloads. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one. KE is the key exchange payload. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, or x can be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), for the user initiator and responder, respectively. HASH is the hash payload. SIG is the signature payload. The data to sign is exchange-specific. AUTH is a generic authentication mechanism, such as HASH or SIG. NONCE is the nonce payload. '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted. => signifies "initiator to responder" communication <= signifies "responder to initiator" communication 4.2 Security Association Establishment The Security Association, Proposal, and Transform payloads are used to build ISAKMP messages for the negotiation and establishment of SAs. An SA establishment message consists of a single SA payload followed by at least one, and possibly many, Proposal payloads and at least one, and pos- sibly many, Transform payloads associated with each Proposal payload. Be- cause these payloads are considered together, the SA payload will point to any following payloads and not to the Proposal payload included with the SA payload. The SA Payload contains the DOI and Situation for the pro- posed SA. Each Proposal payload contains a Security Parameter Index (SPI) and ensures that the SPI is associated with the Protocol-Id in accordance with the Internet Security Architecture [RFC-1825]. Proposal payloads may or may not have the same SPI, as this is implementation dependent. Each Maughan, Schertler, Schneider, Turner ISAKMP [Page 46] INTERNET-DRAFT ISAKMP March 10, 1998 Transform Payload contains the specific security mechanisms to be used for the designated protocol. It is expected that the Proposal and Transform payloads will be used only during SA establishment negotiation. The cre- ation of payloads for security association negotiation and establishment described here in this section are applicable for all ISAKMP exchanges de- scribed later in sections 4.4 through 4.8. The examples shown in 4.2.1 contain only the SA, Proposal, and Transform payloads and do not contain other payloads that might exist for a given ISAKMP exchange. The Proposal payload provides the initiating entity with the capability to present to the responding entity the security protocols and associated security mechanisms for use with the security association being negoti- ated. If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Pro- posal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. The use of the same Proposal number in mul- tiple Proposal payloads provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads each with a monoton- ically increasing Proposal number. The different proposals MUST be pre- sented in the initiator's preference order. The use of different Proposal numbers in multiple Proposal payloads provides a logical OR operation, i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one protocol. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload (if it exists). The existence of a Proposal payload implies the existence of one or more Transform payloads. The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform pay- load allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with mono- tonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform num- ber in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below shows one transform for AH AND one transform for ESP OR two trans- forms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals. When responding to a Security Association payload, the responder MUST send Maughan, Schertler, Schneider, Turner ISAKMP [Page 47] INTERNET-DRAFT ISAKMP March 10, 1998 a Security Association payload with the selected proposal, which may con- sist of multiple Proposal payloads and their associated Transform pay- loads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison di- rectly and quickly. The initiator MUST verify that the Security Associa- tion payload received from the responder matches one of the proposals sent initially. 4.2.1 Security Association Establishment Examples This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a sin- gle transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms pro- posed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Nonce ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SA Pay ! Domain of Interpretation (DOI) ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! Situation ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maughan, Schertler, Schneider, Turner ISAKMP [Page 48] INTERNET-DRAFT ISAKMP March 10, 1998 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Maughan, Schertler, Schneider, Turner ISAKMP [Page 49] INTERNET-DRAFT ISAKMP March 10, 1998 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Security Association Modification Security Association modification within ISAKMP is accomplished by cre- ating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Dele- tion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. The procedure for creating new SAs is outlined in section 4.2. The procedure for deleting SAs is outlined in section 5.15. Modification of an ISAKMP SA (phase 1 negotiation) follows the same proce- dure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3. Modification of a Protocol SA (phase 2 negotiation) follows the same pro- cedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Proto- col SAs. A protocol implementation SHOULD begin using the newly created Maughan, Schertler, Schneider, Turner ISAKMP [Page 50] INTERNET-DRAFT ISAKMP March 10, 1998 SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy. 4.4 Base Exchange The Base Exchange is designed to allow the Key Exchange and Authentica- tion related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity pro- tection. Identity protection is not provided because identities are ex- changed before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange. BASE EXCHANGE _#______Initiator____Direction_____Responder______________________NOTE______ ______________ (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE Basic SA agreed upon (3) HDR; KE; => IDii; AUTH Key Generated (by responder) Initiator Identity Verified by Responder (4) <= HDR; KE; IDir; AUTH Responder Identity Verified by Initiator Key Generated (by initiator) SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also trans- mitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information Maughan, Schertler, Schneider, Turner ISAKMP [Page 51] INTERNET-DRAFT ISAKMP March 10, 1998 provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local secu- rity policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third (3) and fourth (4) messages, the initiator and responder, re- spectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these mes- sages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.5 Identity Protection Exchange The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the ex- pense of two additional messages. Identities are exchanged under the pro- tection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange. IDENTITY PROTECTION EXCHANGE _#_______Initiator_____Direction______Responder_____NOTE____________________ ____________________ (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA Basic SA agreed upon (3) HDR; KE; NONCE => (4) <= HDR; KE; NONCE Key Generated (by Initiator and Responder) (5) HDR*; IDii; AUTH => Initiator Identity Verified by Responder (6) <= HDR*; IDir; AUTH Responder Identity Verified by Initiator SA established In the first message (1), the initiator generates a proposal it consid- ers adequate to protect traffic for the given situation. The Security As- sociation, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Maughan, Schertler, Schneider, Turner ISAKMP [Page 52] INTERNET-DRAFT ISAKMP March 10, 1998 In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the trans- mission of a Notify payload as part of an Informational Exchange. In the third (3) and fourth (4) messages, the initiator and responder, re- spectively, exchange keying material used to arrive at a common shared se- cret and random information which is used to guarantee liveness and pro- tect against replay attacks. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the ac- tion if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the fifth (5) and sixth (6) messages, the initiator and responder, re- spectively, exchange identification information and the results of the agreed upon authentication function. This information is transmitted un- der the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One pos- sible action is the transmission of a Notify payload as part of an Infor- mational Exchange. 4.6 Authentication Only Exchange The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational ex- pense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negoti- ated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authenti- cation only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible pay- loads sent in each message and notes for an example of the Authentication Only Exchange. Maughan, Schertler, Schneider, Turner ISAKMP [Page 53] INTERNET-DRAFT ISAKMP March 10, 1998 AUTHENTICATION ONLY EXCHANGE _#______Initiator_____Direction_____Responder_______________________NOTE____ ________________ (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE; IDir; AUTH Basic SA agreed upon Responder Identity Verified by Initiator (3) HDR; IDii; AUTH => Initiator Identity Verified by Responder SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also trans- mitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform pay- loads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this infor- mation is transmitted under the protection of the agreed upon authentica- tion function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third message (3), the initiator transmits identification informa- tion. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.7 Aggressive Exchange The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication- related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is Maughan, Schertler, Schneider, Turner ISAKMP [Page 54] INTERNET-DRAFT ISAKMP March 10, 1998 not provided because identities are exchanged before a common shared se- cret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to es- tablish all security relevant information in a single exchange. The fol- lowing diagram shows the messages with possible payloads sent in each mes- sage and notes for an example of the Aggressive Exchange. AGGRESSIVE EXCHANGE _#_____Initiator___Direction______Responder________________________NOTE_____ _______________ (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation NONCE; IDii and Key Exchange (2) <= HDR; SA; KE; NONCE; IDir; AUTH Initiator Identity Verified by Responder Key Generated Basic SA agreed upon (3) HDR*; AUTH => Responder Identity Verified by Initiator SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Associ- ation, Proposal, and Transform payloads are included in the Security Asso- ciation payload (for notation purposes). There can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work. Keying material used to arrive at a common shared se- cret and random information which is used to guarantee liveness and pro- tect against replay attacks are also transmitted. Random information pro- vided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the initiator transmits identification information. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is trans- mitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. Maughan, Schertler, Schneider, Turner ISAKMP [Page 55] INTERNET-DRAFT ISAKMP March 10, 1998 In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted un- der the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One pos- sible action is the transmission of a Notify payload as part of an Infor- mational Exchange. 4.8 Informational Exchange The Informational Exchange is designed as a one-way transmittal of infor- mation that can be used for security association management. The follow- ing diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange. INFORMATIONAL EXCHANGE __#___Initiator__Direction_Responder_______________NOTE_______________ (1) HDR*; N/D => Error Notification or Deletion In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete payload. If the Informational Exchange occurs prior to the exchange of keying me- terial during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. All exchanges are similar in that with the beginning of any exchange cryp- tographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Initial- ization Vector (IV) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informa- tional Exchange will be processed correctly. 5 ISAKMP Payload Processing Section 3 describes the ISAKMP payloads. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI. This section describes the processing for each of the payloads. This section suggests the logging of events to a system au- dit file. This action is controlled by a system security policy and is, Maughan, Schertler, Schneider, Turner ISAKMP [Page 56] INTERNET-DRAFT ISAKMP March 10, 1998 therefore, only a suggested action. 5.1 General Message Processing Every ISAKMP message has basic processing applied to insure protocol re- liability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Set a timer and initialize a retry counter. 2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE. 5.2 ISAKMP Header Processing When creating an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Create the respective cookie. See section 2.5.3 for details. 2. Determine the relevant security characteristics of the session (i.e. DOI and situation). 3. Construct an ISAKMP Header with fields as described in section 3.1. 4. Construct other ISAKMP payloads, depending on the exchange type. 5. Transmit the message to the destination host as described in section 5.1. When an ISAKMP message is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 57] INTERNET-DRAFT ISAKMP March 10, 1998 1. Verify the Initiator and Responder ``cookies''. If the cookie validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID COOKIE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Check the Major and Minor Version fields to confirm they are correct. If the Version field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID ISAKMP VERSION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 4. Check the Exchange Type field to confirm it is valid. If the Exchange Type field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-EXCHANGE-TYPE message type MAY be sent to the Maughan, Schertler, Schneider, Turner ISAKMP [Page 58] INTERNET-DRAFT ISAKMP March 10, 1998 transmitting entity. This action is dictated by a system security policy. 5. Check the Flags field to ensure it contains correct values. If the Flags field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID FLAGS, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-FLAGS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 6. Check the Message ID field to ensure it contains correct values. If the Message ID validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID MESSAGE ID, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-MESSAGE-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 7. Processing of the ISAKMP message continues using the value in the Next Payload field. 5.3 Generic Payload Header Processing When creating any of the ISAKMP Payloads described in sections 3.4 through 3.15 a Generic Payload Header is placed at the beginning of these pay- loads. When creating the Generic Payload Header, the transmitting entity (initiator or responder) MUST do the following: 1. Place the value of the Next Payload in the Next Payload field. These values are described in section 3.1. 2. Place the value zero (0) in the RESERVED field. 3. Place the length (in octets) of the payload in the Payload Length field. Maughan, Schertler, Schneider, Turner ISAKMP [Page 59] INTERNET-DRAFT ISAKMP March 10, 1998 4. Construct the payloads as defined in the remainder of this section. When any of the ISAKMP Payloads are received, the receiving entity (ini- tiator or responder) MUST do the following: 1. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Verify the RESERVED field contains the value zero. If the value in the RESERVED field is not zero, the message is discarded and the following actions are taken: (a) The event, INVALID RESERVED FIELD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads as defined by the Next Payload field. 5.4 Security Association Payload Processing When creating a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Domain of Interpretation for which this negotiation is being performed. 2. Determine the situation within the determined DOI for which this negotiation is being performed. Maughan, Schertler, Schneider, Turner ISAKMP [Page 60] INTERNET-DRAFT ISAKMP March 10, 1998 3. Determine the proposal(s) and transform(s) within the situation. These are described, respectively, in sections 3.5 and 3.6. 4. Construct a Security Association payload. 5. Transmit the message to the receiving entity as described in section 5.1. When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Determine if the given situation can be protected. If the Situation determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID SITUATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads (i.e. Proposal, Transform) of the Security Association Payload. If the Security Association Proposal (as described in sections 5.5 and 5.6) is not accepted, then the following actions are taken: (a) The event, INVALID PROPOSAL, MAY be logged in the appropriate system audit file. Maughan, Schertler, Schneider, Turner ISAKMP [Page 61] INTERNET-DRAFT ISAKMP March 10, 1998 (b) An Informational Exchange with a Notification payload containing the NO-PROPOSAL-CHOSEN message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.5 Proposal Payload Processing When creating a Proposal Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Protocol for this proposal. 2. Determine the number of proposals to be offered for this protocol and the number of transforms for each proposal. Transforms are described in section 3.6. 3. Generate a unique pseudo-random SPI. 4. Construct a Proposal payload. When a Proposal payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Protocol is supported. If the Protocol-ID field is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID PROTOCOL, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PROTOCOL-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. Maughan, Schertler, Schneider, Turner ISAKMP [Page 62] INTERNET-DRAFT ISAKMP March 10, 1998 (b) An Informational Exchange with a Notification payload containing the INVALID-SPI message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Ensure the Proposals are presented according to the details given in section 3.5 and 4.2. If the proposals are not formed correctly, the following actions are taken: (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 4. Process the Proposal and Transform payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. 5.6 Transform Payload Processing When creating a Transform Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Transform # for this transform. 2. Determine the number of transforms to be offered for this proposal. Transforms are described in sections 3.6. 3. Construct a Transform payload. When a Transform payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Transform is supported. If the Transform-ID field contains an unknown or unsupported value, then that Transform payload MUST be ignored and MUST NOT cause the generation of an INVALID TRANSFORM event. If the Transform-ID field is invalid, the payload is discarded and the following actions are taken: Maughan, Schertler, Schneider, Turner ISAKMP [Page 63] INTERNET-DRAFT ISAKMP March 10, 1998 (a) The event, INVALID TRANSFORM, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-TRANSFORM-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Ensure the Transforms are presented according to the details given in section 3.6 and 4.2. If the transforms are not formed correctly, the following actions are taken: (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID ATTRIBUTES, are logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT- SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the subsequent Transform and Proposal payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1. 5.7 Key Exchange Payload Processing When creating a Key Exchange Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Key Exchange to be used as defined by the DOI. 2. Determine the usage of the Key Exchange Data field as defined by the DOI. 3. Construct a Key Exchange payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Key Exchange payload is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 64] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Key Exchange is supported. If the Key Exchange determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID KEY INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-KEY-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.8 Identification Payload Processing When creating an Identification Payload, the transmitting entity (initia- tor or responder) MUST do the following: 1. Determine the Identification information to be used as defined by the DOI (and possibly the situation). 2. Determine the usage of the Identification Data field as defined by the DOI. 3. Construct an Identification payload. 4. Transmit the message to the receiving entity as described in section 5.1. When an Identification payload is received, the receiving entity (initia- tor or responder) MUST do the following: 1. Determine if the Identification Type is supported. This may be based on the DOI and Situation. If the Identification determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID ID INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-ID-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 65] INTERNET-DRAFT ISAKMP March 10, 1998 5.9 Certificate Payload Processing When creating a Certificate Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Certificate Encoding to be used. This may be specified by the DOI. 2. Ensure the existence of a certificate formatted as defined by the Certificate Encoding. 3. Construct a Certificate payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Certificate payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Process the Certificate Data field. If the Certificate Data is invalid or improperly formatted, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERTIFICATE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 66] INTERNET-DRAFT ISAKMP March 10, 1998 5.10 Certificate Request Payload Processing When creating a Certificate Request Payload, the transmitting entity (ini- tiator or responder) MUST do the following: 1. Determine the type of Certificate Encoding to be requested. This may be specified by the DOI. 2. Determine the name of an acceptable Certificate Authority which is to be requested (if applicable). 3. Construct a Certificate Request payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Certificate Request payload is received, the receiving entity (ini- tiator or responder) MUST do the following: 1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken: (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the CERT-TYPE-UNSUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. Maughan, Schertler, Schneider, Turner ISAKMP [Page 67] INTERNET-DRAFT ISAKMP March 10, 1998 2. Determine if the Certificate Authority is supported for the specified Certificate Encoding. If the Certificate Authority is invalid or improperly formatted, the payload is discarded and the following actions are taken: (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-CERT-AUTHORITY message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the Certificate Request. If a requested Certificate Type with the specified Certificate Authority is not available, then the payload is discarded and the following actions are taken: (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the CERTIFICATE-UNAVAILABLE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.11 Hash Payload Processing When creating a Hash Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Determine the Hash function to be used as defined by the SA negotiation. 2. Determine the usage of the Hash Data field as defined by the DOI. 3. Construct a Hash payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Hash payload is received, the receiving entity (initiator or re- sponder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 68] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Hash is supported. If the Hash determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-HASH-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Perform the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the Hash function fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH VALUE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.12 Signature Payload Processing When creating a Signature Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Signature function to be used as defined by the SA negotiation. 2. Determine the usage of the Signature Data field as defined by the DOI. 3. Construct a Signature payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Signature payload is received, the receiving entity (initiator or responder) MUST do the following: Maughan, Schertler, Schneider, Turner ISAKMP [Page 69] INTERNET-DRAFT ISAKMP March 10, 1998 1. Determine if the Signature is supported. If the Signature determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-SIGNATURE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If the Signature function fails, the message is discarded and the following actions are taken: (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.13 Nonce Payload Processing When creating a Nonce Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Create a unique random value to be used as a nonce. 2. Construct a Nonce payload. 3. Transmit the message to the receiving entity as described in section 5.1. When a Nonce payload is received, the receiving entity (initiator or re- sponder) MUST do the following: 1. There are no specific procedures for handling Nonce payloads. The procedures are defined by the exchange types (and possibly the DOI and Key Exchange descriptions). Maughan, Schertler, Schneider, Turner ISAKMP [Page 70] INTERNET-DRAFT ISAKMP March 10, 1998 5.14 Notification Payload Processing During communications it is possible that errors may occur. The Infor- mational Exchange with a Notify Payload provides a controlled method of informing a peer entity that errors have occurred during protocol process- ing. It is RECOMMENDED that Notify Payloads be sent in a separate Infor- mational Exchange rather than appending a Notify Payload to an existing exchange. When creating a Notification Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the DOI for this Notification. 2. Determine the Protocol-ID for this Notification. 3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 4. Determine the Notify Message Type based on the error or status message desired. 5. Determine the SPI which is associated with this notification. 6. Determine if additional Notification Data is to be included. This is additional information specified by the DOI. 7. Construct a Notification payload. 8. Transmit the message to the receiving entity as described in section 5.1. Because the Informational Exchange with a Notification payload is a uni- directional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro- priate system audit file by the receiving entity. If the Informational Exchange occurs prior to the exchange of keying ma- terial during an ISAKMP Phase 1 negotiation there will be no protection provided for the Informational Exchange. Once the keying material has been exchanged or the ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. When a Notification payload is received, the receiving entity (initiator Maughan, Schertler, Schneider, Turner ISAKMP [Page 71] INTERNET-DRAFT ISAKMP March 10, 1998 or responder) MUST do the following: 1. Determine if the Informational Exchange has any protection applied to it by checking the Encryption Bit and the Authentication Only Bit in the ISAKMP Header. If the Encryption Bit is set, i.e. the Informa- tional Exchange is encrypted, then the message MUST be decrypted using the (in-progress or completed) ISAKMP SA. Once the decryption is complete the processing can continue as described below. If the Authentication Only Bit is set, then the message MUST be authenti- cated using the (in-progress or completed) ISAKMP SA. Once the authentication is completed, the processing can continue as described below. If the Informational Exchange is not encrypted or authentica- tion, the payload processing can continue as described below. 2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. 3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file. 4. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following action is taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. 5. Determine if the Notify Message Type is valid. If the Notify Message Type is invalid, the payload is discarded and the following action is taken: (a) The event, INVALID MESSAGE TYPE, MAY be logged in the appropriate system audit file. 6. Process the Notification payload, including additional Notification Maughan, Schertler, Schneider, Turner ISAKMP [Page 72] INTERNET-DRAFT ISAKMP March 10, 1998 Data, and take appropriate action, according to local security policy. 5.15 Delete Payload Processing During communications it is possible that hosts may be compromised or that information may be intercepted during transmission. Determining whether this has occurred is not an easy task and is outside the scope of this Internet-Draft. However, if it is discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA. The Informational Exchange with a Delete Payload provides a controlled method of informing a peer entity that the transmitting entity has deleted the SA(s). Deletion of Security Associations MUST always be performed un- der the protection of an ISAKMP SA. The receiving entity SHOULD clean up its local SA database. However, upon receipt of a Delete message the SAs listed in the Security Parameter Index (SPI) field of the Delete payload cannot be used with the transmitting entity. The SA Establishment proce- dure must be invoked to re-establish secure communications. When creating a Delete Payload, the transmitting entity (initiator or re- sponder) MUST do the following: 1. Determine the DOI for this Deletion. 2. Determine the Protocol-ID for this Deletion. 3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 4. Determine the # of SPIs to be deleted for this protocol. 5. Determine the SPI(s) which is (are) associated with this deletion. 6. Construct a Delete payload. 7. Transmit the message to the receiving entity as described in section 5.1. Because the Informational Exchange with a Delete payload is a unidirec- tional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in the appropriate system au- Maughan, Schertler, Schneider, Turner ISAKMP [Page 73] INTERNET-DRAFT ISAKMP March 10, 1998 dit file by the receiving entity. As described above, the Informational Exchange with a Delete payload MUST be transmitted under the protection provided by an ISAKMP SA. When a Delete payload is received, the receiving entity (initiator or re- sponder) MUST do the following: 1. Because the Informational Exchange is protected by some security service (e.g. authentication for an Auth-Only SA, encryption for other exchanges), the message MUST have these security services applied using the ISAKMP SA. Once the security service processing is complete the processing can continue as described below. Any errors that occur during the security service processing will be evident when checking information in the Delete payload. The local security policy SHOULD dictate any action to be taken as a result of security service processing errors. 2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. 3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken: (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file. 4. Determine if the SPI is valid for each SPI included in the Delete payload. For each SPI that is invalid, the following action is taken: (a) The event, INVALID SPI, MAY be logged in the appropriate system audit file. 5. Process the Delete payload and take appropriate action, according to local security policy. As described above, one appropriate action SHOULD include cleaning up the local SA database. Maughan, Schertler, Schneider, Turner ISAKMP [Page 74] INTERNET-DRAFT ISAKMP March 10, 1998 6 Conclusions The Internet Security Association and Key Management Protocol (ISAKMP) is a well designed protocol aimed at the Internet of the future. The mas- sive growth of the Internet will lead to great diversity in network uti- lization, communications, security requirements, and security mechanisms. ISAKMP contains all the features that will be needed for this dynamic and expanding communications environment. ISAKMP's Security Association (SA) feature coupled with authentication and key establishment provides the security and flexibility that will be needed for future growth and diversity. This security diversity of multi- ple key exchange techniques, encryption algorithms, authentication mecha- nisms, security services, and security attributes will allow users to se- lect the appropriate security for their network, communications, and secu- rity needs. The SA feature allows users to specify and negotiate security requirements with other users. An additional benefit of supporting multi- ple techniques in a single protocol is that as new techniques are devel- oped they can easily be added to the protocol. This provides a path for the growth of Internet security services. ISAKMP supports both publicly or privately defined SAs, making it ideal for government, commercial, and private communications. ISAKMP provides the ability to establish SAs for multiple security proto- cols and applications. These protocols and applications may be session- oriented or sessionless. Having one SA establishment protocol that sup- ports multiple security protocols eliminates the need for multiple, nearly identical authentication, key exchange and SA establishment protocols when more than one security protocol is in use or desired. Just as IP has pro- vided the common networking layer for the Internet, a common security es- tablishment protocol is needed if security is to become a reality on the Internet. ISAKMP provides the common base that allows all other security protocols to interoperate. ISAKMP follows good security design principles. It is not coupled to other insecure transport protocols, therefore it is not vulnerable or weakened by attacks on other protocols. Also, when more secure transport protocols are developed, ISAKMP can be easily migrated to them. ISAKMP also provides protection against protocol related attacks. This protec- tion provides the assurance that the SAs and keys established are with the desired party and not with an attacker. ISAKMP also follows good protocol design principles. Protocol specific information only is in the protocol header, following the design prin- ciples of IPv6. The data transported by the protocol is separated into functional payloads. As the Internet grows and evolves, new payloads to support new security functionality can be added without modifying the en- tire protocol. Maughan, Schertler, Schneider, Turner ISAKMP [Page 75] INTERNET-DRAFT ISAKMP March 10, 1998 A ISAKMP Security Association Attributes A.1 Background/Rationale As detailed in previous sections, ISAKMP is designed to provide a flexible and extensible framework for establishing and managing Security Associa- tions and cryptographic keys. The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner. The definition of mechanisms and their application is the purview of individual Domains of Interpretation (DOIs). This section describes the ISAKMP values for the Internet IP Security DOI, supported security protocols, and identification values for ISAKMP Phase 1 negotiations. The Internet IP Security DOI is MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, in detail, the mechanisms and their application for establishing and managing Security Associations and cryptographic keys for IP Security. A.2 Internet IP Security DOI Assigned Value As described in [IPDOI], the Internet IP Security DOI Assigned Number is one (1). A.3 Supported Security Protocols Values for supported security protocols are specified in the most recent ``Assigned Numbers'' RFC [STD-2]. Presented in the following table are the values for the security protocols supported by ISAKMP for the Internet IP Security DOI. _Protocol_Assigned_Value__ RESERVED 0 ISAKMP 1 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security protocols within that DOI will be numbered accordingly. Security protocol values 2-15359 are reserved to IANA for future use. Values 15360-16383 are permanently reserved for private use amongst mu- Maughan, Schertler, Schneider, Turner ISAKMP [Page 76] INTERNET-DRAFT ISAKMP March 10, 1998 tually consenting implementations. Such private use values are unlikely to be interoperable across different implementations. A.4 ISAKMP Identification Type Values The following table lists the assigned values for the Identification Type field found in the Identification payload during a generic Phase 1 ex- change, which is not for a specific protocol. ______ID_Type_______Value_ ID_IPV4_ADDR 0 ID_IPV4_ADDR_SUBNET 1 ID_IPV6_ADDR 2 ID_IPV6_ADDR_SUBNET 3 A.4.1 ID_IPV4_ADDR The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. A.4.2 ID_IPV4_ADDR_SUBNET The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, repre- sented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. A.4.3 ID_IPV6_ADDR The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address. A.4.4 ID_IPV6_ADDR_SUBNET The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, repre- sented by two sixteen (16) octet values. The first value is an IPv6 ad- dress. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. Maughan, Schertler, Schneider, Turner ISAKMP [Page 77] INTERNET-DRAFT ISAKMP March 10, 1998 B Defining a new Domain of Interpretation The Internet DOI may be sufficient to meet the security requirements of a large portion of the internet community. However, some groups may have a need to customize some aspect of a DOI, perhaps to add a different set of cryptographic algorithms, or perhaps because they want to make their security-relevant decisions based on something other than a host id or user id. Also, a particular group may have a need for a new exchange type, for example to support key management for multicast groups. This section discusses guidelines for defining a new DOI. The full speci- fication for the Internet DOI can be found in [IPDOI]. Defining a new DOI is likely to be a time-consuming process. If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable. If a designer chooses to start from scratch, the following MUST be de- fined: o A ``situation'': the set of information that will be used to determine the required security services. o The set of security policies that must be supported. o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, etc. o A syntax for the specification of proposed security services, attributes, and certificate authorities. o The specific formats of the various payload contents. o Additional exchange types, if required. B.1 Situation The situation is the basis for deciding how to protect a communications channel. It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate. These additional security attributes would be included in the situation. Maughan, Schertler, Schneider, Turner ISAKMP [Page 78] INTERNET-DRAFT ISAKMP March 10, 1998 B.2 Security Policies Security policies define how various types of information must be cate- gorized and protected. The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation, and will protect information appropriately, both in transit and in storage. In a corporate setting, for example, both parties in a negotiation must agree to the meaning of the term ``propri- etary information'' before they can negotiate how to protect it. Note that including the required security policies in the DOI only speci- fies that the participating hosts understand and implement those policies in a full system context. B.3 Naming Schemes Any DOI must define a consistent way to name cryptographic algorithms, certificate authorities, etc. This can usually be done by using IANA nam- ing conventions, perhaps with some private extensions. B.4 Syntax for Specifying Security Services In addition to simply specifying how to name entities, the DOI must also specify the format for complete proposals of how to protect traffic under a given situation. B.5 Payload Specification The DOI must specify the format of each of the payload types. For several of the payload types, ISAKMP has included fields that would have to be present across all DOI (such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload). B.6 Defining new Exchange Types If the basic exchange types are inadequate to meet the requirements within a DOI, a designer can define up to thirteen extra exchange types per DOI. The designer creates a new exchange type by choosing an unused exchange type value, and defining a sequence of messages composed of strings of the ISAKMP payload types. Maughan, Schertler, Schneider, Turner ISAKMP [Page 79] INTERNET-DRAFT ISAKMP March 10, 1998 Note that any new exchange types must be rigorously analyzed for vulner- abilities. Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary. Maughan, Schertler, Schneider, Turner ISAKMP [Page 80] INTERNET-DRAFT ISAKMP March 10, 1998 Security Considerations Cryptographic analysis techniques are improving at a steady pace. The continuing improvement in processing power makes once computationally pro- hibitive cryptographic attacks more realistic. New cryptographic algo- rithms and public key generation techniques are also being developed at a steady pace. New security services and mechanisms are being developed at an accelerated pace. A consistent method of choosing from a variety of security services and mechanisms and to exchange attributes required by the mechanisms is important to security in the complex structure of the Internet. However, a system that locks itself into a single cryptographic algorithm, key exchange technique, or security mechanism will become in- creasingly vulnerable as time passes. UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- troduces a number of security considerations. Since UDP is unreliable, but a key management protocol must be reliable, the reliability is built into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it doesn't rely on any UDP information (e.g. checksum, length) for its pro- cessing. Another issue that must be considered in the development of ISAKMP is the effect of firewalls on the protocol. Many firewalls filter out all UDP packets, making reliance on UDP questionable in certain environments. A number of very important security considerations are presented in [RFC-1825]. One bears repeating. Once a private session key is created, it must be safely stored. Failure to properly protect the private key from access both internal and external to the system completely nullifies any protection provided by the IP Security services. IANA Considerations This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign addi- tional numbers in each of these lists. Domain of Interpretation The Domain of Interpretation (DOI) is a 32-bit field which identifies the domain under which the security association negotiation is taking place. Requests for assignments of new DOIs must be accompanied by a standards- track RFC which describes the specific domain. Maughan, Schertler, Schneider, Turner ISAKMP [Page 81] INTERNET-DRAFT ISAKMP March 10, 1998 Supported Security Protocols ISAKMP is designed to provide security association negotiation and key management for many security protocols. Requests for identifiers for ad- ditional security protocols must be accompanied by a standards-track RFC which describes the security protocol and its relationship to ISAKMP. Acknowledgements Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided design assistance with the protocol and coordination for the [IKE] and [IPDOI] documents. Hilarie Orman, via the Oakley key exchange protocol, has significantly influenced the design of ISAKMP. Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided significant input and review to this document. Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the ISAKMP prototype. Jeff Turner and Steve Smalley contributed to the prototype development and integration with ESP and AH. Mike Oehler and Pete Sell performed interoperability testing with other ISAKMP implementors. Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. Maughan, Schertler, Schneider, Turner ISAKMP [Page 82] INTERNET-DRAFT ISAKMP March 10, 1998 References [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services Industry -- Establishment of Symmetric Algorithm Keys Using Diffie-Hellman, Working Draft, April 19, 1996. [BC] Ballardie, A. and J. Crowcroft, Multicast-specific Security Threats and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks & Distributed Systems Security, pp. 17-30, Internet Society, San Diego, CA, February 1995. [Berge] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work in progress, November, 1995. [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and Military Computer Security Policies, Proceedings of the IEEE Symposium on Security & Privacy, Oakland, CA, 1987, pp. 184-193. [DNSSEC] D. Eastlake III, Domain Name System Protocol Security Extensions, Internet-Draft: draft-ietf-dnssec-secext2-03.txt, Work in Progress, January 1998. [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 107-125, Kluwer Academic Publishers, 1992. [IAB] Bellovin, S., Report of the IAB Security Architecture Workshop, Internet-Draft: draft-iab-secwks-report-00.txt, Work in Progress, November 1997. [IKE] Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), Internet-Draft: draft-ietf-ipsec-isakmp-oakley-06.txt, Work in Progress, February 1998. [IPDOI] Derrell Piper, The Internet IP Security Domain of Interpretation for ISAKMP, Internet-Draft: draft-ietf-ipsec-ipsec-doi-07.txt, Work in Progress, February 1998. [Karn] Karn, P. and B. Simpson, Photuris: Session Key Management Protocol, Internet-Draft: draft-simpson-photuris-15.txt, Work in Progress, July 1997. [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 1994. [Oakley] H. K. Orman, The Oakley Key Determination Protocol, Internet- Draft: draft-ietf-ipsec-oakley-02.txt, Work in Progress, July 1997. [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, February 1993. Maughan, Schertler, Schneider, Turner ISAKMP [Page 83] INTERNET-DRAFT ISAKMP March 10, 1998 [RFC-1825] Randall Atkinson, Security Architecture for the Internet Protocol, RFC-1825, August, 1995. [RFC-1949] A. Ballardie, Scalable Multicast Key Distribution, RFC-1949, May 1996. [RFC-2093] Harney, H. and C. Muckenhirn, Group Key Management Protocol (GKMP) Specification, SPARTA, Inc., RFC-2093, July 1997. [RFC-2094] Harney, H. and C. Muckenhirn, Group Key Management Protocol (GKMP) Architecture, SPARTA, Inc., RFC-2094, July 1997. [RFC-2119] S. Bradner, Key Words for use in RFCs to Indicate Requirement Levels, Harvard University, RFC-2119, March 1997. [Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, and Source Code in C (Second Edition), John Wiley & Sons, Inc., 1996. [STD-2] Reynolds, J. and J. Postel, Assigned Numbers, STD 2, October, 1994. Maughan, Schertler, Schneider, Turner ISAKMP [Page 84] INTERNET-DRAFT ISAKMP March 10, 1998 Addresses of Authors The authors can be contacted at: Douglas Maughan Phone: 301-688-0847 E-mail:wdm@tycho.ncsc.mil Mark Schneider Phone: 301-688-0851 E-mail:mss@tycho.ncsc.mil National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000 Mark Schertler Terisa Systems, Inc. 4984 El Camino Real Los Altos, CA. 94022 Phone: 650-919-1773 E-mail:mjs@terisa.com Jeff Turner RABA Technologies, Inc. 10500 Little Patuxent Parkway Columbia, MD. 21044 Phone: 410-715-9399 E-mail:jeff.turner@raba.com Maughan, Schertler, Schneider, Turner ISAKMP [Page 85] From owner-ipsec Thu Mar 12 09:26:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29346 for ipsec-outgoing; Thu, 12 Mar 1998 09:25:30 -0500 (EST) Message-Id: <3.0.1.32.19960101172534.006a406c@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 01 Jan 1996 17:25:34 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Why can't ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, With respect to the draft draft-ietf-ipsec-arch-sec-03.txt Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. ============================================================= | | | ======================= | | | | | --|-----------------|--- --|-------------------|-- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | ------------------------ ------------------------- admin. boundary admin. boundary Here consider that the host H1 sends out fragments or the incoming packets to the SG1 are fragmented then * Whether such situation arises that the incoming packets to a security gateway are fragmented ?. * What the security gateway does in such situation ?. Does it reassembles all the packets (eventhough they are not destined for it, because reassembly occurs only at the destination) and apply tunnel mode i.e do IPsec processing on the reassembled packet and sends it out with or with out fragmentation as needed. * Does it discards the packet since a fragment has came to the IPsec processing ?. * Why can't we apply IPsec processing on frgaments( I did not get anything from the explaination given in the draft)?. If its only due to the src and dest ports ( which we can't get from the frgaments and if it is ESP ) then that is not sufficient reason to discard fragment fron the IPsec processing, because most of the time the packet will be get fragmented or it will be in ESP mode. If we can apply IPsec on fragments then we can avoid the unneccessary reassembly at the SG1 just to apply IPsec. Thank U in advance Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Thu Mar 12 09:34:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29443 for ipsec-outgoing; Thu, 12 Mar 1998 09:33:30 -0500 (EST) Message-Id: <199803121443.JAA15316@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-09.txt,.ps Date: Thu, 12 Mar 1998 09:43: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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-09.txt,.ps Pages : 85 Date : 11-Mar-98 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and crypto- graphic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mecha- nisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicat- ing peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to es- tablish and maintain secure communications (via IP Security Ser- vice or any other security protocol) 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-ipsec-isakmp-09.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311100655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311100655.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Mar 12 09:34:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29458 for ipsec-outgoing; Thu, 12 Mar 1998 09:34:31 -0500 (EST) Date: Thu, 12 Mar 1998 16:49:14 +0200 (IST) From: Hugo Krawczyk Message-Id: <199803121449.QAA23746@ee.technion.ac.il> To: dharkins@cisco.com, pkoning@xedia.com Subject: Re: Looking for statement of patent issues re ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk IBM US Patent 5,148,479 covers (or at least so say the lawyers) some of the techniques used in the protocols (especially quick mode). However, RFC1822 provides a "grant of rights" by IBM for usage of this patent in key management of ipsec. (The text is somewhat outdated as for its terminology, but still refers to "Photuris or derivatives" which should include IKE) Hugo From owner-ipsec Thu Mar 12 09:44:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29555 for ipsec-outgoing; Thu, 12 Mar 1998 09:43:32 -0500 (EST) Message-Id: <3.0.1.32.19960101161924.006a46cc@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 01 Jan 1996 16:19:24 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Do we need ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, With reference to draft-ietf-ipsec-arch-sec-03.txt "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)." "2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet." In the first paragraphs it says before creating new SA one should check whether SAD already has an appropriate SA created by some other SPD entries.But second paragraph from section "5.1.1 Selecting and Using an SA or SA Bundle" says if no SA found then create the new SA. So which one to follow do we need to search the SAD for appropriate SA created by other SPD entries or simply create the new SA, if no matching SA found ? Thank U in advance Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Thu Mar 12 09:46:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29575 for ipsec-outgoing; Thu, 12 Mar 1998 09:46:33 -0500 (EST) Message-Id: <3.0.1.32.19980312170026.006c68a4@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 12 Mar 1998 17:00:26 +0500 To: ipsec@tis.com From: rohit Subject: clarification Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I am sorry, i didn't get anything from the following table,which is in new ipsec draft ( page 20 ),can sombody on the list will explain this, ****** The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD. The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD. Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- ESP ESP or ANY ANY (i.e., don't look at it) -don't care- ANY ANY (i.e., don't look at it) specific value specific value NOT ANY (i.e.,drop packet) fragment specific value specific value actual port selector field not fragment ***** - Thanks Rohit ******************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ******************************************************************* From owner-ipsec Thu Mar 12 10:51:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00101 for ipsec-outgoing; Thu, 12 Mar 1998 10:49:31 -0500 (EST) Date: Thu, 12 Mar 1998 18:02:29 +0200 (EET) From: Markku-Juhani Saarinen To: ipsec@tis.com Subject: comments on draft-ietf-ipsec-ciph-cbc-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The draft does not mention that the RC5 encryption algorithm is patented (pat.no. 5,724,428). We feel that a 4-round variant of IDEA can not provide the level of security that it's key length would suggest. Cryptoanalytic attacks on 3 and 3.5 - round variants of IDEA has been published. The weak key lists are incomplete, as they will probably always be. The chances of hitting one at random is negligible. What's the point ? - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ipsec Thu Mar 12 11:38:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00533 for ipsec-outgoing; Thu, 12 Mar 1998 11:37:37 -0500 (EST) Message-Id: <199803121648.LAA23239@relay.hq.tis.com> Date: Thu, 12 Mar 98 11:41:01 EST From: Charles Lynn To: rohit cc: ipsec@tis.com, kent@bbn.com Subject: Re: clarification Sender: owner-ipsec@ex.tis.com Precedence: bulk Rohit, Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD --------------- -------------- ---------------------------- 1) ESP ESP or ANY ANY (i.e., don't look at it) 2) -don't care- ANY ANY (i.e., don't look at it) 3) specific value, specific value NOT ANY (i.e., drop packet) fragment 4) specific value, specific value actual port selector field not fragment What the table is trying to convey is that there are interactions between the selectors used to match SPD or SAD entries themselves and also with fields in a packet that are not classified as selectors, i.e., the fragmentation fields. It tries to be "implementation neutral" by specifying certain port selector values that result in the desired behavior. In cases 1), if the protocol field in the packet identifies an ESP header, and the protocol selector specifies either ESP or a wildcard, i.e., the protocol matches, then one cannot use the port selector for anything as one cannot find port values in the packet to be matched against the selector values in the SPD or SAD. The easy way to specify that "there are no useful port value(s) in the packet" is to specify the source and destination port selectors as a wildcard -- ANY. Otherwise in case 2), if the one allows any protocol, then it does not make any sense to try and specify some explicit port number, so again, one should ignore the port selectors by specifying ANY port. Otherwise in case 3), if the IP packet is a fragment and the SPD requires an explicit protocol, then one cannot say that the packet is for that protocol, and the packet must be dropped. Note that in the case of the first fragment, one might be able to identify the protocol. However, since the rest of the fragments will be dropped, there is no point in letting the first one pass through. In addition the first fragment typically has the most useful information in it, if it is to be audited, so rejecting it immediately may produce more meaningful diagnostics. Otherwise in case 4), if the IP packet is not a fragment and is for an explicit protocol, proceed to match the port fields in the packet with the port selectors specified in the SPD. (If that protocol does not use ports, I would expect the policy administrator to have specified ANY for the port selectors.) Does the above answer your questions? Charlie From owner-ipsec Thu Mar 12 13:16:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01146 for ipsec-outgoing; Thu, 12 Mar 1998 13:13:39 -0500 (EST) Date: Thu, 12 Mar 1998 10:28:02 -0800 From: mark@mentat.com (Marc Hasson) Message-Id: <199803121828.KAA04026@orna.mentat.com> To: clynn@bbn.com Subject: Re: clarification Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, > Next Hdr Next Hdr Derived Port Selector Field > in Packet in SPD Value in SPD and SAD > --------------- -------------- ---------------------------- > > 1) ESP ESP or ANY ANY (i.e., don't look at it) > > 2) -don't care- ANY ANY (i.e., don't look at it) > > 3) specific value, specific value NOT ANY (i.e., drop packet) > fragment > > 4) specific value, specific value actual port selector field > not fragment > . . . > > Otherwise in case 3), if the IP packet is a fragment and the SPD > requires an explicit protocol, then one cannot say that the packet is > for that protocol, and the packet must be dropped. Note that in the > case of the first fragment, one might be able to identify the > protocol. However, since the rest of the fragments will be dropped, > there is no point in letting the first one pass through. In addition > the first fragment typically has the most useful information in it, if > it is to be audited, so rejecting it immediately may produce more > meaningful diagnostics. I found the above confusing. I assume you meant that the *port* fields may not be available and that one might be able to identify them (only) in the first fragment. The protocol field is still there, the same for every fragment.... I think we need to revisit the question as to the issue of dropping the fragments or not. I've seen firewalls on the network today which drop the first fragment based on ports (or check/avoid the subsequent re-mixed fragments that try to by-pass the port checks) and yet they allow the later fragments in, safe(?) in the knowledge that properly functioning stacks will never reassemble a packet that has been denied access by dropping the zero'th fragment. I make no comment as to whether this is optimal behavior but it does appear to be a valid IPSEC inbound SA behavior rule that an administrater may desire, yes? Reading your note and the chart/document it would seem to state that any fragmented IPSEC message for a specific value would be dropped. I don't believe this is the case, can't fragments of a TCP or UDP packet be individually tunnelled through ESP (perhaps by a BITW or BITS implementation) to an end-host, for example? I don't want those fragments dropped after authentication/decryption.... Or, depending upon my security rules, maybe I do. So, for Case 3 I'd think that any of the following are possible when a specific-value for protocol on a fragment coming through an SA is specified: "NOT ANY" (drop, we don't like fragments through this SA) "ANY" (don't look for ports, whether there or not pass the fragment) "actual port" (check if this fragment can contain them, else "ANY") Comments? -- Marc -- From owner-ipsec Thu Mar 12 14:13:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01576 for ipsec-outgoing; Thu, 12 Mar 1998 14:09:41 -0500 (EST) Message-ID: From: Roy Pereira To: "'Markku-Juhani Saarinen'" , "'ipsec@tis.com'" Subject: RE: comments on draft-ietf-ipsec-ciph-cbc-02.txt Date: Thu, 12 Mar 1998 15:00:42 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >From: Markku-Juhani Saarinen [SMTP:mjos@ssh.fi] > >We feel that a 4-round variant of IDEA can not provide the level of >security that it's key length would suggest. Cryptoanalytic attacks on >3 and 3.5 - round variants of IDEA has been published. > How many rounds do you suggest for IDEA? > >The weak key lists are incomplete, as they will probably always be. >The chances of hitting one at random is negligible. What's the point ? > >What do you suggest we do with the weak key lists? From our knowledge, we >did include all known weak keys. > From owner-ipsec Thu Mar 12 14:56:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01926 for ipsec-outgoing; Thu, 12 Mar 1998 14:53:44 -0500 (EST) Date: Thu, 12 Mar 1998 15:05:26 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Christophe Gouault From: Stephen Kent Subject: Re: Question about draft-ietf-ipsec-arch-sec-03.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Chirs, You provide simple examples of how ordering can be inferred from IP address ranges or widlcarded addresses. However, the set of selector supported by IPsec in an SPD is more than just addresses and we have previously explained why explicit ordering is needed, i.e., we have a 5+ dimensional space and no total ordering can be applied to entries in that space, in general. For inbound traffic, we have an SPI to guide us to an SAD entry and an opportunity to have backpointers in the SAD to guide us to appropriate SPD entries. The NOTE refers to the possible complexity that arises from sharing SA bundles resulting from application of of different policies. Steve From owner-ipsec Thu Mar 12 14:56:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01927 for ipsec-outgoing; Thu, 12 Mar 1998 14:53:45 -0500 (EST) Date: Thu, 12 Mar 1998 15:05:29 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.5.32.19980310143859.009e6660@homebase.htt-consult.com> References: <199803101920.OAA08417@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> <199803101550.KAA08137@carp.morningstar.com> <3.0.5.32.19980310135454.00959830@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Moskowitz From: Stephen Kent Subject: Re: doi-07/interoperability questions Cc: ben@Ascend.COM (Ben Rogers), ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob and Ben, >>> >as to whether I should support mixed proposals. My opinion is that it >>> >makes sense to support AH (transport) and ESP (tunnel) with the >>> >following encapsulation: >>> > >>> >[IP2][AH][ESP][IP1][upper] >>> > >>> >and to not support AH (tunnel) and ESP (transport). Does anyone else > >This feels right to me. What you are saying is that the gateways are >maintaining a secure tunnel, which is separately authenticated. (I think >:). So you want the tunneled IP datagram in one piece. The AH (transport) >and ESP (tunnel) delivers this. The AH (tunnel) and ESP (transport) breaks >the IP datagram. I'm puzzled by this example. Since we discard the outer IP header at a security gateway, AH appears to add no security that cannot be offered by use of the authentication facility in the ESP tunnel. Also, the Arch Doc requires that any SA terminating at a security gateway be in tunnel mode, implying that there is an inner IP header. So, in this example, AH should be considered tunnel mode, not transport mode. The position of AH realtive to the outer IP header is the same in tunnel and transport modes, so the difference between the two modes is less apparent here, but the implications for header checking after processing are different. In reducing the required set of AH and ESP combinations to be supported, as per the December IETF, we don't require support for nested AH + ESP in tunnel mode, so we'd have to add this back in. I may be that folks at that meeting didn't feel the need to reatin this support for the reason cited above. Anyway, please think about the basic question of what features are provided by the use of AH here, so we can decide if it's appropriate to modify the arch doc again to accommodate this combination. Steve From owner-ipsec Thu Mar 12 15:18:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02117 for ipsec-outgoing; Thu, 12 Mar 1998 15:17:42 -0500 (EST) Message-Id: <199803122032.PAA04260@relay.rv.tis.com> Date: Thu, 12 Mar 98 15:24:37 EST From: Charles Lynn To: Marc Hasson cc: clynn@bbn.com, ipsec@tis.com Subject: Re: clarification Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, > > Next Hdr Next Hdr Derived Port Selector Field > > in Packet in SPD Value in SPD and SAD > > --------------- -------------- ---------------------------- > > > > 3) specific value, specific value NOT ANY (i.e., drop packet) > > fragment > > > > Otherwise in case 3), if the IP packet is a fragment and the SPD > > requires an explicit protocol, then one cannot say that the packet is > > for that protocol, and the packet must be dropped. Note that in the > > case of the first fragment, one might be able to identify the > > protocol. However, since the rest of the fragments will be dropped, > > there is no point in letting the first one pass through. > > I found the above confusing. I assume you meant that the *port* fields > may not be available and that one might be able to identify them (only) > in the first fragment. That is correct. > The protocol field is still there, the same for every fragment.... For IPv4 yes (assuming one isn't using Extension Headers in IPv4, which is happening), for IPv6 maybe not, as the Next Hdr field in the Fragmentation Header might not identify a transport protocol (e.g., it could be Destination Options). The mechanism used in the table to reject a packet for which the protocol selector matched is to use the port selectors (since, as you correctly point out, they are not always available) to force a mismatch and thus reject an otherwise matching packet. > I think we need to revisit the question as to the issue of dropping > the fragments or not. ... but [filtering the first fragment and > passing all others] does appear to be a valid IPSEC inbound SA > behavior rule that an administrator may desire, yes? Yes, and I would check to make sure that a product offered that feature before buying; others may find the more limited functionality specified in the document to be sufficient for their needs. > Reading your note and the chart/document it would seem to state that > any fragmented IPSEC message for a specific value would be dropped. That is the way I read it, too. [Nit: "IPSEC" is irrelevant here.] > ... can't fragments of a TCP or UDP packet be individually tunneled > through ESP (perhaps by a BITW or BITS implementation) to an end-host Yes. > I don't want those fragments dropped after authentication/decryption.... > Or, depending upon my security rules, maybe I do. Agreed. > So, for Case 3 I'd think that any of the following are possible when a > specific-value for protocol on a fragment coming through an SA is specified: > "NOT ANY" (drop, we don't like fragments through this SA) > "ANY" (don't look for ports, whether there or not pass the fragment) > "actual port" (check if this fragment can contain them, else "ANY") I do not think that the first two options would not require any code changes, so would "only" impact product documentation. I think that the third would also require a code change for some vendors. What do others in the working group think about changing the minimum required functionality for fragments? 3a) specific value, specific value NOT ANY (i.e., drop packet), or first fragment ANY (pass the fragmented packet), or actual port selector field 3b) specific value, specific value ANY (pass the fragmented packet) other fragments Charlie From owner-ipsec Thu Mar 12 15:46:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02344 for ipsec-outgoing; Thu, 12 Mar 1998 15:45:45 -0500 (EST) Date: Thu, 12 Mar 1998 15:58:18 -0500 Message-Id: <9803122058.AA03899@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mark@mentat.com Cc: ipsec@tis.com Subject: Re: clarification References: <199803121828.KAA04026@orna.mentat.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Marc" == Marc Hasson writes: Marc> Charlie, >> Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD >> Value in SPD and SAD --------------- -------------- >> ---------------------------- >> >> 1) ESP ESP or ANY ANY (i.e., don't look at it) >> >> 2) -don't care- ANY ANY (i.e., don't look at it) >> >> 3) specific value, specific value NOT ANY (i.e., drop packet) >> fragment >> >> 4) specific value, specific value actual port selector field not >> fragment >> Marc> . . . >> Otherwise in case 3), if the IP packet is a fragment and the SPD >> requires an explicit protocol, then one cannot say that the packet >> is for that protocol, and the packet must be dropped. Note that >> in the case of the first fragment, one might be able to identify >> the protocol. However, since the rest of the fragments will be >> dropped, there is no point in letting the first one pass through. >> In addition the first fragment typically has the most useful >> information in it, if it is to be audited, so rejecting it >> immediately may produce more meaningful diagnostics. Marc> I found the above confusing. I assume you meant that the Marc> *port* fields may not be available and that one might be able Marc> to identify them (only) in the first fragment. The protocol Marc> field is still there, the same for every fragment.... I found the discussion on fragment handling in IPSEC to be problematic for a different reason. Conceptually, IPSEC lives above IP, just like UDP or TCP do. Reassembly is an IP layer function, so clients of IP (such as UDP, or IPSEC) see fully assembled packets. Fragments don't appear on that abstract interface at all, so it's not really meaningful to talk about what you're required to do when you see them. In addition, the interface from IPSEC to IP is an internal interface. Internal interfaces are generally not subject to standardization (unless you're talking about an API spec). Stating properties of such interfaces as requirements is confusing. The required behavior applies to observable interfaces -- wires coming out of the box. It is perfectly valid to say that incomplete packets don't make it through a security gateway. But I'd prefer not to see that described in the current terms. paul From owner-ipsec Thu Mar 12 15:47:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02365 for ipsec-outgoing; Thu, 12 Mar 1998 15:47:44 -0500 (EST) Message-Id: <9803122100.AA30816@gimili.watson.ibm.com> To: ipsec@tis.com Subject: comments on draft-ietf-isakmp-mode-cfg-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Mar 98 16:00:20 -0500 From: "Partha P. Bhattacharya" Sender: owner-ipsec@ex.tis.com Precedence: bulk Comments on draft-ietf-ipsec-isakmp-mode-cfg-02.txt 1. The draft specifies ways to exchange configuration information either within an ISAKMP Phase 1 exchange or by ISAKMP Informational exchange. Couple of points here: -when done over Phase 1, the HASH has to include the configuration information being exchanged, otherwise it is not authenticated. This means though that HASH_I and HASH_R in the IKE exchange has to be augmented to include NOTIFY payloads. Not desirable for reasons of compatibility. -hence the information exchange shd be done after Phase 1 is complete, although this may mean more message exchanges. The format specified in section 5.7 of the IKE draft (ISAKMP-OAKLEY draft 06) shd be used. 2. The draft proposes to distribute policy and certificates by this method across road warrior-gateway tunnels. I don't see the benefit in doing as opposed to running generic client applications. Hence I would restrict this method to only distribute basic routing related information, such as local address and DNS address. Comments? Partha P. Bhattacharya Pau-Chen Cheng IBM Research From owner-ipsec Thu Mar 12 16:15:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02706 for ipsec-outgoing; Thu, 12 Mar 1998 16:12:44 -0500 (EST) Date: Thu, 12 Mar 1998 13:26:53 -0800 From: mark@mentat.com (Marc Hasson) Message-Id: <199803122126.NAA04275@orna.mentat.com> To: clynn@bbn.com Subject: Re: clarification Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, > For IPv4 yes (assuming one isn't using Extension Headers in IPv4, > which is happening), for IPv6 maybe not, as the Next Hdr field in the > Fragmentation Header might not identify a transport protocol (e.g., it > could be Destination Options). Yes, this is true. One might be able to chain down to the transport header but only on the first fragment if it was big enough. I think Dst opts could be forbidden by an administrater in this case so that, in return, he/she could do transport protocol (and port) enforcement on fragments. I agree that this isn't a great answer and there may be other headers as well at some point that interfere. > > So, for Case 3 I'd think that any of the following are possible when a > > specific-value for protocol on a fragment coming through an SA is specified: > > "NOT ANY" (drop, we don't like fragments through this SA) > > "ANY" (don't look for ports, whether there or not pass the fragment) > > "actual port" (check if this fragment can contain them, else "ANY") > > I do not think that the first two options would not require any code changes, > so would "only" impact product documentation. I think that the third would > also require a code change for some vendors. What do others in the working > group think about changing the minimum required functionality for fragments? I'm satisfied with not changing the minimum functionality as long as implementations are free to have additional/conflicting selector rules, including not discarding specified transport protocol/port fragments. It seems obvious but just wanted to make sure there wouldn't be an IPSEC conformance or interop issue. Thanks. -- Marc -- > > 3a) specific value, specific value NOT ANY (i.e., drop packet), or > first fragment ANY (pass the fragmented packet), or > actual port selector field > > 3b) specific value, specific value ANY (pass the fragmented packet) > other fragments > > Charlie > From owner-ipsec Thu Mar 12 17:32:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03314 for ipsec-outgoing; Thu, 12 Mar 1998 17:30:48 -0500 (EST) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Thu, 12 Mar 1998 23:17:04 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: RE: comments on draft-ietf-ipsec-ciph-cbc-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 12 Mar 1998, Roy Pereira wrote: > How many rounds do you suggest for IDEA? Not less than 6. But as the general cryptanalysis of IDEA is just beginning (on contrary of the cryptanalysis of DES-style ciphers, which has its traditions), I'd personally stick with the 8 rounds version of it: getting it 8.5/6.5 faster by omitting two rounds and by potentially decreasing the security is not a proper way. If you need speed, use some ciphers designed to be fast. E.g., CAST5, Blowfish, RC5, Square. A 8-round IDEA is (on MMX machines) only <20% slower than 16-round DES. It is not a big cost for the increased security. > >The weak key lists are incomplete, as they will probably always be. > >The chances of hitting one at random is negligible. What's the point ? > > > >What do you suggest we do with the weak key lists? From our knowledge, we > >did include all known weak keys. On page 4, the point should be clarified. I'm perfectly happy with not checking for weak keys of IDEA. But there could be a _suggestion_ to xor every subkey with a constant (see the paper by Daemen&Co). Another remark on the same draft. 3DES's key is 168-bits, 192 includes the parity bits. It should be clarified a bit better. I'd like to know where the speed estimates have been get from. [Schneier97] is not a valid reference: it has only estimations, which are completely wrong in the case of IDEA. Hint: ask Antoon Bosselaers (http://www.esat.kuleuven.ac.be/~bosselae/). I feel also that in the several places the draft should refer to "Handbook of Applied Cryptography" by MOV, not to [Schneier]. Helger Lipmaa Cybernetica Ltd, senior research engineer http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Thu Mar 12 22:12:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04977 for ipsec-outgoing; Thu, 12 Mar 1998 22:08:48 -0500 (EST) Date: Thu, 12 Mar 1998 19:23:29 -0800 From: mark@mentat.com (Marc Hasson) Message-Id: <199803130323.TAA04744@orna.mentat.com> To: pkoning@xedia.com Subject: Re: clarification Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, > Conceptually, IPSEC lives above IP, just like UDP or TCP do. > Reassembly is an IP layer function, so clients of IP (such as UDP, or > IPSEC) see fully assembled packets. Fragments don't appear on that > abstract interface at all, so it's not really meaningful to talk about > what you're required to do when you see them. I didn't get the point of this. I thought we were discussing what happens *within* something like an ESP tunnel mode packet when its actually carrying an IP fragment? Once a fragmented ESP packet is reassembled by IP and presented to your "IP client" IPSEC code what happens when there is a tunnelled IP fragment found after decryption? Do you reinsert it back into IP processing as if it came in "off the wire"? Or apply selection criteria in the context of the SA that this IP fragment came from? > > In addition, the interface from IPSEC to IP is an internal interface. > Internal interfaces are generally not subject to standardization > (unless you're talking about an API spec). Stating properties of such > interfaces as requirements is confusing. True, but I'm not talking about interfaces nor standardizing them. Just system behavior. If there's a statement in an IPSEC architecture document that implies fragmented packets arriving *within* an ESP/AH tunnel are to be discarded then I would think senders shouldn't waste their time to send them. :-) But we do allow senders (hosts or gateways) to tunnel fragments within an unfragmented (or fragmented) IPSEC ESP packet. And the "discard" statement is apparently not a MUST or conformance requirement so I think we're OK, for now. -- Marc -- From owner-ipsec Fri Mar 13 03:14:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA06733 for ipsec-outgoing; Fri, 13 Mar 1998 03:12:47 -0500 (EST) Date: Fri, 13 Mar 1998 10:26:51 +0200 (EET) From: Markku-Juhani Saarinen To: Roy Pereira cc: "'ipsec@tis.com'" Subject: RE: comments on draft-ietf-ipsec-ciph-cbc-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > How many rounds do you suggest for IDEA? IDEA has eight rounds. 4-round IDEA is a research toy, and should not even be called IDEA. X. Lai and J. Massey never proposed it for real-life applications. It apparently creeped into the drafts because Applied Cryptography says (2nd ed, p. 325): "(..) Currently the best attack against IDEA is faster than brute force only for 2.5 rounds or less; 4 round IDEA would be twice as fast and, as far as I know, just as secure." This does not reflect our 1998 knowledge. - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ipsec Fri Mar 13 09:41:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09294 for ipsec-outgoing; Fri, 13 Mar 1998 09:38:50 -0500 (EST) Date: Tue, 10 Mar 98 18:58:14 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9803102358.AA06308@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP-09 .ps Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 4 As promised, ISAKMP-09 PostScript. Doug ---------- X-Sun-Data-Type: postscript-file X-Sun-Data-Description: postscript-file X-Sun-Data-Name: draft-ietf-ipsec-isakmp-09.ps X-Sun-Content-Lines: 6429 %!PS-Adobe-2.0 %%Creator: dvipsk 5.55a Copyright 1986, 1994 Radical Eye Software %%Title: isakmp-draft.dvi %%Pages: 66 %%PageOrder: Ascend %%BoundingBox: 0 0 612 792 %%EndComments %DVIPSCommandLine: dvips -oisakmp-draft.ps isakmp-draft.dvi %DVIPSParameters: dpi=600, compressed, comments removed %DVIPSSource: TeX output 1998.03.10:1843 %%BeginProcSet: texc.pro /TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N /X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72 mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1} ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul TR[matrix currentmatrix{dup dup round sub abs 0.00001 lt{round}if} forall round exch round exch]setmatrix}N /@landscape{/isls true N}B /@manualfeed{statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{ /nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{ /sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0] N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{ 128 ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 sub]/id ch-image N /rw ch-width 7 add 8 idiv string N /rc 0 N /gp 0 N /cp 0 N{rc 0 ne{rc 1 sub /rc X rw}{G}ifelse}imagemask restore}B /G{{id gp get /gp gp 1 add N dup 18 mod S 18 idiv pl S get exec}loop}B /adv{cp add /cp X}B /chg{rw cp id gp 4 index getinterval putinterval dup gp add /gp X adv}B /nd{/cp 0 N rw exit}B /lsh{rw cp 2 copy get dup 0 eq{pop 1}{ dup 255 eq{pop 254}{dup dup add 255 and S 1 and or}ifelse}ifelse put 1 adv}B /rsh{rw cp 2 copy get dup 0 eq{pop 128}{dup 255 eq{pop 127}{dup 2 idiv S 128 and or}ifelse}ifelse put 1 adv}B /clr{rw cp 2 index string putinterval adv}B /set{rw cp fillstr 0 4 index getinterval putinterval adv}B /fillstr 18 string 0 1 17{2 copy 255 put pop}for N /pl[{adv 1 chg} {adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{ adv rsh nd}{1 add adv}{/rc X nd}{1 add set}{1 add clr}{adv 2 chg}{adv 2 chg nd}{pop nd}]dup{bind pop}forall N /D{/cc X dup type /stringtype ne{] }if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{ cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin 0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore showpage userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for 65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V {}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7 getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false} ifelse}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave newpath transform round exch round exch itransform moveto rulex 0 rlineto 0 ruley neg rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta 0 N /tail {dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}B /c{-4 M} B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{ 4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w}B /q{ p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p a}B /bos{/SS save N}B /eos{SS restore}B end %%EndProcSet TeXDict begin 40258431 52099146 1000 600 600 (isakmp-draft.dvi) @start /Fa 1 98 df<1407A24A7EA34A7EA3EC37E0A2EC77F01463A2ECC1F8A201017F 1480A2903803007EA301067FA2010E80010C131FA2496D7EA2013FB57EA2903830000749 6D7EA3496D7EA200018149130012036D801207D81FE0903801FF80D8FFF8010F13F8A22D 2C7DAB33>97 D E /Fb 58 124 df12 D14 D<150C151C153815F0EC01E0EC03C0EC0780EC0F00141E5C147C5C5C495A1303495A5C13 0F49C7FCA2133EA25BA25BA2485AA212035B12075BA2120F5BA2121FA290C8FCA25AA212 3EA2127EA2127CA412FC5AAD1278A57EA3121C121EA2120E7EA26C7E6C7EA212001E5274 BD22>40 D<140C140E80EC0380A2EC01C015E0A2140015F0A21578A4157C153CAB157CA7 15FCA215F8A21401A215F0A21403A215E0A21407A215C0140F1580A2141F1500A2143EA2 5CA25CA2495AA2495A5C1307495A91C7FC5B133E133C5B5B485A12035B48C8FC120E5A12 785A12C01E527FBD22>I44 D<387FFFF8A2B5FCA214F0150579941E>I<120EEA3F80127F12FFA31300127E123C0909 778819>I50 D<16E0ED01F01503A3150716E0A3150F16C0A2151F1680A2ED3F00A3157EA2157C15FC5D 14015D14035D14075D140F5D141F92C7FC143EA25CECF81C153E903801F07EEB03E014C0 90380780FE130F49485A133EEB7C01137801F05BEA01E03803C003EA0FFE391FFFC3F048 13FB267C01FF13403AF0003FFFE000601307C71400EC0FE05DA3141F5DA3143F92C7FCA4 143E141C24487DB72A>52 D57 D<133C137E13FF5AA313FE13FCEA00701300B2120EEA3F80127F12FFA31300127E123C10 2477A319>I65 D<0107B612FCEFFF8018 C0903B000FF0001FF04BEB07F81703021F15FC17014B14FEA2023F1400A24B1301A2147F 18FC92C7120318F84A140718F04AEC0FE0EF1FC00101ED3F80EF7F004AEB01FEEE07F849 B612E05F9139F80007F0EE01FC01076E7E177F4AEC3F80A2010F16C0171F5CA2131F173F 5CA2133FEF7F805C1800017F5D4C5A91C7485A5F49140FEE1FE0494A5A00014AB45AB748 C7FC16F816C037397BB83A>II<0103B612FEEFFFC018F0903B0007F8000FF84BEB03FCEF00FE 020F157FF03F804B141F19C0021F150F19E05D1807143F19F05DA2147FA292C8FCA25C18 0F5CA2130119E04A151FA2130319C04A153FA201071780187F4A1600A2010F16FEA24A4A 5A60011F15034D5A4A5D4D5A013F4B5A173F4A4AC7FC17FC017FEC03F84C5A91C7EA1FC0 4949B45A007F90B548C8FCB712F016803C397CB83F>I<0107B8FCA3903A000FF000034B EB007F183E141F181E5DA2143FA25D181C147FA29238000380A24A130718004A91C7FC5E 13015E4A133E167E49B512FEA25EECF8000107147C163C4A1338A2010F147818E04A1370 1701011F16C016004A14031880013F150718004A5CA2017F151E173E91C8123C177C4915 FC4C5A4914070001ED7FF0B8FCA25F38397BB838>I<0107B712FEA3903A000FF000074B 1300187C021F153CA25DA2143FA25D1838147FA292C8FCEE03804A130718004A91C7FCA2 01015CA24A131E163E010314FE91B5FC5EA2903807F800167C4A1378A2130FA24A1370A2 011F14F0A24A90C8FCA2133FA25CA2137FA291CAFCA25BA25B487EB6FCA337397BB836> II<0103B5D8F80FB512E0A390260007F8C7381FE0004B5DA2020F153F615DA2021F 157F96C7FC5DA2023F5D605DA2027F14016092C7FCA24A1403605CA249B7FC60A202FCC7 12070103150F605CA20107151F605CA2010F153F605CA2011F157F95C8FC5CA2013F5D5F 5CA2017F14015F91C7FC491403007FD9FE01B512F8B55BA243397CB83E>I<0103B512F8 A390390007F8005DA2140FA25DA2141FA25DA2143FA25DA2147FA292C7FCA25CA25CA213 01A25CA21303A25CA21307A25CA2130FA25CA2131FA25CA2133FA25CA2137FA291C8FC49 7EB6FCA25C25397CB820>I<0103B500F890387FFFE0A21AC090260007F8C7380FFC004B 15E061020F4BC7FC183E4B5C18F0021F4A5A4D5A4BEB0F804DC8FC023F143C5F4B5B4C5A 027FEB07C04CC9FCED001E5E4A5BED01FCECFE0315070101497E151FECFC7C4B7E903903 FDE07FDAFFC07F1580ED003F49488014F84A131F83130F160F4A801607011F81A24A1303 83133F16014A80A2017F6E7EA291C8FC494A7F007F01FE011F13FCB55CA243397CB840> 75 D<0107B512FCA25E9026000FF8C7FC5D5D141FA25DA2143FA25DA2147FA292C8FCA2 5CA25CA21301A25CA21303A25CA21307A25CA2130F170C4A141CA2011F153C17384A1478 A2013F157017F04A14E01601017F140317C091C71207160F49EC1F80163F4914FF000102 071300B8FCA25E2E397BB834>I<902607FFF8923807FFF0614F13E0D9000FEFF0004F5A A2021F167FF1EFC0141DDA1CFCEC01CF023C16DF9538039F800238ED071FA20278ED0E3F 97C7FC0270151CA202F04B5AF0707E14E0037E14E0010117FE4D485A02C0EC0380A20103 ED0701610280140EA20107ED1C0305385B14006F137049160705E05B010EEC01C0A2011E 913803800F61011CEC0700A2013C020E131F4C5C1338ED1FB80178163F04F091C8FC0170 5CA201F04A5B187E00015DD807F816FEB500C09039007FFFFC151E150E4C397AB84A>I< 902603FFF891B512E0A281D90007923807F8006F6E5A61020F5E81DA0E7F5DA2021E6D13 07033F92C7FC141C82DA3C1F5C70130EEC380FA202786D131E0307141C147082DAF00314 3C70133814E0150101016E1378030014705C8201036E13F0604A1480163F010715C1041F 5B91C7FC17E149EC0FE360010E15F31607011E15FF95C8FC011C80A2013C805F13381600 13785F01F8157CEA03FC267FFFE0143CB51538A243397CB83E>II<0107B612F817FF1880903B 000FF0003FE04BEB0FF0EF03F8141FEF01FC5DA2023F15FEA25DA2147FEF03FC92C7FCA2 4A15F817074A15F0EF0FE01301EF1FC04AEC3F80EFFE0001034A5AEE0FF091B612C04CC7 FCD907F8C9FCA25CA2130FA25CA2131FA25CA2133FA25CA2137FA291CAFCA25BA25B1201 B512FCA337397BB838>I<0103B612F017FEEFFF80903B0007F8003FC04BEB0FF0170702 0FEC03F8EF01FC5DA2021F15FEA25DA2143FEF03FC5DA2027FEC07F818F092C7120F18E0 4AEC1FC0EF3F004A14FEEE01F80101EC0FE091B6128004FCC7FC9138FC003F0103EC0F80 834A6D7E8301071403A25C83010F14075F5CA2011F140FA25CA2133F161F4AECE007A201 7F160F180E91C7FC49020F131C007F01FE153CB5913807F078040313F0CAEAFFE0EF3F80 383B7CB83D>82 D<92383FC00E913901FFF01C020713FC91391FC07E3C91393F001F7C02 7CEB0FF84A130749481303495A4948EB01F0A2495AA2011F15E091C7FCA34915C0A36E90 C7FCA2806D7E14FCECFF806D13F015FE6D6D7E6D14E0010080023F7F14079138007FFC15 0F15031501A21500A2167C120EA3001E15FC5EA3003E4A5AA24B5AA2007F4A5A4B5A6D49 C7FC6D133ED8F9F013FC39F8FC03F839F07FFFE0D8E01F138026C003FCC8FC2F3D7ABA2F >I<0007B812E0A25AD9F800EB001F01C049EB07C0485AD900011403121E001C5C003C17 801403123800785C00701607140700F01700485CA2140FC792C7FC5DA2141FA25DA2143F A25DA2147FA292C9FCA25CA25CA21301A25CA21303A25CA21307A25CA2130FA25CEB3FF0 007FB512F8B6FCA2333971B83B>I<003FB539800FFFFEA326007F80C7EA7F8091C8EA3F 00173E49153CA2491538A20001167817705BA2000316F05F5BA2000715015F5BA2000F15 035F5BA2001F150794C7FC5BA2003F5D160E5BA2007F151E161C90C8FCA2163C4815385A 16781670A216F04B5A5E1503007E4A5A4BC8FC150E6C143E6C6C5B15F0390FC003E03907 F01FC00001B5C9FC38007FFCEB1FE0373B70B83E>II< B5D8F80FB590381FFFF06102F018E0D807FEC7D87FE0903803FE00D803F8DA3F806D5AF1 00F0A24F5A621903621907047F92C7FC190E16FF4B5DA2DB03BF5C7F0001DA073F5CA203 0E5D83DB1C1F495A180303385D4EC8FC157003F0140E15E0DA01C05CA2DA03805CA2DA07 005CA2020E5D17C14A5DEFC3805C027802C7C9FC14704A14CE13FE6C6C4814DCA24A14F8 A291C75B160F495D5F5B5F5B4992CAFCA249140E4C3B6FB853>I<49B5D8F007B5FCA3D9 000790C713E0DA03FCEC7F00187C020115786F5C4D5A02005D6F495A4DC7FC6F5BEE801E 5F033F5BEEC0705F92381FC1C016E3EEE780DB0FEFC8FC16FE6F5A5EA2150382A2150782 150F151CED3CFF5D4B7EDA01E07FEDC03FDA03807FEC0700020E131F021E805C4A130F02 70805C49481307494880130749C71203011E81133E01FE81D807FF1407B500E090387FFF FC93B5FC6040397CB83E>II<14F8EB 07FE90381F871C90383E03FE137CEBF801120148486C5A485A120FEBC001001F5CA2EA3F 801403007F5C1300A21407485C5AA2140F5D48ECC1C0A2141F15831680143F1587007C01 7F1300ECFF076C485B9038038F8E391F0F079E3907FE03FC3901F000F0222677A42A>97 D<133FEA1FFFA3C67E137EA313FE5BA312015BA312035BA31207EBE0F8EBE7FE9038EF0F 80390FFC07C013F89038F003E013E0D81FC013F0A21380A2123F1300A214075A127EA214 0F12FE4814E0A2141F15C05AEC3F80A215005C147E5C387801F8007C5B383C03E0383E07 C0381E1F80D80FFEC7FCEA01F01C3B77B926>I<147F903803FFC090380FC1E090381F00 70017E13784913383901F801F83803F003120713E0120FD81FC013F091C7FC485AA2127F 90C8FCA35A5AA45AA3153015381578007C14F0007EEB01E0003EEB03C0EC0F806CEB3E00 380F81F83803FFE0C690C7FC1D2677A426>II<147F903803FFC090380FC1E09038 3F00F0017E13785B485A485A485A120F4913F8001F14F0383F8001EC07E0EC1F80397F81 FF00EBFFF891C7FC90C8FC5A5AA55AA21530007C14381578007E14F0003EEB01E0EC03C0 6CEB0F806CEB3E00380781F83803FFE0C690C7FC1D2677A426>IIIII107 DII I<147F903803FFC090380FC1F090381F00F8017E137C5B4848137E4848133E0007143F5B 120F485AA2485A157F127F90C7FCA215FF5A4814FEA2140115FC5AEC03F8A2EC07F015E0 140F007C14C0007EEB1F80003EEB3F00147E6C13F8380F83F03803FFC0C648C7FC202677 A42A>I<9039078007C090391FE03FF090393CF0787C903938F8E03E9038787FC0017049 7EECFF00D9F0FE148013E05CEA01E113C15CA2D80003143FA25CA20107147FA24A1400A2 010F5C5E5C4B5A131F5EEC80035E013F495A6E485A5E6E48C7FC017F133EEC70FC90387E 3FF0EC0F8001FEC9FCA25BA21201A25BA21203A25B1207B512C0A3293580A42A>II<3903C003F0390FF01FFC391E783C0F381C7C70 3A3C3EE03F8038383FC0EB7F800078150000701300151CD8F07E90C7FCEAE0FE5BA21200 12015BA312035BA312075BA3120F5BA3121F5BA3123F90C9FC120E212679A423>I<14FE 903807FF8090380F83C090383E00E04913F00178137001F813F00001130313F0A215E000 03EB01C06DC7FC7FEBFFC06C13F814FE6C7F6D13807F010F13C01300143F141F140F123E 127E00FE1480A348EB1F0012E06C133E00705B6C5B381E03E06CB45AD801FEC7FC1C267A A422>II<13F8D803FEEB 01C0D8078FEB03E0390E0F8007121E121C0038140F131F007815C01270013F131F00F013 0000E015805BD8007E133FA201FE14005B5D120149137EA215FE120349EBFC0EA2020113 1E161C15F813E0163CD9F003133814070001ECF07091381EF8F03A00F83C78E090393FF0 3FC090390FC00F00272679A42D>I<01F0130ED803FC133FD8071EEB7F80EA0E1F121C12 3C0038143F49131F0070140FA25BD8F07E140000E08013FEC6485B150E12015B151E0003 141C5BA2153C000714385B5DA35DA24A5A140300035C6D48C7FC0001130E3800F83CEB7F F8EB0FC0212679A426>I<903907E007C090391FF81FF89039787C383C9038F03E703A01 E01EE0FE3803C01F018013C0D8070014FC481480000E1570023F1300001E91C7FC121CA2 C75AA2147EA214FEA25CA21301A24A1370A2010314F016E0001C5B007E1401010714C000 FEEC0380010F1307010EEB0F0039781CF81E9038387C3C393FF03FF03907C00FC027267C A427>120 D<13F0D803FCEB01C0D8071EEB03E0D80E1F1307121C123C0038140F4914C0 1270A249131FD8F07E148012E013FEC648133F160012015B5D0003147E5BA215FE00075C 5BA214015DA314035D14070003130FEBF01F3901F87FE038007FF7EB1FC7EB000F5DA214 1F003F5C48133F92C7FC147E147C007E13FC387001F8EB03E06C485A383C1F80D80FFEC8 FCEA03F0233679A428>I123 D E /Fc 1 16 df 15 D E /Fd 3 63 df<121C127FEAFF80A5EA7F00121C0909798817>58 D60 D<124012F812FE6C7EEA3FE0EA 0FF8EA03FEC66C7EEB3FE0EB0FF8EB03FE903800FF80EC3FE0EC0FF8EC03FE913800FF80 ED3FE0ED0FF8ED03FE923800FF80EE3FE0EE0FF8EE03FE933800FF80EF3FC0A2EFFF8093 3803FE00EE0FF8EE3FE0EEFF80DB03FEC7FCED0FF8ED3FE0EDFF80DA03FEC8FCEC0FF8EC 3FE0ECFF80D903FEC9FCEB0FF8EB3FE0EBFF80D803FECAFCEA0FF8EA3FE0EAFF8048CBFC 12F81260323279AD41>62 D E /Fe 62 124 df<913803FFC0027F13F00103B512FC010F EB00FED93FF8133FD97FE0EBFF8049485A5A1480484A13C04A6C1380A36F1300167E93C7 FCA592383FFFC0B8FCA4000390C7FCB3ABB5D8FC3F13FFA4303A7EB935>12 D34 D<141C143C14F8EB01F0EB03E01307EB0FC0EB1F8014005B137E13FE5B12015B1203A248 5AA2120F5B121FA25B123FA4485AA512FFB1127FA56C7EA4121F7FA2120F7F1207A26C7E A212017F12007F137E7F7F1480EB0FC0EB07E01303EB01F0EB00F8143C141C165377BD25 >40 D<12E07E127C7E7E7F6C7E6C7E12037F6C7E7F12007F137E137FA2EB3F80A214C013 1F14E0A2130F14F0A4EB07F8A514FCB114F8A5EB0FF0A414E0131FA214C0133F1480A2EB 7F00A2137E13FE5B12015B485A5B1207485A485A90C7FC123E5A12F05A16537BBD25>I< B61280A819087F9620>45 DI<167016F8A2150116F0A2150316E0150716C0A2150F1680151F16005D15 3EA2157E157C15FC5DA214015D14035DA214075D140F5D141F92C7FCA25C143E147E147C A214FC5C13015CA213035C13075CA2130F5C131F91C8FC5B133EA2137E137C13FC5BA212 015B12035BA212075B120F5B121F90C9FCA25A123E127E127CA212FC5AA2127025537BBD 30>I<141E143E14FE1307133FB5FCA313CFEA000FB3B3A6007FB61280A4213779B630> 49 DIII<001C15C0D8 1F80130701F8137F90B61280A216005D5D15F05D15804AC7FC14F090C9FCA8EB07FE9038 3FFFE090B512F89038FC07FC9038E003FFD98001138090C713C0120EC813E0157F16F0A2 16F8A21206EA3F80EA7FE012FF7FA44914F0A26C4813FF90C713E0007C15C06C5B6C4913 80D9C0071300390FF01FFE6CB512F8000114E06C6C1380D90FF8C7FC25387BB630>II<123C123EEA3FE090B71280A41700485D 5E5E5EA25E007CC7EA0FC000784A5A4BC7FC00F8147E48147C15FC4A5A4A5AC7485A5D14 0F4A5A143F92C8FC5C147E14FE1301A2495AA31307A2130F5CA2131FA5133FA96D5A6D5A 6D5A293A7BB830>I<49B47E010F13F0013F13FC9038FE01FF3A01F8007F804848EB3FC0 4848EB1FE0150F485AED07F0121FA27FA27F7F01FEEB0FE0EBFF809138E01FC06CEBF03F 02FC13809138FF7F006C14FC6C5C7E6C14FE6D7F6D14C04914E048B612F0EA07F848486C 13F8261FE01F13FC383FC007EB8001007F6D13FE90C7123F48140F48140715031501A215 00A216FC7E6C14016D14F86C6CEB03F06D13076C6CEB0FE0D80FFEEB7FC00003B61200C6 14FC013F13F00103138027387CB630>III65 DII< B87E17F817FF18C028007FF8000713F09338007FF8EF1FFE717E050313807113C0A27113 E0F07FF0A2F03FF8A219FC181FA219FEA419FFAC19FEA419FC183FA219F8187F19F0F0FF E0A24D13C04D13804D1300EF1FFEEF7FFC933807FFF0B912C095C7FC17FC178040397DB8 49>IIIIII75 D77 DI80 D82 DI<003F B91280A4D9F800EBF003D87FC09238007FC049161F007EC7150FA2007C1707A200781703 A400F818E0481701A4C892C7FCB3AE010FB7FCA43B387DB742>III<0160130301E05B0003141F49131E48485B48C75A001E5CA248495A00385C00 78130300705CA300F013074891C7FCD8E7C0133ED8FFF0EBFF8001F814C0A201FC14E0A3 007F7FA26C486C13C0A26C486C1380D807C0EB3E00231D75B932>92 D97 D<13FFB5FCA412077EAF4AB47E020F13F0023F13FC9138FE03FFDAF000 13804AEB7FC00280EB3FE091C713F0EE1FF8A217FC160FA217FEAA17FCA3EE1FF8A217F0 6E133F6EEB7FE06E14C0903AFDF001FF80903AF8FC07FE009039F03FFFF8D9E00F13E0D9 C00390C7FC2F3A7EB935>I<903801FFC0010F13FC017F13FFD9FF8013802603FE0013C0 48485AEA0FF8121F13F0123F6E13804848EB7F00151C92C7FC12FFA9127FA27F123FED01 E06C7E15036C6CEB07C06C6C14806C6C131FC69038C07E006DB45A010F13F00101138023 257DA42A>I I<903803FF80011F13F0017F13FC3901FF83FE3A03FE007F804848133F484814C0001FEC 1FE05B003FEC0FF0A2485A16F8150712FFA290B6FCA301E0C8FCA4127FA36C7E1678121F 6C6C14F86D14F000071403D801FFEB0FE06C9038C07FC06DB51200010F13FC010113E025 257DA42C>II<161FD907FEEBFFC090387FFFE348B6EAEFE02607FE07138F260FF801131F48486C13 8F003F15CF4990387FC7C0EEC000007F81A6003F5DA26D13FF001F5D6C6C4890C7FC3907 FE07FE48B512F86D13E0261E07FEC8FC90CAFCA2123E123F7F6C7E90B512F8EDFF8016E0 6C15F86C816C815A001F81393FC0000F48C8138048157F5A163FA36C157F6C16006D5C6C 6C495AD81FF0EB07FCD807FEEB3FF00001B612C06C6C91C7FC010713F02B377DA530>I< 13FFB5FCA412077EAFED7FC0913803FFF8020F13FE91381F03FFDA3C01138014784A7E4A 14C05CA25CA291C7FCB3A3B5D8FC3F13FFA4303A7DB935>II<141FEC 7FC0ECFFE0A24913F0A56D13E0A2EC7FC0EC1F0091C7FCA9EC0FF0EB0FFFA4EB007F143F B3B0121FEA3F80EA7FC0EAFFE0EC7FE0A215C014FF6C481380903883FE006CB45A000F13 F0000113801C4B86BA1D>I<13FFB5FCA412077EAF92380FFFE0A4923803FC0016F0ED0F E0ED1F804BC7FC157E5DEC03F8EC07E04A5A141FEC7FE04A7E8181A2ECCFFEEC0FFF496C 7F806E7F6E7F82157F6F7E6F7E82150F82B5D8F83F13F8A42D3A7EB932>I<13FFB5FCA4 12077EB3B3ACB512FCA4163A7DB91B>I<01FED97FE0EB0FFC00FF902601FFFC90383FFF 80020701FF90B512E0DA1F81903983F03FF0DA3C00903887801F000749DACF007F000349 14DE6D48D97FFC6D7E4A5CA24A5CA291C75BB3A3B5D8FC1FB50083B512F0A44C257DA451 >I<01FEEB7FC000FF903803FFF8020F13FE91381F03FFDA3C011380000713780003497E 6D4814C05CA25CA291C7FCB3A3B5D8FC3F13FFA430257DA435>I<903801FFC0010F13F8 017F13FFD9FF807F3A03FE003FE048486D7E48486D7E48486D7EA2003F81491303007F81 A300FF1680A9007F1600A3003F5D6D1307001F5DA26C6C495A6C6C495A6C6C495A6C6C6C B45A6C6CB5C7FC011F13FC010113C029257DA430>I<9039FF01FF80B5000F13F0023F13 FC9138FE07FFDAF00113800003496C13C00280EB7FE091C713F0EE3FF8A2EE1FFCA3EE0F FEAA17FC161FA217F8163F17F06E137F6E14E06EEBFFC0DAF00313809139FC07FE009138 3FFFF8020F13E0020390C7FC91C9FCACB512FCA42F357EA435>I<49B4EB0780010FEBE0 0F013FEBF81F9039FFC07C3F0003EB803E3A07FE000F7F4848EB07FF121F497F123F497F 127FA25B12FFAA6C7EA36C7E5D6C7E000F5C6C6C5B6C6C133F6CEBC0FD39007FFFF1011F 13C10101130190C7FCAC037F13FEA42F357DA432>I<9038FE03F000FFEB0FFEEC3FFF91 387C7F809138F8FFC000075B6C6C5A5CA29138807F80ED3F00150C92C7FC91C8FCB3A2B5 12FEA422257EA427>I<90383FF0383903FFFEF8000F13FF381FC00F383F0003007E1301 007C130012FC15787E7E6D130013FCEBFFE06C13FCECFF806C14C06C14F06C14F81203C6 14FC131F9038007FFE140700F0130114007E157E7E157C6C14FC6C14F8EB80019038F007 F090B512C000F8140038E01FF81F257DA426>I<130FA55BA45BA25B5BA25A1207001FEB FFE0B6FCA3000390C7FCB21578A815F86CEB80F014816CEBC3E090383FFFC06D13809038 03FE001D357EB425>I<01FFEC3FC0B5EB3FFFA4000714016C80B3A35DA25DA26C5C6E48 13E06CD9C03E13FF90387FFFFC011F13F00103138030257DA435>IIIII123 D E /Ff 44 122 df12 D<151E153F15FF1403140F147F0107B5FC0003B6FCB7FCA314BFEB F83FEAFC00C7FCB3B3B3A4007FB81280A6314E76CD45>49 DI<91380FFFC091B512FE0107ECFFC0011F15F04915FC90267F F8077F9026FFC0007F4848C76C138048486E13C0486C6E13E0486C6C15F08082486D15F8 A380A25CA26C5D4A15F06C5B6C90C7FCC64816E090C85A18C04C138018004C5A4B5B4B5B 030F5B037F13C0027FB55A04FCC7FC16F016FEEEFFC0DA000713F0030113FC6F6CB4FC70 13807013C018E07013F018F818FCA27013FEA3D801E016FFEA0FFC487E487E487FA2B57E A318FEA25E18FC6C5B18F891C75A6C4816F0D81FF84A13E06D4A13C06CB449B512806CD9 F00714006C90B65AC616F8013F15E0010F1580010102FCC7FCD9001F13C0384F7ACD45> I<173F4D7E17FF5E5EA25E5E5E5EA25E93B5FC5D5DA25D5DED1FDFED3F9FED7F1FA215FE EC01FCEC03F8EC07F0A2EC0FE0EC1FC0EC3F80EC7F00A214FE495A495A495A5C130F495A 495A49C7FC13FEA2485A485A485A485AA2485A485A48C8FC12FEBA12F0A6C9003FEB8000 AE0207B712F0A63C4E7CCD45>II<923807FF80037F13F00203B512FC021F14FF027F158091B5000113C001039039F800 3FE04901E0130F490180EB3FF04990C712FF49485B494815F849485B5A5C5A485BA2486F 13F05C486F13E0EF3F8094C7FC5AA25C5AA2ED3FF80281B57E028314E0B5008714F8028F 80DA9FC07F9139BF001FFF02FC6D13807013C04A6D13E04A15F018F84A7F18FCA24A15FE A44A15FFA37EA67EA46C17FE80A26C17FCA26C4B13F8806C17F06C6D15E06C5D6E4913C0 D97FFE4913806D6C6CB512006D90B512FC01075D6D5D010015C0021F49C7FC020313E038 4F7ACD45>I65 DI<932601FFFCEC03C0047FD9FFC013 070307B600F8130F033F03FE131F92B8EA803F0203EFC0FF020FDAF00113F1023F49C7EA 3FFB4A01F00207B5FC49B500C0804991C9FC4949824901F88249498249498249498290B5 488292CAFC4885485B86485B481A7FA24849183FA3485B1B1FA25AA24A95C7FCA3B5FCAE 7EA280A2F30FC07EA36C7FA21B1F6C6D1980A26C1A3F6C7F1C006C6D606C6E17FEA26D6D 4C5A6D6D4C5A6D6D16076D6D4C5A6D01FE4C5A6D6D4C5A6D02C0EDFF806D6C01F8020390 C7FC6E01FFEC1FFE020F02F0EBFFF8020391B65A020017C0033F93C8FC030715FCDB007F 14E0040101FCC9FC525478D263>IIII73 D75 DIII 80 D82 D<91261FFF80130F91B500F85B010702FF5B011FEDC07F49EDF0FF90B712F948D9FC0190 B5FC489038E0000F48018013034848C8FC173F4848814981003F8283485A838312FFA284 7FA26D82A27F7F6E92C7FC14E06C13FCECFFC015FE6CECFFE016FF6C16E017F86C16FE6C 82846C17E06C836C837F011F826D82010382EB007F020F1680EC007F1503DB003F14C016 031600053F13E0838383127C00FC82A383A27E19C0A27EA26D4B1380A27F6D4B130001F8 5E6D150F01FF4B5A02C04A5A02F8ECFFF09126FFC0075B019F90B65A010F5ED8FE034BC7 FC48C66C5C48010F14E0489026007FFEC8FC3B5478D24C>I<001FBC12C0A5481BE09126 F0003F9038E0007F91C7160701FC1801498401E0193FA249191F49190FA248C8EF07F0A4 007E1A03A500FE1BF8481A01A4C994C7FCB3B3AA91B912F8A655517BD060>I<91383FFF C00107B512FC011FECFF80017F15E090B77E48D9E0077F48D9800013FE486DEB3FFF8248 6D81707F8284A2707F6C5BA26C5BC648C7FC90C8FCA44BB5FC4AB6FC143F49B7FC130F01 3FEBFE0390B512E0000314004813FC4813F0485B485B5C4890C7FCA2B5FC5BA35EA27F6C 5D5E6E497F6C6D017E13FE6C6D4848EBFFF86C9026FC0FF814FC6C90B5487E0001EDC03F 6C6CEC800F011F9026FE000313F8010101E090C8FC3E387CB643>97 D I<913803FFF0023FEBFF8091B612E0010315F8010F81499038C01FFE903A7FFE0007FF49 48491380485B48494913C05C5A485BA2485B7013805A70130048ED01FC91CAFCA3B5FCAD 7E80A27EA2EF07E06C7F170F6C6D15C06C161F6E15806C6D143F6C6DEC7F006C6D14FE90 3A7FFF8003FC6D9038F01FF8010F90B55A6D5D01011580D9003F49C7FC020313E033387B B63D>I<943801FFC00407B5FCA6EE001F1707B3A3913803FFC0023F13FC49B6FC010715 C74915F7013FD9E03FB5FC49EB0007D9FFFC130148496D7E484980484980484980A25A5C 5AA25A91C8FCA3B5FCAD7EA46C7FA27EA26C6D5CA26C6D5C6C5E6C6D49B5FC6C6D4914F0 D97FFE010FECFFC0903A3FFF807FEF6D90B512CF0107158F6DECFE0FD9007F13F0020701 8049C7FC42547BD24C>I<913803FFE0023F13FE91B612C0010381010F15F84901C07F90 3A7FFE001FFE49486D7E48496D138048496D13C0484915E048814A15F048815C48EE7FF8 A25A91C8FC18FC173FB5FCA391B7FCA418F891CAFCA57EA3807EA218786C6D15FC17016C 7F6CEE03F86C6D14076E15F06C6DEC1FE06C6C6C143F6D6C6CEBFFC06DD9F00713000107 90B55A010115F86D6C14E0021F1480020001F8C7FC36387CB63F>II<91261FFF80EB3FC049B539F803FFE00107DAFE0F13F0011FDAFF BF13F8017F92B512FC9026FFFC0314CF48D9F000EBFC1F4801C0013F130F4816FE4849D9 1FFF13F8F007F04890C76CEB81E0F08000A24883A86C5FA36C6D4990C7FCA26C6D495A6C 5E6C01F0EBFFF86CD9FC035B4890B65A1780D803E74AC8FC01E114F82607E01F138091CB FC120FA37FA27F13FE90B712C06C16FCEFFF8018E06C17F8846C836C836D178048B912C0 12074818E04848C8FCD83FF8150F4848030313F01700485A187FA56D16FF007F18E06D5D 6C6C4B13C06C6C4B13806C6C6C021F13006C01F0ECFFFE6C01FF010F5BC691B612F0013F 16C0010F93C7FC010115F8D9000749C8FC3E4F7CB545>II<137F3801 FFC0487F487F487FA2487FA76C5BA26C5B6C5B6C5B6C6CC7FC90C8FCABEB1FF8B5FCA612 017EB3B3A4B612F0A61C547BD326>I107 DIIIII<90393FF001FFB5010F13E04B13 F84B7F4B7F9238FF1FFFECF1FC00039026F3F03F1380C6EBF7E015C0ECFF80A215007013 005C705AEE03F84A90C8FCA45CB3A9B612FEA631367CB539>114 D<903A01FFF00780011FEBFF1F90B7FC5A120748EB001FD81FF8130701E0130148487F00 7F157F49143FA200FF151FA27FA27F01F891C7FC13FF14F06CEBFFC015FE6F7E6C15E06C 15F86C816C816C816C16806C6C15C0011F15E01303D9001F14F01400030713F81501007C EC007F00FC153F161F7E160F7EA26D15F0A26D141F6D15E06D143F6DEC7FC001FE903801 FF809026FFC00F130091B55A01BF5CD8FE1F14F0D8FC0714C027F0007FFCC7FC2D387CB6 36>I<143FA65CA45CA25BA35B5BA25B5B5B90B5FC5A000F91B5FCB8FCA5D8003F90C8FC B3A8EE07E0AB6DEC0FC01580161F6D01C01380163F6D9038F07F006DEBFFFE6D5C6D6C5B 021F13E0020313802B4D7ECB35>II119 D<007FB500F8013FB51280A6D8003F0180D907FEC7FC6D6D6D5A6D6D495A 6D6D495A6D4B5A6D6D495A6F495A6D6D49C8FC6E6C485A6E13816EEB83FC6EEBC7F8EEEF F06EEBFFE06E5C6E5C6E91C9FC81A26F7F6F7F6F7F5D4B7F4B7F92B57E834A486C7E4A48 7EDA07F8804A486C7F4A486C7F4A486C7F4A486C7F82DAFF008049486D7F49486E7E4948 6E7F49486E7F013F81B691B612F0A644357EB449>II E /Fg 77 127 df<121C127FEAFF80B1EA7F00AF123EC7FCA8121C127FA2EAFF80A3EA7F 00A2121C09346FB32C>33 D<003C131E007F137F481480A66C1400A6007E7FA6003E133E A3003C131E001C131C191977B32C>I<010F133C90381F807EA8013F13FE4A5AA4007FB6 12F0B712F8A4003F15F03A007E01F800A5EBFE0301FC5BA6003FB612F0B712F8A46C15F0 3A01F807E000A30003130F01F05BA86C486C5A25337DB22C>I39 D<143814FC13011303EB07F8EB0FF0EB1FC0EB3F80EB7F0013 FE485A485A5B12075B120F5B485AA2123F90C7FCA25A127EA312FE5AAC7E127EA3127F7E A27F121FA26C7E7F12077F12037F6C7E6C7E137FEB3F80EB1FC0EB0FF0EB07F8EB03FC13 0113001438164272B92C>I<127012FC7E7E6C7E6C7EEA0FE06C7E6C7E6C7E6C7E137F7F 1480131F14C0130FEB07E0A214F01303A214F81301A314FC1300AC130114F8A3130314F0 A2130714E0A2EB0FC0131F1480133F14005B13FE485A485A485A485AEA3FC0485A48C7FC 5A5A1270164279B92C>II<147814FCAF007FB612F0B712F8A46C15F0C700FCC7FCAF147825267DAB2C>II<007FB6FCB71280A46C150021067B9B2C>I<12 1FEA3F80EA7FC0EAFFE0A5EA7FC0EA3F80EA1F000B0B708A2C>I<1507ED0F80151FA215 3F16005D157E15FE5D14015D14035DA214075D140F5D141F5D143F92C7FC5C147E14FE5C A213015C13035C13075C130F5C131F5CA2133F91C8FC5B137E13FE5B12015B12035B1207 5BA2120F5B121F5B123F90C9FC5A127E12FE5AA25A127821417BB92C>II<1307497EA2131FA2133F137F13FF5A1207127FB5FC 13DF139FEA7C1F1200B3AE007FB512E0B612F0A36C14E01C3477B32C>IIII<000FB512FE4880A35D0180C8FCADEB83FE 90389FFF8090B512E015F8819038FE03FE9038F000FF01C07F49EB3F8090C7121F6C15C0 C8120FA2ED07E0A4123C127EB4FC150F16C0A248141F007EEC3F80007FEC7F006C6C5B6D 485A391FF80FFC6CB55A6C5C000114C06C6C90C7FCEB0FF823347CB22C>II<1278B712C016E0A316C000FCC7EA3F80ED 7F0015FE00785CC712014A5A4A5A5D140F5D4A5A143F92C7FC5C147E14FE5C13015CA249 5AA213075CA3495AA4495AA5133F91C8FCAA131E23357CB32C>III<121FEA3F80EA7FC0EAFFE0A5EA7FC0EA3F80EA1F00C7FCAE121FEA3F80EA7F C0EAFFE0A5EA7FC0EA3F80EA1F000B2470A32C>II<1507ED1F80153F15FF1403 4A1300EC1FFC4A5AECFFE0491380010790C7FCEB0FFCEB3FF8EB7FE048485A4890C8FCEA 0FFEEA1FF8EA7FF0EAFFC05BA27FEA7FF0EA1FF8EA0FFEEA03FF6C13C06C6C7EEB3FF8EB 0FFC6DB4FC01017F6D13E0EC3FF86E7EEC07FF6E13801400153F151FED0700212A7BAD2C >I<003FB612E04815F0B712F8A36C15F0CAFCA8007FB612F0B712F8A36C15F06C15E025 147DA22C>I<127012FC7E6C7E13E06C7EEA1FFC6C7E3803FF80C67FEB7FF0EB1FF8EB0F FEEB03FF6D13C06D6C7EEC3FF8EC0FFC6EB4FC0201138080A25C02071300EC0FFCEC3FF8 EC7FE049485A4990C7FCEB0FFEEB1FF8EB7FF0EBFFC000035BD80FFEC8FC485AEA7FF048 5A138048C9FC5A1270212A7BAD2C>I64 D<14FE497EA4497FA214 EFA2130781A214C7A2010F7FA314C390381F83F0A590383F01F8A490387E00FCA549137E 90B512FEA34880A29038F8003FA34848EB1F80A4000715C049130FD87FFEEBFFFC6D5AB5 14FE6C15FC497E27347EB32C>I<02FF13700107EBE0F84913F9013F13FD4913FFEBFF81 3901FE007F4848131FD807F0130F1507485A491303485A150148C7FCA25A007EEC00F016 00A212FE5AAB7E127EA3007F15F06CEC01F8A26C7EA26C6C13036D14F06C6C130716E0D8 03FC131F6C6CEB3FC03A00FF81FF806DB512006D5B010F5B6D13F00100138025357DB32C >67 D<007FB5FCB612C015F0816C803907E003FEEC00FFED7F80153FED1FC0ED0FE0A215 0716F0150316F81501A4ED00FCACED01F8A3150316F0A2150716E0150FED1FC0153FED7F 80EDFF00EC03FE007FB55AB65A5D15C06C91C7FC26337EB22C>I<007FB612F0B712F8A3 7E3903F00001A7ED00F01600A4EC01E04A7EA490B5FCA5EBF003A46E5A91C8FCA5163C16 7EA8007FB612FEB7FCA36C15FC27337EB22C>I<007FB612F8B712FCA37ED803F0C7FCA7 16781600A515F04A7EA490B5FCA5EBF001A46E5A92C7FCAD387FFFE0B5FC805C7E26337E B22C>I<903901FC038090390FFF87C04913EF017F13FF90B6FC4813073803FC01497E48 48137F4848133F49131F121F5B003F140F90C7FCA2127EED078092C7FCA212FE5AA89138 03FFF84A13FCA27E007E6D13F89138000FC0A36C141FA27F121F6D133F120F6D137F6C7E 6C6C13FF6D5A3801FF076C90B5FC6D13EF011F13CF6DEB0780D901FCC7FC26357DB32C> II<007FB512F8B612FCA36C14F839000F C000B3B3A5007FB512F8B612FCA36C14F81E3379B22C>I75 D<387FFFE0B57EA36C5BD803F0C8FCB3AE16F0ED01F8A8 007FB6FCB7FCA36C15F025337DB22C>IIII<007FB512C0B612F88115FF 6C15802603F00013C0153FED0FE0ED07F0A2150316F81501A6150316F01507A2ED0FE0ED 3FC015FF90B61280160015FC5D15C001F0C8FCB0387FFF80B57EA36C5B25337EB22C>I< 387FFFFCB67E15E015F86C803907E007FE1401EC007F6F7E151FA26F7EA64B5AA2153F4B C7FCEC01FE140790B55A5D15E081819038E007FCEC01FE1400157F81A8160FEE1F80A5D8 7FFEEB1FBFB5ECFF00815E6C486D5AC8EA01F029347EB22C>82 D<90381FF80790B5EA0F 804814CF000714FF5A381FF01F383FC003497E48C7FC007E147F00FE143F5A151FA46CEC 0F00007E91C7FC127F7FEA3FE0EA1FFCEBFFC06C13FC0003EBFFC06C14F06C6C7F01077F 9038007FFEEC07FF02001380153FED1FC0A2ED0FE0A20078140712FCA56CEC0FC0A26CEC 1F806D133F01E0EB7F009038FE01FF90B55A5D00F914F0D8F83F13C0D8700790C7FC2335 7CB32C>I<007FB612FCB712FEA43AFC007E007EA70078153CC71400B3AF90383FFFFCA2 497F6D5BA227337EB22C>I<3B7FFF803FFFC0B56C4813E0A36C496C13C03B03F00001F8 00B3AF6D130300015DA26D130700005D6D130F017F495A6D6C485AECE0FF6DB5C7FC6D5B 010313F86D5B9038003F802B3480B22C>II89 D<127812F87EA27E127E127F7E7F121F7F120F7F1207A27F1203 7F12017F12007F137E137F7F80131FA280130F801307801303801301801300A280147E14 7F8081141F81140F811407811403A281140181140081157E157F811680151FA2150FED07 0021417BB92C>92 D<130EEB3F80EBFFE0000313F8000F13FE487FD87FF113C0D8FFE013 E0EB803F38FE000F007CEB07C00030EB01801B0C78B22C>94 D<3801FFF0000713FE001F 6D7E15E048809038C01FF81407EC01FC381F80000006C77EC8127EA3ECFFFE131F90B5FC 1203120F48EB807E383FF800EA7FC090C7FC12FE5AA47E007F14FEEB8003383FE01F6CB6 12FC6C15FE6C14BF0001EBFE1F3A003FF007FC27247CA32C>97 DI<903803FFE001 1F13F8017F13FE48B5FC48804848C6FCEA0FF0485A49137E4848131890C9FC5A127EA25A A8127EA2127F6C140F6DEB1F806C7E6D133F6C6CEB7F003907FE03FF6CB55A6C5C6C6C5B 011F13E0010390C7FC21247AA32C>IIIIII<1307EB1FC0A2497EA36D5AA2 0107C7FC90C8FCA7387FFFC080B5FC7EA2EA0007B3A8007FB512FCB612FEA36C14FC1F34 79B32C>I<140EEC3F80A2EC7FC0A3EC3F80A2EC0E0091C7FCA748B512804814C0A37EC7 120FB3B3A2141F003C1480007E133FB414005CEB01FEEBFFFC6C5B5C001F5B000790C7FC 1A467CB32C>II<387FFFE0B57EA37EEA0003B3B3A5007FB61280B712C0A36C15802233 7BB22C>I<3A7F83F007E09039CFFC1FF83AFFDFFE3FFCD87FFF13FF91B57E3A07FE1FFC 3E01FCEBF83F496C487E01F013E001E013C0A301C01380B33B7FFC3FF87FF0027F13FFD8 FFFE6D13F8D87FFC4913F0023F137F2D2481A32C>I<397FF01FE039FFF87FFC9038F9FF FE01FB7F6CB6FC00019038F03F80ECC01F02807FEC000F5B5BA25BB3267FFFE0B5FCB500 F11480A36C01E0140029247FA32C>II<397FF01FE039FFF8FFF801FB13FE90B6FC 6C158000019038F07FC09138801FE091380007F049EB03F85BED01FC491300A216FE167E A816FE6D14FCA2ED01F86D13036DEB07F0150F9138801FE09138E07FC091B51280160001 FB5B01F813F8EC3FC091C8FCAD387FFFE0B57EA36C5B27367FA32C>I<903903FC078090 391FFF0FC0017F13CF48B512EF4814FF3807FE07380FF00148487E49137F4848133F90C7 FC48141F127E150F5AA87E007E141FA26C143F7F6C6C137F6D13FF380FF0033807FC0F6C B6FC6C14EF6C6C138F6D130FEB07F890C7FCAD0203B5FC4A1480A36E140029367DA32C> II<90387FF870 0003B512F8120F5A5A387FC00F387E00034813015AA36CEB00F0007F140013F0383FFFC0 6C13FE6CEBFF80000314E0C66C13F8010113FCEB0007EC00FE0078147F00FC143F151F7E A26C143F6D133E6D13FE9038F007FC90B5FC15F815E000F8148039701FFC0020247AA32C >I<131E133FA9007FB6FCB71280A36C1500D8003FC8FCB1ED03C0ED07E0A5EC800F011F EB1FC0ECE07F6DB51280160001035B6D13F89038003FE0232E7EAD2C>I<3A7FF003FF80 486C487FA3007F7F0001EB000FB3A3151FA2153F6D137F3900FE03FF90B7FC6D15807F6D 13CF902603FE07130029247FA32C>I<3A7FFF01FFFCB514FE148314016C15FC3A03E000 0F80A26D131F00011500A26D5B0000143EA26D137E017C137CA2017E13FC013E5BA2EB3F 01011F5BA21483010F5BA214C701075BA214EF01035BA214FF6D90C7FCA26D5A147C2724 7EA32C>II<3A3FFF03FFF048018713 F8A36C010313F03A00FC007E005D90387E01F8013F5BEB1F83EC87E090380FCFC0903807 EF80EB03FF6D90C7FC5C6D5A147C14FE130180903803EF80903807CFC0EB0FC7EC83E090 381F01F0013F7FEB7E00017C137C49137E0001803A7FFF01FFFC1483B514FE6C15FC1401 27247EA32C>I<3A7FFF01FFFCB5008113FE148314816C010113FC3A03E0000F806C7E15 1F6D140012005D6D133E137C017E137E013E137CA2013F13FC6D5BA2EB0F815DA2EB07C1 ECC3E0A2EB03E3ECE7C0130114F75DEB00FFA292C7FC80A2143EA2147E147CA214FC5CA2 EA0C01003F5BEA7F83EB87E0EA7E0F495A387FFF806C90C8FC6C5A6C5AEA07E027367EA3 2C>I<003FB612E04815F0A4007EC7EA1FE0ED3FC0ED7F80EDFF004A5A003C495AC7485A 4A5A4A5A4A5A4A5A4AC7FCEB01FC495AEB0FF0495A495A495A49C8FC4848EB01E04848EB 03F0485A485A485A485A485AB7FCA46C15E024247DA32C>I<01F81370D803FE13F8380F FF0148138748EBCFF0397F9FFFE0D8FF0F13C0D8FC07138039F803FE00387000F81D0A79 B22C>126 D E /Fh 37 123 df12 D<14C01301EB0380EB0F00130E5B133C5B5BA2 485A485AA212075B120F90C7FC5AA2121E123EA3123C127CA55AB0127CA5123C123EA312 1E121FA27E7F12077F1203A26C7E6C7EA213787F131C7F130FEB0380EB01C01300124A79 B71E>40 D<12C07E1270123C121C7E120F6C7E6C7EA26C7E6C7EA27F1378137C133C133E A2131E131FA37F1480A5EB07C0B0EB0F80A514005BA3131E133EA2133C137C137813F85B A2485A485AA2485A48C7FC120E5A123C12705A5A124A7CB71E>I<123C127EB4FCA21380 A2127F123D1201A412031300A25A1206120E120C121C5A5A126009177A8715>44 DI<123C127E12FFA4127E123C08087A8715>I<15E0A34A7EA24A 7EA34A7EA3EC0DFE140CA2EC187FA34A6C7EA202707FEC601FA202E07FECC00FA2D90180 7F1507A249486C7EA301066D7EA2010E80010FB5FCA249800118C77EA24981163FA2496E 7EA3496E7EA20001821607487ED81FF04A7ED8FFFE49B512E0A333367DB53A>65 D73 D75 D 77 D80 D<90381FE00390387FFC0748B5FC3907F01FCF390F8003FF48C7FC00 3E80814880A200788000F880A46C80A27E92C7FC127F13C0EA3FF013FF6C13F06C13FF6C 14C06C14F0C680013F7F01037F9038003FFF140302001380157F153FED1FC0150F12C0A2 1507A37EA26CEC0F80A26C15006C5C6C143E6C147E01C05B39F1FC03F800E0B512E0011F 138026C003FEC7FC22377CB42B>83 D<007FB712FEA390398007F001D87C00EC003E0078 161E0070160EA20060160600E01607A3481603A6C71500B3AB4A7E011FB512FCA330337D B237>I97 DII<153FEC0FFFA3EC007F81AEEB07F0EB3FFCEBFC0F3901F003BF39 07E001FF48487E48487F8148C7FCA25A127E12FEAA127E127FA27E6C6C5BA26C6C5B6C6C 4813803A03F007BFFC3900F81E3FEB3FFCD90FE0130026357DB32B>III<151F90391FC07F809039FFF8E3C03901F07FC73907E03F033A0FC01F8380 9039800F8000001F80EB00074880A66C5CEB800F000F5CEBC01F6C6C48C7FCEBF07C380E FFF8380C1FC0001CC9FCA3121EA2121F380FFFFEECFFC06C14F06C14FC4880381F000100 3EEB007F4880ED1F8048140FA56C141F007C15006C143E6C5C390FC001F83903F007E0C6 B51280D91FFCC7FC22337EA126>III107 DI<2703F01FE013FF00FF 90267FF80313C0903BF1E07C0F03E0903BF3803E1C01F02807F7003F387FD803FE147049 6D486C7EA2495CA2495CB3486C496C487EB53BC7FFFE3FFFF0A33C217EA041>I<3903F0 1FC000FFEB7FF09038F1E0FC9038F3807C3907F7007EEA03FE497FA25BA25BB3486CEB7F 80B538C7FFFCA326217EA02B>II<3903F03F8000FFEBFFE09038F3C0F89038F7007ED807FE7F6C48EB1F804914C049 130F16E0ED07F0A3ED03F8A9150716F0A216E0150F16C06D131F6DEB3F80160001FF13FC 9038F381F89038F1FFE0D9F07FC7FC91C8FCAA487EB512C0A325307EA02B>I<903807F0 0390383FFC07EBFC0F3901F8038F3807E001000F14DF48486CB4FC497F123F90C77E5AA2 5A5AA9127FA36C6C5B121F6D5B000F5B3907E003BF3903F0073F3800F81EEB3FF8EB0FE0 90C7FCAAED7F8091380FFFFCA326307DA029>I<3803E07C38FFE1FF9038E38F809038E7 1FC0EA07EEEA03ECA29038FC0F8049C7FCA35BB2487EB512E0A31A217FA01E>II<1330A51370A313F0A21201A2120312 07381FFFFEB5FCA23803F000AF1403A814073801F806A23800FC0EEB7E1CEB1FF8EB07E0 182F7FAD1E>IIII<3A7FFF807FF8A33A07F8001FC00003EC0F800001EC07 0015066C6C5BA26D131C017E1318A26D5BA2EC8070011F1360ECC0E0010F5BA2903807E1 80A214F3010390C7FC14FBEB01FEA26D5AA31478A21430A25CA214E05CA2495A1278D8FC 03C8FCA21306130EEA701CEA7838EA1FF0EA0FC025307F9F29>121 D<003FB512F0A2EB000F003C14E00038EB1FC00030EB3F800070137F1500006013FE495A 13035CC6485A495AA2495A495A49C7FC153013FE485A12035B48481370485A001F146049 13E0485A387F000348130F90B5FCA21C207E9F22>I E /Fi 7 117 df65 D97 DI<903807FF80013F13F090B512FC3903FE01FE4848487EEA0FF8 EA1FF0EA3FE0A2007F6D5A496C5A153000FF91C7FCA9127F7FA2003FEC07807F6C6C130F 000FEC1F00D807FE133E3903FF80FCC6EBFFF8013F13E0010790C7FC21217DA027>I<39 01F81F8000FFEB7FF0ECFFF89038F9E3FC9038FBC7FE380FFF876C1307A213FEEC03FCEC 01F8EC0060491300B1B512F0A41F217EA024>114 D<9038FFE1C0000713FF5A383F803F 387E000F14075A14037EA26C6CC7FC13FCEBFFE06C13FC806CEBFF80000F14C06C14E0C6 FC010F13F0EB007F140F00F0130714037EA26C14E06C13076CEB0FC09038C01F8090B512 0000F913FC38E03FE01C217DA023>I<133CA5137CA313FCA21201A212031207001FB512 80B6FCA3D807FCC7FCB0EC03C0A79038FE078012033901FF0F006C13FEEB3FFCEB0FF01A 2F7EAE22>I E /Fj 59 122 df12 D40 D<12F07E127E7E6C7E6C7E6C7E7F6C7E6C7E12007F137F80133F806D7EA26D7EA26D7EA2 801303A2801301A280A27F1580A4EC7FC0A615E0A2143FAE147FA215C0A6ECFF80A41500 5BA25CA213035CA213075CA2495AA2495AA2495A5C137F91C7FC13FE5B1201485A485A5B 485A485A48C8FC127E12F85A1B647ACA2C>I46 DI< EC3FF849B5FC010F14E0013F14F890397FF01FFC9039FFC007FE4890380001FF48486D13 80000716C049147F000F16E049143F001F16F0A2003F16F8A249141F007F16FCA600FF16 FEB3A3007F16FCA56C6CEC3FF8A3001F16F0A2000F16E06D147F000716C06D14FF6C6C49 13806C6D4813006C6D485A90397FF01FFC6DB55A010F14E0010314809026003FF8C7FC2F 427CC038>IIII<163FA25E5E5D5D A25D5D5D5DA25D92B5FCEC01F7EC03E7140715C7EC0F87EC1F07143E147E147C14F8EB01 F0EB03E0130714C0EB0F80EB1F00133E5BA25B485A485A485A120F5B48C7FC123E5A12FC B91280A5C8000F90C7FCAC027FB61280A531417DC038>I<0007150301E0143F01FFEB07 FF91B6FC5E5E5E5E5E16804BC7FC5D15E092C8FC01C0C9FCAAEC3FF001C1B5FC01C714C0 01DF14F09039FFE03FFC9138000FFE01FC6D7E01F06D13804915C0497F6C4815E0C8FC6F 13F0A317F8A4EA0F80EA3FE0487E12FF7FA317F05B5D6C4815E05B007EC74813C0123E00 3F4A1380D81FC0491300D80FF0495AD807FEEBFFFC6CB612F0C65D013F1480010F01FCC7 FC010113C02D427BC038>I<4AB47E021F13F0027F13FC49B6FC01079038807F8090390F FC001FD93FF014C04948137F4948EBFFE048495A5A1400485A120FA248486D13C0EE7F80 EE1E00003F92C7FCA25B127FA2EC07FC91381FFF8000FF017F13E091B512F89039F9F01F FC9039FBC007FE9039FF8003FF17804A6C13C05B6F13E0A24915F0A317F85BA4127FA512 3FA217F07F121FA2000F4A13E0A26C6C15C06D4913806C018014006C6D485A6C9038E01F FC6DB55A011F5C010714C0010191C7FC9038003FF02D427BC038>I<121E121F13FC90B7 12FEA45A17FC17F817F017E017C0A2481680007EC8EA3F00007C157E5E00785D15014B5A 00F84A5A484A5A5E151FC848C7FC157E5DA24A5A14035D14074A5AA2141F5D143FA2147F 5D14FFA25BA35B92C8FCA35BA55BAA6D5A6D5A6D5A2F447AC238>III<903807FFC0013F13FC48B612804815E0260FF80013F0D81FC0EB3FF848C7EA1F FC4815FE01C0130F486C14FF7FA66C485B6C4814FE000FC7FCC8EA3FFCED7FF8EDFFF04A 13E04A13801600EC07FC4A5A5D4A5A5D4A5A92C7FCA2147E147CA31478AA91C8FCA814F8 EB03FE497E497FA2497FA56D5BA26D90C7FC6D5AEB00F828467AC535>63 D65 DIII< BA12F8A485D8001F90C71201EF003F180F180318011800A2197E193EA3191EA21778A285 A405F890C7FCA316011603161F92B5FCA5ED001F160316011600A2F101E01778A2F103C0 A494C7FC1907A21A80A2190FA2191FA2193FF17F0061601807181F4DB5FCBBFC61A44344 7DC34A>II III75 D77 DI<923807FFC092 B512FE0207ECFFC0021F15F091267FFE0013FC902601FFF0EB1FFF01070180010313C049 90C76C7FD91FFC6E6C7E49486F7E49486F7E01FF8348496F7E48496F1380A248496F13C0 A24890C96C13E0A24819F04982003F19F8A3007F19FC49177FA400FF19FEAD007F19FC6D 17FFA3003F19F8A26D5E6C19F0A26E5D6C19E0A26C6D4B13C06C19806E5D6C6D4B13006C 6D4B5A6D6C4B5A6D6C4B5A6D6C4A5B6D01C001075B6D01F0011F5B010101FE90B5C7FC6D 90B65A023F15F8020715C002004AC8FC030713C047467AC454>II82 DI<003FBA12E0A59026FE 000FEB8003D87FE09338003FF049171F90C71607A2007E1803007C1801A300781800A400 F819F8481978A5C81700B3B3A20107B8FCA545437CC24E>I86 DI<903801FFE0011F13FE017F6D7E48 B612E03A03FE007FF84848EB1FFC6D6D7E486C6D7EA26F7FA36F7F6C5A6C5AEA00F090C7 FCA40203B5FC91B6FC1307013F13F19038FFFC01000313E0000F1380381FFE00485A5B12 7F5B12FF5BA35DA26D5B6C6C5B4B13F0D83FFE013EEBFFC03A1FFF80FC7F0007EBFFF86C ECE01FC66CEB8007D90FFCC9FC322F7DAD36>97 DIIIIIII<137C48B4FC4813804813C0A24813E0A56C13C0 A26C13806C1300EA007C90C7FCAAEB7FC0EA7FFFA512037EB3AFB6FCA518467CC520>I< EB7FC0B5FCA512037EB293387FFFE0A593380FE0004C5A4CC7FC167E5EED03F8ED07E04B 5A4B5A037FC8FC15FEECC1FCECC3FE14C7ECDFFF91B57E82A202F97F02E17F02C07FEC80 7F6F7E826F7E816F7F836F7F816F7F83707E163FB60003B512F8A535457DC43B>107 DI<90277F8007FEEC0FFCB590 263FFFC090387FFF8092B5D8F001B512E002816E4880913D87F01FFC0FE03FF8913D8FC0 0FFE1F801FFC0003D99F009026FF3E007F6C019E6D013C130F02BC5D02F86D496D7EA24A 5D4A5DA34A5DB3A7B60081B60003B512FEA5572D7CAC5E>I<90397F8007FEB590383FFF 8092B512E0028114F8913987F03FFC91388F801F000390399F000FFE6C139E14BC02F86D 7E5CA25CA35CB3A7B60083B512FEA5372D7CAC3E>II<90397FC00FF8B590B57E02C314E002CF14F89139DFC03FFC91 39FF001FFE000301FCEB07FF6C496D13804A15C04A6D13E05C7013F0A2EF7FF8A4EF3FFC ACEF7FF8A318F017FFA24C13E06E15C06E5B6E4913806E4913006E495A9139DFC07FFC02 CFB512F002C314C002C091C7FCED1FF092C9FCADB67EA536407DAC3E>II<90387F807FB53881FFE0028313 F0028F13F8ED8FFC91389F1FFE000313BE6C13BC14F8A214F0ED0FFC9138E007F8ED01E0 92C7FCA35CB3A5B612E0A5272D7DAC2E>I<90391FFC038090B51287000314FF120F381F F003383FC00049133F48C7121F127E00FE140FA215077EA27F01E090C7FC13FE387FFFF0 14FF6C14C015F06C14FC6C800003806C15806C7E010F14C0EB003F020313E0140000F014 3FA26C141F150FA27EA26C15C06C141FA26DEB3F8001E0EB7F009038F803FE90B55A00FC 5CD8F03F13E026E007FEC7FC232F7CAD2C>IIIIIII E /Fk 85 123 df11 DIII<001C131C007F137F39FF80FF80A26D13C0A3007F137F001C 131C00001300A40001130101801380A20003130301001300485B00061306000E130E485B 485B485B006013601A197DB92A>34 D<030C1303031E497EA2033E130FA2033C91C7FCA3 037C5BA20378131EA203F8133EA24B133CA20201147CA24B1378A3020314F8A24B5BA202 071301007FB91280BA12C0A3C7271F0007C0C7FCA2021E5CA2023E130FA2023C91C8FCA2 027C5BA20278131EA202F8133EA2BA12C0A36C1880280003E000F8C8FC4A5BA201071301 A202805BA3010F1303A202005BA2491307A2011E5CA2013E130FA2013C91C9FCA3017C5B A20178131EA20130130C3A4A7BB945>I<141FEC7FC0903801F0E0903803C06001071370 90380F803090381F00381518A25BA2133E133F15381530A215705D5D140190381F838092 CAFC1487148E02DC49B51280EB0FF85C4A9039003FF8000107ED0FC06E5D71C7FC6E140E 010F150CD91DFC141C01391518D970FE143801E015302601C07F1470D803805D00076D6C 5BD80F00EBC00148011F5C4890380FE003003E6E48C8FC007E903807F8060203130E00FE 6E5A6E6C5A1400ED7F706C4B13036F5A6F7E6C6C6D6C5B7013066C6C496C130E6DD979FE 5B281FF001F07F133C3C07F80FE03FC0F86CB539800FFFF0C69026FE000313C0D91FF0D9 007FC7FC393E7DBB41>38 D<121C127FEAFF80A213C0A3127F121C1200A412011380A212 0313005A1206120E5A5A5A12600A1979B917>I<146014E0EB01C0EB0380EB0700130E13 1E5B5BA25B485AA2485AA212075B120F90C7FCA25A121EA2123EA35AA65AB2127CA67EA3 121EA2121F7EA27F12077F1203A26C7EA26C7E1378A27F7F130E7FEB0380EB01C0EB00E0 1460135278BD20>I<12C07E12707E7E7E120F6C7E6C7EA26C7E6C7EA21378A2137C133C 133E131EA2131F7FA21480A3EB07C0A6EB03E0B2EB07C0A6EB0F80A31400A25B131EA213 3E133C137C1378A25BA2485A485AA2485A48C7FC120E5A5A5A5A5A13527CBD20>II<15301578B3 A6007FB812F8B912FCA26C17F8C80078C8FCB3A6153036367BAF41>I<121C127FEAFF80 A213C0A3127F121C1200A412011380A2120313005A1206120E5A5A5A12600A19798817> II<121C127FEAFF80A5EA7F00121C0909798817>I<150C151E15 3EA2153C157CA2157815F8A215F01401A215E01403A215C01407A21580140FA215005CA2 141E143EA2143C147CA2147814F8A25C1301A25C1303A2495AA25C130FA291C7FC5BA213 1E133EA2133C137CA2137813F8A25B1201A25B1203A25B1207A25B120FA290C8FC5AA212 1E123EA2123C127CA2127812F8A25A12601F537BBD2A>IIIII<1538A2157815F8A2140114031407A2140F141F 141B14331473146314C313011483EB030313071306130C131C131813301370136013C012 01EA038013005A120E120C5A123812305A12E0B712F8A3C73803F800AB4A7E0103B512F8 A325397EB82A>I<0006140CD80780133C9038F003F890B5FC5D5D158092C7FC14FC3806 7FE090C9FCABEB07F8EB3FFE9038780F803907E007E090388003F0496C7E12066E7EC87E A28181A21680A4123E127F487EA490C71300485C12E000605C12700030495A00385C6C13 03001E495A6C6C485A3907E03F800001B5C7FC38007FFCEB1FE0213A7CB72A>II<12301238123E003FB612E0A316C05A168016000070C71206 0060140E5D151800E01438485C5D5DC712014A5A92C7FC5C140E140C141C5CA25CA214F0 495AA21303A25C1307A2130FA3495AA3133FA5137FA96DC8FC131E233B7BB82A>III<121C127FEAFF80A5EA7F00121CC7FC B2121C127FEAFF80A5EA7F00121C092479A317>I<121C127FEAFF80A5EA7F00121CC7FC B2121C127F5A1380A4127F121D1201A412031300A25A1206A2120E5A121812385A126009 3479A317>I<007FB812F8B912FCA3CCFCAEB912FCA36C17F836167B9F41>61 D63 DI<1538A3157CA315FEA34A7EA34A6C7EA202077FEC063FA2020E7FEC0C1F A2021C7FEC180FA202387FEC3007A202707FEC6003A202C07F1501A2D901807F81A249C7 7F167FA20106810107B6FCA24981010CC7121FA2496E7EA3496E7EA3496E7EA213E0707E 1201486C81D80FFC02071380B56C90B512FEA3373C7DBB3E>II<91 3A01FF800180020FEBE003027F13F8903A01FF807E07903A03FC000F0FD90FF0EB039F49 48EB01DFD93F80EB00FF49C8127F01FE153F12014848151F4848150FA248481507A2485A 1703123F5B007F1601A35B00FF93C7FCAD127F6DED0180A3123F7F001F160318006C7E5F 6C7E17066C6C150E6C6C5D00001618017F15386D6C5CD91FE05C6D6CEB03C0D903FCEB0F 80902701FF803FC7FC9039007FFFFC020F13F002011380313D7BBA3C>IIIII II<013FB512E0A3903900 1FFC00EC07F8B3B3A3123FEA7F80EAFFC0A44A5A1380D87F005B0070131F6C5C6C495A6C 49C7FC380781FC3801FFF038007F80233B7DB82B>IIIIIIIIII<003FB812E0A3D9C003EB001F273E0001FE130348EE01F00078160000701770 A300601730A400E01738481718A4C71600B3B0913807FF80011FB612E0A335397DB83C> IIII<007FB590383FFFFCA3C601F801071380D97FE0D903FCC7FC013FEC01 F06D6C5C5F6D6C5C6D6C13034CC8FC6D6C1306160E6D6C5B6DEB8018163891387FC0306E 6C5A16E06E6C5A91380FF18015FB6EB4C9FC5D14036E7EA26E7F6F7EA24B7E15DF913801 9FF09138038FF8150F91380607FC91380E03FE140C4A6C7EEC38000230804A6D7E14E04A 6D7E49486D7E130391C76C7E01066E7E130E010C6E7E011C1401013C8101FE822607FF80 010713E0B500E0013FEBFF80A339397EB83E>II91 D<3901800180000313033907000700000E130E485B001813180038133800301330007013 7000601360A200E013E0485BA400CE13CE39FF80FF806D13C0A3007F137FA2393F803F80 390E000E001A1974B92A>II97 DIIII<147E903803FF8090380FC1E0EB1F8790383F0F F0137EA213FCA23901F803C091C7FCADB512FCA3D801F8C7FCB3AB487E387FFFF8A31C3B 7FBA19>IIIIIII<2703F00FF0EB1FE000FFD93FFCEB7FF8913AF03F01E07E903B F1C01F83803F3D0FF3800FC7001F802603F70013CE01FE14DC49D907F8EB0FC0A2495CA3 495CB3A3486C496CEB1FE0B500C1B50083B5FCA340257EA445>I<3903F00FF000FFEB3F FCECF03F9039F1C01F803A0FF3800FC03803F70013FE496D7EA25BA35BB3A3486C497EB5 00C1B51280A329257EA42E>II<3903F01FE000FFEB7FF89038F1E07E 9039F3801F803A07F7000FC0D803FEEB07E049EB03F04914F849130116FC150016FEA316 7FAA16FEA3ED01FCA26DEB03F816F06D13076DEB0FE001F614C09039F7803F009038F1E0 7E9038F0FFF8EC1FC091C8FCAB487EB512C0A328357EA42E>II<3807E01F00FFEB7F C09038E1E3E09038E387F0380FE707EA03E613EE9038EC03E09038FC0080491300A45BB3 A2487EB512F0A31C257EA421>II<1318A51338A31378A313F8120112031207001FB5FCB6FCA2D801 F8C7FCB215C0A93800FC011580EB7C03017E13006D5AEB0FFEEB01F81A347FB220>IIIIII<003FB512FCA2EB8003D83E0013F8003CEB07F00038EB0FE012300070EB1FC0EC3F80 0060137F150014FE495AA2C6485A495AA2495A495A495AA290387F000613FEA2485A485A 0007140E5B4848130C4848131CA24848133C48C7127C48EB03FC90B5FCA21F247EA325> I E end %%EndProlog %%BeginSetup %%Feature: *Resolution 600dpi TeXDict begin %%EndSetup %%Page: 1 1 1 0 bop 0 568 a Fk(IPSEC)27 b(W)-7 b(orking)26 b(Group)1060 b(Douglas)26 b(Maughan,)h(Mark)g(Sc)n(hertler)0 667 y(INTERNET-DRAFT) 1352 b(Mark)27 b(Sc)n(hneider,)g(Je\013)h(T)-7 b(urner)0 767 y(draft-ietf-ipsec-isakmp-09.txt,)26 b(.ps)1388 b(Marc)n(h)27 b(10,)g(1998)152 1046 y Fj(In)m(ternet)37 b(Securit)m(y)f(Asso)s (ciation)g(and)i(Key)g(Managemen)m(t)g(Proto)s(col)e(\(ISAKMP\))1781 1486 y Fi(Abstract)323 1683 y Fh(This)28 b(memo)e(describ)r(es)i(a)g (proto)r(col)g(utilizing)h(securit)n(y)e(concepts)h(necessary)g(for)g (establishing)h(Securit)n(y)d(Asso-)208 1774 y(ciations)h(\(SA\))f(and) g(cryptographic)h(k)n(eys)f(in)g(an)h(In)n(ternet)e(en)n(vironmen)n(t.) 36 b(A)26 b(Securit)n(y)f(Asso)r(ciation)k(proto)r(col)f(that)208 1865 y(negotiates,)e(establishes,)h(mo)r(di\014es)e(and)f(deletes)i (Securit)n(y)e(Asso)r(ciations)j(and)e(their)g(attributes)g(is)g (required)g(for)g(an)208 1957 y(ev)n(olving)h(In)n(ternet,)g(where)h (there)f(will)i(b)r(e)f(n)n(umerous)e(securit)n(y)h(mec)n(hanisms)f (and)h(sev)n(eral)i(options)f(for)g(eac)n(h)g(secu-)208 2048 y(rit)n(y)d(mec)n(hanism.)32 b(The)25 b(k)n(ey)e(managemen)n(t)g (proto)r(col)j(m)n(ust)d(b)r(e)h(robust)g(in)g(order)h(to)g(handle)f (public)g(k)n(ey)f(generation)208 2139 y(for)29 b(the)f(In)n(ternet)f (comm)n(unit)n(y)f(at)i(large)i(and)e(priv)l(ate)g(k)n(ey)f(requiremen) n(ts)h(for)h(those)f(priv)l(ate)h(net)n(w)n(orks)f(with)h(that)208 2231 y(requiremen)n(t.)323 2322 y(The)c(In)n(ternet)e(Securit)n(y)h (Asso)r(ciation)j(and)d(Key)g(Managemen)n(t)h(Proto)r(col)i(\(ISAKMP\)) c(de\014nes)i(the)f(pro)r(cedures)208 2413 y(for)30 b(authen)n (ticating)f(a)h(comm)n(unicating)e(p)r(eer,)j(creation)f(and)f (managemen)n(t)f(of)i(Securit)n(y)f(Asso)r(ciations,)j(k)n(ey)d(gen-) 208 2505 y(eration)j(tec)n(hniques,)h(and)e(threat)h(mitigation)g (\(e.g.)53 b(denial)32 b(of)h(service)f(and)f(repla)n(y)h(attac)n (ks\).)53 b(All)32 b(of)g(these)g(are)208 2596 y(necessary)22 b(to)f(establish)i(and)e(main)n(tain)g(secure)h(comm)n(unications)f (\(via)g(IP)h(Securit)n(y)f(Service)g(or)h(an)n(y)f(other)h(securit)n (y)208 2687 y(proto)r(col\))k(in)g(an)g(In)n(ternet)e(en)n(vironmen)n (t.)1584 2969 y Fk(Status)k(of)f(this)h(memo)0 3252 y(This)d(do)r (cumen)n(t)h(is)f(b)r(eing)g(submitted)h(to)f(the)g(IETF)g(In)n(ternet) g(Proto)r(col)f(Securit)n(y)g(\(IPSEC\))h(W)-7 b(orking)24 b(Group)h(for)g(con-)0 3351 y(sideration)f(as)g(a)g(metho)r(d)h(for)g (the)g(establishmen)n(t)g(and)f(managemen)n(t)g(of)h(securit)n(y)f (asso)r(ciations)e(and)j(their)g(appropriate)0 3451 y(securit)n(y)i (attributes.)37 b(Additionally)-7 b(,)28 b(this)g(do)r(cumen)n(t)g (prop)r(oses)e(a)h(metho)r(d)h(for)f(k)n(ey)g(managemen)n(t)g(to)g (supp)r(ort)h(IPSEC)0 3551 y(and)j(IPv6.)46 b(It)31 b(is)g(in)n(tended) g(that)h(a)e(future)i(v)n(ersion)d(of)i(this)g(draft)g(b)r(e)h (submitted)g(to)f(the)g(IESG)g(for)f(publication)h(as)f(a)0 3650 y(Draft)k(Standard)e(RF)n(C.)i(Commen)n(ts)f(are)f(solicited)i (and)f(should)g(b)r(e)h(addressed)e(to)h(the)h(authors)e(and/or)g(the)i (IPSEC)0 3750 y(w)n(orking)26 b(group)g(mailing)i(list)f(at)h Fg(ipsec@tis.com)p Fk(.)0 3949 y(This)35 b(do)r(cumen)n(t)h(is)g(an)f (In)n(ternet)g(Draft.)61 b(In)n(ternet)36 b(Drafts)f(are)g(w)n(orking)e (do)r(cumen)n(ts)j(of)f(the)h(In)n(ternet)g(Engineering)0 4049 y(T)-7 b(ask)25 b(F)-7 b(orce)26 b(\(IETF\),)g(its)g(Areas,)g(and) g(its)g(W)-7 b(orking)25 b(Groups.)35 b(Note)27 b(that)f(other)f (groups)g(ma)n(y)g(also)g(distribute)i(w)n(orking)0 4148 y(do)r(cumen)n(ts)h(as)f(In)n(ternet)g(Drafts.)0 4348 y(In)n(ternet)j(Drafts)g(are)f(draft)i(do)r(cumen)n(ts)f(v)-5 b(alid)30 b(for)g(a)f(maxim)n(um)i(of)f(six)g(mon)n(ths.)44 b(In)n(ternet)30 b(Drafts)g(ma)n(y)g(b)r(e)g(up)r(dated,)0 4447 y(replaced,)39 b(or)e(obsoleted)g(b)n(y)g(other)g(do)r(cumen)n(ts) h(at)f(an)n(y)g(time.)68 b(It)38 b(is)f(not)h(appropriate)e(to)h(use)h (In)n(ternet)f(Drafts)h(as)0 4547 y(reference)27 b(material)f(or)h(to)h (cite)f(them)i(other)e(than)g(as)g(\\w)n(orking)f(draft")h(or)f(\\w)n (ork)g(in)i(progress.")0 4746 y(T)-7 b(o)22 b(learn)f(the)i(curren)n(t) e(status)h(of)g(an)n(y)f(In)n(ternet-Draft,)i(please)e(c)n(hec)n(k)h (the)g(\\1id-abstracts.txt")e(listing)i(con)n(tained)f(in)i(the)0 4846 y(In)n(ternet-)29 b(Drafts)g(Shado)n(w)g(Directories)f(on)h(ds.in) n(ternic.net)h(\(US)g(East)f(Coast\),)g(nic.nordu.net)g(\(Europ)r(e\),) h(ftp.isi.edu)0 4945 y(\(US)e(W)-7 b(est)28 b(Coast\),)f(or)g(m)n (unnari.oz.au)f(\(P)n(aci\014c)h(Rim\).)0 5145 y(Distribution)h(of)g (this)f(do)r(cumen)n(t)h(is)g(unlimited.)p eop %%Page: 2 2 2 1 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(Con)l(ten)l(ts)0 573 y Fe(1)77 b(In)m(tro)s(duction)3201 b(5)125 672 y Fk(1.1)83 b(Requiremen)n(ts)28 b(T)-7 b(erminology)19 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)134 b Fk(5)125 772 y(1.2)83 b(The)28 b(Need)g(for)f(Negotiation)66 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(6)125 872 y(1.3)83 b(What)28 b(can)g(b)r(e)g(Negotiated?)64 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)134 b Fk(6)125 971 y(1.4)83 b(Securit)n(y)28 b(Asso)r(ciations)e(and)h(Managemen)n(t)21 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(6)315 1071 y(1.4.1)94 b(Securit)n(y)27 b(Asso)r(ciations)g(and)g (Registration)34 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(7)315 1171 y(1.4.2)94 b(ISAKMP)27 b(Requiremen)n(ts)66 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)134 b Fk(7)125 1270 y(1.5)83 b(Authen)n(tication)66 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(7)315 1370 y(1.5.1)94 b(Certi\014cate)27 b(Authorities)45 b Fd(:)d(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)134 b Fk(8)315 1469 y(1.5.2)94 b(En)n(tit)n(y)27 b(Naming)61 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(8)315 1569 y(1.5.3)94 b(ISAKMP)27 b(Requiremen)n(ts)66 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(8)125 1669 y(1.6)83 b(Public)28 b(Key)f(Cryptograph)n(y)56 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)134 b Fk(9)315 1768 y(1.6.1)94 b(Key)27 b(Exc)n(hange)f(Prop)r(erties)66 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)134 b Fk(9)315 1868 y(1.6.2)94 b(ISAKMP)27 b(Requiremen)n(ts)66 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(10)125 1968 y(1.7)83 b(ISAKMP)28 b(Protection)58 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(10)315 2067 y(1.7.1)h(An)n (ti-Clogging)26 b(\(Denial)i(of)g(Service\))35 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(10)315 2167 y(1.7.2)h(Connection)27 b(Hijac)n(king)80 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) 93 b Fk(11)315 2267 y(1.7.3)h(Man-in-the-Middle)27 b(A)n(ttac)n(ks)66 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(11)125 2366 y(1.8)83 b(Multicast)28 b(Comm)n(unications)82 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)93 b Fk(11)0 2549 y Fe(2)77 b(T)-8 b(erminology)29 b(and)j(Concepts)2560 b(12)125 2648 y Fk(2.1)83 b(ISAKMP)28 b(T)-7 b(erminology)50 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(12)125 2748 y(2.2)83 b(ISAKMP)28 b(Placemen)n(t)61 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(13)125 2848 y(2.3)83 b(Negotiation)27 b(Phases)41 b Fd(:)g(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(13)125 2947 y(2.4)83 b(Iden)n(tifying)28 b(Securit)n(y)f(Asso)r (ciations)62 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)93 b Fk(15)125 3047 y(2.5)83 b(Miscellaneous)47 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(16)315 3147 y(2.5.1)h(T)-7 b(ransp)r(ort)27 b(Proto)r(col)32 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)93 b Fk(16)315 3246 y(2.5.2)h(RESER)-9 b(VED)27 b(Fields)33 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(16)315 3346 y(2.5.3)h(An)n(ti-Clogging)26 b(T)-7 b(ok)n(en)27 b(\(\\Co)r(okie"\))f(Creation)50 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(17)0 3528 y Fe(3)77 b(ISAKMP)32 b(P)m(a)m(yloads)2889 b(17)125 3628 y Fk(3.1)83 b(ISAKMP)28 b(Header)f(F)-7 b(ormat)84 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(17)125 3728 y(3.2)83 b(Generic)28 b(P)n(a)n(yload)d(Header)53 b Fd(:)41 b(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(20)125 3827 y(3.3)83 b(Data)28 b(A)n(ttributes)h Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(20)125 3927 y(3.4)83 b(Securit)n(y)28 b(Asso)r(ciation)e(P)n(a)n(yload)67 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)93 b Fk(21)125 4027 y(3.5)83 b(Prop)r(osal)26 b(P)n(a)n(yload)36 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(22)125 4126 y(3.6)83 b(T)-7 b(ransform)27 b(P)n(a)n(yload)44 b Fd(:)d(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(23)125 4226 y(3.7)83 b(Key)27 b(Exc)n(hange)f(P)n(a)n(yload)i Fd(:)42 b(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(24)125 4325 y(3.8)83 b(Iden)n(ti\014cation)28 b(P)n(a)n(yload)68 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(25)125 4425 y(3.9)83 b(Certi\014cate)28 b(P)n(a)n(yload)40 b Fd(:)h(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(26)125 4525 y(3.10)41 b(Certi\014cate)28 b(Request)f(P)n(a)n (yload)46 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(27)125 4624 y(3.11)41 b(Hash)28 b(P)n(a)n(yload)42 b Fd(:)g(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)93 b Fk(28)125 4724 y(3.12)41 b(Signature)27 b(P)n(a)n(yload)73 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(29)125 4824 y(3.13)41 b(Nonce)28 b(P)n(a)n(yload)66 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)93 b Fk(30)125 4923 y(3.14)41 b(Noti\014cation)28 b(P)n(a)n(yload)56 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(31)315 5023 y(3.14.1)52 b(Notify)28 b(Message)e(T)n(yp)r(es)58 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)93 b Fk(32)125 5122 y(3.15)41 b(Delete)29 b(P)n(a)n(yload)60 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(33)125 5222 y(3.16)41 b(V)-7 b(endor)28 b(ID)g(P)n(a)n(yload)39 b Fd(:)i(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(35)0 5405 y Fe(4)77 b(ISAKMP)32 b(Exc)m(hanges)2822 b(36)0 5656 y Fk(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(2])p eop %%Page: 3 3 3 2 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y(4.1)83 b(ISAKMP)28 b(Exc)n(hange)d(T)n(yp)r(es)39 b Fd(:)j(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(36)315 490 y(4.1.1)h(Notation)23 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(37)125 589 y(4.2)83 b(Securit)n(y)28 b(Asso)r(ciation)e (Establishmen)n(t)36 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)93 b Fk(37)315 689 y(4.2.1)h(Securit)n(y)27 b(Asso)r(ciation)g(Establishmen)n(t)g(Examples)38 b Fd(:)j(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)93 b Fk(38)125 789 y(4.3)83 b(Securit)n(y)28 b(Asso)r(ciation)e(Mo) r(di\014cation)31 b Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)93 b Fk(41)125 888 y(4.4)83 b(Base)27 b(Exc)n(hange)63 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(41)125 988 y(4.5)83 b(Iden)n(tit)n(y)28 b(Protection)e(Exc)n (hange)56 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)93 b Fk(42)125 1088 y(4.6)83 b(Authen)n(tication)28 b(Only)g(Exc)n(hange)64 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(43)125 1187 y(4.7)83 b(Aggressiv)n(e)26 b(Exc)n(hange)44 b Fd(:)e(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(44)125 1287 y(4.8)83 b(Informational)27 b(Exc)n(hange)62 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)93 b Fk(45)0 1469 y Fe(5)77 b(ISAKMP)32 b(P)m(a)m(yload)h(Pro)s(cessing)2449 b(45)125 1569 y Fk(5.1)83 b(General)27 b(Message)f(Pro)r(cessing)41 b Fd(:)g(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)93 b Fk(46)125 1669 y(5.2)83 b(ISAKMP)28 b(Header)f(Pro)r (cessing)i Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)93 b Fk(46)125 1768 y(5.3)83 b(Generic)28 b(P)n(a)n(yload)d(Header)i(Pro)r(cessing)h Fd(:)42 b(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(47)125 1868 y(5.4)83 b(Securit)n(y)28 b(Asso)r(ciation)e(P)n(a)n(yload)f(Pro)r (cessing)45 b Fd(:)c(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(48)125 1968 y(5.5)83 b(Prop)r(osal)26 b(P)n(a)n(yload)f(Pro)r (cessing)78 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)93 b Fk(49)125 2067 y(5.6)83 b(T)-7 b(ransform)27 b(P)n(a)n(yload)e(Pro)r(cessing)c Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) 93 b Fk(50)125 2167 y(5.7)83 b(Key)27 b(Exc)n(hange)f(P)n(a)n(yload)f (Pro)r(cessing)70 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)93 b Fk(50)125 2267 y(5.8)83 b(Iden)n(ti\014cation)28 b(P)n(a)n(yload)d(Pro)r(cessing)45 b Fd(:)d(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(51)125 2366 y(5.9)83 b(Certi\014cate)28 b(P)n(a)n(yload)d(Pro)r(cessing)82 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)93 b Fk(51)125 2466 y(5.10)41 b(Certi\014cate)28 b(Request)f(P)n(a)n(yload)e(Pro)r(cessing)e Fd(:)42 b(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(52)125 2565 y(5.11)41 b(Hash)28 b(P)n(a)n(yload)d(Pro)r(cessing)20 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)93 b Fk(53)125 2665 y(5.12)41 b(Signature)27 b(P)n(a)n(yload)e(Pro)r(cessing)50 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(54)125 2765 y(5.13)41 b(Nonce)28 b(P)n(a)n(yload)d(Pro)r(cessing)43 b Fd(:)f(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)93 b Fk(54)125 2864 y(5.14)41 b(Noti\014cation)28 b(P)n(a)n(yload)d(Pro)r(cessing)34 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(55)125 2964 y(5.15)41 b(Delete)29 b(P)n(a)n(yload)c(Pro)r(cessing)37 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)93 b Fk(56)0 3147 y Fe(6)77 b(Conclusions)3184 b(58)0 3329 y(A)53 b(ISAKMP)32 b(Securit)m(y)g(Asso)s(ciation)f(A)m (ttributes)1938 b(59)125 3429 y Fk(A.1)63 b(Bac)n(kground/Rationale)43 b Fd(:)f(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)93 b Fk(59)125 3528 y(A.2)63 b(In)n(ternet)28 b(IP)f(Securit)n(y)g(DOI)h(Assigned)f(V)-7 b(alue)84 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(59)125 3628 y(A.3)63 b(Supp)r(orted)28 b(Securit)n(y)f(Proto)r (cols)56 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)93 b Fk(59)125 3728 y(A.4)63 b(ISAKMP)28 b(Iden)n(ti\014cation)f(T)n(yp)r(e)h(V)-7 b(alues)63 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(59)315 3827 y(A.4.1)74 b(ID)p 679 3827 25 4 v 30 w(IPV4)p 900 3827 V 30 w(ADDR)g Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(60)315 3927 y(A.4.2)74 b(ID)p 679 3927 V 30 w(IPV4)p 900 3927 V 30 w(ADDR)p 1179 3927 V 31 w(SUBNET)84 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(60)315 4027 y(A.4.3)74 b(ID)p 679 4027 V 30 w(IPV6)p 900 4027 V 30 w(ADDR)g Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(60)315 4126 y(A.4.4)74 b(ID)p 679 4126 V 30 w(IPV6)p 900 4126 V 30 w(ADDR)p 1179 4126 V 31 w(SUBNET)84 b Fd(:)42 b(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(60)0 4309 y Fe(B)57 b(De\014ning)31 b(a)h(new)g(Domain)e(of)i(In)m(terpretation) 1965 b(61)125 4408 y Fk(B.1)66 b(Situation)84 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(61)125 4508 y(B.2)66 b(Securit)n(y)28 b(P)n(olicies)77 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(61)125 4608 y(B.3)66 b(Naming)28 b(Sc)n(hemes)59 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(62)125 4707 y(B.4)66 b(Syn)n(tax)28 b(for)f(Sp)r(ecifying)h (Securit)n(y)f(Services)j Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)93 b Fk(62)125 4807 y(B.5)66 b(P)n(a)n(yload)26 b(Sp)r(eci\014cation)g Fd(:)42 b(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(62)125 4907 y(B.6)66 b(De\014ning)28 b(new)g(Exc)n(hange)e(T)n(yp) r(es)j Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)93 b Fk(62)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(3])p eop %%Page: 4 4 4 3 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(List)46 b(of)g(Figures)125 572 y Fk(1)148 b(ISAKMP)28 b(Relationships)82 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)93 b Fk(14)125 672 y(2)148 b(ISAKMP)28 b(Header)f(F)-7 b(ormat)84 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(18)125 771 y(3)148 b(Generic)28 b(P)n(a)n(yload)d(Header)53 b Fd(:)41 b(:)h(:)f(:)h(:)f(:) h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h (:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(20)125 871 y(4)148 b(Data)28 b(A)n(ttributes)h Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(21)125 971 y(5)148 b(Securit)n(y)28 b(Asso)r(ciation)e(P)n(a)n(yload)67 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)93 b Fk(22)125 1070 y(6)148 b(Prop)r(osal)26 b(P)n(a)n(yload)f(F)-7 b(ormat)69 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(23)125 1170 y(7)148 b(T)-7 b(ransform)27 b(P)n(a)n(yload)e(F)-7 b(ormat)77 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(24)125 1269 y(8)148 b(Key)27 b(Exc)n(hange)f(P)n(a)n(yload)f(F)-7 b(ormat)61 b Fd(:)41 b(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(25)125 1369 y(9)148 b(Iden)n(ti\014cation)28 b(P)n(a)n(yload)d(F) -7 b(ormat)36 b Fd(:)42 b(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(26)125 1469 y(10)106 b(Certi\014cate)28 b(P)n(a)n(yload)d(F)-7 b(ormat)73 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:) f(:)h(:)f(:)93 b Fk(27)125 1568 y(11)106 b(Certi\014cate)28 b(Request)f(P)n(a)n(yload)e(F)-7 b(ormat)79 b Fd(:)41 b(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h (:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(28)125 1668 y(12)106 b(Hash)28 b(P)n(a)n(yload)d(F)-7 b(ormat)75 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f (:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:) h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(29)125 1768 y(13)106 b(Signature)27 b(P)n(a)n(yload)e(F)-7 b(ormat)41 b Fd(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:) h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g (:)f(:)h(:)f(:)93 b Fk(29)125 1867 y(14)106 b(Nonce)28 b(P)n(a)n(yload)d(F)-7 b(ormat)34 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h (:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:) f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(30)125 1967 y(15)106 b(Noti\014cation)28 b(P)n(a)n(yload)d(F)-7 b(ormat)25 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(31)125 2066 y(16)106 b(Delete)29 b(P)n(a)n(yload)c(F)-7 b(ormat)28 b Fd(:)42 b(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f (:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:) g(:)f(:)h(:)f(:)93 b Fk(34)125 2166 y(17)106 b(V)-7 b(endor)28 b(ID)g(P)n(a)n(yload)d(F)-7 b(ormat)72 b Fd(:)41 b(:)h(:)f(:)h(:)g(:)f (:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)h(:) f(:)h(:)g(:)f(:)h(:)f(:)h(:)f(:)h(:)g(:)f(:)h(:)f(:)93 b Fk(36)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(4])p eop %%Page: 5 5 5 4 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(1)137 b(In)l(tro)t(duction)0 672 y Fk(This)44 b(do)r(cumen)n(t)h(describ)r(es)f(an)g(In)n(ternet)h (Securit)n(y)f(Asso)r(ciation)f(and)i(Key)f(Managemen)n(t)f(Proto)r (col)g(\(ISAKMP\).)0 771 y(ISAKMP)32 b(com)n(bines)g(the)h(securit)n(y) e(concepts)h(of)g(authen)n(tication,)i(k)n(ey)d(managemen)n(t,)i(and)f (securit)n(y)g(asso)r(ciations)e(to)0 871 y(establish)d(the)h(required) f(securit)n(y)g(for)g(go)n(v)n(ernmen)n(t,)e(commercial,)i(and)g(priv) -5 b(ate)28 b(comm)n(unications)e(on)h(the)h(In)n(ternet.)0 1070 y(The)d(In)n(ternet)g(Securit)n(y)f(Asso)r(ciation)g(and)h(Key)f (Managemen)n(t)g(Proto)r(col)f(\(ISAKMP\))i(de\014nes)g(pro)r(cedures)e (and)i(pac)n(k)n(et)0 1170 y(formats)j(to)h(establish,)f(negotiate,)h (mo)r(dify)g(and)g(delete)g(Securit)n(y)f(Asso)r(ciations)f(\(SA\).)j (SAs)f(con)n(tain)f(all)h(the)g(informa-)0 1269 y(tion)c(required)g (for)g(execution)g(of)g(v)-5 b(arious)24 b(net)n(w)n(ork)g(securit)n(y) g(services,)h(suc)n(h)g(as)g(the)g(IP)g(la)n(y)n(er)f(services)g(\(suc) n(h)h(as)g(header)0 1369 y(authen)n(tication)k(and)h(pa)n(yload)e (encapsulation\),)i(transp)r(ort)e(or)h(application)g(la)n(y)n(er)f (services,)h(or)g(self-protection)g(of)g(ne-)0 1469 y(gotiation)g (tra\016c.)44 b(ISAKMP)30 b(de\014nes)g(pa)n(yloads)e(for)i(exc)n (hanging)e(k)n(ey)i(generation)f(and)h(authen)n(tication)f(data.)44 b(These)0 1568 y(formats)30 b(pro)n(vide)g(a)h(consisten)n(t)f(framew)n (ork)f(for)i(transferring)e(k)n(ey)h(and)h(authen)n(tication)g(data)f (whic)n(h)h(is)g(indep)r(enden)n(t)0 1668 y(of)d(the)g(k)n(ey)e (generation)h(tec)n(hnique,)g(encryption)g(algorithm)g(and)g(authen)n (tication)g(mec)n(hanism.)0 1867 y(ISAKMP)19 b(is)g(distinct)h(from)e (k)n(ey)h(exc)n(hange)f(proto)r(cols)f(in)j(order)e(to)h(cleanly)f (separate)g(the)h(details)g(of)g(securit)n(y)g(asso)r(ciation)0 1967 y(managemen)n(t)33 b(\(and)h(k)n(ey)f(managemen)n(t\))g(from)h (the)g(details)g(of)g(k)n(ey)f(exc)n(hange.)54 b(There)34 b(ma)n(y)f(b)r(e)h(man)n(y)g(di\013eren)n(t)g(k)n(ey)0 2066 y(exc)n(hange)29 b(proto)r(cols,)i(eac)n(h)f(with)h(di\013eren)n (t)g(securit)n(y)f(prop)r(erties.)46 b(Ho)n(w)n(ev)n(er,)30 b(a)h(common)f(framew)n(ork)f(is)i(required)f(for)0 2166 y(agreeing)c(to)i(the)h(format)e(of)i(SA)f(attributes,)g(and)g(for)g (negotiating,)f(mo)r(difying,)i(and)f(deleting)g(SAs.)39 b(ISAKMP)28 b(serv)n(es)0 2266 y(as)f(this)h(common)f(framew)n(ork.)0 2465 y(Separating)22 b(the)h(functionalit)n(y)g(in)n(to)f(three)h (parts)f(adds)h(complexit)n(y)f(to)h(the)g(securit)n(y)f(analysis)f(of) i(a)g(complete)f(ISAKMP)0 2565 y(implemen)n(tation.)78 b(Ho)n(w)n(ev)n(er,)43 b(the)f(separation)e(is)h(critical)g(for)g(in)n (terop)r(erabilit)n(y)f(b)r(et)n(w)n(een)h(systems)g(with)h (di\013ering)0 2664 y(securit)n(y)27 b(requiremen)n(ts,)f(and)i(should) f(also)g(simplify)h(the)g(analysis)e(of)h(further)h(ev)n(olution)f(of)g (a)g(ISAKMP)h(serv)n(er.)0 2863 y(ISAKMP)33 b(is)g(in)n(tended)g(to)g (supp)r(ort)g(the)h(negotiation)e(of)h(SAs)g(for)g(securit)n(y)f(proto) r(cols)g(at)h(all)g(la)n(y)n(ers)e(of)i(the)g(net)n(w)n(ork)0 2963 y(stac)n(k)28 b(\(e.g.,)g(IPSEC,)g(TLS,)h(TLSP)-7 b(,)28 b(OSPF,)g(etc.\).)41 b(By)28 b(cen)n(tralizing)f(the)i (managemen)n(t)f(of)g(the)h(securit)n(y)f(asso)r(ciations,)0 3063 y(ISAKMP)i(reduces)g(the)g(amoun)n(t)g(of)h(duplicated)f (functionalit)n(y)h(within)g(eac)n(h)f(securit)n(y)f(proto)r(col.)44 b(ISAKMP)30 b(can)g(also)0 3162 y(reduce)d(connection)g(setup)h(time,)g (b)n(y)g(negotiating)e(a)h(whole)h(stac)n(k)e(of)i(services)e(at)h (once.)0 3362 y(The)c(remainder)f(of)h(section)g(1)f(establishes)h(the) g(motiv)-5 b(ation)23 b(for)g(securit)n(y)f(negotiation)g(and)h (outlines)g(the)g(ma)5 b(jor)22 b(comp)r(o-)0 3461 y(nen)n(ts)30 b(of)h(ISAKMP)-7 b(,)30 b(i.e.)45 b(Securit)n(y)30 b(Asso)r(ciations)f (and)h(Managemen)n(t,)g(Authen)n(tication,)h(Public)g(Key)e (Cryptograph)n(y)-7 b(,)0 3561 y(and)23 b(Miscellaneous)g(items.)36 b(Section)23 b(2)h(presen)n(ts)e(the)i(terminology)f(and)g(concepts)g (asso)r(ciated)g(with)h(ISAKMP)-7 b(.)23 b(Section)0 3660 y(3)31 b(describ)r(es)f(the)i(di\013eren)n(t)f(ISAKMP)f(pa)n (yload)g(formats.)46 b(Section)31 b(4)g(describ)r(es)f(ho)n(w)h(the)g (pa)n(yloads)e(of)i(ISAKMP)g(are)0 3760 y(comp)r(osed)k(together)f(as)h (exc)n(hange)f(t)n(yp)r(es)h(to)g(establish)g(securit)n(y)f(asso)r (ciations)g(and)h(p)r(erform)g(k)n(ey)f(exc)n(hanges)g(in)h(an)0 3860 y(authen)n(ticated)e(manner.)51 b(Additionally)-7 b(,)34 b(securit)n(y)e(asso)r(ciation)f(mo)r(di\014cation,)j(deletion,) g(and)e(error)f(noti\014cation)h(are)0 3959 y(discussed.)59 b(Section)35 b(5)g(describ)r(es)g(the)g(pro)r(cessing)f(of)h(eac)n(h)g (pa)n(yload)e(within)j(the)g(con)n(text)f(of)g(ISAKMP)g(exc)n(hanges,)0 4059 y(including)30 b(error)d(handling)i(and)h(asso)r(ciated)e (actions.)41 b(The)30 b(app)r(endices)f(pro)n(vide)f(the)i(attribute)g (v)-5 b(alues)29 b(necessary)f(for)0 4159 y(ISAKMP)f(and)h(requiremen)n (t)e(for)h(de\014ning)h(a)f(new)h(Domain)f(of)h(In)n(terpretation)e (\(DOI\))j(within)f(ISAKMP)-7 b(.)0 4491 y Fj(1.1)112 b(Requiremen)m(ts)36 b(T)-9 b(erminology)0 4743 y Fk(The)25 b(k)n(eyw)n(ords)e(MUST,)j(MUST)g(NOT,)f(REQUIRED,)g(SHALL,)g(SHALL)h (NOT,)f(SHOULD,)h(SHOULD)g(NOT,)f(REC-)0 4843 y(OMMENDED,)33 b(MA)-7 b(Y,)34 b(and)f(OPTIONAL,)g(when)g(they)h(app)r(ear)e(in)i (this)f(do)r(cumen)n(t,)i(are)d(to)h(b)r(e)h(in)n(terpreted)f(as)f(de-) 0 4943 y(scrib)r(ed)27 b(in)h([RF)n(C-2119)n(].)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(5])p eop %%Page: 6 6 6 5 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(1.2)112 b(The)38 b(Need)g(for)f(Negotiation)0 643 y Fk(ISAKMP)31 b(extends)h(the)h (assertion)d(in)i([DO)n(W92)o(])g(that)g(authen)n(tication)g(and)f(k)n (ey)h(exc)n(hanges)e(m)n(ust)i(b)r(e)g(com)n(bined)g(for)0 743 y(b)r(etter)26 b(securit)n(y)g(to)g(include)g(securit)n(y)f(asso)r (ciation)g(exc)n(hanges.)34 b(The)26 b(securit)n(y)g(services)e (required)i(for)f(comm)n(unications)0 842 y(dep)r(ends)32 b(on)f(the)g(individual)h(net)n(w)n(ork)e(con\014gurations)f(and)i(en)n (vironmen)n(ts.)47 b(Organizations)29 b(are)h(setting)i(up)f(Virtual)0 942 y(Priv)-5 b(ate)20 b(Net)n(w)n(orks)f(\(VPN\),)j(also)e(kno)n(wn)g (as)g(In)n(tranets,)i(that)f(will)g(require)f(one)g(set)h(of)g(securit) n(y)f(functions)h(for)g(comm)n(uni-)0 1042 y(cations)j(within)h(the)g (VPN)g(and)f(p)r(ossibly)g(man)n(y)g(di\013eren)n(t)h(securit)n(y)e (functions)i(for)f(comm)n(unications)g(outside)g(the)h(VPN)0 1141 y(to)31 b(supp)r(ort)g(geographically)e(separate)h(organizational) e(comp)r(onen)n(ts,)k(customers,)f(suppliers,)h(sub-con)n(tractors)c (\(with)0 1241 y(their)c(o)n(wn)g(VPNs\),)h(go)n(v)n(ernmen)n(t,)d(and) i(others.)35 b(Departmen)n(ts)24 b(within)h(large)e(organizations)e(ma) n(y)j(require)f(a)g(n)n(um)n(b)r(er)h(of)0 1340 y(securit)n(y)h(asso)r (ciations)f(to)i(separate)f(and)h(protect)g(data)f(\(e.g.)36 b(p)r(ersonnel)26 b(data,)g(compan)n(y)f(proprietary)f(data,)i (medical\))0 1440 y(on)f(in)n(ternal)g(net)n(w)n(orks)e(and)i(other)g (securit)n(y)f(asso)r(ciations)g(to)h(comm)n(unicate)f(within)i(the)g (same)f(departmen)n(t.)35 b(Nomadic)0 1540 y(users)e(w)n(an)n(ting)f (to)i(\\phone)f(home")g(represen)n(t)f(another)h(set)h(of)f(securit)n (y)g(requiremen)n(ts.)54 b(These)33 b(requiremen)n(ts)g(m)n(ust)0 1639 y(b)r(e)28 b(temp)r(ered)f(with)h(bandwidth)g(c)n(hallenges.)36 b(Smaller)26 b(groups)g(of)i(p)r(eople)f(ma)n(y)g(meet)g(their)h (securit)n(y)e(requiremen)n(ts)g(b)n(y)0 1739 y(setting)g(up)h(\\W)-7 b(ebs)26 b(of)h(T)-7 b(rust".)35 b(ISAKMP)26 b(exc)n(hanges)f(pro)n (vide)g(these)i(assorted)e(net)n(w)n(orking)f(comm)n(unities)j(the)f (abilit)n(y)0 1839 y(to)33 b(presen)n(t)g(p)r(eers)g(with)h(the)g (securit)n(y)f(functionalit)n(y)g(that)h(the)g(user)f(supp)r(orts)g(in) h(an)f(authen)n(ticated)g(and)g(protected)0 1938 y(manner)27 b(for)g(agreemen)n(t)f(up)r(on)i(a)f(common)g(set)h(of)g(securit)n(y)e (attributes,)i(i.e.)37 b(an)27 b(in)n(terop)r(erable)f(securit)n(y)h (asso)r(ciation.)0 2270 y Fj(1.3)112 b(What)38 b(can)g(b)s(e)g (Negotiated?)0 2523 y Fk(Securit)n(y)g(asso)r(ciations)f(m)n(ust)h (supp)r(ort)h(di\013eren)n(t)g(encryption)f(algorithms,)i(authen)n (tication)e(mec)n(hanisms,)i(and)f(k)n(ey)0 2623 y(establishmen)n(t)d (algorithms)g(for)g(other)g(securit)n(y)g(proto)r(cols,)h(as)f(w)n(ell) g(as)g(IP)h(Securit)n(y)-7 b(.)63 b(Securit)n(y)36 b(asso)r(ciations)f (m)n(ust)0 2722 y(also)26 b(supp)r(ort)g(host-orien)n(ted)g (certi\014cates)g(for)g(lo)n(w)n(er)f(la)n(y)n(er)g(proto)r(cols)h(and) g(user-orien)n(ted)f(certi\014cates)h(for)g(higher)h(lev)n(el)0 2822 y(proto)r(cols.)36 b(Algorithm)27 b(and)h(mec)n(hanism)f(indep)r (endence)i(is)f(required)e(in)j(applications)d(suc)n(h)i(as)f(e-mail,)g (remote)h(login,)0 2922 y(and)21 b(\014le)g(transfer,)h(as)e(w)n(ell)h (as)g(in)g(session)f(orien)n(ted)h(proto)r(cols,)g(routing)f(proto)r (cols,)h(and)g(link)h(la)n(y)n(er)d(proto)r(cols.)33 b(ISAKMP)0 3021 y(pro)n(vides)40 b(a)h(common)f(securit)n(y)h(asso)r (ciation)e(and)i(k)n(ey)g(establishmen)n(t)g(proto)r(col)f(for)h(this)g (wide)h(range)e(of)h(securit)n(y)0 3121 y(proto)r(cols,)26 b(applications,)h(securit)n(y)g(requiremen)n(ts,)f(and)i(net)n(w)n(ork) e(en)n(vironmen)n(ts.)0 3320 y(ISAKMP)h(is)g(not)g(b)r(ound)h(to)f(an)n (y)f(sp)r(eci\014c)h(cryptographic)e(algorithm,)i(k)n(ey)f(generation)g (tec)n(hnique,)h(or)f(securit)n(y)h(mec)n(h-)0 3420 y(anism.)36 b(This)28 b(\015exibilit)n(y)f(is)g(b)r(ene\014cial)g(for)g(a)f(n)n(um) n(b)r(er)h(of)g(reasons.)35 b(First,)27 b(it)h(supp)r(orts)f(the)g (dynamic)g(comm)n(unications)0 3519 y(en)n(vironmen)n(t)i(describ)r(ed) g(ab)r(o)n(v)n(e.)41 b(Second,)30 b(the)g(indep)r(endence)h(from)e(sp)r (eci\014c)h(securit)n(y)e(mec)n(hanisms)h(and)g(algorithms)0 3619 y(pro)n(vides)g(a)h(forw)n(ard)f(migration)g(path)h(to)h(b)r (etter)g(mec)n(hanisms)e(and)h(algorithms.)44 b(When)31 b(impro)n(v)n(ed)e(securit)n(y)h(mec)n(ha-)0 3719 y(nisms)f(are)f(dev)n (elop)r(ed)h(or)f(new)h(attac)n(ks)f(against)g(curren)n(t)g(encryption) h(algorithms,)f(authen)n(tication)h(mec)n(hanisms)f(and)0 3818 y(k)n(ey)g(exc)n(hanges)f(are)h(disco)n(v)n(ered,)g(ISAKMP)g(will) i(allo)n(w)d(the)j(up)r(dating)f(of)g(the)g(algorithms)f(and)g(mec)n (hanisms)h(without)0 3918 y(ha)n(ving)e(to)g(dev)n(elop)g(a)g (completely)g(new)h(KMP)f(or)g(patc)n(h)g(the)h(curren)n(t)f(one.)0 4117 y(ISAKMP)i(has)g(basic)h(requiremen)n(ts)e(for)h(its)h(authen)n (tication)f(and)h(k)n(ey)f(exc)n(hange)f(comp)r(onen)n(ts.)43 b(These)29 b(requiremen)n(ts)0 4217 y(guard)35 b(against)h(denial)g(of) g(service,)i(repla)n(y)d(/)h(re\015ection,)j(man-in-the-middle,)f(and)e (connection)g(hijac)n(king)g(attac)n(ks.)0 4316 y(This)h(is)g(imp)r (ortan)n(t)g(b)r(ecause)g(these)g(are)g(the)g(t)n(yp)r(es)g(of)h(attac) n(ks)e(that)h(are)f(targeted)h(against)f(proto)r(cols.)64 b(Complete)0 4416 y(Securit)n(y)27 b(Asso)r(ciation)g(\(SA\))i(supp)r (ort,)e(whic)n(h)h(pro)n(vides)e(mec)n(hanism)i(and)f(algorithm)g (indep)r(endence,)h(and)g(protection)0 4516 y(from)f(proto)r(col)g (threats)g(are)f(the)i(strengths)f(of)h(ISAKMP)-7 b(.)0 4848 y Fj(1.4)112 b(Securit)m(y)37 b(Asso)s(ciations)f(and)i(Managemen) m(t)0 5101 y Fk(A)31 b(Securit)n(y)f(Asso)r(ciation)g(\(SA\))i(is)f(a)f (relationship)g(b)r(et)n(w)n(een)h(t)n(w)n(o)f(or)g(more)g(en)n(tities) g(that)h(describ)r(es)g(ho)n(w)f(the)h(en)n(tities)0 5200 y(will)23 b(utilize)h(securit)n(y)e(services)g(to)h(comm)n (unicate)f(securely)-7 b(.)34 b(This)23 b(relationship)g(is)g(represen) n(ted)e(b)n(y)i(a)g(set)g(of)g(information)0 5300 y(that)31 b(can)g(b)r(e)g(considered)f(a)g(con)n(tract)g(b)r(et)n(w)n(een)h(the)g (en)n(tities.)47 b(The)31 b(information)f(m)n(ust)h(b)r(e)h(agreed)d (up)r(on)i(and)g(shared)0 5399 y(b)r(et)n(w)n(een)c(all)f(the)h(en)n (tities.)37 b(Sometimes)27 b(the)g(information)f(alone)g(is)g(referred) g(to)h(as)f(an)g(SA,)h(but)h(this)f(is)f(just)i(a)e(ph)n(ysical)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(6])p eop %%Page: 7 7 7 6 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(instan)n(tiation)f(of)g(the)g (existing)g(relationship.)35 b(The)27 b(existence)e(of)h(this)h (relationship,)e(represen)n(ted)g(b)n(y)h(the)h(information,)0 490 y(is)21 b(what)h(pro)n(vides)d(the)j(agreed)e(up)r(on)i(securit)n (y)e(information)h(needed)g(b)n(y)g(en)n(tities)h(to)f(securely)g(in)n (terop)r(erate.)33 b(All)22 b(en)n(tities)0 589 y(m)n(ust)j(adhere)e (to)i(the)g(SA)g(for)e(secure)h(comm)n(unications)g(to)g(b)r(e)h(p)r (ossible.)35 b(When)26 b(accessing)d(SA)h(attributes,)i(en)n(tities)e (use)0 689 y(a)29 b(p)r(oin)n(ter)g(or)g(iden)n(ti\014er)h(refered)f (to)g(as)g(the)h(Securit)n(y)f(P)n(arameter)e(Index)j(\(SPI\).)g([RF)n (C-1825)n(])g(pro)n(vides)e(details)h(on)h(IP)0 789 y(Securit)n(y)d (Asso)r(ciations)g(\(SA\))h(and)g(Securit)n(y)f(P)n(arameter)e(Index)j (\(SPI\))f(de\014nitions.)0 1104 y Fe(1.4.1)94 b(Securit)m(y)33 b(Asso)s(ciations)d(and)i(Registration)0 1357 y Fk(The)j(SA)g (attributes)f(required)g(and)g(recommended)h(for)f(the)h(IP)f(Securit)n (y)g(\(AH,)i(ESP\))e(are)f(de\014ned)i(in)g([RF)n(C-1825)n(].)0 1457 y(The)d(attributes)g(sp)r(eci\014ed)g(for)g(an)f(IP)h(Securit)n(y) g(SA)g(include,)i(but)e(are)f(not)h(limited)h(to,)g(authen)n(tication)f (mec)n(hanism,)0 1556 y(cryptographic)d(algorithm,)i(algorithm)f(mo)r (de,)i(k)n(ey)e(length,)i(and)f(Initialization)g(V)-7 b(ector)31 b(\(IV\).)h(Other)e(proto)r(cols)g(that)0 1656 y(pro)n(vide)d(algorithm)h(and)g(mec)n(hanism)g(indep)r(enden)n(t) h(securit)n(y)f(MUST)h(de\014ne)f(their)h(requiremen)n(ts)e(for)h(SA)h (attributes.)0 1756 y(The)d(separation)f(of)h(ISAKMP)f(from)h(a)g(sp)r (eci\014c)g(SA)g(de\014nition)h(is)f(imp)r(ortan)n(t)f(to)h(ensure)g (ISAKMP)f(can)h(establish)g(SAs)0 1855 y(for)h(all)g(p)r(ossible)h (securit)n(y)e(proto)r(cols)h(and)g(applications.)0 2054 y Fg(NOTE:)35 b Fk(See)h([IPDOI])h(for)f(a)g(discussion)g(of)g(SA)i (attributes)e(that)h(should)f(b)r(e)i(considered)d(when)i(de\014ning)g (a)f(securit)n(y)0 2154 y(proto)r(col)26 b(or)h(application.)0 2353 y(In)32 b(order)f(to)g(facilitate)h(easy)f(iden)n(ti\014cation)h (of)g(sp)r(eci\014c)g(attributes)g(\(e.g.)49 b(a)32 b(sp)r(eci\014c)g (encryption)f(algorithm\))g(among)0 2453 y(di\013eren)n(t)d(net)n(w)n (ork)f(en)n(tites)i(the)f(attributes)h(m)n(ust)f(b)r(e)h(assigned)e (iden)n(ti\014ers)h(and)g(these)g(iden)n(ti\014ers)g(m)n(ust)h(b)r(e)g (registered)0 2553 y(b)n(y)34 b(a)g(cen)n(tral)f(authorit)n(y)-7 b(.)56 b(The)35 b(In)n(ternet)f(Assigned)g(Num)n(b)r(ers)g(Authorit)n (y)g(\(IANA\))i(pro)n(vides)c(this)j(function)g(for)f(the)0 2652 y(In)n(ternet.)0 2968 y Fe(1.4.2)94 b(ISAKMP)32 b(Requiremen)m(ts)0 3220 y Fk(Securit)n(y)21 b(Asso)r(ciation)g(\(SA\)) i(establishmen)n(t)f(MUST)g(b)r(e)g(part)f(of)h(the)g(k)n(ey)f (managemen)n(t)g(proto)r(col)g(de\014ned)h(for)f(IP)h(based)0 3320 y(net)n(w)n(orks.)50 b(The)32 b(SA)h(concept)g(is)f(required)g(to) g(supp)r(ort)g(securit)n(y)g(proto)r(cols)f(in)i(a)f(div)n(erse)f(and)i (dynamic)f(net)n(w)n(orking)0 3420 y(en)n(vironmen)n(t.)40 b(Just)29 b(as)f(authen)n(tication)h(and)g(k)n(ey)f(exc)n(hange)g(m)n (ust)h(b)r(e)g(link)n(ed)g(to)g(pro)n(vide)f(assurance)f(that)i(the)h (k)n(ey)e(is)0 3519 y(established)22 b(with)g(the)g(authen)n(ticated)g (part)n(y)f([DO)n(W92)o(],)i(SA)g(establishmen)n(t)f(m)n(ust)g(b)r(e)g (link)n(ed)g(with)g(the)g(authen)n(tication)0 3619 y(and)27 b(the)h(k)n(ey)f(exc)n(hange)f(proto)r(col.)0 3818 y(ISAKMP)35 b(pro)n(vides)f(the)h(proto)r(col)f(exc)n(hanges)g(to)h(establish)g(a)g (securit)n(y)f(asso)r(ciation)g(b)r(et)n(w)n(een)h(negotiating)f(en)n (tities)0 3918 y(follo)n(w)n(ed)21 b(b)n(y)g(the)h(establishmen)n(t)f (of)h(a)f(securit)n(y)g(asso)r(ciation)f(b)n(y)h(these)h(negotiating)e (en)n(tities)i(in)g(b)r(ehalf)g(of)f(some)g(proto)r(col)0 4017 y(\(e.g.)35 b(ESP/AH\).)22 b(First,)h(an)f(initial)g(proto)r(col)f (exc)n(hange)g(allo)n(ws)g(a)g(basic)h(set)g(of)g(securit)n(y)f (attributes)h(to)h(b)r(e)f(agreed)f(up)r(on.)0 4117 y(This)30 b(basic)g(set)h(pro)n(vides)e(protection)g(for)h(subsequen)n(t)h (ISAKMP)f(exc)n(hanges.)43 b(It)31 b(also)e(indicates)i(the)f(authen)n (tication)0 4217 y(metho)r(d)d(and)f(k)n(ey)g(exc)n(hange)f(that)h (will)h(b)r(e)g(p)r(erformed)f(as)f(part)h(of)h(the)f(ISAKMP)g(proto)r (col.)36 b(If)26 b(a)g(basic)g(set)h(of)f(securit)n(y)0 4316 y(attributes)i(is)h(already)e(in)i(place)f(b)r(et)n(w)n(een)h(the) f(negotiating)g(serv)n(er)f(en)n(tities,)i(the)g(initial)g(ISAKMP)f (exc)n(hange)f(ma)n(y)h(b)r(e)0 4416 y(skipp)r(ed)g(and)g(the)g (establishmen)n(t)g(of)f(a)h(securit)n(y)f(asso)r(ciation)f(can)h(b)r (e)i(done)e(directly)-7 b(.)38 b(After)28 b(the)g(basic)f(set)h(of)g (securit)n(y)0 4516 y(attributes)d(has)g(b)r(een)h(agreed)e(up)r(on,)i (initial)f(iden)n(tit)n(y)h(authen)n(ticated,)f(and)g(required)g(k)n (eys)f(generated,)h(the)g(established)0 4615 y(SA)33 b(can)e(b)r(e)i(used)f(for)g(subsequen)n(t)f(comm)n(unications)g(b)n(y) h(the)h(en)n(tit)n(y)f(that)g(in)n(v)n(ok)n(ed)f(ISAKMP)-7 b(.)32 b(The)g(basic)f(set)i(of)f(SA)0 4715 y(attributes)c(that)f(MUST) i(b)r(e)f(implemen)n(ted)g(to)f(pro)n(vide)g(ISAKMP)g(in)n(terop)r (erabilit)n(y)f(are)h(de\014ned)h(in)g(App)r(endix)g(A.)0 5047 y Fj(1.5)112 b(Authen)m(tication)0 5300 y Fk(A)28 b(v)n(ery)f(imp)r(ortan)n(t)h(step)g(in)g(establishing)f(secure)h(net)n (w)n(ork)e(comm)n(unications)h(is)h(authen)n(tication)g(of)g(the)g(en)n (tit)n(y)g(at)g(the)0 5399 y(other)33 b(end)h(of)g(the)g(comm)n (unication.)55 b(Man)n(y)33 b(authen)n(tication)h(mec)n(hanisms)f(are)g (a)n(v)-5 b(ailable.)54 b(Authen)n(tication)34 b(mec)n(ha-)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(7])p eop %%Page: 8 8 8 7 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(nisms)32 b(fall)h(in)n(to)f(t)n(w)n (o)g(catagories)e(of)i(strength)h(-)f(w)n(eak)f(and)i(strong.)50 b(Sending)32 b(cleartext)g(k)n(eys)g(or)f(other)h(unprotected)0 490 y(authen)n(ticating)24 b(information)g(o)n(v)n(er)f(a)i(net)n(w)n (ork)e(is)h(w)n(eak,)h(due)g(to)f(the)h(threat)g(of)g(reading)e(them)i (with)h(a)e(net)n(w)n(ork)f(sni\013er.)0 589 y(Additionally)-7 b(,)26 b(sending)e(one-w)n(a)n(y)f(hashed)i(p)r(o)r(orly-c)n(hosen)d(k) n(eys)i(with)i(lo)n(w)e(en)n(trop)n(y)f(is)i(also)f(w)n(eak,)g(due)i (to)e(the)i(threat)e(of)0 689 y(brute-force)i(guessing)g(attac)n(ks)g (on)h(the)h(sni\013ed)g(messages.)35 b(While)28 b(passw)n(ords)d(can)i (b)r(e)g(used)g(for)g(establishing)g(iden)n(tit)n(y)-7 b(,)0 789 y(they)31 b(are)e(not)h(considered)g(in)g(this)h(con)n(text)f (b)r(ecause)g(of)g(recen)n(t)g(statemen)n(ts)g(from)g(the)g(In)n (ternet)h(Arc)n(hitecture)f(Board)0 888 y([IAB].)56 b(Digital)34 b(signatures,)g(suc)n(h)g(as)f(the)i(Digital)e(Signature)h(Standard)f (\(DSS\))i(and)f(the)g(Riv)n(est-Shamir-Adleman)0 988 y(\(RSA\))h(signature,)g(are)e(public)i(k)n(ey)e(based)h(strong)f (authen)n(tication)g(mec)n(hanisms.)56 b(When)35 b(using)e(public)i(k)n (ey)e(digital)0 1088 y(signatures)e(eac)n(h)g(en)n(tit)n(y)h(requires)e (a)i(public)g(k)n(ey)g(and)g(a)f(priv)-5 b(ate)32 b(k)n(ey)-7 b(.)49 b(Certi\014cates)32 b(are)f(an)g(essen)n(tial)g(part)h(of)g(a)g (digi-)0 1187 y(tal)g(signature)g(authen)n(tication)g(mec)n(hanism.)51 b(Certi\014cates)32 b(bind)h(a)f(sp)r(eci\014c)h(en)n(tit)n(y's)f(iden) n(tit)n(y)h(\(b)r(e)g(it)g(host,)g(net)n(w)n(ork,)0 1287 y(user,)j(or)e(application\))g(to)h(its)g(public)g(k)n(eys)f(and)h(p)r (ossibly)f(other)h(securit)n(y-related)d(information)j(suc)n(h)f(as)g (privileges,)0 1386 y(clearances,)26 b(and)i(compartmen)n(ts.)37 b(Authen)n(tication)29 b(based)e(on)h(digital)g(signatures)e(requires)h (a)h(trusted)g(third)g(part)n(y)f(or)0 1486 y(certi\014cate)33 b(authorit)n(y)f(to)g(create,)i(sign)f(and)f(prop)r(erly)g(distribute)i (certi\014cates.)52 b(F)-7 b(or)33 b(more)f(detailed)h(information)f (on)0 1586 y(digital)27 b(signatures,)g(suc)n(h)g(as)g(DSS)h(and)g (RSA,)g(and)f(certi\014cates)g(see)g([Sc)n(hneier].)0 1901 y Fe(1.5.1)94 b(Certi\014cate)32 b(Authorities)0 2154 y Fk(Certi\014cates)c(require)f(an)i(infrastructure)e(for)h (generation,)g(v)n(eri\014cation,)f(rev)n(o)r(cation,)g(managemen)n(t)h (and)g(distribution.)0 2254 y(The)33 b(In)n(ternet)f(P)n(olicy)f (Registration)g(Authorit)n(y)h(\(IPRA\))h([RF)n(C-1422)n(])g(has)f(b)r (een)g(established)h(to)f(direct)g(this)h(infras-)0 2353 y(tructure)26 b(for)g(the)h(IETF.)f(The)g(IPRA)h(certi\014es)f(P)n (olicy)f(Certi\014cation)g(Authorities)i(\(PCA\).)g(PCAs)e(con)n(trol)h (Certi\014cate)0 2453 y(Authorities)h(\(CA\))i(whic)n(h)e(certify)g (users)g(and)g(sub)r(ordinate)g(en)n(tities.)37 b(Curren)n(t)27 b(certi\014cate)f(related)h(w)n(ork)f(includes)i(the)0 2553 y(Domain)k(Name)h(System)g(\(DNS\))h(Securit)n(y)e(Extensions)f ([DNSSEC)q(])i(whic)n(h)f(will)h(pro)n(vide)e(signed)i(en)n(tit)n(y)f (k)n(eys)g(in)h(the)0 2652 y(DNS.)g(The)f(Public)g(Key)f(Infrastucture) g(\(PKIX\))h(w)n(orking)e(group)h(is)h(sp)r(ecifying)g(an)g(In)n (ternet)f(pro\014le)h(for)f(X.509)g(cer-)0 2752 y(ti\014cates.)41 b(There)29 b(is)g(also)f(w)n(ork)g(going)g(on)g(in)i(industry)f(to)g (dev)n(elop)f(X.500)g(Directory)g(Services)h(whic)n(h)g(w)n(ould)f(pro) n(vide)0 2851 y(X.509)35 b(certi\014cates)f(to)i(users.)60 b(The)36 b(U.S.)g(P)n(ost)e(O\016ce)i(is)f(dev)n(eloping)g(a)g(\(CA\))h (hierarc)n(h)n(y)-7 b(.)59 b(The)36 b(NIST)g(Public)g(Key)0 2951 y(Infrastructure)c(W)-7 b(orking)33 b(Group)g(has)g(also)f(b)r (een)i(doing)e(w)n(ork)g(in)i(this)g(area.)53 b(The)33 b(DOD)h(Multi)g(Lev)n(el)f(Information)0 3051 y(System)j(Securit)n(y)f (Initiativ)n(e)h(\(MISSI\))h(program)d(has)h(b)r(egun)h(deplo)n(ying)f (a)h(certi\014cate)f(infrastructure)g(for)g(the)h(U.S.)0 3150 y(Go)n(v)n(ernmen)n(t.)54 b(Alternativ)n(ely)-7 b(,)35 b(if)f(no)g(infrastructure)e(exists,)j(the)g(PGP)d(W)-7 b(eb)35 b(of)e(T)-7 b(rust)34 b(certi\014cates)f(can)g(b)r(e)h(used)g (to)0 3250 y(pro)n(vide)26 b(user)h(authen)n(tication)h(and)f(priv)-5 b(acy)27 b(in)h(a)f(comm)n(unit)n(y)g(of)h(users)e(who)i(kno)n(w)e(and) i(trust)f(eac)n(h)g(other.)0 3565 y Fe(1.5.2)94 b(En)m(tit)m(y)32 b(Naming)0 3818 y Fk(An)h(en)n(tit)n(y's)f(name)g(is)g(its)h(iden)n (tit)n(y)g(and)f(is)g(b)r(ound)h(to)f(its)h(public)f(k)n(eys)g(in)h (certi\014cates.)50 b(The)32 b(CA)h(MUST)g(de\014ne)g(the)0 3918 y(naming)g(seman)n(tics)g(for)g(the)h(certi\014cates)e(it)i (issues.)54 b(See)34 b(the)f(UNINETT)h(PCA)f(P)n(olicy)g(Statemen)n(ts) g([Berge)o(])g(for)g(an)0 4017 y(example)f(of)g(ho)n(w)g(a)g(CA)h (de\014nes)f(its)h(naming)f(p)r(olicy)-7 b(.)51 b(When)33 b(the)f(certi\014cate)g(is)h(v)n(eri\014ed,)f(the)h(name)f(is)h(v)n (eri\014ed)e(and)0 4117 y(that)24 b(name)g(will)g(ha)n(v)n(e)e(meaning) i(within)g(the)h(realm)e(of)g(that)i(CA.)f(An)g(example)f(is)h(the)g (DNS)h(securit)n(y)e(extensions)g(whic)n(h)0 4217 y(mak)n(e)30 b(DNS)i(serv)n(ers)d(CAs)i(for)f(the)h(zones)g(and)f(no)r(des)h(they)g (serv)n(e.)46 b(Resource)29 b(records)g(are)h(pro)n(vided)g(for)h (public)g(k)n(eys)0 4316 y(and)23 b(signatures)e(on)i(those)f(k)n(eys.) 35 b(The)23 b(names)f(asso)r(ciated)g(with)h(the)h(k)n(eys)e(are)g(IP)g (addresses)f(and)i(domain)g(names)f(whic)n(h)0 4416 y(ha)n(v)n(e)i (meaning)g(to)h(en)n(tities)g(accessing)f(the)h(DNS)h(for)e(this)h (information.)36 b(A)25 b(W)-7 b(eb)25 b(of)g(T)-7 b(rust)25 b(is)g(another)f(example.)36 b(When)0 4516 y(w)n(ebs)31 b(of)h(trust)g(are)f(set)h(up,)h(names)e(are)g(b)r(ound)h(with)h(the)f (public)g(k)n(eys.)49 b(In)32 b(PGP)f(the)h(name)g(is)g(usually)f(the)h (en)n(tit)n(y's)0 4615 y(e-mail)e(address)f(whic)n(h)i(has)f(meaning)g (to)h(those,)g(and)f(only)h(those,)g(who)f(understand)g(e-mail.)46 b(Another)30 b(w)n(eb)g(of)h(trust)0 4715 y(could)c(use)h(an)f(en)n (tirely)g(di\013eren)n(t)h(naming)f(sc)n(heme.)0 5030 y Fe(1.5.3)94 b(ISAKMP)32 b(Requiremen)m(ts)0 5283 y Fk(Strong)d(authen)n(tication)g(MUST)h(b)r(e)g(pro)n(vided)e(on)h (ISAKMP)g(exc)n(hanges.)41 b(Without)30 b(b)r(eing)g(able)f(to)g (authen)n(ticate)h(the)0 5383 y(en)n(tit)n(y)35 b(at)g(the)g(other)g (end,)i(the)f(Securit)n(y)e(Asso)r(ciation)g(\(SA\))j(and)d(session)g (k)n(ey)h(established)g(are)f(susp)r(ect.)59 b(Without)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(8])p eop %%Page: 9 9 9 8 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(authen)n(tication)32 b(y)n(ou)g(are)f(unable)h(to)h(trust)f(an)g(en)n(tit)n(y's)g(iden)n (ti\014cation,)i(whic)n(h)e(mak)n(es)g(access)f(con)n(trol)g (questionable.)0 490 y(While)f(encryption)e(\(e.g.)42 b(ESP\))29 b(and)g(in)n(tegrit)n(y)f(\(e.g.)41 b(AH\))30 b(will)g(protect)f(subsequen)n(t)f(comm)n(unications)h(from)f(passiv)n (e)0 589 y(ea)n(v)n(esdropp)r(ers,)23 b(without)j(authen)n(tication)f (it)h(is)f(p)r(ossible)h(that)f(the)h(SA)g(and)f(k)n(ey)g(ma)n(y)g(ha)n (v)n(e)f(b)r(een)i(established)f(with)h(an)0 689 y(adv)n(ersary)f(who)i (p)r(erformed)g(an)h(activ)n(e)e(man-in-the-middle)i(attac)n(k)f(and)g (is)g(no)n(w)g(stealing)g(all)h(y)n(our)e(p)r(ersonal)g(data.)0 888 y(A)45 b(digital)g(signature)e(algorithm)h(MUST)h(b)r(e)g(used)g (within)g(ISAKMP's)g(authen)n(tication)f(comp)r(onen)n(t.)88 b(Ho)n(w)n(ev)n(er,)0 988 y(ISAKMP)34 b(do)r(es)h(not)g(mandate)f(a)h (sp)r(eci\014c)g(signature)e(algorithm)h(or)g(certi\014cate)g(authorit) n(y)g(\(CA\).)i(ISAKMP)e(allo)n(ws)0 1088 y(an)24 b(en)n(tit)n(y)h (initiating)f(comm)n(unications)g(to)g(indicate)h(whic)n(h)g(CAs)f(it)h (supp)r(orts.)36 b(After)25 b(selection)f(of)g(a)g(CA,)h(the)g(proto)r (col)0 1187 y(pro)n(vides)36 b(the)i(messages)d(required)i(to)g(supp)r (ort)g(the)h(actual)f(authen)n(tication)f(exc)n(hange.)65 b(The)37 b(proto)r(col)g(pro)n(vides)e(a)0 1287 y(facilit)n(y)e(for)g (iden)n(ti\014cation)g(of)g(di\013eren)n(t)g(certi\014cate)g (authorities,)h(certi\014cate)f(t)n(yp)r(es)g(\(e.g.)53 b(X.509,)34 b(PK)n(CS)e(#7,)j(PGP)-7 b(,)0 1386 y(DNS)28 b(SIG)g(and)g(KEY)f(records\),)f(and)i(the)g(exc)n(hange)e(of)h(the)h (certi\014cates)f(iden)n(ti\014ed.)0 1586 y(ISAKMP)i(utilizes)h (digital)f(signatures,)g(based)g(on)g(public)h(k)n(ey)f(cryptograph)n (y)-7 b(,)28 b(for)h(authen)n(tication.)42 b(There)29 b(are)g(other)0 1685 y(strong)21 b(authen)n(tication)g(systems)h(a)n(v) -5 b(ailable,)21 b(whic)n(h)h(could)g(b)r(e)g(sp)r(eci\014ed)g(as)g (additional)f(optional)g(authen)n(tication)h(mec)n(h-)0 1785 y(anisms)32 b(for)g(ISAKMP)-7 b(.)32 b(Some)h(of)f(these)h(authen) n(tication)f(systems)g(rely)g(on)g(a)g(trusted)h(third)g(part)n(y)e (called)h(a)h(k)n(ey)e(dis-)0 1885 y(tribution)f(cen)n(ter)g(\(KDC\))h (to)f(distribute)h(secret)e(session)g(k)n(eys.)44 b(An)31 b(example)f(is)g(Kerb)r(eros,)f(where)h(the)h(trusted)f(third)0 1984 y(part)n(y)f(is)h(the)h(Kerb)r(eros)e(serv)n(er,)g(whic)n(h)h (holds)g(secret)g(k)n(eys)f(for)h(all)g(clien)n(ts)g(and)g(serv)n(ers)e (within)j(its)g(net)n(w)n(ork)d(domain.)0 2084 y(A)g(clien)n(t's)f(pro) r(of)g(that)h(it)g(holds)g(its)f(secret)g(k)n(ey)g(pro)n(vides)f (authen)n(ticaton)h(to)h(a)f(serv)n(er.)0 2283 y(The)j(ISAKMP)g(sp)r (eci\014cation)g(do)r(es)g(not)g(sp)r(ecify)h(the)f(proto)r(col)f(for)h (comm)n(unicating)g(with)g(the)h(trusted)f(third)h(parties)0 2383 y(\(TTP\))41 b(or)f(certi\014cate)h(directory)e(services.)76 b(These)41 b(proto)r(cols)f(are)g(de\014ned)h(b)n(y)g(the)g(TTP)g(and)f (directory)g(service)0 2482 y(themselv)n(es)24 b(and)h(are)f(outside)h (the)g(scop)r(e)g(of)g(this)g(sp)r(eci\014cation.)36 b(The)25 b(use)g(of)g(these)g(additional)f(services)g(and)h(proto)r (cols)0 2582 y(will)j(b)r(e)g(describ)r(ed)f(in)h(a)f(Key)g(Exc)n (hange)f(sp)r(eci\014c)i(do)r(cumen)n(t.)0 2914 y Fj(1.6)112 b(Public)36 b(Key)h(Cryptograph)m(y)0 3167 y Fk(Public)j(k)n(ey)f (cryptograph)n(y)e(is)j(the)g(most)f(\015exible,)k(scalable,)f(and)d (e\016cien)n(t)h(w)n(a)n(y)f(for)g(users)g(to)h(obtain)f(the)h(shared)0 3267 y(secrets)26 b(and)i(session)e(k)n(eys)g(needed)i(to)f(supp)r(ort) g(the)h(large)e(n)n(um)n(b)r(er)h(of)g(w)n(a)n(ys)f(In)n(ternet)h (users)g(will)g(in)n(terop)r(erate.)36 b(Man)n(y)0 3366 y(k)n(ey)k(generation)f(algorithms,)k(that)e(ha)n(v)n(e)e(di\013eren)n (t)i(prop)r(erties,)i(are)d(a)n(v)-5 b(ailable)39 b(to)i(users)e(\(see) i([DO)n(W92)o(],)j([ANSI)q(],)0 3466 y(and)28 b([Oakley)o(]\).)40 b(Prop)r(erties)27 b(of)h(k)n(ey)g(exc)n(hange)f(proto)r(cols)g (include)i(the)g(k)n(ey)f(establishmen)n(t)g(metho)r(d,)h(authen)n (tication,)0 3565 y(symmetry)-7 b(,)27 b(p)r(erfect)h(forw)n(ard)e (secrecy)-7 b(,)27 b(and)g(bac)n(k)g(tra\016c)g(protection.)0 3765 y Fg(NOTE:)e Fk(Cryptographic)g(k)n(eys)g(can)i(protect)f (information)g(for)g(a)h(considerable)e(length)i(of)g(time.)37 b(Ho)n(w)n(ev)n(er,)25 b(this)i(is)g(based)0 3864 y(on)f(the)h (assumption)e(that)i(k)n(eys)e(used)h(for)g(protection)g(of)g(comm)n (unications)f(are)g(destro)n(y)n(ed)g(after)h(use)g(and)g(not)g(k)n (ept)h(for)0 3964 y(an)n(y)g(reason.)0 4279 y Fe(1.6.1)94 b(Key)32 b(Exc)m(hange)g(Prop)s(erties)0 4532 y(Key)d(Establishmen)m(t) e(\(Key)i(Generation)g(/)g(Key)h(T)-8 b(ransp)s(ort\):)83 b Fk(The)25 b(t)n(w)n(o)g(common)g(metho)r(ds)g(of)h(using)f(public)0 4632 y(k)n(ey)h(cryptograph)n(y)e(for)i(k)n(ey)g(establishmen)n(t)h (are)f(k)n(ey)g(transp)r(ort)f(and)i(k)n(ey)f(generation.)35 b(An)27 b(example)f(of)h(k)n(ey)f(transp)r(ort)0 4731 y(is)34 b(the)g(use)g(of)g(the)g(RSA)g(algorithm)f(to)h(encrypt)f(a)h (randomly)f(generated)f(session)h(k)n(ey)g(\(for)h(encrypting)f (subsequen)n(t)0 4831 y(comm)n(unications\))20 b(with)h(the)g(recipien) n(t's)f(public)h(k)n(ey)-7 b(.)34 b(The)21 b(encrypted)f(random)f(k)n (ey)h(is)h(then)g(sen)n(t)f(to)h(the)g(recipien)n(t,)g(who)0 4931 y(decrypts)26 b(it)h(using)f(his)h(priv)-5 b(ate)26 b(k)n(ey)-7 b(.)36 b(A)n(t)27 b(this)f(p)r(oin)n(t)h(b)r(oth)g(sides)f (ha)n(v)n(e)g(the)g(same)g(session)g(k)n(ey)-7 b(,)26 b(ho)n(w)n(ev)n(er)e(it)j(w)n(as)f(created)0 5030 y(based)d(on)h(input) h(from)e(only)h(one)f(side)h(of)g(the)g(comm)n(unications.)35 b(The)24 b(b)r(ene\014t)h(of)f(the)g(k)n(ey)f(transp)r(ort)g(metho)r(d) i(is)e(that)i(it)0 5130 y(has)g(less)g(computational)g(o)n(v)n(erhead)f (than)i(the)g(follo)n(wing)f(metho)r(d.)36 b(The)26 b(Di\016e-Hellman)g (\(D-H\))h(algorithm)e(illustrates)0 5230 y(k)n(ey)i(generation)f (using)h(public)h(k)n(ey)f(cryptograph)n(y)-7 b(.)35 b(The)28 b(D-H)g(algorithm)e(is)i(b)r(egun)g(b)n(y)f(t)n(w)n(o)g(users) g(exc)n(hanging)f(public)0 5329 y(information.)42 b(Eac)n(h)29 b(user)g(then)h(mathematically)f(com)n(bines)g(the)h(other's)f(public)h (information)f(along)g(with)h(their)g(o)n(wn)0 5656 y(Maughan,)d(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)498 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)499 b([P)n(age)25 b(9])p eop %%Page: 10 10 10 9 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(secret)h(information)g(to)h(compute) g(a)f(shared)g(secret)g(v)-5 b(alue.)40 b(This)29 b(secret)f(v)-5 b(alue)29 b(can)f(b)r(e)h(used)g(as)f(a)h(session)e(k)n(ey)h(or)g(as)g (a)0 490 y(k)n(ey)i(encryption)h(k)n(ey)f(for)g(encrypting)h(a)f (randomly)g(generated)g(session)g(k)n(ey)-7 b(.)46 b(This)31 b(metho)r(d)h(generates)d(a)i(session)f(k)n(ey)0 589 y(based)25 b(on)f(public)i(and)f(secret)f(information)h(held)g(b)n(y)g (b)r(oth)h(users.)35 b(The)25 b(b)r(ene\014t)h(of)f(the)g(D-H)h (algorithm)e(is)h(that)g(the)h(k)n(ey)0 689 y(used)g(for)g(encrypting)f (messages)g(is)g(based)h(on)g(information)f(held)i(b)n(y)e(b)r(oth)i (users)e(and)h(the)g(indep)r(endence)h(of)f(k)n(eys)f(from)0 789 y(one)h(k)n(ey)g(exc)n(hange)f(to)h(another)g(pro)n(vides)f(p)r (erfect)i(forw)n(ard)e(secrecy)-7 b(.)35 b(Detailed)27 b(descriptions)e(of)i(these)f(algorithms)f(can)0 888 y(b)r(e)34 b(found)g(in)h([Sc)n(hneier)o(].)56 b(There)33 b(are)g(a)g(n)n(um)n(b)r(er)h(of)g(v)-5 b(ariations)32 b(on)i(these)g(t)n(w)n(o)f(k)n(ey)g(generation)f(sc)n(hemes)h(and)h (these)0 988 y(v)-5 b(ariations)26 b(do)i(not)f(necessarily)f(in)n (terop)r(erate.)0 1298 y Fe(Key)48 b(Exc)m(hange)g(Authen)m(tication:) 83 b Fk(Key)41 b(exc)n(hanges)f(ma)n(y)g(b)r(e)i(authen)n(ticated)f (during)g(the)h(proto)r(col)e(or)g(after)0 1398 y(proto)r(col)29 b(completion.)46 b(Authen)n(tication)31 b(of)g(the)g(k)n(ey)f(exc)n (hange)f(during)i(the)g(proto)r(col)e(is)i(pro)n(vided)e(when)i(eac)n (h)f(part)n(y)0 1498 y(pro)n(vides)39 b(pro)r(of)h(it)h(has)e(the)i (secret)f(session)f(k)n(ey)h(b)r(efore)g(the)h(end)f(of)g(the)h(proto)r (col.)74 b(Pro)r(of)39 b(can)h(b)r(e)h(pro)n(vided)e(b)n(y)0 1597 y(encrypting)c(kno)n(wn)h(data)f(in)h(the)h(secret)e(session)g(k)n (ey)g(during)g(the)i(proto)r(col)d(exc)n(hange.)61 b(Authen)n(tication) 36 b(after)g(the)0 1697 y(proto)r(col)i(m)n(ust)i(o)r(ccur)e(in)i (subsequen)n(t)f(comm)n(unications.)71 b(Authen)n(tication)40 b(during)e(the)i(proto)r(col)e(is)h(preferred)g(so)0 1796 y(subsequen)n(t)d(comm)n(unications)e(are)h(not)h(initiated)g(if)h (the)f(secret)f(session)g(k)n(ey)g(is)h(not)g(established)f(with)h(the) h(desired)0 1896 y(part)n(y)-7 b(.)0 2206 y Fe(Key)30 b(Exc)m(hange)g(Symmetry:)81 b Fk(A)26 b(k)n(ey)f(exc)n(hange)f(pro)n (vides)g(symmetry)i(if)g(either)f(part)n(y)g(can)g(initiate)h(the)h (exc)n(hange)0 2306 y(and)e(exc)n(hanged)f(messages)f(can)i(cross)f(in) h(transit)g(without)g(a\013ecting)g(the)h(k)n(ey)e(that)i(is)f (generated.)34 b(This)26 b(is)f(desirable)f(so)0 2406 y(that)29 b(computation)g(of)f(the)i(k)n(eys)e(do)r(es)g(not)h(require) f(either)g(part)n(y)g(to)h(kno)n(w)f(who)h(initiated)g(the)g(exc)n (hange.)39 b(While)30 b(k)n(ey)0 2505 y(exc)n(hange)19 b(symmetry)h(is)g(desirable,)h(symmetry)f(in)g(the)h(en)n(tire)f(k)n (ey)g(managemen)n(t)f(proto)r(col)g(ma)n(y)h(pro)n(vide)f(a)h (vulnerablit)n(y)0 2605 y(to)27 b(re\015ection)g(attac)n(ks.)0 2915 y Fe(P)m(erfect)35 b(F)-8 b(orw)m(ard)35 b(Secrecy:)84 b Fk(As)30 b(describ)r(ed)f(in)h([DO)n(W92)o(],)g(an)f(authen)n (ticated)g(k)n(ey)g(exc)n(hange)f(proto)r(col)h(pro)n(vides)0 3015 y(p)r(erfect)f(forw)n(ard)d(secrecy)h(if)i(disclosure)e(of)h (long-term)f(secret)h(k)n(eying)f(material)g(do)r(es)h(not)h (compromise)d(the)j(secrecy)e(of)0 3115 y(the)i(exc)n(hanged)e(k)n(eys) g(from)h(previous)f(comm)n(unications.)36 b(The)27 b(prop)r(ert)n(y)g (of)g(p)r(erfect)g(forw)n(ard)f(secrecy)g(do)r(es)h(not)g(apply)0 3214 y(to)g(k)n(ey)g(exc)n(hange)g(without)h(authen)n(tication.)0 3525 y Fe(1.6.2)94 b(ISAKMP)32 b(Requiremen)m(ts)0 3777 y Fk(An)j(authen)n(ticated)f(k)n(ey)f(exc)n(hange)g(MUST)h(b)r(e)h (supp)r(orted)f(b)n(y)f(ISAKMP)-7 b(.)34 b(Users)g(SHOULD)g(c)n(ho)r (ose)f(additional)h(k)n(ey)0 3877 y(establishmen)n(t)e(algorithms)e (based)h(on)g(their)h(requiremen)n(ts.)48 b(ISAKMP)31 b(do)r(es)h(not)f(sp)r(ecify)h(a)g(sp)r(eci\014c)f(k)n(ey)g(exc)n (hange.)0 3977 y(Ho)n(w)n(ev)n(er,)19 b([IKE)o(])g(describ)r(es)f(a)h (prop)r(osal)e(for)h(using)h(the)g(Oakley)f(k)n(ey)g(exc)n(hange)f ([Oakley)o(])i(in)g(conjunction)g(with)g(ISAKMP)-7 b(.)0 4076 y(Requiremen)n(ts)26 b(that)h(should)g(b)r(e)g(ev)-5 b(aluated)27 b(when)g(c)n(ho)r(osing)e(a)i(k)n(ey)f(establishmen)n(t)g (algorithm)g(include)h(establishmen)n(t)0 4176 y(metho)r(d)33 b(\(generation)e(vs.)52 b(transp)r(ort\),)33 b(p)r(erfect)g(forw)n(ard) e(secrecy)-7 b(,)33 b(computational)f(o)n(v)n(erhead,)f(k)n(ey)h(escro) n(w,)g(and)h(k)n(ey)0 4276 y(strength.)h(Based)21 b(on)h(user)f (requiremen)n(ts,)g(ISAKMP)g(allo)n(ws)g(an)g(en)n(tit)n(y)h (initiating)f(comm)n(unications)g(to)g(indicate)h(whic)n(h)0 4375 y(k)n(ey)j(exc)n(hanges)f(it)i(supp)r(orts.)36 b(After)26 b(selection)f(of)g(a)h(k)n(ey)e(exc)n(hange,)h(the)h(proto)r(col)e(pro) n(vides)h(the)h(messages)e(required)g(to)0 4475 y(supp)r(ort)j(the)h (actual)f(k)n(ey)g(establishmen)n(t.)0 4802 y Fj(1.7)112 b(ISAKMP)37 b(Protection)0 5055 y Fe(1.7.1)94 b(An)m(ti-Clogging)30 b(\(Denial)h(of)h(Service\))0 5308 y Fk(Of)f(the)h(n)n(umerous)e (securit)n(y)g(services)g(a)n(v)-5 b(ailable,)31 b(protection)f (against)g(denial)h(of)g(service)f(alw)n(a)n(ys)f(seems)i(to)g(b)r(e)g (one)g(of)0 5407 y(the)25 b(most)f(di\016cult)h(to)f(address.)35 b(A)24 b(\\co)r(okie")f(or)g(an)n(ti-clogging)f(tok)n(en)i(\(A)n(CT\))g (is)h(aimed)f(at)g(protecting)f(the)i(computing)0 5656 y(Maughan,)i(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(10])p eop %%Page: 11 11 11 10 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(resources)c(from)h(attac)n(k)g (without)i(sp)r(ending)f(excessiv)n(e)e(CPU)i(resources)d(to)j (determine)g(its)g(authen)n(ticit)n(y)-7 b(.)36 b(An)26 b(exc)n(hange)0 490 y(prior)20 b(to)h(CPU-in)n(tensiv)n(e)f(public)i(k) n(ey)f(op)r(erations)f(can)h(th)n(w)n(art)f(some)h(denial)g(of)g (service)g(attempts)g(\(e.g.)35 b(simple)21 b(\015o)r(o)r(ding)0 589 y(with)30 b(b)r(ogus)g(IP)f(source)g(addresses\).)42 b(Absolute)30 b(protection)f(against)g(denial)g(of)h(service)f(is)h (imp)r(ossible,)g(but)h(this)f(an)n(ti-)0 689 y(clogging)g(tok)n(en)g (pro)n(vides)g(a)h(tec)n(hnique)h(for)e(making)h(it)h(easier)e(to)h (handle.)48 b(The)32 b(use)f(of)g(an)g(an)n(ti-clogging)e(tok)n(en)i(w) n(as)0 789 y(in)n(tro)r(duced)c(b)n(y)h(Karn)e(and)h(Simpson)h(in)g ([Karn)o(].)0 988 y(It)k(should)g(b)r(e)h(noted)f(that)g(in)h(the)f (exc)n(hanges)f(sho)n(wn)g(in)h(section)g(4,)h(the)f(an)n(ti-clogging)e (mec)n(hanism)i(should)g(b)r(e)g(used)0 1088 y(in)g(conjuction)f(with)h (a)f(garbage-state)d(collection)j(mec)n(hanism;)i(an)e(attac)n(k)n(er)f (can)h(still)g(\015o)r(o)r(d)h(a)f(serv)n(er)e(using)i(pac)n(k)n(ets)0 1187 y(with)j(b)r(ogus)f(IP)g(addresses)f(and)h(cause)f(state)i(to)f(b) r(e)h(created.)53 b(Suc)n(h)34 b(aggressiv)n(e)c(memory)j(managemen)n (t)f(tec)n(hniques)0 1287 y(SHOULD)j(b)r(e)f(emplo)n(y)n(ed)f(b)n(y)h (proto)r(cols)e(using)i(ISAKMP)f(that)i(do)e(not)h(go)f(through)g(an)h (initial,)i(an)n(ti-clogging)31 b(only)0 1386 y(phase,)c(as)g(w)n(as)g (done)g(in)h([Karn)o(].)0 1702 y Fe(1.7.2)94 b(Connection)31 b(Hijac)m(king)0 1955 y Fk(ISAKMP)24 b(prev)n(en)n(ts)f(connection)h (hijac)n(king)f(b)n(y)h(linking)g(the)h(authen)n(tication,)f(k)n(ey)g (exc)n(hange)e(and)i(securit)n(y)g(asso)r(ciation)0 2054 y(exc)n(hanges.)34 b(This)22 b(linking)h(prev)n(en)n(ts)e(an)h(attac)n (k)n(er)f(from)h(allo)n(wing)g(the)h(authen)n(tication)f(to)g(complete) h(and)f(then)i(jumping)0 2154 y(in)k(and)f(imp)r(ersonating)g(one)g(en) n(tit)n(y)h(to)f(the)h(other)f(during)g(the)h(k)n(ey)f(and)h(securit)n (y)e(asso)r(ciation)g(exc)n(hanges.)0 2469 y Fe(1.7.3)94 b(Man-in-the-Middle)29 b(A)m(ttac)m(ks)0 2722 y Fk(Man-in-the-Middle)e (attac)n(ks)e(include)i(in)n(terception,)g(insertion,)f(deletion,)h (and)g(mo)r(di\014cation)g(of)f(messages,)g(re\015ecting)0 2822 y(messages)31 b(bac)n(k)g(at)h(the)h(sender,)g(repla)n(ying)d(old) i(messages)f(and)h(redirecting)f(messages.)49 b(ISAKMP)32 b(features)g(prev)n(en)n(t)0 2922 y(these)e(t)n(yp)r(es)f(of)h(attac)n (ks)f(from)g(b)r(eing)h(successful.)43 b(The)29 b(linking)h(of)g(the)g (ISAKMP)f(exc)n(hanges)f(prev)n(en)n(ts)h(the)h(insertion)0 3021 y(of)f(messages)f(in)i(the)g(proto)r(col)e(exc)n(hange.)41 b(The)29 b(ISAKMP)h(proto)r(col)e(state)h(mac)n(hine)g(is)g(de\014ned)h (so)f(deleted)h(messages)0 3121 y(will)d(not)f(cause)f(a)h(partial)g (SA)h(to)f(b)r(e)g(created,)g(the)h(state)f(mac)n(hine)g(will)h(clear)e (all)h(state)g(and)g(return)g(to)g(idle.)37 b(The)26 b(state)0 3220 y(mac)n(hine)32 b(also)e(prev)n(en)n(ts)h(re\015ection)h (of)g(a)f(message)g(from)h(causing)f(harm.)49 b(The)32 b(requiremen)n(t)f(for)h(a)f(new)h(co)r(okie)g(with)0 3320 y(time)f(v)-5 b(arian)n(t)29 b(material)g(for)g(eac)n(h)h(new)g (SA)h(establishmen)n(t)e(prev)n(en)n(ts)g(attac)n(ks)g(that)i(in)n(v)n (olv)n(e)d(repla)n(ying)h(old)h(messages.)0 3420 y(The)f(ISAKMP)f (strong)g(authen)n(tication)g(requiremen)n(t)g(prev)n(en)n(ts)f(an)i (SA)g(from)f(b)r(eing)h(established)f(with)i(an)n(y)n(one)d(other)0 3519 y(than)h(the)h(in)n(tended)g(part)n(y)-7 b(.)38 b(Messages)26 b(ma)n(y)i(b)r(e)h(redirected)e(to)h(a)g(di\013eren)n(t)h (destination)f(or)f(mo)r(di\014ed)i(but)g(this)f(will)h(b)r(e)0 3619 y(detected)g(and)g(an)f(SA)i(will)f(not)f(b)r(e)h(established.)41 b(The)28 b(ISAKMP)h(sp)r(eci\014cation)f(de\014nes)h(where)f(abnormal)g (pro)r(cessing)0 3719 y(has)f(o)r(ccurred)g(and)g(recommends)g (notifying)g(the)h(appropriate)e(part)n(y)h(of)g(this)h(abnormalit)n(y) -7 b(.)0 4051 y Fj(1.8)112 b(Multicast)36 b(Comm)m(unications)0 4303 y Fk(It)e(is)f(exp)r(ected)h(that)f(m)n(ulticast)h(comm)n (unications)e(will)h(require)g(the)g(same)g(securit)n(y)g(services)f (as)g(unicast)i(comm)n(uni-)0 4403 y(cations)i(and)i(ma)n(y)e(in)n(tro) r(duce)h(the)h(need)f(for)g(additional)f(securit)n(y)h(services.)64 b(The)38 b(issues)e(of)i(distributing)f(SPIs)g(for)0 4503 y(m)n(ulticast)f(tra\016c)g(are)f(presen)n(ted)g(in)i([RF)n (C-1825)m(].)63 b(Multicast)36 b(securit)n(y)f(issues)h(are)f(also)g (discussed)h(in)g([RF)n(C-1949)n(])0 4602 y(and)31 b([BC].)48 b(A)32 b(future)f(extension)g(to)g(ISAKMP)g(will)h(supp)r(ort)f(m)n (ulticast)g(k)n(ey)g(distribution.)48 b(F)-7 b(or)30 b(an)h(in)n(tro)r(duction)g(to)0 4702 y(the)d(issues)f(related)g(to)h (m)n(ulticast)f(securit)n(y)-7 b(,)27 b(consult)h(the)g(In)n(ternet)g (Drafts,)f([RF)n(C-2094)n(])h(and)f([RF)n(C-2093)n(],)h(describing)0 4802 y(Sparta's)f(researc)n(h)e(in)j(this)g(area.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(11])p eop %%Page: 12 12 12 11 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(2)137 b(T)-11 b(erminology)44 b(and)i(Concepts)0 688 y Fj(2.1)112 b(ISAKMP)37 b(T)-9 b(erminology)0 941 y Fe(Securit)m(y)46 b(Proto)s(col:)82 b Fk(A)40 b(Securit)n(y)e(Proto)r(col)g(consists)g(of)h(an)g(en)n(tit)n (y)g(at)g(a)f(single)h(p)r(oin)n(t)g(in)h(the)f(net)n(w)n(ork)f(stac)n (k,)0 1041 y(p)r(erforming)c(a)f(securit)n(y)h(service)f(for)h(net)n(w) n(ork)f(comm)n(unication.)56 b(F)-7 b(or)34 b(example,)i(IPSEC)d(ESP)h (and)g(IPSEC)f(AH)i(are)0 1140 y(t)n(w)n(o)c(di\013eren)n(t)h(securit)n (y)e(proto)r(cols.)48 b(TLS)31 b(is)h(another)f(example.)48 b(Securit)n(y)31 b(Proto)r(cols)f(ma)n(y)h(p)r(erform)g(more)g(than)g (one)0 1240 y(service,)c(for)g(example)g(pro)n(viding)f(in)n(tegrit)n (y)h(and)g(con\014den)n(tialit)n(y)g(in)h(one)f(mo)r(dule.)0 1555 y Fe(Protection)40 b(Suite:)82 b Fk(A)35 b(protection)f(suite)h (is)g(a)f(list)i(of)e(the)h(securit)n(y)f(services)g(that)h(m)n(ust)g (b)r(e)g(applied)g(b)n(y)f(v)-5 b(arious)0 1655 y(securit)n(y)32 b(proto)r(cols.)53 b(F)-7 b(or)33 b(example,)h(a)f(protection)g(suite)h (ma)n(y)e(consist)h(of)g(DES)h(encryption)f(in)g(IP)g(ESP)-7 b(,)33 b(and)g(k)n(ey)n(ed)0 1755 y(MD5)28 b(in)g(IP)f(AH.)h(All)g(of)g (the)g(protections)f(in)h(a)f(suite)h(m)n(ust)g(b)r(e)g(treated)f(as)g (a)g(single)h(unit.)37 b(This)28 b(is)g(necessary)d(b)r(ecause)0 1854 y(securit)n(y)k(services)f(in)i(di\013eren)n(t)g(securit)n(y)f (proto)r(cols)g(can)g(ha)n(v)n(e)g(subtle)h(in)n(teractions,)f(and)h (the)g(e\013ects)g(of)g(a)f(suite)h(m)n(ust)0 1954 y(b)r(e)e(analyzed)f (and)g(v)n(eri\014ed)g(as)g(a)g(whole.)0 2269 y Fe(Securit)m(y)i(Asso)s (ciation)f(\(SA\):)83 b Fk(A)25 b(Securit)n(y)f(Asso)r(ciation)g(is)g (a)h(securit)n(y-proto)r(col-sp)r(eci\014c)c(set)k(of)g(parameters)e (that)0 2369 y(completely)f(de\014nes)f(the)i(services)d(and)i(mec)n (hanisms)f(necessary)f(to)i(protect)f(tra\016c)g(at)h(that)g(securit)n (y)f(proto)r(col)g(lo)r(cation.)0 2469 y(These)31 b(parameters)e(can)i (include)g(algorithm)f(iden)n(ti\014ers,)i(mo)r(des,)f(cryptographic)e (k)n(eys,)i(etc.)48 b(The)31 b(SA)g(is)g(referred)f(to)0 2568 y(b)n(y)d(its)h(asso)r(ciated)e(securit)n(y)h(proto)r(col)f(\(for) i(example,)f(\\ISAKMP)g(SA",)g(\\ESP)g(SA",)g(\\TLS)h(SA"\).)0 2884 y Fe(ISAKMP)40 b(SA:)83 b Fk(An)35 b(SA)g(used)g(b)n(y)f(the)h (ISAKMP)g(serv)n(ers)d(to)j(protect)f(their)h(o)n(wn)f(tra\016c.)57 b(Sections)35 b(2.3)e(and)i(2.4)0 2983 y(pro)n(vide)26 b(more)h(details)h(ab)r(out)f(ISAKMP)g(SAs.)0 3299 y Fe(Securit)m(y)43 b(P)m(arameter)g(Index)f(\(SPI\):)83 b Fk(An)37 b(iden)n(ti\014er)g(for)f(a)g(Securit)n(y)g(Asso)r(cation,)i (relativ)n(e)e(to)g(some)g(securit)n(y)0 3398 y(proto)r(col.)58 b(Eac)n(h)33 b(securit)n(y)h(proto)r(col)g(has)h(its)g(o)n(wn)f (\\SPI-space".)56 b(A)36 b(\(securit)n(y)e(proto)r(col,)i(SPI\))f(pair) f(ma)n(y)g(uniquely)0 3498 y(iden)n(tify)g(an)g(SA.)g(The)g(uniqueness) g(of)g(the)g(SPI)g(is)f(implemen)n(tation)h(dep)r(enden)n(t,)j(but)d (could)g(b)r(e)g(based)f(p)r(er)h(system,)0 3598 y(p)r(er)d(proto)r (col,)g(or)g(other)f(options.)48 b(Dep)r(ending)32 b(on)f(the)g(DOI,)h (additional)e(information)h(\(e.g.)48 b(host)31 b(address\))f(ma)n(y)h (b)r(e)0 3697 y(necessary)23 b(to)h(iden)n(tify)h(an)f(SA.)g(The)h(DOI) f(will)h(also)e(determine)h(whic)n(h)h(SPIs)e(\(i.e.)37 b(initiator's)23 b(or)h(resp)r(onder's\))f(are)g(sen)n(t)0 3797 y(during)k(comm)n(unication.)0 4112 y Fe(Domain)g(of)i(In)m (terpretation:)84 b Fk(A)25 b(Domain)g(of)g(In)n(terpretation)f (\(DOI\))i(de\014nes)f(pa)n(yload)f(formats,)g(exc)n(hange)g(t)n(yp)r (es,)0 4212 y(and)36 b(con)n(v)n(en)n(tions)d(for)j(naming)f(securit)n (y-relev)-5 b(an)n(t)34 b(information)h(suc)n(h)g(as)g(securit)n(y)g(p) r(olicies)g(or)g(cryptographic)f(algo-)0 4312 y(rithms)22 b(and)h(mo)r(des.)35 b(A)23 b(Domain)f(of)g(In)n(terpretation)g (\(DOI\))h(iden)n(ti\014er)f(is)h(used)f(to)h(in)n(terpret)e(the)i(pa)n (yloads)e(of)h(ISAKMP)0 4411 y(pa)n(yloads.)43 b(A)31 b(system)f(SHOULD)h(supp)r(ort)f(m)n(ultiple)h(Domains)f(of)g(In)n (terpretation)f(sim)n(ultaneously)-7 b(.)45 b(The)30 b(concept)g(of)0 4511 y(a)h(DOI)h(is)f(based)g(on)g(previous)g(w)n(ork) f(b)n(y)h(the)h(TSIG)f(CIPSO)g(W)-7 b(orking)31 b(Group,)h(but)g (extends)f(b)r(ey)n(ond)g(securit)n(y)g(lab)r(el)0 4610 y(in)n(terpretation)c(to)g(include)h(naming)f(and)h(in)n(terpretation)e (of)i(securit)n(y)e(services.)36 b(A)28 b(DOI)g(de\014nes:)125 4893 y Fc(\017)41 b Fk(A)27 b(\\situation":)36 b(the)28 b(set)g(of)f(information)g(that)h(will)g(b)r(e)g(used)g(to)f(determine) h(the)g(required)e(securit)n(y)h(services.)125 5059 y Fc(\017)41 b Fk(The)27 b(set)h(of)f(securit)n(y)g(p)r(olicies)g(that)h (m)n(ust,)g(and)g(ma)n(y)-7 b(,)27 b(b)r(e)h(supp)r(orted.)125 5225 y Fc(\017)41 b Fk(A)27 b(syn)n(tax)g(for)g(the)h(sp)r (eci\014cation)f(of)h(prop)r(osed)f(securit)n(y)f(services.)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(12])p eop %%Page: 13 13 13 12 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y Fc(\017)41 b Fk(A)d(sc)n(heme)h (for)f(naming)g(securit)n(y-relev)-5 b(an)n(t)36 b(information,)41 b(including)e(encryption)f(algorithms,)i(k)n(ey)e(exc)n(hange)208 490 y(algorithms,)26 b(securit)n(y)h(p)r(olicy)g(attributes,)h(and)f (certi\014cate)g(authorities.)125 656 y Fc(\017)41 b Fk(The)27 b(sp)r(eci\014c)h(formats)f(of)g(the)h(v)-5 b(arious)27 b(pa)n(yload)f(con)n(ten)n(ts.)125 822 y Fc(\017)41 b Fk(Additional)27 b(exc)n(hange)g(t)n(yp)r(es,)g(if)h (required.)0 1104 y(The)e(rules)f(for)g(the)g(IETF)h(IP)f(Securit)n(y)g (DOI)g(are)g(presen)n(ted)g(in)h([IPDOI)o(].)37 b(Sp)r(eci\014cations) 25 b(of)g(the)h(rules)f(for)g(customized)0 1204 y(DOIs)i(will)h(b)r(e)g (presen)n(ted)f(in)h(separate)e(do)r(cumen)n(ts.)0 1519 y Fe(Situation:)82 b Fk(A)28 b(situation)g(con)n(tains)e(all)i(of)f (the)h(securit)n(y-relev)-5 b(an)n(t)26 b(information)h(that)h(a)f (system)g(considers)g(necessary)0 1619 y(to)j(decide)g(the)h(securit)n (y)e(services)f(required)i(to)g(protect)f(the)i(session)e(b)r(eing)h (negotiated.)43 b(The)30 b(situation)g(ma)n(y)g(include)0 1718 y(addresses,)c(securit)n(y)h(classi\014cations,)f(mo)r(des)h(of)h (op)r(eration)e(\(normal)h(vs.)37 b(emergency\),)26 b(etc.)0 2034 y Fe(Prop)s(osal:)82 b Fk(A)33 b(prop)r(osal)f(is)h(a)g(list,)i (in)f(decreasing)d(order)h(of)h(preference,)h(of)g(the)f(protection)g (suites)g(that)g(a)g(system)0 2134 y(considers)26 b(acceptable)h(to)h (protect)f(tra\016c)g(under)g(a)h(giv)n(en)e(situation.)0 2449 y Fe(P)m(a)m(yload:)84 b Fk(ISAKMP)18 b(de\014nes)h(sev)n(eral)e (t)n(yp)r(es)h(of)h(pa)n(yloads,)g(whic)n(h)f(are)g(used)g(to)h (transfer)f(information)g(suc)n(h)g(as)g(securit)n(y)0 2549 y(asso)r(ciation)32 b(data,)j(or)e(k)n(ey)h(exc)n(hange)e(data,)j (in)f(DOI-de\014ned)g(formats.)56 b(A)34 b(pa)n(yload)e(consists)h(of)h (a)g(generic)f(pa)n(yload)0 2648 y(header)39 b(and)h(a)g(string)g(of)g (o)r(ctects)g(that)h(is)f(opaque)f(to)h(ISAKMP)-7 b(.)40 b(ISAKMP)g(uses)g(DOI-sp)r(eci\014c)g(functionalit)n(y)g(to)0 2748 y(syn)n(thesize)31 b(and)g(in)n(terpret)f(these)h(pa)n(yloads.)46 b(Multiple)32 b(pa)n(yloads)e(can)g(b)r(e)i(sen)n(t)f(in)h(a)e(single)h (ISAKMP)g(message.)46 b(See)0 2847 y(section)29 b(3)g(for)f(more)h (details)g(on)g(the)g(pa)n(yload)f(t)n(yp)r(es,)i(and)f([IPDOI)o(])h (for)f(the)g(formats)g(of)g(the)h(IETF)e(IP)h(Securit)n(y)g(DOI)0 2947 y(pa)n(yloads.)0 3263 y Fe(Exc)m(hange)f(T)m(yp)s(e:)83 b Fk(An)23 b(exc)n(hange)f(t)n(yp)r(e)h(is)g(a)g(sp)r(eci\014cation)g (of)g(the)g(n)n(um)n(b)r(er)g(of)g(messages)f(in)h(an)g(ISAKMP)f(exc)n (hange,)0 3362 y(and)35 b(the)h(pa)n(yload)e(t)n(yp)r(es)i(that)f(are)g (con)n(tained)g(in)g(eac)n(h)g(of)h(those)f(messages.)59 b(Eac)n(h)34 b(exc)n(hange)g(t)n(yp)r(e)i(is)f(designed)g(to)0 3462 y(pro)n(vide)23 b(a)g(particular)f(set)i(of)f(securit)n(y)g (services,)g(suc)n(h)h(as)f(anon)n(ymit)n(y)f(of)i(the)g(participan)n (ts,)g(p)r(erfect)g(forw)n(ard)e(secrecy)g(of)0 3561 y(the)30 b(k)n(eying)e(material,)h(authen)n(tication)g(of)g(the)h (participan)n(ts,)e(etc.)43 b(Section)29 b(4.1)f(de\014nes)i(the)f (default)h(set)f(of)g(ISAKMP)0 3661 y(exc)n(hange)d(t)n(yp)r(es.)37 b(Other)27 b(exc)n(hange)f(t)n(yp)r(es)i(can)f(b)r(e)h(added)f(to)h (supp)r(ort)f(additional)g(k)n(ey)g(exc)n(hanges,)f(if)i(required.)0 3993 y Fj(2.2)112 b(ISAKMP)37 b(Placemen)m(t)0 4246 y Fk(Figure)23 b(1)g(is)h(a)f(high)h(lev)n(el)f(view)h(of)f(the)i (placemen)n(t)e(of)h(ISAKMP)f(within)h(a)g(system)f(con)n(text)h(in)g (a)f(net)n(w)n(ork)f(arc)n(hitecture.)0 4346 y(An)32 b(imp)r(ortan)n(t)g(part)f(of)h(negotiating)f(securit)n(y)g(services)g (is)h(to)f(consider)g(the)i(en)n(tire)e(\\stac)n(k")f(of)i(individual)g (SAs)g(as)f(a)0 4445 y(unit.)38 b(This)27 b(is)h(referred)e(to)h(as)g (a)h(\\protection)e(suite".)0 4777 y Fj(2.3)112 b(Negotiation)36 b(Phases)0 5030 y Fk(ISAKMP)25 b(o\013ers)g(t)n(w)n(o)f(\\phases")g(of) h(negotiation.)35 b(In)26 b(the)f(\014rst)h(phase,)f(t)n(w)n(o)g(en)n (tities)g(\(e.g.)36 b(ISAKMP)25 b(serv)n(ers\))f(agree)f(on)0 5130 y(ho)n(w)28 b(to)g(protect)g(further)g(negotiation)g(tra\016c)g(b) r(et)n(w)n(een)g(themselv)n(es,)g(establishing)g(an)g(ISAKMP)g(SA.)h (This)f(ISAKMP)0 5229 y(SA)c(is)f(then)g(used)g(to)g(protect)g(the)h (negotiations)e(for)g(the)i(Proto)r(col)d(SA)j(b)r(eing)f(requested.)35 b(Tw)n(o)22 b(en)n(tities)h(\(e.g.)35 b(ISAKMP)0 5329 y(serv)n(ers\))26 b(can)h(negotiate)g(\(and)g(ha)n(v)n(e)g(activ)n(e\)) g(m)n(ultiple)h(ISAKMP)f(SAs.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(13])p eop %%Page: 14 14 14 13 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)218 490 y Fg(+------------+)343 b(+--------+)693 b(+--------------+)218 589 y(!)217 b(DOI)174 b(!)348 b(!)g(!)697 b(!)87 b(Application)39 b(!)218 689 y(!)k(Definition)d(!)j(<---->)e(!)i(ISAKMP)e(!)697 b(!)174 b(Process)128 b(!)218 789 y(+------------+)168 b(-->)43 b(!)348 b(!)697 b(!--------------!)174 888 y(+--------------+)124 b(!)131 b(+--------+)693 b(!)43 b(Appl)f(Protocol!)174 988 y(!)i(Key)e(Exchange)e(!)130 b(!)218 b(^)87 b(^)871 b(+--------------+)174 1088 y(!)87 b(Definition)c(!<--)260 b(!)87 b(!)1176 b(^)174 1187 y(+--------------+)386 b(!)87 b(!)1176 b(!)1264 1287 y(!)87 b(!)1176 b(!)523 1386 y(!---------------) o(-!)81 b(!)1176 b(!)523 1486 y(v)828 b(!)1176 b(!)349 1586 y(+-------+)650 b(v)1176 b(v)349 1685 y(!)86 b(API)g(!)349 b(+--------------)o(---)o(--)o(---)o(--)o(--)o(---)o(--)o(---)o(--)o (---)o(--)o(--)o(--+)349 1785 y(+-------+)c(!)697 b(Socket)41 b(Layer)739 b(!)523 1885 y(!)523 b(!--------------)o(---)o(--)o(---)o (--)o(--)o(---)o(--)o(---)o(--)o(---)o(--)o(--)o(--!)523 1984 y(v)g(!)348 b(Transport)40 b(Protocol)g(\(TCP)i(/)h(UDP\))304 b(!)218 2084 y(+----------+)344 b(!--------------)o(---)o(--)o(---)o (--)o(--)o(---)o(--)o(---)o(--)o(---)o(--)o(--)o(--!)218 2183 y(!)43 b(Security)d(!)k(<---->)d(!)915 b(IP)958 b(!)218 2283 y(!)43 b(Protocol)d(!)349 b(!--------------)o(---)o(--)o (---)o(--)o(--)o(---)o(--)o(---)o(--)o(---)o(--)o(--)o(--!)218 2383 y(+----------+)344 b(!)566 b(Link)42 b(Layer)f(Protocol)564 b(!)1090 2482 y(+--------------)o(---)o(--)o(---)o(--)o(--)o(---)o(--)o (---)o(--)o(---)o(--)o(--)o(--+)1343 2848 y Fk(Figure)27 b(1:)37 b(ISAKMP)27 b(Relationships)0 3113 y(The)h(second)g(phase)g(of) h(negotiation)e(is)h(used)h(to)f(establish)g(securit)n(y)f(asso)r (ciations)g(for)h(other)g(securit)n(y)f(proto)r(cols.)38 b(This)0 3212 y(second)29 b(phase)g(can)g(b)r(e)h(used)f(to)g (establish)h(man)n(y)e(securit)n(y)h(asso)r(ciations.)41 b(The)29 b(securit)n(y)g(asso)r(ciations)e(established)i(b)n(y)0 3312 y(ISAKMP)e(during)g(this)h(phase)f(can)h(b)r(e)g(used)f(b)n(y)g(a) h(securit)n(y)e(proto)r(col)h(to)g(protect)g(man)n(y)g(message/data)f (exc)n(hanges.)0 3511 y(While)c(the)h(t)n(w)n(o-phased)d(approac)n(h)g (has)h(a)h(higher)f(start-up)g(cost)h(for)f(most)h(simple)g(scenarios,) f(there)h(are)f(sev)n(eral)f(reasons)0 3611 y(that)28 b(it)g(is)f(b)r(ene\014cial)h(for)f(most)h(cases.)0 3810 y(First,)33 b(en)n(tities)g(\(e.g.)51 b(ISAKMP)31 b(serv)n(ers\))g(can) h(amortize)f(the)i(cost)e(of)i(the)f(\014rst)g(phase)g(across)e(sev)n (eral)h(second)h(phase)0 3910 y(negotiations.)50 b(This)32 b(allo)n(ws)f(m)n(ultiple)h(SAs)h(to)f(b)r(e)h(established)f(b)r(et)n (w)n(een)g(p)r(eers)g(o)n(v)n(er)e(time)j(without)f(ha)n(ving)g(to)g (start)0 4010 y(o)n(v)n(er)26 b(for)h(eac)n(h)g(comm)n(unication.)0 4209 y(Second,)h(securit)n(y)f(services)g(negotiated)h(during)f(the)i (\014rst)f(phase)f(pro)n(vide)g(securit)n(y)h(prop)r(erties)f(for)g (the)i(second)f(phase.)0 4308 y(F)-7 b(or)29 b(example,)h(after)f(the)h (\014rst)g(phase)f(of)h(negotiation,)f(the)h(encryption)f(pro)n(vided)g (b)n(y)g(the)h(ISAKMP)g(SA)g(can)f(pro)n(vide)0 4408 y(iden)n(tit)n(y)i(protection,)h(p)r(oten)n(tially)f(allo)n(wing)f(the) i(use)f(of)g(simpler)g(second-phase)f(exc)n(hanges.)47 b(On)31 b(the)h(other)e(hand,)j(if)0 4508 y(the)f(c)n(hannel)f (established)g(during)h(the)f(\014rst)h(phase)f(is)g(not)h(adequate)f (to)g(protect)h(iden)n(tities,)h(then)f(the)g(second)f(phase)0 4607 y(m)n(ust)d(negotiate)e(adequate)h(securit)n(y)g(mec)n(hanisms.)0 4807 y(Third,)35 b(ha)n(ving)d(an)h(ISAKMP)g(SA)h(in)g(place)f (considerably)e(reduces)i(the)h(cost)f(of)g(ISAKMP)g(managemen)n(t)f (activit)n(y)h(-)0 4906 y(without)28 b(the)h(\\trusted)e(path")h(that)g (an)g(ISAKMP)f(SA)i(giv)n(es)d(y)n(ou,)i(the)g(en)n(tities)g(\(e.g.)38 b(ISAKMP)28 b(serv)n(ers\))e(w)n(ould)h(ha)n(v)n(e)0 5006 y(to)g(go)g(through)g(a)g(complete)h(re-authen)n(tication)e(for)h (eac)n(h)g(error)f(noti\014cation)h(or)f(deletion)i(of)g(an)f(SA.)0 5205 y(Negotiation)20 b(during)h(eac)n(h)f(phase)h(is)g(accomplished)g (using)f(ISAKMP-de\014ned)h(exc)n(hanges)f(\(see)h(section)f(4\))h(or)g (exc)n(hanges)0 5305 y(de\014ned)28 b(for)f(a)g(k)n(ey)g(exc)n(hange)f (within)j(a)e(DOI.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i (T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(14])p eop %%Page: 15 15 15 14 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(Note)37 b(that)g(securit)n(y)f (services)g(ma)n(y)g(b)r(e)h(applied)g(di\013eren)n(tly)g(in)g(eac)n(h) f(negotiation)g(phase.)64 b(F)-7 b(or)36 b(example,)j(di\013eren)n(t)0 490 y(parties)26 b(are)g(b)r(eing)i(authen)n(ticated)f(during)f(eac)n (h)h(of)g(the)g(phases)g(of)g(negotiation.)35 b(During)27 b(the)h(\014rst)f(phase,)f(the)i(parties)0 589 y(b)r(eing)e(authen)n (ticated)f(ma)n(y)g(b)r(e)h(the)g(ISAKMP)g(serv)n(ers/hosts,)d(while)i (during)h(the)g(second)f(phase,)g(users)g(or)g(application)0 689 y(lev)n(el)i(programs)e(are)i(b)r(eing)h(authen)n(ticated.)0 1021 y Fj(2.4)112 b(Iden)m(tifying)37 b(Securit)m(y)f(Asso)s(ciations)0 1274 y Fk(While)g(b)r(o)r(otstrapping)e(secure)g(c)n(hannels)g(b)r(et)n (w)n(een)h(systems,)h(ISAKMP)f(cannot)g(assume)f(the)h(existence)g(of)g (securit)n(y)0 1374 y(services,)28 b(and)h(m)n(ust)g(pro)n(vide)e(some) i(protections)f(for)g(itself.)41 b(Therefore,)28 b(ISAKMP)h(considers)e (an)i(ISAKMP)g(Securit)n(y)0 1473 y(Asso)r(ciation)k(to)g(b)r(e)h (di\013eren)n(t)g(than)g(other)f(t)n(yp)r(es,)i(and)e(manages)f(ISAKMP) i(SAs)f(itself,)j(in)e(their)f(o)n(wn)g(name)h(space.)0 1573 y(ISAKMP)d(uses)g(the)g(t)n(w)n(o)g(co)r(okie)f(\014elds)h(in)h (the)f(ISAKMP)g(header)g(to)g(iden)n(tify)g(ISAKMP)g(SAs.)48 b(The)31 b(Message)f(ID)i(in)0 1672 y(the)25 b(ISAKMP)f(Header)f(and)h (the)h(SPI)f(\014eld)g(in)h(the)f(Prop)r(osal)f(pa)n(yload)f(are)i (used)g(during)g(SA)g(establishmen)n(t)g(to)h(iden)n(tify)0 1772 y(the)33 b(SA)h(for)e(other)h(securit)n(y)f(proto)r(cols.)52 b(The)33 b(in)n(terpretation)f(of)h(these)g(four)f(\014elds)h(is)g(dep) r(enden)n(t)h(on)f(the)g(op)r(eration)0 1872 y(taking)27 b(place.)0 2071 y(The)i(follo)n(wing)f(table)g(sho)n(ws)g(the)h (presence)f(or)g(absence)g(of)h(sev)n(eral)e(\014elds)i(during)g(SA)g (establishmen)n(t.)40 b(The)29 b(follo)n(wing)0 2171 y(\014elds)23 b(are)f(necessary)f(for)h(v)-5 b(arious)22 b(op)r(erations)f(asso)r(ciated)h(with)h(SA)g(establishmen)n(t:)34 b(co)r(okies)22 b(in)h(the)g(ISAKMP)g(header,)0 2270 y(the)34 b(ISAKMP)e(Header)h(Message)f(ID)h(\014eld,)i(and)e(the)h(SPI) f(\014eld)g(in)h(the)f(Prop)r(osal)e(pa)n(yload.)53 b(An)33 b('X')h(in)f(the)h(column)0 2370 y(means)28 b(the)h(v)-5 b(alue)28 b(MUST)h(b)r(e)g(presen)n(t.)38 b(An)29 b('NA')g(in)g(the)g (column)f(means)g(a)g(v)-5 b(alue)28 b(in)h(the)g(column)f(is)g(Not)h (Applicable)0 2470 y(to)e(the)h(op)r(eration.)445 2846 y(#)558 b(Op)r(eration)538 b(I-Co)r(okie)98 b(R-Co)r(okie)h(Message)26 b(ID)100 b(SPI)p 377 2879 3147 4 v 427 2946 a(\(1\))f(Start)28 b(ISAKMP)f(SA)h(negotiation)227 b(X)344 b(0)396 b(0)477 b(0)427 3045 y(\(2\))99 b(Resp)r(ond)28 b(ISAKMP)f(SA)h(negotiation)99 b(X)344 b(X)376 b(0)477 b(0)427 3145 y(\(3\))99 b(Init)28 b(other)g(SA)g(negotiation)426 b(X)344 b(X)376 b(X)457 b(X)427 3244 y(\(4\))99 b(Resp)r(ond)28 b(other)f(SA)h(negotiation)245 b(X)344 b(X)376 b(X)457 b(X)427 3344 y(\(5\))99 b(Other)27 b(\(KE,)h(ID,)g(etc.\))596 b(X)344 b(X)376 b(X/0)d(NA)427 3444 y(\(6\))99 b(Securit)n(y)27 b(Proto)r(col)f(\(ESP)-7 b(,)27 b(AH\))296 b(NA)282 b(NA)314 b(NA)395 b(X)0 3727 y(In)35 b(the)g(\014rst)f(line)h(\(1\))f(of)h(the)g(table,)h(the)f (initiator)f(includes)h(the)f(Initiator)g(Co)r(okie)g(\014eld)h(in)g (the)g(ISAKMP)f(Header,)0 3826 y(using)27 b(the)h(pro)r(cedures)f (outlined)g(in)h(sections)f(2.5.3)g(and)g(3.1.)0 4026 y(In)38 b(the)h(second)e(line)h(\(2\))h(of)f(the)g(table,)j(the)d(resp) r(onder)f(includes)h(the)h(Initiator)e(and)h(Resp)r(onder)g(Co)r(okie)f (\014elds)h(in)0 4125 y(the)e(ISAKMP)g(Header,)h(using)f(the)g(pro)r (cedures)f(outlined)h(in)g(sections)g(2.5.3)e(and)i(3.1.)61 b(Additional)37 b(messages)d(ma)n(y)0 4225 y(b)r(e)c(exc)n(hanged)f(b)r (et)n(w)n(een)g(ISAKMP)h(p)r(eers,)g(dep)r(ending)g(on)f(the)h(ISAKMP)g (exc)n(hange)e(t)n(yp)r(e)i(used)g(during)f(the)h(phase)f(1)0 4325 y(negotiation.)44 b(Once)31 b(the)f(phase)g(1)g(exc)n(hange)f(is)i (completed,)g(the)g(Initiator)f(and)g(Resp)r(onder)g(co)r(okies)f(are)h (included)h(in)0 4424 y(the)d(ISAKMP)f(Header)g(of)h(all)f(subsequen)n (t)g(comm)n(unications)g(b)r(et)n(w)n(een)g(the)h(ISAKMP)g(p)r(eers.)0 4623 y(During)d(phase)g(1)f(negotiations,)h(the)g(initiator)g(and)g (resp)r(onder)f(co)r(okies)g(determine)h(the)h(ISAKMP)f(SA.)g (Therefore,)g(the)0 4723 y(SPI)32 b(\014eld)h(in)g(the)f(Prop)r(osal)f (pa)n(yload)g(is)h(redundan)n(t)g(and)g(MA)-7 b(Y)33 b(b)r(e)g(set)g(to)f(0)g(or)g(it)h(MA)-7 b(Y)33 b(con)n(tain)e(the)i (transmitting)0 4823 y(en)n(tit)n(y's)27 b(co)r(okie.)0 5022 y(In)j(the)f(third)h(line)f(\(3\))h(of)f(the)h(table,)g(the)f (initiator)g(asso)r(ciates)f(a)h(Message)f(ID)i(with)f(the)h(Proto)r (cols)d(con)n(tained)i(in)h(the)0 5122 y(SA)24 b(Prop)r(osal.)34 b(This)24 b(Message)e(ID)j(and)e(the)i(initiator's)e(SPI\(s\))h(to)g(b) r(e)g(asso)r(ciated)e(with)j(eac)n(h)e(proto)r(col)g(in)h(the)g(Prop)r (osal)0 5221 y(are)i(sen)n(t)h(to)h(the)f(resp)r(onder.)36 b(The)27 b(SPI\(s\))g(will)h(b)r(e)g(used)f(b)n(y)g(the)h(securit)n(y)e (proto)r(cols)g(once)h(the)g(phase)g(2)g(negotiation)f(is)0 5321 y(completed.)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i (T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(15])p eop %%Page: 16 16 16 15 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(In)i(the)h(fourth)f(line)h(\(4\))f (of)g(the)h(table,)g(the)f(resp)r(onder)f(includes)i(the)f(same)g (Message)f(ID)h(and)h(the)f(resp)r(onder's)f(SPI\(s\))0 490 y(to)f(b)r(e)h(asso)r(ciated)f(with)h(eac)n(h)f(proto)r(col)f(in)i (the)g(accepted)f(Prop)r(osal.)35 b(This)28 b(information)e(is)i (returned)f(to)h(the)g(initiator.)0 689 y(In)d(the)f(\014fth)i(line)e (\(5\))h(of)f(the)h(table,)g(the)f(initiator)g(and)g(resp)r(onder)f (use)i(the)f(Message)f(ID)i(\014eld)g(in)f(the)h(ISAKMP)f(Header)0 789 y(to)i(k)n(eep)f(trac)n(k)g(of)h(the)g(in-progress)e(proto)r(col)g (negotiation.)36 b(This)26 b(is)g(only)f(applicable)g(for)h(a)f(phase)h (2)f(exc)n(hange)g(and)h(the)0 888 y(v)-5 b(alue)31 b(SHOULD)g(b)r(e)g (0)g(for)f(a)h(phase)f(1)g(exc)n(hange)g(b)r(ecause)g(the)h(com)n (bined)g(co)r(okies)f(iden)n(tify)h(the)g(ISAKMP)g(SA.)g(The)0 988 y(SPI)25 b(\014eld)i(in)f(the)g(Prop)r(osal)e(pa)n(yload)g(is)i (not)f(applicable)h(b)r(ecause)f(the)h(Prop)r(osal)e(pa)n(yload)g(is)i (only)f(used)h(during)f(the)i(SA)0 1088 y(negotiation)g(message)f(exc)n (hange)g(\(steps)i(3)f(and)g(4\).)0 1287 y(In)g(the)h(sixth)f(line)g (\(6\))h(of)f(the)g(table,)g(the)h(phase)e(2)h(negotiation)f(is)h (complete.)37 b(The)27 b(securit)n(y)f(proto)r(cols)g(use)h(the)g (SPI\(s\))0 1386 y(to)32 b(determine)h(whic)n(h)f(securit)n(y)g (services)f(and)h(mec)n(hanisms)g(to)g(apply)h(to)f(the)h(comm)n (unication)f(b)r(et)n(w)n(een)g(them.)52 b(The)0 1486 y(SPI)24 b(v)-5 b(alue)23 b(sho)n(wn)g(in)h(the)h(sixth)f(line)g(\(6\)) g(is)f(not)h(the)h(SPI)e(\014eld)h(in)g(the)h(Prop)r(osal)c(pa)n (yload,)i(but)i(the)f(SPI)g(\014eld)g(con)n(tained)0 1586 y(within)k(the)g(securit)n(y)f(proto)r(col)f(header.)0 1785 y(During)35 b(the)g(SA)h(establishmen)n(t,)g(a)f(SPI)g(MUST)g(b)r (e)h(generated.)57 b(ISAKMP)35 b(is)g(designed)g(to)f(handle)h(v)-5 b(ariable)34 b(sized)0 1885 y(SPIs.)h(This)23 b(is)g(accomplished)g(b)n (y)f(using)h(the)h(SPI)f(Size)g(\014eld)h(within)f(the)h(Prop)r(osal)d (pa)n(yload)h(during)h(SA)g(establishmen)n(t.)0 1984 y(Handling)k(of)h(SPIs)f(will)h(b)r(e)g(outlined)g(b)n(y)f(the)h(DOI)g (sp)r(eci\014cation)f(\(e.g.)37 b([IPDOI)o(]\).)0 2183 y(When)26 b(a)f(securit)n(y)f(asso)r(ciation)g(\(SA\))i(is)g(initially) f(established,)h(one)f(side)g(assumes)f(the)i(role)f(of)g(initiator)g (and)g(the)h(other)0 2283 y(the)32 b(role)f(of)h(resp)r(onder.)48 b(Once)31 b(the)h(SA)g(is)g(established,)g(b)r(oth)g(the)h(original)d (initiator)h(and)h(resp)r(onder)e(can)h(initiate)h(a)0 2383 y(phase)27 b(2)g(negotiation)g(with)h(the)g(p)r(eer)f(en)n(tit)n (y)-7 b(.)37 b(Th)n(us,)28 b(ISAKMP)f(SAs)h(are)e(bidirectional)h(in)h (nature.)0 2582 y(Additionally)-7 b(,)41 b(ISAKMP)d(allo)n(ws)e(b)r (oth)j(initiator)f(and)g(resp)r(onder)f(to)h(ha)n(v)n(e)f(some)g(con)n (trol)g(during)h(the)g(negotiation)0 2682 y(pro)r(cess.)77 b(While)41 b(ISAKMP)g(is)g(designed)g(to)g(allo)n(w)f(an)h(SA)h (negotiation)e(that)i(includes)f(m)n(ultiple)h(prop)r(osals,)h(the)0 2781 y(initiator)34 b(can)h(main)n(tain)g(some)f(con)n(trol)g(b)n(y)g (only)h(making)f(one)h(prop)r(osal)e(in)j(accordance)d(with)i(the)g (initiator's)g(lo)r(cal)0 2881 y(securit)n(y)i(p)r(olicy)-7 b(.)66 b(Once)37 b(the)h(initiator)f(sends)h(a)f(prop)r(osal)f(con)n (taining)g(more)h(than)h(one)f(prop)r(osal)f(\(whic)n(h)i(are)e(sen)n (t)0 2980 y(in)d(decreasing)f(preference)g(order\),)h(the)g(initiator)g (relinquishes)f(con)n(trol)g(to)g(the)i(resp)r(onder.)52 b(Once)32 b(the)h(resp)r(onder)f(is)0 3080 y(con)n(trolling)21 b(the)j(SA)f(establishmen)n(t,)h(the)g(resp)r(onder)e(can)g(mak)n(e)g (its)i(p)r(olicy)e(tak)n(e)h(precedence)f(o)n(v)n(er)f(the)j(initiator) e(within)0 3180 y(the)30 b(con)n(text)g(of)f(the)i(m)n(ultiple)f (options)f(o\013ered)h(b)n(y)f(the)i(initiator.)43 b(This)30 b(is)f(accomplished)g(b)n(y)h(selecting)f(the)i(prop)r(osal)0 3279 y(b)r(est)d(suited)g(for)f(the)h(resp)r(onder's)e(lo)r(cal)h (securit)n(y)g(p)r(olicy)g(and)h(returning)f(this)h(selection)f(to)g (the)h(initiator.)0 3611 y Fj(2.5)112 b(Miscellaneous)0 3864 y Fe(2.5.1)94 b(T)-8 b(ransp)s(ort)32 b(Proto)s(col)0 4117 y Fk(ISAKMP)24 b(can)h(b)r(e)g(implemen)n(ted)h(o)n(v)n(er)d(an)n (y)h(transp)r(ort)f(proto)r(col)h(or)g(o)n(v)n(er)f(IP)h(itself.)37 b(Implemen)n(tations)24 b(MUST)i(include)0 4217 y(send)h(and)h(receiv)n (e)e(capabilit)n(y)g(for)h(ISAKMP)g(using)g(the)h(User)f(Datagram)f (Proto)r(col)g(\(UDP\))i(on)f(p)r(ort)g(500.)36 b(UDP)27 b(P)n(ort)0 4316 y(500)c(has)h(b)r(een)h(assigned)e(to)h(ISAKMP)g(b)n (y)g(the)h(In)n(ternet)g(Assigned)f(Num)n(b)r(ered)g(Authorit)n(y)g (\(IANA\).)i(Implemen)n(tations)0 4416 y(MA)-7 b(Y)28 b(additionally)f(supp)r(ort)h(ISAKMP)f(o)n(v)n(er)f(other)h(transp)r (ort)f(proto)r(cols)h(or)f(o)n(v)n(er)g(IP)h(itself.)0 4731 y Fe(2.5.2)94 b(RESER)-11 b(VED)31 b(Fields)0 4984 y Fk(The)e(existence)g(of)g(RESER)-9 b(VED)28 b(\014elds)i(within)f (ISAKMP)g(pa)n(yloads)e(are)h(used)h(strictly)g(to)g(preserv)n(e)f(b)n (yte)g(alignmen)n(t.)0 5084 y(All)36 b(RESER)-9 b(VED)36 b(\014elds)f(in)h(the)h(ISAKMP)e(proto)r(col)g(MUST)h(b)r(e)g(set)g(to) g(zero)f(\(0\))h(when)g(a)f(pac)n(k)n(et)g(is)h(issued.)61 b(The)0 5184 y(receiv)n(er)30 b(SHOULD)i(c)n(hec)n(k)f(the)i(RESER)-9 b(VED)31 b(\014elds)h(for)f(a)g(zero)g(\(0\))h(v)-5 b(alue)32 b(and)f(discard)g(the)h(pac)n(k)n(et)f(if)h(other)f(v)-5 b(alues)0 5283 y(are)27 b(found.)0 5656 y(Maughan,)g(Sc)n(hertler,)f (Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(16])p eop %%Page: 17 17 17 16 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fe(2.5.3)94 b(An)m(ti-Clogging)30 b(T)-8 b(ok)m(en)32 b(\(\\Co)s(okie"\))f(Creation)0 643 y Fk(The)26 b(details)h(of)f(co)r(okie)g(generation)f(are)g(implemen)n (tation)h(dep)r(enden)n(t,)i(but)f(MUST)g(satisfy)f(these)g(basic)g (requiremen)n(ts)0 743 y(\(originally)g(stated)i(b)n(y)f(Phil)g(Karn)g (in)h([Karn)o(]\):)131 1025 y Fg(1.)173 b(The)43 b(cookie)e(must)h (depend)f(on)i(the)f(specific)e(parties.)84 b(This)42 b(prevents)392 1125 y(an)h(attacker)d(from)i(obtaining)e(a)j(cookie)e (using)h(a)h(real)f(IP)h(address)d(and)392 1224 y(UDP)j(port,)e(and)h (then)g(using)g(it)h(to)f(swamp)g(the)g(victim)f(with)h(Diffie-)392 1324 y(Hellman)f(requests)f(from)i(randomly)e(chosen)i(IP)g(addresses)e (or)j(ports.)131 1523 y(2.)173 b(It)43 b(must)f(not)g(be)h(possible)d (for)j(anyone)e(other)g(than)h(the)h(issuing)392 1623 y(entity)e(to)i(generate)d(cookies)h(that)h(will)g(be)h(accepted)d(by)j (that)392 1722 y(entity.)85 b(This)41 b(implies)g(that)h(the)g(issuing) f(entity)g(must)h(use)h(local)392 1822 y(secret)e(information)e(in)k (the)g(generation)c(and)j(subsequent)392 1922 y(verification)d(of)k(a)g (cookie.)84 b(It)43 b(must)f(not)g(be)h(possible)d(to)j(deduce)392 2021 y(this)f(secret)f(information)e(from)j(any)h(particular)c(cookie.) 131 2220 y(3.)173 b(The)43 b(cookie)e(generation)e(function)h(must)i (be)h(fast)f(to)h(thwart)e(attacks)392 2320 y(intended)g(to)h(sabotage) f(CPU)h(resources.)0 2602 y Fk(Karn's)30 b(suggested)h(metho)r(d)h(for) f(creating)g(the)h(co)r(okie)e(is)i(to)g(p)r(erform)f(a)g(fast)h(hash)f (\(e.g.)49 b(MD5\))32 b(o)n(v)n(er)e(the)i(IP)f(Source)0 2702 y(and)36 b(Destination)g(Address,)h(the)f(UDP)g(Source)f(and)h (Destination)g(P)n(orts)e(and)i(a)f(lo)r(cally)g(generated)g(secret)g (random)0 2802 y(v)-5 b(alue.)35 b(ISAKMP)23 b(requires)f(that)i(the)f (co)r(okie)g(b)r(e)g(unique)h(for)f(eac)n(h)f(SA)i(establishmen)n(t)f (to)g(help)h(prev)n(en)n(t)e(repla)n(y)g(attac)n(ks,)0 2901 y(therefore,)h(the)f(date)h(and)f(time)h(MUST)f(b)r(e)h(added)f (to)h(the)f(information)g(hashed.)35 b(The)22 b(generated)f(co)r(okies) g(are)h(placed)g(in)0 3001 y(the)f(ISAKMP)f(Header)g(\(describ)r(ed)h (in)g(section)f(3.1\))h(Initiator)f(and)g(Resp)r(onder)g(co)r(okie)g (\014elds.)35 b(These)20 b(\014elds)h(are)f(8)g(o)r(ctets)0 3101 y(in)30 b(length,)g(th)n(us,)f(requiring)f(a)h(generated)g(co)r (okie)f(to)h(b)r(e)h(8)f(o)r(ctets.)42 b(Notify)30 b(and)f(Delete)h (messages)d(\(see)j(sections)e(3.14,)0 3200 y(3.15,)i(and)g(4.8\))g (are)f(uni-directional)g(transmissions)g(and)h(are)g(done)g(under)g (the)h(protection)e(of)i(an)f(existing)f(ISAKMP)0 3300 y(SA,)d(th)n(us,)f(not)g(requiring)f(the)i(generation)d(of)j(a)e(new)h (co)r(okie.)36 b(One)24 b(exception)h(to)g(this)h(is)f(the)g (transmission)f(of)h(a)g(Notify)0 3399 y(message)j(during)h(a)f(Phase)g (1)h(exc)n(hange,)f(prior)g(to)i(completing)f(the)g(establishmen)n(t)g (of)g(an)g(SA.)h(Sections)f(3.14)f(and)h(4.8)0 3499 y(pro)n(vide)d (additional)h(details.)0 3873 y Ff(3)137 b(ISAKMP)46 b(P)l(a)l(yloads)0 4155 y Fk(ISAKMP)28 b(pa)n(yloads)e(pro)n(vide)h(mo) r(dular)h(building)g(blo)r(c)n(ks)f(for)h(constructing)f(ISAKMP)h (messages.)37 b(The)28 b(presence)f(and)0 4254 y(ordering)f(of)h(pa)n (yloads)e(in)j(ISAKMP)f(is)g(de\014ned)h(b)n(y)f(and)g(dep)r(enden)n(t) h(up)r(on)g(the)g Fb(Exchange)i(T)-6 b(yp)l(e)30 b(Field)f Fk(lo)r(cated)e(in)h(the)0 4354 y(ISAKMP)33 b(Header)g(\(see)h(Figure)f (2\).)55 b(The)34 b(ISAKMP)f(pa)n(yload)f(t)n(yp)r(es)i(are)e (discussed)i(in)g(sections)f(3.4)f(through)h(3.15.)0 4454 y(The)23 b(descriptions)e(of)i(the)g(ISAKMP)f(pa)n(yloads,)g (messages,)g(and)g(exc)n(hanges)f(\(see)i(Section)f(4\))h(are)e(sho)n (wn)h(using)g(net)n(w)n(ork)0 4553 y(o)r(ctet)28 b(ordering.)35 b(Additionally)-7 b(,)28 b(all)f(ISAKMP)g(messages)f(MUST)i(b)r(e)g (aligned)f(at)h(4-o)r(ctet)f(m)n(ultiples.)0 4885 y Fj(3.1)112 b(ISAKMP)37 b(Header)h(F)-9 b(ormat)0 5138 y Fk(An)40 b(ISAKMP)g(message)e(has)h(a)h(\014xed)g(header)f(format,)j(sho)n(wn)d (in)h(Figure)f(2,)k(follo)n(w)n(ed)c(b)n(y)g(a)h(v)-5 b(ariable)39 b(n)n(um)n(b)r(er)g(of)0 5238 y(pa)n(yloads.)49 b(A)33 b(\014xed)f(header)f(simpli\014es)i(parsing,)f(pro)n(viding)f (the)h(b)r(ene\014t)h(of)f(proto)r(col)f(parsing)g(soft)n(w)n(are)g (that)h(is)h(less)0 5337 y(complex)g(and)g(easier)f(to)i(implemen)n(t.) 55 b(The)33 b(\014xed)h(header)e(con)n(tains)h(the)h(information)e (required)h(b)n(y)g(the)h(proto)r(col)e(to)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(17])p eop %%Page: 18 18 18 17 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)1133 b(Initiator)1216 b(!)349 839 y(!)k(Cookie)1261 b(!)349 939 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)349 1039 y(!)1133 b(Responder)1216 b(!)349 1138 y(!)k(Cookie)1261 b(!)349 1238 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)349 1338 y(!)86 b(Next)42 b(Payload)f(!)i(MjVer)f(!)h(MnVer)e(!)j (Exchange)c(Type)i(!)217 b(Flags)f(!)349 1437 y(+-+-+-+-+-+-+-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 1537 y(!)1133 b(Message)40 b(ID)1176 b(!)349 1636 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 1736 y(!)1220 b(Length)1261 b(!)349 1836 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)1313 2101 y Fk(Figure)27 b(2:)36 b(ISAKMP)27 b(Header)g(F)-7 b(ormat)0 2367 y(main)n(tain)27 b(state,)h(pro)r(cess)e(pa)n(yloads)g (and)h(p)r(ossibly)h(prev)n(en)n(t)e(denial)i(of)f(service)g(or)f (repla)n(y)h(attac)n(ks.)0 2566 y(The)h(ISAKMP)f(Header)g(\014elds)g (are)g(de\014ned)h(as)f(follo)n(ws:)125 2832 y Fc(\017)41 b Fk(Initiator)29 b(Co)r(okie)h(\(8)g(o)r(ctets\))h(-)f(Co)r(okie)f(of) h(en)n(tit)n(y)h(that)f(initiated)h(SA)g(establishmen)n(t,)g(SA)g (noti\014cation,)f(or)g(SA)208 2931 y(deletion.)125 3097 y Fc(\017)41 b Fk(Resp)r(onder)25 b(Co)r(okie)h(\(8)g(o)r(ctets\))h(-)f (Co)r(okie)g(of)g(en)n(tit)n(y)g(that)h(is)f(resp)r(onding)g(to)g(an)g (SA)h(establishmen)n(t)g(request,)f(SA)208 3197 y(noti\014cation,)h(or) f(SA)j(deletion.)125 3363 y Fc(\017)41 b Fk(Next)30 b(P)n(a)n(yload)e (\(1)i(o)r(ctet\))h(-)f(Indicates)g(the)h(t)n(yp)r(e)f(of)h(the)f (\014rst)g(pa)n(yload)f(in)i(the)f(message.)44 b(The)30 b(format)g(for)g(eac)n(h)208 3462 y(pa)n(yload)23 b(is)i(de\014ned)h (in)f(sections)g(3.4)f(through)h(3.16.)35 b(The)25 b(pro)r(cessing)f (for)g(the)i(pa)n(yloads)d(is)j(de\014ned)f(in)h(section)e(5.)1484 3673 y(Next)k(P)n(a)n(yload)e(T)n(yp)r(e)280 b(V)-7 b(alue)p 1318 3706 1472 4 v 1368 3776 a(NONE)939 b(0)1368 3875 y(Securit)n(y)27 b(Asso)r(ciation)g(\(SA\))260 b(1)1368 3975 y(Prop)r(osal)26 b(\(P\))732 b(2)1368 4075 y(T)-7 b(ransform)26 b(\(T\))673 b(3)1368 4174 y(Key)27 b(Exc)n(hange)f (\(KE\))465 b(4)1368 4274 y(Iden)n(ti\014cation)27 b(\(ID\))535 b(5)1368 4374 y(Certi\014cate)27 b(\(CER)-7 b(T\))498 b(6)1368 4473 y(Certi\014cate)27 b(Request)h(\(CR\))290 b(7)1368 4573 y(Hash)27 b(\(HASH\))693 b(8)1368 4672 y(Signature)27 b(\(SIG\))620 b(9)1368 4772 y(Nonce)27 b(\(NONCE\))557 b(10)1368 4872 y(Noti\014cation)27 b(\(N\))598 b(11)1368 4971 y(Delete)28 b(\(D\))794 b(12)1368 5071 y(V)-7 b(endor)27 b(ID)h(\(VID\))552 b(13)1368 5171 y(RESER)-9 b(VED)619 b(14)27 b(-)g(127)1368 5270 y(Priv)-5 b(ate)27 b(USE)584 b(128)27 b(-)g(255)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(18])p eop %%Page: 19 19 19 18 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y Fc(\017)41 b Fk(Ma)5 b(jor)24 b(V)-7 b(ersion)26 b(\(4)g(bits\))h(-)e(indicates)h(the)h(ma)5 b(jor)25 b(v)n(ersion)f(of)i(the)h(ISAKMP)f(proto)r(col)f(in)h(use.)36 b(Implemen)n(tations)208 490 y(based)31 b(on)i(this)f(v)n(ersion)f(of)i (the)f(ISAKMP)g(In)n(ternet-Draft)h(MUST)g(set)f(the)h(Ma)5 b(jor)31 b(V)-7 b(ersion)32 b(to)g(1.)51 b(Implemen-)208 589 y(tations)36 b(based)h(on)g(previous)f(v)n(ersions)g(of)h(ISAKMP)g (In)n(ternet-Drafts)g(MUST)h(set)f(the)h(Ma)5 b(jor)36 b(V)-7 b(ersion)36 b(to)h(0.)208 689 y(Implemen)n(tations)27 b(SHOULD)h(nev)n(er)f(accept)g(pac)n(k)n(ets)f(with)i(a)g(ma)5 b(jor)26 b(v)n(ersion)g(n)n(um)n(b)r(er)h(larger)f(than)i(its)g(o)n (wn.)125 855 y Fc(\017)41 b Fk(Minor)25 b(V)-7 b(ersion)26 b(\(4)g(bits\))i(-)e(indicates)g(the)h(minor)f(v)n(ersion)f(of)h(the)h (ISAKMP)f(proto)r(col)f(in)i(use.)36 b(Implemen)n(tations)208 955 y(based)c(on)g(this)h(v)n(ersion)e(of)h(the)h(ISAKMP)f(In)n (ternet-Draft)h(MUST)g(set)f(the)h(Minor)f(V)-7 b(ersion)32 b(to)g(0.)52 b(Implemen-)208 1054 y(tations)37 b(based)g(on)g(previous) f(v)n(ersions)g(of)h(ISAKMP)g(In)n(ternet-Drafts)g(MUST)h(set)g(the)f (Minor)g(V)-7 b(ersion)37 b(to)g(1.)208 1154 y(Implemen)n(tations)f (SHOULD)g(nev)n(er)g(accept)g(pac)n(k)n(ets)f(with)h(a)g(minor)g(v)n (ersion)f(n)n(um)n(b)r(er)h(larger)e(than)i(its)h(o)n(wn,)208 1254 y(giv)n(en)26 b(the)i(ma)5 b(jor)27 b(v)n(ersion)f(n)n(um)n(b)r (ers)h(are)f(iden)n(tical.)125 1420 y Fc(\017)41 b Fk(Exc)n(hange)27 b(T)n(yp)r(e)j(\(1)g(o)r(ctet\))g(-)f(indicates)h(the)g(t)n(yp)r(e)g (of)f(exc)n(hange)g(b)r(eing)g(used.)44 b(This)29 b(dictates)h(the)g (message)e(and)208 1519 y(pa)n(yload)e(orderings)f(in)j(the)g(ISAKMP)f (exc)n(hanges.)1578 1730 y(Exc)n(hange)f(T)n(yp)r(e)244 b(V)-7 b(alue)p 1427 1763 1254 4 v 1477 1833 a(NONE)742 b(0)1477 1932 y(Base)817 b(1)1477 2032 y(Iden)n(tit)n(y)27 b(Protection)294 b(2)1477 2132 y(Authen)n(tication)28 b(Only)238 b(3)1477 2231 y(Aggressiv)n(e)604 b(4)1477 2331 y(Informational)493 b(5)1477 2430 y(ISAKMP)27 b(F)-7 b(uture)28 b(Use)141 b(6)27 b(-)g(31)1477 2530 y(DOI)g(Sp)r(eci\014c)h (Use)244 b(32)27 b(-)g(255)125 2747 y Fc(\017)41 b Fk(Flags)33 b(\(1)h(o)r(ctet\))h(-)g(indicates)f(sp)r(eci\014c)g(options)g(that)h (are)f(set)g(for)g(the)h(ISAKMP)f(exc)n(hange.)56 b(The)34 b(\015ags)g(listed)208 2846 y(b)r(elo)n(w)28 b(are)g(sp)r(eci\014ed)g (in)h(the)g(Flags)f(\014eld)h(b)r(eginning)g(with)g(the)g(least)f (signi\014can)n(t)g(bit,)h(i.e)g(the)g(Encryption)f(bit)h(is)208 2946 y(bit)g(0)g(of)f(the)i(Flags)e(\014eld,)h(the)h(Commit)f(bit)g(is) g(bit)h(1)e(of)h(the)g(Flags)f(\014eld,)i(and)f(the)g(Authen)n (tication)g(Only)g(bit)g(is)208 3046 y(bit)f(2)f(of)g(the)h(Flags)f (\014eld.)37 b(The)27 b(remaining)g(bits)h(of)f(the)h(Flags)f(\014eld)h (MUST)g(b)r(e)g(set)f(to)g(0)h(prior)e(to)h(transmission.)301 3228 y Fe({)41 b Fk(E\(ncryption)34 b(Bit\))h(\(1)f(bit\))h(-)f(If)g (set)h(\(1\),)h(all)e(pa)n(yloads)e(follo)n(wing)h(the)i(header)f(are)f (encrypted)h(using)g(the)390 3328 y(encryption)19 b(algorithm)g(iden)n (ti\014ed)h(in)g(the)g(ISAKMP)f(SA.)i(The)e(ISAKMP)h(SA)g(Iden)n (ti\014er)f(is)h(the)g(com)n(bination)390 3428 y(of)j(the)h(initiator)f (and)g(resp)r(onder)f(co)r(okie.)35 b(It)23 b(is)h(RECOMMENDED)e(that)i (encryption)f(of)g(comm)n(unications)390 3527 y(b)r(e)31 b(done)f(as)g(so)r(on)g(as)g(p)r(ossible)g(b)r(et)n(w)n(een)h(the)g(p)r (eers.)45 b(F)-7 b(or)30 b(all)g(ISAKMP)g(exc)n(hanges)f(describ)r(ed)i (in)f(section)390 3627 y(4.1,)i(the)h(encryption)e(SHOULD)h(b)r(egin)g (after)g(b)r(oth)g(parties)f(ha)n(v)n(e)g(exc)n(hanged)g(Key)g(Exc)n (hange)f(pa)n(yloads.)390 3726 y(If)e(the)g(E\(ncryption)f(Bit\))h(is)g (not)f(set)h(\(0\),)g(the)g(pa)n(yloads)e(are)g(not)i(encrypted.)301 3859 y Fe({)41 b Fk(C\(ommit)c(Bit\))g(\(1)f(bit\))h(-)f(This)g(bit)h (is)f(used)g(to)g(signal)f(k)n(ey)h(exc)n(hange)f(sync)n(hronization.) 60 b(It)37 b(is)f(used)g(to)390 3959 y(ensure)28 b(that)g(encrypted)g (material)f(is)g(not)h(receiv)n(ed)f(prior)g(to)h(completion)g(of)f (the)i(SA)f(establishmen)n(t.)38 b(The)390 4058 y(Commit)31 b(Bit)f(can)h(b)r(e)f(set)h(\(at)f(an)n(ytime\))h(b)n(y)f(either)g (part)n(y)f(participating)h(in)h(the)f(SA)h(establishmen)n(t,)g(and)390 4158 y(can)c(b)r(e)h(used)f(during)f(b)r(oth)i(phases)e(of)h(an)g (ISAKMP)g(SA)h(establishmen)n(t.)36 b(Ho)n(w)n(ev)n(er,)25 b(the)j(v)-5 b(alue)27 b(MUST)h(b)r(e)390 4258 y(reset)d(after)g(the)h (Phase)e(1)h(negotiation.)35 b(If)25 b(set\(1\),)h(the)g(en)n(tit)n(y)f (whic)n(h)g(did)h(not)f(set)h(the)f(Commit)h(Bit)g(MUST)390 4357 y(w)n(ait)g(for)g(an)g(Informational)f(Exc)n(hange)g(con)n (taining)g(a)h(Notify)h(pa)n(yload)e(\(with)i(the)g(CONNECTED)f(Notify) 390 4457 y(Message\))21 b(from)g(the)h(en)n(tit)n(y)g(whic)n(h)g(set)f (the)i(Commit)f(Bit.)35 b(This)22 b(indicates)f(that)h(the)g(SA)h (establishmen)n(t)e(w)n(as)390 4557 y(successful)h(and)g(either)h(en)n (tit)n(y)f(can)g(no)n(w)g(pro)r(ceed)f(with)i(encrypted)f(tra\016c)g (comm)n(unication.)34 b(In)23 b(addition)f(to)390 4656 y(sync)n(hronizing)j(k)n(ey)h(exc)n(hange,)f(the)i(Commit)g(Bit)f(can)g (b)r(e)h(used)g(to)f(protect)g(against)g(loss)f(of)i(transmissions)390 4756 y(o)n(v)n(er)f(unreliable)h(net)n(w)n(orks)f(and)h(guard)g (against)f(the)i(need)g(for)f(m)n(ultiple)h(retransmissions.)390 4872 y Fg(NOTE:)17 b Fk(It)j(is)f(alw)n(a)n(ys)f(p)r(ossible)h(that)g (the)h(\014nal)f(message)f(of)h(an)g(exc)n(hange)f(can)h(b)r(e)g(lost.) 34 b(In)20 b(this)f(case,)h(the)g(en)n(tit)n(y)390 4972 y(exp)r(ecting)31 b(to)f(receiv)n(e)f(the)h(\014nal)h(message)e(of)h (an)g(exc)n(hange)f(w)n(ould)h(receiv)n(e)f(the)h(Phase)f(2)h(SA)h (negotiation)390 5071 y(message)21 b(follo)n(wing)g(a)h(Phase)g(1)g (exc)n(hange)f(or)g(encrypted)h(tra\016c)g(follo)n(wing)f(a)h(Phase)g (2)g(exc)n(hange.)33 b(Handling)390 5171 y(of)38 b(this)h(situation)f (is)g(not)g(standardized,)i(but)f(w)n(e)f(prop)r(ose)f(the)i(follo)n (wing)e(p)r(ossibilities.)69 b(If)38 b(the)h(en)n(tit)n(y)390 5271 y(a)n(w)n(aiting)22 b(the)i(Informational)e(Exc)n(hange)f(can)i(v) n(erify)g(the)g(receiv)n(ed)g(message)e(\(i.e.)36 b(Phase)22 b(2)h(SA)h(negotiation)390 5370 y(message)38 b(or)h(encrypted)g (tra\016c\),)j(then)e(they)g(MA)-7 b(Y)40 b(consider)f(the)h(SA)g(w)n (as)e(established)h(and)h(con)n(tin)n(ue)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(19])p eop %%Page: 20 20 20 19 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)390 390 y(pro)r(cessing.)35 b(The)27 b(other)f(option)g(is)g(to)h(retransmit)f(the)h(last)f(ISAKMP) g(message)f(to)h(force)g(the)h(other)f(en)n(tit)n(y)390 490 y(to)k(retransmit)f(the)i(\014nal)f(message.)42 b(This)30 b(suggests)f(that)h(implemen)n(tations)g(ma)n(y)g(consider)e(retaining) i(the)390 589 y(last)d(message)g(\(lo)r(cally\))g(un)n(til)h(they)g (are)f(sure)g(the)h(SA)g(is)f(established.)301 709 y Fe({)41 b Fk(A\(uthen)n(tication)28 b(Only)f(Bit\))h(\(1)f(bit\))h(-)f (This)h(bit)f(is)h(in)n(tended)f(for)g(use)g(with)h(the)g (Informational)e(Exc)n(hange)390 809 y(with)h(a)e(Notify)i(pa)n(yload)e (and)g(will)i(allo)n(w)e(the)h(transmission)f(of)h(information)f(with)i (in)n(tegrit)n(y)e(c)n(hec)n(king,)g(but)390 908 y(no)c(encryption)f (\(e.g.)34 b("emergency)19 b(mo)r(de"\).)35 b(Section)20 b(4.8)g(states)g(that)h(a)g(Phase)e(2)h(Informational)g(Exc)n(hange)390 1008 y(MUST)26 b(b)r(e)g(sen)n(t)f(under)g(the)g(protection)g(of)g(an)g (ISAKMP)g(SA.)h(This)f(is)g(the)h(only)f(exception)f(to)i(that)f(p)r (olicy)-7 b(.)390 1107 y(If)30 b(the)g(Authen)n(tication)f(Only)g(bit)h (is)g(set)f(\(1\),)h(only)f(authen)n(tication)g(securit)n(y)f(services) g(will)i(b)r(e)g(applied)f(to)390 1207 y(the)f(en)n(tire)f(Notify)h(pa) n(yload)e(of)i(the)g(Informational)e(Exc)n(hange)g(and)h(the)h(pa)n (yload)f(will)g(not)h(b)r(e)g(encrypted.)125 1370 y Fc(\017)41 b Fk(Message)d(ID)h(\(4)h(o)r(ctets\))g(-)f(Unique)h(Message)e(Iden)n (ti\014er)h(used)g(to)h(iden)n(tify)g(proto)r(col)e(state)h(during)g (Phase)f(2)208 1469 y(negotiations.)58 b(This)35 b(v)-5 b(alue)35 b(is)f(randomly)g(generated)g(b)n(y)h(the)h(initiator)e(of)h (the)h(Phase)e(2)g(negotiation.)58 b(In)36 b(the)208 1569 y(ev)n(en)n(t)28 b(of)h(sim)n(ultaneous)f(SA)i(establishmen)n(ts)e (\(i.e.)42 b(collisions\),)28 b(the)i(v)-5 b(alue)28 b(of)h(this)h(\014eld)f(will)g(lik)n(ely)g(b)r(e)g(di\013eren)n(t)208 1669 y(b)r(ecause)35 b(they)h(are)e(indep)r(enden)n(tly)j(generated)d (and,)k(th)n(us,)g(t)n(w)n(o)d(securit)n(y)g(asso)r(ciations)e(will)j (progress)e(to)n(w)n(ard)208 1768 y(establishmen)n(t.)66 b(Ho)n(w)n(ev)n(er,)38 b(it)g(is)f(unlik)n(ely)h(there)f(will)h(b)r(e)g (absolute)e(sim)n(ultaneous)h(establishmen)n(ts.)66 b(During)208 1868 y(Phase)26 b(1)h(negotiations,)g(the)h(v)-5 b(alue)27 b(MUST)h(b)r(e)g(set)g(to)f(0.)125 2021 y Fc(\017)41 b Fk(Length)24 b(\(4)h(o)r(ctets\))g(-)g(Length)f(of)h(total)g(message) e(\(header)h(+)h(pa)n(yloads\))e(in)i(o)r(ctets.)36 b(Encryption)24 b(can)g(expand)h(the)208 2120 y(size)i(of)g(an)h(ISAKMP)f(message.)0 2446 y Fj(3.2)112 b(Generic)37 b(P)m(a)m(yload)g(Header)0 2699 y Fk(Eac)n(h)29 b(ISAKMP)g(pa)n(yload)f(de\014ned)i(in)g(sections) g(3.4)e(through)i(3.16)e(b)r(egins)i(with)g(a)f(generic)g(header,)h (sho)n(wn)f(in)h(Figure)0 2799 y(3,)d(whic)n(h)h(pro)n(vides)e(a)h(pa)n (yload)f("c)n(haining")g(capabilit)n(y)h(and)g(clearly)g(de\014nes)g (the)h(b)r(oundaries)f(of)h(a)f(pa)n(yload.)1264 3035 y Fg(1)828 b(2)f(3)392 3135 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9) g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g (7)g(8)g(9)g(0)h(1)349 3234 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+)349 3334 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 3434 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+) 1329 3699 y Fk(Figure)27 b(3:)36 b(Generic)28 b(P)n(a)n(yload)d(Header) 0 3885 y(The)j(Generic)f(P)n(a)n(yload)e(Header)i(\014elds)g(are)g (de\014ned)h(as)f(follo)n(ws:)125 4124 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g (for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4224 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g (message,)f(then)h(this)g(\014eld)g(will)f(b)r(e)h(0.)37 b(This)28 b(\014eld)g(pro)n(vides)e(the)i("c)n(haining")208 4323 y(capabilit)n(y)-7 b(.)125 4476 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n(used,)f(set)h(to)f(0.)125 4629 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h (-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h(curren)n(t)e(pa)n(yload,)i (including)f(the)h(generic)e(pa)n(yload)208 4728 y(header.)0 5055 y Fj(3.3)112 b(Data)38 b(A)m(ttributes)0 5308 y Fk(There)24 b(are)g(sev)n(eral)g(instances)g(within)i(ISAKMP)e(where)h (it)g(is)g(necessary)e(to)i(represen)n(t)f(Data)h(A)n(ttributes.)36 b(An)26 b(example)0 5407 y(of)g(this)g(is)g(the)g(Securit)n(y)g(Asso)r (ciation)f(\(SA\))i(A)n(ttributes)f(con)n(tained)f(in)h(the)g(T)-7 b(ransform)25 b(pa)n(yload)f(\(describ)r(ed)i(in)g(section)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(20])p eop %%Page: 21 21 21 20 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(3.6\).)60 b(These)36 b(Data)f(A)n(ttributes)h(are)f(not)h(an)f(ISAKMP)g(pa)n(yload,)h(but)h (are)d(con)n(tained)h(within)i(ISAKMP)e(pa)n(yloads.)0 490 y(The)k(format)f(of)h(the)h(Data)f(A)n(ttributes)g(pro)n(vides)f (the)h(\015exibilit)n(y)g(for)f(represen)n(tation)g(of)h(man)n(y)f (di\013eren)n(t)h(t)n(yp)r(es)g(of)0 589 y(information.)47 b(There)31 b(can)f(b)r(e)i(m)n(ultiple)g(Data)f(A)n(ttributes)g(within) h(a)f(pa)n(yload.)46 b(The)31 b(length)g(of)g(the)h(Data)f(A)n (ttributes)0 689 y(will)i(either)g(b)r(e)g(4)g(o)r(ctets)g(or)f (de\014ned)i(b)n(y)e(the)i(A)n(ttribute)f(Length)g(\014eld.)54 b(This)32 b(is)h(done)g(using)g(the)g(A)n(ttribute)h(F)-7 b(ormat)0 789 y(bit)31 b(describ)r(ed)f(b)r(elo)n(w.)45 b(Sp)r(eci\014c)31 b(information)e(ab)r(out)i(the)f(attributes)h(for)f (eac)n(h)f(domain)h(will)h(b)r(e)f(describ)r(ed)g(in)h(a)f(DOI)0 888 y(do)r(cumen)n(t,)e(e.g.)36 b(IPSEC)27 b(DOI)h([IPDOI)o(].)1264 1142 y Fg(1)828 b(2)f(3)392 1242 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h (8)f(9)g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5) f(6)g(7)g(8)g(9)g(0)h(1)349 1342 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 1441 y(!A!)304 b(Attribute)39 b(Type)347 b(!)174 b(AF=0)86 b(Attribute)40 b(Length)215 b(!)349 1541 y(!F!)1262 b(!)174 b(AF=1)86 b(Attribute)40 b(Value)259 b(!)349 1641 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-) o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+)349 1740 y(.)827 b(AF=0)86 b(Attribute)40 b(Value)1000 b(.)349 1840 y(.)827 b(AF=1)86 b(Not)42 b(Transmitted)998 b(.)349 1939 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+)o(-+-)o(+)1478 2205 y Fk(Figure)27 b(4:)36 b(Data)28 b(A)n(ttributes)0 2400 y(The)g(Data)f(A)n(ttributes)h (\014elds)g(are)e(de\014ned)i(as)f(follo)n(ws:)125 2665 y Fc(\017)41 b Fk(A)n(ttribute)30 b(T)n(yp)r(e)g(\(2)g(o)r(ctets\))h(-) f(Unique)g(iden)n(ti\014er)g(for)g(eac)n(h)f(t)n(yp)r(e)i(of)f (attribute.)45 b(These)29 b(attributes)i(are)e(de\014ned)208 2765 y(as)d(part)i(of)f(the)h(DOI-sp)r(eci\014c)g(information.)208 2898 y(The)i(most)g(signi\014can)n(t)g(bit,)i(or)d(A)n(ttribute)j(F)-7 b(ormat)29 b(\(AF\),)j(indicates)e(whether)h(the)g(data)f(attributes)g (follo)n(w)g(the)208 2998 y(T)n(yp)r(e/Length/V)-7 b(alue)31 b(\(TL)-9 b(V\))33 b(format)f(or)g(a)g(shortened)g(T)n(yp)r(e/V)-7 b(alue)32 b(\(TV\))h(format.)51 b(If)33 b(the)g(AF)g(bit)h(is)e(a)g (zero)208 3097 y(\(0\),)e(then)g(the)h(Data)e(A)n(ttributes)h(are)f(of) h(the)g(T)n(yp)r(e/Length/V)-7 b(alue)29 b(\(TL)-9 b(V\))30 b(form.)43 b(If)30 b(the)h(AF)f(bit)g(is)g(a)f(one)h(\(1\),)208 3197 y(then)e(the)g(Data)f(A)n(ttributes)h(are)f(of)g(the)h(T)n(yp)r (e/V)-7 b(alue)27 b(form.)125 3363 y Fc(\017)41 b Fk(A)n(ttribute)29 b(Length)g(\(2)f(o)r(ctets\))h(-)g(Length)g(in)g(o)r(ctets)f(of)h(the)g (A)n(ttribute)h(V)-7 b(alue.)40 b(When)30 b(the)f(AF)g(bit)g(is)g(a)f (one)h(\(1\),)208 3462 y(the)f(A)n(ttribute)g(V)-7 b(alue)27 b(is)h(only)f(2)g(o)r(ctets)h(and)f(the)h(A)n(ttribute)g(Length)g (\014eld)g(is)f(not)h(presen)n(t.)125 3629 y Fc(\017)41 b Fk(A)n(ttribute)31 b(V)-7 b(alue)31 b(\(v)-5 b(ariable)31 b(length\))g(-)g(V)-7 b(alue)31 b(of)g(the)h(attribute)f(asso)r(ciated) f(with)h(the)h(DOI-sp)r(eci\014c)e(A)n(ttribute)208 3728 y(T)n(yp)r(e.)36 b(If)26 b(the)g(AF)h(bit)f(is)g(a)f(zero)g(\(0\),)h (this)g(\014eld)g(has)g(a)f(v)-5 b(ariable)25 b(length)h(de\014ned)g(b) n(y)f(the)i(A)n(ttribute)f(Length)g(\014eld.)208 3828 y(If)i(the)g(AF)g(bit)g(is)f(a)h(one)f(\(1\),)h(the)g(A)n(ttribute)g(V) -7 b(alue)27 b(has)g(a)h(length)f(of)h(2)f(o)r(ctets.)0 4160 y Fj(3.4)112 b(Securit)m(y)37 b(Asso)s(ciation)f(P)m(a)m(yload)0 4413 y Fk(The)g(Securit)n(y)f(Asso)r(ciation)f(P)n(a)n(yload)f(is)j (used)f(to)h(negotiate)e(securit)n(y)h(attributes)g(and)h(to)f (indicate)h(the)g(Domain)f(of)0 4512 y(In)n(terpretation)27 b(\(DOI\))h(and)g(Situation)g(under)g(whic)n(h)g(the)g(negotiation)f (is)g(taking)h(place.)37 b(Figure)27 b(5)h(sho)n(ws)e(the)j(format)0 4612 y(of)f(the)g(Securit)n(y)f(Asso)r(ciation)f(pa)n(yload.)0 4811 y(The)i(Securit)n(y)f(Asso)r(ciation)f(P)n(a)n(yload)g(\014elds)h (are)g(de\014ned)h(as)f(follo)n(ws:)125 5077 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g (for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 5176 y(curren)n(t)24 b(pa)n(yload)g(is)i(the)f(last)h(in)f(the)h (message,)f(then)h(this)g(\014eld)g(will)f(b)r(e)h(0.)36 b(This)26 b(\014eld)f(MUST)h(NOT)g(con)n(tain)f(the)208 5276 y(v)-5 b(alues)29 b(for)g(the)g(Prop)r(osal)f(or)g(T)-7 b(ransform)28 b(pa)n(yloads)g(as)h(they)g(are)g(considered)f(part)h(of) g(the)h(securit)n(y)f(asso)r(ciation)208 5376 y(negotiation.)35 b(F)-7 b(or)25 b(example,)h(this)g(\014eld)g(w)n(ould)f(con)n(tain)g (the)h(v)-5 b(alue)26 b("10")e(\(Nonce)h(pa)n(yload\))g(in)h(the)g (\014rst)f(message)0 5656 y(Maughan,)i(Sc)n(hertler,)f(Sc)n(hneider,)i (T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(21])p eop %%Page: 22 22 22 21 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)609 b(Domain)42 b(of)g(Interpretation)82 b(\(DOI\))782 b(!)349 1039 y(+-+-+-+-+-+-+-+)o (-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 1138 y(!)2745 b(!)349 1238 y(~)1176 b(Situation)d(~)349 1338 y(!)2745 b(!)349 1437 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)1240 1703 y Fk(Figure)27 b(5:)37 b(Securit)n(y)27 b(Asso)r(ciation)f(P)n(a)n(yload)208 1942 y(of)35 b(a)g(Base)f(Exc)n (hange)g(\(see)h(Section)g(4.4\))g(and)g(the)h(v)-5 b(alue)35 b("0")f(in)i(the)f(\014rst)g(message)f(of)i(an)f(Iden)n(tit)n(y)g (Protect)208 2042 y(Exc)n(hange)25 b(\(see)j(Section)f(4.5\).)125 2195 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 2348 y Fc(\017)41 b Fk(P)n(a)n(yload)24 b(Length)j(\(2)h(o)r(ctets\))f(-)g(Length)g(in)h(o)r(ctets)f(of)g(the)h (en)n(tire)e(Securit)n(y)h(Asso)r(ciation)g(pa)n(yload,)e(including)j (the)208 2448 y(SA)g(pa)n(yload,)e(all)h(Prop)r(osal)f(pa)n(yloads,)g (and)i(all)f(T)-7 b(ransform)26 b(pa)n(yloads)g(asso)r(ciated)h(with)h (the)g(prop)r(osed)f(Securit)n(y)208 2547 y(Asso)r(ciation.)125 2701 y Fc(\017)41 b Fk(Domain)25 b(of)h(In)n(terpretation)f(\(4)g(o)r (ctets\))i(-)e(Iden)n(ti\014es)h(the)g(DOI)g(\(as)g(describ)r(ed)f(in)h (Section)g(2.1\))f(under)h(whic)n(h)g(this)208 2800 y(negotiation)j(is) i(taking)g(place.)46 b(The)31 b(DOI)g(is)g(a)f(32-bit)g(unsigned)h(in)n (teger.)46 b(A)31 b(DOI)g(v)-5 b(alue)31 b(of)g(0)f(during)h(a)f(Phase) 208 2900 y(1)i(exc)n(hange)f(sp)r(eci\014es)h(a)g(Generic)g(ISAKMP)g (SA)h(whic)n(h)f(can)g(b)r(e)h(used)g(for)f(an)n(y)f(proto)r(col)g (during)h(the)h(Phase)e(2)208 2999 y(exc)n(hange.)37 b(The)29 b(necessary)d(SA)j(A)n(ttributes)g(are)e(de\014ned)i(in)g (A.4.)39 b(A)29 b(DOI)f(v)-5 b(alue)28 b(of)h(1)f(is)g(assigned)f(to)h (the)h(IPsec)208 3099 y(DOI)34 b([IPDOI].)58 b(All)35 b(other)g(DOI)f(v)-5 b(alues)35 b(are)e(reserv)n(ed)g(to)i(IANA)h(for)e (future)h(use.)58 b(IANA)36 b(will)e(not)h(normally)208 3199 y(assign)g(a)i(DOI)g(v)-5 b(alue)37 b(without)g(referencing)f (some)g(public)i(sp)r(eci\014cation,)h(suc)n(h)e(as)f(an)h(In)n(ternet) g(RF)n(C.)g(Other)208 3298 y(DOI's)d(can)g(b)r(e)h(de\014ned)f(using)g (the)h(description)f(in)h(app)r(endix)f(B.)57 b(This)35 b(\014eld)f(MUST)h(b)r(e)g(presen)n(t)f(within)h(the)208 3398 y(Securit)n(y)27 b(Asso)r(ciation)f(pa)n(yload.)125 3551 y Fc(\017)41 b Fk(Situation)27 b(\(v)-5 b(ariable)27 b(length\))h(-)g(A)g(DOI-sp)r(eci\014c)f(\014eld)h(that)g(iden)n (ti\014es)g(the)g(situation)g(under)f(whic)n(h)h(this)g(negoti-)208 3651 y(ation)f(is)h(taking)f(place.)38 b(The)28 b(Situation)g(is)f (used)h(to)g(mak)n(e)f(p)r(olicy)h(decisions)f(regarding)f(the)i (securit)n(y)f(attributes)208 3750 y(b)r(eing)e(negotiated.)36 b(Sp)r(eci\014cs)26 b(for)f(the)h(IETF)f(IP)g(Securit)n(y)h(DOI)f (Situation)h(are)f(detailed)g(in)h([IPDOI].)36 b(This)26 b(\014eld)208 3850 y(MUST)i(b)r(e)g(presen)n(t)f(within)h(the)g (Securit)n(y)f(Asso)r(ciation)g(pa)n(yload.)0 4090 y(The)h(pa)n(yload)e (t)n(yp)r(e)h(for)h(the)g(Securit)n(y)f(Asso)r(ciation)f(P)n(a)n(yload) f(is)j(one)f(\(1\).)0 4416 y Fj(3.5)112 b(Prop)s(osal)37 b(P)m(a)m(yload)0 4669 y Fk(The)g(Prop)r(osal)f(P)n(a)n(yload)f(con)n (tains)h(information)h(used)g(during)g(Securit)n(y)g(Asso)r(ciation)g (negotiation.)65 b(The)38 b(prop)r(osal)0 4769 y(consists)28 b(of)h(securit)n(y)f(mec)n(hanisms,)g(or)g(transforms,)f(to)i(b)r(e)g (used)g(to)g(secure)f(the)h(comm)n(unications)e(c)n(hannel.)40 b(Figure)28 b(6)0 4868 y(sho)n(ws)e(the)i(format)f(of)h(the)g(Prop)r (osal)d(P)n(a)n(yload.)35 b(A)28 b(description)f(of)g(its)h(use)g(can)f (b)r(e)h(found)g(in)g(section)f(4.2.)0 5068 y(The)h(Prop)r(osal)d(P)n (a)n(yload)g(\014elds)j(are)e(de\014ned)i(as)f(follo)n(ws:)125 5308 y Fc(\017)41 b Fk(Next)27 b(P)n(a)n(yload)e(\(1)i(o)r(ctet\))h(-)f (Iden)n(ti\014er)g(for)g(the)g(pa)n(yload)f(t)n(yp)r(e)h(of)h(the)f Fb(next)f Fk(pa)n(yload)g(in)i(the)f(message.)36 b(This)27 b(\014eld)208 5407 y(MUST)32 b(only)g(con)n(tain)f(the)i(v)-5 b(alue)32 b("2")f(or)g("0".)49 b(If)33 b(there)e(are)h(additional)f (Prop)r(osal)f(pa)n(yloads)h(in)h(the)g(message,)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(22])p eop %%Page: 23 23 23 22 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)86 b(Proposal)41 b(#)130 b(!)87 b(Protocol-Id)82 b(!)174 b(SPI)43 b(Size)129 b(!#)43 b(of)f(Transforms!)349 1039 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 1138 y(!)1045 b(SPI)43 b(\(variable\))1085 b(!)349 1238 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)1305 1504 y Fk(Figure)27 b(6:)36 b(Prop)r(osal)26 b(P)n(a)n(yload)f(F)-7 b(ormat)208 1769 y(then)35 b(this)f(\014eld)h (will)g(b)r(e)g(2.)57 b(If)35 b(the)g(curren)n(t)e(Prop)r(osal)g(pa)n (yload)g(is)h(the)h(last)f(within)h(the)g(securit)n(y)f(asso)r(ciation) 208 1868 y(prop)r(osal,)26 b(then)i(this)g(\014eld)g(will)f(b)r(e)h(0.) 125 2035 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g (Un)n(used,)f(set)h(to)f(0.)125 2201 y Fc(\017)41 b Fk(P)n(a)n(yload)23 b(Length)i(\(2)g(o)r(ctets\))h(-)f(Length)g(in)h(o)r(ctets)g(of)f(the)h (en)n(tire)f(Prop)r(osal)e(pa)n(yload,)i(including)g(generic)g(pa)n (yload)208 2300 y(header,)i(the)i(Prop)r(osal)c(pa)n(yload,)i(and)h (all)g(T)-7 b(ransform)27 b(pa)n(yloads)f(asso)r(ciated)h(with)h(this)h (prop)r(osal.)37 b(In)28 b(the)h(ev)n(en)n(t)208 2400 y(there)23 b(are)g(m)n(ultiple)h(prop)r(osals)e(with)j(the)f(same)f (prop)r(osal)f(n)n(um)n(b)r(er)i(\(see)f(section)h(4.2\),)g(the)g(P)n (a)n(yload)d(Length)j(\014eld)208 2499 y(only)j(applies)g(to)g(the)h (curren)n(t)f(Prop)r(osal)f(pa)n(yload)g(and)h(not)h(to)f(all)g(Prop)r (osal)f(pa)n(yloads.)125 2665 y Fc(\017)41 b Fk(Prop)r(osal)29 b(#)k(\(1)f(o)r(ctet\))g(-)g(Iden)n(ti\014es)g(the)g(Prop)r(osal)e(n)n (um)n(b)r(er)i(for)g(the)g(curren)n(t)f(pa)n(yload.)49 b(A)32 b(description)g(of)g(the)208 2765 y(use)27 b(of)h(this)f (\014eld)h(is)g(found)g(in)g(section)f(4.2.)125 2931 y Fc(\017)41 b Fk(Proto)r(col-Id)31 b(\(1)j(o)r(ctet\))g(-)f(Sp)r (eci\014es)h(the)g(proto)r(col)e(iden)n(ti\014er)i(for)f(the)h(curren)n (t)f(negotiation.)54 b(Examples)32 b(migh)n(t)208 3031 y(include)c(IPSEC)e(ESP)-7 b(,)27 b(IPSEC)g(AH,)h(OSPF,)f(TLS,)h(etc.) 125 3197 y Fc(\017)41 b Fk(SPI)25 b(Size)g(\(1)g(o)r(ctet\))h(-)f (Length)g(in)h(o)r(ctets)f(of)g(the)h(SPI)f(as)g(de\014ned)h(b)n(y)f (the)g(Proto)r(col-Id.)34 b(In)26 b(the)g(case)e(of)h(ISAKMP)-7 b(,)208 3296 y(the)26 b(Initiator)f(and)h(Resp)r(onder)g(co)r(okie)f (pair)g(from)h(the)g(ISAKMP)g(Header)f(is)h(the)h(ISAKMP)e(SPI,)h (therefore,)g(the)208 3396 y(SPI)c(Size)h(is)g(irrelev)-5 b(an)n(t)21 b(and)i(MA)-7 b(Y)23 b(b)r(e)h(from)e(zero)g(\(0\))h(to)f (sixteen)h(\(16\).)35 b(If)23 b(the)g(SPI)g(Size)g(is)f(non-zero,)g (the)h(con)n(ten)n(t)208 3496 y(of)h(the)g(SPI)g(\014eld)g(MUST)h(b)r (e)f(ignored.)35 b(If)24 b(the)h(SPI)e(Size)i(is)f(not)g(a)f(m)n (ultiple)i(of)f(4)g(o)r(ctets)g(it)g(will)h(ha)n(v)n(e)d(some)i(impact) 208 3595 y(on)e(the)i(SPI)e(\014eld)i(and)f(the)g(alignmen)n(t)g(of)g (all)g(pa)n(yloads)e(in)i(the)g(message.)34 b(The)24 b(Domain)e(of)i(In)n(terpretation)d(\(DOI\))208 3695 y(will)27 b(dictate)h(the)g(SPI)f(Size)h(for)f(other)g(proto)r(cols.) 125 3861 y Fc(\017)41 b Fk(#)36 b(of)g(T)-7 b(ransforms)34 b(\(1)i(o)r(ctet\))h(-)f(Sp)r(eci\014es)g(the)h(n)n(um)n(b)r(er)e(of)h (transforms)f(for)h(the)g(Prop)r(osal.)60 b(Eac)n(h)35 b(of)h(these)g(is)208 3961 y(con)n(tained)26 b(in)i(a)g(T)-7 b(ransform)26 b(pa)n(yload.)125 4127 y Fc(\017)41 b Fk(SPI)26 b(\(v)-5 b(ariable\))25 b(-)h(The)h(sending)f(en)n(tit)n(y's)g(SPI.)g (In)g(the)h(ev)n(en)n(t)f(the)g(SPI)g(Size)g(is)h(not)f(a)g(m)n (ultiple)h(of)f(4)g(o)r(ctets,)g(there)208 4226 y(is)h(no)g(padding)h (applied)f(to)h(the)g(pa)n(yload,)e(ho)n(w)n(ev)n(er,)f(it)j(can)f(b)r (e)h(applied)g(at)g(the)g(end)f(of)h(the)g(message.)0 4492 y(The)g(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g(Prop)r(osal)d(P)n(a) n(yload)g(is)j(t)n(w)n(o)e(\(2\).)0 4824 y Fj(3.6)112 b(T)-9 b(ransform)37 b(P)m(a)m(yload)0 5077 y Fk(The)28 b(T)-7 b(ransform)26 b(P)n(a)n(yload)g(con)n(tains)h(information)g (used)h(during)f(Securit)n(y)h(Asso)r(ciation)f(negotiation.)37 b(The)27 b(T)-7 b(ransform)0 5176 y(pa)n(yload)29 b(consists)h(of)h(a)g (sp)r(eci\014c)g(securit)n(y)f(mec)n(hanism,)h(or)f(transforms,)h(to)g (b)r(e)g(used)g(to)g(secure)f(the)h(comm)n(unications)0 5276 y(c)n(hannel.)k(The)23 b(T)-7 b(ransform)22 b(pa)n(yload)f(also)h (con)n(tains)g(the)i(securit)n(y)e(asso)r(ciation)f(attributes)i(asso)r (ciated)f(with)h(the)h(sp)r(eci\014c)0 5656 y(Maughan,)j(Sc)n(hertler,) f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(23])p eop %%Page: 24 24 24 23 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)86 b(Transform)40 b(#)87 b(!)g(Transform-Id)38 b(!)479 b(RESERVED2)d(!)349 1039 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 1138 y(!)2745 b(!)349 1238 y(~)1045 b(SA)43 b(Attributes)1129 b(~)349 1338 y(!)2745 b(!)349 1437 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)1276 1703 y Fk(Figure)27 b(7:)37 b(T)-7 b(ransform)26 b(P)n(a)n(yload)f(F)-7 b(ormat)0 1941 y(transform.)42 b(These)30 b(SA)g(attributes)g(are)f(DOI-sp)r (eci\014c.)43 b(Figure)30 b(7)f(sho)n(ws)g(the)h(format)f(of)h(the)g(T) -7 b(ransform)29 b(P)n(a)n(yload.)41 b(A)0 2041 y(description)27 b(of)h(its)f(use)h(can)f(b)r(e)h(found)g(in)g(section)f(4.2.)0 2240 y(The)h(T)-7 b(ransform)26 b(P)n(a)n(yload)f(\014elds)j(are)e (de\014ned)i(as)f(follo)n(ws:)125 2479 y Fc(\017)41 b Fk(Next)27 b(P)n(a)n(yload)e(\(1)i(o)r(ctet\))h(-)f(Iden)n(ti\014er)g (for)g(the)g(pa)n(yload)f(t)n(yp)r(e)h(of)h(the)f Fb(next)f Fk(pa)n(yload)g(in)i(the)f(message.)36 b(This)27 b(\014eld)208 2578 y(MUST)h(only)g(con)n(tain)f(the)i(v)-5 b(alue)28 b("3")e(or)i("0".)37 b(If)28 b(there)g(are)f(additional)h(T)-7 b(ransform)26 b(pa)n(yloads)h(in)h(the)h(prop)r(osal,)208 2678 y(then)j(this)h(\014eld)g(will)g(b)r(e)f(3.)51 b(If)33 b(the)g(curren)n(t)f(T)-7 b(ransform)31 b(pa)n(yload)f(is)j(the)g(last) f(within)h(the)g(prop)r(osal,)f(then)h(this)208 2778 y(\014eld)27 b(will)h(b)r(e)g(0.)125 2930 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n(used,)f(set)h(to)f (0.)125 3083 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r (ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h(curren)n(t)e(pa)n (yload,)i(including)f(the)h(generic)e(pa)n(yload)208 3182 y(header,)26 b(T)-7 b(ransform)27 b(v)-5 b(alues,)27 b(and)g(all)h(SA)g(A)n(ttributes.)125 3335 y Fc(\017)41 b Fk(T)-7 b(ransform)33 b(#)i(\(1)g(o)r(ctet\))h(-)e(Iden)n(ti\014es)h (the)h(T)-7 b(ransform)33 b(n)n(um)n(b)r(er)i(for)f(the)i(curren)n(t)e (pa)n(yload.)57 b(If)35 b(there)g(is)g(more)208 3434 y(than)25 b(one)g(transform)g(prop)r(osed)f(for)h(a)g(sp)r(eci\014c)h (proto)r(col)f(within)h(the)g(Prop)r(osal)d(pa)n(yload,)i(then)h(eac)n (h)e(T)-7 b(ransform)208 3534 y(pa)n(yload)26 b(has)h(a)g(unique)h(T)-7 b(ransform)26 b(n)n(um)n(b)r(er.)36 b(A)28 b(description)f(of)h(the)g (use)f(of)h(this)g(\014eld)g(is)f(found)h(in)g(section)f(4.2.)125 3687 y Fc(\017)41 b Fk(T)-7 b(ransform-Id)21 b(\(1)j(o)r(ctet\))g(-)f (Sp)r(eci\014es)h(the)g(T)-7 b(ransform)22 b(iden)n(ti\014er)h(for)g (the)h(proto)r(col)f(within)h(the)g(curren)n(t)f(prop)r(osal.)208 3786 y(These)k(transforms)f(are)h(de\014ned)h(b)n(y)f(the)h(DOI)g(and)f (are)g(dep)r(enden)n(t)h(on)f(the)h(proto)r(col)f(b)r(eing)g (negotiated.)125 3939 y Fc(\017)41 b Fk(RESER)-9 b(VED2)26 b(\(2)i(o)r(ctets\))f(-)h(Un)n(used,)f(set)h(to)g(0.)125 4091 y Fc(\017)41 b Fk(SA)30 b(A)n(ttributes)g(\(v)-5 b(ariable)28 b(length\))i(-)g(This)f(\014eld)h(con)n(tains)f(the)h (securit)n(y)e(asso)r(ciation)g(attributes)i(as)f(de\014ned)h(for)208 4191 y(the)38 b(transform)g(giv)n(en)f(in)i(the)g(T)-7 b(ransform-Id)37 b(\014eld.)69 b(The)39 b(SA)g(A)n(ttributes)f(SHOULD)h (b)r(e)g(represen)n(ted)e(using)208 4291 y(the)32 b(Data)h(A)n (ttributes)f(format)g(describ)r(ed)g(in)h(section)f(3.3.)50 b(If)33 b(the)g(SA)g(A)n(ttributes)f(are)g(not)g(aligned)g(on)g(4-b)n (yte)208 4390 y(b)r(oundaries,)25 b(then)h(subsequen)n(t)f(pa)n(yloads) f(will)i(not)g(b)r(e)g(aligned)f(and)h(an)n(y)f(padding)g(will)h(b)r(e) g(added)g(at)f(the)h(end)g(of)208 4490 y(the)i(message)e(to)h(mak)n(e)g (the)h(message)e(4-o)r(ctet)h(aligned.)0 4728 y(The)h(pa)n(yload)e(t)n (yp)r(e)h(for)h(the)g(T)-7 b(ransform)26 b(P)n(a)n(yload)f(is)i(three)h (\(3\).)0 5055 y Fj(3.7)112 b(Key)38 b(Exc)m(hange)g(P)m(a)m(yload)0 5308 y Fk(The)f(Key)f(Exc)n(hange)f(P)n(a)n(yload)g(supp)r(orts)h(a)h (v)-5 b(ariet)n(y)36 b(of)g(k)n(ey)h(exc)n(hange)e(tec)n(hniques.)65 b(Example)36 b(k)n(ey)g(exc)n(hanges)f(are)0 5407 y(Oakley)26 b([Oakley)o(],)i(Di\016e-Hellman,)g(the)g(enhanced)f(Di\016e-Hellman)h (k)n(ey)f(exc)n(hange)f(describ)r(ed)h(in)h(X9.42)f([ANSI],)h(and)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(24])p eop %%Page: 25 25 25 24 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(the)h(RSA-based)f(k)n(ey)g(exc)n (hange)f(used)i(b)n(y)f(PGP)-7 b(.)27 b(Figure)g(8)g(sho)n(ws)g(the)h (format)f(of)g(the)h(Key)f(Exc)n(hange)f(pa)n(yload.)1264 640 y Fg(1)828 b(2)f(3)392 739 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f (9)g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6) g(7)g(8)g(9)g(0)h(1)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+)349 939 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 1038 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 1138 y(!)2745 b(!)349 1237 y(~)1002 b(Key)42 b(Exchange)e(Data)1001 b(~)349 1337 y(!)2745 b(!)349 1437 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)1204 1702 y Fk(Figure)27 b(8:)36 b(Key)27 b(Exc)n(hange)f(P)n(a)n(yload)f(F)-7 b(ormat)0 1902 y(The)28 b(Key)f(Exc)n(hange)e(P)n(a)n(yload)g(\014elds)j(are)f (de\014ned)h(as)f(follo)n(ws:)125 2167 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g (for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 2267 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g (message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 2433 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 2599 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 2699 y(header.)125 2865 y Fc(\017)41 b Fk(Key)33 b(Exc)n(hange)e(Data)j (\(v)-5 b(ariable)33 b(length\))h(-)g(Data)f(required)g(to)g(generate)g (a)g(session)g(k)n(ey)-7 b(.)54 b(The)34 b(in)n(terpretation)208 2964 y(of)29 b(this)h(data)f(is)h(sp)r(eci\014ed)g(b)n(y)f(the)h(DOI)g (and)f(the)h(asso)r(ciated)e(Key)h(Exc)n(hange)f(algorithm.)42 b(This)29 b(\014eld)h(ma)n(y)f(also)208 3064 y(con)n(tain)d(pre-placed) h(k)n(ey)g(indicators.)0 3330 y(The)h(pa)n(yload)e(t)n(yp)r(e)h(for)h (the)g(Key)e(Exc)n(hange)g(P)n(a)n(yload)f(is)j(four)f(\(4\).)0 3662 y Fj(3.8)112 b(Iden)m(ti\014cation)36 b(P)m(a)m(yload)0 3915 y Fk(The)h(Iden)n(ti\014cation)g(P)n(a)n(yload)e(con)n(tains)h (DOI-sp)r(eci\014c)h(data)g(used)g(to)g(exc)n(hange)f(iden)n (ti\014cation)h(information.)65 b(This)0 4014 y(information)27 b(is)g(used)g(for)g(determining)g(the)g(iden)n(tities)h(of)f(comm)n (unicating)f(p)r(eers)h(and)g(ma)n(y)g(b)r(e)g(used)h(for)e (determining)0 4114 y(authen)n(ticit)n(y)i(of)f(information.)36 b(Figure)27 b(9)g(sho)n(ws)g(the)h(format)f(of)h(the)g(Iden)n (ti\014cation)f(P)n(a)n(yload.)0 4313 y(The)h(Iden)n(ti\014cation)f(P)n (a)n(yload)e(\014elds)j(are)e(de\014ned)i(as)f(follo)n(ws:)125 4579 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f (Iden)n(ti\014er)g(for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4678 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h (the)g(message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 4844 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 5010 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 5110 y(header.)125 5276 y Fc(\017)41 b Fk(ID)28 b(T)n(yp)r(e)f(\(1)h(o) r(ctet\))g(-)f(Sp)r(eci\014es)h(the)g(t)n(yp)r(e)g(of)f(Iden)n (ti\014cation)h(b)r(eing)f(used.)37 b(This)28 b(\014eld)g(is)f(DOI-dep) r(enden)n(t.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(25])p eop %%Page: 26 26 26 25 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)130 b(ID)43 b(Type)216 b(!)566 b(DOI)43 b(Specific)d(ID)j(Data)608 b(!)349 1039 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)349 1138 y(!)2745 b(!)349 1238 y(~)827 b(Identification)38 b(Data)1088 b(~)349 1338 y(!)2745 b(!)349 1437 y(+-+-+-+-+-+-+-+)o(-+-) o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)1224 1703 y Fk(Figure)27 b(9:)36 b(Iden)n(ti\014cation)28 b(P)n(a)n(yload)d(F)-7 b(ormat)125 1968 y Fc(\017)41 b Fk(DOI)27 b(Sp)r(eci\014c)i(ID)f(Data)g (\(3)g(o)r(ctets\))g(-)f(Con)n(tains)g(DOI)h(sp)r(eci\014c)g(Iden)n (ti\014cation)g(data.)37 b(If)28 b(un)n(used,)g(then)h(this)f(\014eld) 208 2068 y(MUST)g(b)r(e)g(set)f(to)h(0.)125 2234 y Fc(\017)41 b Fk(Iden)n(ti\014cation)23 b(Data)g(\(v)-5 b(ariable)23 b(length\))h(-)f(Con)n(tains)f(iden)n(tit)n(y)i(information.)35 b(The)23 b(v)-5 b(alues)23 b(for)g(this)h(\014eld)g(are)e(DOI-)208 2333 y(sp)r(eci\014c)i(and)g(the)h(format)f(is)h(sp)r(eci\014ed)f(b)n (y)h(the)f(ID)h(T)n(yp)r(e)g(\014eld.)36 b(Sp)r(eci\014c)25 b(details)f(for)g(the)h(IETF)f(IP)g(Securit)n(y)g(DOI)208 2433 y(Iden)n(ti\014cation)j(Data)g(are)g(detailed)h(in)f([IPDOI].)0 2699 y(The)h(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g(Iden)n(ti\014cation) f(P)n(a)n(yload)e(is)i(\014v)n(e)h(\(5\).)0 3031 y Fj(3.9)112 b(Certi\014cate)37 b(P)m(a)m(yload)0 3284 y Fk(The)c(Certi\014cate)g(P) n(a)n(yload)e(pro)n(vides)h(a)h(means)g(to)g(transp)r(ort)f (certi\014cates)h(or)f(other)h(certi\014cate-related)f(information)0 3383 y(via)40 b(ISAKMP)g(and)g(can)g(app)r(ear)f(in)i(an)n(y)e(ISAKMP)h (message.)74 b(Certi\014cate)40 b(pa)n(yloads)e(SHOULD)j(b)r(e)g (included)g(in)0 3483 y(an)36 b(exc)n(hange)e(whenev)n(er)h(an)h (appropriate)e(directory)h(service)g(\(e.g.)62 b(Secure)36 b(DNS)h([DNSSEC]\))g(is)e(not)h(a)n(v)-5 b(ailable)35 b(to)0 3582 y(distribute)27 b(certi\014cates.)35 b(The)27 b(Certi\014cate)f(pa)n(yload)f(MUST)i(b)r(e)g(accepted)f(at)g(an)n(y)g (p)r(oin)n(t)g(during)g(an)h(exc)n(hange.)35 b(Figure)0 3682 y(10)27 b(sho)n(ws)f(the)i(format)f(of)h(the)g(Certi\014cate)f(P)n (a)n(yload.)0 3881 y Fg(NOTE:)h Fk(Certi\014cate)h(t)n(yp)r(es)h(and)f (formats)g(are)g(not)h(generally)e(b)r(ound)i(to)g(a)f(DOI)h(-)g(it)g (is)g(exp)r(ected)g(that)g(there)f(will)h(only)0 3981 y(b)r(e)e(a)f(few)h(certi\014cate)f(t)n(yp)r(es,)h(and)f(that)h(most)f (DOIs)h(will)g(accept)f(all)g(of)h(these)f(t)n(yp)r(es.)0 4180 y(The)h(Certi\014cate)f(P)n(a)n(yload)e(\014elds)j(are)e (de\014ned)i(as)f(follo)n(ws:)125 4446 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g (for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4546 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g (message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 4712 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 4878 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(26])p eop %%Page: 27 27 27 26 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)43 b(Cert)f(Encoding)e(!)2048 b(!)349 1039 y(+-+-+-+-+-+-+-+)o(-+)2042 b(!)349 1138 y(~)1002 b(Certificate)39 b(Data)1044 b(~)349 1238 y(!)2745 b(!)349 1338 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)1254 1603 y Fk(Figure)27 b(10:)36 b(Certi\014cate)27 b(P)n(a)n(yload)e(F)-7 b(ormat)208 1868 y(header.)125 2035 y Fc(\017)41 b Fk(Certi\014cate)29 b(Enco)r(ding)h(\(1)g(o)r (ctet\))h(-)f(This)g(\014eld)h(indicates)f(the)h(t)n(yp)r(e)f(of)h (certi\014cate)f(or)f(certi\014cate-related)g(infor-)208 2134 y(mation)e(con)n(tained)g(in)h(the)g(Certi\014cate)f(Data)g (\014eld.)1548 2328 y(Certi\014cate)g(T)n(yp)r(e)523 b(V)-7 b(alue)p 1134 2362 1841 4 v 1183 2431 a(NONE)1315 b(0)1183 2531 y(PK)n(CS)27 b(#7)g(wrapp)r(ed)g(X.509)g(certi\014cate) 251 b(1)1183 2631 y(PGP)27 b(Certi\014cate)990 b(2)1183 2730 y(DNS)29 b(Signed)e(Key)962 b(3)1183 2830 y(X.509)27 b(Certi\014cate)g(-)g(Signature)529 b(4)1183 2929 y(X.509)27 b(Certi\014cate)g(-)g(Key)g(Exc)n(hange)354 b(5)1183 3029 y(Kerb)r(eros)26 b(T)-7 b(ok)n(ens)968 b(6)1183 3129 y(Certi\014cate)27 b(Rev)n(o)r(cation)g(List)g(\(CRL\))332 b(7)1183 3228 y(Authorit)n(y)28 b(Rev)n(o)r(cation)e(List)i(\(ARL\))350 b(8)1183 3328 y(SPKI)27 b(Certi\014cate)971 b(9)1183 3428 y(X.509)27 b(Certi\014cate)g(-)g(A)n(ttribute)514 b(10)1183 3527 y(RESER)-9 b(VED)996 b(11)26 b(-)i(255)125 3844 y Fc(\017)41 b Fk(Certi\014cate)d(Data)h(\(v)-5 b(ariable)39 b(length\))h(-)f(Actual)g(enco)r(ding)g(of)g (certi\014cate)g(data.)71 b(The)40 b(t)n(yp)r(e)f(of)g(certi\014cate)g (is)208 3943 y(indicated)27 b(b)n(y)h(the)g(Certi\014cate)f(Enco)r (ding)g(\014eld.)0 4209 y(The)h(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g (Certi\014cate)f(P)n(a)n(yload)e(is)i(six)h(\(6\).)0 4541 y Fj(3.10)112 b(Certi\014cate)37 b(Request)g(P)m(a)m(yload)0 4794 y Fk(The)c(Certi\014cate)f(Request)g(P)n(a)n(yload)e(pro)n(vides)h (a)h(means)g(to)h(request)f(certi\014cates)g(via)g(ISAKMP)g(and)g(can)g (app)r(ear)g(in)0 4893 y(an)n(y)d(message.)43 b(Certi\014cate)29 b(Request)h(pa)n(yloads)e(SHOULD)j(b)r(e)f(included)h(in)f(an)g(exc)n (hange)e(whenev)n(er)h(an)h(appropriate)0 4993 y(directory)k(service)g (\(e.g.)60 b(Secure)34 b(DNS)i([DNSSEC)q(]\))g(is)f(not)g(a)n(v)-5 b(ailable)34 b(to)h(distribute)g(certi\014cates.)59 b(The)36 b(Certi\014cate)0 5093 y(Request)e(pa)n(yload)e(MUST)i(b)r(e)g (accepted)f(at)h(an)n(y)f(p)r(oin)n(t)h(during)f(the)h(exc)n(hange.)54 b(The)33 b(resp)r(onder)g(to)g(the)i(Certi\014cate)0 5192 y(Request)d(pa)n(yload)e(MUST)i(send)g(its)g(certi\014cate,)g(if)g (certi\014cates)f(are)g(supp)r(orted,)i(based)e(on)g(the)h(v)-5 b(alues)32 b(con)n(tained)f(in)0 5292 y(the)h(pa)n(yload.)47 b(If)32 b(m)n(ultiple)h(certi\014cates)d(are)h(required,)h(then)g(m)n (ultiple)g(Certi\014cate)f(Request)h(pa)n(yloads)d(SHOULD)k(b)r(e)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(27])p eop %%Page: 28 28 28 27 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)86 b(Cert.)42 b(Type)129 b(!)2048 b(!)349 1039 y(+-+-+-+-+-+-+-+)o(-+)2042 b(!)349 1138 y(~)871 b(Certificate)39 b(Authority)955 b(~)349 1238 y(!)2745 b(!)349 1338 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)1095 1703 y Fk(Figure)27 b(11:)36 b(Certi\014cate)27 b(Request)h(P)n(a)n(yload)d(F)-7 b(ormat)0 1968 y(transmitted.)37 b(Figure)27 b(11)g(sho)n(ws)f(the)i(format)f(of) h(the)g(Certi\014cate)f(Request)g(P)n(a)n(yload.)0 2167 y(The)h(Certi\014cate)f(P)n(a)n(yload)e(\014elds)j(are)e(de\014ned)i (as)f(follo)n(ws:)125 2433 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g(for)g(the)h (pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i (the)g(message.)56 b(If)35 b(the)208 2533 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g(message,)e(then)i(this)g (\014eld)g(will)g(b)r(e)g(0.)125 2699 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n(used,)f(set)h(to)f (0.)125 2865 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r (ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h(curren)n(t)e(pa)n (yload,)i(including)f(the)h(generic)e(pa)n(yload)208 2964 y(header.)125 3130 y Fc(\017)41 b Fk(Certi\014cate)20 b(T)n(yp)r(e)h(\(1)g(o)r(ctet\))h(-)f(Con)n(tains)f(an)h(enco)r(ding)g (of)g(the)h(t)n(yp)r(e)f(of)g(certi\014cate)g(requested.)34 b(Acceptable)21 b(v)-5 b(alues)208 3230 y(are)26 b(listed)i(in)g (section)f(3.9.)125 3396 y Fc(\017)41 b Fk(Certi\014cate)32 b(Authorit)n(y)h(\(v)-5 b(ariable)33 b(length\))g(-)g(Con)n(tains)g(an) g(enco)r(ding)g(of)g(an)g(acceptable)f(certi\014cate)h(authorit)n(y)208 3496 y(for)d(the)h(t)n(yp)r(e)g(of)f(certi\014cate)g(requested.)46 b(As)30 b(an)h(example,)g(for)f(an)g(X.509)g(certi\014cate)g(this)h (\014eld)g(w)n(ould)f(con)n(tain)208 3595 y(the)h(Distinguished)h(Name) g(enco)r(ding)f(of)g(the)h(Issuer)f(Name)g(of)g(an)h(X.509)e (certi\014cate)h(authorit)n(y)f(acceptable)h(to)208 3695 y(the)24 b(sender)g(of)g(this)h(pa)n(yload.)34 b(This)25 b(w)n(ould)f(b)r(e)h(included)f(to)h(assist)e(the)i(resp)r(onder)e(in)i (determining)f(ho)n(w)g(m)n(uc)n(h)g(of)208 3795 y(the)i(certi\014cate) f(c)n(hain)g(w)n(ould)g(need)h(to)g(b)r(e)g(sen)n(t)g(in)g(resp)r(onse) f(to)g(this)h(request.)36 b(If)26 b(there)g(is)f(no)h(sp)r(eci\014c)g (certi\014cate)208 3894 y(authorit)n(y)g(requested,)h(this)h(\014eld)g (SHOULD)g(not)g(b)r(e)g(included.)0 4160 y(The)g(pa)n(yload)e(t)n(yp)r (e)h(for)h(the)g(Certi\014cate)f(Request)g(P)n(a)n(yload)e(is)j(sev)n (en)f(\(7\).)0 4492 y Fj(3.11)112 b(Hash)38 b(P)m(a)m(yload)0 4745 y Fk(The)g(Hash)g(P)n(a)n(yload)e(con)n(tains)i(data)g(generated)f (b)n(y)h(the)g(hash)g(function)h(\(selected)g(during)f(the)g(SA)h (establishmen)n(t)0 4844 y(exc)n(hange\),)31 b(o)n(v)n(er)e(some)h (part)g(of)h(the)g(message)f(and/or)f(ISAKMP)h(state.)47 b(This)30 b(pa)n(yload)g(ma)n(y)g(b)r(e)h(used)g(to)g(v)n(erify)f(the)0 4944 y(in)n(tegrit)n(y)k(of)g(the)h(data)g(in)f(an)h(ISAKMP)f(message)f (or)h(for)g(authen)n(tication)g(of)h(the)g(negotiating)f(en)n(tities.) 58 b(Figure)34 b(12)0 5044 y(sho)n(ws)26 b(the)i(format)f(of)h(the)g (Hash)f(P)n(a)n(yload.)0 5243 y(The)h(Hash)f(P)n(a)n(yload)e(\014elds)j (are)e(de\014ned)i(as)f(follo)n(ws:)0 5656 y(Maughan,)g(Sc)n(hertler,)f (Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(28])p eop %%Page: 29 29 29 28 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)2745 b(!)349 1039 y(~)1176 b(Hash)42 b(Data)1175 b(~)349 1138 y(!)2745 b(!)349 1238 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)1352 1504 y Fk(Figure)27 b(12:)36 b(Hash)27 b(P)n(a)n(yload)e(F)-7 b(ormat)125 1769 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r (ctet\))g(-)f(Iden)n(ti\014er)g(for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h (of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 1868 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f (in)h(the)g(message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 2035 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 2201 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 2300 y(header.)125 2466 y Fc(\017)41 b Fk(Hash)20 b(Data)g(\(v)-5 b(ariable)19 b(length\))i(-)f(Data)g(that)g(results)g(from)g(applying)g (the)g(hash)g(routine)g(to)g(the)h(ISAKMP)f(message)208 2566 y(and/or)26 b(state.)0 2832 y(The)i(pa)n(yload)e(t)n(yp)r(e)h(for) h(the)g(Hash)f(P)n(a)n(yload)e(is)i(eigh)n(t)h(\(8\).)0 3164 y Fj(3.12)112 b(Signature)38 b(P)m(a)m(yload)0 3416 y Fk(The)c(Signature)f(P)n(a)n(yload)e(con)n(tains)i(data)g(generated)g (b)n(y)g(the)i(digital)e(signature)g(function)h(\(selected)g(during)f (the)i(SA)0 3516 y(establishmen)n(t)f(exc)n(hange\),)i(o)n(v)n(er)d (some)h(part)g(of)g(the)h(message)e(and/or)g(ISAKMP)i(state.)57 b(This)35 b(pa)n(yload)e(is)i(used)f(to)0 3616 y(v)n(erify)e(the)i(in)n (tegrit)n(y)e(of)i(the)f(data)g(in)g(the)h(ISAKMP)f(message,)g(and)g (ma)n(y)g(b)r(e)g(of)g(use)h(for)e(non-repudiation)g(services.)0 3715 y(Figure)27 b(13)g(sho)n(ws)f(the)i(format)f(of)h(the)g(Signature) f(P)n(a)n(yload.)1264 3965 y Fg(1)828 b(2)f(3)392 4064 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5)g(6) g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 4164 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 4264 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 4363 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 4463 y(!)2745 b(!)349 4563 y(~)1089 b(Signature)40 b(Data)1044 b(~)349 4662 y(!)2745 b(!)349 4762 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+)1270 5028 y Fk(Figure)27 b(13:)36 b(Signature)27 b(P)n(a)n(yload)e(F)-7 b(ormat)0 5227 y(The)28 b(Signature)e(P)n(a)n (yload)g(\014elds)h(are)g(de\014ned)h(as)f(follo)n(ws:)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(29])p eop %%Page: 30 30 30 29 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g(for)g(the)h (pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i (the)g(message.)56 b(If)35 b(the)208 490 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g(message,)e(then)i(this)g (\014eld)g(will)g(b)r(e)g(0.)125 656 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n(used,)f(set)h(to)f(0.)125 822 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h (-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h(curren)n(t)e(pa)n(yload,)i (including)f(the)h(generic)e(pa)n(yload)208 922 y(header.)125 1088 y Fc(\017)41 b Fk(Signature)32 b(Data)h(\(v)-5 b(ariable)33 b(length\))h(-)f(Data)g(that)h(results)e(from)h(applying)g(the)h (digital)f(signature)f(function)i(to)208 1187 y(the)28 b(ISAKMP)f(message)f(and/or)g(state.)0 1453 y(The)i(pa)n(yload)e(t)n (yp)r(e)h(for)h(the)g(Signature)e(P)n(a)n(yload)f(is)j(nine)g(\(9\).)0 1785 y Fj(3.13)112 b(Nonce)38 b(P)m(a)m(yload)0 2038 y Fk(The)23 b(Nonce)g(P)n(a)n(yload)d(con)n(tains)i(random)g(data)g (used)h(to)g(guaran)n(tee)e(liv)n(eness)h(during)g(an)h(exc)n(hange)e (and)i(protect)f(against)0 2137 y(repla)n(y)31 b(attac)n(ks.)49 b(Figure)32 b(14)f(sho)n(ws)g(the)i(format)e(of)h(the)h(Nonce)f(P)n(a)n (yload.)48 b(If)32 b(nonces)g(are)f(used)h(b)n(y)g(a)g(particular)f(k)n (ey)0 2237 y(exc)n(hange,)21 b(the)h(use)f(of)g(the)h(Nonce)f(pa)n (yload)f(will)h(b)r(e)h(dictated)g(b)n(y)f(the)h(k)n(ey)e(exc)n(hange.) 34 b(The)21 b(nonces)g(ma)n(y)f(b)r(e)i(transmitted)0 2337 y(as)30 b(part)h(of)g(the)g(k)n(ey)f(exc)n(hange)g(data,)h(or)g (as)f(a)g(separate)g(pa)n(yload.)46 b(Ho)n(w)n(ev)n(er,)30 b(this)h(is)g(de\014ned)g(b)n(y)g(the)g(k)n(ey)f(exc)n(hange,)0 2436 y(not)e(b)n(y)f(ISAKMP)-7 b(.)1264 2686 y Fg(1)828 b(2)f(3)392 2785 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g (2)h(3)f(4)g(5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9) g(0)h(1)349 2885 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+)349 2985 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 3084 y(+-+-+-+-+-+-+-+)o(-+-) o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 3184 y(!)2745 b(!)349 3284 y(~)1220 b(Nonce)41 b(Data)1088 b(~)349 3383 y(!)2745 b(!)349 3483 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+)1331 3749 y Fk(Figure)27 b(14:)36 b(Nonce)27 b(P)n(a)n(yload)f(F)-7 b(ormat)0 3948 y(The)28 b(Nonce)f(P)n(a)n(yload)e(\014elds)j(are)e(de\014ned)i(as)f(follo)n (ws:)125 4213 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r (ctet\))g(-)f(Iden)n(ti\014er)g(for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h (of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4313 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f (in)h(the)g(message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 4479 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 4645 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 4745 y(header.)125 4911 y Fc(\017)41 b Fk(Nonce)27 b(Data)g(\(v)-5 b(ariable)27 b(length\))h(-)f(Con)n(tains)g(the)h(random)f(data)g (generated)f(b)n(y)i(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)0 5176 y(The)28 b(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g(Nonce)f(P)n (a)n(yload)e(is)i(ten)h(\(10\).)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc) n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(30])p eop %%Page: 31 31 31 30 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(3.14)112 b(Noti\014cation)36 b(P)m(a)m(yload)0 643 y Fk(The)c(Noti\014cation)f(P)n(a)n(yload)e(can)i (con)n(tain)g(b)r(oth)h(ISAKMP)f(and)g(DOI-sp)r(eci\014c)h(data)f(and)g (is)g(used)h(to)f(transmit)h(infor-)0 743 y(mational)h(data,)h(suc)n(h) f(as)g(error)e(conditions,)j(to)f(an)g(ISAKMP)g(p)r(eer.)54 b(It)34 b(is)f(p)r(ossible)g(to)g(send)g(m)n(ultiple)h(Noti\014cation)0 842 y(pa)n(yloads)26 b(in)i(a)f(single)g(ISAKMP)g(message.)36 b(Figure)27 b(15)f(sho)n(ws)h(the)h(format)f(of)g(the)h(Noti\014cation) g(P)n(a)n(yload.)0 1042 y(Noti\014cation)j(whic)n(h)g(o)r(ccurs)g (during,)g(or)g(is)g(concerned)f(with,)j(a)e(Phase)f(1)h(negotiation)f (is)h(iden)n(ti\014ed)h(b)n(y)f(the)h(Initiator)0 1141 y(and)22 b(Resp)r(onder)g(co)r(okie)g(pair)g(in)g(the)h(ISAKMP)f (Header.)35 b(The)22 b(Proto)r(col)f(Iden)n(ti\014er,)j(in)e(this)h (case,)g(is)f(ISAKMP)g(and)h(the)0 1241 y(SPI)i(v)-5 b(alue)25 b(is)h(0)f(b)r(ecause)g(the)g(co)r(okie)g(pair)g(in)g(the)h (ISAKMP)f(Header)g(iden)n(ti\014es)g(the)h(ISAKMP)f(SA.)h(If)g(the)g (noti\014cation)0 1340 y(tak)n(es)d(place)h(prior)f(to)h(the)h (completed)f(exc)n(hange)f(of)h(k)n(eying)f(information,)i(then)g(the)f (noti\014cation)g(will)g(b)r(e)h(unprotected.)0 1540 y(Noti\014cation)31 b(whic)n(h)g(o)r(ccurs)g(during,)g(or)g(is)g (concerned)f(with,)j(a)e(Phase)f(2)h(negotiation)f(is)h(iden)n (ti\014ed)h(b)n(y)f(the)h(Initiator)0 1639 y(and)25 b(Resp)r(onder)f (co)r(okie)g(pair)h(in)g(the)g(ISAKMP)g(Header)f(and)h(the)g(Message)f (ID)h(and)g(SPI)f(asso)r(ciated)g(with)i(the)f(curren)n(t)0 1739 y(negotiation.)36 b(One)27 b(example)g(for)g(this)h(t)n(yp)r(e)g (of)g(noti\014cation)f(is)g(to)h(indicate)f(wh)n(y)h(a)f(prop)r(osal)f (w)n(as)g(rejected.)1264 1980 y Fg(1)828 b(2)f(3)392 2080 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g (5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 2179 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 2279 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 2378 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 2478 y(!)609 b(Domain)42 b(of)g(Interpretation)82 b(\(DOI\))782 b(!)349 2578 y(+-+-+-+-+-+-+-+)o (-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 2677 y(!)86 b(Protocol-ID)d(!)130 b(SPI)43 b(Size)172 b(!)262 b(Notify)41 b(Message)f(Type)260 b(!)349 2777 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 2877 y(!)2745 b(!)349 2976 y(~)697 b(Security)40 b(Parameter)g(Index)h(\(SPI\))739 b(~)349 3076 y(!)2745 b(!)349 3175 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 3275 y(!)g(!)349 3375 y(~)1002 b(Notification)38 b(Data)1001 b(~)349 3474 y(!)2745 b(!)349 3574 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+) 1230 3840 y Fk(Figure)27 b(15:)36 b(Noti\014cation)27 b(P)n(a)n(yload)e(F)-7 b(ormat)0 4030 y(The)28 b(Noti\014cation)f(P)n (a)n(yload)e(\014elds)j(are)e(de\014ned)i(as)f(follo)n(ws:)125 4279 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f (Iden)n(ti\014er)g(for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4379 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h (the)g(message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 4536 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 4694 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 4793 y(header.)125 4951 y Fc(\017)41 b Fk(Domain)25 b(of)h(In)n (terpretation)f(\(4)g(o)r(ctets\))i(-)e(Iden)n(ti\014es)h(the)g(DOI)g (\(as)g(describ)r(ed)f(in)h(Section)g(2.1\))f(under)h(whic)n(h)g(this) 208 5050 y(noti\014cation)j(is)h(taking)f(place.)43 b(F)-7 b(or)29 b(ISAKMP)h(this)g(v)-5 b(alue)30 b(is)f(zero)g(\(0\))h(and)g (for)f(the)h(IPSEC)f(DOI)h(it)h(is)e(one)h(\(1\).)208 5150 y(Other)d(DOI's)g(can)g(b)r(e)h(de\014ned)g(using)f(the)h (description)g(in)f(app)r(endix)h(B.)125 5308 y Fc(\017)41 b Fk(Proto)r(col-Id)31 b(\(1)i(o)r(ctet\))h(-)f(Sp)r(eci\014es)g(the)h (proto)r(col)e(iden)n(ti\014er)h(for)g(the)h(curren)n(t)e (noti\014cation.)54 b(Examples)32 b(migh)n(t)208 5407 y(include)c(ISAKMP)-7 b(,)27 b(IPSEC)g(ESP)-7 b(,)27 b(IPSEC)f(AH,)j(OSPF,)e(TLS,)g(etc.)0 5656 y(Maughan,)g(Sc)n(hertler,)f (Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(31])p eop %%Page: 32 32 32 31 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y Fc(\017)41 b Fk(SPI)25 b(Size)g(\(1)g(o)r(ctet\))h(-)f(Length)g(in)h(o)r(ctets)f(of)g(the)h (SPI)f(as)g(de\014ned)h(b)n(y)f(the)g(Proto)r(col-Id.)34 b(In)26 b(the)g(case)e(of)h(ISAKMP)-7 b(,)208 490 y(the)26 b(Initiator)f(and)h(Resp)r(onder)g(co)r(okie)f(pair)g(from)h(the)g (ISAKMP)g(Header)f(is)h(the)h(ISAKMP)e(SPI,)h(therefore,)g(the)208 589 y(SPI)c(Size)h(is)g(irrelev)-5 b(an)n(t)21 b(and)i(MA)-7 b(Y)23 b(b)r(e)h(from)e(zero)g(\(0\))h(to)f(sixteen)h(\(16\).)35 b(If)23 b(the)g(SPI)g(Size)g(is)f(non-zero,)g(the)h(con)n(ten)n(t)208 689 y(of)29 b(the)g(SPI)g(\014eld)h(MUST)g(b)r(e)f(ignored.)41 b(The)29 b(Domain)h(of)f(In)n(terpretation)f(\(DOI\))i(will)f(dictate)h (the)f(SPI)g(Size)h(for)208 789 y(other)d(proto)r(cols.)125 955 y Fc(\017)41 b Fk(Notify)27 b(Message)f(T)n(yp)r(e)h(\(2)g(o)r (ctets\))g(-)g(Sp)r(eci\014es)h(the)f(t)n(yp)r(e)h(of)f(noti\014cation) g(message)f(\(see)h(section)f(3.14.1\).)36 b(Addi-)208 1054 y(tional)27 b(text,)h(if)g(sp)r(eci\014ed)g(b)n(y)f(the)h(DOI,)g (is)f(placed)h(in)f(the)h(Noti\014cation)g(Data)f(\014eld.)125 1220 y Fc(\017)41 b Fk(SPI)27 b(\(v)-5 b(ariable)26 b(length\))i(-)f (Securit)n(y)g(P)n(arameter)e(Index.)36 b(The)28 b(receiving)e(en)n (tit)n(y's)h(SPI.)g(The)h(use)f(of)g(the)h(SPI)f(\014eld)208 1320 y(is)36 b(describ)r(ed)g(in)h(section)g(2.4.)63 b(The)36 b(length)h(of)g(this)g(\014eld)g(is)f(determined)h(b)n(y)f (the)h(SPI)g(Size)f(\014eld)h(and)g(is)f(not)208 1420 y(necessarily)26 b(aligned)g(to)i(a)f(4)g(o)r(ctet)h(b)r(oundary)-7 b(.)125 1586 y Fc(\017)41 b Fk(Noti\014cation)26 b(Data)g(\(v)-5 b(ariable)25 b(length\))i(-)f(Informational)f(or)g(error)f(data)i (transmitted)g(in)h(addition)f(to)g(the)h(Notify)208 1685 y(Message)f(T)n(yp)r(e.)36 b(V)-7 b(alues)28 b(for)f(this)h (\014eld)g(are)e(DOI-sp)r(eci\014c.)0 1951 y(The)i(pa)n(yload)e(t)n(yp) r(e)h(for)h(the)g(Noti\014cation)f(P)n(a)n(yload)e(is)i(elev)n(en)h (\(11\).)0 2266 y Fe(3.14.1)93 b(Notify)32 b(Message)e(T)m(yp)s(es)0 2519 y Fk(Noti\014cation)23 b(information)g(can)f(b)r(e)i(error)d (messages)h(sp)r(ecifying)h(wh)n(y)g(an)g(SA)h(could)f(not)g(b)r(e)h (established.)35 b(It)24 b(can)e(also)h(b)r(e)0 2619 y(status)18 b(data)h(that)f(a)h(pro)r(cess)e(managing)g(an)i(SA)g (database)e(wishes)h(to)h(comm)n(unicate)f(with)h(a)f(p)r(eer)h(pro)r (cess.)32 b(F)-7 b(or)18 b(example,)0 2719 y(a)28 b(secure)f(fron)n(t)g (end)i(or)e(securit)n(y)g(gatew)n(a)n(y)f(ma)n(y)h(use)h(the)h(Notify)f (message)f(to)h(sync)n(hronize)e(SA)j(comm)n(unication.)37 b(The)0 2818 y(table)28 b(b)r(elo)n(w)g(lists)h(the)f(No\014tication)g (messages)f(and)h(their)g(corresp)r(onding)f(v)-5 b(alues.)38 b(V)-7 b(alues)28 b(in)h(the)g(Priv)-5 b(ate)27 b(Use)h(range)0 2918 y(are)f(exp)r(ected)h(to)f(b)r(e)h(DOI-sp)r(eci\014c)f(v)-5 b(alues.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(32])p eop %%Page: 33 33 33 32 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1196 377 y(NOTIFY)h(MESSA)n(GES)f(-)h(ERR)n (OR)e(TYPES)1558 576 y(Errors)765 b(V)-7 b(alue)p 966 609 1969 4 v 1016 679 a(INV)e(ALID-P)i(A)g(YLO)n(AD-TYPE)582 b(1)1016 779 y(DOI-NOT-SUPPOR)-7 b(TED)711 b(2)1016 878 y(SITUA)-7 b(TION-NOT-SUPPOR)g(TED)399 b(3)1016 978 y(INV)-9 b(ALID-COOKIE)911 b(4)1016 1078 y(INV)-9 b(ALID-MAJOR-VERSION)535 b(5)1016 1177 y(INV)-9 b(ALID-MINOR-VERSION)548 b(6)1016 1277 y(INV)-9 b(ALID-EX)n(CHANGE-TYPE)504 b(7)1016 1377 y(INV)-9 b(ALID-FLA)n(GS)976 b(8)1016 1476 y(INV)-9 b(ALID-MESSA)n (GE-ID)725 b(9)1016 1576 y(INV)-9 b(ALID-PR)n(OTOCOL-ID)628 b(10)1016 1675 y(INV)-9 b(ALID-SPI)1099 b(11)1016 1775 y(INV)-9 b(ALID-TRANSF)n(ORM-ID)566 b(12)1016 1875 y(A)-7 b(TTRIBUTES-NOT-SUPPOR)g(TED)298 b(13)1016 1974 y(NO-PR)n (OPOSAL-CHOSEN)614 b(14)1016 2074 y(BAD-PR)n(OPOSAL-SYNT)-7 b(AX)562 b(15)1016 2174 y(P)-7 b(A)g(YLO)n(AD-MALF)n(ORMED)613 b(16)1016 2273 y(INV)-9 b(ALID-KEY-INF)n(ORMA)i(TION)402 b(17)1016 2373 y(INV)-9 b(ALID-ID-INF)n(ORMA)i(TION)493 b(18)1016 2472 y(INV)-9 b(ALID-CER)i(T-ENCODING)509 b(19)1016 2572 y(INV)-9 b(ALID-CER)i(TIFICA)g(TE)655 b(20)1016 2672 y(CER)-7 b(T-TYPE-UNSUPPOR)g(TED)444 b(21)1016 2771 y(INV)-9 b(ALID-CER)i(T-A)n(UTHORITY)451 b(22)1016 2871 y(INV)-9 b(ALID-HASH-INF)n(ORMA)i(TION)354 b(23)1016 2971 y(A)n(UTHENTICA)-7 b(TION-F)e(AILED)490 b(24)1016 3070 y(INV)-9 b(ALID-SIGNA)i(TURE)734 b(25)1016 3170 y(ADDRESS-NOTIFICA)-7 b(TION)553 b(26)1016 3269 y(NOTIFY-SA-LIFETIME) 699 b(27)1016 3369 y(CER)-7 b(TIFICA)g(TE-UNA)e(V)g(AILABLE)403 b(28)1016 3469 y(RESER)-9 b(VED)27 b(\(F)-7 b(uture)28 b(Use\))541 b(29)26 b(-)i(8191)1016 3568 y(Priv)-5 b(ate)26 b(Use)991 b(8192)25 b(-)j(16383)1186 3859 y(NOTIFY)g(MESSA)n(GES)f(-)g (ST)-7 b(A)g(TUS)29 b(TYPES)1522 3958 y(Status)619 b(V)-7 b(alue)p 1114 3992 1673 4 v 1164 4061 a(CONNECTED)674 b(16384)1164 4161 y(RESER)-9 b(VED)27 b(\(F)-7 b(uture)28 b(Use\))127 b(16385)26 b(-)h(24575)1164 4261 y(DOI-sp)r(eci\014c)g(co)r (des)389 b(24576)26 b(-)h(32767)1164 4360 y(Priv)-5 b(ate)26 b(Use)639 b(32768)26 b(-)h(40959)1164 4460 y(RESER)-9 b(VED)27 b(\(F)-7 b(uture)28 b(Use\))113 b(40960)26 b(-)h(65535)0 4783 y Fj(3.15)112 b(Delete)37 b(P)m(a)m(yload)0 5036 y Fk(The)30 b(Delete)h(P)n(a)n(yload)c(con)n(tains)j(a)f(proto)r (col-sp)r(eci\014c)g(securit)n(y)g(asso)r(ciation)g(iden)n(ti\014er)h (that)g(the)h(sender)e(has)h(remo)n(v)n(ed)0 5136 y(from)f(its)h (securit)n(y)f(asso)r(ciation)e(database)i(and)g(is,)h(therefore,)f(no) g(longer)g(v)-5 b(alid.)42 b(Figure)29 b(16)g(sho)n(ws)f(the)i(format)f (of)h(the)0 5235 y(Delete)i(P)n(a)n(yload.)44 b(It)32 b(is)e(p)r(ossible)h(to)g(send)g(m)n(ultiple)h(SPIs)e(in)h(a)g(Delete)h (pa)n(yload,)e(ho)n(w)n(ev)n(er,)g(eac)n(h)g(SPI)h(MUST)g(b)r(e)h(for)0 5335 y(the)c(same)f(proto)r(col.)36 b(Mixing)27 b(of)h(Proto)r(col)d (Iden)n(ti\014ers)i(MUST)i(NOT)e(b)r(e)h(p)r(erformed)f(with)h(the)g (Delete)g(pa)n(yload.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(33])p eop %%Page: 34 34 34 33 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(Deletion)j(whic)n(h)f(is)h (concerned)e(with)i(an)f(ISAKMP)g(SA)h(will)g(con)n(tain)f(a)g(Proto)r (col-Id)e(of)j(ISAKMP)f(and)g(the)h(SPIs)f(are)0 490 y(the)e(initiator)e(and)h(resp)r(onder)f(co)r(okies)g(from)h(the)h (ISAKMP)f(Header.)35 b(Deletion)27 b(whic)n(h)f(is)g(concerned)f(with)i (a)f(Proto)r(col)0 589 y(SA,)33 b(suc)n(h)f(as)g(ESP)g(or)g(AH,)h(will) g(con)n(tain)f(the)h(Proto)r(col-Id)e(of)h(that)h(proto)r(col)f(\(e.g.) 52 b(ESP)-7 b(,)32 b(AH\))h(and)g(the)g(SPI)f(is)h(the)0 689 y(sending)27 b(en)n(tit)n(y's)h(SPI\(s\).)0 888 y Fg(NOTE:)33 b Fk(The)i(Delete)h(P)n(a)n(yload)c(is)j(not)g(a)g(request) f(for)h(the)g(resp)r(onder)f(to)h(delete)g(an)g(SA,)g(but)h(an)f (advisory)e(from)i(the)0 988 y(initiator)e(to)g(the)h(resp)r(onder.)54 b(If)34 b(the)g(resp)r(onder)e(c)n(ho)r(oses)g(to)h(ignore)g(the)g (message,)h(the)g(next)g(comm)n(unication)e(from)0 1088 y(the)38 b(resp)r(onder)e(to)h(the)h(initiator,)h(using)e(that)h (securit)n(y)e(asso)r(ciation,)i(will)g(fail.)66 b(A)38 b(resp)r(onder)e(is)h(not)h(exp)r(ected)f(to)0 1187 y(ac)n(kno)n (wledge)25 b(receipt)j(of)f(a)g(Delete)i(pa)n(yload.)1264 1437 y Fg(1)828 b(2)f(3)392 1536 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h (8)f(9)g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5) f(6)g(7)g(8)g(9)g(0)h(1)349 1636 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+)349 1736 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 1835 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+)349 1935 y(!)609 b(Domain)42 b(of)g(Interpretation)82 b(\(DOI\))782 b(!)349 2035 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+)349 2134 y(!)86 b(Protocol-Id)d(!)130 b(SPI)43 b(Size)172 b(!)479 b(#)44 b(of)e(SPIs)478 b(!)349 2234 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 2333 y(!)2745 b(!)349 2433 y(~)653 b(Security)40 b(Parameter)g (Index\(es\))g(\(SPI\))608 b(~)349 2533 y(!)2745 b(!)349 2632 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+) 1328 2898 y Fk(Figure)27 b(16:)36 b(Delete)28 b(P)n(a)n(yload)d(F)-7 b(ormat)0 3097 y(The)28 b(Delete)g(P)n(a)n(yload)d(\014elds)j(are)e (de\014ned)i(as)f(follo)n(ws:)125 3363 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j(o)r(ctet\))g(-)f(Iden)n(ti\014er)g (for)g(the)h(pa)n(yload)e(t)n(yp)r(e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 3462 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f(in)h(the)g (message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 3629 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 3795 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 3894 y(header.)125 4060 y Fc(\017)41 b Fk(Domain)25 b(of)h(In)n (terpretation)f(\(4)g(o)r(ctets\))i(-)e(Iden)n(ti\014es)h(the)g(DOI)g (\(as)g(describ)r(ed)f(in)h(Section)g(2.1\))f(under)h(whic)n(h)g(this) 208 4160 y(deletion)d(is)g(taking)g(place.)35 b(F)-7 b(or)23 b(ISAKMP)g(this)h(v)-5 b(alue)23 b(is)h(zero)e(\(0\))i(and)f (for)g(the)h(IPSEC)e(DOI)i(it)g(is)f(one)g(\(1\).)36 b(Other)208 4259 y(DOI's)27 b(can)g(b)r(e)h(de\014ned)g(using)f(the)h (description)f(in)h(app)r(endix)g(B.)125 4426 y Fc(\017)41 b Fk(Proto)r(col-Id)34 b(\(1)i(o)r(ctet\))h(-)f(ISAKMP)g(can)f (establish)h(securit)n(y)g(asso)r(ciations)e(for)i(v)-5 b(arious)35 b(proto)r(cols,)i(including)208 4525 y(ISAKMP)h(and)h (IPSEC.)f(This)h(\014eld)g(iden)n(ti\014es)h(whic)n(h)f(securit)n(y)f (asso)r(ciation)f(database)h(to)h(apply)f(the)i(delete)208 4625 y(request.)125 4791 y Fc(\017)h Fk(SPI)25 b(Size)g(\(1)g(o)r (ctet\))h(-)f(Length)g(in)h(o)r(ctets)f(of)g(the)h(SPI)f(as)g (de\014ned)h(b)n(y)f(the)g(Proto)r(col-Id.)34 b(In)26 b(the)g(case)e(of)h(ISAKMP)-7 b(,)208 4890 y(the)32 b(Initiator)f(and)g (Resp)r(onder)g(co)r(okie)g(pair)g(is)g(the)h(ISAKMP)g(SPI.)f(In)h (this)g(case,)g(the)g(SPI)f(Size)h(w)n(ould)f(b)r(e)h(16)208 4990 y(o)r(ctets)27 b(for)g(eac)n(h)g(SPI)g(b)r(eing)h(deleted.)125 5156 y Fc(\017)41 b Fk(#)31 b(of)g(SPIs)f(\(2)h(o)r(ctets\))h(-)e(The)i (n)n(um)n(b)r(er)e(of)h(SPIs)g(con)n(tained)f(in)i(the)f(Delete)h(pa)n (yload.)45 b(The)31 b(size)g(of)g(eac)n(h)f(SPI)h(is)208 5256 y(de\014ned)d(b)n(y)f(the)h(SPI)f(Size)h(\014eld.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(34])p eop %%Page: 35 35 35 34 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)125 390 y Fc(\017)41 b Fk(Securit)n(y)23 b(P)n(arameter)f(Index\(es\))j(\(v)-5 b(ariable)23 b(length\))i(-)f (Iden)n(ti\014es)g(the)h(sp)r(eci\014c)f(securit)n(y)g(asso)r (ciation\(s\))f(to)h(delete.)208 490 y(V)-7 b(alues)30 b(for)g(this)h(\014eld)g(are)e(DOI)i(and)f(proto)r(col)g(sp)r (eci\014c.)45 b(The)31 b(length)g(of)f(this)h(\014eld)g(is)f (determined)h(b)n(y)f(the)h(SPI)208 589 y(Size)c(and)h(#)g(of)f(SPIs)g (\014elds.)0 850 y(The)h(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g(Delete)g (P)n(a)n(yload)d(is)i(t)n(w)n(elv)n(e)g(\(12\).)0 1180 y Fj(3.16)112 b(V)-9 b(endor)37 b(ID)g(P)m(a)m(yload)0 1433 y Fk(The)24 b(V)-7 b(endor)25 b(ID)f(P)n(a)n(yload)e(con)n(tains)i (a)g(v)n(endor)f(de\014ned)i(constan)n(t.)35 b(The)24 b(constan)n(t)g(is)g(used)h(b)n(y)f(v)n(endors)f(to)h(iden)n(tify)h (and)0 1533 y(recognize)30 b(remote)g(instances)h(of)h(their)f (implemen)n(tations.)48 b(This)31 b(mec)n(hanism)g(allo)n(ws)f(a)h(v)n (endor)f(to)h(exp)r(erimen)n(t)h(with)0 1633 y(new)23 b(features)g(while)g(main)n(taining)g(bac)n(kw)n(ards)d(compatibilit)n (y)-7 b(.)36 b(This)23 b(is)g(not)g(a)g(general)f(extension)g(facilit)n (y)h(of)g(ISAKMP)-7 b(.)0 1732 y(Figure)27 b(17)g(sho)n(ws)f(the)i (format)f(of)h(the)g(V)-7 b(endor)27 b(ID)h(P)n(a)n(yload.)0 1931 y(The)g(V)-7 b(endor)27 b(ID)i(pa)n(yload)d(is)i(not)g(an)f (announcemen)n(t)h(from)f(the)i(sender)e(that)h(it)g(will)g(send)g (priv)-5 b(ate)28 b(pa)n(yload)e(t)n(yp)r(es.)38 b(A)0 2031 y(v)n(endor)29 b(sending)i(the)g(V)-7 b(endor)30 b(ID)h(MUST)g(not)g(mak)n(e)f(an)n(y)g(assumptions)f(ab)r(out)i(priv)-5 b(ate)30 b(pa)n(yloads)f(that)i(it)g(ma)n(y)f(send)0 2131 y(unless)g(a)h(V)-7 b(endor)30 b(ID)h(is)g(receiv)n(ed)f(as)g(w)n (ell.)46 b(Multiple)31 b(V)-7 b(endor)30 b(ID)i(pa)n(yloads)c(MA)-7 b(Y)32 b(b)r(e)f(sen)n(t.)46 b(An)31 b(implemen)n(tation)g(is)0 2230 y(NOT)24 b(REQUIRED)g(to)g(understand)g(an)n(y)f(V)-7 b(endor)24 b(ID)h(pa)n(yloads.)34 b(An)25 b(implemen)n(tation)f(is)g (NOT)g(REQUIRED)g(to)g(send)0 2330 y(an)n(y)h(V)-7 b(endor)26 b(ID)g(pa)n(yload)e(at)i(all.)36 b(If)26 b(a)g(priv)-5 b(ate)25 b(pa)n(yload)g(w)n(as)g(sen)n(t)g(without)i(prior)d(agreemen)n (t)h(to)h(send)f(it,)i(a)f(complian)n(t)0 2430 y(implemen)n(tation)i (ma)n(y)f(reject)g(a)g(prop)r(osal)f(with)i(a)g(notify)g(message)e(of)h (t)n(yp)r(e)h(INV)-9 b(ALID-P)i(A)g(YLO)n(AD-TYPE.)0 2629 y(If)33 b(a)e(V)-7 b(endor)32 b(ID)g(pa)n(yload)f(is)h(sen)n(t,)h (it)g(MUST)f(b)r(e)h(sen)n(t)f(during)f(the)i(Phase)e(1)h(negotiation.) 49 b(Reception)32 b(of)g(a)g(familiar)0 2728 y(V)-7 b(endor)23 b(ID)g(pa)n(yload)f(in)h(the)h(Phase)e(1)h(negotiation)f(allo)n(ws)g (an)h(implemen)n(tation)g(to)g(mak)n(e)f(use)h(of)g(Priv)-5 b(ate)23 b(USE)g(pa)n(yload)0 2828 y(n)n(um)n(b)r(ers)k(\(128-255\),)d (describ)r(ed)j(in)h(section)e(3.1)h(for)f(v)n(endor)g(sp)r(eci\014c)i (extensions)e(during)h(Phase)f(2)h(negotiations.)35 b(The)0 2928 y(de\014nition)40 b(of)f("familiar")f(is)i(left)g(to)g(implemen)n (tations)f(to)g(determine.)73 b(Some)40 b(v)n(endors)e(ma)n(y)h(wish)g (to)g(implemen)n(t)0 3027 y(another)33 b(v)n(endor's)h(extension)g (prior)f(to)h(standardization.)56 b(Ho)n(w)n(ev)n(er,)34 b(this)h(practice)f(SHOULD)h(not)f(b)r(e)h(widespread)0 3127 y(and)27 b(v)n(endors)g(should)g(w)n(ork)f(to)n(w)n(ards)g (standardization)g(instead.)0 3326 y(The)h(v)n(endor)f(de\014ned)i (constan)n(t)e(MUST)i(b)r(e)g(unique.)37 b(The)27 b(c)n(hoice)g(of)g (hash)g(and)g(text)g(to)h(hash)e(is)h(left)h(to)g(the)f(v)n(endor)f(to) 0 3426 y(decide.)36 b(As)23 b(an)g(example,)h(v)n(endors)f(could)g (generate)f(their)i(v)n(endor)e(id)i(b)n(y)f(taking)g(a)g(plain)g (\(non-k)n(ey)n(ed\))g(hash)g(of)h(a)f(string)0 3525 y(con)n(taining)30 b(the)i(pro)r(duct)f(name,)h(and)f(the)h(v)n(ersion) e(of)h(the)h(pro)r(duct.)48 b(A)31 b(hash)g(is)g(used)g(instead)h(of)f (a)g(v)n(endor)f(registry)0 3625 y(to)f(a)n(v)n(oid)e(lo)r(cal)h (cryptographic)f(p)r(olicy)i(problems)f(with)h(ha)n(ving)f(a)h(list)g (of)g("appro)n(v)n(ed")d(pro)r(ducts,)i(to)h(k)n(eep)g(a)n(w)n(a)n(y)d (from)0 3725 y(main)n(taining)33 b(a)f(list)i(of)f(v)n(endors,)g(and)g (to)g(allo)n(w)f(classi\014ed)h(pro)r(ducts)f(to)h(a)n(v)n(oid)f(ha)n (ving)g(to)h(app)r(ear)g(on)f(an)n(y)h(list.)54 b(F)-7 b(or)0 3824 y(instance:)0 4024 y("Example)26 b(Compan)n(y)h(IPsec.)36 b(V)-7 b(ersion)27 b(97.1")0 4223 y(\(not)21 b(including)h(the)f (quotes\))g(has)g(MD5)g(hash:)33 b(48544f9b1fe662af98b9b39e5)o(0c0)o (1a)o(5a)o(,)17 b(when)k(using)g(MD5\014le.)35 b(V)-7 b(endors)0 4322 y(ma)n(y)26 b(include)h(all)g(of)g(the)g(hash,)g(or)e (just)j(a)e(p)r(ortion)h(of)f(it,)i(as)e(the)h(pa)n(yload)f(length)h (will)g(b)r(ound)g(the)g(data.)36 b(There)27 b(are)e(no)0 4422 y(securit)n(y)i(implications)g(of)h(this)f(hash,)h(so)f(its)g(c)n (hoice)g(is)h(arbitrary)-7 b(.)0 4621 y(The)28 b(V)-7 b(endor)27 b(ID)h(P)n(a)n(yload)d(\014elds)j(are)e(de\014ned)i(as)f (follo)n(ws:)125 4881 y Fc(\017)41 b Fk(Next)34 b(P)n(a)n(yload)e(\(1)j (o)r(ctet\))g(-)f(Iden)n(ti\014er)g(for)g(the)h(pa)n(yload)e(t)n(yp)r (e)h(of)h(the)g Fb(next)e Fk(pa)n(yload)g(in)i(the)g(message.)56 b(If)35 b(the)208 4981 y(curren)n(t)26 b(pa)n(yload)g(is)i(the)g(last)f (in)h(the)g(message,)e(then)i(this)g(\014eld)g(will)g(b)r(e)g(0.)125 5144 y Fc(\017)41 b Fk(RESER)-9 b(VED)27 b(\(1)g(o)r(ctet\))h(-)g(Un)n (used,)f(set)h(to)f(0.)125 5308 y Fc(\017)41 b Fk(P)n(a)n(yload)32 b(Length)j(\(2)g(o)r(ctets\))h(-)f(Length)g(in)g(o)r(ctets)g(of)g(the)h (curren)n(t)e(pa)n(yload,)i(including)f(the)h(generic)e(pa)n(yload)208 5407 y(header.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i (T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(35])p eop %%Page: 36 36 36 35 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1264 441 y Fg(1)828 b(2)f(3)392 541 y(0)43 b(1)h(2)f(3)g(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)g(2)h(3)f(4)g(5) g(6)g(7)g(8)h(9)f(0)g(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)349 640 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+) o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 740 y(!)f(Next)f(Payload)84 b(!)130 b(RESERVED)171 b(!)392 b(Payload)41 b(Length)346 b(!)349 839 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+)349 939 y(!)2745 b(!)349 1039 y(~)1045 b(Vendor)41 b(ID)i(\(VID\))1044 b(~)349 1138 y(!)2745 b(!)349 1238 y(+-+-+-+-+-+-+-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+)1253 1504 y Fk(Figure)27 b(17:)36 b(V)-7 b(endor)27 b(ID)h(P)n(a)n(yload)e(F)-7 b(ormat)125 1769 y Fc(\017)41 b Fk(V)-7 b(endor)27 b(ID)h(\(v)-5 b(ariable)27 b(length\))h(-)f(Hash)g(of)h(the)g(v)n(endor)e(string)h (plus)h(v)n(ersion)e(\(as)h(describ)r(ed)g(ab)r(o)n(v)n(e\).)0 2035 y(The)h(pa)n(yload)e(t)n(yp)r(e)h(for)h(the)g(V)-7 b(endor)27 b(ID)h(P)n(a)n(yload)d(is)i(thirteen)h(\(13\).)0 2409 y Ff(4)137 b(ISAKMP)46 b(Exc)l(hanges)0 2690 y Fk(ISAKMP)25 b(supplies)g(the)h(basic)f(syn)n(tax)f(of)h(a)g(message)f(exc)n(hange.) 35 b(The)25 b(basic)g(building)g(blo)r(c)n(ks)g(for)g(ISAKMP)g (messages)0 2790 y(are)e(the)h(pa)n(yload)f(t)n(yp)r(es)g(describ)r(ed) h(in)g(section)g(3.)35 b(This)24 b(section)f(describ)r(es)h(the)g(pro)r (cedures)f(for)g(SA)i(establishmen)n(t)e(and)0 2889 y(SA)j(mo)r (di\014cation,)g(follo)n(w)n(ed)f(b)n(y)g(a)h(default)g(set)g(of)g(exc) n(hanges)e(that)i(MA)-7 b(Y)26 b(b)r(e)h(used)e(for)h(initial)g(in)n (terop)r(erabilit)n(y)-7 b(.)35 b(Other)0 2989 y(exc)n(hanges)24 b(will)j(b)r(e)f(de\014ned)g(dep)r(ending)h(on)e(the)i(DOI)f(and)g(k)n (ey)f(exc)n(hange.)35 b([IPDOI)o(])26 b(and)g([IKE)o(])g(are)f (examples)h(of)g(ho)n(w)0 3089 y(this)i(is)f(ac)n(hiev)n(ed.)36 b(App)r(endix)29 b(B)e(explains)g(the)h(pro)r(cedures)e(for)h (accomplishing)g(these)h(additions.)0 3421 y Fj(4.1)112 b(ISAKMP)37 b(Exc)m(hange)h(T)m(yp)s(es)0 3674 y Fk(ISAKMP)21 b(allo)n(ws)f(the)i(creation)e(of)h(exc)n(hanges)f(for)g(the)i (establishmen)n(t)f(of)g(Securit)n(y)g(Asso)r(ciations)f(and)i(k)n (eying)e(material.)0 3773 y(There)h(are)g(curren)n(tly)f(\014v)n(e)h (default)h(Exc)n(hange)e(T)n(yp)r(es)h(de\014ned)h(for)f(ISAKMP)-7 b(.)21 b(Sections)h(4.4)e(through)h(4.8)g(describ)r(e)g(these)0 3873 y(exc)n(hanges.)33 b(Exc)n(hanges)19 b(de\014ne)j(the)f(con)n(ten) n(t)g(and)g(ordering)f(of)h(ISAKMP)g(messages)e(during)i(comm)n (unications)f(b)r(et)n(w)n(een)0 3972 y(p)r(eers.)36 b(Most)27 b(exc)n(hanges)e(will)j(include)f(all)g(the)g(basic)g(pa)n (yload)e(t)n(yp)r(es)i(-)g(SA,)g(KE,)g(ID,)g(SIG)h(-)e(and)h(ma)n(y)f (include)i(others.)0 4072 y(The)34 b(primary)e(di\013erence)h(b)r(et)n (w)n(een)h(exc)n(hange)e(t)n(yp)r(es)h(is)h(the)g(ordering)d(of)j(the)g (messages)e(and)h(the)h(pa)n(yload)e(ordering)0 4172 y(within)41 b(eac)n(h)e(message.)73 b(While)41 b(the)f(ordering)e(of)i (pa)n(yloads)f(within)h(messages)f(is)h(not)g(mandated,)j(for)d(pro)r (cessing)0 4271 y(e\016ciency)g(it)g(is)g(RECOMMENDED)f(that)h(the)g (Securit)n(y)g(Asso)r(ciation)e(pa)n(yload)h(b)r(e)h(the)g(\014rst)g (pa)n(yload)e(within)i(an)0 4371 y(exc)n(hange.)35 b(Pro)r(cessing)26 b(of)h(eac)n(h)g(pa)n(yload)f(within)j(an)e(exc)n(hange)f(is)i(describ) r(ed)f(in)h(section)f(5.)0 4570 y(Sections)35 b(4.4)f(through)h(4.8)f (pro)n(vide)g(a)g(default)i(set)f(of)g(ISAKMP)g(exc)n(hanges.)58 b(These)35 b(exc)n(hanges)e(pro)n(vide)h(di\013eren)n(t)0 4670 y(securit)n(y)23 b(protection)h(for)g(the)g(exc)n(hange)f(itself)i (and)f(information)f(exc)n(hanged.)35 b(The)24 b(diagrams)e(in)j(eac)n (h)e(of)i(the)f(follo)n(wing)0 4769 y(sections)g(sho)n(w)g(the)h (message)e(ordering)g(for)i(eac)n(h)f(exc)n(hange)f(t)n(yp)r(e)i(as)f (w)n(ell)g(as)g(the)h(pa)n(yloads)e(included)j(in)f(eac)n(h)e(message,) 0 4869 y(and)29 b(pro)n(vide)e(basic)i(notes)f(describing)g(what)h(has) f(happ)r(ened)i(after)e(eac)n(h)g(message)g(exc)n(hange.)39 b(None)29 b(of)f(the)i(examples)0 4969 y(include)f(an)n(y)g("optional)f (pa)n(yloads",)f(lik)n(e)i(certi\014cate)f(and)h(certi\014cate)g (request.)41 b(Additionally)-7 b(,)29 b(none)g(of)g(the)h(examples)0 5068 y(include)i(an)g(initial)g(exc)n(hange)f(of)h(ISAKMP)f(Headers)g (\(con)n(taining)g(initiator)h(and)g(resp)r(onder)f(co)r(okies\))g (whic)n(h)h(w)n(ould)0 5168 y(pro)n(vide)26 b(protection)h(against)g (clogging)f(\(see)h(section)g(2.5.3\).)0 5367 y(The)35 b(de\014ned)h(exc)n(hanges)e(are)g(not)h(mean)n(t)h(to)f(satisfy)g(all) g(DOI)g(and)g(k)n(ey)g(exc)n(hange)f(proto)r(col)g(requiremen)n(ts.)59 b(If)36 b(the)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T) -7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(36])p eop %%Page: 37 37 37 36 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(de\014ned)i(exc)n(hanges)e(meet)i (the)g(DOI)f(requiremen)n(ts,)g(then)h(they)g(can)f(b)r(e)h(used)f(as)g (outlined.)40 b(If)29 b(the)g(de\014ned)g(exc)n(hanges)0 490 y(do)21 b(not)g(meet)g(the)g(securit)n(y)f(requiremen)n(ts)g (de\014ned)h(b)n(y)g(the)g(DOI,)h(then)f(the)g(DOI)g(MUST)h(sp)r(ecify) f(new)g(exc)n(hange)f(t)n(yp)r(e\(s\))0 589 y(and)34 b(the)h(v)-5 b(alid)34 b(sequences)f(of)i(pa)n(yloads)d(that)j(mak)n(e) e(up)i(a)e(successful)h(exc)n(hange,)h(and)f(ho)n(w)g(to)g(build)h(and) f(in)n(terpret)0 689 y(those)23 b(pa)n(yloads.)33 b(All)24 b(ISAKMP)e(implemen)n(tations)h(MUST)h(implemen)n(t)f(the)h (Informational)d(Exc)n(hange)h(and)g(SHOULD)0 789 y(implemen)n(t)j(the) g(other)f(four)g(exc)n(hanges.)35 b(Ho)n(w)n(ev)n(er,)23 b(this)i(is)f(dep)r(enden)n(t)i(on)e(the)h(de\014nition)g(of)f(the)h (DOI)g(and)f(asso)r(ciated)0 888 y(k)n(ey)j(exc)n(hange)f(proto)r (cols.)0 1088 y(As)33 b(discussed)f(ab)r(o)n(v)n(e,)h(these)g(exc)n (hange)e(t)n(yp)r(es)i(can)f(b)r(e)h(used)g(in)g(either)f(phase)h(of)f (negotiation.)52 b(Ho)n(w)n(ev)n(er,)32 b(they)h(ma)n(y)0 1187 y(pro)n(vide)c(di\013eren)n(t)i(securit)n(y)f(prop)r(erties)f(in)i (eac)n(h)f(of)h(the)g(phases.)45 b(With)31 b(eac)n(h)f(of)h(these)f (exc)n(hanges,)g(the)h(com)n(bination)0 1287 y(of)36 b(co)r(okies)e(and)i(SPI)f(\014elds)h(iden)n(ti\014es)g(whether)g(this) g(exc)n(hange)e(is)i(b)r(eing)g(used)g(in)g(the)g(\014rst)f(or)g (second)g(phase)h(of)f(a)0 1386 y(negotiation.)0 1701 y Fe(4.1.1)94 b(Notation)0 1954 y Fk(The)25 b(follo)n(wing)g(notation)g (is)g(used)g(to)h(describ)r(e)f(the)h(ISAKMP)f(exc)n(hange)f(t)n(yp)r (es,)h(sho)n(wn)g(in)h(the)g(next)f(section,)h(with)g(the)0 2054 y(message)g(formats)h(and)g(asso)r(ciated)g(pa)n(yloads:)218 2332 y Fg(HDR)42 b(is)h(an)g(ISAKMP)e(header)g(whose)h(exchange)e(type) i(defines)e(the)j(payload)d(orderings)218 2432 y(SA)j(is)f(an)h(SA)g (negotiation)c(payload)i(with)h(one)g(or)h(more)f(Proposal)e(and)349 2532 y(Transform)g(payloads.)f(An)k(initiator)d(MAY)i(provide)f (multiple)f(proposals)436 2631 y(for)i(negotiation;)d(a)k(responder)d (MUST)i(reply)f(with)h(only)g(one.)218 2731 y(KE)h(is)f(the)h(key)f (exchange)e(payload.)218 2830 y(IDx)i(is)h(the)f(identity)f(payload)f (for)j("x".)f(x)h(can)f(be:)g("ii")g(or)h("ir")436 2930 y(for)f(the)h(ISAKMP)e(initiator)f(and)i(responder,)d(respectively,)g (or)j(x)h(can)436 3030 y(be:)f("ui",)g("ur")g(\(when)f(the)i(ISAKMP)e (daemon)g(is)h(a)i(proxy)d(negotiator\),)436 3129 y(for)h(the)h(user)e (initiator)f(and)j(responder,)c(respectively.)218 3229 y(HASH)j(is)h(the)f(hash)g(payload.)218 3329 y(SIG)g(is)h(the)f (signature)e(payload.)h(The)h(data)g(to)h(sign)e(is)i (exchange-specific)o(.)218 3428 y(AUTH)f(is)h(a)g(generic)d (authentication)e(mechanism,)i(such)i(as)g(HASH)g(or)h(SIG.)218 3528 y(NONCE)e(is)i(the)g(nonce)e(payload.)218 3627 y('*')h(signifies)e (payload)h(encryption)e(after)j(the)g(ISAKMP)f(header.)g(This)436 3727 y(encryption)e(MUST)j(begin)g(immediately)d(after)i(the)i(ISAKMP)e (header)g(and)436 3827 y(all)h(payloads)e(following)g(the)j(ISAKMP)e (header)g(MUST)h(be)h(encrypted.)218 4026 y(=>)g(signifies)d ("initiator)f(to)k(responder")c(communication)218 4126 y(<=)k(signifies)d("responder)f(to)k(initiator")c(communication)0 4457 y Fj(4.2)112 b(Securit)m(y)37 b(Asso)s(ciation)f(Establishmen)m(t) 0 4710 y Fk(The)c(Securit)n(y)g(Asso)r(ciation,)g(Prop)r(osal,)g(and)g (T)-7 b(ransform)30 b(pa)n(yloads)h(are)g(used)h(to)g(build)h(ISAKMP)f (messages)e(for)i(the)0 4809 y(negotiation)22 b(and)g(establishmen)n(t) h(of)g(SAs.)35 b(An)23 b(SA)h(establishmen)n(t)e(message)f(consists)h (of)h(a)f(single)h(SA)g(pa)n(yload)e(follo)n(w)n(ed)0 4909 y(b)n(y)38 b(at)f(least)h(one,)i(and)d(p)r(ossibly)h(man)n(y)-7 b(,)40 b(Prop)r(osal)c(pa)n(yloads)g(and)h(at)h(least)f(one,)j(and)e(p) r(ossibly)g(man)n(y)-7 b(,)39 b(T)-7 b(ransform)0 5009 y(pa)n(yloads)31 b(asso)r(ciated)h(with)h(eac)n(h)f(Prop)r(osal)f(pa)n (yload.)51 b(Because)32 b(these)h(pa)n(yloads)e(are)h(considered)g (together,)h(the)h(SA)0 5108 y(pa)n(yload)23 b(will)i(p)r(oin)n(t)h(to) e(an)n(y)g(follo)n(wing)g(pa)n(yloads)f(and)i(not)g(to)g(the)g(Prop)r (osal)e(pa)n(yload)g(included)j(with)f(the)g(SA)h(pa)n(yload.)0 5208 y(The)33 b(SA)h(P)n(a)n(yload)d(con)n(tains)h(the)i(DOI)f(and)g (Situation)g(for)g(the)h(prop)r(osed)e(SA.)h(Eac)n(h)f(Prop)r(osal)g (pa)n(yload)f(con)n(tains)h(a)0 5308 y(Securit)n(y)d(P)n(arameter)f (Index)i(\(SPI\))g(and)g(ensures)f(that)h(the)h(SPI)f(is)f(asso)r (ciated)g(with)i(the)f(Proto)r(col-Id)e(in)i(accordance)0 5407 y(with)d(the)f(In)n(ternet)g(Securit)n(y)g(Arc)n(hitecture)g([RF)n (C-1825)m(].)37 b(Prop)r(osal)24 b(pa)n(yloads)g(ma)n(y)i(or)f(ma)n(y)g (not)h(ha)n(v)n(e)f(the)i(same)e(SPI,)0 5656 y(Maughan,)i(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(37])p eop %%Page: 38 38 38 37 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(as)34 b(this)h(is)g(implemen)n (tation)g(dep)r(enden)n(t.)59 b(Eac)n(h)34 b(T)-7 b(ransform)33 b(P)n(a)n(yload)g(con)n(tains)h(the)h(sp)r(eci\014c)g(securit)n(y)f (mec)n(hanisms)0 490 y(to)g(b)r(e)g(used)g(for)g(the)g(designated)g (proto)r(col.)55 b(It)34 b(is)g(exp)r(ected)g(that)g(the)h(Prop)r(osal) d(and)i(T)-7 b(ransform)32 b(pa)n(yloads)g(will)j(b)r(e)0 589 y(used)23 b(only)g(during)g(SA)h(establishmen)n(t)f(negotiation.)35 b(The)23 b(creation)f(of)i(pa)n(yloads)d(for)i(securit)n(y)f(asso)r (ciation)g(negotiation)0 689 y(and)33 b(establishmen)n(t)f(describ)r (ed)h(here)f(in)h(this)g(section)g(are)f(applicable)g(for)g(all)h (ISAKMP)f(exc)n(hanges)f(describ)r(ed)i(later)0 789 y(in)i(sections)e (4.4)h(through)f(4.8.)56 b(The)35 b(examples)e(sho)n(wn)h(in)g(4.2.1)f (con)n(tain)h(only)g(the)h(SA,)f(Prop)r(osal,)g(and)g(T)-7 b(ransform)0 888 y(pa)n(yloads)26 b(and)h(do)h(not)f(con)n(tain)g (other)g(pa)n(yloads)f(that)i(migh)n(t)f(exist)h(for)f(a)g(giv)n(en)g (ISAKMP)g(exc)n(hange.)0 1088 y(The)20 b(Prop)r(osal)e(pa)n(yload)h (pro)n(vides)g(the)h(initiating)g(en)n(tit)n(y)h(with)f(the)h (capabilit)n(y)e(to)h(presen)n(t)g(to)g(the)g(resp)r(onding)g(en)n(tit) n(y)g(the)0 1187 y(securit)n(y)j(proto)r(cols)e(and)j(asso)r(ciated)e (securit)n(y)g(mec)n(hanisms)h(for)g(use)g(with)h(the)g(securit)n(y)e (asso)r(ciation)g(b)r(eing)i(negotiated.)0 1287 y(If)j(the)g(SA)g (establishmen)n(t)g(negotiation)f(is)g(for)h(a)f(com)n(bined)g (protection)g(suite)h(consisting)f(of)h(m)n(ultiple)g(proto)r(cols,)f (then)0 1386 y(there)j(MUST)h(b)r(e)g(m)n(ultiple)g(Prop)r(osal)e(pa)n (yloads)f(eac)n(h)i(with)h(the)g(same)f(Prop)r(osal)e(n)n(um)n(b)r(er.) 43 b(These)29 b(prop)r(osals)f(MUST)0 1486 y(b)r(e)37 b(considered)f(as)h(a)f(unit)i(and)f(MUST)h(NOT)e(b)r(e)i(separated)e (b)n(y)g(a)h(prop)r(osal)e(with)j(a)f(di\013eren)n(t)g(prop)r(osal)e(n) n(um)n(b)r(er.)0 1586 y(The)28 b(use)g(of)h(the)f(same)g(Prop)r(osal)e (n)n(um)n(b)r(er)i(in)h(m)n(ultiple)g(Prop)r(osal)d(pa)n(yloads)g(pro)n (vides)h(a)h(logical)f(AND)i(op)r(eration,)f(i.e.)0 1685 y(Proto)r(col)h(1)h(AND)i(Proto)r(col)d(2.)46 b(The)31 b(\014rst)f(example)g(b)r(elo)n(w)h(sho)n(ws)e(an)i(ESP)f(AND)h(AH)h (protection)e(suite.)46 b(If)31 b(the)h(SA)0 1785 y(establishmen)n(t)26 b(negotiation)f(is)h(for)g(di\013eren)n(t)g(protection)f(suites,)i (then)f(there)g(MUST)h(b)r(e)f(m)n(ultiple)h(Prop)r(osal)d(pa)n(yloads) 0 1885 y(eac)n(h)k(with)h(a)f(monotonically)f(increasing)g(Prop)r(osal) f(n)n(um)n(b)r(er.)39 b(The)29 b(di\013eren)n(t)g(prop)r(osals)d(MUST)j (b)r(e)g(presen)n(ted)f(in)h(the)0 1984 y(initiator's)c(preference)h (order.)35 b(The)26 b(use)g(of)g(di\013eren)n(t)h(Prop)r(osal)d(n)n(um) n(b)r(ers)h(in)i(m)n(ultiple)f(Prop)r(osal)e(pa)n(yloads)h(pro)n(vides) f(a)0 2084 y(logical)e(OR)i(op)r(eration,)f(i.e.)36 b(Prop)r(osal)21 b(1)j(OR)f(Prop)r(osal)f(2,)i(where)f(eac)n(h)g(prop)r(osal)f(ma)n(y)h (ha)n(v)n(e)f(more)h(than)h(one)f(proto)r(col.)0 2183 y(The)i(second)f(example)g(b)r(elo)n(w)g(sho)n(ws)g(either)h(an)f(AH)h (AND)h(ESP)e(protection)g(suite)h(OR)f(just)i(an)e(ESP)g(protection)g (suite.)0 2283 y(Note)29 b(that)h(the)f(Next)h(P)n(a)n(yload)c(\014eld) k(of)f(the)g(Prop)r(osal)e(pa)n(yload)h(p)r(oin)n(ts)h(to)g(another)f (Prop)r(osal)f(pa)n(yload)h(\(if)i(it)f(exists\).)0 2383 y(The)f(existence)f(of)h(a)f(Prop)r(osal)e(pa)n(yload)h(implies)i(the)g (existence)f(of)h(one)f(or)g(more)g(T)-7 b(ransform)26 b(pa)n(yloads.)0 2582 y(The)f(T)-7 b(ransform)24 b(pa)n(yload)g(pro)n (vides)g(the)i(initiating)g(en)n(tit)n(y)f(with)h(the)g(capabilit)n(y)e (to)i(presen)n(t)f(to)g(the)h(resp)r(onding)e(en)n(tit)n(y)0 2682 y(m)n(ultiple)34 b(mec)n(hanisms,)h(or)e(transforms,)h(for)g(a)f (giv)n(en)g(proto)r(col.)55 b(The)34 b(Prop)r(osal)e(pa)n(yload)g(iden) n(ti\014es)i(a)g(Proto)r(col)e(for)0 2781 y(whic)n(h)27 b(services)f(and)h(mec)n(hanisms)f(are)h(b)r(eing)g(negotiated.)36 b(The)27 b(T)-7 b(ransform)26 b(pa)n(yload)f(allo)n(ws)h(the)i (initiating)f(en)n(tit)n(y)g(to)0 2881 y(presen)n(t)h(sev)n(eral)e(p)r (ossible)i(supp)r(orted)g(transforms)f(for)h(that)h(prop)r(osed)e (proto)r(col.)38 b(There)28 b(ma)n(y)f(b)r(e)i(sev)n(eral)d(transforms) 0 2980 y(asso)r(ciated)j(with)i(a)g(sp)r(eci\014c)f(Prop)r(osal)f(pa)n (yload)g(eac)n(h)h(iden)n(ti\014ed)h(in)g(a)f(separate)f(T)-7 b(ransform)29 b(pa)n(yload.)45 b(The)31 b(m)n(ultiple)0 3080 y(transforms)g(MUST)h(b)r(e)h(presen)n(ted)e(with)h(monotonically) f(increasing)g(n)n(um)n(b)r(ers)g(in)h(the)h(initiator's)e(preference)g (order.)0 3180 y(The)36 b(receiving)f(en)n(tit)n(y)h(MUST)h(select)f(a) f(single)h(transform)f(for)g(eac)n(h)g(proto)r(col)g(in)i(a)e(prop)r (osal)g(or)g(reject)h(the)h(en)n(tire)0 3279 y(prop)r(osal.)e(The)27 b(use)g(of)f(the)h(T)-7 b(ransform)26 b(n)n(um)n(b)r(er)g(in)h(m)n (ultiple)h(T)-7 b(ransform)25 b(pa)n(yloads)g(pro)n(vides)g(a)i(second) f(lev)n(el)g(OR)h(op-)0 3379 y(eration,)d(i.e.)36 b(T)-7 b(ransform)23 b(1)h(OR)h(T)-7 b(ransform)23 b(2)h(OR)g(T)-7 b(ransform)24 b(3.)35 b(Example)24 b(1)g(b)r(elo)n(w)g(sho)n(ws)f(t)n (w)n(o)h(p)r(ossible)g(transforms)0 3479 y(for)k(ESP)g(and)g(a)h (single)f(transform)f(for)h(AH.)i(Example)d(2)i(b)r(elo)n(w)f(sho)n(ws) f(one)i(transform)e(for)h(AH)h(AND)h(one)e(transform)0 3578 y(for)35 b(ESP)g(OR)h(t)n(w)n(o)f(transforms)f(for)h(ESP)g(alone.) 60 b(Note)36 b(that)g(the)g(Next)g(P)n(a)n(yload)e(\014eld)i(of)f(the)h (T)-7 b(ransform)35 b(pa)n(yload)0 3678 y(p)r(oin)n(ts)28 b(to)f(another)g(T)-7 b(ransform)26 b(pa)n(yload)g(or)h(0.)36 b(The)28 b(Prop)r(osal)d(pa)n(yload)h(delineates)h(the)h(di\013eren)n (t)g(prop)r(osals.)0 3877 y(When)41 b(resp)r(onding)f(to)g(a)g(Securit) n(y)g(Asso)r(ciation)g(pa)n(yload,)i(the)f(resp)r(onder)e(MUST)i(send)g (a)f(Securit)n(y)g(Asso)r(ciation)0 3977 y(pa)n(yload)31 b(with)h(the)h(selected)f(prop)r(osal,)g(whic)n(h)g(ma)n(y)g(consist)g (of)g(m)n(ultiple)h(Prop)r(osal)d(pa)n(yloads)g(and)i(their)g(asso)r (ciated)0 4076 y(T)-7 b(ransform)29 b(pa)n(yloads.)45 b(Eac)n(h)30 b(of)h(the)g(Prop)r(osal)e(pa)n(yloads)g(MUST)i(con)n (tain)f(a)g(single)h(T)-7 b(ransform)29 b(pa)n(yload)g(asso)r(ciated)0 4176 y(with)k(the)g(Proto)r(col.)51 b(The)33 b(resp)r(onder)e(SHOULD)j (retain)e(the)h(Prop)r(osal)e(#)i(\014eld)g(in)g(the)g(Prop)r(osal)e (pa)n(yload)g(and)i(the)0 4276 y(T)-7 b(ransform)22 b(#)i(\014eld)g(in) g(eac)n(h)f(T)-7 b(ransform)22 b(pa)n(yload)g(of)i(the)g(selected)g (Prop)r(osal.)33 b(Reten)n(tion)24 b(of)f(Prop)r(osal)f(and)h(T)-7 b(ransform)0 4375 y(n)n(um)n(b)r(ers)30 b(should)h(sp)r(eed)g(the)g (initiator's)f(proto)r(col)g(pro)r(cessing)f(b)n(y)i(negating)f(the)h (need)g(to)g(compare)f(the)h(resp)r(ondor's)0 4475 y(selection)j(with)h (ev)n(ery)e(o\013ered)h(option.)57 b(These)34 b(v)-5 b(alues)35 b(enable)f(the)h(initiator)e(to)i(p)r(erform)f(the)h (comparison)d(directly)0 4575 y(and)d(quic)n(kly)-7 b(.)40 b(The)29 b(initiator)f(MUST)i(v)n(erify)e(that)h(the)g(Securit)n(y)f (Asso)r(ciation)g(pa)n(yload)g(receiv)n(ed)f(from)i(the)g(resp)r(onder) 0 4674 y(matc)n(hes)e(one)g(of)h(the)g(prop)r(osals)e(sen)n(t)h (initially)-7 b(.)0 4990 y Fe(4.2.1)94 b(Securit)m(y)33 b(Asso)s(ciation)d(Establishmen)m(t)f(Examples)0 5242 y Fk(This)39 b(example)f(sho)n(ws)g(a)g(Prop)r(osal)f(for)h(a)h(com)n (bined)f(protection)g(suite)h(with)g(t)n(w)n(o)f(di\013eren)n(t)h (proto)r(cols.)69 b(The)39 b(\014rst)0 5342 y(proto)r(col)23 b(is)i(presen)n(ted)f(with)h(t)n(w)n(o)f(transforms)f(supp)r(orted)h(b) n(y)h(the)g(prop)r(oser.)34 b(The)25 b(second)f(proto)r(col)f(is)i (presen)n(ted)f(with)0 5656 y(Maughan,)j(Sc)n(hertler,)f(Sc)n(hneider,) i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(38])p eop %%Page: 39 39 39 38 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(a)k(single)f(transform.)46 b(An)32 b(example)e(for)h(this)g(prop)r(osal)f(migh)n(t)h(b)r(e:)44 b(Proto)r(col)29 b(1)i(is)g(ESP)f(with)i(T)-7 b(ransform)29 b(1)i(as)f(3DES)0 490 y(and)23 b(T)-7 b(ransform)21 b(2)i(as)f(DES)h (AND)h(Proto)r(col)e(2)g(is)h(AH)h(with)f(T)-7 b(ransform)22 b(1)g(as)g(SHA.)i(The)f(resp)r(onder)f(MUST)i(select)e(from)0 589 y(the)27 b(t)n(w)n(o)f(transforms)f(prop)r(osed)h(for)g(ESP)-7 b(.)26 b(The)g(resulting)g(protection)g(suite)h(will)g(b)r(e)g(either)g (\(1\))f(3DES)h Fb(AND)e Fk(SHA)j Fb(OR)0 689 y Fk(\(2\))h(DES)f Fb(AND)g Fk(SHA,)h(dep)r(ending)g(on)f(whic)n(h)h(ESP)e(transform)h(w)n (as)f(selected)i(b)n(y)f(the)h(resp)r(onder.)38 b(Note)29 b(this)g(example)0 789 y(is)e(sho)n(wn)g(using)h(the)g(Base)e(Exc)n (hange.)1220 1056 y Fg(1)828 b(2)g(3)349 1155 y(0)43 b(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)f(2)g(3)g(4)g(5)g(6)h(7)f (8)g(9)g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)262 1255 y(/+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+) 218 1354 y(/)g(!)g(NP)g(=)g(Nonce)172 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 1454 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 1554 y(SA)43 b(Pay)f(!)741 b(Domain)41 b(of)i(Interpretation)37 b(\(DOI\))696 b(!)174 1653 y(\\)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-) o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)218 1753 y(\\)43 b(!)1177 b(Situation)c(!)262 1853 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+) 218 1952 y(/)43 b(!)g(NP)g(=)g(Proposal)d(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 2052 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 2151 y(Prop)42 b(1)h(!)g(Proposal)e(#)i(=)g(1!)86 b(Protocol-Id)d(!)174 b(SPI)42 b(Size)129 b(!#)43 b(of)g(Trans.)e(=)i(2!)0 2251 y(Prot)f(1)h(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)218 2351 y(\\)g(!)1089 b(SPI)43 b(\(variable\))1042 b(!)262 2450 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)218 2550 y(/)43 b(!)g(NP)g(=)g(Transform!)127 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 2650 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 2749 y(Tran)42 b(1)h(!)g(Transform)d(#)j(1)g(!)h(Transform)c(ID)86 b(!)479 b(RESERVED2)d(!)174 2849 y(\\)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+) o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)218 2949 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 3048 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3148 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 3247 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-)o(+-+)0 3347 y(Tran)42 b(2)h(!)g(Transform)d(#)j(2)g(!)h(Transform) c(ID)86 b(!)479 b(RESERVED2)d(!)174 3447 y(\\)87 b(+-+-+-+-+-+-+-+-)o (+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3546 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 3646 y(>+-+-+-+-+-+-+-)o(+-) o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-) o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3746 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 3845 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)0 3945 y(Prop)42 b(1)h(!)g(Proposal)e(#)i(=)g(1!) 86 b(Protocol)41 b(ID)86 b(!)174 b(SPI)42 b(Size)129 b(!#)43 b(of)g(Trans.)e(=)i(1!)0 4044 y(Prot)f(2)h(+-+-+-+-+-+-+-+-)o (+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 4144 y(\\)g(!)1089 b(SPI)43 b(\(variable\))1042 b(!)262 4244 y(>+-+-+-+-+-+-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 4343 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 4443 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-)o(+-+)0 4543 y(Tran)42 b(1)h(!)g(Transform)d(#)j(1)g(!)h(Transform) c(ID)86 b(!)479 b(RESERVED2)d(!)174 4642 y(\\)87 b(+-+-+-+-+-+-+-+-)o (+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 4742 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 4841 y(\\+-+-+-+-+-+-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 5208 y Fk(This)35 b(second)f(example)h(sho)n(ws)f(a)h(Prop)r(osal)e(for)h(t)n(w)n(o)h (di\013eren)n(t)g(protection)f(suites.)59 b(The)35 b(SA)h(P)n(a)n (yload)d(w)n(as)h(omitted)0 5308 y(for)c(space)g(reasons.)44 b(The)31 b(\014rst)f(protection)g(suite)h(is)g(presen)n(ted)f(with)h (one)f(transform)g(for)g(the)h(\014rst)f(proto)r(col)g(and)g(one)0 5407 y(transform)25 b(for)g(the)h(second)g(proto)r(col.)35 b(The)26 b(second)f(protection)g(suite)h(is)g(presen)n(ted)f(with)h(t)n (w)n(o)f(transforms)g(for)g(a)h(single)0 5656 y(Maughan,)h(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(39])p eop %%Page: 40 40 40 39 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(proto)r(col.)47 b(An)31 b(example)g(for)g(this)g(prop)r(osal)f(migh)n(t)h(b)r(e:)45 b(Prop)r(osal)29 b(1)i(with)h(Proto)r(col)d(1)i(as)f(AH)i(with)g(T)-7 b(ransform)30 b(1)h(as)0 490 y(MD5)26 b(AND)h(Proto)r(col)e(2)g(as)h (ESP)f(with)h(T)-7 b(ransform)25 b(1)h(as)f(3DES.)h(This)g(is)g(follo)n (w)n(ed)f(b)n(y)h(Prop)r(osal)e(2)h(with)i(Proto)r(col)d(1)i(as)0 589 y(ESP)c(with)i(T)-7 b(ransform)21 b(1)i(as)f(DES)h(and)g(T)-7 b(ransform)22 b(2)g(as)h(3DES.)f(The)h(resp)r(onder)f(MUST)i(select)f (from)f(the)i(t)n(w)n(o)e(di\013eren)n(t)0 689 y(prop)r(osals.)37 b(If)28 b(the)h(second)e(Prop)r(osal)f(is)i(selected,)g(the)h(resp)r (onder)d(MUST)j(select)f(from)g(the)g(t)n(w)n(o)g(transforms)e(for)i (ESP)-7 b(.)0 789 y(The)25 b(resulting)g(protection)f(suite)i(will)f(b) r(e)h(either)f(\(1\))g(MD5)h Fb(AND)e Fk(3DES)h Fb(OR)f Fk(the)i(selection)f(b)r(et)n(w)n(een)g(\(2\))g(DES)g Fb(OR)g Fk(\(3\))0 888 y(3DES.)1220 1171 y Fg(1)828 b(2)g(3)349 1270 y(0)43 b(1)g(2)g(3)g(4)h(5)f(6)g(7)g(8)g(9)g(0)h(1)f(2)g(3)g(4)g (5)g(6)h(7)f(8)g(9)g(0)g(1)g(2)h(3)f(4)g(5)g(6)g(7)h(8)f(9)g(0)g(1)262 1370 y(/+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+) 218 1469 y(/)g(!)g(NP)g(=)g(Proposal)d(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 1569 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 1669 y(Prop)42 b(1)h(!)g(Proposal)e(#)i(=)g(1!)86 b(Protocol)41 b(ID)86 b(!)174 b(SPI)42 b(Size)129 b(!#)43 b(of)g(Trans.)e(=)i(1!)0 1768 y(Prot)f(1)h(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)218 1868 y(\\)g(!)1089 b(SPI)43 b(\(variable\))1042 b(!)262 1968 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o (+-+)218 2067 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 2167 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 2267 y(Tran)42 b(1)h(!)g(Transform)d(#)j(1)g(!)h(Transform)c(ID)86 b(!)479 b(RESERVED2)d(!)174 2366 y(\\)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+) o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)218 2466 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 2565 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 2665 y(/)43 b(!)g(NP)g(=)g (Proposal)d(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 2765 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)0 2864 y(Prop)42 b(1)h(!)g(Proposal)e(#)i(=)g(1!)g (Protocol)d(ID)130 b(!)174 b(SPI)42 b(Size)129 b(!#)43 b(of)g(Trans.)e(=)i(1!)0 2964 y(Prot)f(2)h(+-+-+-+-+-+-+-+-)o(+-+)o(-+) o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3064 y(\\)g(!)1089 b(SPI)43 b(\(variable\))1042 b(!)262 3163 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)218 3263 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 3362 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-)o(+-+)0 3462 y(Tran)42 b(1)h(!)g(Transform)d(#)j(1)g(!)h(Transform) c(ID)86 b(!)479 b(RESERVED2)d(!)174 3562 y(\\)87 b(+-+-+-+-+-+-+-+-)o (+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3661 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 3761 y(>+-+-+-+-+-+-+-)o(+-) o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-) o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 3861 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 3960 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-)o(+-+)0 4060 y(Prop)42 b(2)h(!)g(Proposal)e(#)i(=)g(2!)g (Protocol)d(ID)130 b(!)174 b(SPI)42 b(Size)129 b(!#)43 b(of)g(Trans.)e(=)i(2!)0 4159 y(Prot)f(1)h(+-+-+-+-+-+-+-+-)o(+-+)o(-+) o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)218 4259 y(\\)g(!)1089 b(SPI)43 b(\(variable\))1042 b(!)262 4359 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-)o(+-+)218 4458 y(/)43 b(!)g(NP)g(=)g(Transform!)127 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 4558 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o (-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 4658 y(Tran)42 b(1)h(!)g(Transform)d(#)j(1)g(!)h(Transform)c(ID)86 b(!)479 b(RESERVED2)d(!)174 4757 y(\\)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+) o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+) o(-+)o(-+-)o(+-)o(+-)o(+-+)218 4857 y(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 4956 y(>+-+-+-+-+-+-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)218 5056 y(/)43 b(!)g(NP)g(=)g(0)348 b(!)131 b(RESERVED)171 b(!)392 b(Payload)40 b(Length)347 b(!)174 5156 y(/)87 b(+-+-+-+-+-+-+-+-)o(+-+)o(-+)o(-+-)o(+-)o(+-+)o (-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+-)o(+-)o (+-)o(+-+)0 5255 y(Tran)42 b(2)h(!)g(Transform)d(#)j(2)g(!)h(Transform) c(ID)86 b(!)479 b(RESERVED2)d(!)174 5355 y(\\)87 b(+-+-+-+-+-+-+-+-)o (+-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o (+-)o(+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 5656 y Fk(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(40])p eop %%Page: 41 41 41 40 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)218 390 y Fg(\\)43 b(!)1089 b(SA)43 b(Attributes)1086 b(!)262 490 y(\\+-+-+-+-+-+-+-)o(+-)o(+-+)o (-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o(+-+)o(-+)o(-+)o(-+-)o(+-)o (+-+)o(-+)o(-+-)o(+-)o(+-)o(+-+)0 857 y Fj(4.3)112 b(Securit)m(y)37 b(Asso)s(ciation)f(Mo)s(di\014cation)0 1110 y Fk(Securit)n(y)23 b(Asso)r(ciation)f(mo)r(di\014cation)h(within)g(ISAKMP)g(is)g (accomplished)f(b)n(y)h(creating)f(a)h(new)g(SA)h(and)e(initiating)i (com-)0 1209 y(m)n(unications)g(using)f(that)i(new)f(SA.)h(Deletion)f (of)g(the)h(old)f(SA)g(can)g(b)r(e)h(done)e(an)n(ytime)h(after)g(the)h (new)f(SA)g(is)g(established.)0 1309 y(Deletion)g(of)g(the)g(old)f(SA)h (is)g(dep)r(enden)n(t)g(on)f(lo)r(cal)g(securit)n(y)g(p)r(olicy)-7 b(.)36 b(Mo)r(di\014cation)23 b(of)h(SAs)g(b)n(y)f(using)g(a)g("Create) g(New)h(SA)0 1409 y(follo)n(w)n(ed)j(b)n(y)h(Delete)g(Old)g(SA")g (metho)r(d)h(is)f(done)g(to)g(a)n(v)n(oid)e(p)r(oten)n(tial)i (vulnerabilities)g(in)g(sync)n(hronizing)e(mo)r(di\014cation)0 1508 y(of)i(existing)f(SA)h(attributes.)37 b(The)28 b(pro)r(cedure)f (for)g(creating)g(new)h(SAs)g(is)f(outlined)h(in)g(section)g(4.2.)36 b(The)28 b(pro)r(cedure)f(for)0 1608 y(deleting)h(SAs)f(is)h(outlined)g (in)g(section)f(5.15.)0 1807 y(Mo)r(di\014cation)c(of)g(an)h(ISAKMP)f (SA)h(\(phase)f(1)g(negotiation\))f(follo)n(ws)h(the)h(same)e(pro)r (cedure)h(as)g(creation)f(of)h(an)g(ISAKMP)0 1907 y(SA.)j(There)g(is)f (no)h(relationship)f(b)r(et)n(w)n(een)g(the)h(t)n(w)n(o)f(SAs)h(and)g (the)g(initiator)f(and)h(resp)r(onder)f(co)r(okie)f(pairs)h(SHOULD)i(b) r(e)0 2006 y(di\013eren)n(t,)h(as)f(outlined)h(in)f(section)h(2.5.3.)0 2206 y(Mo)r(di\014cation)k(of)h(a)f(Proto)r(col)f(SA)i(\(phase)f(2)h (negotiation\))e(follo)n(ws)h(the)h(same)f(pro)r(cedure)g(as)g (creation)f(of)i(a)f(Proto)r(col)0 2305 y(SA.)f(The)g(creation)f(of)g (a)h(new)f(SA)i(is)e(protected)h(b)n(y)f(the)h(existing)f(ISAKMP)h(SA.) g(There)f(is)h(no)f(relationship)g(b)r(et)n(w)n(een)0 2405 y(the)25 b(t)n(w)n(o)e(Proto)r(col)g(SAs.)36 b(A)25 b(proto)r(col)e(implemen)n(tation)h(SHOULD)h(b)r(egin)g(using)f(the)g (newly)h(created)e(SA)i(for)f(outb)r(ound)0 2505 y(tra\016c)k(and)f (SHOULD)i(con)n(tin)n(ue)f(to)g(supp)r(ort)g(incoming)f(tra\016c)h(on)g (the)g(old)g(SA)g(un)n(til)h(it)g(is)e(deleted)i(or)e(un)n(til)i (tra\016c)e(is)0 2604 y(receiv)n(ed)j(under)h(the)g(protection)f(of)h (the)g(newly)g(created)f(SA.)h(As)g(stated)g(previously)f(in)h(this)g (section,)h(deletion)f(of)f(an)0 2704 y(old)d(SA)h(is)g(then)g(dep)r (enden)n(t)g(on)g(lo)r(cal)f(securit)n(y)f(p)r(olicy)-7 b(.)0 3029 y Fj(4.4)112 b(Base)38 b(Exc)m(hange)0 3282 y Fk(The)33 b(Base)f(Exc)n(hange)g(is)h(designed)f(to)h(allo)n(w)f(the) i(Key)e(Exc)n(hange)f(and)i(Authen)n(tication)h(related)e(information)h (to)g(b)r(e)0 3381 y(transmitted)d(together.)42 b(Com)n(bining)29 b(the)h(Key)f(Exc)n(hange)f(and)i(Authen)n(tication-related)f (information)g(in)n(to)g(one)g(mes-)0 3481 y(sage)c(reduces)h(the)g(n)n (um)n(b)r(er)g(of)g(round-trips)f(at)i(the)f(exp)r(ense)g(of)h(not)f (pro)n(viding)f(iden)n(tit)n(y)h(protection.)36 b(Iden)n(tit)n(y)26 b(protec-)0 3581 y(tion)32 b(is)f(not)h(pro)n(vided)e(b)r(ecause)h (iden)n(tities)h(are)f(exc)n(hanged)f(b)r(efore)i(a)f(common)g(shared)f (secret)h(has)g(b)r(een)h(established)0 3680 y(and,)d(therefore,)f (encryption)g(of)h(the)g(iden)n(tities)g(is)g(not)g(p)r(ossible.)40 b(The)29 b(follo)n(wing)e(diagram)h(sho)n(ws)f(the)i(messages)f(with)0 3780 y(the)g(p)r(ossible)f(pa)n(yloads)f(sen)n(t)h(in)h(eac)n(h)f (message)f(and)i(notes)f(for)g(an)g(example)g(of)h(the)g(Base)f(Exc)n (hange.)1582 4016 y(BASE)g(EX)n(CHANGE)104 4215 y(#)318 b(Initiator)299 b(Direction)259 b(Resp)r(onder)880 b(NOTE)p 36 4248 3829 4 v 85 4315 a(\(1\))100 b(HDR;)29 b(SA;)f(NONCE)202 b(=)p Fd(>)1004 b Fk(Begin)27 b(ISAKMP-SA)h(or)e(Pro)n(xy)g (negotiation)85 4514 y(\(2\))1005 b Fd(<)p Fk(=)202 b(HDR;)29 b(SA;)f(NONCE)2330 4613 y(Basic)f(SA)h(agreed)e(up)r(on)85 4713 y(\(3\))100 b(HDR;)29 b(KE;)522 b(=)p Fd(>)291 4813 y Fk(IDii;)28 b(A)n(UTH)1605 b(Key)27 b(Generated)g(\(b)n(y)h(resp)r (onder\))2330 4912 y(Initiator)f(Iden)n(tit)n(y)h(V)-7 b(eri\014ed)27 b(b)n(y)h(Resp)r(onder)85 5012 y(\(4\))1005 b Fd(<)p Fk(=)202 b(HDR;)29 b(KE;)1528 5112 y(IDir;)f(A)n(UTH)2330 5211 y(Resp)r(onder)f(Iden)n(tit)n(y)h(V)-7 b(eri\014ed)27 b(b)n(y)h(Initiator)2330 5311 y(Key)f(Generated)g(\(b)n(y)h (initiator\))2330 5411 y(SA)g(established)0 5656 y(Maughan,)f(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(41])p eop %%Page: 42 42 42 41 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(In)34 b(the)g(\014rst)g(message)e (\(1\),)k(the)e(initiator)g(generates)e(a)h(prop)r(osal)g(it)h (considers)f(adequate)g(to)h(protect)f(tra\016c)g(for)h(the)0 490 y(giv)n(en)d(situation.)49 b(The)32 b(Securit)n(y)f(Asso)r (ciation,)h(Prop)r(osal,)f(and)g(T)-7 b(ransform)31 b(pa)n(yloads)e (are)i(included)h(in)g(the)h(Securit)n(y)0 589 y(Asso)r(ciation)c(pa)n (yload)g(\(for)g(notation)h(purp)r(oses\).)43 b(Random)30 b(information)f(whic)n(h)h(is)g(used)g(to)g(guaran)n(tee)e(liv)n(eness) h(and)0 689 y(protect)e(against)f(repla)n(y)g(attac)n(ks)g(is)i(also)e (transmitted.)37 b(Random)27 b(information)g(pro)n(vided)f(b)n(y)h(b)r (oth)h(parties)e(SHOULD)0 789 y(b)r(e)i(used)g(b)n(y)f(the)h(authen)n (tication)f(mec)n(hanism)g(to)h(pro)n(vide)e(shared)h(pro)r(of)g(of)g (participation)g(in)h(the)g(exc)n(hange.)0 988 y(In)34 b(the)g(second)f(message)f(\(2\),)k(the)e(resp)r(onder)f(indicates)g (the)h(protection)f(suite)h(it)h(has)e(accepted)g(with)h(the)h(Securit) n(y)0 1088 y(Asso)r(ciation,)k(Prop)r(osal,)e(and)g(T)-7 b(ransform)36 b(pa)n(yloads.)64 b(Again,)39 b(random)e(information)f (whic)n(h)i(is)f(used)g(to)g(guaran)n(tee)0 1187 y(liv)n(eness)20 b(and)h(protect)g(against)f(repla)n(y)g(attac)n(ks)f(is)i(also)f (transmitted.)35 b(Random)21 b(information)f(pro)n(vided)h(b)n(y)f(b)r (oth)i(parties)0 1287 y(SHOULD)h(b)r(e)g(used)g(b)n(y)f(the)i(authen)n (tication)e(mec)n(hanism)g(to)h(pro)n(vide)e(shared)h(pro)r(of)g(of)h (participation)e(in)i(the)g(exc)n(hange.)0 1386 y(Lo)r(cal)30 b(securit)n(y)g(p)r(olicy)g(dictates)h(the)g(action)f(of)h(the)g(resp)r (onder)e(if)i(no)g(prop)r(osed)e(protection)h(suite)h(is)g(accepted.)45 b(One)0 1486 y(p)r(ossible)27 b(action)g(is)h(the)g(transmission)e(of)i (a)f(Notify)h(pa)n(yload)e(as)h(part)g(of)g(an)h(Informational)e(Exc)n (hange.)0 1685 y(In)g(the)g(third)g(\(3\))g(and)f(fourth)h(\(4\))g (messages,)f(the)h(initiator)f(and)h(resp)r(onder,)f(resp)r(ectiv)n (ely)-7 b(,)25 b(exc)n(hange)f(k)n(eying)h(material)0 1785 y(used)32 b(to)h(arriv)n(e)e(at)h(a)g(common)g(shared)g(secret)f (and)i(iden)n(ti\014cation)f(information.)51 b(This)33 b(information)f(is)g(transmitted)0 1885 y(under)26 b(the)g(protection)f (of)h(the)h(agreed)d(up)r(on)i(authen)n(tication)g(function.)37 b(Lo)r(cal)25 b(securit)n(y)g(p)r(olicy)h(dictates)g(the)g(action)g(if) 0 1984 y(an)j(error)f(o)r(ccurs)g(during)i(these)f(messages.)41 b(One)29 b(p)r(ossible)h(action)f(is)g(the)h(transmission)e(of)i(a)f (Notify)h(pa)n(yload)e(as)h(part)0 2084 y(of)f(an)f(Informational)f (Exc)n(hange.)0 2416 y Fj(4.5)112 b(Iden)m(tit)m(y)36 b(Protection)g(Exc)m(hange)0 2669 y Fk(The)29 b(Iden)n(tit)n(y)g (Protection)e(Exc)n(hange)g(is)i(designed)f(to)h(separate)f(the)h(Key)f (Exc)n(hange)f(information)h(from)h(the)g(Iden)n(tit)n(y)0 2768 y(and)22 b(Authen)n(tication)h(related)f(information.)35 b(Separating)21 b(the)i(Key)f(Exc)n(hange)f(from)h(the)h(Iden)n(tit)n (y)f(and)h(Authen)n(tication)0 2868 y(related)35 b(information)g(pro)n (vides)f(protection)h(of)h(the)g(comm)n(unicating)e(iden)n(tities)i(at) g(the)g(exp)r(ense)f(of)h(t)n(w)n(o)f(additional)0 2968 y(messages.)40 b(Iden)n(tities)29 b(are)f(exc)n(hanged)g(under)h(the)g (protection)g(of)g(a)f(previously)g(established)h(common)g(shared)f (secret.)0 3067 y(The)e(follo)n(wing)e(diagram)g(sho)n(ws)h(the)h (messages)e(with)i(the)g(p)r(ossible)f(pa)n(yloads)f(sen)n(t)i(in)f (eac)n(h)g(message)g(and)g(notes)g(for)g(an)0 3167 y(example)i(of)h (the)g(Iden)n(tit)n(y)f(Protection)g(Exc)n(hange.)1235 3527 y(IDENTITY)h(PR)n(OTECTION)d(EX)n(CHANGE)68 3726 y(#)325 b(Initiator)305 b(Direction)270 b(Resp)r(onder)f(NOTE)p 0 3760 4007 4 v 50 3826 a(\(1\))100 b(HDR;)28 b(SA)572 b(=)p Fd(>)1025 b Fk(Begin)27 b(ISAKMP-SA)h(or)e(Pro)n(xy)g (negotiation)50 3926 y(\(2\))1017 b Fd(<)p Fk(=)202 b(HDR;)29 b(SA)2328 4025 y(Basic)e(SA)h(agreed)e(up)r(on)50 4125 y(\(3\))100 b(HDR;)28 b(KE;)f(NONCE)202 b(=)p Fd(>)50 4225 y Fk(\(4\))1017 b Fd(<)p Fk(=)202 b(HDR;)29 b(KE;)e(NONCE)2328 4324 y(Key)g(Generated)g(\(b)n(y)h(Initiator)f(and)g(Resp)r(onder\))50 4424 y(\(5\))100 b(HDR*;)28 b(IDii;)g(A)n(UTH)204 b(=)p Fd(>)2328 4523 y Fk(Initiator)27 b(Iden)n(tit)n(y)h(V)-7 b(eri\014ed)28 b(b)n(y)f(Resp)r(onder)50 4623 y(\(6\))1017 b Fd(<)p Fk(=)202 b(HDR*;)29 b(IDir;)e(A)n(UTH)2328 4723 y(Resp)r(onder)g(Iden)n(tit)n(y)h(V)-7 b(eri\014ed)28 b(b)n(y)f(Initiator)2328 4822 y(SA)h(established)0 5105 y(In)34 b(the)g(\014rst)g(message)e(\(1\),)k(the)e(initiator)g (generates)e(a)h(prop)r(osal)g(it)h(considers)f(adequate)g(to)h (protect)f(tra\016c)g(for)h(the)0 5205 y(giv)n(en)d(situation.)49 b(The)32 b(Securit)n(y)f(Asso)r(ciation,)h(Prop)r(osal,)f(and)g(T)-7 b(ransform)31 b(pa)n(yloads)e(are)i(included)h(in)g(the)h(Securit)n(y)0 5305 y(Asso)r(ciation)27 b(pa)n(yload)f(\(for)h(notation)g(purp)r (oses\).)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(42])p eop %%Page: 43 43 43 42 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(In)34 b(the)g(second)f(message)f (\(2\),)k(the)e(resp)r(onder)f(indicates)g(the)h(protection)f(suite)h (it)h(has)e(accepted)g(with)h(the)h(Securit)n(y)0 490 y(Asso)r(ciation,)c(Prop)r(osal,)f(and)h(T)-7 b(ransform)30 b(pa)n(yloads.)46 b(Lo)r(cal)30 b(securit)n(y)g(p)r(olicy)h(dictates)g (the)h(action)f(of)g(the)g(resp)r(onder)0 589 y(if)g(no)f(prop)r(osed)g (protection)f(suite)i(is)f(accepted.)46 b(One)30 b(p)r(ossible)g (action)g(is)g(the)h(transmission)e(of)i(a)f(Notify)h(pa)n(yload)e(as)0 689 y(part)e(of)h(an)f(Informational)f(Exc)n(hange.)0 888 y(In)g(the)g(third)g(\(3\))g(and)f(fourth)h(\(4\))g(messages,)f (the)h(initiator)f(and)h(resp)r(onder,)f(resp)r(ectiv)n(ely)-7 b(,)25 b(exc)n(hange)f(k)n(eying)h(material)0 988 y(used)k(to)g(arriv)n (e)f(at)h(a)g(common)f(shared)g(secret)h(and)g(random)f(information)h (whic)n(h)g(is)g(used)g(to)h(guaran)n(tee)d(liv)n(eness)h(and)0 1088 y(protect)36 b(against)f(repla)n(y)g(attac)n(ks.)62 b(Random)36 b(information)f(pro)n(vided)h(b)n(y)g(b)r(oth)g(parties)g (SHOULD)h(b)r(e)f(used)h(b)n(y)f(the)0 1187 y(authen)n(tication)c(mec)n (hanism)h(to)f(pro)n(vide)g(shared)g(pro)r(of)g(of)g(participation)g (in)h(the)g(exc)n(hange.)51 b(Lo)r(cal)32 b(securit)n(y)g(p)r(olicy)0 1287 y(dictates)h(the)h(action)e(if)i(an)f(error)e(o)r(ccurs)h(during)h (these)g(messages.)52 b(One)33 b(p)r(ossible)g(action)g(is)g(the)g (transmission)f(of)h(a)0 1386 y(Notify)28 b(pa)n(yload)e(as)h(part)g (of)h(an)f(Informational)f(Exc)n(hange.)0 1586 y(In)37 b(the)g(\014fth)h(\(5\))f(and)g(sixth)g(\(6\))g(messages,)h(the)f (initiator)f(and)h(resp)r(onder,)h(resp)r(ectiv)n(ely)-7 b(,)39 b(exc)n(hange)c(iden)n(ti\014cation)0 1685 y(information)g(and)g (the)g(results)g(of)g(the)h(agreed)d(up)r(on)j(authen)n(tication)f (function.)60 b(This)35 b(information)g(is)g(transmitted)0 1785 y(under)i(the)h(protection)f(of)g(the)h(common)e(shared)h(secret.) 65 b(Lo)r(cal)37 b(securit)n(y)f(p)r(olicy)h(dictates)h(the)f(action)g (if)h(an)f(error)0 1885 y(o)r(ccurs)d(during)h(these)g(messages.)59 b(One)35 b(p)r(ossible)g(action)f(is)i(the)f(transmission)f(of)h(a)g (Notify)h(pa)n(yload)e(as)g(part)h(of)g(an)0 1984 y(Informational)26 b(Exc)n(hange.)0 2316 y Fj(4.6)112 b(Authen)m(tication)36 b(Only)h(Exc)m(hange)0 2569 y Fk(The)23 b(Authen)n(tication)g(Only)f (Exc)n(hange)f(is)i(designed)f(to)h(allo)n(w)f(only)g(Authen)n (tication)h(related)f(information)g(to)h(b)r(e)g(trans-)0 2669 y(mitted.)36 b(The)24 b(b)r(ene\014t)g(of)f(this)g(exc)n(hange)f (is)h(the)h(abilit)n(y)e(to)h(p)r(erform)g(only)g(authen)n(tication)g (without)g(the)h(computational)0 2768 y(exp)r(ense)33 b(of)h(computing)f(k)n(eys.)54 b(Using)33 b(this)h(exc)n(hange)e (during)h(negotiation,)h(none)f(of)g(the)h(transmitted)g(information)0 2868 y(will)c(b)r(e)f(encrypted.)42 b(Ho)n(w)n(ev)n(er,)28 b(the)i(information)e(ma)n(y)h(b)r(e)h(encrypted)f(in)g(other)g (places.)42 b(F)-7 b(or)28 b(example,)i(if)g(encryption)0 2968 y(is)35 b(negotiated)f(during)h(the)g(\014rst)g(phase)g(of)g(a)f (negotiation)g(and)h(the)h(authen)n(tication)e(only)h(exc)n(hange)e(is) i(used)g(in)h(the)0 3067 y(second)23 b(phase)h(of)g(a)f(negotiation,)h (then)g(the)h(authen)n(tication)e(only)h(exc)n(hange)e(will)i(b)r(e)h (encrypted)e(b)n(y)h(the)g(ISAKMP)g(SAs)0 3167 y(negotiated)h(in)h(the) g(\014rst)f(phase.)36 b(The)25 b(follo)n(wing)g(diagram)f(sho)n(ws)h (the)h(messages)d(with)k(p)r(ossible)e(pa)n(yloads)f(sen)n(t)h(in)h (eac)n(h)0 3267 y(message)g(and)i(notes)f(for)g(an)g(example)g(of)h (the)g(Authen)n(tication)g(Only)f(Exc)n(hange.)1170 3543 y(A)n(UTHENTICA)-7 b(TION)28 b(ONL)-7 b(Y)28 b(EX)n(CHANGE)92 3743 y(#)318 b(Initiator)299 b(Direction)271 b(Resp)r(onder)891 b(NOTE)p 24 3776 3852 4 v 74 3842 a(\(1\))100 b(HDR;)28 b(SA;)g(NONCE)203 b(=)p Fd(>)1027 b Fk(Begin)27 b(ISAKMP-SA)g(or)g(Pro) n(xy)e(negotiation)74 4041 y(\(2\))1005 b Fd(<)p Fk(=)202 b(HDR;)28 b(SA;)g(NONCE;)1517 4141 y(IDir;)f(A)n(UTH)2342 4241 y(Basic)f(SA)i(agreed)f(up)r(on)2342 4340 y(Resp)r(onder)g(Iden)n (tit)n(y)g(V)-7 b(eri\014ed)28 b(b)n(y)f(Initiator)74 4440 y(\(3\))100 b(HDR;)28 b(IDii;)g(A)n(UTH)234 b(=)p Fd(>)2342 4540 y Fk(Initiator)27 b(Iden)n(tit)n(y)g(V)-7 b(eri\014ed)28 b(b)n(y)f(Resp)r(onder)2342 4639 y(SA)h(established)0 4922 y(In)34 b(the)g(\014rst)g(message)e(\(1\),)k(the)e(initiator)g (generates)e(a)h(prop)r(osal)g(it)h(considers)f(adequate)g(to)h (protect)f(tra\016c)g(for)h(the)0 5022 y(giv)n(en)d(situation.)49 b(The)32 b(Securit)n(y)f(Asso)r(ciation,)h(Prop)r(osal,)f(and)g(T)-7 b(ransform)31 b(pa)n(yloads)e(are)i(included)h(in)g(the)h(Securit)n(y)0 5122 y(Asso)r(ciation)c(pa)n(yload)g(\(for)g(notation)h(purp)r(oses\).) 43 b(Random)30 b(information)f(whic)n(h)h(is)g(used)g(to)g(guaran)n (tee)e(liv)n(eness)h(and)0 5221 y(protect)e(against)f(repla)n(y)g (attac)n(ks)g(is)i(also)e(transmitted.)37 b(Random)27 b(information)g(pro)n(vided)f(b)n(y)h(b)r(oth)h(parties)e(SHOULD)0 5321 y(b)r(e)i(used)g(b)n(y)f(the)h(authen)n(tication)f(mec)n(hanism)g (to)h(pro)n(vide)e(shared)h(pro)r(of)g(of)g(participation)g(in)h(the)g (exc)n(hange.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(43])p eop %%Page: 44 44 44 43 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(In)34 b(the)g(second)f(message)f (\(2\),)k(the)e(resp)r(onder)f(indicates)g(the)h(protection)f(suite)h (it)h(has)e(accepted)g(with)h(the)h(Securit)n(y)0 490 y(Asso)r(ciation,)k(Prop)r(osal,)e(and)g(T)-7 b(ransform)36 b(pa)n(yloads.)64 b(Again,)39 b(random)e(information)f(whic)n(h)i(is)f (used)g(to)g(guaran)n(tee)0 589 y(liv)n(eness)20 b(and)h(protect)g (against)f(repla)n(y)g(attac)n(ks)f(is)i(also)f(transmitted.)35 b(Random)21 b(information)f(pro)n(vided)h(b)n(y)f(b)r(oth)i(parties)0 689 y(SHOULD)h(b)r(e)g(used)g(b)n(y)f(the)i(authen)n(tication)e(mec)n (hanism)g(to)h(pro)n(vide)e(shared)h(pro)r(of)g(of)h(participation)e (in)i(the)g(exc)n(hange.)0 789 y(Additionally)-7 b(,)24 b(the)e(resp)r(onder)f(transmits)h(iden)n(ti\014cation)g(information.) 35 b(All)22 b(of)h(this)f(information)g(is)g(transmitted)g(under)0 888 y(the)31 b(protection)f(of)g(the)h(agreed)e(up)r(on)i(authen)n (tication)f(function.)47 b(Lo)r(cal)30 b(securit)n(y)f(p)r(olicy)i (dictates)f(the)h(action)f(of)h(the)0 988 y(resp)r(onder)g(if)i(no)f (prop)r(osed)f(protection)h(suite)g(is)g(accepted.)51 b(One)32 b(p)r(ossible)g(action)g(is)g(the)h(transmission)e(of)h(a)g (Notify)0 1088 y(pa)n(yload)26 b(as)h(part)g(of)h(an)f(Informational)f (Exc)n(hange.)0 1287 y(In)i(the)g(third)g(message)e(\(3\),)i(the)h (initiator)e(transmits)g(iden)n(ti\014cation)h(information.)36 b(This)28 b(information)f(is)h(transmitted)0 1386 y(under)e(the)g (protection)f(of)h(the)h(agreed)d(up)r(on)i(authen)n(tication)g (function.)37 b(Lo)r(cal)25 b(securit)n(y)g(p)r(olicy)h(dictates)g(the) g(action)g(if)0 1486 y(an)j(error)f(o)r(ccurs)g(during)i(these)f (messages.)41 b(One)29 b(p)r(ossible)h(action)f(is)g(the)h (transmission)e(of)i(a)f(Notify)h(pa)n(yload)e(as)h(part)0 1586 y(of)f(an)f(Informational)f(Exc)n(hange.)0 1917 y Fj(4.7)112 b(Aggressiv)m(e)37 b(Exc)m(hange)0 2170 y Fk(The)29 b(Aggressiv)n(e)e(Exc)n(hange)h(is)h(designed)g(to)g(allo)n (w)f(the)i(Securit)n(y)f(Asso)r(ciation,)g(Key)f(Exc)n(hange)g(and)h (Authen)n(tication)0 2269 y(related)40 b(pa)n(yloads)g(to)g(b)r(e)i (transmitted)f(together.)76 b(Com)n(bining)41 b(the)g(Securit)n(y)g (Asso)r(ciation,)i(Key)e(Exc)n(hange,)h(and)0 2369 y(Authen)n (tication-related)32 b(information)h(in)n(to)f(one)h(message)f(reduces) g(the)h(n)n(um)n(b)r(er)g(of)g(round-trips)f(at)h(the)g(exp)r(ense)g (of)0 2468 y(not)23 b(pro)n(viding)e(iden)n(tit)n(y)h(protection.)35 b(Iden)n(tit)n(y)22 b(protection)g(is)h(not)f(pro)n(vided)g(b)r(ecause) g(iden)n(tities)h(are)e(exc)n(hanged)g(b)r(efore)0 2568 y(a)35 b(common)h(shared)e(secret)h(has)h(b)r(een)g(established)f(and,) j(therefore,)f(encryption)e(of)h(the)g(iden)n(tities)g(is)g(not)f(p)r (ossible.)0 2668 y(Additionally)-7 b(,)26 b(the)f(Aggressiv)n(e)e(Exc)n (hange)g(is)h(attempting)i(to)e(establish)h(all)g(securit)n(y)f(relev) -5 b(an)n(t)24 b(information)g(in)h(a)g(single)0 2767 y(exc)n(hange.)35 b(The)25 b(follo)n(wing)f(diagram)f(sho)n(ws)h(the)i (messages)d(with)j(p)r(ossible)f(pa)n(yloads)e(sen)n(t)i(in)g(eac)n(h)g (message)e(and)i(notes)0 2867 y(for)i(an)g(example)h(of)f(the)h (Aggressiv)n(e)d(Exc)n(hange.)1419 3138 y(A)n(GGRESSIVE)j(EX)n(CHANGE) 135 3337 y(#)238 b(Initiator)218 b(Direction)309 b(Resp)r(onder)928 b(NOTE)p 67 3370 3766 4 v 117 3437 a(\(1\))100 b(HDR;)28 b(SA;)g(KE;)202 b(=)p Fd(>)1103 b Fk(Begin)27 b(ISAKMP-SA)g(or)g(Pro)n (xy)e(negotiation)323 3536 y(NONCE;)i(IDii)1481 b(and)27 b(Key)g(Exc)n(hange)117 3735 y(\(2\))843 b Fd(<)p Fk(=)202 b(HDR;)29 b(SA;)f(KE;)1398 3835 y(NONCE;)g(IDir;)f(A)n(UTH)2299 3935 y(Initiator)g(Iden)n(tit)n(y)g(V)-7 b(eri\014ed)28 b(b)n(y)f(Resp)r(onder)2299 4034 y(Key)g(Generated)2299 4134 y(Basic)f(SA)i(agreed)e(up)r(on)117 4234 y(\(3\))100 b(HDR*;)28 b(A)n(UTH)220 b(=)p Fd(>)2299 4333 y Fk(Resp)r(onder)27 b(Iden)n(tit)n(y)g(V)-7 b(eri\014ed)28 b(b)n(y)f(Initiator)2299 4433 y(SA)h(established)0 4710 y(In)34 b(the)g(\014rst)g(message)e (\(1\),)k(the)e(initiator)g(generates)e(a)h(prop)r(osal)g(it)h (considers)f(adequate)g(to)h(protect)f(tra\016c)g(for)h(the)0 4809 y(giv)n(en)d(situation.)49 b(The)32 b(Securit)n(y)f(Asso)r (ciation,)h(Prop)r(osal,)f(and)g(T)-7 b(ransform)31 b(pa)n(yloads)e (are)i(included)h(in)g(the)h(Securit)n(y)0 4909 y(Asso)r(ciation)22 b(pa)n(yload)g(\(for)h(notation)g(purp)r(oses\).)35 b(There)22 b(can)h(b)r(e)h(only)e(one)h(Prop)r(osal)e(and)i(one)g(T)-7 b(ransform)22 b(o\013ered)h(\(i.e.)0 5009 y(no)g(c)n(hoices\))g(in)h (order)e(for)h(the)h(aggressiv)n(e)d(exc)n(hange)h(to)i(w)n(ork.)34 b(Keying)23 b(material)f(used)i(to)f(arriv)n(e)f(at)i(a)f(common)g (shared)0 5108 y(secret)32 b(and)g(random)g(information)g(whic)n(h)g (is)g(used)h(to)f(guaran)n(tee)f(liv)n(eness)h(and)g(protect)g(against) g(repla)n(y)f(attac)n(ks)g(are)0 5208 y(also)h(transmitted.)52 b(Random)32 b(information)g(pro)n(vided)g(b)n(y)h(b)r(oth)g(parties)f (SHOULD)h(b)r(e)g(used)g(b)n(y)f(the)h(authen)n(tication)0 5308 y(mec)n(hanism)f(to)g(pro)n(vide)g(shared)f(pro)r(of)h(of)h (participation)f(in)g(the)h(exc)n(hange.)51 b(Additionally)-7 b(,)34 b(the)e(initiator)h(transmits)0 5407 y(iden)n(ti\014cation)27 b(information.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(44])p eop %%Page: 45 45 45 44 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(In)34 b(the)g(second)f(message)f (\(2\),)k(the)e(resp)r(onder)f(indicates)g(the)h(protection)f(suite)h (it)h(has)e(accepted)g(with)h(the)h(Securit)n(y)0 490 y(Asso)r(ciation,)28 b(Prop)r(osal,)e(and)j(T)-7 b(ransform)27 b(pa)n(yloads.)37 b(Keying)28 b(material)g(used)g(to)g(arriv)n(e)f(at)h (a)g(common)g(shared)g(secret)0 589 y(and)d(random)f(information)g (whic)n(h)h(is)g(used)g(to)g(guaran)n(tee)e(liv)n(eness)h(and)h (protect)f(against)g(repla)n(y)g(attac)n(ks)f(is)i(also)f(trans-)0 689 y(mitted.)38 b(Random)27 b(information)h(pro)n(vided)e(b)n(y)i(b)r (oth)g(parties)f(SHOULD)h(b)r(e)g(used)g(b)n(y)f(the)h(authen)n (tication)g(mec)n(hanism)0 789 y(to)23 b(pro)n(vide)f(shared)g(pro)r (of)g(of)h(participation)f(in)h(the)h(exc)n(hange.)33 b(Additionally)-7 b(,)25 b(the)e(resp)r(onder)f(transmits)g(iden)n (ti\014cation)0 888 y(information.)42 b(All)30 b(of)f(this)h (information)f(is)g(transmitted)h(under)f(the)h(protection)f(of)g(the)h (agreed)e(up)r(on)h(authen)n(tication)0 988 y(function.)35 b(Lo)r(cal)19 b(securit)n(y)g(p)r(olicy)h(dictates)g(the)g(action)f(of) h(the)h(resp)r(onder)d(if)j(no)e(prop)r(osed)g(protection)g(suite)h(is) g(accepted.)0 1088 y(One)27 b(p)r(ossible)h(action)f(is)g(the)h (transmission)e(of)i(a)f(Notify)h(pa)n(yload)e(as)h(part)g(of)h(an)f (Informational)f(Exc)n(hange.)0 1287 y(In)e(the)h(third)f(\(3\))g (message,)f(the)h(initiator)g(transmits)f(the)i(results)e(of)h(the)h (agreed)d(up)r(on)i(authen)n(tication)g(function.)36 b(This)0 1386 y(information)25 b(is)h(transmitted)g(under)f(the)i (protection)e(of)h(the)g(common)f(shared)g(secret.)35 b(Lo)r(cal)26 b(securit)n(y)f(p)r(olicy)g(dictates)0 1486 y(the)36 b(action)g(if)g(an)g(error)e(o)r(ccurs)h(during)h(these)g (messages.)60 b(One)36 b(p)r(ossible)g(action)f(is)h(the)g (transmission)f(of)h(a)g(Notify)0 1586 y(pa)n(yload)26 b(as)h(part)g(of)h(an)f(Informational)f(Exc)n(hange.)0 1918 y Fj(4.8)112 b(Informational)36 b(Exc)m(hange)0 2171 y Fk(The)21 b(Informational)f(Exc)n(hange)g(is)h(designed)g(as)f (a)h(one-w)n(a)n(y)e(transmittal)i(of)g(information)g(that)h(can)e(b)r (e)i(used)f(for)g(securit)n(y)0 2270 y(asso)r(ciation)33 b(managemen)n(t.)58 b(The)34 b(follo)n(wing)g(diagram)g(sho)n(ws)f(the) i(messages)e(with)j(p)r(ossible)e(pa)n(yloads)f(sen)n(t)i(in)g(eac)n(h) 0 2370 y(message)26 b(and)i(notes)f(for)g(an)g(example)g(of)h(the)g (Informational)e(Exc)n(hange.)1328 2647 y(INF)n(ORMA)-7 b(TIONAL)28 b(EX)n(CHANGE)593 2846 y(#)190 b(Initiator)171 b(Direction)99 b(Resp)r(onder)519 b(NOTE)p 524 2879 2852 4 v 574 2946 a(\(1\))100 b(HDR*;)28 b(N/D)203 b(=)p Fd(>)684 b Fk(Error)25 b(Noti\014cation)j(or)e(Deletion)0 3229 y(In)i(the)g(\014rst)f(message)f(\(1\),)i(the)g(initiator)f(or)g(resp)r (onder)f(transmits)h(an)h(ISAKMP)f(Notify)h(or)f(Delete)h(pa)n(yload.)0 3428 y(If)h(the)g(Informational)e(Exc)n(hange)g(o)r(ccurs)h(prior)f(to) h(the)h(exc)n(hange)e(of)i(k)n(eying)f(meterial)g(during)g(an)g(ISAKMP) g(Phase)f(1)0 3528 y(negotiation,)f(there)g(will)h(b)r(e)g(no)g (protection)f(pro)n(vided)f(for)i(the)g(Informational)e(Exc)n(hange.)35 b(Once)26 b(k)n(eying)g(material)g(has)0 3627 y(b)r(een)e(exc)n(hanged) e(or)h(an)g(ISAKMP)g(SA)i(has)e(b)r(een)h(established,)g(the)g (Informational)e(Exc)n(hange)g(MUST)i(b)r(e)g(transmitted)0 3727 y(under)j(the)h(protection)f(pro)n(vided)g(b)n(y)g(the)h(k)n (eying)f(material)f(or)h(the)h(ISAKMP)f(SA.)0 3926 y(All)h(exc)n (hanges)e(are)h(similar)f(in)i(that)g(with)g(the)g(b)r(eginning)g(of)f (an)n(y)g(exc)n(hange)f(cryptographic)g(sync)n(hronization)g(MUST)0 4026 y(o)r(ccur.)34 b(The)22 b(Informational)f(Exc)n(hange)f(is)i(an)g (exc)n(hange)f(and)h(not)g(an)f(ISAKMP)h(message.)34 b(Th)n(us,)22 b(the)h(generation)d(of)i(an)0 4125 y(Initialization)27 b(V)-7 b(ector)26 b(\(IV\))i(for)f(an)g(Informational)f(Exc)n(hange)f (SHOULD)j(b)r(e)f(indep)r(enden)n(t)h(of)f(IVs)g(of)g(other)g(on-going) 0 4225 y(comm)n(unication.)43 b(This)29 b(will)h(ensure)g (cryptographic)d(sync)n(hronization)h(is)i(main)n(tained)f(for)h (existing)f(comm)n(unications)0 4325 y(and)e(the)h(Informational)f(Exc) n(hange)f(will)h(b)r(e)h(pro)r(cessed)f(correctly)-7 b(.)0 4699 y Ff(5)137 b(ISAKMP)46 b(P)l(a)l(yload)f(Pro)t(cessing)0 4980 y Fk(Section)31 b(3)f(describ)r(es)g(the)i(ISAKMP)e(pa)n(yloads.) 45 b(These)30 b(pa)n(yloads)f(are)h(used)h(in)g(the)g(exc)n(hanges)e (describ)r(ed)h(in)h(section)0 5080 y(4)c(and)h(can)g(b)r(e)g(used)g (in)g(exc)n(hanges)e(de\014ned)i(for)g(a)f(sp)r(eci\014c)h(DOI.)g(This) g(section)g(describ)r(es)f(the)h(pro)r(cessing)f(for)g(eac)n(h)g(of)0 5179 y(the)h(pa)n(yloads.)34 b(This)28 b(section)e(suggests)g(the)i (logging)d(of)i(ev)n(en)n(ts)g(to)g(a)f(system)h(audit)h(\014le.)37 b(This)27 b(action)f(is)h(con)n(trolled)f(b)n(y)0 5279 y(a)h(system)h(securit)n(y)e(p)r(olicy)i(and)f(is,)h(therefore,)e(only) i(a)f(suggested)f(action.)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(45])p eop %%Page: 46 46 46 45 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(5.1)112 b(General)38 b(Message)h(Pro)s(cessing)0 643 y Fk(Ev)n(ery)24 b(ISAKMP)h(message)g (has)g(basic)g(pro)r(cessing)f(applied)i(to)g(insure)f(proto)r(col)g (reliabilit)n(y)-7 b(,)25 b(and)h(to)f(minimize)i(threats,)0 743 y(suc)n(h)f(as)g(denial)g(of)g(service)g(and)g(repla)n(y)f(attac)n (ks.)35 b(All)27 b(pro)r(cessing)e(SHOULD)i(include)g(pac)n(k)n(et)e (length)i(c)n(hec)n(ks)e(to)i(insure)0 842 y(the)h(pac)n(k)n(et)f (receiv)n(ed)f(is)i(at)f(least)g(as)g(long)g(as)g(the)h(length)g(giv)n (en)e(in)i(the)g(ISAKMP)f(Header.)0 1042 y(When)37 b(transmitting)g(an) g(ISAKMP)f(message,)i(the)f(transmitting)g(en)n(tit)n(y)f(\(initiator)h (or)f(resp)r(onder\))g(MUST)h(do)g(the)0 1141 y(follo)n(wing:)101 1414 y(1.)42 b(Set)28 b(a)f(timer)g(and)h(initialize)f(a)h(retry)e (coun)n(ter.)101 1545 y(2.)42 b(If)28 b(the)g(timer)f(expires,)g(the)h (ISAKMP)f(message)f(is)i(resen)n(t)f(and)g(the)h(retry)f(coun)n(ter)g (is)g(decremen)n(ted.)101 1676 y(3.)42 b(If)33 b(the)g(retry)e(coun)n (ter)h(reac)n(hes)f(zero)h(\(0\),)i(the)f(ev)n(en)n(t,)h Fb(RETR)-6 b(Y)33 b(LIMIT)i(REA)n(CHED)p Fk(,)e(MA)-7 b(Y)33 b(b)r(e)g(logged)f(in)h(the)208 1776 y(appropriate)25 b(system)j(audit)g(\014le.)101 1907 y(4.)42 b(The)27 b(ISAKMP)g(proto)r(col)g(mac)n(hine)g(clears)f(all)i(states)f(and)g (returns)g(to)h(IDLE.)0 2237 y Fj(5.2)112 b(ISAKMP)37 b(Header)h(Pro)s(cessing)0 2490 y Fk(When)22 b(creating)e(an)g(ISAKMP)h (message,)g(the)h(transmitting)f(en)n(tit)n(y)g(\(initiator)g(or)f (resp)r(onder\))g(MUST)i(do)f(the)g(follo)n(wing:)101 2763 y(1.)42 b(Create)26 b(the)i(resp)r(ectiv)n(e)f(co)r(okie.)36 b(See)28 b(section)f(2.5.3)f(for)h(details.)101 2894 y(2.)42 b(Determine)28 b(the)g(relev)-5 b(an)n(t)26 b(securit)n(y)h(c)n (haracteristics)e(of)j(the)g(session)e(\(i.e.)38 b(DOI)27 b(and)h(situation\).)101 3024 y(3.)42 b(Construct)27 b(an)g(ISAKMP)g(Header)g(with)h(\014elds)g(as)f(describ)r(ed)g(in)h (section)f(3.1.)101 3155 y(4.)42 b(Construct)27 b(other)g(ISAKMP)g(pa)n (yloads,)f(dep)r(ending)i(on)f(the)h(exc)n(hange)e(t)n(yp)r(e.)101 3286 y(5.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h (destination)g(host)f(as)g(describ)r(ed)g(in)h(section)f(5.1.)0 3559 y(When)e(an)g(ISAKMP)f(message)g(is)g(receiv)n(ed,)h(the)g (receiving)f(en)n(tit)n(y)g(\(initiator)h(or)f(resp)r(onder\))g(MUST)h (do)g(the)g(follo)n(wing:)101 3832 y(1.)42 b(V)-7 b(erify)30 b(the)i(Initiator)e(and)h(Resp)r(onder)f(\\co)r(okies".)44 b(If)32 b(the)f(co)r(okie)f(v)-5 b(alidation)30 b(fails,)i(the)f (message)e(is)i(discarded)208 3932 y(and)c(the)h(follo)n(wing)f (actions)f(are)h(tak)n(en:)243 4094 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(COOKIE)p Fk(,)g(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system)h(audit)h (\014le.)238 4208 y(\(b\))42 b(An)28 b(Informational)e(Exc)n(hange)f (with)i(a)g(Noti\014cation)g(pa)n(yload)e(con)n(taining)h(the)i(INV)-9 b(ALID-COOKIE)25 b(mes-)390 4308 y(sage)30 b(t)n(yp)r(e)h(MA)-7 b(Y)32 b(b)r(e)f(sen)n(t)g(to)g(the)g(transmitting)g(en)n(tit)n(y)-7 b(.)47 b(This)31 b(action)f(is)h(dictated)g(b)n(y)g(a)f(system)h (securit)n(y)390 4408 y(p)r(olicy)-7 b(.)101 4570 y(2.)42 b(Chec)n(k)36 b(the)h(Next)g(P)n(a)n(yload)d(\014eld)j(to)g(con\014rm)f (it)h(is)g(v)-5 b(alid.)65 b(If)37 b(the)g(Next)g(P)n(a)n(yload)d (\014eld)j(v)-5 b(alidation)37 b(fails,)i(the)208 4669 y(message)26 b(is)h(discarded)g(and)g(the)h(follo)n(wing)f(actions)g (are)f(tak)n(en:)243 4832 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(NEXT)i(P)-6 b(A)g(YLO)n(AD)p Fk(,)26 b(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system)h (audit)h(\014le.)238 4946 y(\(b\))42 b(An)d(Informational)e(Exc)n (hange)f(with)i(a)g(Noti\014cation)g(pa)n(yload)e(con)n(taining)h(the)i (INV)-9 b(ALID-P)i(A)g(YLO)n(AD-)390 5046 y(TYPE)25 b(message)f(t)n(yp) r(e)i(MA)-7 b(Y)26 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n (tit)n(y)-7 b(.)36 b(This)26 b(action)f(is)g(dictated)h(b)n(y)f(a)g (system)390 5145 y(securit)n(y)i(p)r(olicy)-7 b(.)101 5308 y(3.)42 b(Chec)n(k)29 b(the)h(Ma)5 b(jor)28 b(and)i(Minor)f(V)-7 b(ersion)29 b(\014elds)h(to)f(con\014rm)h(they)g(are)e(correct.)42 b(If)30 b(the)g(V)-7 b(ersion)30 b(\014eld)g(v)-5 b(alidation)208 5407 y(fails,)27 b(the)h(message)e(is)i(discarded)e(and)i(the)g(follo)n (wing)e(actions)h(are)g(tak)n(en:)0 5656 y(Maughan,)g(Sc)n(hertler,)f (Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(46])p eop %%Page: 47 47 47 46 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)243 390 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(ISAKMP)i(VERSION)p Fk(,)c(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g(appropriate)e(system) h(audit)h(\014le.)238 506 y(\(b\))42 b(An)19 b(Informational)e(Exc)n (hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i (INV)-9 b(ALID-MAJOR-VERSION)390 606 y(or)27 b(INV)-9 b(ALID-MINOR-VERSION)27 b(message)f(t)n(yp)r(e)i(MA)-7 b(Y)28 b(b)r(e)g(sen)n(t)f(to)h(the)f(transmitting)h(en)n(tit)n(y)-7 b(.)37 b(This)27 b(ac-)390 706 y(tion)h(is)f(dictated)h(b)n(y)g(a)f (system)g(securit)n(y)g(p)r(olicy)-7 b(.)101 872 y(4.)42 b(Chec)n(k)29 b(the)h(Exc)n(hange)d(T)n(yp)r(e)j(\014eld)g(to)f (con\014rm)g(it)h(is)g(v)-5 b(alid.)43 b(If)30 b(the)g(Exc)n(hange)d(T) n(yp)r(e)j(\014eld)g(v)-5 b(alidation)29 b(fails,)h(the)208 971 y(message)c(is)h(discarded)g(and)g(the)h(follo)n(wing)f(actions)g (are)f(tak)n(en:)243 1137 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(EX)n(CHANGE)i(TYPE)p Fk(,)e(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g(appropriate)e(system)h(audit)h (\014le.)238 1254 y(\(b\))42 b(An)30 b(Informational)e(Exc)n(hange)g (with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-EX)n(CHANGE-)390 1353 y(TYPE)25 b(message)f(t)n(yp)r(e)i(MA)-7 b(Y)26 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)36 b(This)26 b(action)f(is)g(dictated)h(b)n(y)f(a)g(system)390 1453 y(securit)n(y)i(p)r(olicy)-7 b(.)101 1619 y(5.)42 b(Chec)n(k)22 b(the)i(Flags)f(\014eld)g(to)g(ensure)g(it)h(con)n(tains) e(correct)g(v)-5 b(alues.)35 b(If)24 b(the)g(Flags)e(\014eld)i(v)-5 b(alidation)23 b(fails,)h(the)g(message)208 1719 y(is)j(discarded)g (and)g(the)h(follo)n(wing)f(actions)f(are)h(tak)n(en:)243 1885 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(FLA)n(GS)p Fk(,)g(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g (appropriate)e(system)h(audit)h(\014le.)238 2001 y(\(b\))42 b(An)22 b(Informational)d(Exc)n(hange)g(with)i(a)g(Noti\014cation)f(pa) n(yload)g(con)n(taining)g(the)h(INV)-9 b(ALID-FLA)n(GS)21 b(message)390 2100 y(t)n(yp)r(e)27 b(MA)-7 b(Y)27 b(b)r(e)f(sen)n(t)h (to)f(the)g(transmitting)h(en)n(tit)n(y)-7 b(.)36 b(This)26 b(action)g(is)g(dictated)h(b)n(y)f(a)g(system)g(securit)n(y)f(p)r (olicy)-7 b(.)101 2267 y(6.)42 b(Chec)n(k)25 b(the)i(Message)e(ID)h (\014eld)h(to)f(ensure)f(it)i(con)n(tains)e(correct)g(v)-5 b(alues.)36 b(If)27 b(the)f(Message)f(ID)i(v)-5 b(alidation)25 b(fails,)i(the)208 2366 y(message)f(is)h(discarded)g(and)g(the)h(follo) n(wing)f(actions)g(are)f(tak)n(en:)243 2532 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(MESSA)n(GE)i(ID)p Fk(,)e(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system) h(audit)h(\014le.)238 2648 y(\(b\))42 b(An)28 b(Informational)f(Exc)n (hange)f(with)i(a)f(Noti\014cation)h(pa)n(yload)e(con)n(taining)h(the)h (INV)-9 b(ALID-MESSA)n(GE-ID)390 2748 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 2848 y(p)r(olicy)-7 b(.)101 3014 y(7.)42 b(Pro)r(cessing)25 b(of)j(the)g(ISAKMP)f(message)f(con)n(tin)n(ues)h (using)g(the)h(v)-5 b(alue)28 b(in)f(the)h(Next)g(P)n(a)n(yload)d (\014eld.)0 3346 y Fj(5.3)112 b(Generic)37 b(P)m(a)m(yload)g(Header)h (Pro)s(cessing)0 3599 y Fk(When)21 b(creating)f(an)n(y)f(of)i(the)g (ISAKMP)f(P)n(a)n(yloads)e(describ)r(ed)i(in)h(sections)f(3.4)f (through)h(3.15)f(a)i(Generic)f(P)n(a)n(yload)e(Header)0 3698 y(is)29 b(placed)f(at)h(the)h(b)r(eginning)f(of)f(these)h(pa)n (yloads.)40 b(When)29 b(creating)f(the)h(Generic)g(P)n(a)n(yload)d (Header,)j(the)g(transmitting)0 3798 y(en)n(tit)n(y)f(\(initiator)f(or) g(resp)r(onder\))f(MUST)i(do)g(the)g(follo)n(wing:)101 4080 y(1.)42 b(Place)28 b(the)j(v)-5 b(alue)29 b(of)h(the)g(Next)h(P)n (a)n(yload)c(in)j(the)g(Next)h(P)n(a)n(yload)c(\014eld.)44 b(These)29 b(v)-5 b(alues)30 b(are)f(describ)r(ed)g(in)h(section)208 4180 y(3.1.)101 4313 y(2.)42 b(Place)26 b(the)i(v)-5 b(alue)28 b(zero)e(\(0\))i(in)g(the)g(RESER)-9 b(VED)27 b(\014eld.)101 4445 y(3.)42 b(Place)26 b(the)i(length)g(\(in)g(o)r (ctets\))g(of)f(the)h(pa)n(yload)e(in)i(the)g(P)n(a)n(yload)d(Length)j (\014eld.)101 4578 y(4.)42 b(Construct)27 b(the)h(pa)n(yloads)d(as)i (de\014ned)h(in)g(the)g(remainder)f(of)g(this)h(section.)0 4861 y(When)e(an)n(y)f(of)g(the)h(ISAKMP)g(P)n(a)n(yloads)c(are)j (receiv)n(ed,)g(the)h(receiving)e(en)n(tit)n(y)i(\(initiator)f(or)g (resp)r(onder\))f(MUST)i(do)g(the)0 4960 y(follo)n(wing:)101 5242 y(1.)42 b(Chec)n(k)36 b(the)h(Next)g(P)n(a)n(yload)d(\014eld)j(to) g(con\014rm)f(it)h(is)g(v)-5 b(alid.)65 b(If)37 b(the)g(Next)g(P)n(a)n (yload)d(\014eld)j(v)-5 b(alidation)37 b(fails,)i(the)208 5342 y(message)26 b(is)h(discarded)g(and)g(the)h(follo)n(wing)f (actions)g(are)f(tak)n(en:)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(47])p eop %%Page: 48 48 48 47 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)243 390 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(NEXT)i(P)-6 b(A)g(YLO)n(AD)p Fk(,)26 b(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e (system)h(audit)h(\014le.)238 506 y(\(b\))42 b(An)d(Informational)e (Exc)n(hange)f(with)i(a)g(Noti\014cation)g(pa)n(yload)e(con)n(taining)h (the)i(INV)-9 b(ALID-P)i(A)g(YLO)n(AD-)390 606 y(TYPE)25 b(message)f(t)n(yp)r(e)i(MA)-7 b(Y)26 b(b)r(e)g(sen)n(t)f(to)h(the)g (transmitting)f(en)n(tit)n(y)-7 b(.)36 b(This)26 b(action)f(is)g (dictated)h(b)n(y)f(a)g(system)390 706 y(securit)n(y)i(p)r(olicy)-7 b(.)101 872 y(2.)42 b(V)-7 b(erify)28 b(the)g(RESER)-9 b(VED)27 b(\014eld)i(con)n(tains)e(the)h(v)-5 b(alue)28 b(zero.)37 b(If)29 b(the)f(v)-5 b(alue)28 b(in)g(the)h(RESER)-9 b(VED)27 b(\014eld)h(is)g(not)g(zero,)208 971 y(the)g(message)e(is)h (discarded)g(and)g(the)h(follo)n(wing)f(actions)g(are)f(tak)n(en:)243 1137 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(RESER)-8 b(VED)28 b(FIELD)p Fk(,)g(MA)-7 b(Y)29 b(b)r(e)f(logged)e (in)i(the)g(appropriate)e(system)h(audit)h(\014le.)238 1254 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(BAD-PR)n (OPOSAL-SYNT)-7 b(AX)390 1353 y(or)24 b(P)-7 b(A)g(YLO)n(AD-MALF)n (ORMED)25 b(message)e(t)n(yp)r(e)i(MA)-7 b(Y)26 b(b)r(e)f(sen)n(t)g(to) g(the)g(transmitting)g(en)n(tit)n(y)-7 b(.)36 b(This)25 b(action)390 1453 y(is)j(dictated)g(b)n(y)f(a)g(system)g(securit)n(y)g (p)r(olicy)-7 b(.)101 1619 y(3.)42 b(Pro)r(cess)25 b(the)j(remaining)f (pa)n(yloads)f(as)h(de\014ned)h(b)n(y)f(the)h(Next)g(P)n(a)n(yload)d (\014eld.)0 1951 y Fj(5.4)112 b(Securit)m(y)37 b(Asso)s(ciation)f(P)m (a)m(yload)h(Pro)s(cessing)0 2204 y Fk(When)d(creating)d(a)i(Securit)n (y)g(Asso)r(ciation)f(P)n(a)n(yload,)g(the)h(transmitting)g(en)n(tit)n (y)g(\(initiator)g(or)f(resp)r(onder\))g(MUST)h(do)0 2303 y(the)28 b(follo)n(wing:)101 2586 y(1.)42 b(Determine)28 b(the)g(Domain)f(of)h(In)n(terpretation)e(for)h(whic)n(h)h(this)g (negotiation)e(is)i(b)r(eing)f(p)r(erformed.)101 2719 y(2.)42 b(Determine)28 b(the)g(situation)f(within)h(the)g(determined)g (DOI)g(for)f(whic)n(h)g(this)h(negotiation)f(is)g(b)r(eing)h(p)r (erformed.)101 2851 y(3.)42 b(Determine)26 b(the)h(prop)r(osal\(s\))e (and)h(transform\(s\))f(within)i(the)g(situation.)36 b(These)26 b(are)f(describ)r(ed,)h(resp)r(ectiv)n(ely)-7 b(,)26 b(in)208 2951 y(sections)h(3.5)f(and)i(3.6.)101 3084 y(4.)42 b(Construct)27 b(a)g(Securit)n(y)g(Asso)r(ciation)g(pa)n (yload.)101 3217 y(5.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h (the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h (5.1.)0 3499 y(When)f(a)f(Securit)n(y)g(Asso)r(ciation)g(pa)n(yload)f (is)i(receiv)n(ed,)e(the)i(receiving)f(en)n(tit)n(y)g(\(initiator)h(or) f(resp)r(onder\))f(MUST)i(do)g(the)0 3599 y(follo)n(wing:)101 3881 y(1.)42 b(Determine)34 b(if)h(the)g(Domain)f(of)h(In)n (terpretation)e(\(DOI\))i(is)f(supp)r(orted.)58 b(If)34 b(the)h(DOI)g(determination)f(fails,)i(the)208 3981 y(message)26 b(is)h(discarded)g(and)g(the)h(follo)n(wing)f(actions)g(are)f(tak)n (en:)243 4147 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(DOI)p Fk(,)f(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g (appropriate)e(system)h(audit)h(\014le.)238 4263 y(\(b\))42 b(An)27 b(Informational)e(Exc)n(hange)g(with)i(a)f(Noti\014cation)g(pa) n(yload)f(con)n(taining)g(the)i(DOI-NOT-SUPPOR)-7 b(TED)390 4362 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h (the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 4462 y(p)r(olicy)-7 b(.)101 4628 y(2.)42 b(Determine)28 b(if)g(the)g(giv)n(en)f(situation)h(can)f(b)r(e)h(protected.)37 b(If)28 b(the)h(Situation)f(determination)f(fails,)h(the)g(message)e (is)208 4728 y(discarded)g(and)i(the)g(follo)n(wing)e(actions)h(are)g (tak)n(en:)243 4894 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(SITUA)-6 b(TION)p Fk(,)27 b(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system)i(audit)f (\014le.)238 5010 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g (with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(SITUA) -7 b(TION-NOT-SUPPOR)g(TED)390 5110 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 5209 y(p)r(olicy)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(48])p eop %%Page: 49 49 49 48 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)101 390 y(3.)42 b(Pro)r(cess)24 b(the)k(remaining)d(pa)n(yloads)g(\(i.e.)37 b(Prop)r(osal,)25 b(T)-7 b(ransform\))26 b(of)g(the)h(Securit)n(y)g(Asso)r(ciation)e(P)n (a)n(yload.)35 b(If)27 b(the)208 490 y(Securit)n(y)d(Asso)r(ciation)g (Prop)r(osal)f(\(as)h(describ)r(ed)h(in)g(sections)f(5.5)g(and)h(5.6\)) g(is)f(not)h(accepted,)g(then)h(the)f(follo)n(wing)208 589 y(actions)h(are)h(tak)n(en:)243 756 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(PR)n(OPOSAL)p Fk(,)f(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system) h(audit)h(\014le.)238 872 y(\(b\))42 b(An)19 b(Informational)e(Exc)n (hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i (NO-PR)n(OPOSAL-CHOSEN)390 971 y(message)i(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 1071 y(p)r(olicy)-7 b(.)0 1403 y Fj(5.5)112 b(Prop)s(osal)37 b(P)m(a)m(yload)h(Pro)s(cessing)0 1656 y Fk(When)26 b(creating)f(a)h(Prop)r(osal)d(P)n(a)n(yload,)h(the)j (transmitting)e(en)n(tit)n(y)h(\(initiator)g(or)f(resp)r(onder\))g (MUST)h(do)g(the)g(follo)n(wing:)101 1938 y(1.)42 b(Determine)28 b(the)g(Proto)r(col)d(for)i(this)h(prop)r(osal.)101 2071 y(2.)42 b(Determine)32 b(the)g(n)n(um)n(b)r(er)f(of)h(prop)r(osals)e (to)h(b)r(e)i(o\013ered)e(for)g(this)h(proto)r(col)e(and)i(the)g(n)n (um)n(b)r(er)g(of)f(transforms)g(for)208 2171 y(eac)n(h)26 b(prop)r(osal.)36 b(T)-7 b(ransforms)26 b(are)g(describ)r(ed)i(in)g (section)f(3.6.)101 2303 y(3.)42 b(Generate)27 b(a)g(unique)h (pseudo-random)d(SPI.)101 2436 y(4.)42 b(Construct)27 b(a)g(Prop)r(osal)e(pa)n(yload.)0 2719 y(When)j(a)f(Prop)r(osal)f(pa)n (yload)g(is)h(receiv)n(ed,)g(the)h(receiving)e(en)n(tit)n(y)i (\(initiator)f(or)g(resp)r(onder\))g(MUST)h(do)f(the)h(follo)n(wing:) 101 3001 y(1.)42 b(Determine)24 b(if)h(the)g(Proto)r(col)d(is)j(supp)r (orted.)35 b(If)25 b(the)g(Proto)r(col-ID)d(\014eld)j(is)f(in)n(v)-5 b(alid,)25 b(the)g(pa)n(yload)e(is)h(discarded)f(and)208 3100 y(the)28 b(follo)n(wing)e(actions)h(are)f(tak)n(en:)243 3267 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(PR)n(OTOCOL)p Fk(,)f(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g (appropriate)e(system)h(audit)h(\014le.)238 3383 y(\(b\))42 b(An)31 b(Informational)d(Exc)n(hange)g(with)j(a)e(Noti\014cation)h(pa) n(yload)e(con)n(taining)h(the)h(INV)-9 b(ALID-PR)n(OTOCOL-)390 3482 y(ID)34 b(message)f(t)n(yp)r(e)h(MA)-7 b(Y)34 b(b)r(e)g(sen)n(t)g (to)f(the)h(transmitting)g(en)n(tit)n(y)-7 b(.)55 b(This)34 b(action)f(is)h(dictated)g(b)n(y)f(a)g(system)390 3582 y(securit)n(y)27 b(p)r(olicy)-7 b(.)101 3748 y(2.)42 b(Determine)28 b(if)h(the)g(SPI)f(is)h(v)-5 b(alid.)39 b(If)29 b(the)g(SPI)f(is)g(in)n(v)-5 b(alid,)29 b(the)g(pa)n(yload)e (is)h(discarded)f(and)i(the)f(follo)n(wing)g(actions)208 3848 y(are)e(tak)n(en:)243 4014 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(SPI)p Fk(,)g(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g (the)h(appropriate)e(system)i(audit)f(\014le.)238 4130 y(\(b\))42 b(An)36 b(Informational)e(Exc)n(hange)g(with)h(a)g (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-SPI)35 b(message)390 4230 y(t)n(yp)r(e)27 b(MA)-7 b(Y)27 b(b)r(e)f(sen)n(t)h(to)f(the)g(transmitting)h(en)n(tit)n(y)-7 b(.)36 b(This)26 b(action)g(is)g(dictated)h(b)n(y)f(a)g(system)g (securit)n(y)f(p)r(olicy)-7 b(.)101 4396 y(3.)42 b(Ensure)19 b(the)i(Prop)r(osals)d(are)h(presen)n(ted)h(according)e(to)j(the)g (details)f(giv)n(en)f(in)i(section)f(3.5)f(and)i(4.2.)33 b(If)21 b(the)g(prop)r(osals)208 4495 y(are)26 b(not)i(formed)f (correctly)-7 b(,)26 b(the)i(follo)n(wing)f(actions)g(are)f(tak)n(en:) 243 4661 y(\(a\))41 b(P)n(ossible)31 b(ev)n(en)n(ts,)h Fb(BAD)h(PR)n(OPOSAL)g(SYNT)-6 b(AX,)33 b(INV)-8 b(ALID)32 b(PR)n(OPOSAL)p Fk(,)f(are)f(logged)h(in)h(the)h(appro-)390 4761 y(priate)27 b(system)h(audit)f(\014le.)238 4877 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(BAD-PR)n (OPOSAL-SYNT)-7 b(AX)390 4977 y(or)24 b(P)-7 b(A)g(YLO)n(AD-MALF)n (ORMED)25 b(message)e(t)n(yp)r(e)i(MA)-7 b(Y)26 b(b)r(e)f(sen)n(t)g(to) g(the)g(transmitting)g(en)n(tit)n(y)-7 b(.)36 b(This)25 b(action)390 5076 y(is)j(dictated)g(b)n(y)f(a)g(system)g(securit)n(y)g (p)r(olicy)-7 b(.)101 5242 y(4.)42 b(Pro)r(cess)36 b(the)j(Prop)r(osal) e(and)h(T)-7 b(ransform)37 b(pa)n(yloads)g(as)h(de\014ned)h(b)n(y)f (the)h(Next)g(P)n(a)n(yload)d(\014eld.)71 b(Examples)37 b(of)208 5342 y(pro)r(cessing)26 b(these)h(pa)n(yloads)f(are)h(giv)n (en)f(in)i(section)g(4.2.1.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(49])p eop %%Page: 50 50 50 49 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(5.6)112 b(T)-9 b(ransform)37 b(P)m(a)m(yload)h(Pro)s(cessing)0 643 y Fk(When)22 b(creating)f(a)g(T)-7 b(ransform)21 b(P)n(a)n(yload,)f(the)i (transmitting)g(en)n(tit)n(y)g(\(initiator)f(or)g(resp)r(onder\))g (MUST)h(do)g(the)g(follo)n(wing:)101 915 y(1.)42 b(Determine)28 b(the)g(T)-7 b(ransform)26 b(#)i(for)f(this)h(transform.)101 1045 y(2.)42 b(Determine)d(the)g(n)n(um)n(b)r(er)g(of)g(transforms)f (to)g(b)r(e)i(o\013ered)e(for)h(this)g(prop)r(osal.)70 b(T)-7 b(ransforms)37 b(are)h(describ)r(ed)h(in)208 1145 y(sections)27 b(3.6.)101 1276 y(3.)42 b(Construct)27 b(a)g(T)-7 b(ransform)26 b(pa)n(yload.)0 1547 y(When)h(a)e(T)-7 b(ransform)25 b(pa)n(yload)f(is)i(receiv)n(ed,)f(the)i(receiving)e(en)n (tit)n(y)g(\(initiator)h(or)f(resp)r(onder\))g(MUST)i(do)f(the)g(follo) n(wing:)101 1819 y(1.)42 b(Determine)18 b(if)h(the)g(T)-7 b(ransform)17 b(is)i(supp)r(orted.)33 b(If)19 b(the)g(T)-7 b(ransform-ID)17 b(\014eld)i(con)n(tains)e(an)h(unkno)n(wn)g(or)g (unsupp)r(orted)208 1918 y(v)-5 b(alue,)35 b(then)f(that)g(T)-7 b(ransform)32 b(pa)n(yload)g(MUST)j(b)r(e)f(ignored)e(and)i(MUST)g(NOT) f(cause)g(the)h(generation)f(of)g(an)208 2018 y(INV)-9 b(ALID)28 b(TRANSF)n(ORM)g(ev)n(en)n(t.)37 b(If)28 b(the)h(T)-7 b(ransform-ID)26 b(\014eld)i(is)g(in)n(v)-5 b(alid,)27 b(the)h(pa)n(yload)f(is)g(discarded)g(and)h(the)208 2117 y(follo)n(wing)e(actions)h(are)g(tak)n(en:)243 2279 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(TRANSF)n(ORM)p Fk(,)f(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system) h(audit)h(\014le.)238 2393 y(\(b\))42 b(An)23 b(Informational)f(Exc)n (hange)f(with)i(a)f(Noti\014cation)h(pa)n(yload)e(con)n(taining)g(the)i (INV)-9 b(ALID-TRANSF)n(ORM-)390 2493 y(ID)34 b(message)f(t)n(yp)r(e)h (MA)-7 b(Y)34 b(b)r(e)g(sen)n(t)g(to)f(the)h(transmitting)g(en)n(tit)n (y)-7 b(.)55 b(This)34 b(action)f(is)h(dictated)g(b)n(y)f(a)g(system) 390 2592 y(securit)n(y)27 b(p)r(olicy)-7 b(.)101 2754 y(2.)42 b(Ensure)37 b(the)i(T)-7 b(ransforms)36 b(are)i(presen)n(ted)f (according)g(to)h(the)h(details)f(giv)n(en)f(in)i(section)f(3.6)g(and)g (4.2.)68 b(If)39 b(the)208 2854 y(transforms)26 b(are)g(not)i(formed)f (correctly)-7 b(,)26 b(the)i(follo)n(wing)f(actions)g(are)f(tak)n(en:) 243 3016 y(\(a\))41 b(P)n(ossible)17 b(ev)n(en)n(ts,)j Fb(BAD)h(PR)n(OPOSAL)f(SYNT)-6 b(AX,)20 b(INV)-8 b(ALID)19 b(TRANSF)n(ORM,)i(INV)-8 b(ALID)20 b(A)-6 b(TTRIBUTES)p Fk(,)390 3115 y(are)27 b(logged)f(in)i(the)g(appropriate)e(system)h (audit)h(\014le.)238 3229 y(\(b\))42 b(An)19 b(Informational)e(Exc)n (hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i (BAD-PR)n(OPOSAL-SYNT)-7 b(AX,)390 3329 y(P)g(A)g(YLO)n(AD-MALF)n (ORMED)22 b(or)f(A)-7 b(TTRIBUTES-NOT-SUPPOR)g(TED)20 b(message)g(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)f(sen)n(t)g(to)390 3429 y(the)28 b(transmitting)g(en)n(tit)n(y)-7 b(.)36 b(This)28 b(action)f(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)g (p)r(olicy)-7 b(.)101 3590 y(3.)42 b(Pro)r(cess)30 b(the)i(subsequen)n (t)f(T)-7 b(ransform)31 b(and)g(Prop)r(osal)f(pa)n(yloads)g(as)h (de\014ned)h(b)n(y)g(the)g(Next)g(P)n(a)n(yload)d(\014eld.)50 b(Ex-)208 3690 y(amples)27 b(of)g(pro)r(cessing)f(these)i(pa)n(yloads)e (are)g(giv)n(en)h(in)h(section)f(4.2.1.)0 4020 y Fj(5.7)112 b(Key)38 b(Exc)m(hange)g(P)m(a)m(yload)f(Pro)s(cessing)0 4273 y Fk(When)i(creating)d(a)i(Key)f(Exc)n(hange)f(P)n(a)n(yload,)j (the)f(transmitting)g(en)n(tit)n(y)g(\(initiator)f(or)g(resp)r(onder\)) h(MUST)g(do)g(the)0 4373 y(follo)n(wing:)101 4644 y(1.)k(Determine)28 b(the)g(Key)e(Exc)n(hange)g(to)i(b)r(e)g(used)f(as)g(de\014ned)h(b)n(y) f(the)h(DOI.)101 4775 y(2.)42 b(Determine)28 b(the)g(usage)e(of)i(the)g (Key)e(Exc)n(hange)g(Data)i(\014eld)g(as)e(de\014ned)i(b)n(y)g(the)g (DOI.)101 4905 y(3.)42 b(Construct)27 b(a)g(Key)g(Exc)n(hange)f(pa)n (yload.)101 5036 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h (the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h (5.1.)0 5308 y(When)42 b(a)e(Key)h(Exc)n(hange)e(pa)n(yload)g(is)i (receiv)n(ed,)i(the)f(receiving)e(en)n(tit)n(y)g(\(initiator)h(or)f (resp)r(onder\))g(MUST)i(do)f(the)0 5407 y(follo)n(wing:)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(50])p eop %%Page: 51 51 51 50 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)101 390 y(1.)42 b(Determine)27 b(if)g(the)h(Key)e(Exc)n(hange)f(is)i(supp)r(orted.)37 b(If)27 b(the)g(Key)g(Exc)n(hange)e(determination)h(fails,)h(the)h (message)d(is)208 490 y(discarded)h(and)i(the)g(follo)n(wing)e(actions) h(are)g(tak)n(en:)243 656 y(\(a\))41 b(The)35 b(ev)n(en)n(t,)h Fb(INV)-8 b(ALID)35 b(KEY)i(INF)n(ORMA)-6 b(TION)p Fk(,)33 b(MA)-7 b(Y)36 b(b)r(e)f(logged)f(in)h(the)g(appropriate)e(system)i (audit)390 756 y(\014le.)238 872 y(\(b\))42 b(An)19 b(Informational)e (Exc)n(hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g (the)i(INV)-9 b(ALID-KEY-INF)n(ORMA)i(TION)390 971 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g (transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h (dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 1071 y(p)r(olicy)-7 b(.)0 1403 y Fj(5.8)112 b(Iden)m(ti\014cation)36 b(P)m(a)m(yload)i(Pro)s(cessing)0 1656 y Fk(When)h(creating)e(an)h (Iden)n(ti\014cation)g(P)n(a)n(yload,)h(the)f(transmitting)h(en)n(tit)n (y)f(\(initiator)g(or)f(resp)r(onder\))h(MUST)h(do)f(the)0 1756 y(follo)n(wing:)101 2038 y(1.)k(Determine)22 b(the)h(Iden)n (ti\014cation)f(information)g(to)g(b)r(e)h(used)f(as)g(de\014ned)h(b)n (y)f(the)g(DOI)h(\(and)f(p)r(ossibly)g(the)h(situation\).)101 2171 y(2.)42 b(Determine)28 b(the)g(usage)e(of)i(the)g(Iden)n (ti\014cation)f(Data)g(\014eld)h(as)f(de\014ned)h(b)n(y)f(the)h(DOI.) 101 2303 y(3.)42 b(Construct)27 b(an)g(Iden)n(ti\014cation)g(pa)n (yload.)101 2436 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h (the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h (5.1.)0 2719 y(When)k(an)e(Iden)n(ti\014cation)h(pa)n(yload)f(is)h (receiv)n(ed,)g(the)g(receiving)f(en)n(tit)n(y)h(\(initiator)g(or)f (resp)r(onder\))g(MUST)i(do)f(the)g(fol-)0 2818 y(lo)n(wing:)101 3100 y(1.)42 b(Determine)31 b(if)h(the)g(Iden)n(ti\014cation)f(T)n(yp)r (e)g(is)g(supp)r(orted.)48 b(This)31 b(ma)n(y)g(b)r(e)h(based)e(on)h (the)h(DOI)f(and)g(Situation.)49 b(If)208 3200 y(the)28 b(Iden)n(ti\014cation)f(determination)g(fails,)h(the)g(message)e(is)h (discarded)g(and)g(the)h(follo)n(wing)f(actions)g(are)f(tak)n(en:)243 3366 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(ID)i(INF)n(ORMA)-6 b(TION)p Fk(,)26 b(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g(the)h(appropriate)e(system)i(audit)f(\014le.) 238 3482 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-ID-INF)n(ORMA)i(TION)390 3582 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 3682 y(p)r(olicy)-7 b(.)0 4014 y Fj(5.9)112 b(Certi\014cate)37 b(P)m(a)m(yload)g(Pro)s(cessing)0 4267 y Fk(When)22 b(creating)e(a)i(Certi\014cate)f(P)n(a)n(yload,)f (the)i(transmitting)f(en)n(tit)n(y)g(\(initiator)h(or)e(resp)r(onder\)) h(MUST)h(do)f(the)h(follo)n(wing:)101 4549 y(1.)42 b(Determine)28 b(the)g(Certi\014cate)f(Enco)r(ding)f(to)i(b)r(e)g(used.)37 b(This)27 b(ma)n(y)g(b)r(e)h(sp)r(eci\014ed)g(b)n(y)f(the)h(DOI.)101 4682 y(2.)42 b(Ensure)26 b(the)i(existence)f(of)h(a)f(certi\014cate)g (formatted)h(as)f(de\014ned)g(b)n(y)h(the)g(Certi\014cate)f(Enco)r (ding.)101 4814 y(3.)42 b(Construct)27 b(a)g(Certi\014cate)g(pa)n (yload.)101 4947 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h (the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h (5.1.)0 5230 y(When)e(a)g(Certi\014cate)f(pa)n(yload)f(is)i(receiv)n (ed,)f(the)h(receiving)e(en)n(tit)n(y)i(\(initiator)g(or)e(resp)r (onder\))h(MUST)i(do)e(the)h(follo)n(wing:)0 5656 y(Maughan,)h(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(51])p eop %%Page: 52 52 52 51 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)101 390 y(1.)42 b(Determine)29 b(if)h(the)g(Certi\014cate)f(Enco)r(ding)f(is)i(supp)r(orted.)41 b(If)30 b(the)g(Certi\014cate)f(Enco)r(ding)f(is)i(not)f(supp)r(orted,) h(the)208 490 y(pa)n(yload)c(is)h(discarded)g(and)g(the)h(follo)n(wing) f(actions)g(are)f(tak)n(en:)243 656 y(\(a\))41 b(The)34 b(ev)n(en)n(t,)h Fb(INV)-8 b(ALID)34 b(CER)-6 b(TIFICA)g(TE)36 b(TYPE)p Fk(,)f(MA)-7 b(Y)34 b(b)r(e)h(logged)d(in)i(the)g(appropriate) e(system)i(audit)390 756 y(\014le.)238 872 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f(Noti\014cation)g(pa) n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-CER)i(T-ENCODING)390 971 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h (the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 1071 y(p)r(olicy)-7 b(.)101 1237 y(2.)42 b(Pro)r(cess)37 b(the)i(Certi\014cate)g(Data)f(\014eld.)72 b(If)39 b(the)h (Certi\014cate)e(Data)h(is)g(in)n(v)-5 b(alid)39 b(or)f(improp)r(erly)g (formatted,)k(the)208 1337 y(pa)n(yload)26 b(is)h(discarded)g(and)g (the)h(follo)n(wing)f(actions)g(are)f(tak)n(en:)243 1503 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(CER)-6 b(TIFICA)g(TE)p Fk(,)29 b(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g (the)h(appropriate)e(system)i(audit)f(\014le.)238 1619 y(\(b\))42 b(An)23 b(Informational)e(Exc)n(hange)g(with)h(a)g (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-CER)i(TIFICA)g(TE)390 1719 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 1818 y(p)r(olicy)-7 b(.)0 2150 y Fj(5.10)112 b(Certi\014cate)37 b(Request)g(P)m(a)m(yload)g(Pro)s(cessing)0 2403 y Fk(When)26 b(creating)f(a)g(Certi\014cate)g(Request)g(P)n(a)n (yload,)f(the)i(transmitting)f(en)n(tit)n(y)h(\(initiator)f(or)g(resp)r (onder\))f(MUST)i(do)g(the)0 2503 y(follo)n(wing:)101 2785 y(1.)42 b(Determine)28 b(the)g(t)n(yp)r(e)f(of)h(Certi\014cate)f (Enco)r(ding)g(to)g(b)r(e)h(requested.)37 b(This)27 b(ma)n(y)g(b)r(e)h (sp)r(eci\014ed)g(b)n(y)f(the)h(DOI.)101 2918 y(2.)42 b(Determine)28 b(the)g(name)f(of)g(an)h(acceptable)f(Certi\014cate)g (Authorit)n(y)g(whic)n(h)h(is)f(to)h(b)r(e)g(requested)f(\(if)h (applicable\).)101 3051 y(3.)42 b(Construct)27 b(a)g(Certi\014cate)g (Request)h(pa)n(yload.)101 3183 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r (ed)h(in)f(section)h(5.1.)0 3466 y(When)i(a)f(Certi\014cate)g(Request)g (pa)n(yload)f(is)i(receiv)n(ed,)f(the)g(receiving)g(en)n(tit)n(y)g (\(initiator)g(or)g(resp)r(onder\))g(MUST)h(do)f(the)0 3565 y(follo)n(wing:)101 3848 y(1.)42 b(Determine)27 b(if)g(the)g(Certi\014cate)g(Enco)r(ding)f(is)g(supp)r(orted.)37 b(If)27 b(the)g(Certi\014cate)g(Enco)r(ding)f(is)g(in)n(v)-5 b(alid,)27 b(the)h(pa)n(yload)208 3947 y(is)f(discarded)g(and)g(the)h (follo)n(wing)f(actions)f(are)h(tak)n(en:)243 4113 y(\(a\))41 b(The)34 b(ev)n(en)n(t,)h Fb(INV)-8 b(ALID)34 b(CER)-6 b(TIFICA)g(TE)36 b(TYPE)p Fk(,)f(MA)-7 b(Y)34 b(b)r(e)h(logged)d(in)i (the)g(appropriate)e(system)i(audit)390 4213 y(\014le.)238 4329 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(INV)-9 b(ALID-CER)i(T-ENCODING)390 4429 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 4528 y(p)r(olicy)-7 b(.)208 4694 y(If)34 b(the)g(Certi\014cate)f(Enco)r(ding)g(is)h(not)g(supp)r(orted,)h(the)f (pa)n(yload)f(is)g(discarded)g(and)h(the)g(follo)n(wing)f(actions)g (are)208 4794 y(tak)n(en:)243 4960 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)g Fb(CER)-6 b(TIFICA)g(TE)32 b(TYPE)f(UNSUPPOR)-6 b(TED)p Fk(,)27 b(MA)-7 b(Y)28 b(b)r(e)h(logged)e(in)h(the)h (appropriate)d(system)390 5060 y(audit)i(\014le.)238 5176 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(CER)-7 b(T-TYPE-UNSUPPOR)g(TED)390 5276 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g (securit)n(y)390 5375 y(p)r(olicy)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(52])p eop %%Page: 53 53 53 52 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)101 390 y(2.)42 b(Determine)e(if)h(the)g (Certi\014cate)f(Authorit)n(y)h(is)f(supp)r(orted)g(for)g(the)h(sp)r (eci\014ed)g(Certi\014cate)f(Enco)r(ding.)75 b(If)41 b(the)208 490 y(Certi\014cate)33 b(Authorit)n(y)h(is)f(in)n(v)-5 b(alid)34 b(or)f(improp)r(erly)g(formatted,)i(the)f(pa)n(yload)f(is)g (discarded)g(and)h(the)g(follo)n(wing)208 589 y(actions)26 b(are)h(tak)n(en:)243 756 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)g Fb(INV)-8 b(ALID)29 b(CER)-6 b(TIFICA)g(TE)31 b(A)n(UTHORITY)p Fk(,)c(MA)-7 b(Y)29 b(b)r(e)f(logged)f(in)h(the)h(appropriate)d(system) 390 855 y(audit)i(\014le.)238 971 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload) f(con)n(taining)g(the)i(INV)-9 b(ALID-CER)i(T-A)n(UTHORITY)390 1071 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h (the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 1171 y(p)r(olicy)-7 b(.)101 1337 y(3.)42 b(Pro)r(cess)19 b(the)i(Certi\014cate)g(Request.)34 b(If)22 b(a)e(requested)g (Certi\014cate)h(T)n(yp)r(e)g(with)g(the)h(sp)r(eci\014ed)f (Certi\014cate)f(Authorit)n(y)208 1436 y(is)27 b(not)h(a)n(v)-5 b(ailable,)26 b(then)i(the)g(pa)n(yload)e(is)i(discarded)e(and)i(the)g (follo)n(wing)e(actions)h(are)g(tak)n(en:)243 1602 y(\(a\))41 b(The)c(ev)n(en)n(t,)h Fb(CER)-6 b(TIFICA)g(TE-UNA)e(V)g(AILABLE)p Fk(,)35 b(MA)-7 b(Y)37 b(b)r(e)g(logged)e(in)i(the)f(appropriate)f (system)h(audit)390 1702 y(\014le.)238 1818 y(\(b\))42 b(An)19 b(Informational)e(Exc)n(hange)g(with)i(a)f(Noti\014cation)g(pa) n(yload)f(con)n(taining)g(the)i(CER)-7 b(TIFICA)g(TE-UNA)e(V)g(AILABLE) 390 1918 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f (to)h(the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 2017 y(p)r(olicy)-7 b(.)0 2349 y Fj(5.11)112 b(Hash)38 b(P)m(a)m(yload)g(Pro)s(cessing)0 2602 y Fk(When)28 b(creating)f(a)g (Hash)g(P)n(a)n(yload,)e(the)j(transmitting)g(en)n(tit)n(y)f (\(initiator)h(or)e(resp)r(onder\))h(MUST)h(do)f(the)h(follo)n(wing:) 101 2885 y(1.)42 b(Determine)28 b(the)g(Hash)f(function)h(to)f(b)r(e)h (used)g(as)f(de\014ned)h(b)n(y)f(the)h(SA)g(negotiation.)101 3017 y(2.)42 b(Determine)28 b(the)g(usage)e(of)i(the)g(Hash)f(Data)g (\014eld)h(as)f(de\014ned)h(b)n(y)f(the)h(DOI.)101 3150 y(3.)42 b(Construct)27 b(a)g(Hash)g(pa)n(yload.)101 3283 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h(receiving)f (en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h(5.1.)0 3565 y(When)g(a)f(Hash)h(pa)n(yload)e(is)h(receiv)n(ed,)g(the)h (receiving)e(en)n(tit)n(y)i(\(initiator)f(or)g(resp)r(onder\))g(MUST)h (do)f(the)h(follo)n(wing:)101 3848 y(1.)42 b(Determine)27 b(if)h(the)f(Hash)g(is)g(supp)r(orted.)36 b(If)28 b(the)f(Hash)g (determination)g(fails,)g(the)g(message)f(is)h(discarded)f(and)h(the) 208 3947 y(follo)n(wing)f(actions)h(are)g(tak)n(en:)243 4113 y(\(a\))41 b(The)31 b(ev)n(en)n(t,)g Fb(INV)-8 b(ALID)31 b(HASH)h(INF)n(ORMA)-6 b(TION)p Fk(,)29 b(MA)-7 b(Y)32 b(b)r(e)f(logged)e(in)i(the)g(appropriate)e(system)i(audit)390 4213 y(\014le.)238 4329 y(\(b\))42 b(An)19 b(Informational)e(Exc)n (hange)g(with)i(a)f(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i (INV)-9 b(ALID-HASH-INF)n(ORMA)i(TION)390 4429 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h(the)g (transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h (dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 4528 y(p)r(olicy)-7 b(.)101 4694 y(2.)42 b(P)n(erform)28 b(the)j(Hash)f (function)h(as)f(outlined)g(in)h(the)g(DOI)f(and/or)f(Key)h(Exc)n (hange)e(proto)r(col)i(do)r(cumen)n(ts.)45 b(If)31 b(the)208 4794 y(Hash)c(function)h(fails,)g(the)g(message)e(is)h(discarded)g(and) g(the)h(follo)n(wing)f(actions)g(are)f(tak)n(en:)243 4960 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(HASH)h(V)-8 b(ALUE)p Fk(,)26 b(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i (the)g(appropriate)e(system)h(audit)h(\014le.)238 5076 y(\(b\))42 b(An)d(Informational)e(Exc)n(hange)g(with)h(a)g (Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i(A)n(UTHENTICA)-7 b(TION-)390 5176 y(F)e(AILED)38 b(message)e(t)n(yp)r(e)i(MA)-7 b(Y)38 b(b)r(e)g(sen)n(t)g(to)f(the)h(transmitting)f(en)n(tit)n(y)-7 b(.)67 b(This)38 b(action)f(is)g(dictated)h(b)n(y)f(a)390 5276 y(system)28 b(securit)n(y)e(p)r(olicy)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(53])p eop %%Page: 54 54 54 53 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(5.12)112 b(Signature)38 b(P)m(a)m(yload)f(Pro)s(cessing)0 643 y Fk(When)24 b(creating)f(a)h (Signature)f(P)n(a)n(yload,)f(the)i(transmitting)g(en)n(tit)n(y)f (\(initiator)h(or)f(resp)r(onder\))g(MUST)h(do)g(the)g(follo)n(wing:) 101 925 y(1.)42 b(Determine)28 b(the)g(Signature)e(function)j(to)e(b)r (e)h(used)g(as)e(de\014ned)i(b)n(y)g(the)g(SA)g(negotiation.)101 1058 y(2.)42 b(Determine)28 b(the)g(usage)e(of)i(the)g(Signature)e (Data)i(\014eld)g(as)f(de\014ned)h(b)n(y)f(the)h(DOI.)101 1191 y(3.)42 b(Construct)27 b(a)g(Signature)g(pa)n(yload.)101 1324 y(4.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h (receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h(5.1.)0 1606 y(When)g(a)f(Signature)g(pa)n(yload)f(is)i(receiv)n(ed,)e(the)i (receiving)f(en)n(tit)n(y)g(\(initiator)h(or)e(resp)r(onder\))h(MUST)h (do)f(the)h(follo)n(wing:)101 1888 y(1.)42 b(Determine)25 b(if)h(the)g(Signature)e(is)h(supp)r(orted.)36 b(If)26 b(the)f(Signature)g(determination)g(fails,)g(the)h(message)e(is)h (discarded)208 1988 y(and)i(the)h(follo)n(wing)f(actions)f(are)h(tak)n (en:)243 2154 y(\(a\))41 b(The)27 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)27 b(SIGNA)-6 b(TURE)28 b(INF)n(ORMA)-6 b(TION)p Fk(,)25 b(MA)-7 b(Y)28 b(b)r(e)f(logged)e(in)i(the)g(appropriate)d (system)390 2254 y(audit)k(\014le.)238 2370 y(\(b\))42 b(An)32 b(Informational)d(Exc)n(hange)g(with)j(a)e(Noti\014cation)h(pa) n(yload)f(con)n(taining)f(the)j(INV)-9 b(ALID-SIGNA)i(TURE)390 2470 y(message)21 b(t)n(yp)r(e)i(MA)-7 b(Y)23 b(b)r(e)g(sen)n(t)f(to)h (the)g(transmitting)f(en)n(tit)n(y)-7 b(.)35 b(This)22 b(action)g(is)h(dictated)f(b)n(y)h(a)f(system)g(securit)n(y)390 2569 y(p)r(olicy)-7 b(.)101 2735 y(2.)42 b(P)n(erform)27 b(the)j(Signature)e(function)i(as)f(outlined)g(in)h(the)g(DOI)f(and/or) f(Key)g(Exc)n(hange)g(proto)r(col)g(do)r(cumen)n(ts.)42 b(If)208 2835 y(the)28 b(Signature)e(function)j(fails,)e(the)h(message) e(is)i(discarded)e(and)i(the)g(follo)n(wing)e(actions)h(are)g(tak)n (en:)243 3001 y(\(a\))41 b(The)24 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)25 b(SIGNA)-6 b(TURE)24 b(V)-8 b(ALUE)p Fk(,)23 b(MA)-7 b(Y)24 b(b)r(e)g(logged)e(in)i(the)f(appropriate)f(system)h (audit)h(\014le.)238 3117 y(\(b\))42 b(An)d(Informational)e(Exc)n (hange)g(with)h(a)g(Noti\014cation)g(pa)n(yload)f(con)n(taining)g(the)i (A)n(UTHENTICA)-7 b(TION-)390 3217 y(F)e(AILED)38 b(message)e(t)n(yp)r (e)i(MA)-7 b(Y)38 b(b)r(e)g(sen)n(t)g(to)f(the)h(transmitting)f(en)n (tit)n(y)-7 b(.)67 b(This)38 b(action)f(is)g(dictated)h(b)n(y)f(a)390 3316 y(system)28 b(securit)n(y)e(p)r(olicy)-7 b(.)0 3648 y Fj(5.13)112 b(Nonce)38 b(P)m(a)m(yload)f(Pro)s(cessing)0 3901 y Fk(When)28 b(creating)f(a)g(Nonce)g(P)n(a)n(yload,)e(the)j (transmitting)g(en)n(tit)n(y)f(\(initiator)h(or)e(resp)r(onder\))h (MUST)h(do)f(the)h(follo)n(wing:)101 4184 y(1.)42 b(Create)26 b(a)h(unique)h(random)f(v)-5 b(alue)27 b(to)h(b)r(e)g(used)f(as)g(a)h (nonce.)101 4316 y(2.)42 b(Construct)27 b(a)g(Nonce)g(pa)n(yload.)101 4449 y(3.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h (receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h(5.1.)0 4732 y(When)g(a)f(Nonce)h(pa)n(yload)e(is)h(receiv)n(ed,)g(the)h (receiving)e(en)n(tit)n(y)i(\(initiator)f(or)g(resp)r(onder\))g(MUST)h (do)f(the)h(follo)n(wing:)101 5014 y(1.)42 b(There)36 b(are)g(no)h(sp)r(eci\014c)h(pro)r(cedures)e(for)g(handling)h(Nonce)g (pa)n(yloads.)64 b(The)37 b(pro)r(cedures)f(are)g(de\014ned)i(b)n(y)f (the)208 5113 y(exc)n(hange)26 b(t)n(yp)r(es)h(\(and)h(p)r(ossibly)f (the)h(DOI)g(and)f(Key)g(Exc)n(hange)f(descriptions\).)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(54])p eop %%Page: 55 55 55 54 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(5.14)112 b(Noti\014cation)36 b(P)m(a)m(yload)h(Pro)s(cessing)0 643 y Fk(During)e(comm)n(unications)f (it)i(is)f(p)r(ossible)g(that)h(errors)d(ma)n(y)i(o)r(ccur.)59 b(The)35 b(Informational)g(Exc)n(hange)e(with)j(a)f(Notify)0 743 y(P)n(a)n(yload)27 b(pro)n(vides)h(a)i(con)n(trolled)e(metho)r(d)i (of)g(informing)f(a)g(p)r(eer)g(en)n(tit)n(y)h(that)g(errors)d(ha)n(v)n (e)i(o)r(ccurred)f(during)h(proto)r(col)0 842 y(pro)r(cessing.)62 b(It)37 b(is)g(RECOMMENDED)f(that)h(Notify)g(P)n(a)n(yloads)d(b)r(e)j (sen)n(t)f(in)h(a)f(separate)f(Informational)h(Exc)n(hange)0 942 y(rather)27 b(than)g(app)r(ending)h(a)f(Notify)h(P)n(a)n(yload)d (to)j(an)f(existing)g(exc)n(hange.)0 1141 y(When)f(creating)f(a)g (Noti\014cation)h(P)n(a)n(yload,)d(the)j(transmitting)g(en)n(tit)n(y)f (\(initiator)h(or)f(resp)r(onder\))f(MUST)j(do)e(the)h(follo)n(w-)0 1241 y(ing:)101 1519 y(1.)42 b(Determine)28 b(the)g(DOI)f(for)g(this)h (Noti\014cation.)101 1651 y(2.)42 b(Determine)28 b(the)g(Proto)r (col-ID)d(for)i(this)h(Noti\014cation.)101 1783 y(3.)42 b(Determine)23 b(the)g(SPI)f(size)h(based)f(on)h(the)g(Proto)r(col-ID)e (\014eld.)35 b(This)23 b(\014eld)g(is)g(necessary)e(b)r(ecause)h (di\013eren)n(t)h(securit)n(y)208 1882 y(proto)r(cols)e(ha)n(v)n(e)h (di\013eren)n(t)h(SPI)g(sizes.)34 b(F)-7 b(or)23 b(example,)g(ISAKMP)g (com)n(bines)f(the)h(Initiator)g(and)g(Resp)r(onder)f(co)r(okie)208 1982 y(pair)k(\(16)h(o)r(ctets\))h(as)f(a)g(SPI,)h(while)g(ESP)e(and)i (AH)g(ha)n(v)n(e)e(8)i(o)r(ctet)f(SPIs.)101 2114 y(4.)42 b(Determine)28 b(the)g(Notify)f(Message)g(T)n(yp)r(e)g(based)g(on)g (the)h(error)e(or)h(status)g(message)f(desired.)101 2246 y(5.)42 b(Determine)28 b(the)g(SPI)f(whic)n(h)g(is)h(asso)r(ciated)e (with)i(this)g(noti\014cation.)101 2378 y(6.)42 b(Determine)24 b(if)h(additional)f(Noti\014cation)h(Data)f(is)g(to)h(b)r(e)g (included.)36 b(This)24 b(is)h(additional)f(information)g(sp)r (eci\014ed)g(b)n(y)208 2477 y(the)k(DOI.)101 2609 y(7.)42 b(Construct)27 b(a)g(Noti\014cation)g(pa)n(yload.)101 2741 y(8.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h (receiving)f(en)n(tit)n(y)g(as)g(describ)r(ed)h(in)f(section)h(5.1.)0 3019 y(Because)21 b(the)i(Informational)e(Exc)n(hange)g(with)h(a)g (Noti\014cation)g(pa)n(yload)f(is)h(a)g(unidirectional)g(message)f(a)h (retransmission)0 3119 y(will)34 b(not)g(b)r(e)g(p)r(erformed.)55 b(The)34 b(lo)r(cal)f(securit)n(y)g(p)r(olicy)h(will)g(dictate)g(the)g (pro)r(cedures)f(for)g(con)n(tin)n(uing.)55 b(Ho)n(w)n(ev)n(er,)33 b(w)n(e)0 3218 y(RECOMMEND)i(that)h(a)f(NOTIFICA)-7 b(TION)36 b(P)-7 b(A)g(YLO)n(AD)36 b(ERR)n(OR)e(ev)n(en)n(t)h(b)r(e)h(logged)f (in)h(the)f(appropriate)f(system)0 3318 y(audit)28 b(\014le)g(b)n(y)f (the)h(receiving)e(en)n(tit)n(y)-7 b(.)0 3517 y(If)29 b(the)f(Informational)f(Exc)n(hange)g(o)r(ccurs)g(prior)g(to)h(the)h (exc)n(hange)e(of)h(k)n(eying)f(material)h(during)g(an)f(ISAKMP)h (Phase)f(1)0 3617 y(negotiation)17 b(there)i(will)f(b)r(e)h(no)f (protection)g(pro)n(vided)f(for)h(the)h(Informational)e(Exc)n(hange.)32 b(Once)18 b(the)h(k)n(eying)e(material)h(has)0 3716 y(b)r(een)k(exc)n (hanged)e(or)h(the)h(ISAKMP)f(SA)h(has)f(b)r(een)h(established,)h(the)f (Informational)e(Exc)n(hange)g(MUST)i(b)r(e)g(transmitted)0 3816 y(under)27 b(the)h(protection)f(pro)n(vided)g(b)n(y)g(the)h(k)n (eying)f(material)f(or)h(the)h(ISAKMP)f(SA.)0 4015 y(When)c(a)f (Noti\014cation)g(pa)n(yload)f(is)i(receiv)n(ed,)f(the)h(receiving)e (en)n(tit)n(y)i(\(initiator)f(or)f(resp)r(onder\))h(MUST)h(do)f(the)h (follo)n(wing:)101 4293 y(1.)42 b(Determine)27 b(if)h(the)g (Informational)e(Exc)n(hange)g(has)h(an)n(y)g(protection)f(applied)i (to)f(it)h(b)n(y)f(c)n(hec)n(king)f(the)i(Encryption)208 4393 y(Bit)33 b(and)f(the)i(Authen)n(tication)f(Only)g(Bit)g(in)g(the)g (ISAKMP)g(Header.)52 b(If)33 b(the)h(Encryption)d(Bit)j(is)e(set,)j (i.e.)53 b(the)208 4492 y(Informational)26 b(Exc)n(hange)f(is)i (encrypted,)g(then)h(the)f(message)f(MUST)i(b)r(e)g(decrypted)f(using)f (the)i(\(in-progress)d(or)208 4592 y(completed\))33 b(ISAKMP)f(SA.)i (Once)f(the)g(decryption)f(is)h(complete)g(the)g(pro)r(cessing)f(can)h (con)n(tin)n(ue)f(as)g(describ)r(ed)208 4692 y(b)r(elo)n(w.)62 b(If)37 b(the)g(Authen)n(tication)g(Only)f(Bit)g(is)h(set,)h(then)f (the)g(message)e(MUST)i(b)r(e)f(authen)n(ticated)h(using)f(the)208 4791 y(\(in-progress)e(or)h(completed\))i(ISAKMP)f(SA.)h(Once)f(the)h (authen)n(tication)f(is)h(completed,)i(the)d(pro)r(cessing)f(can)208 4891 y(con)n(tin)n(ue)e(as)g(describ)r(ed)g(b)r(elo)n(w.)55 b(If)34 b(the)h(Informational)d(Exc)n(hange)g(is)i(not)f(encrypted)h (or)f(authen)n(tication,)i(the)208 4991 y(pa)n(yload)26 b(pro)r(cessing)g(can)h(con)n(tin)n(ue)g(as)g(describ)r(ed)g(b)r(elo)n (w.)101 5123 y(2.)42 b(Determine)34 b(if)h(the)g(Domain)f(of)h(In)n (terpretation)e(\(DOI\))i(is)f(supp)r(orted.)58 b(If)34 b(the)h(DOI)g(determination)f(fails,)i(the)208 5222 y(pa)n(yload)26 b(is)h(discarded)g(and)g(the)h(follo)n(wing)f(action)g(is)g(tak)n(en:) 243 5386 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(DOI)p Fk(,)f(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g (appropriate)e(system)h(audit)h(\014le.)0 5656 y(Maughan,)f(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(55])p eop %%Page: 56 56 56 55 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)101 390 y(3.)42 b(Determine)31 b(if)h(the)g(Proto)r(col-Id)d(is)i(supp)r(orted.)48 b(If)32 b(the)f(Proto)r(col-Id)f(determination)h(fails,)h(the)f(pa)n(yload)f (is)h(dis-)208 490 y(carded)26 b(and)i(the)g(follo)n(wing)e(action)h (is)h(tak)n(en:)243 655 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(PR)n(OTOCOL-ID)p Fk(,)f(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g(the)h(appropriate)e(system)i(audit)f(\014le.) 101 819 y(4.)42 b(Determine)26 b(if)g(the)g(SPI)f(is)h(v)-5 b(alid.)36 b(If)27 b(the)f(SPI)f(is)h(in)n(v)-5 b(alid,)26 b(the)g(pa)n(yload)e(is)i(discarded)f(and)g(the)h(follo)n(wing)f (action)g(is)208 919 y(tak)n(en:)243 1084 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(SPI)p Fk(,)g(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g(the)h(appropriate)e(system) i(audit)f(\014le.)101 1249 y(5.)42 b(Determine)30 b(if)h(the)g(Notify)f (Message)f(T)n(yp)r(e)h(is)g(v)-5 b(alid.)45 b(If)31 b(the)f(Notify)h(Message)e(T)n(yp)r(e)h(is)g(in)n(v)-5 b(alid,)31 b(the)g(pa)n(yload)d(is)208 1348 y(discarded)e(and)i(the)g (follo)n(wing)e(action)h(is)h(tak)n(en:)243 1513 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(MESSA)n(GE)i(TYPE)p Fk(,)f(MA)-7 b(Y)28 b(b)r(e)g(logged)e(in)i(the)g(appropriate)e(system) h(audit)h(\014le.)101 1678 y(6.)42 b(Pro)r(cess)25 b(the)i (Noti\014cation)g(pa)n(yload,)f(including)h(additional)f (Noti\014cation)h(Data,)g(and)g(tak)n(e)f(appropriate)g(action,)208 1778 y(according)f(to)j(lo)r(cal)f(securit)n(y)g(p)r(olicy)-7 b(.)0 2109 y Fj(5.15)112 b(Delete)37 b(P)m(a)m(yload)g(Pro)s(cessing)0 2362 y Fk(During)22 b(comm)n(unications)e(it)i(is)g(p)r(ossible)f(that) h(hosts)g(ma)n(y)f(b)r(e)h(compromised)e(or)h(that)h(information)f(ma)n (y)g(b)r(e)h(in)n(tercepted)0 2462 y(during)33 b(transmission.)52 b(Determining)33 b(whether)g(this)g(has)g(o)r(ccurred)f(is)h(not)g(an)g (easy)f(task)g(and)h(is)g(outside)g(the)h(scop)r(e)0 2561 y(of)j(this)g(In)n(ternet-Draft.)64 b(Ho)n(w)n(ev)n(er,)37 b(if)g(it)g(is)g(disco)n(v)n(ered)d(that)j(transmissions)e(are)h(b)r (eing)h(compromised,)h(then)f(it)g(is)0 2661 y(necessary)26 b(to)h(establish)h(a)f(new)g(SA)h(and)g(delete)g(the)g(curren)n(t)e (SA.)0 2860 y(The)h(Informational)e(Exc)n(hange)g(with)i(a)f(Delete)h (P)n(a)n(yload)d(pro)n(vides)h(a)h(con)n(trolled)f(metho)r(d)i(of)g (informing)f(a)g(p)r(eer)g(en)n(tit)n(y)0 2960 y(that)38 b(the)h(transmitting)f(en)n(tit)n(y)g(has)f(deleted)i(the)f(SA\(s\).)70 b(Deletion)38 b(of)g(Securit)n(y)g(Asso)r(ciations)f(MUST)h(alw)n(a)n (ys)f(b)r(e)0 3059 y(p)r(erformed)d(under)g(the)h(protection)f(of)g(an) g(ISAKMP)g(SA.)h(The)f(receiving)f(en)n(tit)n(y)i(SHOULD)g(clean)f(up)g (its)h(lo)r(cal)f(SA)0 3159 y(database.)k(Ho)n(w)n(ev)n(er,)26 b(up)r(on)j(receipt)f(of)g(a)g(Delete)g(message)f(the)i(SAs)f(listed)h (in)f(the)h(Securit)n(y)f(P)n(arameter)e(Index)i(\(SPI\))0 3259 y(\014eld)j(of)g(the)h(Delete)f(pa)n(yload)f(cannot)g(b)r(e)h (used)g(with)h(the)f(transmitting)g(en)n(tit)n(y)-7 b(.)47 b(The)31 b(SA)h(Establishmen)n(t)e(pro)r(cedure)0 3358 y(m)n(ust)e(b)r(e)g(in)n(v)n(ok)n(ed)e(to)h(re-establish)g(secure)f (comm)n(unications.)0 3557 y(When)i(creating)f(a)g(Delete)h(P)n(a)n (yload,)d(the)j(transmitting)f(en)n(tit)n(y)h(\(initiator)f(or)g(resp)r (onder\))g(MUST)h(do)f(the)h(follo)n(wing:)101 3837 y(1.)42 b(Determine)28 b(the)g(DOI)f(for)g(this)h(Deletion.)101 3969 y(2.)42 b(Determine)28 b(the)g(Proto)r(col-ID)d(for)i(this)h (Deletion.)101 4101 y(3.)42 b(Determine)23 b(the)g(SPI)f(size)h(based)f (on)h(the)g(Proto)r(col-ID)e(\014eld.)35 b(This)23 b(\014eld)g(is)g (necessary)e(b)r(ecause)h(di\013eren)n(t)h(securit)n(y)208 4201 y(proto)r(cols)e(ha)n(v)n(e)h(di\013eren)n(t)h(SPI)g(sizes.)34 b(F)-7 b(or)23 b(example,)g(ISAKMP)g(com)n(bines)f(the)h(Initiator)g (and)g(Resp)r(onder)f(co)r(okie)208 4300 y(pair)k(\(16)h(o)r(ctets\))h (as)f(a)g(SPI,)h(while)g(ESP)e(and)i(AH)g(ha)n(v)n(e)e(8)i(o)r(ctet)f (SPIs.)101 4432 y(4.)42 b(Determine)28 b(the)g(#)f(of)h(SPIs)f(to)g(b)r (e)h(deleted)g(for)f(this)h(proto)r(col.)101 4565 y(5.)42 b(Determine)28 b(the)g(SPI\(s\))f(whic)n(h)h(is)f(\(are\))g(asso)r (ciated)g(with)h(this)g(deletion.)101 4697 y(6.)42 b(Construct)27 b(a)g(Delete)h(pa)n(yload.)101 4829 y(7.)42 b(T)-7 b(ransmit)27 b(the)h(message)e(to)h(the)h(receiving)f(en)n(tit)n(y)g(as)g(describ)r (ed)h(in)f(section)h(5.1.)0 5108 y(Because)36 b(the)i(Informational)f (Exc)n(hange)e(with)j(a)f(Delete)h(pa)n(yload)e(is)i(a)f (unidirectional)g(message)f(a)h(retransmission)0 5208 y(will)d(not)g(b)r(e)g(p)r(erformed.)55 b(The)34 b(lo)r(cal)f(securit)n (y)g(p)r(olicy)h(will)g(dictate)g(the)g(pro)r(cedures)f(for)g(con)n (tin)n(uing.)55 b(Ho)n(w)n(ev)n(er,)33 b(w)n(e)0 5308 y(RECOMMEND)d(that)g(a)f(DELETE)g(P)-7 b(A)g(YLO)n(AD)30 b(ERR)n(OR)g(ev)n(en)n(t)f(b)r(e)h(logged)f(in)h(the)h(appropriate)d (system)i(audit)g(\014le)0 5407 y(b)n(y)d(the)h(receiving)f(en)n(tit)n (y)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(56])p eop %%Page: 57 57 57 56 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y(As)35 b(describ)r(ed)f(ab)r(o)n(v)n (e,)h(the)g(Informational)e(Exc)n(hange)g(with)i(a)f(Delete)h(pa)n (yload)e(MUST)j(b)r(e)f(transmitted)f(under)h(the)0 490 y(protection)27 b(pro)n(vided)f(b)n(y)i(an)f(ISAKMP)g(SA.)0 689 y(When)h(a)f(Delete)h(pa)n(yload)e(is)i(receiv)n(ed,)f(the)h (receiving)e(en)n(tit)n(y)i(\(initiator)f(or)g(resp)r(onder\))f(MUST)i (do)g(the)g(follo)n(wing:)101 971 y(1.)42 b(Because)27 b(the)j(Informational)d(Exc)n(hange)h(is)g(protected)h(b)n(y)g(some)f (securit)n(y)g(service)g(\(e.g.)40 b(authen)n(tication)29 b(for)f(an)208 1071 y(Auth-Only)19 b(SA,)i(encryption)e(for)g(other)g (exc)n(hanges\),)h(the)g(message)e(MUST)j(ha)n(v)n(e)d(these)i(securit) n(y)f(services)f(applied)208 1171 y(using)30 b(the)h(ISAKMP)f(SA.)h (Once)f(the)h(securit)n(y)e(service)h(pro)r(cessing)f(is)h(complete)h (the)f(pro)r(cessing)f(can)i(con)n(tin)n(ue)208 1270 y(as)c(describ)r(ed)g(b)r(elo)n(w.)37 b(An)n(y)28 b(errors)d(that)j(o)r (ccur)f(during)g(the)h(securit)n(y)f(service)g(pro)r(cessing)f(will)i (b)r(e)g(eviden)n(t)g(when)208 1370 y(c)n(hec)n(king)f(information)h (in)g(the)h(Delete)g(pa)n(yload.)38 b(The)29 b(lo)r(cal)f(securit)n(y)f (p)r(olicy)i(SHOULD)g(dictate)g(an)n(y)e(action)h(to)208 1469 y(b)r(e)g(tak)n(en)f(as)f(a)i(result)f(of)h(securit)n(y)e(service) h(pro)r(cessing)f(errors.)101 1602 y(2.)42 b(Determine)34 b(if)h(the)g(Domain)f(of)h(In)n(terpretation)e(\(DOI\))i(is)f(supp)r (orted.)58 b(If)34 b(the)h(DOI)g(determination)f(fails,)i(the)208 1702 y(pa)n(yload)26 b(is)h(discarded)g(and)g(the)h(follo)n(wing)f (action)g(is)g(tak)n(en:)243 1868 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(DOI)p Fk(,)f(MA)-7 b(Y)29 b(b)r(e)f(logged)e(in)i(the)g(appropriate)e(system)h(audit)h (\014le.)101 2034 y(3.)42 b(Determine)31 b(if)h(the)g(Proto)r(col-Id)d (is)i(supp)r(orted.)48 b(If)32 b(the)f(Proto)r(col-Id)f(determination)h (fails,)h(the)f(pa)n(yload)f(is)h(dis-)208 2134 y(carded)26 b(and)i(the)g(follo)n(wing)e(action)h(is)h(tak)n(en:)243 2300 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(PR)n(OTOCOL-ID)p Fk(,)f(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g(the)h (appropriate)e(system)i(audit)f(\014le.)101 2466 y(4.)42 b(Determine)25 b(if)h(the)g(SPI)f(is)g(v)-5 b(alid)25 b(for)g(eac)n(h)f(SPI)h(included)h(in)f(the)h(Delete)g(pa)n(yload.)34 b(F)-7 b(or)25 b(eac)n(h)f(SPI)h(that)h(is)f(in)n(v)-5 b(alid,)208 2565 y(the)28 b(follo)n(wing)e(action)h(is)h(tak)n(en:)243 2731 y(\(a\))41 b(The)28 b(ev)n(en)n(t,)f Fb(INV)-8 b(ALID)28 b(SPI)p Fk(,)g(MA)-7 b(Y)28 b(b)r(e)g(logged)f(in)g(the)h(appropriate)e (system)i(audit)f(\014le.)101 2897 y(5.)42 b(Pro)r(cess)18 b(the)j(Delete)h(pa)n(yload)d(and)h(tak)n(e)g(appropriate)f(action,)j (according)d(to)h(lo)r(cal)g(securit)n(y)g(p)r(olicy)-7 b(.)35 b(As)20 b(describ)r(ed)208 2997 y(ab)r(o)n(v)n(e,)26 b(one)h(appropriate)f(action)h(SHOULD)h(include)g(cleaning)f(up)h(the)g (lo)r(cal)f(SA)h(database.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(57])p eop %%Page: 58 58 58 57 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(6)137 b(Conclusions)0 672 y Fk(The)35 b(In)n(ternet)g(Securit)n(y)g(Asso)r(ciation)f(and)h (Key)f(Managemen)n(t)g(Proto)r(col)f(\(ISAKMP\))i(is)g(a)g(w)n(ell)g (designed)f(proto)r(col)0 771 y(aimed)k(at)g(the)h(In)n(ternet)f(of)g (the)h(future.)69 b(The)38 b(massiv)n(e)f(gro)n(wth)g(of)h(the)g(In)n (ternet)g(will)h(lead)f(to)g(great)f(div)n(ersit)n(y)g(in)0 871 y(net)n(w)n(ork)22 b(utilization,)i(comm)n(unications,)f(securit)n (y)g(requiremen)n(ts,)g(and)g(securit)n(y)f(mec)n(hanisms.)35 b(ISAKMP)23 b(con)n(tains)f(all)0 971 y(the)28 b(features)f(that)h (will)g(b)r(e)g(needed)f(for)h(this)f(dynamic)h(and)f(expanding)g(comm) n(unications)g(en)n(vironmen)n(t.)0 1170 y(ISAKMP's)32 b(Securit)n(y)g(Asso)r(ciation)f(\(SA\))j(feature)e(coupled)g(with)h (authen)n(tication)f(and)g(k)n(ey)g(establishmen)n(t)h(pro)n(vides)0 1269 y(the)h(securit)n(y)f(and)h(\015exibilit)n(y)g(that)g(will)g(b)r (e)g(needed)g(for)f(future)h(gro)n(wth)f(and)g(div)n(ersit)n(y)-7 b(.)55 b(This)34 b(securit)n(y)f(div)n(ersit)n(y)f(of)0 1369 y(m)n(ultiple)27 b(k)n(ey)f(exc)n(hange)f(tec)n(hniques,)h (encryption)g(algorithms,)f(authen)n(tication)h(mec)n(hanisms,)g (securit)n(y)g(services,)f(and)0 1469 y(securit)n(y)36 b(attributes)h(will)h(allo)n(w)e(users)g(to)h(select)g(the)g (appropriate)f(securit)n(y)g(for)h(their)g(net)n(w)n(ork,)h(comm)n (unications,)0 1568 y(and)30 b(securit)n(y)g(needs.)45 b(The)31 b(SA)f(feature)g(allo)n(ws)g(users)f(to)h(sp)r(ecify)h(and)f (negotiate)g(securit)n(y)f(requiremen)n(ts)h(with)h(other)0 1668 y(users.)k(An)27 b(additional)e(b)r(ene\014t)i(of)f(supp)r(orting) g(m)n(ultiple)g(tec)n(hniques)g(in)g(a)g(single)f(proto)r(col)g(is)h (that)g(as)f(new)h(tec)n(hniques)0 1768 y(are)33 b(dev)n(elop)r(ed)h (they)h(can)e(easily)h(b)r(e)h(added)f(to)g(the)h(proto)r(col.)55 b(This)34 b(pro)n(vides)f(a)h(path)h(for)e(the)i(gro)n(wth)e(of)h(In)n (ternet)0 1867 y(securit)n(y)24 b(services.)35 b(ISAKMP)25 b(supp)r(orts)g(b)r(oth)h(publicly)f(or)g(priv)-5 b(ately)24 b(de\014ned)i(SAs,)g(making)f(it)g(ideal)g(for)g(go)n(v)n(ernmen)n(t,)0 1967 y(commercial,)h(and)i(priv)-5 b(ate)27 b(comm)n(unications.)0 2166 y(ISAKMP)41 b(pro)n(vides)f(the)i(abilit)n(y)f(to)g(establish)g (SAs)h(for)e(m)n(ultiple)i(securit)n(y)f(proto)r(cols)f(and)h (applications.)77 b(These)0 2266 y(proto)r(cols)34 b(and)h (applications)f(ma)n(y)g(b)r(e)h(session-orien)n(ted)e(or)h (sessionless.)58 b(Ha)n(ving)34 b(one)h(SA)g(establishmen)n(t)g(proto)r (col)0 2365 y(that)d(supp)r(orts)f(m)n(ultiple)h(securit)n(y)f(proto)r (cols)f(eliminates)i(the)g(need)g(for)f(m)n(ultiple,)i(nearly)e(iden)n (tical)g(authen)n(tication,)0 2465 y(k)n(ey)j(exc)n(hange)e(and)i(SA)h (establishmen)n(t)f(proto)r(cols)f(when)h(more)g(than)g(one)g(securit)n (y)f(proto)r(col)g(is)i(in)f(use)g(or)g(desired.)0 2565 y(Just)f(as)g(IP)g(has)g(pro)n(vided)g(the)h(common)f(net)n(w)n(orking) f(la)n(y)n(er)g(for)h(the)g(In)n(ternet,)i(a)f(common)f(securit)n(y)f (establishmen)n(t)0 2664 y(proto)r(col)f(is)h(needed)g(if)h(securit)n (y)e(is)h(to)g(b)r(ecome)g(a)g(realit)n(y)f(on)g(the)i(In)n(ternet.)50 b(ISAKMP)32 b(pro)n(vides)f(the)h(common)g(base)0 2764 y(that)c(allo)n(ws)e(all)h(other)g(securit)n(y)g(proto)r(cols)f(to)i (in)n(terop)r(erate.)0 2963 y(ISAKMP)34 b(follo)n(ws)f(go)r(o)r(d)h (securit)n(y)f(design)h(principles.)57 b(It)34 b(is)g(not)h(coupled)f (to)g(other)g(insecure)f(transp)r(ort)g(proto)r(cols,)0 3063 y(therefore)27 b(it)i(is)f(not)g(vulnerable)g(or)f(w)n(eak)n(ened) g(b)n(y)h(attac)n(ks)f(on)h(other)f(proto)r(cols.)38 b(Also,)28 b(when)g(more)g(secure)f(transp)r(ort)0 3162 y(proto)r(cols)21 b(are)g(dev)n(elop)r(ed,)i(ISAKMP)e(can)h(b)r(e)g (easily)g(migrated)f(to)h(them.)36 b(ISAKMP)21 b(also)g(pro)n(vides)g (protection)g(against)0 3262 y(proto)r(col)k(related)h(attac)n(ks.)36 b(This)26 b(protection)g(pro)n(vides)f(the)i(assurance)e(that)i(the)g (SAs)g(and)f(k)n(eys)g(established)g(are)g(with)0 3362 y(the)i(desired)f(part)n(y)g(and)g(not)h(with)g(an)f(attac)n(k)n(er.)0 3561 y(ISAKMP)i(also)g(follo)n(ws)f(go)r(o)r(d)h(proto)r(col)f(design)h (principles.)43 b(Proto)r(col)27 b(sp)r(eci\014c)j(information)f(only)g (is)h(in)f(the)h(proto)r(col)0 3660 y(header,)39 b(follo)n(wing)d(the)i (design)f(principles)g(of)g(IPv6.)65 b(The)38 b(data)f(transp)r(orted)f (b)n(y)h(the)h(proto)r(col)e(is)h(separated)f(in)n(to)0 3760 y(functional)27 b(pa)n(yloads.)35 b(As)27 b(the)g(In)n(ternet)g (gro)n(ws)e(and)i(ev)n(olv)n(es,)e(new)i(pa)n(yloads)e(to)i(supp)r(ort) g(new)g(securit)n(y)f(functionalit)n(y)0 3860 y(can)h(b)r(e)h(added)g (without)g(mo)r(difying)f(the)h(en)n(tire)g(proto)r(col.)0 5656 y(Maughan,)f(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(58])p eop %%Page: 59 59 59 58 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(A)137 b(ISAKMP)46 b(Securit)l(y)h(Asso)t(ciation)f(A)l(ttributes)0 688 y Fj(A.1)112 b(Bac)m(kground/Rationale)0 941 y Fk(As)19 b(detailed)h(in)f(previous)g(sections,)h(ISAKMP)f(is)g(designed)g(to)g (pro)n(vide)g(a)g(\015exible)g(and)g(extensible)h(framew)n(ork)d(for)i (estab-)0 1041 y(lishing)29 b(and)g(managing)e(Securit)n(y)i(Asso)r (ciations)f(and)h(cryptographic)e(k)n(eys.)40 b(The)29 b(framew)n(ork)f(pro)n(vided)g(b)n(y)g(ISAKMP)0 1140 y(consists)f(of)h(header)f(and)h(pa)n(yload)e(de\014nitions,)j(exc)n (hange)d(t)n(yp)r(es)i(for)g(guiding)f(message)g(and)g(pa)n(yload)g (exc)n(hanges,)f(and)0 1240 y(general)j(pro)r(cessing)f(guidelines.)44 b(ISAKMP)29 b(do)r(es)h(not)g(de\014ne)g(the)h(mec)n(hanisms)e(that)h (will)g(b)r(e)h(used)f(to)g(establish)f(and)0 1340 y(manage)22 b(Securit)n(y)g(Asso)r(ciations)g(and)h(cryptographic)e(k)n(eys)g(in)j (an)e(authen)n(ticated)h(and)g(con\014den)n(tial)f(manner.)35 b(The)23 b(def-)0 1439 y(inition)28 b(of)f(mec)n(hanisms)g(and)h(their) f(application)g(is)h(the)g(purview)f(of)g(individual)h(Domains)f(of)h (In)n(terpretation)e(\(DOIs\).)0 1639 y(This)k(section)g(describ)r(es)g (the)g(ISAKMP)g(v)-5 b(alues)30 b(for)g(the)h(In)n(ternet)f(IP)g (Securit)n(y)g(DOI,)g(supp)r(orted)g(securit)n(y)f(proto)r(cols,)0 1738 y(and)23 b(iden)n(ti\014cation)g(v)-5 b(alues)22 b(for)g(ISAKMP)h(Phase)f(1)g(negotiations.)34 b(The)23 b(In)n(ternet)g(IP)g(Securit)n(y)f(DOI)h(is)g(MAND)n(A)-7 b(TOR)g(Y)0 1838 y(to)29 b(implemen)n(t)h(for)f(IP)f(Securit)n(y)-7 b(.)42 b([Oakley)n(])30 b(and)f([IKE)o(])g(describ)r(e,)g(in)h(detail,) g(the)f(mec)n(hanisms)g(and)g(their)g(application)0 1937 y(for)e(establishing)g(and)g(managing)g(Securit)n(y)g(Asso)r(ciations)f (and)i(cryptographic)d(k)n(eys)i(for)g(IP)g(Securit)n(y)-7 b(.)0 2269 y Fj(A.2)112 b(In)m(ternet)37 b(IP)f(Securit)m(y)h(DOI)g (Assigned)g(V)-9 b(alue)0 2522 y Fk(As)28 b(describ)r(ed)f(in)h([IPDOI) o(],)g(the)g(In)n(ternet)g(IP)f(Securit)n(y)g(DOI)h(Assigned)f(Num)n(b) r(er)h(is)f(one)g(\(1\).)0 2854 y Fj(A.3)112 b(Supp)s(orted)38 b(Securit)m(y)f(Proto)s(cols)0 3107 y Fk(V)-7 b(alues)27 b(for)f(supp)r(orted)h(securit)n(y)g(proto)r(cols)e(are)h(sp)r (eci\014ed)i(in)f(the)h(most)f(recen)n(t)f(\\Assigned)g(Num)n(b)r(ers") h(RF)n(C)g([STD-2].)0 3207 y(Presen)n(ted)35 b(in)i(the)g(follo)n(wing) e(table)i(are)e(the)i(v)-5 b(alues)36 b(for)g(the)h(securit)n(y)e (proto)r(cols)g(supp)r(orted)i(b)n(y)f(ISAKMP)g(for)g(the)0 3306 y(In)n(ternet)27 b(IP)h(Securit)n(y)f(DOI.)1470 3583 y(Proto)r(col)171 b(Assigned)27 b(V)-7 b(alue)p 1347 3617 1206 4 v 1397 3686 a(RESER)e(VED)354 b(0)1397 3786 y(ISAKMP)473 b(1)0 4064 y(All)25 b(DOIs)f(MUST)h(reserv)n(e)d (ISAKMP)i(with)h(a)f(Proto)r(col-ID)f(of)h(1.)36 b(All)24 b(other)g(securit)n(y)g(proto)r(cols)f(within)i(that)f(DOI)h(will)0 4164 y(b)r(e)j(n)n(um)n(b)r(ered)f(accordingly)-7 b(.)0 4363 y(Securit)n(y)28 b(proto)r(col)f(v)-5 b(alues)28 b(2-15359)e(are)h(reserv)n(ed)g(to)h(IANA)i(for)e(future)h(use.)39 b(V)-7 b(alues)29 b(15360-16383)23 b(are)k(p)r(ermanen)n(tly)0 4463 y(reserv)n(ed)d(for)i(priv)-5 b(ate)26 b(use)g(amongst)g(m)n (utually)g(consen)n(ting)f(implemen)n(tations.)37 b(Suc)n(h)26 b(priv)-5 b(ate)26 b(use)g(v)-5 b(alues)26 b(are)f(unlik)n(ely)0 4562 y(to)i(b)r(e)h(in)n(terop)r(erable)f(across)e(di\013eren)n(t)j (implemen)n(tations.)0 4895 y Fj(A.4)112 b(ISAKMP)37 b(Iden)m(ti\014cation)e(T)m(yp)s(e)j(V)-9 b(alues)0 5147 y Fk(The)38 b(follo)n(wing)f(table)h(lists)g(the)h(assigned)d(v)-5 b(alues)38 b(for)g(the)g(Iden)n(ti\014cation)g(T)n(yp)r(e)g(\014eld)g (found)h(in)f(the)g(Iden)n(ti\014cation)0 5247 y(pa)n(yload)26 b(during)h(a)g(generic)g(Phase)f(1)i(exc)n(hange,)e(whic)n(h)h(is)h (not)f(for)g(a)h(sp)r(eci\014c)f(proto)r(col.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(59])p eop %%Page: 60 60 60 59 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)1645 377 y(ID)h(T)n(yp)r(e)430 b(V)-7 b(alue)p 1264 410 1372 4 v 1314 480 a(ID)p 1412 480 25 4 v 30 w(IPV4)p 1633 480 V 29 w(ADDR)558 b(0)1314 579 y(ID)p 1412 579 V 30 w(IPV4)p 1633 579 V 29 w(ADDR)p 1911 579 V 32 w(SUBNET)180 b(1)1314 679 y(ID)p 1412 679 V 30 w(IPV6)p 1633 679 V 29 w(ADDR)558 b(2)1314 779 y(ID)p 1412 779 V 30 w(IPV6)p 1633 779 V 29 w(ADDR)p 1911 779 V 32 w(SUBNET)180 b(3)0 1189 y Fe(A.4.1)94 b(ID)p 431 1189 29 4 v 35 w(IPV4)p 687 1189 V 35 w(ADDR)0 1442 y Fk(The)28 b(ID)p 269 1442 25 4 v 30 w(IPV4)p 490 1442 V 29 w(ADDR)h(t)n(yp)r(e)f(sp)r(eci\014es)f(a)g(single)h(four)f(\(4\))g (o)r(ctet)h(IPv4)f(address.)0 1758 y Fe(A.4.2)94 b(ID)p 431 1758 29 4 v 35 w(IPV4)p 687 1758 V 35 w(ADDR)p 1012 1758 V 34 w(SUBNET)0 2010 y Fk(The)31 b(ID)p 272 2010 25 4 v 30 w(IPV4)p 493 2010 V 29 w(ADDR)p 771 2010 V 31 w(SUBNET)g(t)n(yp)r(e)g(sp)r(eci\014es)f(a)g(range)f(of)i(IPv4)f (addresses,)f(represen)n(ted)h(b)n(y)g(t)n(w)n(o)g(four)g(\(4\))h(o)r (ctet)0 2110 y(v)-5 b(alues.)53 b(The)33 b(\014rst)g(v)-5 b(alue)33 b(is)f(an)h(IPv4)f(address.)52 b(The)33 b(second)f(is)h(an)g (IPv4)f(net)n(w)n(ork)g(mask.)52 b(Note)33 b(that)h(ones)e(\(1s\))h(in) 0 2210 y(the)j(net)n(w)n(ork)e(mask)h(indicate)g(that)h(the)g(corresp)r (onding)e(bit)i(in)f(the)h(address)f(is)g(\014xed,)j(while)d(zeros)g (\(0s\))g(indicate)g(a)0 2309 y("wildcard")26 b(bit.)0 2625 y Fe(A.4.3)94 b(ID)p 431 2625 29 4 v 35 w(IPV6)p 687 2625 V 35 w(ADDR)0 2878 y Fk(The)28 b(ID)p 269 2878 25 4 v 30 w(IPV6)p 490 2878 V 29 w(ADDR)h(t)n(yp)r(e)f(sp)r(eci\014es)f (a)g(single)h(sixteen)f(\(16\))g(o)r(ctet)h(IPv6)f(address.)0 3193 y Fe(A.4.4)94 b(ID)p 431 3193 29 4 v 35 w(IPV6)p 687 3193 V 35 w(ADDR)p 1012 3193 V 34 w(SUBNET)0 3446 y Fk(The)36 b(ID)p 277 3446 25 4 v 30 w(IPV6)p 498 3446 V 29 w(ADDR)p 776 3446 V 31 w(SUBNET)g(t)n(yp)r(e)f(sp)r(eci\014es)h(a) f(range)f(of)h(IPv6)g(addresses,)h(represen)n(ted)e(b)n(y)h(t)n(w)n(o)g (sixteen)g(\(16\))0 3546 y(o)r(ctet)29 b(v)-5 b(alues.)39 b(The)29 b(\014rst)f(v)-5 b(alue)28 b(is)h(an)f(IPv6)f(address.)39 b(The)28 b(second)g(is)g(an)h(IPv6)e(net)n(w)n(ork)g(mask.)39 b(Note)29 b(that)f(ones)g(\(1s\))0 3645 y(in)i(the)g(net)n(w)n(ork)f (mask)g(indicate)g(that)i(the)f(corresp)r(onding)e(bit)i(in)g(the)g (address)f(is)g(\014xed,)i(while)f(zeros)e(\(0s\))i(indicate)f(a)0 3745 y("wildcard")d(bit.)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n (hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(60])p eop %%Page: 61 61 61 60 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(B)137 b(De\014ning)48 b(a)d(new)i(Domain)f(of)f(In)l(terpretation)0 672 y Fk(The)37 b(In)n(ternet)f(DOI)g(ma)n(y)g(b)r(e)h(su\016cien)n(t)g(to)f(meet)h (the)f(securit)n(y)g(requiremen)n(ts)f(of)i(a)f(large)f(p)r(ortion)h (of)g(the)h(in)n(ternet)0 771 y(comm)n(unit)n(y)-7 b(.)53 b(Ho)n(w)n(ev)n(er,)33 b(some)f(groups)g(ma)n(y)g(ha)n(v)n(e)g(a)h (need)g(to)g(customize)g(some)g(asp)r(ect)g(of)g(a)f(DOI,)i(p)r(erhaps) e(to)h(add)0 871 y(a)h(di\013eren)n(t)g(set)g(of)g(cryptographic)e (algorithms,)j(or)e(p)r(erhaps)g(b)r(ecause)h(they)g(w)n(an)n(t)g(to)g (mak)n(e)f(their)h(securit)n(y-relev)-5 b(an)n(t)0 971 y(decisions)27 b(based)h(on)g(something)g(other)f(than)i(a)f(host)g(id) g(or)f(user)h(id.)39 b(Also,)28 b(a)g(particular)f(group)g(ma)n(y)g(ha) n(v)n(e)g(a)h(need)h(for)0 1070 y(a)e(new)h(exc)n(hange)e(t)n(yp)r(e,)i (for)f(example)g(to)h(supp)r(ort)f(k)n(ey)g(managemen)n(t)f(for)i(m)n (ulticast)f(groups.)0 1269 y(This)h(section)g(discusses)g(guidelines)g (for)f(de\014ning)i(a)f(new)g(DOI.)g(The)h(full)g(sp)r(eci\014cation)f (for)g(the)g(In)n(ternet)g(DOI)h(can)f(b)r(e)0 1369 y(found)g(in)g ([IPDOI)o(].)0 1568 y(De\014ning)h(a)e(new)i(DOI)f(is)g(lik)n(ely)g(to) g(b)r(e)g(a)g(time-consuming)g(pro)r(cess.)37 b(If)29 b(at)f(all)g(p)r(ossible,)g(it)g(is)h(recommended)e(that)i(the)0 1668 y(designer)e(b)r(egin)g(with)h(an)g(existing)f(DOI)g(and)h (customize)f(only)g(the)h(parts)f(that)h(are)f(unacceptable.)0 1867 y(If)h(a)f(designer)g(c)n(ho)r(oses)f(to)h(start)g(from)h(scratc)n (h,)e(the)i(follo)n(wing)f(MUST)h(b)r(e)g(de\014ned:)125 2149 y Fc(\017)41 b Fk(A)27 b(\\situation":)36 b(the)28 b(set)g(of)f(information)g(that)h(will)g(b)r(e)g(used)g(to)f(determine) h(the)g(required)e(securit)n(y)h(services.)125 2316 y Fc(\017)41 b Fk(The)27 b(set)h(of)f(securit)n(y)g(p)r(olicies)g(that)h (m)n(ust)g(b)r(e)g(supp)r(orted.)125 2482 y Fc(\017)41 b Fk(A)d(sc)n(heme)h(for)f(naming)g(securit)n(y-relev)-5 b(an)n(t)36 b(information,)41 b(including)e(encryption)f(algorithms,)i (k)n(ey)e(exc)n(hange)208 2581 y(algorithms,)26 b(etc.)125 2747 y Fc(\017)41 b Fk(A)27 b(syn)n(tax)g(for)g(the)h(sp)r (eci\014cation)f(of)h(prop)r(osed)f(securit)n(y)f(services,)h (attributes,)g(and)h(certi\014cate)f(authorities.)125 2913 y Fc(\017)41 b Fk(The)27 b(sp)r(eci\014c)h(formats)f(of)g(the)h(v) -5 b(arious)27 b(pa)n(yload)f(con)n(ten)n(ts.)125 3079 y Fc(\017)41 b Fk(Additional)27 b(exc)n(hange)g(t)n(yp)r(es,)g(if)h (required.)0 3411 y Fj(B.1)112 b(Situation)0 3664 y Fk(The)28 b(situation)g(is)g(the)g(basis)g(for)f(deciding)h(ho)n(w)f(to)h (protect)g(a)f(comm)n(unications)g(c)n(hannel.)38 b(It)29 b(m)n(ust)f(con)n(tain)f(all)h(of)g(the)0 3764 y(data)h(that)i(will)f (b)r(e)g(used)g(to)g(determine)g(the)g(t)n(yp)r(es)g(and)g(strengths)f (of)h(protections)f(applied)h(in)g(an)g(SA.)g(F)-7 b(or)29 b(example,)0 3863 y(a)i(US)g(Departmen)n(t)g(of)g(Defense)g(DOI)g(w)n (ould)g(probably)e(use)i(unpublished)h(algorithms)d(and)i(ha)n(v)n(e)f (additional)g(sp)r(ecial)0 3963 y(attributes)e(to)f(negotiate.)36 b(These)27 b(additional)g(securit)n(y)g(attributes)h(w)n(ould)f(b)r(e)h (included)g(in)g(the)g(situation.)0 4295 y Fj(B.2)112 b(Securit)m(y)36 b(P)m(olicies)0 4548 y Fk(Securit)n(y)25 b(p)r(olicies)h(de\014ne)g(ho)n(w)f(v)-5 b(arious)24 b(t)n(yp)r(es)i(of)f(information)g(m)n(ust)h(b)r(e)g(categorized)e(and) i(protected.)35 b(The)26 b(DOI)g(m)n(ust)0 4648 y(de\014ne)h(the)f(set) h(of)f(securit)n(y)g(p)r(olicies)g(supp)r(orted,)g(b)r(ecause)g(b)r (oth)h(parties)e(in)i(a)f(negotiation)f(m)n(ust)i(trust)f(that)h(the)g (other)0 4747 y(part)n(y)33 b(understands)f(a)i(situation,)g(and)g (will)g(protect)f(information)g(appropriately)-7 b(,)33 b(b)r(oth)h(in)g(transit)f(and)g(in)h(storage.)0 4847 y(In)g(a)f(corp)r(orate)e(setting,)k(for)e(example,)i(b)r(oth)f (parties)e(in)i(a)f(negotiation)f(m)n(ust)i(agree)e(to)h(the)h(meaning) f(of)g(the)h(term)0 4946 y(\\proprietary)25 b(information")i(b)r(efore) g(they)h(can)f(negotiate)g(ho)n(w)g(to)g(protect)g(it.)0 5146 y(Note)38 b(that)g(including)h(the)f(required)f(securit)n(y)g(p)r (olicies)h(in)g(the)h(DOI)f(only)g(sp)r(eci\014es)g(that)g(the)g (participating)g(hosts)0 5245 y(understand)27 b(and)h(implemen)n(t)g (those)f(p)r(olicies)g(in)h(a)g(full)g(system)f(con)n(text.)0 5656 y(Maughan,)g(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(61])p eop %%Page: 62 62 62 61 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Fj(B.3)112 b(Naming)36 b(Sc)m(hemes)0 643 y Fk(An)n(y)30 b(DOI)f(m)n(ust)h(de\014ne)g(a)f (consisten)n(t)g(w)n(a)n(y)f(to)h(name)h(cryptographic)d(algorithms,)i (certi\014cate)g(authorities,)g(etc.)43 b(This)0 743 y(can)27 b(usually)g(b)r(e)h(done)g(b)n(y)f(using)g(IANA)i(naming)e (con)n(v)n(en)n(tions,)f(p)r(erhaps)h(with)h(some)f(priv)-5 b(ate)27 b(extensions.)0 1075 y Fj(B.4)112 b(Syn)m(tax)38 b(for)g(Sp)s(ecifying)e(Securit)m(y)h(Services)0 1328 y Fk(In)32 b(addition)f(to)h(simply)g(sp)r(ecifying)f(ho)n(w)g(to)h (name)f(en)n(tities,)i(the)f(DOI)g(m)n(ust)f(also)g(sp)r(ecify)h(the)g (format)f(for)g(complete)0 1427 y(prop)r(osals)26 b(of)h(ho)n(w)g(to)h (protect)f(tra\016c)g(under)h(a)f(giv)n(en)g(situation.)0 1759 y Fj(B.5)112 b(P)m(a)m(yload)37 b(Sp)s(eci\014cation)0 2012 y Fk(The)21 b(DOI)g(m)n(ust)f(sp)r(ecify)h(the)h(format)e(of)h (eac)n(h)e(of)i(the)g(pa)n(yload)e(t)n(yp)r(es.)35 b(F)-7 b(or)20 b(sev)n(eral)f(of)i(the)g(pa)n(yload)e(t)n(yp)r(es,)j(ISAKMP)f (has)0 2112 y(included)26 b(\014elds)f(that)h(w)n(ould)e(ha)n(v)n(e)h (to)g(b)r(e)g(presen)n(t)g(across)e(all)i(DOI)h(\(suc)n(h)f(as)g(a)f (certi\014cate)h(authorit)n(y)f(in)i(the)g(certi\014cate)0 2211 y(pa)n(yload,)g(or)h(a)g(k)n(ey)g(exc)n(hange)f(iden)n(ti\014er)h (in)h(the)g(k)n(ey)f(exc)n(hange)f(pa)n(yload\).)0 2543 y Fj(B.6)112 b(De\014ning)37 b(new)h(Exc)m(hange)g(T)m(yp)s(es)0 2796 y Fk(If)27 b(the)f(basic)g(exc)n(hange)f(t)n(yp)r(es)h(are)f (inadequate)h(to)g(meet)h(the)f(requiremen)n(ts)f(within)i(a)f(DOI,)g (a)g(designer)f(can)h(de\014ne)h(up)0 2896 y(to)f(thirteen)g(extra)e (exc)n(hange)h(t)n(yp)r(es)g(p)r(er)h(DOI.)g(The)g(designer)e(creates)h (a)g(new)h(exc)n(hange)e(t)n(yp)r(e)i(b)n(y)f(c)n(ho)r(osing)g(an)g(un) n(used)0 2996 y(exc)n(hange)c(t)n(yp)r(e)h(v)-5 b(alue,)24 b(and)e(de\014ning)g(a)g(sequence)g(of)g(messages)f(comp)r(osed)h(of)g (strings)f(of)i(the)f(ISAKMP)g(pa)n(yload)f(t)n(yp)r(es.)0 3195 y(Note)j(that)h(an)n(y)e(new)h(exc)n(hange)f(t)n(yp)r(es)h(m)n (ust)h(b)r(e)f(rigorously)e(analyzed)h(for)h(vulnerabilities.)35 b(Since)24 b(this)h(is)f(an)g(exp)r(ensiv)n(e)0 3294 y(and)j(imprecise)g(undertaking,)g(a)h(new)f(exc)n(hange)f(t)n(yp)r(e)i (should)f(only)h(b)r(e)g(created)e(when)i(absolutely)f(necessary)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(62])p eop %%Page: 63 63 63 62 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(Securit)l(y)47 b(Considerations)0 672 y Fk(Cryptographic)18 b(analysis)g(tec)n (hniques)h(are)g(impro)n(ving)f(at)i(a)f(steady)g(pace.)34 b(The)19 b(con)n(tin)n(uing)g(impro)n(v)n(emen)n(t)g(in)h(pro)r (cessing)0 771 y(p)r(o)n(w)n(er)37 b(mak)n(es)h(once)g(computationally) f(prohibitiv)n(e)h(cryptographic)f(attac)n(ks)g(more)h(realistic.)68 b(New)39 b(cryptographic)0 871 y(algorithms)31 b(and)h(public)h(k)n(ey) e(generation)g(tec)n(hniques)h(are)g(also)f(b)r(eing)h(dev)n(elop)r(ed) g(at)g(a)g(steady)g(pace.)50 b(New)33 b(securit)n(y)0 971 y(services)25 b(and)h(mec)n(hanisms)g(are)f(b)r(eing)i(dev)n(elop)r (ed)f(at)g(an)g(accelerated)f(pace.)36 b(A)26 b(consisten)n(t)g(metho)r (d)h(of)f(c)n(ho)r(osing)f(from)0 1070 y(a)36 b(v)-5 b(ariet)n(y)35 b(of)h(securit)n(y)f(services)f(and)i(mec)n(hanisms)g (and)f(to)h(exc)n(hange)f(attributes)h(required)f(b)n(y)h(the)g(mec)n (hanisms)f(is)0 1170 y(imp)r(ortan)n(t)h(to)g(securit)n(y)f(in)i(the)f (complex)g(structure)g(of)g(the)h(In)n(ternet.)62 b(Ho)n(w)n(ev)n(er,) 37 b(a)f(system)g(that)g(lo)r(c)n(ks)g(itself)g(in)n(to)0 1269 y(a)31 b(single)g(cryptographic)e(algorithm,)j(k)n(ey)e(exc)n (hange)g(tec)n(hnique,)j(or)d(securit)n(y)h(mec)n(hanism)g(will)g(b)r (ecome)h(increasingly)0 1369 y(vulnerable)27 b(as)g(time)h(passes.)0 1568 y(UDP)i(is)f(an)g(unreliable)g(datagram)f(proto)r(col)g(and)h (therefore)g(its)g(use)h(in)f(ISAKMP)h(in)n(tro)r(duces)e(a)h(n)n(um)n (b)r(er)h(of)f(securit)n(y)0 1668 y(considerations.)39 b(Since)29 b(UDP)g(is)g(unreliable,)g(but)g(a)f(k)n(ey)h(managemen)n(t) e(proto)r(col)h(m)n(ust)h(b)r(e)g(reliable,)g(the)g(reliabilit)n(y)f (is)0 1768 y(built)i(in)n(to)g(ISAKMP)-7 b(.)29 b(While)h(ISAKMP)f (utilizes)h(UDP)g(as)e(its)i(transp)r(ort)f(mec)n(hanism,)g(it)h(do)r (esn't)g(rely)f(on)g(an)n(y)g(UDP)0 1867 y(information)e(\(e.g.)37 b(c)n(hec)n(ksum,)26 b(length\))i(for)g(its)f(pro)r(cessing.)0 2066 y(Another)19 b(issue)g(that)h(m)n(ust)f(b)r(e)h(considered)e(in)h (the)h(dev)n(elopmen)n(t)f(of)g(ISAKMP)g(is)g(the)h(e\013ect)f(of)h (\014rew)n(alls)e(on)h(the)g(proto)r(col.)0 2166 y(Man)n(y)27 b(\014rew)n(alls)f(\014lter)i(out)f(all)h(UDP)f(pac)n(k)n(ets,)g (making)g(reliance)f(on)i(UDP)g(questionable)e(in)i(certain)f(en)n (vironmen)n(ts.)0 2365 y(A)38 b(n)n(um)n(b)r(er)f(of)h(v)n(ery)e(imp)r (ortan)n(t)i(securit)n(y)e(considerations)g(are)h(presen)n(ted)g(in)h ([RF)n(C-1825)m(].)68 b(One)37 b(b)r(ears)g(rep)r(eating.)0 2465 y(Once)30 b(a)g(priv)-5 b(ate)31 b(session)e(k)n(ey)h(is)h (created,)f(it)h(m)n(ust)g(b)r(e)g(safely)f(stored.)45 b(F)-7 b(ailure)30 b(to)h(prop)r(erly)e(protect)h(the)h(priv)-5 b(ate)31 b(k)n(ey)0 2565 y(from)c(access)f(b)r(oth)h(in)n(ternal)g(and) g(external)f(to)h(the)h(system)f(completely)g(n)n(ulli\014es)g(an)n(y)f (protection)h(pro)n(vided)f(b)n(y)h(the)h(IP)0 2664 y(Securit)n(y)f (services.)0 3038 y Ff(IANA)45 b(Considerations)0 3320 y Fk(This)30 b(do)r(cumen)n(t)h(con)n(tains)f(man)n(y)g("magic")e(n)n (um)n(b)r(ers)i(to)h(b)r(e)g(main)n(tained)f(b)n(y)g(the)h(IANA.)g (This)g(section)f(explains)g(the)0 3419 y(criteria)c(to)i(b)r(e)g(used) f(b)n(y)h(the)g(IANA)g(to)g(assign)e(additional)h(n)n(um)n(b)r(ers)g (in)h(eac)n(h)f(of)g(these)h(lists.)0 3751 y Fj(Domain)37 b(of)g(In)m(terpretation)0 4004 y Fk(The)30 b(Domain)g(of)h(In)n (terpretation)e(\(DOI\))h(is)h(a)e(32-bit)h(\014eld)g(whic)n(h)g(iden)n (ti\014es)h(the)f(domain)g(under)g(whic)n(h)g(the)h(securit)n(y)0 4104 y(asso)r(ciation)f(negotiation)h(is)g(taking)g(place.)49 b(Requests)31 b(for)g(assignmen)n(ts)g(of)g(new)h(DOIs)g(m)n(ust)f(b)r (e)i(accompanied)d(b)n(y)h(a)0 4204 y(standards-trac)n(k)25 b(RF)n(C)i(whic)n(h)h(describ)r(es)f(the)h(sp)r(eci\014c)g(domain.)0 4536 y Fj(Supp)s(orted)38 b(Securit)m(y)f(Proto)s(cols)0 4789 y Fk(ISAKMP)f(is)h(designed)g(to)f(pro)n(vide)g(securit)n(y)g (asso)r(ciation)f(negotiation)h(and)g(k)n(ey)h(managemen)n(t)e(for)i (man)n(y)f(securit)n(y)0 4888 y(proto)r(cols.)53 b(Requests)33 b(for)g(iden)n(ti\014ers)g(for)g(additional)g(securit)n(y)g(proto)r (cols)f(m)n(ust)h(b)r(e)h(accompanied)e(b)n(y)i(a)f(standards-)0 4988 y(trac)n(k)26 b(RF)n(C)i(whic)n(h)g(describ)r(es)f(the)h(securit)n (y)e(proto)r(col)h(and)g(its)h(relationship)f(to)g(ISAKMP)-7 b(.)0 5656 y(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(63])p eop %%Page: 64 64 64 63 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(Ac)l(kno)l(wledgemen)l(ts)0 672 y Fk(Dan)g(Harkins,)g(Da)n(v)n(e)f(Carrel,)g(and)g(Derrell)h(Pip)r (er)g(of)g(Cisco)f(Systems)h(pro)n(vided)f(design)h(assistance)e(with)j (the)f(proto)r(col)0 771 y(and)g(co)r(ordination)g(for)g(the)h([IKE)o (])g(and)f([IPDOI])g(do)r(cumen)n(ts.)0 971 y(Hilarie)g(Orman,)g(via)g (the)h(Oakley)e(k)n(ey)h(exc)n(hange)f(proto)r(col,)h(has)g (signi\014can)n(tly)f(in\015uenced)i(the)g(design)g(of)f(ISAKMP)-7 b(.)0 1170 y(Marsha)27 b(Gross,)g(Bill)h(Kutz,)g(Mik)n(e)f(Oehler,)h(P) n(ete)f(Sell,)h(and)g(Ruth)h(T)-7 b(a)n(ylor)26 b(pro)n(vided)h (signi\014can)n(t)g(input)i(and)f(review)f(to)0 1269 y(this)h(do)r(cumen)n(t.)0 1469 y(Scott)g(Carlson)e(p)r(orted)h(the)h (TIS)g(DNSSEC)g(protot)n(yp)r(e)f(to)g(F)-7 b(reeBSD)28 b(for)f(use)g(with)i(the)f(ISAKMP)f(protot)n(yp)r(e.)0 1668 y(Je\013)e(T)-7 b(urner)23 b(and)i(Stev)n(e)f(Smalley)g(con)n (tributed)h(to)f(the)h(protot)n(yp)r(e)f(dev)n(elopmen)n(t)g(and)g(in)n (tegration)f(with)i(ESP)f(and)g(AH.)0 1867 y(Mik)n(e)j(Oehler)g(and)g (P)n(ete)g(Sell)h(p)r(erformed)f(in)n(terop)r(erabilit)n(y)g(testing)g (with)h(other)f(ISAKMP)g(implemen)n(tors.)0 2066 y(Thanks)g(to)g(Carl)g (Muc)n(k)n(enhirn)g(of)h(SP)-7 b(AR)g(T)g(A,)28 b(Inc.)37 b(for)27 b(his)g(assistance)g(with)h(L)2539 2055 y Fa(a)2578 2066 y Fk(T)2624 2091 y(E)2669 2066 y(X.)0 5656 y(Maughan,)f(Sc)n (hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(64])p eop %%Page: 65 65 65 64 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(References)0 604 y Fk([ANSI])42 b(ANSI,)26 b Fb(X9.42:)39 b(Public)28 b(Key)f(Crypto)l(gr)l(aphy)j(for)e(the)f(Financial)i(Servic)l(es)e (Industry)g({)g(Establishment)h(of)g(Sym-)171 704 y(metric)i(A)n (lgorithm)g(Keys)g(Using)g(Di\016e-Hel)t(lman)p Fk(,)e(W)-7 b(orking)27 b(Draft,)h(April)g(19,)e(1996.)0 867 y([BC])41 b(Ballardie,)28 b(A.)h(and)f(J.)g(Cro)n(w)n(croft,)f Fb(Multic)l(ast-sp)l(e)l(ci\014c)k(Se)l(curity)f(Thr)l(e)l(ats)h(and)g (Counterme)l(asur)l(es)p Fk(,)d(Pro)r(ceedings)171 967 y(of)23 b(1995)f(ISOC)h(Symp)r(osium)h(on)f(Net)n(w)n(orks)f(&)h (Distributed)h(Systems)g(Securit)n(y)-7 b(,)24 b(pp.)g(17-30,)e(In)n (ternet)h(So)r(ciet)n(y)-7 b(,)24 b(San)171 1067 y(Diego,)j(CA,)h(F)-7 b(ebruary)26 b(1995.)0 1230 y([Berge])40 b(Berge,)25 b(N.H.,)i Fb(UNINETT)h(PCA)g(Policy)i(Statements)p Fk(,)25 b(In)n(ternet-Draft,)h(w)n(ork)e(in)h(progress,)f(No)n(v)n(em)n(b)r (er,)h(1995.)0 1394 y([CW87])41 b(Clark,)26 b(D.D.)h(and)f(D.R.)i (Wilson,)e Fb(A)j(Comp)l(arison)h(of)g(Commer)l(cial)g(and)g(Military)g (Computer)f(Se)l(curity)g(Poli-)171 1494 y(cies)p Fk(,)f(Pro)r (ceedings)e(of)i(the)f(IEEE)g(Symp)r(osium)h(on)f(Securit)n(y)g(&)g (Priv)-5 b(acy)e(,)26 b(Oakland,)h(CA,)h(1987,)e(pp.)i(184-193.)0 1658 y([DNSSEC])42 b(D.)31 b(Eastlak)n(e)e(I)r(I)r(I,)j Fb(Domain)h(Name)g(System)f(Pr)l(oto)l(c)l(ol)i(Se)l(curity)e (Extensions)p Fk(,)f(In)n(ternet-Draft:)43 b(draft-ietf-)171 1757 y(dnssec-secext2-03.txt,)25 b(W)-7 b(ork)27 b(in)h(Progress,)c (Jan)n(uary)i(1998.)0 1921 y([DO)n(W92])41 b(Di\016e,)21 b(W.,)g(M.Wiener,)g(P)-7 b(.)19 b(V)-7 b(an)19 b(Oorsc)n(hot,)g Fb(A)n(uthentic)l(ation)i(and)h(A)n(uthentic)l(ate)l(d)g(Key)g (Exchanges)p Fk(,)f(Designs,)171 2021 y(Co)r(des,)27 b(and)g(Cryptograph)n(y)-7 b(,)26 b(2,)h(107-125,)d(Klu)n(w)n(er)j (Academic)g(Publishers,)g(1992.)0 2184 y([IAB])42 b(Bello)n(vin,)e(S.,) i Fb(R)l(ep)l(ort)e(of)g(the)h(IAB)f(Se)l(curity)f(A)n(r)l(chite)l (ctur)l(e)g(Workshop)p Fk(,)44 b(In)n(ternet-Draft:)58 b(draft-iab-secwks-)171 2284 y(rep)r(ort-00.txt,)26 b(W)-7 b(ork)27 b(in)g(Progress,)e(No)n(v)n(em)n(b)r(er)h(1997.)0 2448 y([IKE])41 b(Harkins,)22 b(D.)g(and)g(D.)h(Carrel,)f Fb(The)j(Internet)e(Key)i(Exchange)h(\(IKE\))p Fk(,)c(In)n (ternet-Draft:)34 b(draft-ietf-ipsec-isakmp-)171 2547 y(oakley-06.txt,)25 b(W)-7 b(ork)27 b(in)h(Progress,)d(F)-7 b(ebruary)26 b(1998.)0 2711 y([IPDOI])41 b(Derrell)d(Pip)r(er,)i Fb(The)g(Internet)e(IP)i(Se)l(curity)f(Domain)h(of)g(Interpr)l(etation) f(for)h(ISAKMP)p Fk(,)e(In)n(ternet-Draft:)171 2811 y (draft-ietf-ipsec-ipsec-doi-07.txt,)25 b(W)-7 b(ork)27 b(in)h(Progress,)c(F)-7 b(ebruary)27 b(1998.)0 2974 y([Karn])40 b(Karn,)46 b(P)-7 b(.)43 b(and)h(B.)f(Simpson,)k Fb(Photuris:)68 b(Session)45 b(Key)f(Management)h(Pr)l(oto)l(c)l(ol)p Fk(,)k(In)n(ternet-Draft:)68 b(draft-)171 3074 y (simpson-photuris-15.txt,)25 b(W)-7 b(ork)27 b(in)h(Progress,)d(July)i (1997.)0 3238 y([Ken)n(t94])40 b(Stev)n(e)28 b(Ken)n(t,)f Fb(IPSEC)j(SMIB)p Fk(,)f(e-mail)e(to)g(ipsec@ans.net,)g(August)h(10,)e (1994.)0 3401 y([Oakley])40 b(H.)h(K.)e(Orman,)j Fb(The)g(Oakley)g(Key) f(Determination)h(Pr)l(oto)l(c)l(ol)p Fk(,)h(In)n(ternet-Draft:)62 b(draft-ietf-ipsec-oakley-)171 3501 y(02.txt,)27 b(W)-7 b(ork)27 b(in)h(Progress,)c(July)k(1997.)0 3665 y([RF)n(C-1422])39 b(Stev)n(e)28 b(Ken)n(t,)g Fb(Privacy)k(Enhanc)l(ement)e(for)h (Internet)e(Ele)l(ctr)l(onic)i(Mail:)40 b(Part)31 b(II:)f(Certi\014c)l (ate-Base)l(d)i(Key)171 3764 y(Management)p Fk(,)c(RF)n(C-1422,)e(F)-7 b(ebruary)26 b(1993.)0 3928 y([RF)n(C-1825])39 b(Randall)27 b(A)n(tkinson,)h Fb(Se)l(curity)h(A)n(r)l(chite)l(ctur)l(e)g(for)i(the) f(Internet)e(Pr)l(oto)l(c)l(ol)p Fk(,)h(RF)n(C-1825,)c(August,)j(1995.) 0 4092 y([RF)n(C-1949])39 b(A.)28 b(Ballardie,)f Fb(Sc)l(alable)k (Multic)l(ast)e(Key)i(Distribution)p Fk(,)c(RF)n(C-1949,)f(Ma)n(y)h (1996.)0 4256 y([RF)n(C-2093])39 b(Harney)-7 b(,)53 b(H.)48 b(and)g(C.)g(Muc)n(k)n(enhirn,)k Fb(Gr)l(oup)d(Key)g(Management)g(Pr)l (oto)l(c)l(ol)g(\(GKMP\))g(Sp)l(e)l(ci\014c)l(ation)p Fk(,)171 4355 y(SP)-7 b(AR)g(T)g(A,)28 b(Inc.,)g(RF)n(C-2093,)d(July)i (1997.)0 4519 y([RF)n(C-2094])39 b(Harney)-7 b(,)54 b(H.)49 b(and)g(C.)g(Muc)n(k)n(enhirn,)54 b Fb(Gr)l(oup)c(Key)f(Management)h (Pr)l(oto)l(c)l(ol)h(\(GKMP\))f(A)n(r)l(chite)l(ctur)l(e)p Fk(,)171 4619 y(SP)-7 b(AR)g(T)g(A,)28 b(Inc.,)g(RF)n(C-2094,)d(July)i (1997.)0 4782 y([RF)n(C-2119])39 b(S.)34 b(Bradner,)g Fb(Key)i(Wor)l(ds)f(for)i(use)e(in)g(RF)n(Cs)g(to)h(Indic)l(ate)g(R)l (e)l(quir)l(ement)e(L)l(evels)p Fk(,)h(Harv)-5 b(ard)33 b(Univ)n(ersit)n(y)-7 b(,)171 4882 y(RF)n(C-2119,)25 b(Marc)n(h)i(1997.)0 5046 y([Sc)n(hneier])41 b(Bruce)36 b(Sc)n(hneier,)j Fb(Applie)l(d)h(Crypto)l(gr)l(aphy)h(-)d(Pr)l(oto)l(c) l(ols,)k(A)n(lgorithms,)g(and)d(Sour)l(c)l(e)f(Co)l(de)i(in)e(C)h(\(Se) l(c)l(ond)171 5145 y(Edition\))p Fk(,)29 b(John)e(Wiley)h(&)f(Sons,)g (Inc.,)h(1996.)0 5309 y([STD-2])41 b(Reynolds,)27 b(J.)h(and)f(J.)h(P)n (ostel,)e Fb(Assigne)l(d)k(Numb)l(ers)p Fk(,)d(STD)h(2,)g(Octob)r(er,)e (1994.)0 5656 y(Maughan,)h(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b(draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(65])p eop %%Page: 66 66 66 65 bop 0 100 a Fk(INTERNET-DRAFT)1128 b(ISAKMP)1101 b(Marc)n(h)26 b(10,)h(1998)0 390 y Ff(Addresses)47 b(of)e(Authors)0 572 y Fk(The)28 b(authors)e(can)h(b)r(e)h(con)n(tacted)f(at:)300 771 y(Douglas)g(Maughan)480 871 y(Phone:)36 b(301-688-0847)480 971 y(E-mail:)f Fg(wdm@tycho.ncsc.m)o(il)300 1170 y Fk(Mark)27 b(Sc)n(hneider)480 1269 y(Phone:)36 b(301-688-0851)480 1369 y(E-mail:)f Fg(mss@tycho.ncsc.m)o(il)480 1568 y Fk(National)27 b(Securit)n(y)g(Agency)480 1668 y(A)-7 b(TTN:)28 b(R23)480 1768 y(9800)e(Sa)n(v)-5 b(age)26 b(Road)480 1867 y(Ft.)37 b(Meade,)28 b(MD.)g(20755-6000)300 2066 y(Mark)f(Sc)n(hertler)480 2166 y(T)-7 b(erisa)26 b(Systems,)i(Inc.)480 2266 y(4984)e(El)h(Camino)g(Real)480 2365 y(Los)g(Altos,)g(CA.)h(94022)480 2465 y(Phone:)36 b(650-919-1773)480 2565 y(E-mail:)f Fg(mjs@terisa.com)300 2764 y Fk(Je\013)28 b(T)-7 b(urner)480 2863 y(RABA)28 b(T)-7 b(ec)n(hnologies,)26 b(Inc.)480 2963 y(10500)f(Little)j(P)n (atuxen)n(t)f(P)n(arkw)n(a)n(y)480 3063 y(Colum)n(bia,)g(MD.)h(21044) 480 3162 y(Phone:)36 b(410-715-9399)480 3262 y(E-mail:)f Fg(jeff.turner@raba)o(.co)o(m)0 5656 y Fk(Maughan,)27 b(Sc)n(hertler,)f(Sc)n(hneider,)i(T)-7 b(urner)477 b (draft-ietf-ipsec-isakmp-09.txt,)25 b(.ps)478 b([P)n(age)26 b(66])p eop %%Trailer end userdict /end-hook known{end-hook}if %%EOF From owner-ipsec Fri Mar 13 09:42:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09368 for ipsec-outgoing; Fri, 13 Mar 1998 09:42:48 -0500 (EST) Date: Tue, 10 Mar 1998 18:14:26 -0600 From: Bezalel Gavish Subject: Fwd: First International Conference on Telecommunications and To: Bezalel Gavish Message-id: <01IUIE6OVR189G8P1N@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: multipart/mixed; boundary="=====================_889596866==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_889596866==_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Subject: First International Conference on Telecommunications and Electronic
Commerce

Dear colleagues,

The First International Conference on Telecommunication and Electronic Commerce will be held in Novemebr 1998, in Nashville, Tennessee. I hope you can contribute to the conference. Feel free to transfer this message to other persons who might be interested in the topic.

Sincerely yours,
Bezalel Gavish
----------------------------------------------------------------------------= --------------
Bezalel Gavish
Owen Graduate School of Management
Vanderbilt University
Nashville, TN 37220

Tel: Office (615) 322-3659=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX (615)= 343-7177
=A0=A0=A0=A0=A0=A0=A0=A0 Home (615) 370-0813

Email: Gavishb@ctral1.vanderbilt.edu

--=====================_889596866==_ Content-Type: application/msword; name="ICTEC98cfp14.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ICTEC98cfp14.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANwAAAAAAAAAA EAAAOQAAAAEAAAD+////AAAAADYAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARwAJBAAAABK/AAAAAAAAEAAAAAAABAAA3BsAAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAA AAAJBBYA6zoAAOyzAQDsswEAtBcAAAAAAAAnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAACwBAAAAAAAALAEAACwB AAAAAAAALAEAAAAAAAAsAQAAAAAAACwBAAAAAAAALAEAAFQAAAAAAAAAAAAAAIABAAAAAAAAgAEA AAAAAACAAQAAAAAAAIABAACYAAAAGAIAAAwAAAAkAgAAJAAAAIABAAAAAAAAnwsAADIBAABcAgAA AAAAAFwCAAAAAAAAXAIAAAAAAABcAgAAAAAAAFwCAAAAAAAAXAIAAAAAAABcAgAAAAAAAFwCAAAA AAAAZAsAAAIAAABmCwAAAAAAAGYLAAAAAAAAZgsAAAAAAABmCwAAAAAAAGYLAAAAAAAAZgsAACQA AADRDAAA9AEAAMUOAACIAAAAigsAABUAAAAAAAAAAAAAAAAAAAAAAAAALAEAAAAAAABcAgAAAAAA AAAAAAAAAAAAAAAAAAAAAABcAgAAAAAAAFwCAAAAAAAAXAIAAAAAAABcAgAAAAAAAIoLAAAAAAAA cAUAAAAAAAAsAQAAAAAAACwBAAAAAAAAXAIAAAAAAAAAAAAAAAAAAFwCAAAAAAAAXAIAAAAAAABw BQAAAAAAAHAFAAAAAAAAcAUAAAAAAABcAgAAngIAACwBAAAAAAAAXAIAAAAAAAAsAQAAAAAAAFwC AAAAAAAAZAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAAAAAACAAQAAAAAAACwBAAAAAAAALAEA AAAAAAAsAQAAAAAAACwBAAAAAAAAXAIAAAAAAABkCwAAAAAAAHAFAAA0BAAAcAUAAAAAAACkCQAA cgAAAAILAABUAAAALAEAAAAAAAAsAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAsAAAAAAABcAgAAAAAAAEgCAAAUAAAAcPq3qZxL vQGAAQAAAAAAAIABAAAAAAAA+gQAAHYAAABWCwAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ2Fs bCBmb3IgUGFwZXJzDUZpcnN0IEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBUZWxlY29tbXVu aWNhdGlvbnMgYW5kIEVsZWN0cm9uaWMgQ29tbWVyY2UgKElDVEVDKQ1OYXNodmlsbGUsIFVTQQ1O b3ZlbWJlciAxOS0yMiwgMTk5OA1odHRwOi8vY290dG9uaWFuLm9nc20udmFuZGVyYmlsdC5lZHUv SUNURUMvDQ1TcG9uc29yZWQgYnkNVmFuZGVyYmlsdCBVbml2ZXJzaXR5IEluc3RpdHV0ZSBmb3Ig UHVibGljIFBvbGljeSBTdHVkaWVzIChWSVBQUykNQmVsbFNvdXRoDU1hZ25ldGVrDUlORk9STVMg Q29sbGVnZXMgb24gSW5mb3JtYXRpb24gU3lzdGVtcyBhbmQgVGVsZWNvbW11bmljYXRpb25zLCBJ RklQIFdHIDcuMywgQVRTTUENDU92ZXIgdGhlIHBhc3QgZmV3IHllYXJzLCBlbGVjdHJvbmljIGNv bW1lcmNlIChFQykgaGFzIGVtZXJnZWQgYXMgYSBkcmFtYXRpYyBuZXcgbW9kZSBvZiBidXNpbmVz cy4gVG9kYXksIGFsbW9zdCBldmVyeSBjb21wYW55IGlzIGVpdGhlciB1c2luZyBvciBjb25zaWRl cmluZyBFQy4gQWR2YW5jZXMgaW4gdGVsZWNvbW11bmljYXRpb25zIGFuZCBhdXRvbWF0ZWQgcHJv Y2Vzc2VzIGFyZSBhbHJlYWR5IGZvcmNpbmcgZHJhbWF0aWMgY2hhbmdlcyBpbiBhIHZhcmlldHkg b2YgaW5kdXN0cmllcywgcmFuZ2luZyBmcm9tIGJhbmtpbmcgYW5kIGZpbmFuY2UgdG8gbXVzaWMg YW5kIGVudGVydGFpbm1lbnQuIFlldCwgdGhlIFRFQyBlbnZpcm9ubWVudCBpcyBzdGlsbCBpbiBh IHJlbGF0aXZlbHkgZWFybHkgc3RhdGUgb2YgZXZvbHV0aW9uLiBUaGUgcmFwaWQgZGV2ZWxvcG1l bnQgb2YgdGhlIGZpZWxkIGhhcyBhbHNvIHJlc3VsdGVkIGluIHR3byBwaGVub21lbmEuIEZpcnN0 LCBtYW55IG9mIHRoZSBzaWduaWZpY2FudCBhZHZhbmNlcyBpbiB1bmRlcnN0YW5kaW5nIGFuZCBp bXBsZW1lbnRpbmcgRUMgYXJlIG9jY3VycmluZyBjb25jdXJyZW50bHkgaW4gYWNhZGVtaWEgYW5k IGluZHVzdHJ5LiBUaGUgdHJhZGl0aW9uYWwgc2VxdWVudGlhbCBwcm9jZXNzIG9mIHRlY2hub2xv Z3kgaW5ub3ZhdGlvbiBmb2xsb3dlZCBieSB0ZWNobm9sb2d5IHRyYW5zZmVyIG5vIGxvbmdlciBh cHBsaWVzLiBUaHVzLCBpdCBpcyBpbmNyZWFzaW5nbHkgaW1wb3J0YW50IGZvciBkaWFsb2d1ZSBv biB0aGlzIGZpZWxkIGJldHdlZW4gYWNhZGVtaWEgYW5kIGluZHVzdHJ5IHRvIGJlIGZvc3RlcmVk LiAgU2Vjb25kLCBzdHVkeSBvZiBFQyBkb2VzIG5vdCBjb25mb3JtIHRvIHRyYWRpdGlvbmFsIGFj YWRlbWljIGRpc2NpcGxpbmVzLCBhbmQgc3BhbnMgYSB3aWRlIHJhbmdlIG9mIHJlZmVyZW5jZSBk aXNjaXBsaW5lcy4gVGh1cywgbmV3IGZvcnVtcyBmb2N1c2luZyBvbiBFQyBhcmUgbmVjZXNzYXJ5 IHRvIHN0aW11bGF0ZSB0aGUgbmVjZXNzYXJ5IGludGVyYWN0aW9ucyBhbmQga25vd2xlZGdlIHNo YXJpbmcuIEZ1cnRoZXJtb3JlLCB0aGUgcm9sZSBvZiB0ZWxlY29tbXVuaWNhdGlvbnMgbmV0d29y a3MgaXMgY2VudHJhbCB0byBFQywgYW5kIGFkdmFuY2VzIGluIHRlbGVjb21tdW5pY2F0aW9ucyB0 ZWNobm9sb2dpZXMgYXJlIGEgZnVuZGFtZW50YWwgZm9yY2UgaW4gc2hhcGluZyBFQy4gVGh1cywg ZGlhbG9ndWUgYmV0d2VlbiB0ZWxlY29tbXVuaWNhdGlvbnMgcmVzZWFyY2hlcnMgYW5kIEVDIHJl c2VhcmNoZXJzIGlzIGVzc2VudGlhbC4gDQ1JQ1RFQyBpcyBpbnRlbmRlZCB0byBhZGRyZXNzIHRo ZXNlIG5lZWRzLiBUaGUgZ29hbCBvZiB0aGUgY29uZmVyZW5jZSBpcyB0byBicmluZyB0b2dldGhl ciBib3RoIGFjYWRlbWljIGFuZCBpbmR1c3RyaWFsIHJlc2VhcmNoZXJzIGluIHRoZSBmaWVsZHMg b2YgdGVsZWNvbW11bmljYXRpb25zIGFuZCBFQyBvbiBhbiBvbmdvaW5nLCBhbm51YWwgYmFzaXMs IHRvIGRpc2N1c3MgbmV3IHRlY2hub2xvZ2ljYWwgZGV2ZWxvcG1lbnRzIGFuZCB0aGVpciBpbXBs aWNhdGlvbnMgZm9yIEVDLCBhcyB3ZWxsIGFzIHRlY2hub2xvZ2ljYWwgaXNzdWVzIHRoYXQgbmVl ZCB0byBiZSBhZGRyZXNzZWQgdG8gZnVydGhlciB0aGUgZWZmZWN0aXZlbmVzcyBhbmQgZWZmaWNp ZW5jeSBvZiBFQy4gVGhlIGNvbmZlcmVuY2Ugd2lsbCBjb21iaW5lIHJlc2VhcmNoIHRyYWNrcyBp biB3aGljaCB0ZWNobmljYWwgcGFwZXJzIHdpbGwgYmUgcHJlc2VudGVkLCB3aXRoIGluZHVzdHJp YWwgdHJhY2tzIGNvbnNpc3Rpbmcgb2YgcGFuZWxzLCBwbGVuYXJ5IHNwZWFrZXJzIGFuZCBleGhp Yml0cy4gDQ1Ub3BpY3Mgb2YgaW50ZXJlc3QgZm9yIHRoZSBjb25mZXJlbmNlIGluY2x1ZGUgKGJ1 dCBhcmUgbm90IGxpbWl0ZWQgdG8pIHRoZSBmb2xsb3dpbmc6DQ0MSW1wYWN0IG9mIEVDIG9uIHN1 cHBseSBjaGFpbiwgZGlzdHJpYnV0aW9uIGNoYWluIG1hbmFnZW1lbnQsIEVESSBhbmQgSU9TDVNl Y3VyZSB0cmFuc2FjdGlvbiBwcm9jZXNzaW5nIG1ldGhvZHMgZm9yIGVsZWN0cm9uaWMgY29tbWVy Y2UgDURlc2lnbiBhbmQgYW5hbHlzaXMgb2YgbXVsdGltZWRpYSBhcHBsaWNhdGlvbnMgb24gdGhl IEludGVybmV0IA1UaGUgaW1wYWN0IG9mIG1vYmlsaXR5IG9uIEVDIG1lY2hhbmlzbXMgDUludGVy bmV0IHRyYWZmaWMgbWFuYWdlbWVudCBhbmQgYW5hbHlzaXMgDVByaWNpbmcgSW50ZXJuZXQgc2Vy dmljZXMgDUVDIG1hcmtldCBtZWNoYW5pc21zIGFuZCBidXNpbmVzcyBtb2RlbHMgDUVDIGludGVy bWVkaWFyeSByb2xlcyBhbmQgdGhlaXIgYW5hbHlzaXMNRWxlY3Ryb25pYyBwYXltZW50IG1lY2hh bmlzbXMNRWNvbm9taWMgYW5hbHlzaXMgb2YgaW50cmFuZXRzIGFuZCBleHRyYW5ldHMNRGVzaWdu IGFuZCBhbmFseXNpcyBvZiBpbnRyYW5ldHMgDURhdGEgbWFuYWdlbWVudCBpc3N1ZXMgaW4gRUMN TWFuYWdpbmcgcmVzcG9uc2UgdGltZSBhbmQgY29udGVudCBpbiBXZWItYmFzZWQgaW5mb3JtYXRp b24gc2VydmljZXMgDUVmZmVjdGl2ZSBtYW5hZ2VtZW50IG9mIGVsZWN0cm9uaWMgY29tbWVyY2Ug dHJhbnNhY3Rpb24gc2VydmVycyANRUMgZGV2ZWxvcG1lbnRzIGFuZCBjaGFsbGVuZ2VzIGluIHNw ZWNpZmljIGluZHVzdHJpZXMgKGUuZy4sIGZpbmFuY2lhbCBzZXJ2aWNlcywgbXVzaWMsIG1hbnVm YWN0dXJpbmcsIHRvdXJpc20sIHB1Ymxpc2hpbmcpDUdsb2JhbGl6YXRpb24gaXNzdWVzIGluIEVD IChzdGFuZGFyZHMsIHJlZ3VsYXRpb24sIHByb3BlcnR5IHJpZ2h0cywgZXRjLikNDCANDEF1dGhv cnMgc2hvdWxkIHN1Ym1pdCBhbiBleHRlbmRlZCBhYnN0cmFjdCBvZiBhdCBsZWFzdCAyMDAwIHdv cmRzLCBvciBhIGNvbXBsZXRlIHBhcGVyLCB0byB0aGUgUHJvZ3JhbSBDb21taXR0ZWUgQ2hhaXIg YnkgTWF5IDE1LCAxOTk4LiBUaHJlZSBoYXJkLWNvcGllcyBzaG91bGQgYmUgc3VibWl0dGVkLiBF bGVjdHJvbmljIHN1Ym1pc3Npb25zIGFyZSB3ZWxjb21lLCBidXQgbXVzdCBiZSBhdWdtZW50ZWQg d2l0aCBhdCBsZWFzdCBvbmUgaGFyZC1jb3B5LiAgQXV0aG9ycyBvZiBhY2NlcHRlZCBwYXBlcnMg d2lsbCBiZSBhc2tlZCB0byBzdWJtaXQgdGhlaXIgY29tcGxldGUgbWFudXNjcmlwdHMgdG8gdGhl IFByb2dyYW0gQ2hhaXIsIGJ5IFNlcHRlbWJlciAxNSwgMTk5OC4gQWNjZXB0ZWQgcGFwZXJzIHRo YXQgYXJlIHByZXNlbnRlZCBhdCB0aGUgY29uZmVyZW5jZSB3aWxsIGJlIGluY2x1ZGVkIGluIHRo ZSBDb25mZXJlbmNlIFByb2NlZWRpbmdzLiBGb3JtYXR0aW5nIGluc3RydWN0aW9ucyBmb3IgYWNj ZXB0ZWQgcGFwZXJzIHdpbGwgYmUgc2VudCB3aXRoIHRoZSBhY2NlcHRhbmNlIG5vdGljZS4gQSBz ZWxlY3Qgc2V0IG9mIHBhcGVycyB3aWxsIGJlIGNvbnNpZGVyZWQgZm9yIHB1YmxpY2F0aW9uIGlu IHJlbGF0ZWQgam91cm5hbHMsIHN1Y2ggYXMgVGVsZWNvbW11bmljYXRpb24gU3lzdGVtcy4NDVBy b3Bvc2FscyBmb3IgcGFuZWxzIGFyZSBhbHNvIGludml0ZWQuIEJvdGggYWNhZGVtaWMgYW5kIGlu ZHVzdHJ5IHBhbmVscyBhcmUgZW5jb3VyYWdlZC4gRWFjaCBwcm9wb3NhbCBzaG91bGQgaW5jbHVk ZSBhIGxpc3Qgb2YgcGFuZWxpc3RzIHdpdGggdGhlaXIgYWZmaWxpYXRpb25zLiBBIGJyaWVmIHN0 YXRlbWVudCBleHBsYWluaW5nIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUgZGVzaWduIGFuZCBjb21w b3NpdGlvbiBvZiB0aGUgcGFuZWwgc2hvdWxkIGFsc28gYmUgaW5jbHVkZWQuIFRoZSBkZWFkbGlu ZSBmb3IgcHJvcG9zYWwgc3VibWlzc2lvbiB0byB0aGUgcHJvZ3JhbSBjaGFpciBpcyBNYXkgMTUs IDE5OTguICANDUFkZHJlc3MgZm9yIFN1Ym1pc3Npb25zOiBQcm9mZXNzb3IgQW1pdCBCYXN1LCBP d2VuIEdyYWR1YXRlIFNjaG9vbCBvZiBNYW5hZ2VtZW50LCBWYW5kZXJiaWx0IFVuaXZlcnNpdHks IE5hc2h2aWxsZSwgVE4gMzcyMDMsIFVTQS4gDVRFTDogKyg2MTUpIDMyMi03MDQzOyBGQVg6ICso NjE1KSAzNDMtNzE3NzsgRU1BSUw6IEFtaXQuQmFzdUBvd2VuLnZhbmRlcmJpbHQuZWR1DQ1Db25m ZXJlbmNlIEdlbmVyYWwgQ2hhaXI6IEJlemFsZWwgR2F2aXNoLCBWYW5kZXJiaWx0IFVuaXZlcnNp dHksIE5hc2h2aWxsZSwgVVNBLiANDVByb2dyYW0gQ29tbWl0dGVlDQ0MS2VtYWwgQWx0aW5rZW1l ciwgUHVyZHVlIFVuaXYuLCBVU0ENTWljaGFlbCBCYWxsLCBVbml2LiBvZiBNYXJ5bGFuZCwgVVNB DUFtaXQgQmFzdSwgVmFuZGVyYmlsdCBVbml2LiwgVVNBIChDaGFpcikNUm9iZXJ0IEJsYW5uaW5n LCBWYW5kZXJiaWx0IFVuaXYuLCBVU0ENTWljaGFlbCBDYXJ0ZXIsIENhbnRlcmJ1cnksIE5ldyBa ZWFsYW5kKg1ILiBNaWNoYWVsIENodW5nLCBDYWxpZm9ybmlhIFN0YXRlIFVuaXYuLCBVU0ENTGF3 cmVuY2UgRG93ZHksIFZhbmRlcmJpbHQgVW5pdi4sIFVTQQ1BbWl0YXZhIER1dHRhLCBHZW9yZ2Ug TWFzb24gVW5pdi4sIFVTQQ1Ub255IEV5ZXJzLCBVbml2LiBvZiBXb29sYWdvbmcsIEF1c3RyYWxp YQ1Vc2FtYSBGYXl5YWQsIE1pY3Jvc29mdCBDb3JwLiwgVVNBDVN0dWFydCBGZWxkbWFuLCBJQk0g Q29ycC4sIFVTQSANU2lnbXVuZCBIYW5kZWxtYW4sIElCTSBDb3JwLiwgVVNBDUVyaWMgdmFuIEhl Y2ssIEVyYXNtdXMgVW5pdi4sIE5ldGhlcmxhbmRzDVJhdmkgS2FsYWtvdGEsIEdlb3JnaWEgU3Rh dGUgVW5pdi4sIFVTQQ1Kb2FraW0gS2FsdmVuZXMsIFVuaXYuIG9mIFRleGFzLCBEYWxsYXMsIFVT QQ1Baml0IEthbWJpbCwgTmV3IFlvcmsgVW5pdi4sIFVTQQ1LYWxldmkgS2lsa2tpLCBOb2tpYSBD b3JwLiwgRmlubGFuZCANTm9yaWhpc2EgS29tb2RhLCBPc2FrYSBVbml2LiwgSmFwYW4NUmFtYXl5 YSBLcmlzaG5hbiwgQ2FybmVnaWUgTWVsbG9uIFVuaXYuLCBVU0ENQWtoaWwgS3VtYXIsIFVuaXYu IG9mIENvbG9yYWRvLCBVU0ENUm9uYWxkIExlZSwgRXJhc211cyBVbml2LiwgTmV0aGVybGFuZHMq DUpvaG4gRC4gQy4gTGl0dGxlLCBNSVQsIFVTQQ1BbGJlcnRvIE1lbmRlbHpvbiwgVW5pdi4gb2Yg VG9yb250bywgQ2FuYWRhDUp1emFyIE1vdGl3YWxsYSwgTmF0aW9uYWwgVW5pdi4gb2YgU2luZ2Fw b3JlDUp1bmUgUGFyaywgVW5pdi4gb2YgSW93YSwgVVNBDUNoYXJsZXMgUGVya2lucywgU3VuIE1p Y3Jvc3lzdGVtcywgVVNBDUhhc2FuIFBpcmt1bCwgVW5pdi4gb2YgVGV4YXMsIERhbGxhcywgVVNB DUtvdGFnaXJpIFJhbWFtb2hhbmFyYW8sIFVuaXYuIG9mIE1lbGJvdXJuZSwgQXVzdHJhbGlhDUxv dWlxYSBSYXNjaGlkLCBVbml2LiBvZiBNYXJ5bGFuZCwgVVNBDUFyaWUgU2VnZXYsIFVDIEJlcmtl bGV5LCBVU0ENT2xpdmlhIFNoZW5nLCBVbml2LiBvZiBBcml6b25hLCBVU0ENQW5kcmV3IFdoaW5z dG9uLCBVbml2LiBvZiBUZXhhcywgQXVzdGluLCBVU0ENTGVvbiBaaGFvLCBVbml2LiBvZiBTY2ll bmNlICYgVGVjaC4sIEhvbmcgS29uZw0MDQ0NSW1wb3J0YW50IERhdGVzOg1QYXBlciAob3IgRXh0 ZW5kZWQgQWJzdHJhY3QpIFN1Ym1pc3Npb24gRGVhZGxpbmU6CU1heSAxNSwgMTk5OA1QYW5lbCBQ cm9wb3NhbCBTdWJtaXNzaW9uIERlYWRsaW5lOiBNYXkgMTUsIDE5OTgNRmluYWwgUGFwZXIgU3Vi bWlzc2lvbiBEZWFkbGluZTogU2VwdGVtYmVyIDE1LCAxOTk4DUNvbmZlcmVuY2UgRGF0ZXM6IE5v dmVtYmVyIDE5LTIyLCAxOTk4CQkJCQ0NDSogdGVudGF0aXZlLCBhd2FpdGluZyBjb25maXJtYXRp b24NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAQBAAAMQQAADIEAABdBAAAZAQA AGUEAAB0BAAAiQQAALYEAADDBAAABAUAAAUFAABrBQAAEg0AAHIQAAB2EAAA8BAAAPwQAADkEQAA 9hEAAHYUAACCFAAAhhQAAIcUAACfFAAAXRUAAHUVAACwFQAAwhUAAMQVAABOFwAAbBcAAG4XAADQ GgAA0xoAANQaAADlGgAAtBsAALUbAAC2GwAA2RsAANsbAADcGwAA9+/n7+Dv99nU2ffO99TZ1Me/ x7/Hv8fZ99n32bXU2bEA2dTZtdnHAMcA2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdoCABuSAkEEjUI gT4qAUNKGABPSgAAUUoAAAAPNQiBQ0oWAE9KAABRSgAADENKFgBPSgAAUUoAAAALNQiBT0oAAFFK AAAIT0oAAFFKAAAADENKGABPSgAAUUoAAAAMQ0okAE9KAABRSgAAAA81CIFDSjAAT0oAAFFKAAAP NQiBQ0osAE9KAABRSgAADzUIgUNKGABPSgAAUUoAAAArAAQAABAEAABlBAAAdAQAAIkEAAC1BAAA tgQAAMMEAAAFBQAADwUAABgFAABrBQAAbAUAAJEKAACSCgAAuQwAALoMAAAQDQAAEQ0AABINAABb DQAAmg0AANoNAAADDgAALQ4AAEgOAAByDgAAmw4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADsAAAAAAAA AAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAA AOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAUPAAomAAtG AwAFDwADJAMPhAAAAAMPAA+EAAAFDwADJAEPhAAAABsABAAAEAQAAGUEAAB0BAAAiQQAALUEAAC2 BAAAwwQAAAUFAAAPBQAAGAUAAGsFAABsBQAAkQoAAJIKAAC5DAAAugwAABANAAARDQAAEg0AAFsN AACaDQAA2g0AAAMOAAAtDgAASA4AAHIOAACbDgAAuQ4AAOYOAAAIDwAAJQ8AAGsPAACsDwAAKBAA AHIQAABzEAAAdRAAACQTAAAlEwAAhhQAAIcUAAALFQAAXBUAAF0VAACvFQAAsBUAAMIVAADDFQAA xBUAAOgVAAANFgAANhYAAF0WAACGFgAAtBYAAP39/f39/f39/f39/f39/f39/fr17ufg2dLLxL22 r6ihmpOM+v39/f39/f39/f39/fr9/f39/f0ADQIPAAgDAAkBCg8AAAANAg8ACAMACQEKDgAAAA0C DwAIAwAJAQoNAAAADQIPAAgDAAkBCgwAAAANAg8ACAMACQEKCwAAAA0CDwAIAwAJAQoKAAAADQIP AAgDAAkBCgkAAAANAg8ACAMACQEKCAAAAA0CDwAIAwAJAQoHAAAADQIPAAgDAAkBCgYAAAANAg8A CAMACQEKBQAAAA0CDwAIAwAJAQoEAAAADQIPAAgDAAkBCgMAAAANAg8ACAMACQEKAgAAAA0CDwAI AwAJAQoBAAAACAIPAAgDAAkBAAUCDwAJAwMCDwAAN5sOAAC5DgAA5g4AAAgPAAAlDwAAaw8AAKwP AAAoEAAAchAAAHMQAAB1EAAAJBMAACUTAACGFAAAhxQAAAsVAABcFQAAXRUAAK8VAACwFQAAwhUA AMMVAADEFQAA6BUAAA0WAAA2FgAAXRYAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAA AAAAAAAAAADiAAAAAAAAAAAAAAAAAAAAAAAAAAkPAA+EAAARhEz/DcYFAAG0AAAFDwADJAEPhAAA BQ8AAyQDD4QAAAADDwAPhAAABQ8ACiYAC0YDAAAaXRYAAIYWAAC0FgAA2hYAAAEXAAArFwAAThcA AG4XAACQFwAAuhcAAOIXAAAPGAAAMBgAAFUYAAB5GAAAphgAAMoYAADyGAAADhkAADoZAABnGQAA hRkAAKwZAADWGQAADBoAADMaAABQGgAAdBoAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAAACwAAD4QAABGETP8NxggA ArQA0AIAAAAJDwAPhAAAEYRM/w3GBQABtAAAABu0FgAA2hYAAAEXAAArFwAAThcAAG4XAACQFwAA uhcAAOIXAAAPGAAAMBgAAFUYAAB5GAAAphgAAMoYAADyGAAADhkAADoZAABnGQAAhRkAAKwZAADW GQAADBoAADMaAABQGgAAdBoAAKEaAADQGgAA0RoAANIaAADTGgAA1BoAAOUaAAAkGwAAVRsAAIkb AAC0GwAAtRsAALYbAADZGwAA2hsAANsbAADcGwAA/f39/QD9/f39/f39/f39/f39/f39/f39/f39 +v39/f39/f39+Pbz9vj9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAFAg8ADQECDQEAAgEBAAUCDwAJAwMCDwAAKnQaAAChGgAA0BoAANEaAADSGgAA0xoAANQaAADl GgAAJBsAAFUbAACJGwAAtBsAALUbAAC2GwAA2RsAANobAADbGwAA3BsAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6wAAAAAA AAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAMPAA+EAAAABQ8AD4QA ABGE0AIACQ8AD4QAABGETP8NxgUAAbQAAAARIAAmUAEAH7DQLyCw4D0hsBAFIrAQBSOQoAUkkIAE JbAAADkACTAAJlABAB+w0C8gsOA9IbAQBSKwEAUjkKAFJJCABCWwAAALUAEABTAAA/IAcBEE8gDQ AgPyAXARJgAJMAAKMAEmUAEAH7DQLyCw4D0hsBAFIrAQBSOQoAUkkIAEJbAAADwACTAACjABJlAB AB+w0C8gsOA9IbAQBSKwEAUjkKAFJJCABCWwAAALUAEABTAAA/IAyhEE8gAcAgPyAcoRJgAJMAAK MAEmUAEAH7DQLyCw4D0hsBAFIrAQBSOQoAUkkIAEJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABIACgABAFsADwACAAAAAAAAACwAAEDx/wIALAAA AAYATgBvAHIAbQBhAGwAAAAGAAAAD4Q4BAgAQ0oYAG1ICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA 8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAA AAAAAAAAAAAANABaQAEA8gA0AAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAPAAwAQ0oUAE9K AwBRSgMALAAfQAEAAgEsAAAABgBIAGUAYQBkAGUAcgAAAA0AEAANxggAAuAQwCEBAgAAACwAIEAB ABIBLAAAAAYARgBvAG8AdABlAHIAAAANABEADcYIAALgEMAhAQIAAAAAAAAAEgkAAHMMAADEEQAA 0RYAANwXAAAHAAA6AAAAAP////8HACI6AAAAAP////8HAF06AAAAAP////8HAIU6AAAAAP////8H AMM6AAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAIA AAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAJgAAACYAAAAmAAAAJgAA ACYAAAAmAAAAJgAAACYAAAAmAAAAJgAAACYAAAAmAAAAJgAAACYAAAAmAAAAKQAAAAAEAADcGwAA FgAAAAAEAACbDgAAXRYAAHQaAADcGwAAFwAAABkAAAAaAAAAHAAAAAAEAAC0FgAA3BsAABgAAAAb AAAAAAAAAAUBAAAOAQAAzgoAANcKAADcCgAA5QoAAP0KAAAGCwAAdxEAAH4RAADEEQAAyREAAMoR AADUEQAA1hEAANwRAACREgAAlhIAANoSAADhEgAA4hIAAOcSAAAGEwAACxMAABYTAAAfEwAAKxMA ADATAAAxEwAANxMAAFUTAABcEwAAbhMAAHUTAAB2EwAAfxMAAJ8TAACmEwAAuhMAAL4TAAC/EwAA xxMAAOITAADoEwAA6RMAAPETAAAPFAAAExQAABQUAAAaFAAAMBQAADYUAAA3FAAAPRQAAD8UAABE FAAAVRQAAF0UAABeFAAAZBQAAHkUAACAFAAAgRQAAIkUAACLFAAAkxQAAJQUAACaFAAAphQAAKsU AACsFAAAsRQAANYUAADdFAAADhUAABUVAAAWFQAAHxUAADoVAAA/FQAAQBUAAEkVAACNFQAAlBUA AKwVAACxFQAAshUAALgVAADWFQAA3hUAAN8VAADsFQAADBYAABIWAAATFgAAGhYAADMWAAA3FgAA OBYAAD0WAABQFgAAVhYAAFcWAABcFgAAexYAAIMWAACmFgAAqhYAALQXAADaFwAA3RcAAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwACAAAAAABzBgAAhAYA ALwGAAASCAAAOAgAAD4IAAAEDQAADw0AAHENAAB6DQAAmA0AAJwNAACpEQAArREAALQXAAC4FwAA wRcAANoXAADdFwAABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcABwAaAAcAAgD//xQAAAAJ AEEAbQBpAHQAIABCAGEAcwB1ACoAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABjAG8A bgBmAGUAcgBlAG4AYwBlAHMAXABJAEMAVABFAEMAOQA4AGMAZgBwAC4AZABvAGMACQBBAG0AaQB0 ACAAQgBhAHMAdQAqAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAYwBvAG4AZgBlAHIA ZQBuAGMAZQBzAFwASQBDAFQARQBDADkAOABjAGYAcAAuAGQAbwBjAAkAQQBtAGkAdAAgAEIAYQBz AHUAKwBDADoAXAB0AGUAbQBwAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAA bwBmACAASQBDAFQARQBDADkAOABjAGYAcAAuAGEAcwBkAAkAQQBtAGkAdAAgAEIAYQBzAHUAKwBD ADoAXAB0AGUAbQBwAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAA SQBDAFQARQBDADkAOABjAGYAcAAuAGEAcwBkAAkAQQBtAGkAdAAgAEIAYQBzAHUAKwBDADoAXAB0 AGUAbQBwAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAASQBDAFQA RQBDADkAOABjAGYAcAAuAGEAcwBkAAkAQQBtAGkAdAAgAEIAYQBzAHUAKgBDADoAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAGMAbwBuAGYAZQByAGUAbgBjAGUAcwBcAEkAQwBUAEUAQwA5ADgA YwBmAHAALgBkAG8AYwAJAEEAbQBpAHQAIABCAGEAcwB1ACsAQwA6AFwAdABlAG0AcABcAEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEkAQwBUAEUAQwA5ADgAYwBmAHAA LgBhAHMAZAAJAEEAbQBpAHQAIABCAGEAcwB1ACsAQwA6AFwAdABlAG0AcABcAEEAdQB0AG8AUgBl AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEkAQwBUAEUAQwA5ADgAYwBmAHAALgBhAHMA ZAAJAEEAbQBpAHQAIABCAGEAcwB1ACoAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABj AG8AbgBmAGUAcgBlAG4AYwBlAHMAXABJAEMAVABFAEMAOQA4AGMAZgBwAC4AZABvAGMACQBBAG0A aQB0ACAAQgBhAHMAdQAqAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAYwBvAG4AZgBl AHIAZQBuAGMAZQBzAFwASQBDAFQARQBDADkAOABjAGYAcAAuAGQAbwBjAAQA+nOrJAsACQT/DwAA AAAAAAAAAAAAAAAAAAABAMhKWigLAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQDLecs8AQAJBP8P/w// D/8P/w//D/8P/w//DwEA9D8keAEACQT/DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oEAFFKBABvKAABANjwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgQAUUoEAG8oAAEA2PAAAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwBAAAAPQ/ JHgAAAAAAAAAAAAAAADLecs8AAAAAAAAAAAAAAAAyEpaKAAAAAAAAAAAAAAAAPpzqyQAAAAAAAAA AAAAAAD///////////////////////8EAAAAAAAAAAAAAAD/QAGAAQBQFQAAUBUAAOh5BQsBAAEA UBUAAAAAAABQFQAAAAAAAAIQAAAAAAAAANwXAABwAAAIAEAAAAUAAABHFpABAAACAgYDBQQFAgME hwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1 FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcD CQICBQIEBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsG kAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAA ACIABABxCIgYAADQAgAAaAEAAAAAMuQixnBLIyY6SyMmBgBIAAAAbQMAAIsTAAABAAoAAAAEAIMQ KQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAhAwAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAClBsAHtAC0AIAAMjAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADEEQAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAB0A QwBhAGwAbAAgAGYAbwByACAAUABhAHAAZQByAHMAIAAoAHAAcgBlAGwAaQBtAGkAbgBhAHIAeQAp AAAAAAAAAAkAQQBtAGkAdAAgAEIAYQBzAHUACQBBAG0AaQB0ACAAQgBhAHMAdQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EI ACsns9kwAAAAjAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMAAAAAEAAAAzAAAAAUAAADgAAAA BwAAAOwAAAAIAAAAAAEAAAkAAAAUAQAAEgAAACABAAAKAAAAPAEAAAsAAABIAQAADAAAAFQBAAAN AAAAYAEAAA4AAABsAQAADwAAAHQBAAAQAAAAfAEAABMAAACEAQAAAgAAAOQEAAAeAAAAHgAAAENh bGwgZm9yIFBhcGVycyAocHJlbGltaW5hcnkpAE1pHgAAAAEAAAAAYWxsHgAAAAoAAABBbWl0IEJh c3UAYXAeAAAAAQAAAABtaXQeAAAACwAAAE5vcm1hbC5kb3QAcB4AAAAKAAAAQW1pdCBCYXN1AABw HgAAAAIAAAA2AGl0HgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAZUAAAAAAsOsOCgAAAEAAAAAA lF6plUu9AUAAAAAARJ6Uo0S9AUAAAAAAQIKlnEu9AQMAAAABAAAAAwAAAG0DAAADAAAAixMAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAA AAXVzdWcLhsQk5cIACss+a5cAQAAGAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJAAAAAGAAAA mAAAABEAAACgAAAAFwAAAKgAAAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAAyAAAAA0AAADQ AAAADAAAAPoAAAACAAAA5AQAAB4AAAAWAAAAVmFuZGVyYmlsdCBVbml2ZXJzaXR5ACAAAwAAACkA AAADAAAACgAAAAMAAAAAGAAAAwAAALMNCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AB4QAAABAAAAHgAAAENhbGwgZm9yIFBhcGVycyAocHJlbGltaW5hcnkpAAwQAAACAAAAHgAAAAYA AABUaXRsZQADAAAAAQAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAK AAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADIANQBCAEUAMQAwADgAQgAtAEEARgA4ADkA LQAxADEARAAxAC0AQgBDADAAQQAtADAAMAA2ADAAOQA3ADIAOQA3AEEANQBCAH0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAA HQAAAP7///8fAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA/v///ycAAAAoAAAAKQAAACoAAAAr AAAALAAAAC0AAAD+////LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAAP7////9////OAAAAP7/ ///+/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /1IAbwBvAHQAIABFAG4AdAByAHkAAAAUAAAAAAAAAAAA5gJFAAAQAADI1BgAuAAUAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAgLlqwo0S9AYD16Kmc S70BOgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAeAAAAABAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADrOgAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAA AAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AABGAAAAADgAAgH///////////////9PQ1V+MVxDT05GRVJ+MVxJQ1RFQzl+My5ET0MA//+t3gAA AAAuAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAABcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABz AFwAYwBvAG4AZgBlAHIAZQBuAGMAEgACAP///////////////zkAOABjAGYAcAAuAGQAbwBjAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAA/v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wEA /v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --=====================_889596866==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu --=====================_889596866==_-- From owner-ipsec Fri Mar 13 09:47:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09392 for ipsec-outgoing; Fri, 13 Mar 1998 09:46:49 -0500 (EST) Message-Id: <199803131455.JAA13243@ghostwheel.ncsl.nist.gov> Date: Fri, 13 Mar 1998 09:55:35 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: ESP_NULL internet draft 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 As some already know, it became apparent at the Raleigh Interoperability Workshop that a draft defining ESP_NULL was needed. Steve Kent and I have put a draft together (draft-ietf-ipsec-ciph-null-00.txt) and it was submitted earlier today. I've also included a copy below. Steve Kent and others are aware that this will require changes to the ESP draft and possibly the Architecture draft. If for no other reason than to get a smile and a chuckle I'd highly recommend taking a look at this draft. Best Regards, Rob G. rob.glenn@nist.gov --------------cut here------------------ Network Working Group IPsec Working Group INTERNET DRAFT R. Glenn, NIST Expire in six months S. Kent, BBN Corp March 1998 The NULL Encryption Algorithm and Its Use With IPsec Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality. Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD]. Glenn,Kent [Page 1] INTERNET DRAFT March 1998 Expires September 1998 1. Introduction This draft defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload [ESP] to provide authentication and integrity without confidentiality. NULL is a block cipher the origins of which appear to be lost in antiquity. Despite rumors that the National Security Agency suppressed publication of this algorithm, there is no evidence of such action on their part. Rather, recent archaeological evidence suggests that the NULL algorithm was developed in Roman times, as an exportable alternative to Ceaser ciphers. However, because Roman numerals lack a symbol for zero, written records of the algorithm's development were lost to historians for over two millennia. [ESP] specifies the use of an optional encryption algorithm to provide confidentiality and the use of an optional authentication algorithm to provide authentication and integrity. The NULL encryption algorithm is a convenient way to represent the option of not applying encryption. This is referred to as ESP_NULL in [DOI]. The IPsec Authentication Header [AH] specification provides a similar service, by computing authentication data which covers the data portion of a packet as well as the immutable in transit portions of the IP header. ESP_NULL does not include the IP header in calculating the authentication data. This can be useful in providing IPsec services through Network Address Translation (NAT) devices and non-IP network devices. The discussion on how ESP_NULL might be used with NAT and non-IP network devices is outside the scope of this document. In this draft, NULL is used within the context of ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ESP] and [ROAD]. 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. Algorithm Definition NULL is defined mathematically by the use of the Identity function I applied to a block of data b such that: NULL(b) = I(b) = b 2.1 Keying Material Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption algorithm can make use of keys of varying lengths. However, no measurable increase in security is afforded by the use of longer key lengths. Glenn,Kent [Page 2] INTERNET DRAFT March 1998 Expires September 1998 2.2 Cryptographic Synchronization Because of the stateless nature of the NULL encryption algorithm, it is not necessary to transmit an IV or similar cryptographic synchronization data on a per packet (or even a per SA) basis. The NULL encryption algorithm combines many of the best features of both block and stream ciphers, while still not requiring the transmission of an IV or analogous cryptographic synchronization data. 2.3 Padding NULL has a block size of 1 byte, thus padding is not necessary. 2.4. Performance The NULL encryption algorithm is significantly faster than other commonly used symmetric encryption algorithms and implementations of the base algorithm are available for all commonly used hardware and OS platforms. 2.5 Test Vectors The following is a set of test vectors to facilitate in the development of interoperable NULL implementations. test_case = 1 data = 0x123456789abcdef data_len = 8 NULL_data = 0x123456789abcdef test_case = 2 data = "Network Security People Have A Strange Sense Of Humor" data_len = 53 NULL_data = "Network Security People Have A Strange Sense Of Humor" 3. ESP_NULL Operational Requirements ESP_NULL is defined by using NULL within the context of ESP. This section further defines ESP_NULL by pointing out particular operational parameter requirements. For purposes of IKE [IKE] key extraction, the key size for this algorithm MUST be zero (0) bits, to facilitate interoperability and to avoid any potential export control problems. To facilitate interoperability, the IV size for this algorithm MUST be zero (0) bits. Padding MAY be included on outgoing packets as specified in [ESP]. 4. Security Considerations The NULL encryption algorithm offers no confidentiality nor does it offer any other security service. It is simply a convenient way to Glenn,Kent [Page 3] INTERNET DRAFT March 1998 Expires September 1998 represent the optional use of applying encryption within ESP. ESP can then be used to provide authentication and integrity without confidentiality. Unlike AH these services are not applied to any part of the IP header. At the time of this writing there is no evidence to support that ESP_NULL is any less secure than AH when using the same authentication algorithm (i.e. a packet secured using ESP_NULL with some authentication algorithm is as cryptographically secure as a packet secured using AH with the same authentication algorithm). As stated in [ESP], while the use of encryption algorithms and authentication algorithms are optional in ESP, it is imperative that an ESP SA specifies the use of at least one cryptographically strong encryption algorithm or one cryptographically strong authentication algorithm or one of each. At the time of this writing there are no known laws preventing the exportation of NULL with a zero (0) bit key length. 5. Intellectual Property Rights Pursuant to the provisions of [RFC-2026], the authors represent that they have disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the authors. The authors do not represent that they personally know of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organizations they represent or third parties. 6. Acknowledgments Steve Bellovin suggested and provided the text for the Intellectual Property Rights section. Credit also needs to be given to the participants of the Cisco/ICSA IPsec & IKE March 1998 Interoperability Workshop since it was there that the need for this document became apparent. 7. References [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload", draft-ietf-ipsec-esp-v2-03.txt, work in progress, February 1998. [AH] Kent, S., Atkinson, R., "IP Authentication Header", draft-ietf-ipsec-auth-header-04.txt, work in progress, February 1998. [ROAD] Thayer, R., Doraswamy, N., Glenn, R., "IP Security Document Roadmap", draft-ietf-ipsec-doc-roadmap-02.txt, work in progress, November 1997. [DOI] Piper, D., "The Internet IP Security Domain of Glenn,Kent [Page 4] INTERNET DRAFT March 1998 Expires September 1998 Interpretation for ISAKMP", draft-ietf-ipsec-ipsec-doi-07.txt, work in progress, February 1998. [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", draft-ietf-ipsec-isakmp-oakley-06.txt, work in progress, February 1998. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2040] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC- Pad, and RC5-CTS Algorithms", RFC2040, October 1996 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC-2119, March 1997. 6. Editors' Address Rob Glenn NIST e-mail: rob.glenn@nist.gov Stephen Kent BBN Corporation e-mail: kent@bbn.com The IPsec working group can be contacted through the chairs: Robert Moskowitz ICSA e-mail: rgm@icsa.net Ted T'so Massachusetts Institute of Technology e-mail: tytso@mit.edu Glenn,Kent [Page 5] From owner-ipsec Fri Mar 13 10:05:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09551 for ipsec-outgoing; Fri, 13 Mar 1998 10:04:51 -0500 (EST) Message-Id: <199803131501.KAA13366@ghostwheel.ncsl.nist.gov> Date: Fri, 13 Mar 1998 10:01:28 -0500 (EST) To: ddp@network-alchemy.com Cc: ipsec@tis.com From: rob.glenn@nist.gov Subject: DOI and ESP_NULL X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, The current DOI specifies a value of 0 to represent the Transform ID for ESP_NULL. 0 is typically reserved for a variety of reasons and should be in this case as well. How 'bout 11 instead? Best Regards, Rob G. rob.glenn@nist.gov From owner-ipsec Fri Mar 13 12:16:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10499 for ipsec-outgoing; Fri, 13 Mar 1998 12:15:06 -0500 (EST) Message-Id: <199803131729.MAA06106@relay.rv.tis.com> Date: Fri, 13 Mar 98 12:25:12 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: AH/ESP drafts Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here is a summary of the changes we've made to the IPsec AH and ESP drafts. Please accept our apologies if we've missed any comments/corrections. At the request of the WG Chairs, we are sending the draft to both the IETF secretariat and directly to the mailing list (to minimize delays.) This latest versions are: draft-ietf-ipsec-esp-v2-04.txt draft-ietf-ipsec-auth-header-05.txt Thank you, Karen =========================================================================== AH Changes Section 3.3.3 Integrity Check Value Calculation -- P. Goli Changed to be consistent with Section 3.3.3.2.1 in saying that the padding is included in the ICV calculation: The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit to: The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation), and explicit padding bytes (if any)) o the upper level protocol data, which is assumed to be immutable in transit =========================================================================== ESP Changes 1. Typos/Clarifications -- per J. Daily Section 3.4.1 Reassembly Added "received" after the words "date/time" in the list of items to log for an auditable event. Added "Sequence Number" to the list of items to log for an auditable event Section 3.4.2 Security Association Lookup Added "received" after the words "date/time" in the list of items to log for an auditable event. Added "Sequence Number" to the list of items to log for an auditable event Section 3.4.3 Sequence Number Verification Added "received" after the words "date/time" in the list of items to log for an auditable event. Section 3.4.4 Integrity Check Value Verification Added "Sequence Number" to the list of items to log for an auditable event 2. Modify to make ESP encryption optional -- per community and WG-chairs ------------------------------------------------------------------------ Section 1. Introduction Changed 3rd paragraph from: ESP is used to provide.... Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality.... to: ESP is used to provide.... Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with (optional) confidentiality.... Note that although both confidentiality and authentication are optional, at least one of them MUST be selected. Section 3.2 Algorithms Added sentence to 1st paragraph Note that although both confidentiality and authentication are optional, at least one of these services MUST be selected hence both algorithms MUST NOT be simultaneously NULL. Section 3.3.2 Packet Encryption Changed leadin sentence from: The sender: 1. encapsulates.... 2. adds... 3. encrypts... to If confidentiality is selected, then the sender: 1. encapsulates.... 2. adds... 3. encrypts... Section 3.4.5 Packet Decryption Changed leadin sentence from: The receiver: 1. decrypts.... to If confidentiality has been selected, then the receiver: 1. decrypts.... Section 5. Conformance Requirements Changed list of algorithms from: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] to: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] - NULL Authentication algorithm - NULL Encryption algorithm Added the text: Since ESP encryption and authentication are optional, support for the 2 "NULL" algorithms is required to maintain consistency with the way these services are negotiated. NOTE that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL". From owner-ipsec Fri Mar 13 12:27:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10581 for ipsec-outgoing; Fri, 13 Mar 1998 12:27:06 -0500 (EST) Message-Id: <199803131737.MAA03366@relay.hq.tis.com> Date: Fri, 13 Mar 98 12:33:39 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Architecture draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here is a summary of the changes we've made to the IPsec Architecture draft. We've tried to include all the comments/feedback received over the past few weeks, but there were a few issues that came up at the last minute which have not yet been resolved (waiting for feedback from the community, etc.) and which therefore did not get addressed in this version. In addition, there is still some text that could benefit from additional clarification. Unfortunately, because of the small amount of time between when we received the comments and today's deadline, we had to focus on addressing the issues that seemed substantive or that were just straightforward changes/corrections. Please accept our apologies if we've missed any other comments/corrections. At the request of the WG Chairs, we are sending the draft to both the IETF secretariat and directly to the mailing list (to minimize delays.) This latest version is: draft-ietf-ipsec-arch-sec-04.txt. Thank you, Karen =========================================================================== 1. Typos/clarifications: ------------------------ Section 1.1 Summary of Contents of Document fixed formatting of item c. Section 1.3 Related Documents fixed formatting of item d. Section 4.3 Combining Security Associations -- per H. Redelmeier changed first bullet of second paragraph from: o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance at the (ultimate) destination. to: 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 (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination. changed 3rd paragraph from: 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. to: These two approaches also can be combined, e.g., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. Section 4.4.1 The Security Policy Database (SPD) -- per H. Redelmeier changed 3rd paragraph to clarify why it is feasible to specify that security processing be applied on a "packet by packet basis": 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. to: For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any 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 (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a single UDP or TCP connection will tend to match a single SPD entry, this requirement will not impose an unreasonably detailed level of SPD specification. The selectors are analogous to what are found in a stateless firewall or filtering router and which are currently manageable this way. Section 4.4.2 Selectors -- paragraph on "Name" -- per D. Piper changed "Note that these name forms are supported in ISAKMP" to "Note that these name forms are supported in the IPsec DOI" changed "[REQUIRED for...." to "[REQUIRED for the following cases...." Section 4.5 Basic Combinations of Security Associations --per Kai Martius changed last sentence of Case 4 from: 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". to 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.6.3, "Locating a Security Gateway". Section 4.6.3 Locating a Security Gateway -- per Kai Martius fixed last word of next to last paragraph from: 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. to 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 host. Section 5.1.2 Header Construction for Tunnel Mode -- per H. Redelmeier changed first bullet to clarify the meaning of "original" in the presence of tunneling within tunneling: o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively.... to o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, (from the perspective of this tunnel), respectively.... Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- per Indermohan Singh Monga changed table entry for checksum from: <-- How Outer Hdr Relates to Inner Hdr --> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ ...... ...... ...... checksum constructed no change ...... ...... ...... to: <-- How Outer Hdr Relates to Inner Hdr --> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ ...... ...... ...... checksum constructed constructed (2) ...... ...... ...... changed footnote (2) from: 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.) Acknowledgements -- per H. Redelmeier removed space after comma and changed 2 years to 3 years: For over 2 years (although it sometimes seems *much* longer) , this.... to For over 3 years (although it sometimes seems *much* longer), this.... Appendix C -- per H. Redelmeier changed each occurrence of "(1 << diff)" to "((u_long)1 << diff)" left "test harness" as is -- received no comments 2. Modify to make ESP encryption/confidentiality optional -- per co-chairs -------------------------------------------------------------------------- Section 3.2 How IPsec Works changed 1st paragraph, second bullet from: o The Encapsulating Security Payload (ESP) protocol [KA98b] provides confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. to: o The Encapsulating Security Payload (ESP) protocol [KA98b] may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.) Section 4.2 Security Association Functionality changed first and last sentences of the 3rd paragraph from: "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." to "ESP optionally provides confidentiality for traffic. (The strength of the confidentiality service depends 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(are) 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. Note that although both confidentiality and authentication are optional, they cannot both be omitted. At least one of them MUST be selected. Section 4.4.1 The Security Policy Database (SPD) added the following text after paragraph 8 ("As described below..." Note that if ESP is specified, either (but not both) authentication or encryption can be omitted. So it MUST be possible to configure the SPD value for the authentication or encryption algorithms to be "NULL". However, at least one of these services MUST be selected, i.e., it MUST NOT be possible to configure both of them as "NULL". Section 4.4.3 Security Association Database (SAD) added the following text at the end of paragraph 1 "For each of the selectors defined in Section 4.4.2..." Note that for an ESP SA, either the encryption algorithm or the authentication algorithm can be "NULL". However they MUST NOT both be "NULL". 3. Mention IPSec DOI support for IP compression negotiation ------------------------------------------------------------ Section 3.1 What IPsec Does changed 4th paragraph from: 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." to; The IPsec DOI supports negotiation of IP compression, motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. 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." From owner-ipsec Fri Mar 13 13:01:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10822 for ipsec-outgoing; Fri, 13 Mar 1998 13:01:13 -0500 (EST) Message-Id: <3.0.5.32.19980313123345.009bf130@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 13 Mar 1998 12:33:45 -0500 To: rob.glenn@nist.gov, ipsec@tis.com From: Robert Moskowitz Subject: Re: ESP_NULL internet draft submitted In-Reply-To: <199803131455.JAA13243@ghostwheel.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:55 AM 3/13/98 -0500, rob.glenn@nist.gov wrote: > >As some already know, it became apparent at the Raleigh Interoperability >Workshop that a draft defining ESP_NULL was needed. Steve Kent and I >have put a draft together (draft-ietf-ipsec-ciph-null-00.txt) and it >was submitted earlier today. I've also included a copy below. Rob, thank you for pulling together this masterful piece in such a short time. :) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Mar 13 15:14:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11722 for ipsec-outgoing; Fri, 13 Mar 1998 15:11:05 -0500 (EST) Message-Id: <199803132021.PAA12657@relay.hq.tis.com> To: ipsec@tis.com Subject: IPSEC DOI V8 Date: Fri, 13 Mar 1998 12:23:55 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here's a summary of the changes to the IPSEC DOI. Section 2 - added reference to base IPSEC documents (ARCH, AH, ESP) Section 4.3.1 - removed refernece to the PF_KEY ID (not in Last Call) Section 4.4.1.4 - corrected name of IPCOMP - IP Payload Compression Section 4.4.3, Section 4.4.4 - added note about the required use of the Authentication Algorithm attribute with AH and ESP Section 4.4.3.n - added restriction against using conflicting AH transform ID's and Authentication Algorithm attribute values, e.g. trying for AH_MD5 with Auth(HMAC-SHA) Section 4.4.4 - restored RESERVED as ESP ID 0 (Rob Glenn) - moved ESP_NULL to ESP ID 11 - removed reference to the ARCFOUR ID (not in Last Call) - added reference to ESP NULL cipher document Section 4.4.4.n, References - removed obsolete cipher document referneces and replaced them with pointers to The One True CBC Cipher Document (tm) Section 4.5 - replaced "B/V" notation with "V" to mirror change to [IKE] - add additional clarifying text about B/V substitutions Section 4.6.1, Figure 1 - added missing Secrecy Level and Integrity Level fields to text description under figure Section 4.6.3 - removed bogus claim that aggressive mode protects Notify's - add security note about using Notify payloads in Main Mode Referneces - updated various document version numbers From owner-ipsec Fri Mar 13 15:51:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11958 for ipsec-outgoing; Fri, 13 Mar 1998 15:51:04 -0500 (EST) Message-ID: <35099F6F.45455058@redcreek.com> Date: Fri, 13 Mar 1998 13:04:47 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: comments on ...isakmp-mode-cfg-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a few comments on draft-ietf-ipsec-isakmp-mode-cfg-02.txt. I am not prepared to comment regarding the usefulness of the proposed functionality. Rather, I'll confine my comments to the mechanism proposed for adding the suggested functionality, i.e. piggy-backing 'configuration' messages onto the notify payload. While such configuration messages might be useful, this is *not* the best way to add them, and in fact, it looks like a hack. The notify messages have been defined for one-way communication of status information, while the configuration exchange being proposed is actually a 2-way negotiation. Why not suggest a new payload type for this? I won't go into all the specific and obvious arguments against the suggested payload overloading, as I believe these are self-evident. I will, however, point out that the ISAKMP-09 draft contains the following text on page 70: 'Because the Informational Exchange with a Notification payload is a unidirectional message a retransmission will not be performed...' It appears that the design intent is for one-way (unidirectional) usage, while the configuration mode suggested clearly requires bidirectional communication... Scott From owner-ipsec Fri Mar 13 16:24:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12238 for ipsec-outgoing; Fri, 13 Mar 1998 16:23:06 -0500 (EST) Message-ID: <3509A6CF.446B@cs.umass.edu> Date: Fri, 13 Mar 1998 16:36:15 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: AH/ESP drafts References: <199803131729.MAA06106@relay.rv.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen Seo writes re: draft-...-esp-v2-04.txt: > Section 5. Conformance Requirements > > Changed list of algorithms [...] > to: > - DES in CBC mode [MD97] > - HMAC with MD5 [MG97a] > - HMAC with SHA-1 [MG97b] > - NULL Authentication algorithm > - NULL Encryption algorithm > > Added the text: > > Since ESP encryption and authentication are optional, > support for the 2 "NULL" algorithms is required to > maintain consistency with the way these services are > negotiated. NOTE that while authentication and > encryption can each be "NULL", they MUST NOT both be > "NULL". If we treat NULL-Auth and NULL-Encrypt as separate algorithms, do we need draft-ietf-ipsec-ciph-null to define a NULL-Auth? Currently it explicitly gives a definition of an _encryption_ algorithm, not an authentication algorithm. (Reading ESP Sec. 2.7 literally, we would need to add specification of the ICV field length and "the comparison and processing steps for validation" to create a conformant auth algorithm spec :-) -Lewis From owner-ipsec Fri Mar 13 16:39:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12411 for ipsec-outgoing; Fri, 13 Mar 1998 16:39:05 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'rob.glenn@nist.gov'" , ipsec@tis.com Subject: RE: ESP_NULL internet draft submitted Date: Fri, 13 Mar 1998 11:57:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Three comments: 1. Should the pad length field be present and set to 0 or omitted? 2. This will mean that the authentication data will not be at 4 or 8 byte boundary (which is typically the case when ESP is used with popular encryption algorithms). This may create a problem for some hardware ESP accelerators! Section suggests that we can use keys of non-zero length. 2.1 Keying Material Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption algorithm can make use of keys of varying lengths. However, no measurable increase in security is afforded by the use of longer key lengths. Section 3 requires that key length is 0. One of the two should be changed to avoid confusion. 3. ESP_NULL Operational Requirements For purposes of IKE [IKE] key extraction, the key size for this algorithm MUST be zero (0) bits, to facilitate interoperability and to avoid any potential export control problems. Baiju > -----Original Message----- > From: rob.glenn@nist.gov [SMTP:rob.glenn@nist.gov] > Sent: Friday, March 13, 1998 6:56 AM > To: ipsec@tis.com > Subject: ESP_NULL internet draft submitted > > > As some already know, it became apparent at the Raleigh > Interoperability > Workshop that a draft defining ESP_NULL was needed. Steve Kent and I > have put a draft together (draft-ietf-ipsec-ciph-null-00.txt) and it > was submitted earlier today. I've also included a copy below. > > Steve Kent and others are aware that this will require changes to > the ESP draft and possibly the Architecture draft. > > If for no other reason than to get a smile and a chuckle I'd highly > recommend taking a look at this draft. > > Best Regards, > > Rob G. rob.glenn@nist.gov > > --------------cut here------------------ > > > > > > > Network Working Group IPsec Working > Group > INTERNET DRAFT R. Glenn, > NIST > Expire in six months S. Kent, BBN > Corp > March > 1998 > > > The NULL Encryption Algorithm and Its Use With IPsec > > > > > > Status of this Memo > > This document is a submission to the IETF Internet Protocol > Security > (IPSEC) Working Group. Comments are solicited and should be > addressed > to the working group mailing list (ipsec@tis.com) or to the editor. > > This document is an Internet-Draft. Internet Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working Groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet-Drafts draft documents are valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents at > any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > To learn the current status of any Internet-Draft, please check the > "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow > Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > Distribution of this memo is unlimited. > > Abstract > > This draft defines the NULL encryption algorithm and its use with > the > IPsec Encapsulating Security Payload (ESP). NULL does nothing to > alter plaintext data. In fact, NULL, by itself, does nothing. > NULL > provides the means for ESP to provide authentication and integrity > without confidentiality. > > Further information on the other components necessary for ESP > implementations is provided by [ESP] and [ROAD]. > > > > > > > > > > > > Glenn,Kent [Page > 1] > > INTERNET DRAFT March 1998 Expires September > 1998 > > > 1. Introduction > > This draft defines the NULL encryption algorithm and its use with > the > IPsec Encapsulating Security Payload [ESP] to provide > authentication > and integrity without confidentiality. > > NULL is a block cipher the origins of which appear to be lost in > antiquity. Despite rumors that the National Security Agency > suppressed publication of this algorithm, there is no evidence of > such action on their part. Rather, recent archaeological evidence > suggests that the NULL algorithm was developed in Roman times, as > an > exportable alternative to Ceaser ciphers. However, because Roman > numerals lack a symbol for zero, written records of the algorithm's > development were lost to historians for over two millennia. > > [ESP] specifies the use of an optional encryption algorithm to > provide confidentiality and the use of an optional authentication > algorithm to provide authentication and integrity. The NULL > encryption algorithm is a convenient way to represent the option of > not applying encryption. This is referred to as ESP_NULL in [DOI]. > > The IPsec Authentication Header [AH] specification provides a > similar > service, by computing authentication data which covers the data > portion of a packet as well as the immutable in transit portions of > the IP header. ESP_NULL does not include the IP header in > calculating the authentication data. This can be useful in > providing > IPsec services through Network Address Translation (NAT) devices > and > non-IP network devices. The discussion on how ESP_NULL might be > used with NAT and non-IP network devices is outside the scope of > this > document. > > In this draft, NULL is used within the context of ESP. For further > information on how the various pieces of ESP fit together to > provide > security services, refer to [ESP] and [ROAD]. > > 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. Algorithm Definition > > NULL is defined mathematically by the use of the Identity function > I > applied to a block of data b such that: > > NULL(b) = I(b) = b > > 2.1 Keying Material > > Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL > encryption > algorithm can make use of keys of varying lengths. However, no > measurable increase in security is afforded by the use of longer > key > lengths. > > > > > > Glenn,Kent [Page > 2] > > INTERNET DRAFT March 1998 Expires September > 1998 > > > 2.2 Cryptographic Synchronization > > Because of the stateless nature of the NULL encryption algorithm, > it > is not necessary to transmit an IV or similar cryptographic > synchronization data on a per packet (or even a per SA) basis. The > NULL encryption algorithm combines many of the best features of > both > block and stream ciphers, while still not requiring the > transmission > of an IV or analogous cryptographic synchronization data. > > 2.3 Padding > > NULL has a block size of 1 byte, thus padding is not necessary. > > 2.4. Performance > > The NULL encryption algorithm is significantly faster than other > commonly used symmetric encryption algorithms and implementations > of > the base algorithm are available for all commonly used hardware and > OS platforms. > > 2.5 Test Vectors > > The following is a set of test vectors to facilitate in the > development of interoperable NULL implementations. > > test_case = 1 > data = 0x123456789abcdef > data_len = 8 > NULL_data = 0x123456789abcdef > > test_case = 2 > data = "Network Security People Have A Strange Sense Of > Humor" > data_len = 53 > NULL_data = "Network Security People Have A Strange Sense Of > Humor" > > 3. ESP_NULL Operational Requirements > > ESP_NULL is defined by using NULL within the context of ESP. This > section further defines ESP_NULL by pointing out particular > operational parameter requirements. > > For purposes of IKE [IKE] key extraction, the key size for this > algorithm MUST be zero (0) bits, to facilitate interoperability and > to avoid any potential export control problems. > > To facilitate interoperability, the IV size for this algorithm MUST > be zero (0) bits. > > Padding MAY be included on outgoing packets as specified in [ESP]. > > 4. Security Considerations > > The NULL encryption algorithm offers no confidentiality nor does it > offer any other security service. It is simply a convenient way to > > > > Glenn,Kent [Page > 3] > > INTERNET DRAFT March 1998 Expires September > 1998 > > > represent the optional use of applying encryption within ESP. ESP > can then be used to provide authentication and integrity without > confidentiality. Unlike AH these services are not applied to any > part of the IP header. At the time of this writing there is no > evidence to support that ESP_NULL is any less secure than AH when > using the same authentication algorithm (i.e. a packet secured > using > ESP_NULL with some authentication algorithm is as cryptographically > secure as a packet secured using AH with the same authentication > algorithm). > > As stated in [ESP], while the use of encryption algorithms and > authentication algorithms are optional in ESP, it is imperative > that > an ESP SA specifies the use of at least one cryptographically > strong > encryption algorithm or one cryptographically strong authentication > algorithm or one of each. > > At the time of this writing there are no known laws preventing the > exportation of NULL with a zero (0) bit key length. > > 5. Intellectual Property Rights > > Pursuant to the provisions of [RFC-2026], the authors represent > that > they have disclosed the existence of any proprietary or > intellectual > property rights in the contribution that are reasonably and > personally known to the authors. The authors do not represent that > they personally know of all potentially pertinent proprietary and > intellectual property rights owned or claimed by the organizations > they represent or third parties. > > 6. Acknowledgments > > Steve Bellovin suggested and provided the text for the Intellectual > Property Rights section. > > Credit also needs to be given to the participants of the Cisco/ICSA > IPsec & IKE March 1998 Interoperability Workshop since it was there > that the need for this document became apparent. > > 7. References > > [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security > Payload", draft-ietf-ipsec-esp-v2-03.txt, work in > progress, > February 1998. > > [AH] Kent, S., Atkinson, R., "IP Authentication Header", > draft-ietf-ipsec-auth-header-04.txt, work in progress, > February 1998. > > [ROAD] Thayer, R., Doraswamy, N., Glenn, R., "IP Security > Document Roadmap", > draft-ietf-ipsec-doc-roadmap-02.txt, work in progress, > November 1997. > > [DOI] Piper, D., "The Internet IP Security Domain of > > > > Glenn,Kent [Page > 4] > > INTERNET DRAFT March 1998 Expires September > 1998 > > > Interpretation for ISAKMP", > draft-ietf-ipsec-ipsec-doi-07.txt, work in progress, > February 1998. > > [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange > (IKE)", draft-ietf-ipsec-isakmp-oakley-06.txt, work in > progress, February 1998. > > [RFC-2026] Bradner, S., "The Internet Standards Process -- > Revision 3", RFC2026, October 1996. > > [RFC-2040] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC- > Pad, and RC5-CTS Algorithms", RFC2040, October 1996 > > [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC-2119, March 1997. > > > 6. Editors' Address > > Rob Glenn > NIST > e-mail: rob.glenn@nist.gov > > Stephen Kent > BBN Corporation > e-mail: kent@bbn.com > > The IPsec working group can be contacted through the chairs: > > Robert Moskowitz > ICSA > e-mail: rgm@icsa.net > > Ted T'so > Massachusetts Institute of Technology > e-mail: tytso@mit.edu > > > > > > > > > > > > > > > > > > > > > Glenn,Kent [Page > 5] > > > From owner-ipsec Fri Mar 13 16:55:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12587 for ipsec-outgoing; Fri, 13 Mar 1998 16:55:09 -0500 (EST) Message-Id: <199803131738.MAA03421@relay.hq.tis.com> Date: Fri, 13 Mar 98 12:39:18 EST From: Karen Seo To: internet-drafts@ietf.org cc: ipsec@tis.com Subject: Internet Draft -- IPsec AH Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec AH specification. Thank you, Karen ^L Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-header-05.txt March 1998 IP Authentication Header Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPsec Working Group. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Copyright (C) The Internet Society (March 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header March 1998 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................5 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................6 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Authentication Algorithms....................................8 3.3 Outbound Packet Processing...................................8 3.3.1 Security Association Lookup.............................9 3.3.2 Sequence Number Generation..............................9 3.3.3 Integrity Check Value Calculation.......................9 3.3.3.1 Handling Mutable Fields...........................10 3.3.3.1.1 ICV Computation for IPv4.....................10 3.3.3.1.1.1 Base Header Fields.......................10 3.3.3.1.1.2 Options..................................11 3.3.3.1.2 ICV Computation for IPv6.....................11 3.3.3.1.2.1 Base Header Fields.......................11 3.3.3.1.2.2 Extension Headers -- Options.............12 3.3.3.1.2.3 Extension Headers -- non-Options.........12 3.3.3.2 Padding...........................................12 3.3.3.2.1 Authentication Data Padding..................12 3.3.3.2.2 Implicit Packet Padding......................13 3.3.4 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................15 4. Auditing.........................................................16 5. Conformance Requirements.........................................16 6. Security Considerations..........................................17 7. Differences from RFC 1826........................................17 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............19 A1. IPv4 Options.................................................19 A2. IPv6 Extension Headers.......................................20 References..........................................................22 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header March 1998 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header March 1998 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Kent, Atkinson [Page 4] Internet Draft IP Authentication Header March 1998 Data Padding"). 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header March 1998 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.3.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header March 1998 BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the Kent, Atkinson [Page 7] Internet Draft IP Authentication Header March 1998 entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<- authenticated except for mutable fields -->| | in the new IP hdr | -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-- authenticated except for mutable fields in new IP hdr ->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 3.3 Outbound Packet Processing In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header Kent, Atkinson [Page 8] Internet Draft IP Authentication Header March 1998 SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the- wire implementation between the host and the network.) 3.3.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document. 3.3.2 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST not send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation), and explicit padding bytes (if any)) o the upper level protocol data, which is assumed to be immutable in transit Kent, Atkinson [Page 9] Internet Draft IP Authentication Header March 1998 3.3.3.1 Handling Mutable Fields If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field is also set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.3.3.1.1 ICV Computation for IPv4 3.3.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Kent, Atkinson [Page 10] Internet Draft IP Authentication Header March 1998 Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.3.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header March 1998 Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit 3.3.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.3.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3.3.3.2 Padding 3.3.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily Kent, Atkinson [Page 12] Internet Draft IP Authentication Header March 1998 selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.3.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.4 Inbound Packet Processing If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 13] Internet Draft IP Authentication Header March 1998 NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Kent, Atkinson [Page 14] Internet Draft IP Authentication Header March 1998 Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Kent, Atkinson [Page 15] Internet Draft IP Authentication Header March 1998 Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms: Kent, Atkinson [Page 16] Internet Draft IP Authentication Header March 1998 - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. Acknowledgements For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Kent, Atkinson [Page 17] Internet Draft IP Authentication Header March 1998 Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. Kent, Atkinson [Page 18] Internet Draft IP Authentication Header March 1998 Appendix A -- Mutability of IP Options/Extension Headers A1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. Kent, Atkinson [Page 19] Internet Draft IP Authentication Header March 1998 However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec. NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. A2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is Kent, Atkinson [Page 20] Internet Draft IP Authentication Header March 1998 included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 21] Internet Draft IP Authentication Header March 1998 References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, March, 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, March 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, February 1998. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, February 1998. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 22] Internet Draft IP Authentication Header March 1998 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@corp.home.net Telephone: +1 (415) 569-5000 Copyright (C) The Internet Society (March 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 23] From owner-ipsec Fri Mar 13 16:55:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12586 for ipsec-outgoing; Fri, 13 Mar 1998 16:55:07 -0500 (EST) Message-Id: <199803131738.MAA03416@relay.hq.tis.com> Date: Fri, 13 Mar 98 12:38:11 EST From: Karen Seo To: internet-drafts@ietf.org cc: ipsec@tis.com Subject: Internet Draft -- IPsec ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec ESP specification. Thank you, Karen ^L Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-v2-04.txt March 1998 IP Encapsulating Security Payload (ESP) Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft is a product of the IETF's IPsec working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Copyright (C) The Internet Society (March 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................6 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................8 3. Encapsulating Security Protocol Processing........................8 3.1 ESP Header Location..........................................8 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................11 3.3 Outbound Packet Processing..................................11 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................12 3.3.4 Integrity Check Value Calculation......................13 3.3.5 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................14 3.4.1 Reassembly.............................................14 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................16 3.4.5 Packet Decryption......................................16 4. Auditing.........................................................18 5. Conformance Requirements.........................................18 6. Security Considerations..........................................19 7. Differences from RFC 1827........................................19 Acknowledgements....................................................19 References..........................................................20 Disclaimer..........................................................21 Author Information..................................................21 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with (optional) confidentiality. The anti- replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. Note that although both confidentiality and authentication are optional, at least one of them MUST be selected. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways Kent, Atkinson [Page 3] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an Integrity Check Value (ICV, see Section 2.7). Whether or not an option is selected is defined as Kent, Atkinson [Page 4] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs. 2.1 Security Parameters Index The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory. The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved. 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow Kent, Atkinson [Page 6] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 2.5 Pad Length The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that no Padding bytes are present. The Pad Length field is mandatory. 2.6 Next Header The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most Kent, Atkinson [Page 7] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 3. Encapsulating Security Protocol Processing 3.1 ESP Header Location Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.) Kent, Atkinson [Page 8] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the Kent, Atkinson [Page 9] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. ----------------------------------------------------------- IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| ----------------------------------------------------------- |<--------- encrypted ---------->| |<----------- authenticated ---------->| ------------------------------------------------------------ IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| ------------------------------------------------------------ |<--------- encrypted ----------->| |<---------- authenticated ---------->| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Algorithms The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. Note that although both confidentiality and authentication are optional, at least one of these services MUST be selected hence both algorithms MUST NOT be simultaneously NULL. 3.2.1 Encryption Algorithms The encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that since encryption (confidentiality) is Kent, Atkinson [Page 10] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) optional, this algorithm may be "NULL". 3.2.2 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. Note that since authentication is optional, this algorithm may be "NULL". 3.3 Outbound Packet Processing In transport mode, the sender encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.1 Security Association Lookup ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document. 3.3.2 Packet Encryption If confidentiality is selected, then the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). Kent, Atkinson [Page 11] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document. If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV. 3.3.3 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). Kent, Atkinson [Page 12] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) 3.3.4 Integrity Check Value Calculation If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is performed prior to authentication. For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, (after the Next Header field) prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. Kent, Atkinson [Page 13] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) 3.4 Inbound Packet Processing 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID. NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable). If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID. 3.4.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the Kent, Atkinson [Page 14] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.4 Integrity Check Value Verification If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID. DISCUSSION: Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 3.4.5 Packet Decryption If confidentiality has been selected, then the receiver: 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. Note: If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address, or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use Kent, Atkinson [Page 17] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] - NULL Authentication algorithm Kent, Atkinson [Page 18] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) - NULL Encryption algorithm Since ESP encryption and authentication are optional, support for the 2 "NULL" algorithms is required to maintain consistency with the way these services are negotiated. NOTE that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL". 6. Security Considerations Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1827 This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92, IB93]. For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors Kent, Atkinson [Page 19] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, March 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1998. [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Internet Draft, February 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, February 1998. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, February 1998. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Kent, Atkinson [Page 20] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@corp.home.net Telephone: +1 (415) 569-5000 Copyright (C) The Internet Society (March 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be Kent, Atkinson [Page 21] Internet Draft IP Encapsulating March 1998 Security Payload (ESP) followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 22] From owner-ipsec Fri Mar 13 16:55:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12588 for ipsec-outgoing; Fri, 13 Mar 1998 16:55:09 -0500 (EST) Message-Id: <199803131738.MAA03419@relay.hq.tis.com> Date: Fri, 13 Mar 98 12:36:06 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 Hello, Please find attached the Internet Draft for the IPsec Architecture document. Thank you, Karen ^L Network Working Group Stephen Kent, BBN Corp draft-ietf-ipsec-arch-sec-04.txt Randall Atkinson, @Home Network Obsoletes RFC 1825 March 1998 Security Architecture for the Internet Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IP Security (IPsec) working group. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments about this draft may be sent to the authors or to the IPsec WG mailing list . Distribution of this document is unlimited. Copyright (C) The Internet Society (March 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft Security Architecture for IP March 1998 Table of Contents 1. Introduction............................................................4 1.1 Summary of Contents of Document.....................................4 1.2 Audience............................................................4 1.3 Related Documents...................................................5 2. Design Objectives.......................................................5 2.1 Goals/Objectives/Requirements/Problem Description...................5 2.2 Caveats and Assumptions.............................................6 3. System Overview ........................................................6 3.1 What IPsec Does.....................................................7 3.2 How IPsec Works.....................................................7 3.3 Where IPsec May Be Implemented......................................8 4. Security Associations...................................................9 4.1 Definition and Scope................................................9 4.2 Security Association Functionality.................................11 4.3 Combining Security Associations....................................12 4.4 Security Association Databases.....................................14 4.4.1 The Security Policy Database (SPD)............................14 4.4.2 Selectors.....................................................18 4.4.3 Security Association Database (SAD)...........................21 4.5 Basic Combinations of Security Associations........................23 4.6 SA and Key Management..............................................26 4.6.1 Manual Techniques.............................................27 4.6.2 Automated SA and Key Management...............................27 4.6.3 Locating a Security Gateway...................................28 4.7 Security Associations and Multicast................................29 5. IP Traffic Processing..................................................30 5.1 Outbound IP Traffic Processing.....................................30 5.1.1 Selecting and Using an SA or SA Bundle........................30 5.1.2 Header Construction for Tunnel Mode...........................31 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............32 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............33 5.2 Processing Inbound IP Traffic......................................33 5.2.1 Selecting and Using an SA or SA Bundle........................33 5.2.2 Handling of AH and ESP tunnels................................34 6. ICMP Processing (relevant to IPsec)....................................35 6.1 PMTU/DF Processing.................................................36 6.1.1 DF Bit........................................................36 6.1.2 Path MTU Discovery (PMTU).....................................36 6.1.2.1 Propagation of PMTU......................................36 6.1.2.2 Calculation of PMTU......................................37 6.1.2.3 Granularity of PMTU Processing...........................37 6.1.2.4 PMTU Aging...............................................38 7. Auditing...............................................................39 8. Use in Systems Supporting Information Flow Security....................39 8.1 Relationship Between Security Associations and Data Sensitivity....40 8.2 Sensitivity Consistency Checking...................................40 Kent, Atkinson [Page 2] Internet Draft Security Architecture for IP March 1998 8.3 Additional MLS Attributes for Security Association Databases.......41 8.4 Additional Inbound Processing Steps for MLS Networking.............41 8.5 Additional Outbound Processing Steps for MLS Networking............41 8.6 Additional MLS Processing for Security Gateways....................42 9. Performance Issues.....................................................42 10. Conformance Requirements..............................................43 11. Security Considerations...............................................43 12. Differences from RFC 1825.............................................43 Acknowledgements..........................................................43 Appendix A -- Glossary....................................................45 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........48 B.1 DF bit.............................................................48 B.2 Fragmentation......................................................48 B.3 Path MTU Discovery.................................................52 B.3.1 Identifying the Originating Host(s)...........................53 B.3.2 Calculation of PMTU...........................................55 B.3.3 Granularity of Maintaining PMTU Data..........................55 B.3.4 Per Socket Maintenance of PMTU Data...........................57 B.3.5 Delivery of PMTU Data to the Transport Layer..................57 B.3.6 Aging of PMTU Data............................................57 Appendix C -- Sequence Space Window Code Example..........................58 Appendix D -- Categorization of ICMP messages.............................60 References................................................................63 Disclaimer................................................................64 Author Information........................................................65 Kent, Atkinson [Page 3] Internet Draft Security Architecture for IP March 1998 1. Introduction 1.1 Summary of Contents of Document This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automatic (The Internet Key Exchange (IKE)) d. Algorithms for authentication and encryption This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 1.2 Audience The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts. Kent, Atkinson [Page 4] Internet Draft Security Architecture for IP March 1998 1.3 Related Documents As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics: a. "IP Security Document Roadmap" [TDG97] -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Header (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b] protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm. d. automatic key management -- RFCs on "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination Protocol" [Orm97], and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98]. 2. Design Objectives 2.1 Goals/Objectives/Requirements/Problem Description IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols. These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations. When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select Kent, Atkinson [Page 5] Internet Draft Security Architecture for IP March 1998 different sets of algorithms (creating cliques) if required. A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology. 2.2 Caveats and Assumptions The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture. Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc. can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards. 3. System Overview This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail. An IPsec implementation operates in a host or a security gateway environment, affording protection to IP traffic. The protection offered is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer Kent, Atkinson [Page 6] Internet Draft Security Architecture for IP March 1998 header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors. 3.1 What IPsec Does IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.) The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc. The IPsec DOI supports negotiation of IP compression, motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPsec." 3.2 How IPsec Works IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA98a, KA98b]. o The IP Authentication Header (AH) [KA98a] provides connectionless integrity, data origin authentication, and an optional anti-replay service. o The Encapsulating Security Payload (ESP) protocol [KA98b] may provide confidentiality (encryption), and limited traffic flow Kent, Atkinson [Page 7] Internet Draft Security Architecture for IP March 1998 confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.) o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols. These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4. IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management must incorporate facilities for specifying: o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed. 3.3 Where IPsec May Be Implemented There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below: a. Integration of IPsec into the native IP implementation. This Kent, Atkinson [Page 8] Internet Draft Security Architecture for IP March 1998 requires access to the IP source code and is applicable to both hosts and security gateways. b. "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts. c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the BITW device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway. 4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Kent, Atkinson [Page 9] Internet Draft Security Architecture for IP March 1998 Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA98a]. A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. Kent, Atkinson [Page 10] Internet Draft Security Architecture for IP March 1998 In summary, a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. 4.2 Security Association Functionality The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors". AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service (except for the non-predictable but mutable parts of the IP header.) ESP optionally provides confidentiality for traffic. (The strength of the confidentiality service depends 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. Note that although both confidentiality and authentication are optional, they cannot both be omitted. At least one of them MUST be selected. 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 Kent, Atkinson [Page 11] Internet Draft Security Architecture for IP March 1998 concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones which are carrying traffic from many subscribers. 4.3 Combining Security Associations The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.) Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling. o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)---------- o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than Kent, Atkinson [Page 12] Internet Draft Security Architecture for IP March 1998 what can be specified through appropriate SPD entries (See Case 3 in Section 4.5) There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.: 1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -------Security Association 1 (tunnel)---------- | | | | ---------Security Association 2 (tunnel)-------------- 2. one endpoint of the SAs is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- 3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)----------- These two approaches also can be combined, e.g., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels. Kent, Atkinson [Page 13] Internet Draft Security Architecture for IP March 1998 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. 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. Kent, Atkinson [Page 14] Internet Draft Security Architecture for IP March 1998 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 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. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any 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 (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a single UDP or TCP connection will tend to match a single SPD entry, this requirement will not impose an unreasonably detailed level of SPD specification. The selectors are analogous to what are found in a stateless firewall or filtering router and which are currently manageable this way. 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. Kent, Atkinson [Page 15] Internet Draft Security Architecture for IP March 1998 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 how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- if this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector were a range, then (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. c. use a wildcard value -- this can be used to create an SA that can be shared by a broader set of SPD entries (vs (b)). For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value: source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) c. wildcard * (any host) Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD Kent, Atkinson [Page 16] Internet Draft Security Architecture for IP March 1998 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 for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5. Note that if ESP is specified, either (but not both) authentication or encryption can be omitted. So it MUST be possible to configure the SPD value for the authentication or encryption algorithms to be "NULL". However, at least one of these services MUST be selected, i.e., it MUST NOT be possible to configure both of them as "NULL". 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 Kent, Atkinson [Page 17] Internet Draft Security Architecture for IP March 1998 and the receiver) MUST allow an SA to be used in more than one bundle. The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway. 4.4.2 Selectors An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and UserID (if present) may be opaque. - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (e.g., behind a security gateway). Note that this selector is conceptually different from the "Destination IP Address" field in the tuple used to uniquely identify an SA. When a tunnelled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. Once the packet has been processed according to the tunnel SA and has come out of the tunnel, its selectors are "looked up" in the Inbound SPD. The Inbound SPD has a selector called destination address. This IP destination address is the one in the inner (encapsulated) IP header. In the case of a Kent, Atkinson [Page 18] Internet Draft Security Architecture for IP March 1998 transport'd packet, there will be only one IP header and this ambiguity does not exist. [REQUIRED for all implementations] - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address, range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] - Name: There are 2 cases (Note that these name forms are supported in the IPsec DOI.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name Note that one of the possible values of this selector is "OPAQUE". [REQUIRED for the following cases: o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations] - Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.] - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations] Kent, Atkinson [Page 19] Internet Draft Security Architecture for IP March 1998 NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. - Source and Destination (e.g., TCP/UDP) Ports: These may be individual UDP or TCP port values or a wildcard port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Address fields), as an SA selector is sometimes referred to as "session-oriented keying."). Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD. Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- ESP ESP or ANY ANY (i.e., don't look at it) -don't care- ANY ANY (i.e., don't look at it) specific value specific value NOT ANY (i.e., drop packet) fragment specific value specific value actual port selector field not fragment If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported] The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy. Kent, Atkinson [Page 20] Internet Draft Security Architecture for IP March 1998 The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.) Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard dst addr single IP addr single IP addr single,range,wildcard xpt protocol* xpt protocol single,wildcard single,wildcard src port* single src port single,wildcard single,wildcard dst port* single dst port single,wildcard single,wildcard user id* single user id single,wildcard single,wildcard sec. labels single value single,wildcard single,wildcard * The SAD and SPD entries for these fields could be "OPAQUE" because the traffic value is encrypted. NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications. 4.4.3 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, before it creates an SA, the implementation should check to see if the SAD already has an appropriate SA (created by some other SPD entry). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This Kent, Atkinson [Page 21] Internet Draft Security Architecture for IP March 1998 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] For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". Note that for an ESP SA, the encryption algorithm or the authentication algorithm could be "NULL". However they MUST not both be "NULL". 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 Kent, Atkinson [Page 22] Internet Draft Security Architecture for IP March 1998 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. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations] NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends. (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded. o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations, unless implicitly defined by context] o Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic] 4.5 Basic Combinations of Security Associations This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in Kent, Atkinson [Page 23] Internet Draft Security Architecture for IP March 1998 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. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. Kent, Atkinson [Page 24] Internet Draft Security Architecture for IP March 1998 Case 2. This case illustrates simple virtual private networks support. =========================== | | ---------------------|---- ---|----------------------- | | | | | | | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Only tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following: Tunnel --------------------- 4. [IP2][AH][IP1][upper] 5. [IP2][ESP][IP1][upper] Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. =============================================================== | | | ========================= | | | | | ---|-----------------|---- ---|-------------------|--- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Kent, Atkinson [Page 25] Internet Draft Security Architecture for IP March 1998 Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway". ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server Only tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case 2. The choices for the SA between H1 and H2 would be one of the ones in case 1. Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application. As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. 4.6 SA and Key Management IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti- replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. Kent, Atkinson [Page 26] Internet Draft Security Architecture for IP March 1998 (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources. The following text describes the minimum requirements for both types of SA management. 4.6.1 Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. 4.6.2 Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed. When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because: Kent, Atkinson [Page 27] Internet Draft Security Architecture for IP March 1998 o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high- order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm. 4.6.3 Locating a Security Gateway This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter. Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues: 1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2? To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to Kent, Atkinson [Page 28] Internet Draft Security Architecture for IP March 1998 configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure: o the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host. o the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host. It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination host. This document does not address the issue of how to automate the discovery/verification of security gateways. 4.7 Security Associations and Multicast The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here. Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast cases are deferred to later IPsec documents. At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key Kent, Atkinson [Page 29] Internet Draft Security Architecture for IP March 1998 distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97]. 5. IP Traffic Processing The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order. 5.1 Outbound IP Traffic Processing 5.1.1 Selecting and Using an SA or SA Bundle In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST: 1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD. 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. Kent, Atkinson [Page 30] Internet Draft Security Architecture for IP March 1998 3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt. In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. 5.1.2 Header Construction for Tunnel Mode This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP": o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, (from the perspective of this tunnel), respectively. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.) o The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. o If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header. The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner). Kent, Atkinson [Page 31] Internet Draft Security Architecture for IP March 1998 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode <-- How Outer Hdr Relates to 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 constructed (2) 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. (The checksum changes when the TTL changes.) 3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header. 4. configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF. Kent, Atkinson [Page 32] Internet Draft Security Architecture for IP March 1998 5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS. 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode See previous section 5.1.2 for notes 1-5 indicated by (footnote number). <-- How Outer Hdr Relates Inner Hdr ---> Outer Hdr at Inner Hdr at IPv6 Encapsulator Decapsulator Header fields: -------------------- ------------ version 6 (1) no change class copied or configured (6) no change flow id copied or configured no change len constructed no change next header AH,ESP,routing hdr no change hop count constructed (2) decrement (2) src address constructed (3) no change dest address constructed (3) no change Extension headers never copied no change 6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. 5.2 Processing Inbound IP Traffic Prior to performing AH or ESP processing, any IP fragments are reassembled. Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context). Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service. 5.2.1 Selecting and Using an SA or SA Bundle Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are: 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the Kent, Atkinson [Page 33] Internet Draft Security Architecture for IP March 1998 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 selector value. (However, an AH or ESP-protected ICMP packet from a gateway may legitimately appear in a tunnel mode SA with a source IP address other than that bound to the SA, and thus such packets should be permitted as exceptions to this check. See Section 6.) Other packet fields MAY match the SA selector values as required by local policy. Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application. 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing. Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied. 5.2.2 Handling of AH and ESP tunnels The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1. Kent, Atkinson [Page 34] Internet Draft Security Architecture for IP March 1998 6. ICMP Processing (relevant to IPsec) The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion. An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA in which the message arrives. Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received. The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy. An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy. The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy. Kent, Atkinson [Page 35] Internet Draft Security Architecture for IP March 1998 6.1 PMTU/DF Processing 6.1.1 DF Bit In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) 6.1.2 Path MTU Discovery (PMTU) This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for: IPv4 (RFC 792): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 6.1.2.1 Propagation of PMTU The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.) o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PMTU information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the Kent, Atkinson [Page 36] Internet Draft Security Architecture for IP March 1998 originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging"). o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 6.1.2.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.) Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth. 6.1.2.3 Granularity of PMTU Processing In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.): a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol Kent, Atkinson [Page 37] Internet Draft Security Architecture for IP March 1998 stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally TOS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. 6.1.2.4 PMTU Aging In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. Kent, Atkinson [Page 38] Internet Draft Security Architecture for IP March 1998 7. Auditing Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 8. Use in Systems Supporting Information Flow Security Information of various sensitivity levels may be carried over a single network. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish such information. The use of labels facilitates segregation of information, in support of information flow security models, e.g., the Bell-LaPadula model [BL73]. Such models, and corresponding supporting techology, are designed to prevent the unauthorized flow of sensitive information, even in the face of Trojan Horse attacks. Conventional, discretionary access control (DAC) mechanisms, e.g., based on access control lists, generally are not sufficient to support such policies, and thus facilities such as the SPD do not suffice in such environments. In the military context, technology that supports such models is often referred to as multi-level security (MLS). Computers and networks often are designated "multi-level secure" if they support the separation of labelled data in conjunction with information flow security policies. Although such technology is more broadly applicable than just military applications, this document uses the acronym "MLS" to designate the technology, consistent with much extant literature. IPsec mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating. This section pertains only to the use of these IP security mechanisms in MLS (information flow security policy) environments. Nothing in this section applies to systems not claiming to provide MLS. As used in this section, "sensitivity information" might include Kent, Atkinson [Page 39] Internet Draft Security Architecture for IP March 1998 implementation-defined hierarchic levels, categories, and/or releasability information. AH can be used to provide strong authentication in support of mandatory access control decisions in MLS environments. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, AH can be used to authenticate the binding between sensitivity labels in the IP header and the IP payload (including user data). This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both. Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. ESP can be used, in conjunction with appropriate key management and encryption algorithms, in support of both DAC and MAC. (The choice of encryption and authentication algorithms, and the assurance level of an IPsec implementation will determine the environments in which an implementation may be deemed sufficient to satisfy MLS requirements.) Key management can make use of sensitivity information to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications. 8.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance". 8.2 Sensitivity Consistency Checking An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD Kent, Atkinson [Page 40] Internet Draft Security Architecture for IP March 1998 compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix. The checking SHOULD be done on both inbound and outbound processing. 8.3 Additional MLS Attributes for Security Association Databases Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute: - Sensitivity information. The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined. 8.4 Additional Inbound Processing Steps for MLS Networking After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it. The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific. 8.5 Additional Outbound Processing Steps for MLS Networking An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity Kent, Atkinson [Page 41] Internet Draft Security Architecture for IP March 1998 consistency checking described in section 8.2. 8.6 Additional MLS Processing for Security Gateways An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment. A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards. Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network. 9. Performance Issues The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per- association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts. The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances, this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may Kent, Atkinson [Page 42] Internet Draft Security Architecture for IP March 1998 be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic. Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet. Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols." 10. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. 11. Security Considerations The focus of this document is security; hence security considerations permeate this specification. 12. Differences from RFC 1825 This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management. Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's Kent, Atkinson [Page 43] Internet Draft Security Architecture for IP March 1998 NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security. For over 3 years (although it sometimes seems *much* longer), this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan. Kent, Atkinson [Page 44] Internet Draft Security Architecture for IP March 1998 Appendix A -- Glossary This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms. Access Control Access control is a security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled is often: o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network. Anti-replay [See "Integrity" below] Authentication This term is used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services. Availability Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability. Confidentiality Confidentiality is the security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also traffic analysis, below.) Kent, Atkinson [Page 45] Internet Draft Security Architecture for IP March 1998 Encryption Encryption is a security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption". Oftimes the term "encryption" is used to generically refer to both processes. Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service. Integrity Integrity is a security service that ensures that modifications to data are detectable. Integrity comes in various flavors to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem. Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP. Security Gateway A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either Kent, Atkinson [Page 46] Internet Draft Security Architecture for IP March 1998 directly or via another security gateway). SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, flow identifiers, etc. [Sch94] Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means. Kent, Atkinson [Page 47] Internet Draft Security Architecture for IP March 1998 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues B.1 DF bit In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments. B.2 Fragmentation Fragmentation MUST be done after outbound IPsec processing. Reassembly MUST be done before inbound IPsec processing. The general reasoning is shown below (delimited by the ****'s). NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer ********************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. Kent, Atkinson [Page 48] Internet Draft Security Architecture for IP March 1998 AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPsec processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B. 2. There are several places where IPsec could be implemented (as shown in the table above). a. Hosts with integration of IPsec into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPsec code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPsec into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) Kent, Atkinson [Page 49] Internet Draft Security Architecture for IP March 1998 IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Class,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Options? Options? Opt ? = AH covers Option-Type and Option-Length, but might not cover Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPsec processing, reassembles before inbound IPsec processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes Kent, Atkinson [Page 50] Internet Draft Security Architecture for IP March 1998 where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPsec module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPsec'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPsec module would have to check and let IPsec'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following Kent, Atkinson [Page 51] Internet Draft Security Architecture for IP March 1998 selectors from the packet -- SRC address, DST address, TOS/Class, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works ********************************************************************** B.3 Path MTU Discovery As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Rx = router x SGx = security gateway x X* = X supports IPsec Kent, Atkinson [Page 52] Internet Draft Security Architecture for IP March 1998 B.3.1 Identifying the Originating Host(s) The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. Kent, Atkinson [Page 53] Internet Draft Security Architecture for IP March 1998 original after IPsec ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), Seq number (32 bits) - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one or a small number of hosts. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, Kent, Atkinson [Page 54] Internet Draft Security Architecture for IP March 1998 if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B.3.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode) Socket 1 -------------------------| | Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A. B.3.3 Granularity of Maintaining PMTU Data In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues: a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same Kent, Atkinson [Page 55] Internet Draft Security Architecture for IP March 1998 granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction Kent, Atkinson [Page 56] Internet Draft Security Architecture for IP March 1998 of the largest amount of IPsec header used for any communication association between a given source and destination. B.3.4 Per Socket Maintenance of PMTU Data Implementation of the calculation of PMTU (Section B.2.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.2.3) is a local matter. However, a socket- based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. B.3.5 Delivery of PMTU Data to the Transport Layer The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). B.3.6 Aging of PMTU Data This topic is covered in Section 6.1.2.4. Kent, Atkinson [Page 57] Internet Draft Security Architecture for IP March 1998 Appendix C -- Sequence Space Window Code Example This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & ((u_long)1 << diff)) return 0; /* this packet already seen */ bitmap |= ((u_long)1 << diff); /* mark as seen */ return 1; /* out of order but good */ } char string_buffer[512]; Kent, Atkinson [Page 58] Internet Draft Security Architecture for IP March 1998 #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Kent, Atkinson [Page 59] Internet Draft Security Architecture for IP March 1998 Appendix D -- Categorization of ICMP messages The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6. IPv4 Type Name/Codes Reference ========================================================================= HOST GENERATED: 3 Destination Unreachable 2 Protocol Unreachable [RFC792] 3 Port Unreachable [RFC792] 8 Source Host Isolated [RFC792] 14 Host Precedence Violation [RFC1812] 10 Router Selection [RFC1256] Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 3 Destination Unreachable 0 Net Unreachable [RFC792] 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 5 Source Route Failed [RFC792] 6 Destination Network Unknown [RFC792] 7 Destination Host Unknown [RFC792] 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 11 Destination Network Unreachable for Type of Service [RFC792] 5 Redirect 0 Redirect Datagram for the Network (or subnet) [RFC792] 2 Redirect Datagram for the Type of Service & Network [RFC792] 9 Router Advertisement [RFC1256] 18 Address Mask Reply [RFC950] Kent, Atkinson [Page 60] Internet Draft Security Architecture for IP March 1998 IPv4 Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 0 Echo Reply [RFC792] 3 Destination Unreachable 1 Host Unreachable [RFC792] 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 12 Destination Host Unreachable for Type of Service [RFC792] 13 Communication Administratively Prohibited [RFC1812] 15 Precedence cutoff in effect [RFC1812] 4 Source Quench [RFC792] 5 Redirect 1 Redirect Datagram for the Host [RFC792] 3 Redirect Datagram for the Type of Service and Host [RFC792] 6 Alternate Host Address [JBP] 8 Echo [RFC792] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792,RFC1108] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request [RFC950] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [Johnson] 39 SKIP [Markson] 40 Photuris [Simpson] Type Name/Codes Reference ========================================================================= UNASSIGNED TYPE OR UNKNOWN GENERATOR: 1 Unassigned [JBP] 2 Unassigned [JBP] 7 Unassigned [JBP] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 33 IPv6 Where-Are-You [Simpson] 34 IPv6 I-Am-Here [Simpson] 35 Mobile Registration Request [Simpson] 36 Mobile Registration Reply [Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 41-255 Reserved [JBP] Kent, Atkinson [Page 61] Internet Draft Security Architecture for IP March 1998 IPv6 Type Name/Codes Reference ========================================================================= HOST GENERATED: 1 Destination Unreachable [RFC 1885] 4 Port Unreachable Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 1 Destination Unreachable [RFC1885] 0 No Route to Destination 1 Comm. w/Destination is Administratively Prohibited 2 Not a Neighbor 3 Address Unreachable 2 Packet Too Big [RFC1885] 0 3 Time Exceeded [RFC1885] 0 Hop Limit Exceeded in Transit 1 Fragment reassembly time exceeded Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 4 Parameter Problem [RFC1885] 0 Erroneous Header Field Encountered 1 Unrecognized Next Header Type Encountered 2 Unrecognized IPv6 Option Encountered Kent, Atkinson [Page 62] Internet Draft Security Architecture for IP March 1998 References [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, DDN Network Information Center, October 1994. [HC98] D. Harkins & D. Carrel, "The Internet Key Exchange (IKE)", Internet Draft, February 1998. [HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio [KA98a] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1998. [KA98b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, March 1998. [Ken91] Steve Kent, "US DoD Security Options for the Internet Kent, Atkinson [Page 63] Internet Draft Security Architecture for IP March 1998 Protocol", RFC-1108, DDN Network Information Center, November 1991. [MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Internet Draft, March 1998. [Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol", Internet Draft, July 1997. [Pip98] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", Internet Draft, February 1998. [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", Internet Draft, December 1997. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. Disclaimer The views and specification expressed in this document are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design. Kent, Atkinson [Page 64] Internet Draft Security Architecture for IP March 1998 Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway Redwood City, CA 94063 USA E-mail: rja@corp.home.net Telephone: +1 (415) 569-5000 Copyright (C) The Internet Society (March 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 65] From owner-ipsec Fri Mar 13 16:56:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12626 for ipsec-outgoing; Fri, 13 Mar 1998 16:56:07 -0500 (EST) Message-Id: <199803132034.MAA24565@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: new IKE draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Mar 1998 12:34:16 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The next rev of the IKE draft, draft-ietf-ipsec-isakmp-oakley-07.txt, has been sent to the IETF secretariat and should appear in the repositories shortly. Here's a list of the changes that made version 6 become version 7 followed by the new draft itself. cheers, Dan. -------------------------------------------------------------------------- 1. removed extranneous nroff (Appendix A) 23 Feb email from Hugh Redelmeier 2. fixed misc. spelling mistakes (throughout draft) 19 Feb email from Derrell Piper 3. mention that it is possible to have multiple simultaneous Quick Modes (section 5.5) 26 Feb email from Matt Thomas 4. noted that the IV should not be updated until the message passes a sanity check and is not a retransmission (Security Considerations) 26 Feb email from Matt Thomas 5. it's "Identification Payload"! (section 3.2) 23 Feb email from Hugh Redelmeier 6. mention that the size of the Diffie-Hellman public value depends on the group negotiated and must be pre-pended with zeros to force the issue if necessary (section 5) bakeoff issue 7. impose limits on the size of nonces: 8 <= len(nonce) <= 256 (section 5) 3 March email from Tero Kivinen and 4 March email from Hilarie Orman 8. mention that a Certificate Request payload can not extend the number of messages in an IKE exchange (section 5) bakeoff issue and 20 Feb email from Roy Pereira 9. impose cryptographic strength requirements on new hash algorithms before a value is given by IANA (IANA Considerations) addition by author 10. Noted that the illustrative example of the hash payloads in Quick Mode can differ if optional payloads (e.g. notify payloads) are chained to the message (section 5.5) 12 Mar phone conversation with Derrell Piper 11. Mention that a substitution attack on payloads in the final encrypted message of Main Mode may not be detected if optional (e.g. notify) payloads are chained onto the message (Security Considerations) 12 Mar phone conversation with Derrell Piper 12. Change text regarding IDci and IDcr in Quick Mode. Due to the lack of response to Shawn Mamros's last post the content of the optional notify message was not specified (section 5.5) 3 Mar email from Shawn Mamros, 3 Mar response from Paul Koning and 5 Mar email from Shawn Mamros. 13. Added even more text to make it clear (hopefully) that RSA signature encoding is not PKCS #1 signatures, it's PKCS #1 private key encryption. (section 5.1) bakeoff issue -------------------------------------------------------------------------- IPSEC Working Group D. Harkins, D. Carrel INTERNET-DRAFT cisco Systems draft-ietf-ipsec-isakmp-oakley-07.txt March 1998 The Internet Key Exchange (IKE) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table Of Contents 1 Abstract 2 Discussion 3 Terms and Definitions 3.1 Requirements Terminology 3.2 Notation 3.3 Perfect Forward Secrecty 3.4 Security Association 4 Introduction 5 Exchanges 5.1 Authentication with Digital Signatures 5.2 Authentication with Public Key Encryption 5.3 A Revised method of Authentication with Public Key Encryption 5.4 Authentication with a Pre-Shared Key 5.5 Quick Mode 5.6 New Group Mode 5.7 ISAKMP Informational Exchanges 6 Oakley Groups Harkins, Carrel [Page 1] INTERNET DRAFT March 1998 6.1 First Oakley Group 6.2 Second Oakley Group 6.3 Third Oakley Group 6.4 Fourth Oakley Group 7 Payload Explosion of Complete Exchange 7.1 Phase 1 with Main Mode 7.2 Phase 2 with Quick Mode 8 Perfect Forward Secrecy Example 9 Implementation Hints 10 Security Considerations 11 IANA Considerations 12 Acknowledgments 13 References Appendix A Appendix B 1. Abstract [MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Harkins, Carrel [Page 2] INTERNET DRAFT March 1998 2. Discussion This draft describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. Processes which implement this draft can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network. Client negotiation is supported. Client mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in client mode, the identities of the end parties remain hidden. This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol. Likewise, this does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces. This protocol is not dependant in any way on the SKEME protocol. 3. Terms and Definitions 3.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 3.2 Notation The following notation is used throughout this draft. HDR is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption. SA is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.

_b indicates the body of payload

-- the ISAKMP generic payload is not included. Harkins, Carrel [Page 3] INTERNET DRAFT March 1998 SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator. CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header. g^xi and g^xr are the Diffie-Hellman public values of the initiator and responder respectively. g^xy is the Diffie-Hellman shared secret. KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g. a TLV) used for the data of a KE payload. Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and responder respectively. IDx is the identification payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. SIG is the signature payload. The data to sign is exchange- specific. CERT is the certificate payload. HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. The contents of the hash are specific to the authentication method. prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]). SKEYID is a string derived from secret material known only to the active players in the exchange. SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages. SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages. Harkins, Carrel [Page 4] INTERNET DRAFT March 1998 SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations. y indicates that "x" is encrypted with the key "y". --> signifies "initiator to responder" communication (requests). <-- signifies "responder to initiator" communication (replies). | signifies concatenation of information-- e.g. X | Y is the concatentation of X with Y. [x] indicates that x is optional. Message encryption (when noted by a '*' after the ISAKMP header) MUST begin immediately after the ISAKMP header. When communication is protected, all payloads following the ISAKMP header MUST be encrypted. Encryption keys are generated from SKEYID_e in a manner that is defined for each algorithm. 3.3 Perfect Forward Secrecy When used in the draft Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys. Perfect Forward Secrecy for both keys and identities is provided in this protocol. (Sections 5.5 and 8). 3.4 Security Association A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. 4. Introduction Oakley and SKEME each define a method to establish an authenticated key exchange. This includes payloads construction, the information payloads carry, the order in which they are processed and how they are used. While Oakley defines "modes", ISAKMP defines "phases". The Harkins, Carrel [Page 5] INTERNET DRAFT March 1998 relationship between the two is very straightforward and IKE presents different exchanges as modes which operate in one of two phases. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" MUST ONLY be used in phase 1. Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. "New Group Mode" is not really a phase 1 or phase 2. It follows phase 1, but serves to establish a new group which can be used in future negotiations. "New Group Mode" MUST ONLY be used after phase 1. The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes. With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. "Main Mode" for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further. Developer hints for doing these optimizations are included below. It should also be noted that using public key encryption to authenticate an Aggressive Mode exchange will still provide identity protection. This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non- ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an Harkins, Carrel [Page 6] INTERNET DRAFT March 1998 ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST98] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA. If a DOI of zero is used for establishment of a phase 1 SA, the syntax of the identity payloads used in phase 1 is that defined in [MSST98] and not from any DOI-- e.g. [Pip97]-- which may further expand the syntax and semantics of identities. The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.) - encryption algorithm (e.g. DES, IDEA, Blowfish). - hash algorithm (e.g. MD5, SHA) - authentication method (e.g. DSS sig, RSA sig, RSA encryption, pre-shared key) - information about a group over which to do Diffie-Hellman. All of these attributes are mandatory and MUST be negotiated. In addition, it is possible to optionally negotiate a psuedo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties). If a "prf" is not negotiation, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non- mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes. The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.6). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange). IKE implementations MUST support the following attribute values: - DES-CBC with a weak, and semi-weak, key check (weak and semi- weak keys are referenced in [Sch96] and listed in Appendix A). The key is derived according to Appendix B. Harkins, Carrel [Page 7] INTERNET DRAFT March 1998 - MD5 and SHA. - Authentication via pre-shared keys. The Digital Signature Standard SHOULD be supported; RSA-- both signatures and authentication with public key encryption-- SHOULD be supported. - MODP over the default group (see below). ECP and EC2N groups MAY be supported. The IKE modes described here MUST be implemented whenever the IETF IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes described here. 5. Exchanges There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be implemented. In addition, Quick Mode MUST be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. In addition, New Group Mode SHOULD be implemented as a mechanism to define private groups for Diffie-Hellman exchanges. Implementations MUST NOT switch exchange types in the middle of an exchange. Exchanges conform to standard ISAKMP [MSST98] payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.g a notify response is sent when, for example, a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc. The SA payload MUST precede all other payloads in a phase 1 exchange. Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order. The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros. The length of nonce payload MUST be between 8 and 256 bytes inclusive. Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange. The authentication method Harkins, Carrel [Page 8] INTERNET DRAFT March 1998 negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose. The XCHG for Main Mode is ISAKMP Identity Protect. Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY NOT be sent under protection of the ISAKMP SA allowing each party to postpone exponentiation, if desired, until negotiation of this exchange is complete. The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be. Exchanges in IKE are not open ended and have a fixed number of messages. Receipt of a Certificate Request payload MUST NOT extend the number of messages transmitted or expected. Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated. For situations where the rich attribute negotiation capabilities of IKE are required Main Mode may be required. Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG values for Quick Mode and New Group Mode are defined in Appendix A. Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. Security Association offers take the form of Tranform Payload(s) encapsulated in Proposal Payload(s) encapsulated in Security Association (SA) payload(s). If multiple offers are being made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST take the form of multiple Transform Payloads for a single Proposal Payload in a single SA payload. To put it another way, for phase 1 exchanges there MUST NOT be multiple Proposal Payloads for a single SA payload and there MUST NOT be multiple SA payloads. This document does not proscribe such behavior on offers in phase 2 exchanges. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons. Harkins, Carrel [Page 9] INTERNET DRAFT March 1998 During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method. For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B). To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption (if the algorithm supports it). Following are Harkins, Carrel [Page 10] INTERNET DRAFT March 1998 Phase 1 exchanges with different authentication options. 5.1 IKE Phase 1 Authenticated With Signatures Using signatures, the ancillary information exchanged during the second roundtrip are nonces; the exchange is authenticated by signing a mutually obtainable hash. Main Mode with signature authentication is described as follows: Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In general the signature will be over HASH_I and HASH_R as above using the negotiated prf, or the HMAC version of the negotiated hash function (if no prf is negotiated). However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e.g. DSS is only defined with SHA's 160 bit output). In this case, the signature will be over HASH_I and HASH_R as above, except using the HMAC version of the hash algorithm associated with the signature method. The negotiated prf and hash function would continue to be used for all other prescribed pseudo- random functions. Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format and not as a signature in PKCS #1 Harkins, Carrel [Page 11] INTERNET DRAFT March 1998 format (which includes the OID of the hash algorithm). DSS signatures MUST be encoded as r followed by s. One or more certificate payloads MAY be optionally passed. 5.2 Phase 1 Authenticated With Public Key Encryption Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange. In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained. In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's public key. If the authentication method is public key encryption, the nonce and identity payloads MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear. When using encryption for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Harkins, Carrel [Page 12] INTERNET DRAFT March 1998 Pubkey_r, Pubkey_r --> HDR, SA, KE, PubKey_i, <-- PubKey_i, HASH_R HDR, HASH_I --> Where HASH(1) is a hash (using the negotiated hash function) of the certificate which the initiator is using to encrypt the nonce and identity. RSA encryption MUST be encoded in PKCS #1 format. While only the body of the ID and nonce payloads is encrypted, the encrypted data must be preceded by a valid ISAKMP generic header. The payload length is the length of the entire encrypted payload plus header. The PKCS #1 encoding allows for determination of the actual length of the cleartext payload upon decryption. Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. This exchange was motivated by [Kra96]. Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode. 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption Authentication with Public Key Encryption has significant advantages over authentication with signatures (see section 5.2 above). Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations. In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. Harkins, Carrel [Page 13] INTERNET DRAFT March 1998 As with the public key encryption method of authentication (section 5.2), a HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e.g. if the certificate is not for signatures only, either due to certificate restrictions or algorithmic restrictions). If the HASH payload is sent it MUST be the first payload of the second message exchange and MUST be followed by the encrypted nonce. If the HASH payload is not sent, the first payload of the second message exchange MUST be the encrypted nonce. In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond. When using the revised encryption mode for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i, [<Ke_i] --> HDR, PubKey_i, Ke_r, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with the revised encryption method is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] Pubkey_r, Ke_i, Ke_i [, Ke_i ] --> HDR, SA, PubKey_i, Ke_r, Ke_r, <-- HASH_R HDR, HASH_I --> where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to the symmetric encryption algorithm negotiated in the SA payload exchange. Only the body of the payloads are encrypted (in both public key and symmetric operations), the generic payload headers are left Harkins, Carrel [Page 14] INTERNET DRAFT March 1998 in the clear. The payload length includes that added to perform encryption. The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed: Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R) The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. If the length of the output of the negotiated prf is greater than or equal to the key length requirements of the cipher, Ke_i and Ke_r are derived from the most significant bits of Ne_i and Ne_r respectively. If the desired length of Ke_i and Ke_r exceed the length of the output of the prf the necessary number of bits is obtained by repeatedly feeding the results of the prf back into itself and concatenating the result until the necessary number has been achieved. For example, if the negotiated encryption algorithm requires 320 bits of key and the output of the prf is only 128 bits, Ke_i is the most significant 320 bits of K, where K = K1 | K2 | K3 and K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) K3 = prf(Ne_i, K2) For brevity, only derivation of Ke_i is shown; Ke_r is identical. The length of the value 0 in the computation of K1 is a single octet. Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be discarded after use. Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements. All payloads-- in whatever order-- following the encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the direction. If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce is set to 0 (zero). The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be Harkins, Carrel [Page 15] INTERNET DRAFT March 1998 padding. 5.4 Phase 1 Authenticated With a Pre-Shared Key A key derived by some out-of-band mechanism may also be used to authenticate the exchange. The actual establishment of this key is out of the scope of this document. When doing a pre-shared key authentication, Main Mode is defined as follows: Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R Aggressive mode with a pre-shared key is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. 5.5 Phase 2 - Quick Mode Quick Mode is not a complete exchange itself (in that it is bound to a phase 1 exchange), but is used as part of the SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs. The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. This HASH authenticates the message and also provides liveliness proofs. Harkins, Carrel [Page 16] INTERNET DRAFT March 1998 The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. Since each instance of a Quick Mode uses a unique initialization vector (see Appendix B) it is possible to have multiple simultaneous Quick Modes, based off a single ISAKMP SA, in progress at any one time. Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. While use of the key exchange payload with Quick Mode is optional it MUST be supported. Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material. The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation. Quick Mode is defined as follows: Initiator Responder ----------- ----------- Harkins, Carrel [Page 17] INTERNET DRAFT March 1998 HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. HASH(3)-- for liveliness-- is the prf over the value zero represented as a single octet, followed by a concatenation of the message id and the two nonces-- the initiator's followed by the responder's-- minus the payload header. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example or if any optional payloads, for example a notify payload, have been chained to the message. If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode. In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. A single SA negotiation results in two security assocations-- one Harkins, Carrel [Page 18] INTERNET DRAFT March 1998 inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words, KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. This keying material (whether with PFS or without, and whether derived directly or through concatenation) MUST be used with the negotiated SA. It is up to the service to define how keys are derived from the keying material. In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, the exponential (g(qm)^xy) is irretreivably removed from the current state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) continue to protect and authenticate the ISAKMP SA and SKEYID_d continues to be used to derive keys. Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> The keying material is derived identically as in the case of a single SA. In this case (negotiation of two SA payloads) the result would be four security associations-- two each way for both SAs. 5.6 New Group Mode New Group Mode MUST NOT be used prior to establishment of an ISAKMP Harkins, Carrel [Page 19] INTERNET DRAFT March 1998 SA. The description of a new group MUST only follow phase 1 negotiation. (It is not a phase 2 exchange, though). Initiator Responder ----------- ----------- HDR*, HASH(1), SA --> <-- HDR*, HASH(2), SA where HASH(1) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the entire SA proposal, body and header, as the data; HASH(2) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the reply as the data. In other words the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA) HASH(2) = prf(SKEYID_a, M-ID | SA) The proposal will specify the characteristics of the group (see appendix A, "Attribute Assigned Numbers"). Group descriptions for private Groups MUST be greater than or equal to 2^15. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). ISAKMP implementations MAY require private groups to expire with the SA under which they were established. Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. 5.7 ISAKMP Informational Exchanges This protocol protects ISAKMP Informational Exchanges when possible. Once the ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated) ISAKMP Information Exchanges, when used with this protocol, are as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete Harkins, Carrel [Page 20] INTERNET DRAFT March 1998 Payload and HASH(1) is the prf output, using SKEYID_a as the key, and a M-ID unique to this exchange concatenated with the entire informational payload (either a Notify or Delete) as the data. In other words, the hash for the above exchange is: HASH(1) = prf(SKEYID_a, M-ID | N/D) As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. The derivation of the initialization vector, used with SKEYID_e to encrypt this message, is described in Appendix B. If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload. 6 Oakley Groups With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. Four groups-- values 1 through 4-- are defined below. These groups originated with the Oakley protocol and are therefore called "Oakley Groups". The attribute class for "Group" is defined in Appendix A. All values 2^15 and higher are used for private group identifiers. For a discussion on the strength of the default Oakley groups please see the Security Considerations section below. 6.1 First Oakley Default Group Oakley implementations MUST support a MODP group with the following prime and generator. This group is assigned id 1 (one). The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is: 2. 6.2 Second Oakley Group IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 2 (two). Harkins, Carrel [Page 21] INTERNET DRAFT March 1998 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2 (decimal) 6.3 Third Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 3 (three). The curve is based on the Galois Field GF[2^155]. The field size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 155 Group Prime/Irreducible Polynomial: 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f Group Order: 0X0800000000000000000057db5698537193aef944 The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). 6.4 Fourth Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 4 (four). The curve is based on the Galois Field GF[2^185]. The field size is 185. The irreducible polynomial for the field is: Harkins, Carrel [Page 22] INTERNET DRAFT March 1998 u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc The data in the KE payload when using this group will be identical to that as when using Oakley Group 3 (three). Other groups can be defined using New Group Mode. These default groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. 7. Payload Explosion for a Complete IKE Exchange This section illustrates how the IKE protocol is used to: - establish a secure and authenticated channel between ISAKMP processes (phase 1); and - generate key material for, and negotiate, an IPsec SA (phase 2). Harkins, Carrel [Page 23] INTERNET DRAFT March 1998 7.1 Phase 1 using Main Mode The following diagram illustrates the payloads exchanged between the two parties in the first round trip exchange. The initiator MAY propose several proposals; the responder MUST reply with one. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_SA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ prefered SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ alternate SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The responder replies in kind but selects, and returns, one transform proposal (the ISAKMP SA attributes). Harkins, Carrel [Page 24] INTERNET DRAFT March 1998 The second exchange consists of the following payloads: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_KE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The shared keys, SKEYID_e and SKEYID_a, are now used to protect and authenticate all further communication. Note that both SKEYID_e and SKEYID_a are unauthenticated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_ID and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SIG ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data of the ISAKMP negotiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ signature verified by the public key of the ID above ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The key exchange is authenticated over a signed hash as described in section 5.1. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. (For brevity, certificate payloads were not exchanged). 7.2 Phase 2 using Quick Mode The following payloads are exchanged in the first round of Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested authentication. Harkins, Carrel [Page 25] INTERNET DRAFT March 1998 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ keyed hash of message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! AH_MD5 | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of source for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of destination for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. The responder replies with a similar message which only contains one Harkins, Carrel [Page 26] INTERNET DRAFT March 1998 transform-- the selected AH transform. Upon receipt, the initiator can provide the key engine with the negotiated security association and the keying material. As a check against replay attacks, the responder waits until receipt of the next message. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. 8 Perfect Forward Secrecy Example This protocol can provide PFS of both keys and identities. The identies of both the ISAKMP negotiating peer and, if applicable, the identities for whom the peers are negotiating can be protected with PFS. To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following: o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state. Since the key for use in the non-ISAKMP SA was derived from the single ephemeral Diffie-Hellman exchange PFS is preserved. To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP security association, it in not necessary to do a phase 1 exchange if an ISAKMP SA exists between the two peers. A single Quick Mode in which the optional KE payload is passed, and an additional Diffie- Hellman exchange is performed, is all that is required. At this point the state derived from this Quick Mode must be deleted from the ISAKMP SA as described in section 5.5. Harkins, Carrel [Page 27] INTERNET DRAFT March 1998 9. Implementation Hints Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as the Phase 1 state remains cached, and PFS is not needed, Phase 2 can proceed without any exponentiation. How many Phase 2 negotiations can be performed for a single Phase 1 is a local policy issue. The decision will depend on the strength of the algorithms being used and level of trust in the peer system. An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. An optimization that is often useful is to establish Security Associations with peers before they are needed so that when they become needed they are already in place. This ensures there would be no delays due to key management before initial data transmission. This optimization is easily implemented by setting up more than one Security Association with a peer for each requested Security Association and caching those not immediately used. Also, if an ISAKMP implementation is alerted that a SA will soon be needed (e.g. to replace an existing SA that will expire in the near future), then it can establish the new SA before that new SA is needed. The base ISAKMP specification describes conditions in which one party of the protocol may inform the other party of some activity-- either deletion of a security association or in response to some error in the protocol such as a signature verification failed or a payload failed to decrypt. It is strongly suggested that these Informational exchanges not be responded to under any circumstances. Such a condition may result in a "notify war" in which failure to understand a message results in a notify to the peer who cannot understand it and sends his own notify back which is also not understood. 10. Security Considerations This entire draft discusses a hybrid protocol, combining parts of Oakley and parts of SKEME with ISAKMP, to negotiate, and derive keying material for, security associations in a secure and authenticated manner. Harkins, Carrel [Page 28] INTERNET DRAFT March 1998 Confidentiality is assured by the use of a negotiated encryption algorithm. Authentication is assured by the use of a negotiated method: a digital signature algorithm; a public key algorithm which supports encryption; or, a pre-shared key. The confidentiality and authentication of this exchange is only as good as the attributes negotiated as part of the ISAKMP security association. Repeated re-keying using Quick Mode can consume the entropy of the Diffie- Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This draft does not prescribe such a limit. Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. The default Diffie-Hellman group (number one) when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for DES. Groups two through four provide greater security. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE which prohibits using stronger groups nor is there anything which will dilute the strength obtained from stronger groups. In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups will greatly increase strength using much smaller numbers. For situations where defined groups provide insufficient strength New Group Mode can be used to exchange a Diffie-Hellman group which provides the necessary strength. In is incumbent upon implementations Harkins, Carrel [Page 29] INTERNET DRAFT March 1998 to check the primality in groups being offered and independently arrive at strength estimates. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents must not be derived from long-lived secrets like the seed to a pseudo-random generator. IKE exchanges maintain running initialization vectors (IV) where the last ciphertext block of the last message is the IV for the next message. To prevent retransmissions (or forged messages with valid cookies) from causing exchanges to get out of sync IKE implementations SHOULD NOT update their running IV until the decrypted message has passed a basic sanity check and has been determined to actually advance the IKE state machine-- i.e. it is not a retransmission. While the last roundtrip of Main Mode (and optionally the last message of Aggressive Mode) is encrypted it is not, strictly speaking, authenticated. An active substitution attack on the ciphertext could result in payload corruption. If such an attack corrupts mandatory payloads it would be detected by an authentication failure, but if it corrupts any optional payloads (e.g. notify payloads chained onto the last message of a Main Mode exchange) it might not be detectable. 11. IANA Considerations This document contains many "magic numbers" to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. 11.1 Attribute Classes Attributes negotiated in this protocol are identified by their class. Requests for assignment of new classes must be accompanied by a standards- track RFC which describes the use of this attribute. 11.2 Encryption Algorithm Class Values of the Encryption Algorithm Class define an encryption algorithm to use when called for in this document. Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. 11.3 Hash Algorithm Values of the Hash Algorithm Class define a hash algorithm to use when called for in this document. Requests for assignment of new hash algorithm values must be accompanied by a reference to a standards- track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. Due to the key derivation and key expansion uses of HMAC forms of hash algorithms in IKE, Harkins, Carrel [Page 30] INTERNET DRAFT March 1998 requests for assignment of new hash algorithm values must take into account the cryptographic properties-- e.g it's resistance to collision-- of the hash algorithm itself. 11.4 Group Description and Group Type Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type. 11.5 Life Type Values of the Life Type Class define a type of lifetime to which the ISAKMP Security Association applies. Requests for assignment of new life types must be accompanied by a detailed description of the units of this type and its expiry. 12. Acknowledgements This document is the result of close consultation with Hugo Krawczyk, Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and Jeff Turner. It relies on protocols which were written by them. Without their interest and dedication, this would not have been written. Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, and Elfed Weaver for technical input, encouragement, and various sanity checks along the way. We would also like to thank the many members of the IPSec working group that contributed to the development of this protocol over the past year. 13. References [Acm97] Adams, C.M., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. Harkins, Carrel [Page 31] INTERNET DRAFT March 1998 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 2, draft-ietf-ipsec-oakley-02.txt [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 8, draft-ietf-ipsec-ipsec-doi-08.txt. [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. Harkins, Carrel [Page 32] INTERNET DRAFT March 1998 Appendix A This is a list of DES Weak and Semi-Weak keys. The keys come from [Sch96]. All keys are listed in hexidecimal. DES Weak Keys 0101 0101 0101 0101 1F1F 1F1F E0E0 E0E0 E0E0 E0E0 1F1F 1F1F FEFE FEFE FEFE FEFE DES Semi-Weak Keys 01FE 01FE 01FE 01FE 1FE0 1FE0 0EF1 0EF1 01E0 01E0 01F1 01F1 1FFE 1FFE 0EFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE F1FE FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 F101 FE1F FE1F FE0E FE0E 1F01 1F01 0E01 0E01 FEE0 FEE0 FEF1 FEF1 Attribute Assigned Numbers Attributes negotiated during phase one use the following definitions. Phase two attributes are defined in the applicable DOI specification (for example, IPsec attributes are defined in the IPsec DOI), with the exception of a group description when Quick Mode includes an ephemeral Diffie-Hellman exchange. Attribute types can be either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the base ISAKMP specification as Type/Value (Basic) and Type/Length/Value (Variable). Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. If this is the case, an attribute offered as variable (or basic) by the initiator of this protocol MAY be returned to the initiator as a basic (or variable). Harkins, Carrel [Page 33] INTERNET DRAFT March 1998 Attribute Classes class value type ------------------------------------------------------------------- Encryption Algorithm 1 B Hash Algorithm 2 B Authentication Method 3 B Group Description 4 B Group Type 5 B Group Prime/Irreducible Polynomial 6 V Group Generator One 7 V Group Generator Two 8 V Group Curve A 9 V Group Curve B 10 V Life Type 11 B Life Duration 12 V PRF 13 B Key Length 14 B Field Size 15 B Group Order 16 V values 17-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. Class Values - Encryption Algorithm DES-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Hash Algorithm MD5 1 SHA 2 Tiger 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Authentication Method pre-shared key 1 DSS signatures 2 Harkins, Carrel [Page 34] INTERNET DRAFT March 1998 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 values 6-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Group Description default 768-bit MODP group (section 6.1) 1 alternate 1024-bit MODP group (section 6.2) 2 EC2N group on GP[2^155] (section 6.3) 3 EC2N group on GP[2^185] (section 6.4) 4 values 5-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties. - Group Type MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Life Type seconds 1 kilobytes 2 values 3-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected. - PRF There are currently no pseudo-random functions defined. values 1-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Key Length When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Harkins, Carrel [Page 35] INTERNET DRAFT March 1998 Encryption Algorithm uses a fixed length key. - Field Size The field size, in bits, of a Diffie-Hellman group. - Group Order The group order of an elliptical curve group. Note the length of this attribute depends on the field size. Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Harkins, Carrel [Page 36] INTERNET DRAFT March 1998 Appendix B This appendix describes encryption details to be used ONLY when encrypting ISAKMP messages. When a service (such as an IPSEC transform) utilizes ISAKMP to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. ISAKMP does not purport to ever produce keys that are suitable for any encryption algorithm. ISAKMP produces the requested amount of keying material from which the service MUST generate a suitable key. Details, such as weak key checks, are the responsibility of the service. Use of negotiated PRFs may require the PRF output to be expanded due to the PRF feedback mechanism employed by this document. For example, if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces only 8 bytes of output, the output must be expanded three times before being used as the key for another instance of itself. The output of a PRF is expanded by feeding back the results of the PRF into itself to generate successive blocks. These blocks are concatenated until the requisite number of bytes has been acheived. For example, for pre-shared key authentication with DOORAK-MAC as the negotiated PRF: BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) and SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 so therefore to derive SKEYID_d: BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) and SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 Subsequent PRF derivations are done similarly. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e Harkins, Carrel [Page 37] INTERNET DRAFT March 1998 only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the ciphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. After the ISAKMP SA has been authenticated all Informational Exchanges are encrypted using SKEYID_e. The initiaization vector for these exchanges is derived in exactly the same fashion as that for a Quick Mode-- i.e. it is derived from a hash of a concatenation of the last phase 1 CBC output block and the message id from the ISAKMP header of the Informational Exchange (not the message id from the message that may have prompted the Informational Exchange). Note that the final phase 1 CBC output block, the result of encryption/decryption of the last phase 1 message, must be retained in the ISAKMP SA state to allow for generation of unique IVs for each Quick Mode. Each post- phase 1 exchange (Quick Modes and Informational Exchanges) generates IVs independantly to prevent IVs from getting out of sync when two different exchanges are started Harkins, Carrel [Page 38] INTERNET DRAFT March 1998 simultaneously. In all cases, there is a single bidirectional cipher/IV context. Having each Quick Mode and Informational Exchange maintain a unique context prevents IVs from getting out of sync. The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above. The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material derived above. The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. The key for RC5-R16-B64-CBC is the negotiated key size, or the first sixteen (16) bytes of a key (if no key size is negotiated) derived from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived above. The number of rounds MUST be 16 and the block size MUST be 64. The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV is the first eight (8) bytes of the IV material derived above. The key for CAST-CBC is either the negotiated key size, or the first sixteen (16) bytes of a key derived in the aforementioned pseudo- random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. Support for algorithms other than DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims. Harkins, Carrel [Page 39] INTERNET DRAFT March 1998 Authors' Addresses: Dan Harkins cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America +1 408 526 4000 Dave Carrel 76 Lippard Ave. San Francisco, CA 94131-2947 United States of America +1 415 337 8469 Authors' Note: The authors encourage independent implementation, and interoperability testing, of this hybrid protocol. Harkins, Carrel [Page 40] From owner-ipsec Sat Mar 14 09:39:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18510 for ipsec-outgoing; Sat, 14 Mar 1998 09:36:11 -0500 (EST) Message-Id: <199803141449.JAA29839@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 14 Mar 1998 09:39:54 -0500 To: Daniel Harkins From: Matt Thomas Subject: Re: new IKE draft Cc: ipsec@tis.com In-Reply-To: <199803132034.MAA24565@dharkins-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >7. impose limits on the size of nonces: 8 <= len(nonce) <= 256 (section 5) > 3 March email from Tero Kivinen and 4 March email from Hilarie Orman Just one question, in the the RSA Encryption modes don't the nonces need to be smaller than the RSA modulus (so they can be encrypted/decrypted)? (Also what happens in the non-Revised mode if the identification payload is larger than what can be encrypted via the RSA modulus?) Also, in the RSA Encryption modes you can specify a hash of the certificate you are using. How do you calculate the hash (since you have not finished negotiating the hash algorithm)? -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sat Mar 14 15:18:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22222 for ipsec-outgoing; Sat, 14 Mar 1998 15:14:07 -0500 (EST) Message-Id: <98Mar14.152742est.11650@janus.tor.securecomputing.com> To: "Patel, Baiju V" Cc: rob.glenn@nist.gov, ipsec@tis.com Subject: Re: ESP_NULL internet draft submitted References: In-reply-to: Your message of "Fri, 13 Mar 1998 14:57:20 -0500". From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <443.889907226.1@gamera.tornd.securecomputing.com> Date: Sat, 14 Mar 1998 15:27:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Patel, Baiju V" writes: > > 1. Should the pad length field be present and set to 0 or omitted? > 2. This will mean that the authentication data will not be at > 4 or 8 byte boundary The ESP master document (draft-ietf-ipsec-esp-v2-03.txt) covers both of these cases. Specifically, padding is always required when authentication is in use: (From 2.4 Padding (for Encryption): o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. and the pad length field is *always* required: 2.5 Pad Length The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that no Padding bytes are present. The Pad Length field is mandatory. > Section 2.1 suggests that we can use keys of non-zero length. > > [ snip ] > > Section 3 requires that key length is 0. One of the two should be > changed to avoid confusion. > > 3. ESP_NULL Operational Requirements > > For purposes of IKE [IKE] key extraction, the key size for this > algorithm MUST be zero (0) bits, to facilitate interoperability and > to avoid any potential export control problems. No. This is fine. Section 3 requires a key length of 0 *when ESP-NULL is negotiated under IKE*. Under section 2.1, *manually* keyed ESP-NULL can use any key length. -- Harald From owner-ipsec Mon Mar 16 03:49:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA03497 for ipsec-outgoing; Mon, 16 Mar 1998 03:42:11 -0500 (EST) Message-Id: <3.0.1.32.19980316114021.0069fa74@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 16 Mar 1998 11:40:21 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Why can't ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, With respect to the draft draft-ietf-ipsec-arch-sec-03.txt Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. ============================================================= | | | ======================= | | | | | --|-----------------|--- --|-------------------|-- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | ------------------------ ------------------------- admin. boundary admin. boundary Here consider that the host H1 sends out fragments or the incoming packets to the SG1 are fragmented then * Whether such situation arises that the incoming packets to a security gateway are fragmented ?. * What the security gateway does in such situation ?. Does it reassembles all the packets (eventhough they are not destined for it, because reassembly occurs only at the destination) and apply tunnel mode i.e do IPsec processing on the reassembled packet and sends it out with or with out fragmentation as needed. * Does it discards the packet since a fragment has came to the IPsec processing ?. * Why can't we apply IPsec processing on frgaments( I did not get anything from the explaination given in the draft)?. If its only due to the src and dest ports ( which we can't get from the frgaments and if it is ESP ) then that is not sufficient reason to discard fragment fron the IPsec processing, because most of the time the packet will be get fragmented or it will be in ESP mode. If we can apply IPsec on fragments then we can avoid the unneccessary reassembly at the SG1 just to apply IPsec. Thank U in advance Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Mon Mar 16 03:49:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA03455 for ipsec-outgoing; Mon, 16 Mar 1998 03:38:11 -0500 (EST) Message-Id: <3.0.1.32.19980316114019.00691c0c@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 16 Mar 1998 11:40:19 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Do we need ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, With reference to draft-ietf-ipsec-arch-sec-03.txt "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)." "2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet." In the first paragraphs it says before creating new SA one should check whether SAD already has an appropriate SA created by some other SPD entries.But second paragraph from section "5.1.1 Selecting and Using an SA or SA Bundle" says if no SA found then create the new SA. So which one to follow do we need to search the SAD for appropriate SA created by other SPD entries or simply create the new SA, if no matching SA found ? Thank U in advance Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Mon Mar 16 05:10:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA04025 for ipsec-outgoing; Mon, 16 Mar 1998 05:08:10 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Date: Mon, 16 Mar 1998 11:20:24 +0100 (MET) From: Bart Preneel Reply-To: Bart Preneel To: Roy Pereira cc: "IPSEC Mailing List (E-mail)" , Bart Preneel , Vincent Rijmen Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Some comments on the weak keys of IDEA. Also note that the following paper will be presented at Eurocrypt'98 (Helsinki, June 1-4). Philip Hawkes, Differential-linear weak key classes of IDEA Vincent Rijmen Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- The draft says: > > 2.3 Weak Keys > > Weak key checks SHOULD be performed. If such a key is found, the > key SHOULD be rejected and a new SA requested. Some cipher > algorithms have weak keys or keys that MUST not be used due to > their weak nature. > [...] > IDEA: > > IDEA has weak keys of the following form [Crypto93]: > > 0000,0000,0x00,0000,0000,000x,xxxx,x000 > > where "x" can be any hexadecimal number. > > Keys of this form guarantee the value of bit-wise XOR of resultant > ciphertext pairs from the bit-wise XOR of certain plaintext pairs. > [...] > [Crypto93] J. Daeman, R. Govaerts, J. Vandewalle, "Weak Keys for > IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, > Springer-Verlag, pp. 224-230. > This statement is incorrect, and it is certainly not in accordance with the [Crypto93] reference. Also note that the name of the first author is Daemen rather than Daeman. In [Crypto93], three classes of weak keys have been identified: 1) keys that result in a linear factor: 0000 00ab 0000 0000 00c0 0000 000d xyzt where a = 0,1,2,3 b = 0,8 c = 0,2,4,6,8,10,12,14 d = 0,1 x,y,z,t = any value (2^23 keys) A linear factor is a linear relation between certain bits of the input and certain bits of the output, that holds with probability one. 2) keys for which a certain difference in the plaintext input leads to a predictable difference in the output (with probability one) 0000 00ax yzb0 0000 00tc 0000 000u vwd0 where a = 0,1,2,3 b = 0,8 c = 0,8 d = 0,2,4,6,8,10,12,14 x,y,z,t,u,v,w = any value (2^35 keys) This is the class of keys that has the weakness that is explained in the draft. Note that the weak key values given in the standard do not agree. 3) other weak keys 0000 00ax yzb0 0000 00tu v000 cwsq prd0 a = 0,1,2,3 b = 0,8 c = 0,1 d = 0,2,4,6,8,10,12,14 x,y,z,t,u,v,w,s,q,p,r = any value (2^51 keys) This is a class of keys that can be easily recovered if the attacker knows the ciphertexts corresponding to 16 plaintexts with a certain structure. (more exactly, the differences between the 16 plaintexts need to have a certain value). Class 2 is a subclass of class 3. Note that according to [Crypto93], class 1 is not a subclass of class 3. If this is considered to be "too complex," one can define the following class, that contains all weak keys and is easy to write down: 0000 00xx xxx0 0000 00xx x000 xxxx xxxx Of course this is a serious overkill (2^64 keys). ------------------------------------------------------------------------------- On Tue, 10 Mar 1998, Roy Pereira wrote: > > Internet Engineering Task Force R. Pereira > IP Security Working Group TimeStep Corporation > Internet Draft R. Adams > Expires in six months Cisco Systems Inc. > March 10, 1998 > > > > The ESP CBC-Mode Cipher Algorithms > > From owner-ipsec Mon Mar 16 10:41:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06628 for ipsec-outgoing; Mon, 16 Mar 1998 10:39:17 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 16 Mar 1998 10:50:34 -0500 Message-Id: <9803161550.AA26962@secpwr.watson.ibm.com> To: matt@ljo.dec.com Subject: Re: new IKE draft Cc: ipsec@tis.com, hugo@ee.technion.ac.il, canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: FXbUsukixf6k78sMdKOZjQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt : > > > >7. impose limits on the size of nonces: 8 <= len(nonce) <= 256 (section 5) > > 3 March email from Tero Kivinen and 4 March email from Hilarie Orman > > Just one question, in the the RSA Encryption modes don't the nonces need to > be smaller than the RSA modulus (so they can be encrypted/decrypted)? > (Also what happens in the non-Revised mode if the identification payload is > larger than what can be encrypted via the RSA modulus?) I think you are right. Actually, for stronger securuty, I think the input to RSA encryption should not be longer than 2/3 of the size of the modulus. Hugo and Ran, am I right about this ? > > Also, in the RSA Encryption modes you can specify a hash of the certificate > you are using. How do you calculate the hash (since you have not finished > negotiating the hash algorithm)? In main mode, this "cert-hash" is not sent until after negotiation is comopleted. In aggressive mode, well, you have to be careful about what you propose. Not only the hash algorithms have to be the same in all proposed transforms, but the encryption algorithms, the prfs (if any), the authentication methods and the groups have to be the same as across proposed transforms as well. As far as I can tell, the only thing that can be different in aggressive mode is the life time. Pau-Chen > -- > Matt Thomas Internet: matt.thomas@altavista-software.com > Internet Locksmith WWW URL: > AltaVista Internet Software Disclaimer: This message reflects my own > Littleton, MA warped views, etc. From owner-ipsec Mon Mar 16 11:24:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06978 for ipsec-outgoing; Mon, 16 Mar 1998 11:23:20 -0500 (EST) Message-ID: From: Roy Pereira To: "'Scott G. Kelly'" , "'ipsec@tis.com'" Subject: RE: comments on ...isakmp-mode-cfg-02 Date: Mon, 16 Mar 1998 11:29:27 -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 Your points are very convincing. The original draft (-00) actually had a Configuration payload specified. This was changed to a NOTIFY payload for the second revision of the draft because of interoperability issues. Most, if not all, ISAKMP implementations would send back an INVALID-PAYLOAD-TYPE error message when encountering an unknown payload type. Since ISAKMP-Cfg is not part of the base ISAKMP spec (nor should it be) not all ISAKMP implementations will support it. Thus we had to come up with a way of not breaking existing implementations. This same converstaion has gone on for a couple of weeks off the mailing list as well, so I'd like to propose the following: 1) A separate Config payload is defined. 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or higher. Support does not mean you actually use it, just that it does not break your implementation. Comments? >-----Original Message----- >From: Scott G. Kelly [SMTP:skelly@redcreek.com] >Sent: Friday, March 13, 1998 4:05 PM >To: ipsec@tis.com >Subject: comments on ...isakmp-mode-cfg-02 > >I have a few comments on draft-ietf-ipsec-isakmp-mode-cfg-02.txt. I am >not prepared to comment regarding the usefulness of the proposed >functionality. Rather, I'll confine my comments to the mechanism >proposed for adding the suggested functionality, i.e. piggy-backing >'configuration' messages onto the notify payload. > >While such configuration messages might be useful, this is *not* the >best way to add them, and in fact, it looks like a hack. The notify >messages have been defined for one-way communication of status >information, while the configuration exchange being proposed is actually >a 2-way negotiation. Why not suggest a new payload type for this? > >I won't go into all the specific and obvious arguments against the >suggested payload overloading, as I believe these are self-evident. I >will, however, point out that the ISAKMP-09 draft contains the following >text on page 70: > >'Because the Informational Exchange with a Notification payload is a >unidirectional message a retransmission will not be performed...' > >It appears that the design intent is for one-way (unidirectional) usage, >while the configuration mode suggested clearly requires bidirectional >communication... > >Scott > From owner-ipsec Mon Mar 16 13:51:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08235 for ipsec-outgoing; Mon, 16 Mar 1998 13:50:25 -0500 (EST) Message-Id: <199803161323.IAA13137@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-08.txt Date: Mon, 16 Mar 1998 08:23:30 -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-08.txt Pages : 30 Date : 13-Mar-98 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a list of changes since the previous version of the IPSEC DOI, please see Section 7. 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-08.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313191819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313191819.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 13:51:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08218 for ipsec-outgoing; Mon, 16 Mar 1998 13:49:22 -0500 (EST) Message-Id: <199803161321.IAA12451@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-04.txt Date: Mon, 16 Mar 1998 08:21:02 -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 : Security Architecture for the Internet Protocol Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-04.txt Pages : 65 Date : 13-Mar-98 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 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-arch-sec-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313174551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313174551.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 13:51:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08236 for ipsec-outgoing; Mon, 16 Mar 1998 13:50:25 -0500 (EST) Message-Id: <199803161320.IAA12410@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-05.txt Date: Mon, 16 Mar 1998 08:20:57 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-05.txt Pages : 23 Date : 13-Mar-98 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just ''authentication''), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-header-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-header-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313174247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313174247.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 13:51:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08234 for ipsec-outgoing; Mon, 16 Mar 1998 13:50:23 -0500 (EST) Message-Id: <199803161320.IAA12374@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-04.txt Date: Mon, 16 Mar 1998 08:20: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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-04.txt Pages : 22 Date : 13-Mar-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313173929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313173929.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 13:51:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08279 for ipsec-outgoing; Mon, 16 Mar 1998 13:51:28 -0500 (EST) Message-Id: <199803161324.IAA13306@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-07.txt Date: Mon, 16 Mar 1998 08:24:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-07.txt Pages : 40 Date : 13-Mar-98 [MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called ''modes''-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. 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-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313193055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313193055.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 13:51:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08280 for ipsec-outgoing; Mon, 16 Mar 1998 13:51:29 -0500 (EST) Message-Id: <199803161341.IAA15378@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-null-00.txt Date: Mon, 16 Mar 1998 08:41:56 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The NULL Encryption Algorithm and Its Use With IPsec Author(s) : S. Kent, R. Glenn Filename : draft-ietf-ipsec-ciph-null-00.txt Pages : 5 Date : 13-Mar-98 This draft defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality. Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-null-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-null-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313140122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-null-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-null-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313140122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 16 14:30:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08609 for ipsec-outgoing; Mon, 16 Mar 1998 14:29:22 -0500 (EST) Date: Mon, 16 Mar 1998 14:42:26 -0500 Message-Id: <199803161942.OAA24677@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bart Preneel Cc: Roy Pereira , "IPSEC Mailing List" , Bart Preneel , Vincent Rijmen In-Reply-To: Bart Preneel's message of Mon, 16 Mar 1998 11:20:24 +0100 (MET), Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Bart, Thanks for sending in this erratum to the draft-ietf-ciph-cbc draft. It would have been nicer if you could have discovered this problem last week, since the I-D submission deadline is closed, and we were in working group last call in preparation for starting the IETF last call and sending these documents off to the IESG. To the working group: As some of you may know, we've been under a lot of pressure to get these documents out the door, since our delay has been blocking the progress of other groups (most notably the IP Compression documents) and the release of these documens as proposed standards is long, long overdue. I realize that these documents are not perfect; but they do not need to be perfect. In particular, as implementors who have not been involved in our multi-year journey towards standards start trying to interpret the IPSEC documents, I am sure there will be a number of places where the text will not be clear to someone who hasn't been living and breathing IPSEC for the last two years. That's OK --- that's what the standards track is for. We can make editorial changes to correct such problems when these documents go up for consideration for elevation to draft standard status. The problem that Bart has pointed out here is not an editorial problem, though, but a problem where the document has screwed up on matters of fact. The correction of the author's name in the bibliography can be corrected in the RFC editing process. The enumeration of the currently known weak keys, though, is a much more serious issue. I can see three paths before us: (a) delay the progress of all of the other IPSEC drafts until this problem can be fixed (which means waiting until after the LA IETF). (b) delay the progression of just the draft-ietf-ciph-cbc draft. (Which we can do since all of its algorithms are OPTIONAL, and no other documents have a dependency on this draft.) (c) note this error, but consider it relatively unimportant, (since the chances of hitting a weak key are infintessimal anyway) and correct it when we progress up to draft standard status. My personal preference would be option (b), but I am certainly willing to entertain arguments for option (c). I assume that everyone agrees that option (a) is a bad idea. :-) Comments? - Ted P.S. I suggest that when we revise the text of this draft, that we word it as saying that implementations SHOULD reject weak keys and request a new SA, but to not claim to have an exhaustive listing of all possible weak keys in the document. That way, when researchers come up with new and interesting weak keys in IDEA, implementations be updated without implementors worrying about violating the spec. From owner-ipsec Mon Mar 16 16:32:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09538 for ipsec-outgoing; Mon, 16 Mar 1998 16:29:35 -0500 (EST) Message-ID: <350D8A0E.C876506@BayNetworks.com> Date: Mon, 16 Mar 1998 15:22:38 -0500 From: Shawn Mamros X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Roy Pereira CC: skelly@redcreek.com, ipsec@tis.com Subject: RE: comments on ...isakmp-mode-cfg-02 X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > This same converstaion has gone on for a couple of weeks off the mailing > list as well, so I'd like to propose the following: > > 1) A separate Config payload is defined. > 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or > higher. Support does not mean you actually use it, just that it does > not break your implementation. > > Comments? If Config becomes a separate payload type, then we're also going to need a new exchange type to deal with any exchanges of config info that happen after Phase 1 completes, such as those required for extended authentication (draft-ietf-ipsec-isakmp-xauth-01.txt). The Informational exchange no longer applies, and we aren't allowed to extend either Main or Aggressive mode, so it seems a new Config exchange is necessary. Actually, I'm wondering now if adding a new exchange might eliminate the need to "bump up" the ISAKMP version number(s), as it seems to me that going to 1.1 might cause its own set of interoperability problems. That would mean that we couldn't put Config payloads in Phase 1, but that might be a small price to pay to avoid problems with the version number. How would most implementations handle an unrecognized exchange type? -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Mon Mar 16 16:37:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09595 for ipsec-outgoing; Mon, 16 Mar 1998 16:35:36 -0500 (EST) Date: Mon, 16 Mar 1998 16:48:02 -0500 Message-Id: <9803162148.AA07048@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tytso@MIT.EDU Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt References: <199803161942.OAA24677@dcl.MIT.EDU> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I like proposal B also. This does suggest something for consideration... would it be possible to establish a "registry" for this sort of information? In other words, a repository for information about things like weak keys, which is updated by a process less rigorous and time consuming than the regular IETF document process? While it clearly is undesirable for mistakes to creep into a listing of weak keys, the consequences of such mistakes are nowhere near as serious as messing up protocols or distributed algorithms. And there is no problem at all with having two ends use different editions of such a list. Does the IETF process have this sort of thing at the moment (other than "Assigned numbers" that is)? paul From owner-ipsec Mon Mar 16 17:52:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10190 for ipsec-outgoing; Mon, 16 Mar 1998 17:49:36 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sumit Vakil" To: ipsec@tis.com Message-ID: <862565C9.007ED929.00@mwgate02.mw.3com.com> Date: Mon, 16 Mar 1998 17:05:57 -0600 Subject: Re: new IKE draft Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk According to PKCS#1, the length of the data to be encrypted must not be more than k-11 octets, where k is the modulus length. PKCS#1 has two interesting notes in section 8: 3. Application of private-key operations as defined here to data other than an octet string containing a message digest is not recommended and is subject to further study. 4. This standard may be extended to handle data of length more than k-11 octets. Is there a standard that describes how to do #4? That would answer how to encrypt longer octet strings. Also, what about #3 above? The Id payload certainly isn't a message digest. Thanks, Sumit A. Vakil 3Com, Corp. pau@watson.ibm.com on 03/16/98 09:50:34 AM To: matt@ljo.dec.com cc: ipsec@tis.com, hugo@ee.technion.ac.il, canetti@watson.ibm.com Subject: Re: new IKE draft Matt : > > > >7. impose limits on the size of nonces: 8 <= len(nonce) <= 256 (section 5) > > 3 March email from Tero Kivinen and 4 March email from Hilarie Orman > > Just one question, in the the RSA Encryption modes don't the nonces need to > be smaller than the RSA modulus (so they can be encrypted/decrypted)? > (Also what happens in the non-Revised mode if the identification payload is > larger than what can be encrypted via the RSA modulus?) I think you are right. Actually, for stronger securuty, I think the input to RSA encryption should not be longer than 2/3 of the size of the modulus. Hugo and Ran, am I right about this ? > > Also, in the RSA Encryption modes you can specify a hash of the certificate > you are using. How do you calculate the hash (since you have not finished > negotiating the hash algorithm)? In main mode, this "cert-hash" is not sent until after negotiation is comopleted. In aggressive mode, well, you have to be careful about what you propose. Not only the hash algorithms have to be the same in all proposed transforms, but the encryption algorithms, the prfs (if any), the authentication methods and the groups have to be the same as across proposed transforms as well. As far as I can tell, the only thing that can be different in aggressive mode is the life time. Pau-Chen > -- > Matt Thomas Internet: matt.thomas@altavista-software.com > Internet Locksmith WWW URL: > AltaVista Internet Software Disclaimer: This message reflects my own > Littleton, MA warped views, etc. From owner-ipsec Mon Mar 16 17:58:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10265 for ipsec-outgoing; Mon, 16 Mar 1998 17:56:42 -0500 (EST) Message-Id: <199803162310.XAA28809@orchard.arlington.ma.us> To: "Theodore Y. Ts'o" cc: Bart Preneel , Roy Pereira , "IPSEC Mailing List" , Bart Preneel , Vincent Rijmen Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt In-reply-to: Your message of "Mon, 16 Mar 1998 14:42:26 -0500 ." <199803161942.OAA24677@dcl.MIT.EDU> Date: Mon, 16 Mar 1998 18:10:22 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > P.S. I suggest that when we revise the text of this draft, that we word > it as saying that implementations SHOULD reject weak keys and request a > new SA, but to not claim to have an exhaustive listing of all possible > weak keys in the document. That way, when researchers come up with new > and interesting weak keys in IDEA, implementations be updated without > implementors worrying about violating the spec. I'm a little leery about this, because it means that different implementations would have different ideas about what constitutes a weak key, which could lead to rarely-occurring, difficult-to-diagnose interoperability glitches when the shared key ends up being "weak" and one endpoint detects this and the other doesn't. - Bill From owner-ipsec Mon Mar 16 19:17:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10730 for ipsec-outgoing; Mon, 16 Mar 1998 19:12:43 -0500 (EST) Message-ID: <350DC31C.41C6@cs.umass.edu> Date: Mon, 16 Mar 1998 19:26:04 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Sumit Vakil CC: IP Security List Subject: Re: new IKE draft References: <862565C9.007ED929.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sumit Vakil writes: > PKCS#1 has two interesting notes in section 8: > 3. Application of private-key operations as defined > here to data other than an octet string containing > a message digest is not recommended and is subject > to further study. [...] > Also, what about #3 above? The Id payload certainly isn't a message > digest. True, but the authentication via public key encryption mode in IKE uses encryption with a public key (PubKey_i or PubKey_r), not with a private key. -Lewis From owner-ipsec Mon Mar 16 19:39:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10856 for ipsec-outgoing; Mon, 16 Mar 1998 19:36:38 -0500 (EST) Message-ID: <350DC8D4.F23C2A7@redcreek.com> Date: Mon, 16 Mar 1998 16:50:28 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Roy Pereira CC: "'ipsec@tis.com'" Subject: Re: comments on ...isakmp-mode-cfg-02 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira wrote: > This same converstaion has gone on for a couple of weeks off the mailing > list as well, so I'd like to propose the following: > > 1) A separate Config payload is defined. > 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or > higher. Support does not mean you actually use it, just that it does > not break your implementation. > > Comments? This makes more sense. Since the draft is relatively new, it will (probably) be hashed out in IPSECond. That being the case, it makes sense to properly integrate the functionality into the protocol. From owner-ipsec Mon Mar 16 19:58:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10966 for ipsec-outgoing; Mon, 16 Mar 1998 19:54:42 -0500 (EST) Date: Mon, 16 Mar 1998 20:08:26 -0500 Message-Id: <199803170108.UAA24829@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Paul Koning Cc: ipsec@tis.com In-Reply-To: Paul Koning's message of Mon, 16 Mar 1998 16:48:02 -0500, <9803162148.AA07048@kona.> Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 16 Mar 1998 16:48:02 -0500 From: Paul Koning This does suggest something for consideration... would it be possible to establish a "registry" for this sort of information? In other words, a repository for information about things like weak keys, which is updated by a process less rigorous and time consuming than the regular IETF document process? The way this is normally done is by publishing an informational RFC containing the relevant information. (With pointers to the relevant papers and research in the bibliography, ideally.) - Ted From owner-ipsec Mon Mar 16 20:04:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11023 for ipsec-outgoing; Mon, 16 Mar 1998 20:01:44 -0500 (EST) Date: Mon, 16 Mar 1998 20:14:11 -0500 Message-Id: <199803170114.UAA24831@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bill Sommerfeld Cc: "Theodore Y. Ts'o" , Bart Preneel , Roy Pereira , "IPSEC Mailing List" , Bart Preneel , Vincent Rijmen In-Reply-To: Bill Sommerfeld's message of Mon, 16 Mar 1998 18:10:22 -0500, <199803162310.XAA28809@orchard.arlington.ma.us> Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 16 Mar 1998 18:10:22 -0500 From: Bill Sommerfeld I'm a little leery about this, because it means that different implementations would have different ideas about what constitutes a weak key, which could lead to rarely-occurring, difficult-to-diagnose interoperability glitches when the shared key ends up being "weak" and one endpoint detects this and the other doesn't. I wouldn't think this should cause an interoperability glitch, since either side should already be able to force that an SA be negotiated, for a variety of reasons, including one where one of the security gateway reboots and loses state. (This is general case problem may be one of the places where we need some implementation and operatonal experience before we're sure we've gotten all of the details right.) - Ted From owner-ipsec Mon Mar 16 20:35:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11228 for ipsec-outgoing; Mon, 16 Mar 1998 20:30:43 -0500 (EST) Message-ID: <350DD531.167E@cs.umass.edu> Date: Mon, 16 Mar 1998 20:43:13 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Matt Thomas CC: IP Security List Subject: Re: Revised Pre-Shared and Public Key Sig modes?? References: <199803062023.PAA15057@tecumseh.altavista-software.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt Thomas writes: > The Main Mode exchanges for Pre-Shared keys (HASH_x) or Public Key > Signatures (SIG_x) are: [...elided...] > Is there any reason why 1/2 a round trip could be not eliminated by > having Revised versions of these modes such that): > > HDR, SA --> > <-- HDR, SA, KE, Nr > HDR, KE, Ni --> > <-- HDR*, IDir, [HASH_R | SIG_R] > HDR*, IDii, [HASH_I | SIG_I] --> > I think your revised mode would make denial of service attacks easier. With the new design, the Responder does a DH computation before confirming that the Initiator at least parsed the Responder's cookie. An attacker could initiate many exponentiation-inducing exchanges without listening to return traffic from the Responder. -Lewis From owner-ipsec Mon Mar 16 23:14:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA12342 for ipsec-outgoing; Mon, 16 Mar 1998 23:11:37 -0500 (EST) Message-Id: <199803170422.XAA21852@relay.hq.tis.com> Date: Mon, 16 Mar 98 23:19:14 EST From: Karen Seo To: "srinivasrao.kulkarni" cc: ipsec@tis.com Subject: Re: Do we need ? Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Oops, Section 5.1.1 is correct. We had changed it in the February draft (as noted below) and missed the text in 4.4.3. [from list of changes -- email 2/20...] 18. Section "5.1.1. Selecting and Using an SA or SA Bundle" [outbound processing] -- Several issues have come up. a) How much searching of the SPD and SAD should be done before creating a new SA? * Several approaches to this have been brought up on the list, e.g., see email from S. Kent 12/7/97 in reply to Ly Loi (Subj: "Re: IPSEC arch comments"). There is a tradeoff between spending more time to search the SAD to avoid creating unnecessary SAs and using more space by creating potentially redundant SAs by using the first SPD hit (if it does not point to a matching SA). One possible enhancement would be to note which policies create overlapping SAs when the SPD is created. There weren't many comments, but the general feeling seemed to be in favor of creating an SA for the first policy hit rather than searching the whole SAD. Thank you, Karen From owner-ipsec Tue Mar 17 01:26:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA13146 for ipsec-outgoing; Tue, 17 Mar 1998 01:24:41 -0500 (EST) Message-Id: <3.0.1.32.19980317114244.006c6794@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 17 Mar 1998 11:42:44 +0500 To: ipsec@tis.com From: "K. SrinivasRao" Subject: No SPD Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, with respect to the draft-ietf-ipsec-arch-sec-04.txt "The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the *derived Port Selector value for the SPD and SAD.*" Above paragraph says that derive the port selectors value for both SPD and SAD. Why one should derive the port selectors value for SPD. I think the port selectors value for the SPD is determined by the adminstrator not by the "Next Header" value in the packet and SPD. I think we have derive the port selectors value only for the SAD. Thanks From owner-ipsec Tue Mar 17 01:31:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA13214 for ipsec-outgoing; Tue, 17 Mar 1998 01:31:37 -0500 (EST) Message-Id: <3.0.1.32.19980317101348.006c1744@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 17 Mar 1998 10:13:48 +0500 To: ipsec@tis.com From: rohit Subject: Complyence Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, Whether it is necessary ( MUST ) to implement ICMP PMTU processing , in order to make our implementation comply to the IpSec Architecture draft ? - Thanks ******************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ******************************************************************* From owner-ipsec Tue Mar 17 01:46:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA13329 for ipsec-outgoing; Tue, 17 Mar 1998 01:46:37 -0500 (EST) Message-Id: <3.0.1.32.19980317094511.006bd1e0@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 17 Mar 1998 09:45:11 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Why can't ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, With respect to the draft draft-ietf-ipsec-arch-sec-04.txt Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. ============================================================= | ===SG3*=========*SG5=== | | | | | | | |===SG4============ | | --|-----------------|--- --|-------------------|-- | | Trusted N/W | | | | Trusted N/W | | | H1 -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2 | | Intranet) | | Intranet) | ------------------------ ------------------------- admin. boundary admin. boundary Let us consider the following situation * SG3, SG4 and SG5 are in between routers. * SG1 and SG2 have AH/ESP tunnel. * SG3 and SG5 have AH/ESP tunnel. * Host H1 sends out the packet destined to H2. * SG1 applies IPsec and the packet get fragmented. * First fragment reaches SG5 and then to SG2, through SG4 with out any IPsec applied since there is no security association between SG4 and SG5. * The rest of the fragments go through the SG3 Since IPSEC does not process fragments, the fragments in the SG3-SG5 tunnel get dropped. Of course, if the PMTU is proper and is above the threshold for MTU, there will not be fragments. But, in the rare case where the PMTU is lower than the threshold or the path changes in the middle of a transmission, there could be fragments. Is this scenario feasible, in the first place? We think it is possible. Will these fragments be discarded? Is it essential for them to be discarded? Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Tue Mar 17 07:56:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15659 for ipsec-outgoing; Tue, 17 Mar 1998 07:51:37 -0500 (EST) Date: Mon, 16 Mar 1998 17:53:27 -0500 (EST) From: Henry Spencer To: "Theodore Y. Ts'o" cc: IPSEC Mailing List Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt In-Reply-To: <199803161942.OAA24677@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > ...but to not claim to have an exhaustive listing of all possible > weak keys in the document. That way, when researchers come up with new > and interesting weak keys in IDEA, implementations be updated without > implementors worrying about violating the spec. Perhaps (in the long run) it would be worth putting the "known weak keys" lists -- not just for IDEA, but for all the ciphers -- in a separate informational RFC? Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Tue Mar 17 08:19:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA15984 for ipsec-outgoing; Tue, 17 Mar 1998 08:18:40 -0500 (EST) To: ipsec@tis.com Subject: some comments on draft-ietf-ipsec-arch-sec-04.txt Date: Mon, 16 Mar 1998 18:53:08 -0500 From: Bill Sommerfeld Message-ID: <9803161853.aa10914@khitomer.epilogue.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk All of these comments are relatively minor and (I think) in the class of editorial changes.... page 11: 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. I would replace "below" with "outside"; I found the use of "below" confusing and potentially ambiguous (as packet layouts are usually drawn with the lower-layer protocols above the upper-layer headers..) page 15: (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.) I think it would be clearer/more appropriate to say that policies may be cached outside the SPD proper on a per-connection/per-flow/ per-whatever basis to speed packet processing. Given that we're specifying the nature of administrative interfaces, it perhaps seems appropriate to specifying whether or not any policy caches need to be coherent -- in other words, whether changes to the SPD need to be immediately reflected in cached policy or if it's ok for such changes to be deferred... page 18: 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. It would be useful to include a definition of what "opaque" means in this context. I assume from context that it means that it is unavailable to the policy code.. page 18..19: Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses, or a wildcard (mask) address. (essentially similar text also applies to source addresses) wording nit: instead of just a mask, presumably an "address+mask" or "address+prefix length" is meant here. Is a fully general mask+match facility needed, or is a simpler address+prefix-length a la CIDR all that's needed? Also, it would appear to not be meaningful to specify an IPv6 source address and an IPv4 destination address (or vice versa). page 19: 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. What's the difference between specifying a Transport Protocol of `ESP' vs. a Transport Protocol of `OPAQUE'? If there is one, it should be specified here.. - Bill From owner-ipsec Tue Mar 17 10:10:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16834 for ipsec-outgoing; Tue, 17 Mar 1998 10:08:44 -0500 (EST) Message-Id: <199803171519.KAA04734@relay.hq.tis.com> Date: Tue, 17 Mar 98 10:21:40 EST From: Charles Lynn To: "K. SrinivasRao" cc: ipsec@tis.com, kent@bbn.com Subject: Re: No SPD Sender: owner-ipsec@ex.tis.com Precedence: bulk > with respect to the draft-ietf-ipsec-arch-sec-04.txt > > "The following table summarizes the relationship between the "Next Header" > value in the packet and SPD and the *derived Port Selector value for the > SPD and SAD.*" > > Above paragraph says that derive the port selectors value for both SPD and > SAD. Why one should derive the port selectors value for SPD. I think the > port selectors value for the SPD is determined by the administrator not by > the "Next Header" value in the packet and SPD. I think we have derive the > port selectors value only for the SAD. Think of the case of a security gateway at the head of a tunnel, i.e., outgoing processing. If the packet arriving from inside is already protected by ESP end-to-end, then the security gateway will be able to determine neither the transport protocol (since ipsec protocol is no longer a selector) nor the source and destination ports. How is that packet processed against the SPD to find the matching SPD entry? When we had "opaque", one could place the policy entry containing opaque protocol and ports either before or after policy entries with the same source and destination addresses and explicit protocol and ports; but opaque has been removed so that freedom is no longer possible. If one makes the explicit wildcard SPD entry choice, as you are suggesting, then the result is that the entry is essentially "after". Trying to place it before the explicit entry would effectively hide the explicit entry since anything that would match the explicit entry would also match the wildcard entry preceding it. If one makes the "derive (protocol and) port selector value" choice, as the document is written, then one has a single SPD entry that is a combination of the two. However, one has the possibility that the SPD entry that will be matched is not the "expected" one, but some previous, possibly explicit, SPD entry that has the same source and destination addresses, but different (protocol and) port selectors. We need to make a decision, and live with it's pluses and minuses. The situation for fragmentation is really ugly. Life was relatively simple when fragments (arriving at a security gateway) for outbound processing were simply dropped (with associated PMTU processing). Trying to permit fragments to enter a tunnel has a range of implementation choices, many of which can lead to interoperability problems and possible failure of the expected security mechanisms (and possible resulting litigation). One issue is making sure that the second to last fragments receive the same protection as the first fragment. For example, I would not want to be the Security Officer who tells the CEO that the trade secret which is the basis for the company's existence was lost because the first fragment utilized the confidentiality service but the other fragments only received integrity protection. I suspect that making sure all fragments receive the same protection will lead one to create dynamic SPD entries, logically inserted before the "configured" SPD entries, based on ; or an alternative of doing the queueing (the first fragment might not be the first to arrive at the security gateway) and bookkeeping associated with IP Reassembly to direct the latter fragments to the same SPD as the first. Then, if there is an ESP header, one looses transport protocol as well as ports resulting in a less specific policy. Then, if there are redundant security gateways, not all fragments may be routed to the same security gateway. Does one really want to try coordinating things between security gateways? In general, it seems like a lot of code, for a (hopefully :-) few packets, that may be very hard to get right, and to interoperate (with the input SPD implementation at the tunnel endpoint). Charlie From owner-ipsec Tue Mar 17 10:12:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16896 for ipsec-outgoing; Tue, 17 Mar 1998 10:12:44 -0500 (EST) Message-Id: <199803171525.KAA01078@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Complyence In-reply-to: Your message of "Tue, 17 Mar 1998 10:13:48 +0500." <3.0.1.32.19980317101348.006c1744@192.9.200.10> Date: Tue, 17 Mar 1998 10:25:31 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "rohit" == rohit writes: rohit> Hi All, rohit> Whether it is necessary ( MUST ) to implement ICMP PMTU processing , in rohit> order to make our implementation comply to the IpSec Architecture draft ? I think it is a very STRONG SHOULD. I don't think it is something that should worry you in release number 1, but don't code yourself into a corner. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Tue Mar 17 10:32:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17017 for ipsec-outgoing; Tue, 17 Mar 1998 10:31:48 -0500 (EST) Date: Tue, 17 Mar 1998 10:45:07 -0500 Message-Id: <9803171545.AA14418@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sommerfeld@orchard.arlington.ma.us Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt References: <199803161942.OAA24677@dcl.MIT.EDU> <199803162310.XAA28809@orchard.arlington.ma.us> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: >> P.S. I suggest that when we revise the text of this draft, that >> we word it as saying that implementations SHOULD reject weak keys >> and request a new SA, but to not claim to have an exhaustive >> listing of all possible weak keys in the document. That way, when >> researchers come up with new and interesting weak keys in IDEA, >> implementations be updated without implementors worrying about >> violating the spec. Bill> I'm a little leery about this, because it means that different Bill> implementations would have different ideas about what Bill> constitutes a weak key, which could lead to rarely-occurring, Bill> difficult-to-diagnose interoperability glitches when the shared Bill> key ends up being "weak" and one endpoint detects this and the Bill> other doesn't. I don't see any alternative. Clearly you have to be able to deal with a situation where one side rejects a key that the other doesn't. The alternative is to prohibit the checking for weak keys other than the ones known at V1 time and listed in the V1 documents. If the idea of checking for weak keys has any merit at all (and I believe it does) then it clearly has to be possible to check according to the latest and best knowledge. This is a very simple case of designing a protocol for extensibility. It's well known how to do this -- surely we can get it right in this case? It seems to me that all that's necessary is to allow each side to decline to use the negotiated parameters once it finds out what the key is. If all else fails it can do that by considering the SA to be expired already and applying the usual mechanisms. paul From owner-ipsec Tue Mar 17 10:48:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17141 for ipsec-outgoing; Tue, 17 Mar 1998 10:47:50 -0500 (EST) Message-Id: <199803171602.LAA04874@relay.rv.tis.com> Date: Tue, 17 Mar 98 10:53:04 EST From: Charles Lynn To: "srinivasrao.kulkarni" cc: ipsec@tis.com Subject: Re: Why can't ? Sender: owner-ipsec@ex.tis.com Precedence: bulk > ============================================================= > | ===SG3*=========*SG5=== | > | | | | | > | |===SG4============ | | > --|-----------------|--- --|-------------------|-- > | | Trusted N/W | | | | Trusted N/W | | > | H1 -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2 | > | Intranet) | | Intranet) | > ------------------------ ------------------------- > admin. boundary admin. boundary > > Let us consider the following situation > > * SG3, SG4 and SG5 are in between routers. > * SG1 and SG2 have AH/ESP tunnel. > * SG3 and SG5 have AH/ESP tunnel. > * Host H1 sends out the packet destined to H2. > * SG1 applies IPsec and the packet get fragmented. > * First fragment reaches SG5 and then to SG2, through SG4 with out any > IPsec applied since there is no security association between SG4 and SG5. ==================== SPD entry > * The rest of the fragments go through the SG3 > > Since IPSEC does not process fragments, I think that this phrase is causing problems. In the outbound direction, fragmentation happens after IPSec processing [that says NOTHING about whether the object to which the IPSec processing is a fragment or not], and, in the inbound direction, reassembly is performed before IPSec processing [which says NOTHING about whether the object that results from the initial IPSec processing, and is handed matched against the input SPD, is a fragment or not]. > the fragments in the SG3-SG5 tunnel get dropped. This is not a result of the "IPSEC does not process fragments" clause, but could happen due to the capabilities/configuration/working group consensus for IPSec tunnels. > in the rare case where the PMTU is lower than the threshold or the > path changes in the middle of a transmission, there could be > fragments. Is this scenario feasible, in the first place? We think it > is possible. Yes, it can certainly happen. > Will these fragments be discarded? It depends on what the working group decides to do, or whether it left up to vendors to decide on extra product differentiating features they choose to support. (See my previous message.) > Is it essential for them to be discarded? I suspect that a paranoid security officer would say "yes", while a user who cannot get either his computer platform/application to do PMTU would say "no". Charlie From owner-ipsec Tue Mar 17 17:41:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20546 for ipsec-outgoing; Tue, 17 Mar 1998 17:37:54 -0500 (EST) Message-Id: <199803172252.RAA04389@relay.rv.tis.com> Date: Tue, 17 Mar 98 17:51:31 EST From: Charles Lynn To: rohit cc: ipsec@tis.com Subject: Re: clarification Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, It has been pointed out that my earlier message is not right. Specifically, I said: > When we had "opaque", one could place the policy entry containing opaque > protocol and ports either before or after policy entries with the same > source and destination addresses and explicit protocol and ports; but > opaque has been removed so that freedom is no longer possible. "Opaque" is still a SHOULD, so the correct statement is: One can place the policy entry containing opaque protocol and ports either before or after policy entries with the same source and destination addresses and explicit protocol and ports. I have also heard the opaque should be defined -- i.e., the value of the field from a packet is not available, either because of an ESP header or because of fragmentation. > If one makes the explicit wildcard SPD entry choice, as you are > suggesting, then the result is that the entry is essentially "after". > Trying to place it before the explicit entry would effectively hide the > explicit entry since anything that would match the explicit entry would > also match the wildcard entry preceding it. This might be stated as: It does not make sense to place an SPD entry for ANY (e.g., WILDCARD) before the SPD entry for an explicit value as the ANY entry would effectively hide the entry for the explicit value, since anything that would match the explicit entry would also match the wildcard entry preceding it. The following paragraph should be ignored: > If one makes the "derive (protocol and) port selector value" choice, as > the document is written, then one has a single SPD entry that is a > combination of the two. However, one has the possibility that the SPD > entry that will be matched is not the "expected" one, but some previous, > possibly explicit, SPD entry that has the same source and destination > addresses, but different (protocol and) port selectors. Sorry for any confusion I might have caused. ........................................................................ > At 11:41 AM 3/12/98 EST, you wrote: > >Rohit, > > > > Next Hdr Next Hdr Derived Port Selector Field > > in Packet in SPD Value in SPD and SAD > > --------------- -------------- ---------------------------- > > > > 1) ESP ESP or ANY ANY (i.e., don't look at it) > > > > 2) -don't care- ANY ANY (i.e., don't look at it) > > > > 3) specific value, specific value NOT ANY (i.e., drop packet) > > fragment > > > > 4) specific value, specific value actual port selector field > > not fragment > > > >What the table is trying to convey is that there are interactions > >between the selectors used to match SPD or SAD entries themselves and > >also with fields in a packet that are not classified as selectors, > >i.e., the fragmentation fields. It tries to be "implementation > >neutral" by specifying certain port selector values that result in the > >desired behavior. > > rohit>> can you elobarate on "fragmentation fields " ? > rohit>> What is the meaning of "implementation neutral"? "Fragmentation fields" means those fields in an IP datagram that indicate that the datagram is a fragment. For an IPv4 header, a fragment is indicated by either the Flags field having Bit 2: (MF) set to 1, or a non-zero Fragment Offset field. A fragment is also indicated when there is a Fragmentation Header with either a non-zero Fragment Offset, or the M bit is set to one. "Implementation neutral" means that the document is not suggesting use of a particular way to implement the desired functionality. A vendor can use any mechanism that results in the correct behavior. > >In cases 1), if the protocol field in the packet identifies an ESP > >header, and the protocol selector specifies either ESP or a wildcard, > >i.e., the protocol matches, then one cannot use the port selector for > >anything as one cannot find port values in the packet to be matched > >against the selector values in the SPD or SAD. The easy way to > >specify that "there are no useful port value(s) in the packet" is to > >specify the source and destination port selectors as a wildcard -- ANY. > > rohit>> Where we have to specifiy ? Since policies in SPD has been > already entered by system administrator, whether it leads to the > modification of the policy ( i.e Selector_Val_Type ) As you say, the policy has been specified in the SPD. The table does not mean that the SPD is modified, but that it does not make sense to specify an explicit port value when one has specified a protocol of ESP, or does not care what protocol is being used. > rohit>> ANY means either packetvalue/SPDValue / wildcard , not just > wildcard , is it right ? I do not think so. It meant that the packetvalue was not available to be compared to the SPDValue, and a way to specify that there was no meaningful comparrison is to specify a wildcard. The distinction, in my mind, between a wildcard (ANY) and OPAQUE is that a wildcard will match any explicit value in the packet while OPAQUE would not match any explicit value, only "no value available". However, the IPSec DOI does not currently specify a way to express OPAQUE (maybe one could define 65535 to mean OPAQUE port and 255 to mean OPAQUE protocol), so there is an inconsistency here that should be addressed. >Otherwise in case 2), if the one allows any protocol, then it does >not make any sense to try and specify some explicit port number, so >again, one should ignore the port selectors by specifying ANY port. rohit >> Again where we should specify ? Again, in the SPD entry entered by system administrator. Charlie From owner-ipsec Tue Mar 17 19:17:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21261 for ipsec-outgoing; Tue, 17 Mar 1998 19:15:55 -0500 (EST) From: Eric Scoredos Message-Id: <199803180029.QAA29721@hpindlm.cup.hp.com> Subject: question about PFS SA duration To: ipsec@tis.com Date: Tue, 17 Mar 1998 16:29:55 PST Cc: ipsec@hpindlm.cup.hp.com X-Mailer: Elm [revision: 212.4] Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a question about PFS that came up at the RTP Interop. The IKE drafts define the conditions for identity protection and non-derivability of keying material necessary for PFS. However, neither the Architecture nor IKE drafts mention how the lifetime of the PFS SA is controlled so that multiple, unrelated messges are not sent using the same QM PFS SA. In the kernel, we can tell when to start a PFS session if there is no pre-existing SA for the appropriate selectors; however, it is not clear how we terminate this SA and prevent its re-use by another message using similar selectors after the original session as terminated. The SKIP documents talk about establishing a specific timeout for the PFS key and establishing new keys if more data needs to be send. A pre-established timeout seems fairly non-specific and I wonder if there are other architectural methods for establishing the duration of the PFS SA. In any case, I think the IPSEC drafts should offer direction here. Thanks for your help (and sorry if I missed the previous resolution of this issue). Salute, erik From owner-ipsec Tue Mar 17 19:23:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21310 for ipsec-outgoing; Tue, 17 Mar 1998 19:22:54 -0500 (EST) Message-Id: <199803180036.TAA03135@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: comments on ...isakmp-mode-cfg-02 In-reply-to: Your message of "Tue, 17 Mar 1998 09:30:50 PST." <350EB34A.E9C1604D@redcreek.com> Date: Tue, 17 Mar 1998 19:36:15 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> The fact of the matter is that if the IPsec suite is to continue Scott> to grow and improve, implementations will be (temporarily) broken Scott> now and then. You might be able to make an argument for hacking Yes, I agree. My proposed vendor ID allows a single vendor to deploy any number of extensions without having to break interoperability with other vendors. I propose that when it comes to writing up new drafts, we will be writing up ISAKMP v1.1. It isn't clear to me what to do when a responder receives a packet with a minor version that is *greater* than its own. I think that one should turn around and initiate with a packet containing major/minor that one can work with. I.e. the initiator's packet is just "lost", but an ISAKMP SA is setup. [hmm. WAIT: o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations *** based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with *** a minor version number larger than its own, given the major version numbers are identical. Isn't the 0/1 minor numbers reversed? Previous == 1, current = 0?] Scott> something in temporarily, but when you start going to the trouble Scott> of writing drafts, why not design it right? I think we are pretty close. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNQ8W+9iXVu0RiA21AQGKeQL9E6FqTNCM80GOc1KUEgtWDK+B9bzZwkOc jqZf2rc+kp5po7QAW2Waf7eD5XesZJm5GWgDgrl4bxiFd0S7SG9UY+TwZ2NbO4sG Xn9tMMgznmSAHC47gT5/o+jKd1zcupBV =C6xe -----END PGP SIGNATURE----- From owner-ipsec Tue Mar 17 20:46:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21925 for ipsec-outgoing; Tue, 17 Mar 1998 20:45:01 -0500 (EST) Date: Tue, 17 Mar 1998 20:57:38 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <9803161853.aa10914@khitomer.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bill Sommerfeld From: Stephen Kent Subject: Re: some comments on draft-ietf-ipsec-arch-sec-04.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I agree with your suggested editorial changes. WRT the wildcarding, the intent is to match exactly what is in IKE, to avoid negotiation vs. SPD mismatches, so we will reword to better reflect that. The text about OPAQUE transport protocols may be left over from when we distinguished between the transport layer protocol and the "next" protocol as different selectors. Since we simplified to a single selector, this text may not be necessary. Steve From owner-ipsec Tue Mar 17 20:46:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21920 for ipsec-outgoing; Tue, 17 Mar 1998 20:44:58 -0500 (EST) Date: Tue, 17 Mar 1998 20:57:56 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.1.32.19980317101348.006c1744@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rohit From: Stephen Kent Subject: Re: Complyence Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:13 AM +0500 3/17/98, rohit wrote: >Hi All, > > Whether it is necessary ( MUST ) to implement ICMP PMTU processing , in >order to make our implementation comply to the IpSec Architecture draft ? > > - Thanks Section 6 of the IPsec architecture defines certain aspects of ICMP PMTU processing that are a MUST. From owner-ipsec Tue Mar 17 20:46:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21937 for ipsec-outgoing; Tue, 17 Mar 1998 20:45:59 -0500 (EST) Date: Tue, 17 Mar 1998 20:57:58 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.1.32.19980317114244.006c6794@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "K. SrinivasRao" From: Stephen Kent Subject: Re: No SPD Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:42 AM +0500 3/17/98, K. SrinivasRao wrote: >Hi All, > >with respect to the draft-ietf-ipsec-arch-sec-04.txt > >"The following table summarizes the relationship between the "Next Header" >value in the packet and SPD and the *derived Port Selector value for the >SPD and SAD.*" > >Above paragraph says that derive the port selectors value for both SPD and >SAD. Why one should derive the port selectors value for SPD. I think the >port selectors value for the SPD is determined by the adminstrator not by >the "Next Header" value in the packet and SPD. I think we have derive the >port selectors value only for the SAD. > You should note that it is possible in the SPD to specify a wildcard (ANY) match for port fields, but also require that the SAD entry be created with the port fields from the packet that caused the SA to be created. This is a good way to specify per-connection keying in the SPD. Steve From owner-ipsec Tue Mar 17 22:50:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22694 for ipsec-outgoing; Tue, 17 Mar 1998 22:48:54 -0500 (EST) Message-Id: <199803180401.XAA04562@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Summary of issues from RTP Date: Tue, 17 Mar 1998 23:01:47 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {Don't ask me to present this in LA, I won't be there. The agenda doesn't say whether or not it will be in an MBONE room. If so, I'll be listening, DVMRP tunnel setup permitting. Email me if you can give me a tunnel!!!. I will update this list again on the 27th. I have taken the list, removed the headers, signatures, and reworded some parts. Please let me know if I've screwed up what you are saying.} 1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when offered different sizes. (2 octets was required for the IPcomp people) 2. ISAKMP payloads had to be in the order they are documented in the draft. Most ISAKMP payloads may be sent in any order. The exception is that there is a proscribed relationship between some payloads (i.e. proposal payloads, transform payloads, etc) 3. IP address in CERTs. Some people expected strings, other expected 4 octets in ipAddress. If string, then is it: CN vs Unstructured or subjectAltName. 4. Some implementations are sending a replay protection number of 0 when manually keying. "I was under the impression sequence # 0 should NEVER go on the wire, but hey, what do I know?" 5. Some vendors are not yet supporting DOI-07 wrt the AH transform type, and the AUTH attribute. {ed note: I wanted to give an example, but I can't seem to. I read as far back as DOI-04, but didn't see any changes... unless the issus is that the Auth(HMAC-MD5) wasn't being sent???} 6. Some vendors used old isakmp-08 certificate request format, but the data attrbute used in the payload was incorrectly formatted (or missing). {ed note: isakmp-09 was not publically available for the interop} 7. Some vendors did not like getting a key hash payload in rsa encryption mode. 8. Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received. Only the single payload should be discarded. 9. Some vendors did not like receiving certificate request payloads when using pre shared keys. (The isakmp draft says certificate requests payloads can exist in any message). 10. Some vendors did not like receiving certificate request payloads at any time. 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4 bytes. 12. Some vendors expected to see client ID's in phase 2. This caused quick mode to complete, but fail to install the SA properly. 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies. This caused premature termination of the negotiation. Speculation that some vendors may terminate on any unknown status-level information notifications. 14. (Relating to #5, and perhaps answering my question) Some vendors were not sending both the AH Transform type (e.g. AH_MD5) AND the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the the Transform type and the Authentication Algorithm attribute. {ed: I must say that I'm not clear why we have two definitions here, and I didn't find anything obvious by grepping my archives. If someone tells me what month to look in...} {ed: I received nothing about any wire level transform level issues. This is probably good.} :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNQ9HH9iXVu0RiA21AQF+KAL+PWlBkRYOCwoXtbm1nW73nbKP+fTS813e k8JG6Hyhe9tgmI6gU57m1PiPL5GZAdZzyC1PCGFSfdsbnAT93kkuBgo8eBgD8ZcP cnJhJtHdRexpCZXsL5cYQ5bwqc464dOT =0OuF -----END PGP SIGNATURE----- From owner-ipsec Wed Mar 18 05:26:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA25260 for ipsec-outgoing; Wed, 18 Mar 1998 05:21:53 -0500 (EST) Message-Id: <3.0.1.32.19980318130549.006a9978@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 18 Mar 1998 13:05:49 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: kent Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi folks, With respect to the draft-ietf-ipsec-esp-v2-04.txt 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. (case 1) o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. srinu>> Will the encryption algorithm which needs multiple of block size adds the padding that also ensures that the resulting ciphertext terminates on a 4-byte boundary. i.e the requirement of following paragraph(case2). (case2) o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. (case3) o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. srinu>> Is there any ordering of above three cases regarding how to process the packet. Like first apply the packet to process under do case2 and then case1 and then case3. Srinu>> If we are applying more than one cases, is it sure that pad length will not exceed 255 bytes. The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). Thank U Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Wed Mar 18 05:26:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA25288 for ipsec-outgoing; Wed, 18 Mar 1998 05:23:55 -0500 (EST) Message-Id: <3.0.1.32.19980318115811.006a9978@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 18 Mar 1998 11:58:11 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: What's the diff ? Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi IPsec folks, with respect to draft-ietf-ipsec-esp-v2-04.txt >From section 2.3 o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. *Can any one tell me what is the difference between (real) ciphertext and ciphertext. Because the ESP draft some times uses (real) ciphertext and some time just ciphertext. What's the difference between them? [Does the ciphertext means whole encrypted part of the packet and (real) ciphertext means just encrypted payload data] SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Wed Mar 18 07:13:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25968 for ipsec-outgoing; Wed, 18 Mar 1998 07:12:53 -0500 (EST) Date: Tue, 17 Mar 1998 23:16:22 -0500 (EST) From: Henry Spencer To: IP Security List Subject: editorial notes on arch-sec-04 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk A rereading of arch-sec-04 turned up a couple of small things, which I *think* are entirely editorial in nature... 1. If 4.4.3 needs to be fixed to reflect the reduced requirements for SA re-use in 5.1.1, then I think the second-last paragraph of 4.4.1 needs similar adjustments (especially that MUST at the end). 2. Section 5 begins: The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface. "Note that" is usually a short form of "As should be obvious from what has been already explained", i.e. it is calling attention to something that you could have already figured out. Except that here it's not; there is not the slightest hint in previous material, and for that matter there's relatively little hint in the rest of section 5, that such distinctions are called for. I would delete "Note that" and "Note also that". I think these issues should be mentioned -- if only with a forward reference -- in either 4.4.1 or 4.4.2. 4.4.1 repeatedly refers to *the* SPD, strongly implying that there is only one. If we're not talking about a model with separate SPDs, then this discussion has quietly added what are effectively two more selectors to the list in 4.4.2, and a warning there would be in order, since 4.4.2's wording implies that its list is complete. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Mar 18 07:13:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25937 for ipsec-outgoing; Wed, 18 Mar 1998 07:11:56 -0500 (EST) Date: Tue, 17 Mar 1998 22:00:45 -0500 (EST) From: Henry Spencer To: Charles Lynn cc: ipsec@tis.com Subject: Re: clarification In-Reply-To: <199803172252.RAA04389@relay.rv.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > opaque has been removed so that freedom is no longer possible. > "Opaque" is still a SHOULD, so the correct statement is... Besides, even if "opaque" *had* been removed, that part of the draft is quite clear that it is specifying *minimum* functionality... so an implementation which feels that it has a need for extra power in its SPD can always provide it. > I have also heard the opaque should be defined... Agreed; context tends to make its meaning clear, but that's not a good substitute for an explicit definition. > However, the IPSec DOI does not currently specify a way to express > OPAQUE (maybe one could define 65535 to mean OPAQUE port and 255 to > mean OPAQUE protocol), so there is an inconsistency here that should > be addressed. I don't understand the inconsistency. How "opaque" is expressed in databases and/or data structures within an IPSEC implementation is an implementation issue. "Opaque" is not an actual port/protocol value -- it never appears in a packet on the wire -- so there is no need for the RFCs to tell you how to express it. The only fact that needs to be pinned down is that it must compare unequal to any actual value (which means that it can't be 65535, unless it is illegal for a TCP/UDP implementation to use 65535 as a real port number, and I don't recall that being the case). Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Mar 18 08:18:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26554 for ipsec-outgoing; Wed, 18 Mar 1998 08:12:52 -0500 (EST) Message-ID: <19980318075951.42844@hazel> Date: Wed, 18 Mar 1998 07:59:51 -0500 From: Raul Miller To: Paul Koning , sommerfeld@orchard.arlington.ma.us Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-ciph-cbc-02.txt Mail-Followup-To: Paul Koning , sommerfeld@orchard.arlington.ma.us, ipsec@tis.com References: <199803161942.OAA24677@dcl.MIT.EDU> <199803162310.XAA28809@orchard.arlington.ma.us> <9803171545.AA14418@kona.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <9803171545.AA14418@kona.>; from Paul Koning on Tue, Mar 17, 1998 at 10:45:07AM -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul Koning wrote: > This is a very simple case of designing a protocol for extensibility. Hmm.. speaking of weak keys, I've not figured out what to do if all keys become weak. [Of course, the protocol will have to be updated, but other than lying about my public key in some site-site pre-arranged manner, I don't see any natural avenues of approach.] [[And, lest someone start quoting the age of the universe at me, I'm worried about the risk of massively parallel attacks: do we just scrap the whole system if someone builds a 128 bit quantum computer?]] [[[I'm sure this topic has been discussed before, and don't want to see this derail anything. If there's a reference on the subject, just point me at it?]]] Thanks, -- Raul From owner-ipsec Wed Mar 18 08:52:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26836 for ipsec-outgoing; Wed, 18 Mar 1998 08:51:52 -0500 (EST) Date: Wed, 18 Mar 1998 09:04:01 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19980318115811.006a9978@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: K SrinivasRao From: Stephen Kent Subject: Re: What's the diff ? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Srinu, >with respect to draft-ietf-ipsec-esp-v2-04.txt > >>From section 2.3 > >o For some IV-based modes of operation, the receiver treats the IV as the >start of the ciphertext, feeding it into the algorithm directly. In these >modes, alignment of the start of the (real) ciphertext is not an issue at >the receiver. > >*Can any one tell me what is the difference between (real) ciphertext and >ciphertext. Because the ESP draft some times uses (real) ciphertext and >some time just ciphertext. What's the difference between them? > >[Does the ciphertext means whole encrypted part of the packet and (real) >ciphertext means just encrypted payload data] We used the term "real ciphertext" to refer to the result of encrypting plaintext, vs. the IV that may be prepended to this output. I think we may have used the more generic term "ciphertext" to refer to the combination of the two. I am not aware of generally accepted terms that address this subtle difference between these two portions of the output from an algorithm that makes use of an explicit IV, so we just adopted this convention. The alternative would be to keep referring to the possibly present IV, which makes for very awkward reading. Steve From owner-ipsec Wed Mar 18 11:45:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03108 for ipsec-outgoing; Wed, 18 Mar 1998 11:43:18 -0500 (EST) Message-ID: From: Roy Pereira To: "'Shawn Mamros'" Cc: "'skelly@redcreek.com'" , "'ipsec@tis.com'" Subject: RE: comments on ...isakmp-mode-cfg-02 Date: Wed, 18 Mar 1998 11:49:31 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Adding a new exchange type would solve the problem of bumping up the ISAKMP version number and should not break any existing implementations. If the peer implementation does not support that exchange it would merely send back a "INVALID-EXCHANGE-TYPE" notify error messages. BTW: If you take a look at draft-ietf-ipsec-isakmp-mode-cfg-00.txt, you will see that it used a CFG payload as well as a CFG exchange. So perhaps we should have kept it that way. ;-) >-----Original Message----- >From: Shawn Mamros [SMTP:smamros@BayNetworks.com] >Sent: Monday, March 16, 1998 3:23 PM >To: Roy Pereira >Cc: skelly@redcreek.com; ipsec@tis.com >Subject: RE: comments on ...isakmp-mode-cfg-02 > >> This same converstaion has gone on for a couple of weeks off the mailing >> list as well, so I'd like to propose the following: >> >> 1) A separate Config payload is defined. >> 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or >> higher. Support does not mean you actually use it, just that it does >> not break your implementation. >> >> Comments? > >If Config becomes a separate payload type, then we're also going to need >a new exchange type to deal with any exchanges of config info that >happen after Phase 1 completes, such as those required for extended >authentication (draft-ietf-ipsec-isakmp-xauth-01.txt). The Informational >exchange no longer applies, and we aren't allowed to extend either Main >or Aggressive mode, so it seems a new Config exchange is necessary. > >Actually, I'm wondering now if adding a new exchange might eliminate the >need to "bump up" the ISAKMP version number(s), as it seems to me that >going to 1.1 might cause its own set of interoperability problems. That >would mean that we couldn't put Config payloads in Phase 1, but that might >be a small price to pay to avoid problems with the version number. How >would most implementations handle an unrecognized exchange type? > >-Shawn Mamros >E-mail to: smamros@BayNetworks.com From owner-ipsec Wed Mar 18 12:29:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04197 for ipsec-outgoing; Wed, 18 Mar 1998 12:28:16 -0500 (EST) Message-ID: <3510073F.E92CCB2C@redcreek.com> Date: Wed, 18 Mar 1998 09:41:19 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: comments on ...isakmp-mode-cfg-02 References: <199803180036.TAA03135@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > > I propose that when it comes to writing up new drafts, we will be writing > up ISAKMP v1.1. It isn't clear to me what to do when a responder receives > a packet with a minor version that is *greater* than its own. I think that > one should turn around and initiate with a packet containing major/minor > that one can work with. I.e. the initiator's packet is just "lost", but an > ISAKMP SA is setup. Yes, this makes sense. > [hmm. WAIT: > > o Minor Version (4 bits) - indicates the minor version of the ISAKMP > protocol in use. Implementations based on this version of the ISAKMP > Internet-Draft MUST set the Minor Version to 0. Implementations > *** > based on previous versions of ISAKMP Internet-Drafts MUST set the > Minor Version to 1. Implementations SHOULD never accept packets with > *** > a minor version number larger than its own, given the major version > numbers are identical. > > Isn't the 0/1 minor numbers reversed? Previous == 1, current = 0?] > I think so - I sent email to Doug Maughan asking about this just before v09 was released to the list, but figured either I was missing something, or that he didn't get the email in time. > Scott> something in temporarily, but when you start going to the trouble > Scott> of writing drafts, why not design it right? > > I think we are pretty close. Yup, and no sense stumbling now... From owner-ipsec Wed Mar 18 13:08:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04998 for ipsec-outgoing; Wed, 18 Mar 1998 13:06:18 -0500 (EST) From: Mingtai_Chang@ne.3com.com X-Lotus-FromDomain: 3COM To: srinu@trinc.com cc: ipsec@tis.com Message-ID: <852565CB.00566E1F.00@usboxmta.ne.3com.com> Date: Wed, 18 Mar 1998 13:19:59 -0500 Subject: Re: Why can't ? Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk >But you have not answered for some 'Questions' please.. >At 11:34 AM 3/16/98 -0500, you wrote: > > >>With respect to the draft draft-ietf-ipsec-arch-sec-03.txt >>Case 3. This case combines cases 1 and 2, adding end-to-end security >> between the sending and receiving hosts. It imposes no new >> requirements on the hosts or security gateways, other than a >> requirement for a security gateway to be configurable to pass >> IPsec traffic (including ISAKMP traffic) for hosts behind it. >> >> ============================================================= >> | | >> | ======================= | >> | | | | >> --|-----------------|--- --|-------------------|-- >>| | | | | | | | >>| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | >>| Intranet) | | Intranet) | >> ------------------------ ------------------------- >> admin. boundary admin. boundary >> >>Here consider that the host H1 sends out fragments or the incoming packets >>to the SG1 are fragmented then >>* Whether such situation arises that the incoming packets to a security >>gateway are fragmented ?. >Obviously it would. > >>all the packets (eventhough they are not destined for it, because >>reassembly occurs only at the destination) and apply tunnel mode i.e do >>IPsec processing on the reassembled packet and sends it out with or with >>out fragmentation as needed. srinu>> You have not answered whether the SG1 reassembles the fragmented >>packets from H1 and apply the IPsec OR discards them. >>(please answer me cnsidering the draft stds). I went back to draft-ietf-ipsec-arch-sec-04.txt, and this is what I gather from section 4.4.2: 1. On receiving a fragment from H1, SG1 goes through its SPD, looking for a match. 2. If the fragment matches no SPD entries, discard it. (More specifically, it "mismatches" some part of the selectors in every SPD entry which do not involve OPAQUE fields. In other words, it is ruled out umambiguously.) 3. If the fragment matches a SPD which does not involve Source and Destination Ports, SG1 accepts it and applies IPSec. (This implies SG2 must re-assemble. It also implies all associated fragments must go through SG2 before reaching H2.) 4. If the fragment matches a SPD which involves Source and Destination Ports, discard the fragment and send out ICMP PMTU. It is not clear from the draft if SG1 would handle the "Transport Layer Protocol" selector fields the same way as the Ports or not. To be consistent, it should. From owner-ipsec Wed Mar 18 13:45:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05705 for ipsec-outgoing; Wed, 18 Mar 1998 13:44:21 -0500 (EST) Message-ID: From: Roy Pereira To: "'Markku-Juhani Saarinen'" Cc: "'ipsec@tis.com'" Subject: RE: comments on draft-ietf-ipsec-ciph-cbc-02.txt Date: Wed, 18 Mar 1998 13:54:06 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The draft does mention that IDEA should use 8 rounds. It does however mention 4 rounds, so we'll take that out of the draft. >-----Original Message----- >From: Markku-Juhani Saarinen [SMTP:mjos@ssh.fi] >Sent: Friday, March 13, 1998 3:27 AM >To: Roy Pereira >Cc: 'ipsec@tis.com' >Subject: RE: comments on draft-ietf-ipsec-ciph-cbc-02.txt > > >> How many rounds do you suggest for IDEA? > >IDEA has eight rounds. > >4-round IDEA is a research toy, and should not even be called IDEA. >X. Lai and J. Massey never proposed it for real-life applications. > >It apparently creeped into the drafts because Applied Cryptography >says (2nd ed, p. 325): > > "(..) Currently the best attack against IDEA is faster than brute force > only for 2.5 rounds or less; 4 round IDEA would be twice as fast and, > as far as I know, just as secure." > >This does not reflect our 1998 knowledge. > >- mj > >Markku-Juhani O. Saarinen , SSH Communications Security Ltd > > From owner-ipsec Wed Mar 18 14:11:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06145 for ipsec-outgoing; Wed, 18 Mar 1998 14:09:19 -0500 (EST) Message-Id: <3.0.1.32.19980318170717.006ab134@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 18 Mar 1998 17:07:17 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: Is there any order? Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi folks, Sorry for sending again. I have done mistake regarding subject is concern. With respect to the draft-ietf-ipsec-esp-v2-04.txt 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. (case 1) o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. srinu>> Will the encryption algorithm which needs multiple of block size adds the padding that also ensures that the resulting ciphertext terminates on a 4-byte boundary. i.e the requirement of following paragraph(case2). (case2) o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. (case3) o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. srinu>> Is there any ordering of above three cases regarding how to process the packet. Like first apply the packet to process under do case2 and then case1 and then case3. Srinu>> If we are applying more than one cases, is it sure that pad length will not exceed 255 bytes. The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). Thank U Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Wed Mar 18 14:54:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06857 for ipsec-outgoing; Wed, 18 Mar 1998 14:53:20 -0500 (EST) Message-ID: From: Roy Pereira To: "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: RE: Summary of issues from RTP Date: Wed, 18 Mar 1998 15:06:10 -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 Also, some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces. The new IKE document does state: The length of nonce payload MUST be between 8 and 256 bytes inclusive. >-----Original Message----- >From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] >Sent: Tuesday, March 17, 1998 11:02 PM >To: ipsec@tis.com >Subject: Summary of issues from RTP > >-----BEGIN PGP SIGNED MESSAGE----- > > > {Don't ask me to present this in LA, I won't be there. The agenda doesn't >say whether or not it will be in an MBONE room. If so, I'll be listening, >DVMRP tunnel setup permitting. Email me if you can give me a tunnel!!!. > > I will update this list again on the 27th. I have taken the list, removed >the headers, signatures, and reworded some parts. Please let me know if I've >screwed up what you are saying.} > > 1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when > offered different sizes. (2 octets was required for the IPcomp people) > > 2. ISAKMP payloads had to be in the order they are documented in the draft. > Most ISAKMP payloads may be sent in any order. The exception is that > there is a proscribed relationship between some payloads > (i.e. proposal payloads, transform payloads, etc) > > 3. IP address in CERTs. Some people expected strings, other expected > 4 octets in ipAddress. If string, then is it: CN vs Unstructured or > subjectAltName. > > 4. Some implementations are sending a replay protection number of 0 > when manually keying. "I was under the impression sequence # 0 should > NEVER go on the wire, but hey, what do I know?" > > 5. Some vendors are not yet supporting DOI-07 wrt the AH transform type, > and the AUTH attribute. > {ed note: I wanted to give an example, but I can't seem to. > I read as far back as DOI-04, but didn't see any changes... unless > the issus is that the Auth(HMAC-MD5) wasn't being sent???} > > 6. Some vendors used old isakmp-08 certificate request format, but the data > attrbute used in the payload was incorrectly formatted (or missing). > {ed note: isakmp-09 was not publically available for the interop} > > 7. Some vendors did not like getting a key hash payload in rsa encryption > mode. > > 8. Some vendors were discarding entire ISAKMP packet when an unknown > notify payload was received. Only the single payload should be > discarded. > > 9. Some vendors did not like receiving certificate request payloads when > using pre shared keys. (The isakmp draft says certificate requests > payloads can exist in any message). > > 10. Some vendors did not like receiving certificate request payloads at any > time. > > 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4 > bytes. > > 12. Some vendors expected to see client ID's in phase 2. This caused > quick mode to complete, but fail to install the SA properly. > > 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies. This > caused premature termination of the negotiation. Speculation that > some vendors may terminate on any unknown status-level information > notifications. > > 14. (Relating to #5, and perhaps answering my question) > Some vendors were not sending both the AH Transform type (e.g. AH_MD5) > AND the Authentication Algorithm attribute (e.g. HMAC-MD5) > Some vendors would not accept receiving both the the Transform type > and the Authentication Algorithm attribute. > {ed: I must say that I'm not clear why we have two definitions here, and > I didn't find anything obvious by grepping my archives. If someone > tells me what month to look in...} > > {ed: I received nothing about any wire level transform level issues. This is > probably good.} > > :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON > Michael Richardson |Network and security consulting and contract >programming > Personal: HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">m >cr@sandelman.ottawa.on.ca. PGP key available. > Corporate: HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca>. > > > > > > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3ia >Charset: latin1 >Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > >iQB1AwUBNQ9HH9iXVu0RiA21AQF+KAL+PWlBkRYOCwoXtbm1nW73nbKP+fTS813e >k8JG6Hyhe9tgmI6gU57m1PiPL5GZAdZzyC1PCGFSfdsbnAT93kkuBgo8eBgD8ZcP >cnJhJtHdRexpCZXsL5cYQ5bwqc464dOT >=0OuF >-----END PGP SIGNATURE----- From owner-ipsec Wed Mar 18 14:55:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06894 for ipsec-outgoing; Wed, 18 Mar 1998 14:55:21 -0500 (EST) To: Derrell Piper Cc: ipsec@tis.com Subject: some comments on draft-ietf-ipsec-ipsec-doi-08.txt Date: Wed, 18 Mar 1998 13:55:47 -0500 From: Bill Sommerfeld Message-ID: <9803181355.aa18487@khitomer.epilogue.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk 4.6.2.5 ID_IPV4_ADDR_SUBNET The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. .... 4.6.2.7 ID_IPV6_ADDR_SUBNET The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. A couple comments: 1) This appears to specify a "fully general" netmask as opposed to a prefix-type netmask (some number of 1 bits filled in from the most significant bit of the address). Do we really need this generality? Current "longest match" routing table algorithms/data structures seem ideally suited for doing SA lookup, and I believe that those structures require contiguous netmasks to work happily. 2) A coworker who knows more about ipv6 than I do says that IPv6 has explicitly banned non-contiguous netmasks, so sending 16 bytes where a single byte of prefix length would do sounds like severe overkill. I'm not suggesting changing the wire protocol for IPV4_ADDR_SUBNET here, merely suggesting that implementations need only support contiguous netmasks and should or must only send contiguous netmasks... On the other hand, I think that IPv6 is still fluid enough that we can get away with changing the IPV6_ADDR_SUBNET encoding to send the prefix length as a single byte; I wouldn't be surprised if other IPv6-family protocols which send around address prefixes do it this way, also. - Bill From owner-ipsec Wed Mar 18 16:05:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07805 for ipsec-outgoing; Wed, 18 Mar 1998 16:03:21 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: is manual keying mandatory Date: Wed, 18 Mar 1998 16:15:28 -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 Is manual keying a required feature of IPSec? In other words, if you do not support manual keying then are you IPSec-compliant or not? There seams to bea bit of confusion surrounding this topic and I would like to see what people think. From owner-ipsec Wed Mar 18 16:05:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07821 for ipsec-outgoing; Wed, 18 Mar 1998 16:05:22 -0500 (EST) Message-ID: From: Roy Pereira To: Roy Pereira , "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: RE: Summary of issues from RTP Date: Wed, 18 Mar 1998 16:17:03 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I forgot to mention that some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET. >-----Original Message----- >From: Roy Pereira >Sent: Wednesday, March 18, 1998 3:06 PM >To: 'Michael C. Richardson'; 'ipsec@tis.com' >Subject: RE: Summary of issues from RTP > >Also, some vendors could not handle larger sized nonces (40 bytes) and >would only allow 20 byte nonces. The new IKE document does state: > > The length of nonce payload MUST be between 8 and 256 bytes > inclusive. > >>-----Original Message----- >>From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] >>Sent: Tuesday, March 17, 1998 11:02 PM >>To: ipsec@tis.com >>Subject: Summary of issues from RTP >> >>-----BEGIN PGP SIGNED MESSAGE----- >> >> >> {Don't ask me to present this in LA, I won't be there. The agenda doesn't >>say whether or not it will be in an MBONE room. If so, I'll be listening, >>DVMRP tunnel setup permitting. Email me if you can give me a tunnel!!!. >> >> I will update this list again on the 27th. I have taken the list, removed >>the headers, signatures, and reworded some parts. Please let me know if I've >>screwed up what you are saying.} >> >> 1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when >> offered different sizes. (2 octets was required for the IPcomp people) >> >> 2. ISAKMP payloads had to be in the order they are documented in the >>draft. >> Most ISAKMP payloads may be sent in any order. The exception is that >> there is a proscribed relationship between some payloads >> (i.e. proposal payloads, transform payloads, etc) >> >> 3. IP address in CERTs. Some people expected strings, other expected >> 4 octets in ipAddress. If string, then is it: CN vs Unstructured or >> subjectAltName. >> >> 4. Some implementations are sending a replay protection number of 0 >> when manually keying. "I was under the impression sequence # 0 should >> NEVER go on the wire, but hey, what do I know?" >> >> 5. Some vendors are not yet supporting DOI-07 wrt the AH transform type, >> and the AUTH attribute. >> {ed note: I wanted to give an example, but I can't seem to. >> I read as far back as DOI-04, but didn't see any changes... unless >> the issus is that the Auth(HMAC-MD5) wasn't being sent???} >> >> 6. Some vendors used old isakmp-08 certificate request format, but the >>data >> attrbute used in the payload was incorrectly formatted (or missing). >> {ed note: isakmp-09 was not publically available for the interop} >> >> 7. Some vendors did not like getting a key hash payload in rsa encryption >> mode. >> >> 8. Some vendors were discarding entire ISAKMP packet when an unknown >> notify payload was received. Only the single payload should be >> discarded. >> >> 9. Some vendors did not like receiving certificate request payloads when >> using pre shared keys. (The isakmp draft says certificate requests >> payloads can exist in any message). >> >> 10. Some vendors did not like receiving certificate request payloads at any >> time. >> >> 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4 >> bytes. >> >> 12. Some vendors expected to see client ID's in phase 2. This caused >> quick mode to complete, but fail to install the SA properly. >> >> 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies. >>This >> caused premature termination of the negotiation. Speculation that >> some vendors may terminate on any unknown status-level information >> notifications. >> >> 14. (Relating to #5, and perhaps answering my question) >> Some vendors were not sending both the AH Transform type (e.g. AH_MD5) >> AND the Authentication Algorithm attribute (e.g. HMAC-MD5) >> Some vendors would not accept receiving both the the Transform type >> and the Authentication Algorithm attribute. >> {ed: I must say that I'm not clear why we have two definitions here, and >> I didn't find anything obvious by grepping my archives. If someone >> tells me what month to look in...} >> >> {ed: I received nothing about any wire level transform level issues. This >>is >> probably good.} >> >> :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON >> Michael Richardson |Network and security consulting and contract >>programming >> Personal: >HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html"> >>m >>cr@sandelman.ottawa.on.ca. PGP key available. >> Corporate: >HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca>A >>>. >> >> >> >> >> >> >>-----BEGIN PGP SIGNATURE----- >>Version: 2.6.3ia >>Charset: latin1 >>Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface >> >>iQB1AwUBNQ9HH9iXVu0RiA21AQF+KAL+PWlBkRYOCwoXtbm1nW73nbKP+fTS813e >>k8JG6Hyhe9tgmI6gU57m1PiPL5GZAdZzyC1PCGFSfdsbnAT93kkuBgo8eBgD8ZcP >>cnJhJtHdRexpCZXsL5cYQ5bwqc464dOT >>=0OuF >>-----END PGP SIGNATURE----- From owner-ipsec Wed Mar 18 16:10:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07892 for ipsec-outgoing; Wed, 18 Mar 1998 16:10:20 -0500 (EST) From: Richard Guy Briggs Message-Id: <199803182046.PAA25256@conscoop.ottawa.on.ca> Subject: comments on draft-ietf-ipsec-doi-08.txt To: ipsec@tis.com Date: Wed, 18 Mar 1998 15:46:38 -0500 (EST) X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: application/X-pgp-message Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I have a few observations/questions about ipsec-doi-08: section: 4.4.4.2 ESP_DES second paragraph reads: All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5. I would propose changing the reference to the authentication and integrity facility to be more explicit of the standard used: All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by [HMACMD5]. I assume this is to be a combined trasform and not ESP used inside AH. similarly, section: 4.4.4.3 ESP_3DES second paragraph reads: All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5. I would propose changing the reference to the authentication and integrity facility to be more explicit of the standard used: All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by [HMACMD5]. Again, I assume this is to be a combined trasform and not ESP used inside AH. Slainte Mhath, rgb - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! rgb at conscoop dot ottawa dot on dot ca http://www.flora.org/afo/ http://www.achilles.net/~rgb/ Ottawa-Rideau Bioregion, Canada Please send all spam to root@127.0.0.1 "We left our footprints in the Earth And punched a hole right through the sky" -- S.Hogarth/J.Helmer(Marillion) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNRAyo9+sBuIhFagtAQFwsQP+I+PEfpTgt3N9y5r8vQ7eyWKlmOdKWWWH kxce3uBQSzOCvAU7nN2K6drg4sAT5WZVporeBsdrfPc+Cm03EpWkxdQpEcglw/Th 76p5RZrGUGY86iMUy+2eqqVOVJdhIJQ+FpfynnDZcgTkFqKQWMQRRfkWIq4P4sYy z7ZrcewpDkY= =e47S -----END PGP SIGNATURE----- From owner-ipsec Wed Mar 18 16:39:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08283 for ipsec-outgoing; Wed, 18 Mar 1998 16:38:22 -0500 (EST) Message-ID: From: William Dixon To: "'Roy Pereira'" , "IPSEC Mailing List (E-mail)" Subject: RE: is manual keying mandatory Date: Wed, 18 Mar 1998 13:51:35 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk Since we have put so much effort into IKE now, I don't think it should be a MUST. Wm William Dixon, Program Manager, IP Security Windows Networking Product Group > -----Original Message----- > From: Roy Pereira [SMTP:rpereira@TimeStep.com] > Sent: Wednesday, March 18, 1998 1:15 PM > To: IPSEC Mailing List (E-mail) > Subject: is manual keying mandatory > > Is manual keying a required feature of IPSec? > In other words, if you do not support manual keying then are you > IPSec-compliant or not? > > There seams to bea bit of confusion surrounding this topic and I would > like to see what people think. From owner-ipsec Wed Mar 18 17:20:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08589 for ipsec-outgoing; Wed, 18 Mar 1998 17:19:23 -0500 (EST) Date: Wed, 18 Mar 1998 17:32:15 -0500 (EST) Message-Id: <199803182232.RAA28484@carp.morningstar.com> From: Ben Rogers To: tytso@MIT.EDU, rgm-sec@htt-consult.com CC: ipsec@tis.com Subject: Wordsmithing Party? Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and Bob, It seems as if there has been quite a bit of traffic recently regarding simple semantic changes to the documents with the goal of improving their clarity and explicitness. Would it be useful to have a "Wordsmithing Party" at the LA IETF? Interested parties could come with their marked up versions of the drafts (or have these presented via a proxy if attendance is impossible). The goal would be to clean up the text as much as is possible in one fell swoop, and provide a quick and simple outlet for many people's frustrations without making any functional changes to the documents. The modified drafts could then be presented to the list immediately following the meeting and given to the IESG soon afterwards. This would serve as a last call for semantic changes, so further discussion would be drastically reduced. How would you both feel about such a party? Ascend would be willing to cover the cost of a meeting space and dinner for anyone interested in attending. ben From owner-ipsec Wed Mar 18 17:45:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08836 for ipsec-outgoing; Wed, 18 Mar 1998 17:44:22 -0500 (EST) Message-Id: <199803182258.RAA09847@relay.rv.tis.com> To: Roy Pereira cc: "IPSEC Mailing List (E-mail)" Subject: Re: is manual keying mandatory In-reply-to: Your message of "Wed, 18 Mar 1998 16:15:28 EST." Date: Wed, 18 Mar 1998 14:57:20 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Manual keying is a required feature of IPSEC, per discussions in Munich. Derrell From owner-ipsec Wed Mar 18 17:58:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08938 for ipsec-outgoing; Wed, 18 Mar 1998 17:58:23 -0500 (EST) Date: Wed, 18 Mar 1998 18:11:59 -0500 Message-Id: <199803182311.SAA26144@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ben@Ascend.COM Cc: rgm-sec@htt-consult.com, ipsec@tis.com In-Reply-To: Ben Rogers's message of Wed, 18 Mar 1998 17:32:15 -0500 (EST), <199803182232.RAA28484@carp.morningstar.com> Subject: Re: Wordsmithing Party? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 18 Mar 1998 17:32:15 -0500 (EST) From: Ben Rogers Would it be useful to have a "Wordsmithing Party" at the LA IETF? Interested parties could come with their marked up versions of the drafts (or have these presented via a proxy if attendance is impossible). The goal would be to clean up the text as much as is possible in one fell swoop, and provide a quick and simple outlet for many people's frustrations without making any functional changes to the documents. The modified drafts could then be presented to the list immediately following the meeting and given to the IESG soon afterwards. This would serve as a last call for semantic changes, so further discussion would be drastically reduced. At some point, as the saying goes, we need to shoot the engineers and ship the product. These drafts have been delayed for a very long time, and they are very, very, late. It is unfortunate --- and frustrating --- that people aren't bothering to read these documents until the very late minute. My concern is that no matter how long we delay publication, there will also be "one more word-smithing suggestion". In the mean time, we are suffering from not having a stable specification to code from, and we are also delaying other groups such as the IP Compression group, whose documents are blocking on ours. It's important for people to remember that the documents don't have to be perfect before we go to Proposed Standard. We can fix editorial changes at the Draft Standard stage, and even before we go to Full Standard. Bob Moskowitz is planning on setting up a web page where the clarifications to the specification can be collected both for the convenience of implementors and so we can make sure we get all of these fixes into the second revision of these documents. I believe that's probably the best place to put these sorts of editorial changes. - Ted From owner-ipsec Wed Mar 18 18:33:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09256 for ipsec-outgoing; Wed, 18 Mar 1998 18:31:21 -0500 (EST) Message-Id: <199803182344.XAA14394@orchard.arlington.ma.us> To: "IPSEC Mailing List (E-mail)" Subject: Re: is manual keying mandatory In-reply-to: Your message of "Wed, 18 Mar 1998 13:51:35 -0800 ." Date: Wed, 18 Mar 1998 18:44:22 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I feel strongly that manual keying should continue to be a MUST. There are going to be some times when the full complexity of ISAKMP won't be necessary; having manual keying universally available will improve interoperability and configurability in those situations... It also leaves makes more room for experimentation with new key management techniques, since a new key management system can be grafted on through the "manual" key management interface. It's also useful in testing to ensure that the transforms, etc., are in a position to really reject things like weak keys. All in all, it makes for a more open, modular system. - Bill From owner-ipsec Wed Mar 18 19:49:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09915 for ipsec-outgoing; Wed, 18 Mar 1998 19:48:26 -0500 (EST) From: Dan McDonald Message-Id: <199803190100.RAA11318@kebe.eng.sun.com> Subject: Re: is manual keying mandatory To: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Wed, 18 Mar 1998 17:00:12 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199803182344.XAA14394@orchard.arlington.ma.us> from "Bill Sommerfeld" at Mar 18, 98 06:44:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I sent my original reply directly to Roy. Sorry 'bout that. I've remembered another reason for MUST on manual keying that Bill hints at here... > It also leaves makes more room for experimentation with new key > management techniques, since a new key management system can be > grafted on through the "manual" key management interface. YES! And one example of a new key management system is any system for multicast keys! If you don't have manual keying, how can you add: AH spi 0x1969 authalg md5 src dst 224.124.12.2 That's a perfectly legal and valid multicast SA, and manual keying (or any first-cut KDC solution that makes you get the group key from a group key manager) is the only way to do that. Dan From owner-ipsec Wed Mar 18 22:51:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA11456 for ipsec-outgoing; Wed, 18 Mar 1998 22:49:26 -0500 (EST) Message-Id: <3.0.1.32.19980319093503.006d734c@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 19 Mar 1998 09:35:03 +0500 To: Mingtai_Chang@ne.3com.com From: K SrinivasRao Subject: Re: Why can't ? Cc: ipsec@tis.com In-Reply-To: <852565CB.00566E1F.00@usboxmta.ne.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:19 PM 3/18/98 -0500, Mingtai_Chang@ne.3com.com wrote: > > > > > > > > > > > >>But you have not answered for some 'Questions' please.. >>At 11:34 AM 3/16/98 -0500, you wrote: >> >> >>>With respect to the draft draft-ietf-ipsec-arch-sec-03.txt >>>Case 3. This case combines cases 1 and 2, adding end-to-end security >>> between the sending and receiving hosts. It imposes no new >>> requirements on the hosts or security gateways, other than a >>> requirement for a security gateway to be configurable to pass >>> IPsec traffic (including ISAKMP traffic) for hosts behind it. >>> >>> ============================================================= >>> | | >>> | ======================= | >>> | | | | >>> --|-----------------|--- --|-------------------|-- >>>| | | | | | | | >>>| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | >>>| Intranet) | | Intranet) | >>> ------------------------ ------------------------- >>> admin. boundary admin. boundary >>> >>>Here consider that the host H1 sends out fragments or the incoming >packets >>>to the SG1 are fragmented then >>>* Whether such situation arises that the incoming packets to a security >>>gateway are fragmented ?. >>Obviously it would. >> >>>all the packets (eventhough they are not destined for it, because >>>reassembly occurs only at the destination) and apply tunnel mode i.e do >>>IPsec processing on the reassembled packet and sends it out with or with >>>out fragmentation as needed. >srinu>> You have not answered whether the SG1 reassembles the fragmented > >>packets from H1 and apply the IPsec OR discards them. > >>(please answer me cnsidering the draft stds). > > > >I went back to draft-ietf-ipsec-arch-sec-04.txt, and this is what I gather >from section 4.4.2: > >1. On receiving a fragment from H1, SG1 goes through its SPD, looking for a >match. > >2. If the fragment matches no SPD entries, discard it. (More specifically, >it "mismatches" some part of the selectors in every SPD entry which do not >involve OPAQUE fields. In other words, it is ruled out umambiguously.) > >3. If the fragment matches a SPD which does not involve Source and >Destination Ports, SG1 accepts it and applies IPSec. (This implies SG2 must >re-assemble. It also implies all associated fragments must go through SG2 >before reaching H2.) > Srinu>> When the source and destination ports are not involved, I feel you are right, that we can apply apply IPsec on fragments. *But why we need re-assemble at SG1 ? When SG1 can nicely apply IPsec processing directly on fragments. So that at the receiver end when them IPsec processing is done we will get the actual fragment then we can re-assemble. Am I right ? >4. If the fragment matches a SPD which involves Source and Destination >Ports, discard the fragment and send out ICMP PMTU. > > > >It is not clear from the draft if SG1 would handle the "Transport Layer >Protocol" selector fields the same way as the Ports or not. To be >consistent, it should. Thank u Srinu From owner-ipsec Wed Mar 18 23:58:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA12137 for ipsec-outgoing; Wed, 18 Mar 1998 23:56:27 -0500 (EST) From: Jackie Wilson Message-Id: <199803190509.XAA26210@jhwilson.austin.ibm.com> Subject: Re: is manual keying mandatory (fwd) To: ipsec@tis.com Date: Wed, 18 Mar 1998 23:09:12 -0600 (CST) 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 agree. It will be some time before all boxes support ISAKMP, but they will need to be included in secure networks. This will help customers adopt ISAKMP as a standard if it is widely available. In a few years it could probably be phased out. Jackie Bill Sommerfeld wrote: > From owner-ipsec@portal.ex.tis.com Wed Mar 18 18:11:53 1998 > Message-Id: <199803182344.XAA14394@orchard.arlington.ma.us> > To: "IPSEC Mailing List (E-mail)" > Subject: Re: is manual keying mandatory > In-reply-to: Your message of "Wed, 18 Mar 1998 13:51:35 -0800 ." > > Date: Wed, 18 Mar 1998 18:44:22 -0500 > From: Bill Sommerfeld > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > > I feel strongly that manual keying should continue to be a MUST. > > There are going to be some times when the full complexity of ISAKMP > won't be necessary; having manual keying universally available will > improve interoperability and configurability in those situations... > > It also leaves makes more room for experimentation with new key > management techniques, since a new key management system can be > grafted on through the "manual" key management interface. > > It's also useful in testing to ensure that the transforms, etc., are > in a position to really reject things like weak keys. > > All in all, it makes for a more open, modular system. > > - Bill > -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec Thu Mar 19 07:47:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15741 for ipsec-outgoing; Thu, 19 Mar 1998 07:45:28 -0500 (EST) Date: Thu, 19 Mar 1998 07:45:28 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199803191245.HAA15741@portal.ex.tis.com> XAA08159; Wed, 18 Mar 1998 23:19:04 -0500 (EST) Date: Wed, 18 Mar 1998 23:19:03 -0500 (EST) From: Henry Spencer To: Roy Pereira cc: "IPSEC Mailing List (E-mail)" Subject: Re: is manual keying mandatory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk > Is manual keying a required feature of IPSec? > In other words, if you do not support manual keying then are you > IPSec-compliant or not? > There seams to bea bit of confusion... I don't see where the confusion comes from. draft-ietf-ipsec-arch-sec-04.txt repeatedly and explicitly states that support for both manual and automatic keying is mandatory. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Thu Mar 19 09:00:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16723 for ipsec-outgoing; Thu, 19 Mar 1998 08:59:28 -0500 (EST) Message-ID: <351126A1.863BD33B@ire-ma.com> Date: Thu, 19 Mar 1998 09:07:29 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Roy Pereira CC: "IPSEC Mailing List (E-mail)" Subject: Re: is manual keying mandatory References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I like Manual Keying and all the benefits of it - and I think it deserves SHOULD or MAY. I don't love at the extent of a MUST ;-) Roy Pereira wrote: > Is manual keying a required feature of IPSec? > In other words, if you do not support manual keying then are you > IPSec-compliant or not? > > There seams to bea bit of confusion surrounding this topic and I would > like to see what people think. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Thu Mar 19 09:00:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16701 for ipsec-outgoing; Thu, 19 Mar 1998 08:56:29 -0500 (EST) Message-Id: <199803191408.JAA04688@jekyll.piermont.com> To: William Dixon cc: "'Roy Pereira'" , "IPSEC Mailing List (E-mail)" Subject: Re: is manual keying mandatory In-reply-to: Your message of "Wed, 18 Mar 1998 13:51:35 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Mar 1998 09:08:58 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk William Dixon writes: > Since we have put so much effort into IKE now, I don't think it should be a > MUST. I would strongly disagree. VERY strongly. There are very real conditions in which people will want to exchange keys by methods other than IKE. The difficulty of providing manual configuration is so low that there is almost no savings in not making it mandatory. .pm > Wm > William Dixon, > Program Manager, IP Security > Windows Networking Product Group > > > > -----Original Message----- > > From: Roy Pereira [SMTP:rpereira@TimeStep.com] > > Sent: Wednesday, March 18, 1998 1:15 PM > > To: IPSEC Mailing List (E-mail) > > Subject: is manual keying mandatory > > > > Is manual keying a required feature of IPSec? > > In other words, if you do not support manual keying then are you > > IPSec-compliant or not? > > > > There seams to bea bit of confusion surrounding this topic and I would > > like to see what people think. From owner-ipsec Thu Mar 19 09:08:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16911 for ipsec-outgoing; Thu, 19 Mar 1998 09:08:31 -0500 (EST) Message-Id: <199803191421.JAA04709@jekyll.piermont.com> To: Jackie Wilson cc: ipsec@tis.com Subject: Re: is manual keying mandatory (fwd) In-reply-to: Your message of "Wed, 18 Mar 1998 23:09:12 CST." <199803190509.XAA26210@jhwilson.austin.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Mar 1998 09:21:17 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Jackie Wilson writes: > I agree. It will be some time before all boxes support ISAKMP, but > they will need to be included in secure networks. This will help > customers adopt ISAKMP as a standard if it is widely available. > > In a few years it could probably be phased out. I would be very against *ever* phasing out support for manual keying. .pm From owner-ipsec Thu Mar 19 09:11:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16945 for ipsec-outgoing; Thu, 19 Mar 1998 09:11:31 -0500 (EST) Message-Id: <199803191424.JAA10184@istari.sandelman.ottawa.on.ca> To: William Dixon CC: ipsec@tis.com Subject: Re: is manual keying mandatory In-reply-to: Your message of "Wed, 18 Mar 1998 13:51:35 PST." Date: Thu, 19 Mar 1998 09:24:46 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "William" == William Dixon writes: William> Since we have put so much effort into IKE now, I don't think it William> should be a MUST. IKE took a lot of effort because it is complicated. All complicated systems need good run time diagnostics tools. Manual keying is an important diagnostic tool because it verifies that the problem isn't in the IPsec portions. If supporting a manual keying API requires too much memory, or something, then alternate boot images may be an option. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNREqrNiXVu0RiA21AQFl4wMAwLEFCj0YzaRtauWRThZuCe6DSEtbL4xo ZMSGvd3IRpq9u4E1vk8gcJHoPRYwD4udL8hWsr1X6MSBlf3MoqEnuiUjT83+MYKl hx0kZZcRGwDBLwKIRlpKEYl1JszOX5m5 =uGLV -----END PGP SIGNATURE----- From owner-ipsec Thu Mar 19 10:08:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17733 for ipsec-outgoing; Thu, 19 Mar 1998 10:05:36 -0500 (EST) From: Charles Kunzinger To: Subject: Mandatory Algorithms for ESP? Message-ID: <5040300013972416000002L062*@MHS> Date: Thu, 19 Mar 1998 09:58:53 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk In reviewing the recent drafts, I found a discrepancy in the mandatory-to-support algorithms (transforms) between "Domain of Interpetation" (....doi-08.txt) and "ESP" (...esp-v2.04.txt). In the ESP draft, it states in Section 5 that a compliant ESP implementation MUST support DES in CBC Mode, HMAC with MD5, HMAC with SHA-1, NULL encryption, and NULL authentication. But in the DOI draft, section 4.4.4, the only mandatory-to-support transforms are NULL encryption and DES with HMAC_MD5. I'm guessing that the information in the DOI draft is valid, and that the ESP draft should be clarified to be consistent. If ESP were the controlling draft, there would be 5 mandatory-to-implement algorithms: ESP(DES-CBC, HMAC-MD5), ESP(DES-CBC, HMAC-SHA), ESP(DES-CBC, NULL), ESP(NULL, HMAC-MD5), and ESP(NULL, HMAC-SHA). This seems excessive, to say the least. However, in the DOI, we should probably also specify a mandatory-to-implement authentication attribute for use with NULL encryption, since ESP(NULL, NULL) is an illegal case. To net it out, I'm working on the assumption that the mandatory-to-implement algorithms (transforms?) for use in ESP are: a) ESP(DES-CBC, HMAC-MD5) and b) ESP(NULL, HMAC-MD5). Is this correct? Also, do the terms "algorithm" and "transform" mean the same thing, or is there some subtle difference that I need to be aware of? Thanks, Charlie ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tieline 8-444-4142 , External 1-919-254-4142 Fax: Tieline 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Thu Mar 19 10:28:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17962 for ipsec-outgoing; Thu, 19 Mar 1998 10:28:33 -0500 (EST) Message-Id: <98Mar19.104254est.11658@janus.tor.securecomputing.com> To: Charles Kunzinger cc: ipsec@tis.com Subject: Re: Mandatory Algorithms for ESP? References: <5040300013972416000002L062*@MHS> In-reply-to: Your message of "Thu, 19 Mar 1998 09:58:53 -0500". <5040300013972416000002L062*@MHS> From: "C. Harald Koch" Date: Thu, 19 Mar 1998 10:41:38 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <5040300013972416000002L062*@MHS>, Charles Kunzinger writes: > In reviewing the recent drafts, I found a discrepancy in the > mandatory-to-support algorithms (transforms) between > "Domain of Interpetation" (....doi-08.txt) and "ESP" (...esp-v2.04.txt). There's no discrepancy. The ESP document describes the MUST support algorithms for ESP itself. The DOI describes those algorithms and transforms that must be supported within the IKE framework. In other words, Just because something is implemented in ESP doesn't mean it has to be negotiable in IKE. They're different 'layers' of the stack, if you will. -- Harald Koch From owner-ipsec Thu Mar 19 10:39:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18089 for ipsec-outgoing; Thu, 19 Mar 1998 10:39:35 -0500 (EST) Date: Thu, 19 Mar 1998 10:50:58 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19980318130549.006a9978@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: K SrinivasRao From: Stephen Kent Subject: Re: kent Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Srinu, >With respect to the draft-ietf-ipsec-esp-v2-04.txt > >2.4 Padding (for Encryption) > >Several factors require or motivate use of the Padding field. > >(case 1) >o If an encryption algorithm is employed that requires the > plaintext to be a multiple of some number of bytes, e.g., the > block size of a block cipher, the Padding field is used to > fill the plaintext (consisting of the Payload Data, Pad Length > and Next Header fields, as well as the Padding) to the size > required by the algorithm. > >srinu>> Will the encryption algorithm which needs multiple of block size >adds the padding that also ensures that the resulting ciphertext terminates >on a 4-byte boundary. i.e the requirement of following paragraph(case2). > >(case2) >o Padding also may be required, irrespective of encryption > algorithm requirements, to ensure that the resulting > ciphertext terminates on a 4-byte boundary. Specifically, the > Pad Length and Next Header fields must be right aligned within > a 4-byte word, as illustrated in the ESP packet format figure > above, to ensure that the Authentication Data field (if > present) is aligned on a 4-byte boundary. > >(case3) >o Padding beyond that required for the algorithm or alignment > reasons cited above, may be used to conceal the actual length > of the payload, in support of (partial) traffic flow > confidentiality. However, inclusion of such additional > padding has adverse bandwidth implications and thus its use > should be undertaken with care. > >srinu>> Is there any ordering of above three cases regarding how to process >the packet. Like first apply the packet to process under do case2 and then >case1 and then case3. > >Srinu>> If we are applying more than one cases, is it sure that pad length >will not exceed 255 bytes. > >The sender MAY add 0-255 bytes of padding. Inclusion of the Padding >field in an ESP packet is optional, but all implementations MUST >support generation and consumption of padding. The padding >computation applies to the plaintext portion of the Payload Data, >exclusive of the IV (if present). > In all cases the padding is either the default (described in ESP) or algorithm-specific (defined in the algorithm). Steve From owner-ipsec Thu Mar 19 10:39:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18090 for ipsec-outgoing; Thu, 19 Mar 1998 10:39:35 -0500 (EST) Date: Thu, 19 Mar 1998 10:51:01 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Henry Spencer From: Stephen Kent Subject: Re: editorial notes on arch-sec-04 Cc: IP Security List Sender: owner-ipsec@ex.tis.com Precedence: bulk Henry, >A rereading of arch-sec-04 turned up a couple of small things, which I >*think* are entirely editorial in nature... > >1. If 4.4.3 needs to be fixed to reflect the reduced requirements for SA >re-use in 5.1.1, then I think the second-last paragraph of 4.4.1 needs >similar adjustments (especially that MUST at the end). > >2. Section 5 begins: > > The SPD must be consulted during the processing of all traffic > (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the > SPD requires distinct entries for inbound and outbound traffic. One > can think of this as separate SPDs (inbound vs. outbound). Note also > that a nominally separate SPD must be provided for each IPsec-enabled > interface. > >"Note that" is usually a short form of "As should be obvious from what has >been already explained", i.e. it is calling attention to something that >you could have already figured out. Except that here it's not; there is >not the slightest hint in previous material, and for that matter there's >relatively little hint in the rest of section 5, that such distinctions >are called for. I would delete "Note that" and "Note also that". > >I think these issues should be mentioned -- if only with a forward >reference -- in either 4.4.1 or 4.4.2. 4.4.1 repeatedly refers to *the* >SPD, strongly implying that there is only one. If we're not talking about >a model with separate SPDs, then this discussion has quietly added what >are effectively two more selectors to the list in 4.4.2, and a warning >there would be in order, since 4.4.2's wording implies that its list is >complete. We can reword this paragraph in section 5 and add some pointers in previous sections, as you suggested. We added this text when we realized that we had not made explicit the notion that SPDs are intirnsically directional, although I'm sure implementors have been following such an approach. After all, since SPD entries are cast in terms of soure and destinations addresses, directionality is critical. Steve From owner-ipsec Thu Mar 19 10:55:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18396 for ipsec-outgoing; Thu, 19 Mar 1998 10:54:35 -0500 (EST) From: Charles Kunzinger To: Subject: IKE Loose Ends? Message-ID: <5040300013976010000002L002*@MHS> Date: Thu, 19 Mar 1998 11:02:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk In the recent IKE draft (...oakley-07.txt), it says in Section 4 that several attributes are negotiated as part of an ISAKMP security association; namely, encryption algorithm, hash algorithm, authentication method, and group information. In the same section, it states that if a 'prf' is not negotiated, the HMAC version of the negotiated hash algorithm is used as a pseudo-random function. I have several questions, which I have not been able to find answers to in the latest round of drafts: 1) What process is used for the "negotiation"? I was not able to find anything in the IPSec DOI that lets me specify either a "ISAKMP hash function" or an "ISAKMP authentication method". Can someone point me to the right draft where I can find the necessary code points and/or attributes to use? 2) At the bottom of section 4.4 it says that IKE implementations must support MD5 and SHA (presumably as the hash algorithms?) Is this really correct, given that everywhere else throughout the IPSec drafts, the non-HMAC versions of MD5 and SHA are never mandatory, and are usually deprecated? 3) In Section 5 on page 10, it says that four different authentication methods are allowed with Main Mode or Aggressive Mode, but they are not enumerated anywhere. What are the methods? I'm guessing that they are the ones described in sections 5.1 through 5.4. Is this correct? 4) Besides being able to specify a "method", I would have expected that one would also need to specify an "algorithm" to be used by the "method". For example, if "digital signature" is the chosen authentication method, how does one specify which digital signature algorithm is actually being used (e.g., RSA or DSS)? Again, I find no code points in given in the DOI. Are there any references to the mechanics of the actual allowable algorithms (i.e., is there anything like a "here's how to use DSS with IKE" document?) Perhaps it's late in the cycle to be raising this type of question, but I've got a feeling that IKE's level of precision in the recent draft is fuzzy enough that there will be many opportunities for non-interoperable implementations to arise. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tieline 8-444-4142 , External 1-919-254-4142 Fax: Tieline 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Thu Mar 19 10:55:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18395 for ipsec-outgoing; Thu, 19 Mar 1998 10:54:34 -0500 (EST) From: Richard Guy Briggs Message-Id: <199803182332.SAA25662@conscoop.ottawa.on.ca> Subject: comments on draft-ietf-ipsec-ciph-3des-expiv-00.txt To: ipsec@tis.com Date: Wed, 18 Mar 1998 18:32:51 -0500 (EST) X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: application/X-pgp-message Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- section 3.1 Weak Keys paragraph 3 reads: However, if the first two independent 64-bit keys are equal (k1 == k2), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property. I believe this should be changed to deal with the case of k1 == k2 OR k2 == k3 for the reason stated, as presented in draft-ietf-ipsec-ciph-cbc-02.txt, section 2.3, subsection 3DES:. Slainte Mhath, rgb - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! rgb at conscoop dot ottawa dot on dot ca http://www.flora.org/afo/ http://www.achilles.net/~rgb/ Ottawa-Rideau Bioregion, Canada Please send all spam to root@127.0.0.1 "We left our footprints in the Earth And punched a hole right through the sky" -- S.Hogarth/J.Helmer(Marillion) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNRBZn9+sBuIhFagtAQFAEgQAk2lKDLN8qhZSM+ABkm5jyk8faigfjWSs zjembFedXZ3Kgcc9EYMQph0ji0jso95U1b+fufPyKAGCdknvmkeDqpWt5hyhLw7v rMS1OI5SVmUYgOVEjez6dJYI2Sl2UMI+1kGySerFMCO6bm9MaL5ydzflMOTYKsfW yE6U4w3eIaU= =mCTB -----END PGP SIGNATURE----- From owner-ipsec Thu Mar 19 11:04:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18526 for ipsec-outgoing; Thu, 19 Mar 1998 11:03:36 -0500 (EST) Date: Thu, 19 Mar 1998 11:14:57 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040300013972416000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Charles Kunzinger From: Stephen Kent Subject: Re: Mandatory Algorithms for ESP? Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, I haven't looked at the mkst recent DOI, but the subset of ESP algorithm combinations you cited is definately not sufficient. Certainly we want to support DES-CBC encryption, and NULL encryption has recently been added back to ESP, by popular demand. For authentication, NULL is an option (i.e., encryption only), as is HMAC. The only long term ambiguity that may still exist is whether HMAC must be supported for both SHA-1 and MD5. This is the sort of analysis that leads to the ESP mandatory algorithm list, and I note that it has not changed for quite some time, with the exception of the very recent addition of NULL encryption as an explicit algorithm. Steve From owner-ipsec Thu Mar 19 11:04:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18527 for ipsec-outgoing; Thu, 19 Mar 1998 11:03:36 -0500 (EST) Date: Thu, 19 Mar 1998 11:16:58 -0500 Message-Id: <9803191616.AA00927@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: perry@piermont.com Cc: jhwilson@austin.ibm.com, ipsec@tis.com Subject: Re: is manual keying mandatory (fwd) References: <199803190509.XAA26210@jhwilson.austin.ibm.com> <199803191421.JAA04709@jekyll.piermont.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Perry" == Perry E Metzger writes: Perry> Jackie Wilson writes: >> I agree. It will be some time before all boxes support ISAKMP, >> but they will need to be included in secure networks. This will >> help customers adopt ISAKMP as a standard if it is widely >> available. >> >> In a few years it could probably be phased out. Perry> I would be very against *ever* phasing out support for manual Perry> keying. I agree with Perry. Consider ARP. It's been around for decades... but people still support static ARP entries. paul From owner-ipsec Thu Mar 19 11:23:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18725 for ipsec-outgoing; Thu, 19 Mar 1998 11:22:36 -0500 (EST) From: Phil Servita To: bkavsan@ire-ma.com CC: ipsec@tis.com In-reply-to: <351126A1.863BD33B@ire-ma.com> (message from Bronislav Kavsan on Thu, 19 Mar 1998 09:07:29 -0500) Subject: Re: is manual keying mandatory Date: Thu, 19 Mar 98 11:35:36 -0500 Message-ID: <9803191135.aa03798@khitomer.epilogue.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk I like Manual Keying and all the benefits of it - and I think it deserves SHOULD or MAY. I don't love at the extent of a MUST ;-) What do people think of the following statement: "I like PING and all the benefits of it - and i think it deserves SHOULD or MAY. I dont think it deserves a MUST. After all, given all the work we have done on TCP, we should be able to phase out PING from the host requirements." Manual keying will always be useful, even if just for verifying that the low-level mechanisms are working. I think it needs to stay at MUST. -phil From owner-ipsec Thu Mar 19 11:23:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18738 for ipsec-outgoing; Thu, 19 Mar 1998 11:23:34 -0500 (EST) Message-Id: <3.0.5.32.19980319113550.00934370@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Mar 1998 11:35:50 -0500 To: Jackie Wilson , ipsec@tis.com From: Robert Moskowitz Subject: Re: is manual keying mandatory (fwd) In-Reply-To: <199803190509.XAA26210@jhwilson.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:09 PM 3/18/98 -0600, Jackie Wilson wrote: >I agree. It will be some time before all boxes support ISAKMP, but >they will need to be included in secure networks. This will help >customers adopt ISAKMP as a standard if it is widely available. Jackie, I disagree with you as to the above reason, in general. Or perhaps you are thinking as I, but use different verbage. Some KMP is needed to rekey sessions. As an ex-network support person, I would not want to deploy non-rekeyable technology anymore except for certain imbedded systems that are either: already running in a semi-secure environment, or are still just too limited to support the cost of IKE code. (think about what it takes to protect a system from electric leaks under your car hood and you might get some ideas about cost overruns). >In a few years it could probably be phased out. In time IKE preshared MIGHT be universally available, but to play with other KMPs, manual keying is important. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 11:24:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18751 for ipsec-outgoing; Thu, 19 Mar 1998 11:24:35 -0500 (EST) Message-Id: <3.0.5.32.19980319113009.009ed400@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Mar 1998 11:30:09 -0500 To: Bill Sommerfeld , "IPSEC Mailing List (E-mail)" From: Robert Moskowitz Subject: Re: is manual keying mandatory In-Reply-To: <199803182344.XAA14394@orchard.arlington.ma.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:44 PM 3/18/98 -0500, Bill Sommerfeld wrote: >I feel strongly that manual keying should continue to be a MUST. I also feel it should remain a MUST. >There are going to be some times when the full complexity of ISAKMP >won't be necessary; having manual keying universally available will >improve interoperability and configurability in those situations... I was jsut talking to Rodney about this. There will be other KMPs, like smartcards injecting session keying material based on barometric pressure or some such. >It also leaves makes more room for experimentation with new key >management techniques, since a new key management system can be >grafted on through the "manual" key management interface. There will be business requirements that will leverage off of this. Perhaps an imbedded system might only do manual keys, so the workstation that talks to that system (say a pacemaker, how is that for an 'imbedded system') will also need to support manual keys. >It's also useful in testing to ensure that the transforms, etc., are >in a position to really reject things like weak keys. probably the only way to test weak keys code paths. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 11:41:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19000 for ipsec-outgoing; Thu, 19 Mar 1998 11:41:37 -0500 (EST) From: "Larry Backman" To: , "Jackie Wilson" Cc: Subject: Re: is manual keying mandatory (fwd) Date: Thu, 19 Mar 1998 11:54:51 -0500 Message-ID: <01bd5357$bc02c440$9285b4cf@sarda.cportcorp.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 >> In a few years it could probably be phased out. > >I would be very against *ever* phasing out support for manual keying. > Loud agreement. Manual keying is akin to having a ping and traceroute in ones application toolbox. When things go wrong its good to have simple tools and a least common denominator by which those simple tools can be used.... L. From owner-ipsec Thu Mar 19 11:51:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19038 for ipsec-outgoing; Thu, 19 Mar 1998 11:50:38 -0500 (EST) Message-Id: <199803191702.JAA00286@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Charles Kunzinger Cc: ipsec@tis.com Subject: Re: IKE Loose Ends? In-Reply-To: Your message of "Thu, 19 Mar 1998 11:02:23 EST." <5040300013976010000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Mar 1998 09:02:42 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, > In the recent IKE draft (...oakley-07.txt), it says in Section 4 that several > attributes are negotiated as part of an ISAKMP security > association; namely, encryption algorithm, hash algorithm, authentication > method, and group information. > > In the same section, it states that if a 'prf' is not negotiated, the HMAC > version of the negotiated hash algorithm is used as a > pseudo-random function. > > I have several questions, which I have not been able to find answers to in the > latest round of drafts: > > 1) What process is used for the "negotiation"? I was not able to find anything > in the IPSec DOI that lets me specify either > a "ISAKMP hash function" or an "ISAKMP authentication method". Can someone > point me to the right draft where I can find > the necessary code points and/or attributes to use? IKE attribute negotiation is not covered by the IPSec DOI. The IPSec DOI covers IPSec negotiation. The attributes necessary to do IKE negotiation are in the IKE draft itself, in Appendix A. It has been like this from the start. > 2) At the bottom of section 4.4 it says that IKE implementations must support > MD5 and SHA (presumably as the hash algorithms?) > Is this really correct, given that everywhere else throughout the IPSec drafts, > the non-HMAC versions of MD5 and SHA are never > mandatory, and are usually deprecated? Yes, this is correct. Native (non-HMAC'd) hashing is used in IKE for things like IV generation and signature payload generation. Section 4 specifically says, "The negotiated hash function must be supported in both native and HMAC modes." > 3) In Section 5 on page 10, it says that four different authentication methods > are allowed with Main Mode or Aggressive Mode, but > they are not enumerated anywhere. What are the methods? I'm guessing that > they are the ones described in sections 5.1 through > 5.4. Is this correct? Correct. > 4) Besides being able to specify a "method", I would have expected that one > would also need to specify an "algorithm" to be used > by the "method". For example, if "digital signature" is the chosen > authentication method, how does one specify which digital signature > algorithm is actually being used (e.g., RSA or DSS)? Again, I find no code > points in given in the DOI. Are there any references to the > mechanics of the actual allowable algorithms (i.e., is there anything like a > "here's how to use DSS with IKE" document?) Appendix A specifies different magic numbers for RSA signatures and DSS signatures. Also, section 5.1 (the actual signature-based authentication method) mentions the encoding differences for each. Again, the DOI will not help you with IKE negotiation issues. Those are wholly contained in the IKE document. > Perhaps it's late in the cycle to be raising this type of question, but I've > got a feeling that IKE's level of precision in the recent draft is > fuzzy enough that there will be many opportunities for non-interoperable > implementations to arise. Is this recent draft worse than the previous ones? Am I becoming more fuzzy as time goes on? I sure hope not. Most of the changes from 6 to 7 were editorial and were supposed to make things _more_ clear. In fact, all but one (the IANA Considerations change) were hashed out on this list so I'd be surprised and disappointed if they actually increased the fuzz. It's a complicated protocol and you're right, there's lots of opportunity to do something wrong. There are quite a few independent, interoperable implementations though. Dan. From owner-ipsec Thu Mar 19 12:24:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19280 for ipsec-outgoing; Thu, 19 Mar 1998 12:22:39 -0500 (EST) Message-Id: <3.0.5.32.19980319123626.009666f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Mar 1998 12:36:26 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Please review draft-ietf-pppext-l2tp-sec-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I know we are busy, but the L2TP crowd is working on their use of IPsec for protecting L2TP sessions. I do not mean at all to question the abilities of the L2TP wg, but I suspect that there are many people here that are not on that list, and may want to study this, the first use of IPsec by another wg. One interesting comment I have of this draft, is it does not actually reference any of the IPsec documents. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 12:26:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19305 for ipsec-outgoing; Thu, 19 Mar 1998 12:25:38 -0500 (EST) Message-Id: <199803191739.MAA11553@relay.rv.tis.com> To: Charles Kunzinger cc: ipsec@tis.com Subject: Re: Mandatory Algorithms for ESP? In-reply-to: Your message of "Thu, 19 Mar 1998 09:58:53 EST." <5040300013972416000002L062*@MHS> Date: Thu, 19 Mar 1998 09:39:13 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, Actually, the DOI is in error here. The text under the DOI ESP section dates from before SHA-1 was a mandatory authentication algorithm. Since the AH section (correctly) mandates MD5 and SHA-1, the correct interpretation for ESP should be that support for both MD5 and SHA-1 are MUST's. In summary, the following combinations are required by the IPSEC DOI: AH(HMAC-MD5) AH(HMAC-SHA) ESP_NULL(HMAC-MD5) ESP_NULL(HMAC-SHA) ESP_DES() ESP_DES(HMAC-MD5) ESP_DES(HMAC-SHA) >Also, do the terms "algorithm" and "transform" mean the same thing, or is there >some subtle difference that I need to be aware of? "Algorithm" is more general than "transform," in the sense that DES is the base cryptographic algorithm used by the ESP_DES transform. In other words, the ESP_DES transform describes how to apply the DES algorithm in the ESP context. The resulting method, including things like how to do padding and IV generation, results in a defined transform. Derrell From owner-ipsec Thu Mar 19 12:43:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19434 for ipsec-outgoing; Thu, 19 Mar 1998 12:42:37 -0500 (EST) Message-Id: <199803191753.MAA29966@relay.hq.tis.com> To: Charles Kunzinger cc: ipsec@tis.com Subject: Re: IKE Loose Ends? In-reply-to: Your message of "Thu, 19 Mar 1998 11:02:23 EST." <5040300013976010000002L002*@MHS> Date: Thu, 19 Mar 1998 09:55:52 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, > I have several questions, which I have not been able to find answers to in the > latest round of drafts: > > 1) What process is used for the "negotiation"? I was not able to find anything > in the IPSec DOI that lets me specify either > a "ISAKMP hash function" or an "ISAKMP authentication method". Can someone > point me to the right draft where I can find > the necessary code points and/or attributes to use? "Negotiation" means the use of the PRF attribute during the Phase 1 SA negotiation (see pg. 34). > 2) At the bottom of section 4.4 it says that IKE implementations must support > MD5 and SHA (presumably as the hash algorithms?) > Is this really correct, given that everywhere else throughout the IPSec drafts, > the non-HMAC versions of MD5 and SHA are never > mandatory, and are usually deprecated? The reference to "MD5" and "SHA" are just names. The IKE draft consistently states, as you point out, that the HMAC versions are the ones that are used in IKE (see pg. 7). > 3) In Section 5 on page 10, it says that four different authentication methods > are allowed with Main Mode or Aggressive Mode, but > they are not enumerated anywhere. What are the methods? I'm guessing that > they are the ones described in sections 5.1 through > 5.4. Is this correct? >From the IKE draft: Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method. These correspond to the following sections as you note. > 4) Besides being able to specify a "method", I would have expected that one > would also need to specify an "algorithm" to be used > by the "method". For example, if "digital signature" is the chosen > authentication method, how does one specify which digital signature > algorithm is actually being used (e.g., RSA or DSS)? Again, I find no code > points in given in the DOI. Are there any references to the > mechanics of the actual allowable algorithms (i.e., is there anything like a > "here's how to use DSS with IKE" document?) What is a code point? Section 5.1, for example, defines how the different signature algorithms (RSA vs. DSS) must be encoded by an IKE implementation (see pp. 10-11). The IKE draft is paired with the base ISAKMP draft and the IPSEC DOI. There are no other drafts describing additional interpretations or implementation mechanisms/tricks. Derrell From owner-ipsec Thu Mar 19 12:47:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19463 for ipsec-outgoing; Thu, 19 Mar 1998 12:47:38 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: FW: is manual keying mandatory Date: Thu, 19 Mar 1998 12:58:25 -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 >-----Original Message----- >From: Dan McDonald [SMTP:danmcd@eng.Sun.COM] >Sent: Wednesday, March 18, 1998 5:18 PM >To: Roy Pereira >Subject: Re: is manual keying mandatory > >> Is manual keying a required feature of IPSec? > >Absolutely! > >It always has been, and always will be. > >> In other words, if you do not support manual keying then are you >> IPSec-compliant or not? > >I would say you are not fully compliant. How much this will _really matter_ >might be the subject of some debate, but if you don't do manual keying, >you're not fully compliant. > >> There seams to bea bit of confusion surrounding this topic and I would like >> to see what people think. > >We've pounded this one into the ground a million times, folks. Let's spend >our time on more important topics, huh? :) > >Dan From owner-ipsec Thu Mar 19 13:16:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19839 for ipsec-outgoing; Thu, 19 Mar 1998 13:15:38 -0500 (EST) Message-ID: From: Roy Pereira To: "'Richard Guy Briggs'" , "'ipsec@tis.com'" Subject: RE: comments on draft-ietf-ipsec-ciph-3des-expiv-00.txt Date: Thu, 19 Mar 1998 13:26:24 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Please read for the current IPSec draft that detailed 3DES operation within ESP. >-----Original Message----- >From: Richard Guy Briggs [SMTP:rgb@conscoop.ottawa.on.ca] >Sent: Wednesday, March 18, 1998 6:33 PM >To: ipsec@tis.com >Subject: comments on draft-ietf-ipsec-ciph-3des-expiv-00.txt > > << File: ATT00184.att >> From owner-ipsec Thu Mar 19 13:25:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20000 for ipsec-outgoing; Thu, 19 Mar 1998 13:24:37 -0500 (EST) Message-Id: <3.0.5.32.19980319133259.009fe8f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Mar 1998 13:32:59 -0500 To: Richard Guy Briggs , ipsec@tis.com From: Robert Moskowitz Subject: Re: comments on draft-ietf-ipsec-ciph-3des-expiv-00.txt In-Reply-To: <199803182332.SAA25662@conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:32 PM 3/18/98 -0500, Richard Guy Briggs wrote: >Attachment Converted: "C:\DATA\SECURITY\EUDORA\FILES\comments on draft-ietf-ipsec-ci" > Please note that this draft is no longer being considered by the wg, it has been superceded by: draft-ietf-ipsec-ciph-cbc-02.txt One of the problems with the draft system is how to get old drafts like this off the ftp server. I will see about getting it cleaned up.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 13:25:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20014 for ipsec-outgoing; Thu, 19 Mar 1998 13:25:39 -0500 (EST) Message-Id: <3.0.5.32.19980319133415.0099ed20@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Mar 1998 13:34:15 -0500 To: Paul Koning , perry@piermont.com From: Robert Moskowitz Subject: Re: is manual keying mandatory (fwd) Cc: jhwilson@austin.ibm.com, ipsec@tis.com In-Reply-To: <9803191616.AA00927@kona.> References: <199803190509.XAA26210@jhwilson.austin.ibm.com> <199803191421.JAA04709@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:16 AM 3/19/98 -0500, Paul Koning wrote: > >Consider ARP. It's been around for decades... but people still >support static ARP entries. And it has worked out as a powerful tool to make sure that the only systems working on your DMZ are the ones you put there. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 13:32:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20072 for ipsec-outgoing; Thu, 19 Mar 1998 13:31:38 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sumit Vakil" To: kunzinge@us.ibm.com cc: ipsec@tis.com Message-ID: <862565CC.00650A0F.00@mwgate02.mw.3com.com> Date: Thu, 19 Mar 1998 12:48:15 -0600 Subject: Re: IKE Loose Ends? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, Please see my comments below. Sumit A. Vakil 3Com, Corp. kunzinge@us.ibm.com on 03/19/98 10:02:23 AM To: ipsec@tis.com cc: Subject: IKE Loose Ends? In the recent IKE draft (...oakley-07.txt), it says in Section 4 that several attributes are negotiated as part of an ISAKMP security association; namely, encryption algorithm, hash algorithm, authentication method, and group information. In the same section, it states that if a 'prf' is not negotiated, the HMAC version of the negotiated hash algorithm is used as a pseudo-random function. I have several questions, which I have not been able to find answers to in the latest round of drafts: 1) What process is used for the "negotiation"? I was not able to find anything in the IPSec DOI that lets me specify either a "ISAKMP hash function" or an "ISAKMP authentication method". Can someone point me to the right draft where I can find the necessary code points and/or attributes to use? >> The hash function and the authentication method can be negotiated using the appropriate attributes from the data attributes list in Appendix A of the IKE draft. These data attributes are used in the transform payload during SA negotiation. Both the ISAKMP and IKE drafts describe how to use the various ISAKMP payloads during the negotiation phase. 2) At the bottom of section 4.4 it says that IKE implementations must support MD5 and SHA (presumably as the hash algorithms?) Is this really correct, given that everywhere else throughout the IPSec drafts, the non-HMAC versions of MD5 and SHA are never mandatory, and are usually deprecated? >> In IKE, the hash algorithms are always used in HMAC form (if the PRF is not negotiated) to do the key and hash derivations. The only exception is the hash of the certificate used with public key encryption based authentication during phase 1. So I think that the document is ok here. 3) In Section 5 on page 10, it says that four different authentication methods are allowed with Main Mode or Aggressive Mode, but they are not enumerated anywhere. What are the methods? I'm guessing that they are the ones described in sections 5.1 through 5.4. Is this correct? >> Section 5 does enumerate the authentication methods: "Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key." And yes, the ways to use the various authentication methods with Main mode and Aggressive mode are described in sections 5.1 through 5.4. 4) Besides being able to specify a "method", I would have expected that one would also need to specify an "algorithm" to be used by the "method". For example, if "digital signature" is the chosen authentication method, how does one specify which digital signature algorithm is actually being used (e.g., RSA or DSS)? Again, I find no code points in given in the DOI. Are there any references to the mechanics of the actual allowable algorithms (i.e., is there anything like a "here's how to use DSS with IKE" document?) >> Check out Appendix A of IKE. It defines the values that the authentication method attribute can take. It includes DSS signatures and RSA signatures. Perhaps it's late in the cycle to be raising this type of question, but I've got a feeling that IKE's level of precision in the recent draft is fuzzy enough that there will be many opportunities for non-interoperable implementations to arise. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tieline 8-444-4142 , External 1-919-254-4142 Fax: Tieline 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Thu Mar 19 13:42:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20221 for ipsec-outgoing; Thu, 19 Mar 1998 13:41:40 -0500 (EST) Message-ID: <01BD5325.5F8EA080.adams@cisco.com> From: Rob Adams Reply-To: "adams@cisco.com" To: "'Robert Moskowitz'" , "'Jackie Wilson'" , "'ipsec@tis.com'" Subject: RE: is manual keying mandatory (fwd) Date: Thu, 19 Mar 1998 10:54:06 -0800 Organization: Cisco Systems X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I personally don't see the need for a MUST on manual keying. I've been saying this for over a year so that isn't anything new. The reasons for a manual keying MUST so far seem to be wrapped around support and other KMP's. I don't see either of these as interoperability issues but as product issues. The other issue is to interop with legacy systems that do not support an automated way of exchanging keys. Well.... The architecture document states, section 3.2 p. 8: "This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. " To be IPSEC compliant, I need to have automatic keying and I need to use IKE. So legacy systems are already not part of the scope of this architecture. This statement also indicates a required method of interoperability that is not manual keying. The other reason I've seen is because it is easy. I'm not sure we should include things in the architecture because they are easy. Otherwise, ESP with NULL authentication and encryption would be required. I feel strongly that manual keying should not be a MUST. SHOULD or MAY is fine. MUST seems like overkill. Based on the traffic this has cause, I'm sure we'll still end up with manual keying being a MUST, but what the heck, we haven't seen a good flame in a week or two. -Rob -----Original Message----- From: Robert Moskowitz [SMTP:rgm-sec@htt-consult.com] Sent: Thursday, March 19, 1998 8:36 AM To: Jackie Wilson; ipsec@tis.com Subject: Re: is manual keying mandatory (fwd) At 11:09 PM 3/18/98 -0600, Jackie Wilson wrote: >I agree. It will be some time before all boxes support ISAKMP, but >they will need to be included in secure networks. This will help >customers adopt ISAKMP as a standard if it is widely available. Jackie, I disagree with you as to the above reason, in general. Or perhaps you are thinking as I, but use different verbage. Some KMP is needed to rekey sessions. As an ex-network support person, I would not want to deploy non-rekeyable technology anymore except for certain imbedded systems that are either: already running in a semi-secure environment, or are still just too limited to support the cost of IKE code. (think about what it takes to protect a system from electric leaks under your car hood and you might get some ideas about cost overruns). >In a few years it could probably be phased out. In time IKE preshared MIGHT be universally available, but to play with other KMPs, manual keying is important. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Mar 19 14:38:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20822 for ipsec-outgoing; Thu, 19 Mar 1998 14:36:41 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sumit Vakil" To: ipsec@tis.com Message-ID: <862565CC.006BD685.00@mwgate02.mw.3com.com> Date: Thu, 19 Mar 1998 13:53:15 -0600 Subject: Sec. Arch. and ICMP PMTU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Various parts of the security architecture document suggest forwarding ICMP PMTU messages received by a SG to a host or a set of hosts. Section B.3.1 is one such place. Consider the example in section B.3.1. H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 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) So, what SG1 gets from R1 is [IP-3] [ICMP hdr] [IP-2] [Atleast 64 bits of the ESP header]. It is most likely that all of the IP-1 header and its data are absent from the ICMP. Even if it were possible to identify the host that sent the offending packet, what would could be sent back to the host? Normally (no IPsec anywhere), the host would be sent the ICMP PMTU with IP-1 and atleast 64 bits of data. But since IP-1 is no longer available... Thanks, Sumit A. Vakil 3Com, Corp. From owner-ipsec Thu Mar 19 14:54:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20991 for ipsec-outgoing; Thu, 19 Mar 1998 14:54:37 -0500 (EST) Date: Thu, 19 Mar 1998 15:02:52 -0500 (EST) From: "W. Mark Townsley" To: Robert Moskowitz cc: ipsec@tis.com Subject: Re: Please review draft-ietf-pppext-l2tp-sec-03.txt In-Reply-To: <3.0.5.32.19980319123626.009666f0@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Note that this draft does not technically use IPSec, though some of the techniques are similar. Comments from other working groups are always welcome. On Thu, 19 Mar 1998, Robert Moskowitz wrote: > I know we are busy, but the L2TP crowd is working on their use of IPsec for > protecting L2TP sessions. > > I do not mean at all to question the abilities of the L2TP wg, but I > suspect that there are many people here that are not on that list, and may > want to study this, the first use of IPsec by another wg. > > One interesting comment I have of this draft, is it does not actually > reference any of the IPsec documents. > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > From owner-ipsec Thu Mar 19 17:04:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21981 for ipsec-outgoing; Thu, 19 Mar 1998 17:03:40 -0500 (EST) Message-Id: <2.2.32.19980319221600.006f5894@trix.cisco.com> X-Sender: sned@trix.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Mar 1998 14:16:00 -0800 To: ipsec@tis.com From: Steve Sneddon Subject: Re: is manual keying mandatory Cc: William Dixon , "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk Could somebody planning a *commercial* IPSec implementation which actually uses manual keying spend a few minutes and tell us the details of transmittal and storage of keys, etc.? Could they also discuss any "insecurities" inherent in the problem? Or is manual keying in the spec only for diagnostic sorts of images and bakeoffs? TIA At 09:24 AM 3/19/98 -0500, Michael C. Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "William" == William Dixon writes: > > William> Since we have put so much effort into IKE now, I don't think it > William> should be a MUST. > > IKE took a lot of effort because it is complicated. All complicated systems >need good run time diagnostics tools. Manual keying is an important >diagnostic tool because it verifies that the problem isn't in the IPsec >portions. > If supporting a manual keying API requires too much memory, or something, >then alternate boot images may be an option. > > :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON > Michael Richardson |Network and security consulting and contract programming > Personal: mcr@sandelman.ottawa.on.ca. PGP key available. > Corporate: sales@sandelman.ottawa.on.ca. > > > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3ia >Charset: latin1 >Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > >iQB1AwUBNREqrNiXVu0RiA21AQFl4wMAwLEFCj0YzaRtauWRThZuCe6DSEtbL4xo >ZMSGvd3IRpq9u4E1vk8gcJHoPRYwD4udL8hWsr1X6MSBlf3MoqEnuiUjT83+MYKl >hx0kZZcRGwDBLwKIRlpKEYl1JszOX5m5 >=uGLV >-----END PGP SIGNATURE----- > > From owner-ipsec Thu Mar 19 17:15:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22069 for ipsec-outgoing; Thu, 19 Mar 1998 17:14:40 -0500 (EST) Date: Thu, 19 Mar 1998 17:28:15 -0500 (EST) From: bede@mitre.org (Bede McCall) Message-Id: <199803192228.RAA17222@zorch.mitre.org> To: ipsec@tis.com Subject: RE: is manual keying mandatory Sender: owner-ipsec@ex.tis.com Precedence: bulk This "MUST" is a non-issue at this point, having been beaten to a pulp, so there is really no point in arguing the reasons behind the "MUST" decision once again. Nonetheless, at the risk of continuing a completed debate I'll summarize: the cost of implementing manual keying is essentially nil, having been the first thing most developers did anyway, and it's potentially a very useful and powerful admin tool for products after they've been fielded. Furthermore, having it guarantees there will always be some (albeit rudimentary, like static ARP entries) form of keying available to your IPSEC. The requirement to support some form of automatic keying for compliance is in addition to, not a replacement for, the manual keying requirement. -- Bede McCall The MITRE Corporation Tel: (781) 271-2839 202 Burlington Road FAX: (781) 271-2423 Bedford, Massachusetts 01730-1420 From owner-ipsec Thu Mar 19 17:33:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22260 for ipsec-outgoing; Thu, 19 Mar 1998 17:32:39 -0500 (EST) Message-Id: <199803192244.OAA00775@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Steve Sneddon Cc: ipsec@tis.com, William Dixon , "Michael C. Richardson" Subject: Re: is manual keying mandatory In-Reply-To: Your message of "Thu, 19 Mar 1998 14:16:00 PST." <2.2.32.19980319221600.006f5894@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Mar 1998 14:44:17 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk A certain paranoid individual (guess who) once told me that he would trust an armed military courier delivering keys created from a known and trusted random source more than he would trust the output of a Diffie-Hellman exchange. There's not many of these people (or maybe there are and I just hang around with the wrong crowd) but that's a use of manual keying. The insecurity of manual keying would depend on the implementation and the general security of the box it's running on. Actually, considering that most commercial implementations aren't going to let buyers look under the hood, paranoia of that sort might not be all that unfounded. People could cut corners in their random number generator or lessen the size of their Diffie-Hellman exponential to speed up exponentiation. If you're really paranoid and/or have extremely sensitive data to protect and you don't have absolute trust in your vendor then manual keying might make sense. Dan. > Could somebody planning a *commercial* IPSec implementation which actually > uses manual keying spend a few minutes and tell us the details of > transmittal and storage of keys, etc.? Could they also discuss any > "insecurities" inherent in the problem? Or is manual keying in the spec only > for diagnostic sorts of images and bakeoffs? From owner-ipsec Thu Mar 19 18:15:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA22617 for ipsec-outgoing; Thu, 19 Mar 1998 18:13:42 -0500 (EST) To: Robert Moskowitz Cc: ipsec@tis.com In-Reply-To: Your message of "Thu, 19 Mar 1998 12:36:26 EST" <3.0.5.32.19980319123626.009666f0@homebase.htt-consult.com> From: Dave Johnson Reply-To: Dave Johnson Subject: Re: Please review draft-ietf-pppext-l2tp-sec-03.txt Date: Thu, 19 Mar 1998 18:27:01 -0500 Message-ID: <10242.890350021@ux6.sp.cs.cmu.edu> Sender: owner-ipsec@ex.tis.com Precedence: bulk >I know we are busy, but the L2TP crowd is working on their use of IPsec for >protecting L2TP sessions. > >I do not mean at all to question the abilities of the L2TP wg, but I >suspect that there are many people here that are not on that list, and may >want to study this, the first use of IPsec by another wg. > >One interesting comment I have of this draft, is it does not actually >reference any of the IPsec documents. > > >Robert Moskowitz >ICSA >Security Interest EMail: rgm-sec@htt-consult.com I'm not sure who was "first", but Mobile IP for IPv6 also uses IPsec for authentication and replay protection on Binding Updates. If any IPsec folks want to review the latest draft, it is available as draft-ietf-mobileip-ipv6-05.txt. At least we reference the IPsec documents :-). Dave From owner-ipsec Thu Mar 19 19:44:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23229 for ipsec-outgoing; Thu, 19 Mar 1998 19:42:40 -0500 (EST) Message-ID: <3511BD0C.FF902314@ire-ma.com> Date: Thu, 19 Mar 1998 19:49:16 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Re: is manual keying mandatory References: <199803192244.OAA00775@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I am in total agreement with Dan and Steve. If someone wants to commercialize manual keying - you need to start with SKIX IETF WG first (Symmetric Key Infrastructure Architecture), similar to PKIX, or use standards like X.17, etc for key distribution and management - and I wish you lots of luck with it! But if someone wants to use manual keying for diagnostics only - go ahead - and differentiate your product in the marketplace, but don't drag me into it by mandating this useful, but IMHO optional capability. Slava Kavsan IRE Daniel Harkins wrote: > A certain paranoid individual (guess who) once told me that he would trust > an armed military courier delivering keys created from a known and trusted > random source more than he would trust the output of a Diffie-Hellman exchange. > There's not many of these people (or maybe there are and I just hang around > with the wrong crowd) but that's a use of manual keying. > > The insecurity of manual keying would depend on the implementation and > the general security of the box it's running on. > > Actually, considering that most commercial implementations aren't going > to let buyers look under the hood, paranoia of that sort might not be all > that unfounded. People could cut corners in their random number generator > or lessen the size of their Diffie-Hellman exponential to speed up > exponentiation. If you're really paranoid and/or have extremely sensitive > data to protect and you don't have absolute trust in your vendor then > manual keying might make sense. > > Dan. > > > Could somebody planning a *commercial* IPSec implementation which actually > > uses manual keying spend a few minutes and tell us the details of > > transmittal and storage of keys, etc.? Could they also discuss any > > "insecurities" inherent in the problem? Or is manual keying in the spec only > > for diagnostic sorts of images and bakeoffs? From owner-ipsec Thu Mar 19 19:49:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23275 for ipsec-outgoing; Thu, 19 Mar 1998 19:48:42 -0500 (EST) Message-ID: <3511BE8D.AA935A2B@ire-ma.com> Date: Thu, 19 Mar 1998 19:55:41 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: [Fwd: is manual keying mandatory] Content-Type: multipart/mixed; boundary="------------EF72AC25582EAC82B10129A7" X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------EF72AC25582EAC82B10129A7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I meant X9.17 there (not X.17) --------------EF72AC25582EAC82B10129A7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3511BD0C.FF902314@ire-ma.com> Date: Thu, 19 Mar 1998 19:49:16 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Re: is manual keying mandatory References: <199803192244.OAA00775@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am in total agreement with Dan and Steve. If someone wants to commercialize manual keying - you need to start with SKIX IETF WG first (Symmetric Key Infrastructure Architecture), similar to PKIX, or use standards like X.17, etc for key distribution and management - and I wish you lots of luck with it! But if someone wants to use manual keying for diagnostics only - go ahead - and differentiate your product in the marketplace, but don't drag me into it by mandating this useful, but IMHO optional capability. Slava Kavsan IRE Daniel Harkins wrote: > A certain paranoid individual (guess who) once told me that he would trust > an armed military courier delivering keys created from a known and trusted > random source more than he would trust the output of a Diffie-Hellman exchange. > There's not many of these people (or maybe there are and I just hang around > with the wrong crowd) but that's a use of manual keying. > > The insecurity of manual keying would depend on the implementation and > the general security of the box it's running on. > > Actually, considering that most commercial implementations aren't going > to let buyers look under the hood, paranoia of that sort might not be all > that unfounded. People could cut corners in their random number generator > or lessen the size of their Diffie-Hellman exponential to speed up > exponentiation. If you're really paranoid and/or have extremely sensitive > data to protect and you don't have absolute trust in your vendor then > manual keying might make sense. > > Dan. > > > Could somebody planning a *commercial* IPSec implementation which actually > > uses manual keying spend a few minutes and tell us the details of > > transmittal and storage of keys, etc.? Could they also discuss any > > "insecurities" inherent in the problem? Or is manual keying in the spec only > > for diagnostic sorts of images and bakeoffs? --------------EF72AC25582EAC82B10129A7-- From owner-ipsec Thu Mar 19 20:13:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA23450 for ipsec-outgoing; Thu, 19 Mar 1998 20:12:41 -0500 (EST) Date: Thu, 19 Mar 1998 17:24:44 -0800 Message-Id: <199803200124.RAA24796@gump.eng.ascend.com> From: Karl Fox To: Dave Johnson Cc: Robert Moskowitz , ipsec@tis.com Subject: Re: Please review draft-ietf-pppext-l2tp-sec-03.txt In-Reply-To: <10242.890350021@ux6.sp.cs.cmu.edu> References: <3.0.5.32.19980319123626.009666f0@homebase.htt-consult.com> <10242.890350021@ux6.sp.cs.cmu.edu> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave Johnson writes: > >I know we are busy, but the L2TP crowd is working on their use of IPsec for > >protecting L2TP sessions. > > > >I do not mean at all to question the abilities of the L2TP wg, but I > >suspect that there are many people here that are not on that list, and may > >want to study this, the first use of IPsec by another wg. > > > >One interesting comment I have of this draft, is it does not actually > >reference any of the IPsec documents. > > > > > >Robert Moskowitz > >ICSA > >Security Interest EMail: rgm-sec@htt-consult.com > > > I'm not sure who was "first", but Mobile IP for IPv6 also uses IPsec > for authentication and replay protection on Binding Updates. If any > IPsec folks want to review the latest draft, it is available as > draft-ietf-mobileip-ipv6-05.txt. At least we reference the IPsec > documents :-). There is another PPPEXT document, draft-ietf-pppext-l2tp-security-01.txt which does reference the IPSEC drafts. It's also the L2TP security document currently preferred by the working group. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri Mar 20 09:49:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28673 for ipsec-outgoing; Fri, 20 Mar 1998 09:42:52 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" , "'Michael C. Richardson'" Subject: RE: Summary of issues from RTP Date: Fri, 20 Mar 1998 09:55: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 >---------- >From: Michael C. Richardson[SMTP:mcr@sandelman.ottawa.on.ca] >Sent: Tuesday, March 17, 1998 11:01 PM >To: ipsec@tis.com >Subject: Summary of issues from RTP > > > 3. IP address in CERTs. Some people expected strings, other expected > 4 octets in ipAddress. If string, then is it: CN vs Unstructured or > subjectAltName. It is never a string when encoded in subjectAltName, if it is then their CA has incorrectly encoded the value. See X.509 (which points to RFC-791), or PKIX part 1. I don't think clarification is needed (see below). I believe consensus was that if IP Addresses (or dns name or rfc822) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG. > > 6. Some vendors used old isakmp-08 certificate request format, but the data > attrbute used in the payload was incorrectly formatted (or missing). > {ed note: isakmp-09 was not publically available for the interop} Then was it really the old format? :) >Bye. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com >From ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-06.txt "When the subjectAltName extension contains a iPAddress, the address shall be stored in the octet string in "network byte order," as specified in RFC791. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string must contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string must contain exactly sixteen octets." > > From owner-ipsec Fri Mar 20 13:55:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00703 for ipsec-outgoing; Fri, 20 Mar 1998 13:52:46 -0500 (EST) Date: Fri, 20 Mar 1998 14:05:53 -0500 Message-Id: <199803201905.OAA26919@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: [Marcia Beaulieu: Re: Is it possible to multicast IPSEC] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I've asked the IETF secretariat if they could move us to a multicast room, and they very graciously agreed to do so. So our IPSEC working group meeting *will* be multicast, for the benefit of those who can't make it to LA for one reason or another.... - Ted ------- Forwarded Message X-Sender: mbeaulie@ietf.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Mar 1998 15:07:21 -0500 To: "Theodore Y. Ts'o" From: Marcia Beaulieu Subject: Re: Is it possible to multicast IPSEC In-Reply-To: <199803191950.OAA26634@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ted, Yes, we do have a multicast room available at that time. I will make the room change for IPSEC from Emerald Bay to San Gabriel. Making a room change is not that bad of a change and since I have to room available I'm happy to do that. Marcia ********************************************************************** Marcia Beaulieu Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-758-5913 ------- End Forwarded Message From owner-ipsec Fri Mar 20 13:56:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00772 for ipsec-outgoing; Fri, 20 Mar 1998 13:56:47 -0500 (EST) Date: Fri, 20 Mar 1998 14:10:16 -0500 Message-Id: <199803201910.OAA26923@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com In-Reply-To: Steve Sneddon's message of Thu, 19 Mar 1998 14:16:00 -0800, <2.2.32.19980319221600.006f5894@trix.cisco.com> Subject: Re: is manual keying mandatory Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Can we please consider the issue of manual keying to be closed, please? We've gone over this before many times --- and the only way to make progress is to avoid continually revisiting issues which we've decided in the past. The Security Architecture document very clearly states that manual keying is mandatory; there shouldn't be any confusion on this issue at all. Some of you may disagree with this decision, but we decided this months ago. Can we please give it a rest? - Ted From owner-ipsec Fri Mar 20 17:03:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02092 for ipsec-outgoing; Fri, 20 Mar 1998 17:02:49 -0500 (EST) Message-Id: <199803202008.PAA28002@ns.ietf.org> To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: The IESG SUBJECT: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 20 Mar 1998 15:08:18 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o Security Architecture for the Internet Protocol o IP Authentication Header o The Use of HMAC-MD5-96 within ESP and AH o The Use of HMAC-SHA-1-96 within ESP and AH o The ESP DES-CBC Cipher Algorithm With Explicit IV o IP Encapsulating Security Payload (ESP) o The Internet IP Security Domain of Interpretation for ISAKMP o Internet Security Association and Key Management Protocol (ISAKMP) o The Internet Key Exchange (IKE) o The NULL Encryption Algorithm and Its Use With IPsec The IESG will also consider publication of the following Internet-Drafts as Informational RFCs: o IP Security Protocol Working Group to consider IP Security Document Roadmap o The OAKLEY Key Determination Protocol The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 11, 1998. Files can be obtained via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-05.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt From owner-ipsec Fri Mar 20 17:03:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02066 for ipsec-outgoing; Fri, 20 Mar 1998 17:01:52 -0500 (EST) Message-ID: <3512B97E.3595898B@baynetworks.com> Date: Fri, 20 Mar 1998 13:46:22 -0500 From: "Daniel C. Fox" Reply-To: dfox@BayNetworks.COM Organization: Bay Networks, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "adams@cisco.com" CC: "'Robert Moskowitz'" , "'Jackie Wilson'" , "'ipsec@tis.com'" Subject: Re: is manual keying mandatory (fwd) References: <01BD5325.5F8EA080.adams@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >From a practical standpoint, Diffie-Hellman is extremely expensive in lessor-powered CPU's, and in an environment where IP interfaces are coming up and down in a dynamic environment (say PPP over demand-dial ISDN lines), doing Diffie-Hellman again and again may be more taxing on the CPU than Triple DES encryption on full throughput. In such an environment, one can use a different KMP than ISAKMP/Oakley. But it would be beneficial to know that a completely inexpensive key management system (manual keying) is universally supported in all IP Security implementations. My customers would then be able to make the choice themselves whether to go with (relatively expensive) automated keying or (relatively inexpensive) manual keying, regardless of the IPSec-capable devices they were interfacing with. For this reason, I feel it is necessary to keep manual keying support a MUST. -- Daniel C. Fox Software Project Leader Tel: +1 978-916-4216 Remote Access Server Division Fax: +1 978-916-4789 Bay Networks, Inc. From owner-ipsec Fri Mar 20 17:03:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02112 for ipsec-outgoing; Fri, 20 Mar 1998 17:03:49 -0500 (EST) From: Charles Kunzinger To: Cc: Subject: Re: Please review draft-ietf-pppext-l2tp-sec-03.txt Message-ID: <5040300014035851000002L012*@MHS> Date: Fri, 20 Mar 1998 15:08:12 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, Did you steer us to the right draft? "Draft-ietf-pppext-l2tp-sec-03.txt" seems to only cover the case where IPSec is not available. There is a different draft, "Securing L2TP using IPSec" (draft-ietf-pppext-l2tp-security-01.txt), that may be more relevant, since it discusses several examples of how IPSec would be applied to a set of representative L2TP-based configurations. I'll try to post some comments on the draft "Securing L2TP using IPSec" draft later today. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tieline 8-444-4142 , External 1-919-254-4142 Fax: Tieline 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Fri Mar 20 17:22:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02208 for ipsec-outgoing; Fri, 20 Mar 1998 17:21:50 -0500 (EST) Date: Fri, 20 Mar 1998 17:35:24 -0500 (EST) Message-Id: <199803202235.RAA29786@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Last call and the DOI Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Interestingly, ESP_DES or ESP_3DES with no auth attribute does not mean the same as any of the other ESP_* without an auth attribute. Namely, the following portions of DOI-08 prevent us from negotiating an DES or 3DES transform without authentication. Perhaps this should be fixed? 4.4.4.2 ESP_DES The ESP_DES type specifies a generic DES transform using DES-CBC. The actual protection suite is determined in concert with an associated SA attribute list. A generic transform is currently undefined. All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.3 ESP_3DES The ESP_3DES type specifies a generic triple-DES transform. The actual protection suite is determined in concert with an associated SA attribute list. The generic transform is currently undefined. All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5. From owner-ipsec Fri Mar 20 17:31:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02259 for ipsec-outgoing; Fri, 20 Mar 1998 17:30:50 -0500 (EST) Date: Fri, 20 Mar 1998 17:44:04 -0500 Message-Id: <199803202244.RAA27062@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Agenda for the LA wg meeting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi folks, My apologies for sending this out earlier, but both Bob and I have been rather busy and distracted with other things, like actually getting the documents pushed out to IETF last call. :-) We need to start planning our IPSEC meeting in LA. Submission of agenda topics are hereby solicited. Please send them to Bob and I. Thanks!! - Ted From owner-ipsec Fri Mar 20 19:08:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02844 for ipsec-outgoing; Fri, 20 Mar 1998 19:06:51 -0500 (EST) Message-Id: <199803210017.TAA09484@relay.hq.tis.com> To: ben@Ascend.COM (Ben Rogers) cc: ipsec@tis.com Subject: Re: Last call and the DOI In-reply-to: Your message of "Fri, 20 Mar 1998 17:35:24 EST." <199803202235.RAA29786@carp.morningstar.com> Date: Fri, 20 Mar 1998 16:19:52 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, The DOI doesn't intend to say that you must use that combination together, it's saying that you have to support that combination to be compliant. Section 4.5 further talks about the use of Auth with ESP_NULL: Authentication Algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4 Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use. There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case. When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal. When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL. I'll certainly try to further clarify this in a subsequent revision, but I'd appreciate some explicit suggestions on additional wording, as it seems okay to me as it is... Derrell From owner-ipsec Fri Mar 20 20:38:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03390 for ipsec-outgoing; Fri, 20 Mar 1998 20:36:51 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: dfox@BayNetworks.COM cc: ipsec@tis.com, "John O Goyo" Message-ID: <882565CE.000907C0.00@domino_c02.certicom.com> Date: Fri, 20 Mar 1998 17:41:21 -0800 Subject: Re: is manual keying mandatory (fwd) Sender: owner-ipsec@ex.tis.com Precedence: bulk >>From a practical standpoint, Diffie-Hellman is >extremely expensive in lessor-powered CPU's This is good reason retain and fix the elliptic curve options in Oakley. It's much faster and a better system solution than manual keys. Paul dfox@BayNetworks.COM on 03/20/98 10:46:22 AM Please respond to dfox@BayNetworks.COM To: adams@cisco.com cc: rgm-sec@htt-consult.com, jhwilson@austin.ibm.com, ipsec@tis.com (bcc: Paul Lambert/Certicom) Subject: Re: is manual keying mandatory (fwd) >From a practical standpoint, Diffie-Hellman is extremely expensive in lessor-powered CPU's, and in an environment where IP interfaces are coming up and down in a dynamic environment (say PPP over demand-dial ISDN lines), doing Diffie-Hellman again and again may be more taxing on the CPU than Triple DES encryption on full throughput. In such an environment, one can use a different KMP than ISAKMP/Oakley. But it would be beneficial to know that a completely inexpensive key management system (manual keying) is universally supported in all IP Security implementations. My customers would then be able to make the choice themselves whether to go with (relatively expensive) automated keying or (relatively inexpensive) manual keying, regardless of the IPSec-capable devices they were interfacing with. For this reason, I feel it is necessary to keep manual keying support a MUST. -- Daniel C. Fox Software Project Leader Tel: +1 978-916-4216 Remote Access Server Division Fax: +1 978-916-4789 Bay Networks, Inc. From owner-ipsec Fri Mar 20 21:05:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA03550 for ipsec-outgoing; Fri, 20 Mar 1998 21:04:51 -0500 (EST) Message-ID: <35132368.794B@cs.umass.edu> Date: Fri, 20 Mar 1998 21:18:16 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: matt@ljo.dec.com CC: IP Security List Subject: Re: new IKE draft References: <9803161550.AA26962@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt Thomas writes: >>> (Also what happens in the non-Revised mode if the identification payload is >>> larger than what can be encrypted via the RSA modulus?) Good question. How do existing implementations behave when this situation arises? I presume there are routine length checks in place to calculate the PKCS#1 padding length and avoid buffer overflows. Is the exchange aborted, are some bits of the ID payload ignored (bad), is the ID payload silently reduced mod N by the crypto engine before encryption (bad) ?? For encryption, PKCS #1 focuses on the common use of RSA to provide a "digital envelope" bearing a key for a conventional symmetric cipher. Secure RSA modulus and symmetric key sizes being what they are, the issue of plaintext that exceeds the block size just doesn't arise in that situation. I'm not aware of any standard that specifies the use of pure RSA for multi- block encryption, presumably in some CBC-like block chaining mode. I think the right way to fix this problem is to prohibit use of the "original" Authentication with Public Key Encryption method if RSA encryption is used and the length of the ID payload exceeds the data length limit specified in Section 8 of PKCS #1. If this condition is discovered after the method of 5.2 has been proposed (and maybe even accepted), the exchange must be aborted and a different authentication method negotiated. If only the responder encountered a length problem, then the initiator might propose use of Auth. with PK Encryption again. *sigh* I'm not sure whether there's a good Notify message type for the responder to send in this case. Maybe Invalid-Exchange-Type or Invalid-Key-Information? Comments? Incidentally, there doesn't seem to be a bibliographic reference in the draft for PKCS #1: [RSA93] RSA Laboratories, "PKCS #1: RSA Encryption Standard", version 1.5, RSA Data Security, Inc. Public-Key Cryptography Standards (PKCS), November 1993, ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-1.asc -Lewis "damn good...and very dangerous" --P.M. Netanyahu, of Ehud Tenebaum From owner-ipsec Sat Mar 21 09:35:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07087 for ipsec-outgoing; Sat, 21 Mar 1998 09:30:52 -0500 (EST) Message-Id: <3.0.1.32.19980321174347.006dd8d4@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 21 Mar 1998 17:43:47 +0500 To: ipsec@tis.com From: rohit Subject: Wrong pointer ?? Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk hi All, In IpSec-Architecture-mar98 draft Section B.3.4 Per socket maintainence of pmtu data have the follwing para "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. " I think the references shown, (Section B.2.2 and Section B.2.3) should be Section B.3.2 and Section B.3.3 , Right ? -Regards Rohit ******************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ******************************************************************* From owner-ipsec Sat Mar 21 14:06:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08597 for ipsec-outgoing; Sat, 21 Mar 1998 14:02:52 -0500 (EST) Date: Sat, 21 Mar 1998 14:16:30 -0500 (EST) Message-Id: <199803211916.OAA11480@carp.morningstar.com> From: Ben Rogers To: "Derrell D. Piper" CC: ipsec@tis.com Subject: Re: Last call and the DOI In-Reply-To: <199803210020.QAA26047@drawbridge.ascend.com> References: <199803202235.RAA29786@carp.morningstar.com> <199803210020.QAA26047@drawbridge.ascend.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, Derrell D. Piper writes: > I'll certainly try to further clarify this in a subsequent revision, but I'd > appreciate some explicit suggestions on additional wording, as it seems okay > to me as it is... I'd suggest the following change in order to make the (DES and 3DES) sections mimic the following sections for other encryption algorithms. I was getting confused as to whether the different wording for the DES and 3DES sections meant we should treat them differently. 4.4.4.2 ESP_DES The ESP_DES type specifies the DES transform defined in [DES]. All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.3 ESP_3DES The ESP_3DES type specifies the triple-DES transform defined in [ESPCBC]. All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5. ben From owner-ipsec Mon Mar 23 08:23:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA21696 for ipsec-outgoing; Mon, 23 Mar 1998 08:10:58 -0500 (EST) Message-Id: <3.0.1.32.19980323185642.006aa2e8@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 23 Mar 1998 18:56:42 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: Deletion of SA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, Suppose the SA life time for the SA between H1 and H2 is in terms of Kbytes. Consider the scenario where H1 sends out messages which lead to expiry of an SA on H1 but the host H2 does not receive all the datagrams (which are lost). H1 goes ahead and negotiates a new SA since its SA has expired. However, H2's SA does not expire since it has not received all the messages. Now, if this SA in H2 is not shared between security policy entries, it will remain forever (until the system reboots) as H1 would have negotiated a new SA and will use that for future communications. Should H1 send a delete payload to delete H2's SA? What happens if it is not sent? In the same context, if the sequence counter in the sender H1 recycles and the anti-replay service is enabled, H1 starts negotiation of a new SA to send this packet on. How does H2 delete the SA it has? By getting a delete payload from H1? Or, it expires in the normal way? From owner-ipsec Mon Mar 23 09:52:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22422 for ipsec-outgoing; Mon, 23 Mar 1998 09:49:58 -0500 (EST) Message-Id: <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Deletion of SA In-reply-to: Your message of "Mon, 23 Mar 1998 18:56:42 +0500." <3.0.1.32.19980323185642.006aa2e8@192.9.200.10> Date: Mon, 23 Mar 1998 10:07:33 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "K" == K SrinivasRao writes: K> since it has not received all the messages. Now, if this SA in K> H2 is not shared between security policy entries, it will K> remain forever (until the system reboots) as H1 would have H2 may have a (configurable) maximum lifetime on all SA's as well. I think this would be a prudent implementation detail. K> negotiated a new SA and will use that for future K> communications. Should H1 send a delete payload to delete H2's Yes. That should occur as part of the new SA being setup. A question though: is a "delete" too strong here? Perhaps a "please delete this SA in X seconds" would be more appropriate? As a notify perhaps? That would allow SA's to be negotiated in advance of being used, and it also allows the network to drain. Someone tell me that this is already addressed, but I just missed that part :-) K> negotiation of a new SA to send this packet on. How does H2 K> delete the SA it has? By getting a delete payload from H1? Or, K> it expires in the normal way? I think a sender should always try and send a delete payload when it removes an outgoing SA. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Mon Mar 23 11:12:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23318 for ipsec-outgoing; Mon, 23 Mar 1998 11:10:09 -0500 (EST) Message-ID: <35167DB4.7A82@lucent.com> Date: Mon, 23 Mar 1998 10:20:20 -0500 From: "Kumar V. Vemuri" Reply-To: vvkumar@lucent.com Organization: Bell Labs X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: DNS and VPN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk All, I've been studying IPSec in the context of VPN for a while now, and was hoping someone could answer the following questions : a. consider the case where one has an IPSec client that is connected to multiple corporate sites through a single ISP PPP-link, with packets being transmitted out in the tunnel-mode to said multiple sites, with IPSec originating at the PC Client and not at the ISP RAS. How does one now resolve DNS queries across sites ? (e.g., if more than one tunnel is simultaneously active, unless a packet interceptor in the protocol stack intercepts a DNS request and then knows which IPSec tunnel - pardon the use of the term here, what I mean is the stream through which tunnel mode packets are being transmitted - to send the query through and modifies the DNS address accordingly, how can the name be resolved ? Also, does not Win 95 permit one to have only two choices for DNS ? Does this restrict the number of tunnels to a maximum of two ?). I think it is unlikely that the client would know, (if incomplete names were used), which DNS server to use to resolve the name, and DNS namespaces hidden within the corporate network namespace would therefore not be accessible - if it knew, and Windows did not permit one to dynamically change the DNS IP, then one would have to intercept the packet in the protocol stack and perform client side NAT to get to the correct server, right ?. If FQDNs were used, then I guess one could argue that even though one was limited to two DNS IP addresses in the base OS, one could change IP addresses on outgoing packets to get to query transmitted to the appropriate corporate network destination, (or to multiple corporate network destinations in a parallel effort to get the DNS query resolved). b. Recently, in the mailing list, there was a reference to the SKIX (Symmetic Key Infrastructure Architecture) and X.17 in the context of symmetric manual keying in IPSec. Could someone point me to the appropriate IETF group that is working on this ? Would appreciate any clarifications and/or pointers to information, even if some of you feel these questions are trivial, since I'd really like to get some answers. Thank You. -- Kumar V. Vemuri, Member of Technical Staff, Lucent Technologies Bell Labs. -- From owner-ipsec Mon Mar 23 11:32:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23560 for ipsec-outgoing; Mon, 23 Mar 1998 11:32:07 -0500 (EST) Message-Id: <199803231648.LAA00512@morden.sandelman.ottawa.on.ca> To: vvkumar@lucent.com CC: ipsec@tis.com Subject: Re: DNS and VPN In-reply-to: Your message of "Mon, 23 Mar 1998 10:20:20 EST." <35167DB4.7A82@lucent.com> Date: Mon, 23 Mar 1998 11:48:55 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Kumar" == Kumar V Vemuri writes: Kumar> RAS. How does one now resolve DNS queries across sites ? The best way is for the IPsec client to include a DNS server locally, which either a) knows which domains to forward to which internal DNS servers b) acts a secondary for all the internal DNS servers (this answering the queries locally) [Bind 8 could transfer just the "STUB" zones, and avoid having everything locally ] c) something else Kumar> Also, does not Win 95 permit one to have only two choices Technology is not limited by what Win95 can do. Kumar> for DNS ? Does this restrict the number of tunnels to a Kumar> maximum of two ?). I think it is unlikely that the client No, since a "domain does not exist" failure from the first does cause the machine to query the second. Instead, one needs to put 127.0.0.1 in, and run a DNS server locally. Kumar> b. Recently, in the mailing list, there was a reference Kumar> to the SKIX (Symmetic Key Infrastructure Architecture) and Kumar> X.17 in the context of symmetric manual keying in Kumar> IPSec. Could someone point me to the appropriate IETF group Kumar> that is working on this ? I think this was partially in jest. No IETF WG exists by that name, but if one did exist, then they might start with the ITU's X.17 standard. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNRaScR4XQavxnHg9AQER8wH+Pqu+eONFZR5vIHD5gUA5miz6CIbTuMGX fsUq5Rqze3zBomd/MVyLsxh/qmqF4fNQEpTVWkOGO2Z6DB7hBaLskg== =KIw7 -----END PGP SIGNATURE----- From owner-ipsec Mon Mar 23 12:03:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23808 for ipsec-outgoing; Mon, 23 Mar 1998 12:03:14 -0500 (EST) Message-Id: <199803231717.JAA06876@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Michael Richardson Cc: ipsec@tis.com Subject: Re: Deletion of SA In-Reply-To: Your message of "Mon, 23 Mar 1998 10:07:33 EST." <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Mar 1998 09:17:11 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson wrote: > >>>>> "K" == K SrinivasRao writes: > K> negotiated a new SA and will use that for future > K> communications. Should H1 send a delete payload to delete H2's > > Yes. That should occur as part of the new SA being setup. > A question though: is a "delete" too strong here? Perhaps a "please > delete this SA in X seconds" would be more appropriate? As a notify > perhaps? That would allow SA's to be negotiated in advance of being > used, and it also allows the network to drain. > Someone tell me that this is already addressed, but I just missed > that part :-) A "delete" is the functional equivalent of a "notify" when used in this context. They're both transmitted using an Informational exchange and are therefore completely optional and are not guaranteed to arrive even if they are sent. As you point out, premature aging really is the way to go. Upon receipt of the "delete" start the last rites but don't go for the shovel yet. > K> negotiation of a new SA to send this packet on. How does H2 > K> delete the SA it has? By getting a delete payload from H1? Or, > K> it expires in the normal way? > > I think a sender should always try and send a delete payload when it > removes an outgoing SA. It is the nice thing to do. It also prevents eventual problems from arising since if it isn't sent you run the risk of having the peer start using that SA and causing "Invalid SPI received" messages. Also, if a "delete" is never received but the peer has initiated negotiation for identical SAs the prudent thing to do is to prematurely age the older SAs and start using the new ones as soon as possible. Dan. From owner-ipsec Mon Mar 23 12:10:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23865 for ipsec-outgoing; Mon, 23 Mar 1998 12:10:14 -0500 (EST) Message-Id: <199803231722.RAA06346@orchard.arlington.ma.us> To: Michael Richardson cc: ipsec@tis.com Subject: Re: Deletion of SA In-reply-to: Your message of "Mon, 23 Mar 1998 10:07:33 -0500 ." <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> Date: Mon, 23 Mar 1998 12:22:32 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > K> negotiated a new SA and will use that for future > K> communications. Should H1 send a delete payload to delete H2's > > Yes. That should occur as part of the new SA being setup. > A question though: is a "delete" too strong here? Perhaps a "please > delete this SA in X seconds" would be more appropriate? As a notify > perhaps? That would allow SA's to be negotiated in advance of being > used, and it also allows the network to drain. > Someone tell me that this is already addressed, but I just missed > that part :-) Alternatively, you could put the burden of not sending the delete until the *sender* has reason to believe that all relevant traffic has drained from the net... For instance, in the case of per-connection keying, the sender could send a delete once the connection closed.. From owner-ipsec Mon Mar 23 13:38:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24646 for ipsec-outgoing; Mon, 23 Mar 1998 13:36:15 -0500 (EST) Message-ID: <3516AEC5.5B35034@redcreek.com> Date: Mon, 23 Mar 1998 10:49:41 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Deletion of SA References: <199803231507.KAA00292@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: > > >>>>> "K" == K SrinivasRao writes: > K> since it has not received all the messages. Now, if this SA in > K> H2 is not shared between security policy entries, it will > K> remain forever (until the system reboots) as H1 would have > > H2 may have a (configurable) maximum lifetime on all SA's as well. I > think this would be a prudent implementation detail. > > K> negotiated a new SA and will use that for future > K> communications. Should H1 send a delete payload to delete H2's > > Yes. That should occur as part of the new SA being setup. > A question though: is a "delete" too strong here? Perhaps a "please > delete this SA in X seconds" would be more appropriate? As a notify > perhaps? That would allow SA's to be negotiated in advance of being > used, and it also allows the network to drain. > Someone tell me that this is already addressed, but I just missed > that part :-) > > K> negotiation of a new SA to send this packet on. How does H2 > K> delete the SA it has? By getting a delete payload from H1? Or, > K> it expires in the normal way? > > I think a sender should always try and send a delete payload when it > removes an outgoing SA. > This issue raises some confusion, and I'm also uncertain as to whether the current document adequately addresses it. If there are SA's in both directions between H1 and H2, and H1 sends a delete payload to H2, which SA may it apply to? If we say it only applies to the SA into H1 from H2 (H1's INBOUND SA), no ambiguity exists. However, there may be ambiguity if we permit H1 to also delete SA's which are outbound with respect to H1. This is because the delete payload permits multiple SPI's to be specified, but gives no mechanism for specifying which SPI is which. Since the SPI's are generated independently, they could (in theory, at least) be identical. It seems the only thing permitted by the protocol as it currently stands is for H1 to delete the INBOUND SA (from H2 to H1), and to send a notify payload with perhaps NOTIFY-SA-LIFETIME in it to delete the OUTBOUND SA. From owner-ipsec Mon Mar 23 14:28:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25082 for ipsec-outgoing; Mon, 23 Mar 1998 14:27:18 -0500 (EST) Message-Id: <2.2.32.19980323193903.006e5768@trix.cisco.com> X-Sender: sned@trix.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Mar 1998 11:39:03 -0800 To: "Theodore Y. Ts'o" From: Steve Sneddon Subject: Re: is manual keying mandatory Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, thanks for expressing the position I take 99.999% of the time. However, I'm afraid that I see this as a big issue. At it's heart, it's a "commercial" issue, a kind of problem we haven't had to deal with as much as other (harder?) technical issues. But, if companies can't make a successful IPSec product, then that's a problem in my book (I know not in everybody's book, etc. etc., please let's not rehash *that* issue again ;=)). And I think there's a very cogent case to be made that manual keying can't "work" (in a commercial sense of being scalable, supportable, security-risk-free, etc.) in everyday use on 10's of millions of machines - a space that certain people are trying to address with commercial products. Would it be a good thing if some major (numbers-wise) implementations were explicitly non-compliant? That might be the alternative. How would that help the overall situation? All this is the reason why I asked for information from people on the topic. There's still lots of issues outside of the IPSec specs that need addressing. Yet practically nobody responded with the detail I requested. Given how quick people usually are on this list, I take that as evidence that nobody's doing it in a general way... Or maybe it's so hard they want to keep it to themselves for competitive reasons :=} ? Regards all, Steve At 02:10 PM 3/20/98 -0500, Theodore Y. Ts'o wrote: > > >Can we please consider the issue of manual keying to be closed, please? >We've gone over this before many times --- and the only way to make >progress is to avoid continually revisiting issues which we've decided >in the past. The Security Architecture document very clearly states >that manual keying is mandatory; there shouldn't be any confusion on >this issue at all. Some of you may disagree with this decision, but we >decided this months ago. Can we please give it a rest? > > - Ted > > > From owner-ipsec Mon Mar 23 14:47:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25266 for ipsec-outgoing; Mon, 23 Mar 1998 14:44:18 -0500 (EST) Message-ID: <3516BECE.20F233B5@redcreek.com> Date: Mon, 23 Mar 1998 11:58:06 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Deletion of SA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson wrote: > > >>>>> "K" == K SrinivasRao writes: > K> since it has not received all the messages. Now, if this SA in > K> H2 is not shared between security policy entries, it will > K> remain forever (until the system reboots) as H1 would have > > H2 may have a (configurable) maximum lifetime on all SA's as well. I > think this would be a prudent implementation detail. > > K> negotiated a new SA and will use that for future > K> communications. Should H1 send a delete payload to delete H2's > > Yes. That should occur as part of the new SA being setup. > A question though: is a "delete" too strong here? Perhaps a "please > delete this SA in X seconds" would be more appropriate? As a notify > perhaps? That would allow SA's to be negotiated in advance of being > used, and it also allows the network to drain. > Someone tell me that this is already addressed, but I just missed > that part :-) > > K> negotiation of a new SA to send this packet on. How does H2 > K> delete the SA it has? By getting a delete payload from H1? Or, > K> it expires in the normal way? > > I think a sender should always try and send a delete payload when it > removes an outgoing SA. > This issue raises some confusion, and I'm also uncertain as to whether the current document adequately addresses it. If there are SA's in both directions between H1 and H2, and H1 sends a delete payload to H2, which SA may it apply to? If we say it only applies to the SA into H1 from H2 (H1's INBOUND SA), no ambiguity exists. However, there may be ambiguity if we permit H1 to also delete SA's which are outbound with respect to H1. This is because the delete payload permits multiple SPI's to be specified, but gives no mechanism for specifying which SPI is which. Since the SPI's are generated independently, they could (in theory, at least) be identical. It seems the only thing permitted by the protocol as it currently stands is for H1 to delete the INBOUND SA (from H2 to H1), and to send a notify payload with perhaps NOTIFY-SA-LIFETIME in it to delete the OUTBOUND SA. From owner-ipsec Mon Mar 23 14:50:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25315 for ipsec-outgoing; Mon, 23 Mar 1998 14:50:18 -0500 (EST) Message-Id: <199803232007.PAA00766@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: is manual keying mandatory In-reply-to: Your message of "Mon, 23 Mar 1998 11:39:03 PST." <2.2.32.19980323193903.006e5768@trix.cisco.com> Date: Mon, 23 Mar 1998 15:07:28 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Steve" == Steve Sneddon writes: Steve> not rehash *that* issue again ;=)). And I think there's a Steve> very cogent case to be made that manual keying can't "work" Steve> (in a commercial sense of being scalable, supportable, Steve> security-risk-free, etc.) in everyday use on 10's of I'm sorry, but the spec doesn't say that manual keying has to be any of these things. It simply must exist. Like I said: you can burry your manual keying interface behind a tty based command line interface that speaks only EBCDIC if you want, and is available only on Thursdays with full moons. So long as someone who arrives at a certification lab has a EBCDIC terminal with them, it won't matter. Just because it is in the spec doesn't mean you have to have it in your GUI. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Mon Mar 23 15:08:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25455 for ipsec-outgoing; Mon, 23 Mar 1998 15:08:18 -0500 (EST) Message-Id: <199803232019.MAA28635@weenie.redbacknetworks.com> To: Steve Sneddon cc: "Theodore Y. Ts'o" , ipsec@tis.com From: Dave Carrel Subject: Re: is manual keying mandatory In-reply-to: Your message of "Mon, 23 Mar 1998 11:39:03 PST." <2.2.32.19980323193903.006e5768@trix.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28632.890684349.1@RedBackNetworks.com> Date: Mon, 23 Mar 1998 12:19:09 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk Sigh... Please give it a rest! Statements like "Its a commercial issue" and "if companies can't make a successful IPSec product" are not productive. It's just pure sensationalism. Can you give any reason why you CAN NOT do manual keying?? Nothing says that it must be your only keying method and nothing says that you have to make it scale. Just that you MUST provide it. As for the rest of this message, I thought it was awfully convenient that you asked that we not re-hash the opposing opinions and just that we re-hash yours. Also it was convenient that you ignored the responses to your original question (including those from your own company). The issue was decided long ago. Whether I think it's a great decision or not is basically irrelevant. It _is not_ a bad decision. It is one that any reasonable person can work with. And if you still dislike it, then just ignore it and let the market decide. (We're not writing laws her, we're writing standards.) If you have a good key management solution and it is everything that your customers need, then they won't care if you leave out manual keying. Of course if you're wrong ... Dave > Ted, thanks for expressing the position I take 99.999% of the time. However, > I'm afraid that I see this as a big issue. At it's heart, it's a > "commercial" issue, a kind of problem we haven't had to deal with as much as > other (harder?) technical issues. But, if companies can't make a successful > IPSec product, then that's a problem in my book (I know not in everybody's > book, etc. etc., please let's not rehash *that* issue again ;=)). And I > think there's a very cogent case to be made that manual keying can't "work" > (in a commercial sense of being scalable, supportable, security-risk-free, > etc.) in everyday use on 10's of millions of machines - a space that certain > people are trying to address with commercial products. > > Would it be a good thing if some major (numbers-wise) implementations were > explicitly non-compliant? That might be the alternative. How would that help > the overall situation? > > All this is the reason why I asked for information from people on the topic. > There's still lots of issues outside of the IPSec specs that need > addressing. Yet practically nobody responded with the detail I requested. > Given how quick people usually are on this list, I take that as evidence > that nobody's doing it in a general way... Or maybe it's so hard they want > to keep it to themselves for competitive reasons :=} ? > > Regards all, > Steve > > At 02:10 PM 3/20/98 -0500, Theodore Y. Ts'o wrote: > > > > > >Can we please consider the issue of manual keying to be closed, please? > >We've gone over this before many times --- and the only way to make > >progress is to avoid continually revisiting issues which we've decided > >in the past. The Security Architecture document very clearly states > >that manual keying is mandatory; there shouldn't be any confusion on > >this issue at all. Some of you may disagree with this decision, but we > >decided this months ago. Can we please give it a rest? > > > > - Ted > > > > > > > From owner-ipsec Mon Mar 23 16:27:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26042 for ipsec-outgoing; Mon, 23 Mar 1998 16:26:18 -0500 (EST) Message-ID: <3516D560.E498950@ire-ma.com> Date: Mon, 23 Mar 1998 16:34:24 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Michael Richardson , ipsec@tis.com Subject: Re: is manual keying mandatory References: <199803232007.PAA00766@morden.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson wrote: > Just because it is in the spec doesn't mean you have to have it in > your GUI. If a tree falls in the forest and there is no one around - does it make a sound? If I don't have it in my GUI and I don't have any other ways (network?) to introduce these keys - how it will make my product to comply with manual-keying requirement? -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 23 16:37:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26195 for ipsec-outgoing; Mon, 23 Mar 1998 16:37:18 -0500 (EST) Date: Mon, 23 Mar 1998 23:50:38 +0200 (EET) Message-Id: <199803232150.XAA05431@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Scott G. Kelly" Cc: "Michael C. Richardson" , ipsec@tis.com Subject: Re: comments on ...isakmp-mode-cfg-02 In-Reply-To: <3510073F.E92CCB2C@redcreek.com> References: <199803180036.TAA03135@istari.sandelman.ottawa.on.ca> <3510073F.E92CCB2C@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly writes: > > o Minor Version (4 bits) - indicates the minor version of the ISAKMP > > protocol in use. Implementations based on this version of the ISAKMP > > Internet-Draft MUST set the Minor Version to 0. Implementations > > *** > > based on previous versions of ISAKMP Internet-Drafts MUST set the > > Minor Version to 1. Implementations SHOULD never accept packets with > > *** > > a minor version number larger than its own, given the major version > > numbers are identical. > > > > Isn't the 0/1 minor numbers reversed? Previous == 1, current = 0?] > I think so - I sent email to Doug Maughan asking about this just before > v09 was released to the list, but figured either I was missing > something, or that he didn't get the email in time. No, they are not reversed. The old version number was 0.1 (major.minor) and now it is 1.0. So the major version number also changes and of course we then reset the minor version number back to zero: ---------------------------------------------------------------------- o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than its own. o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Mon Mar 23 16:46:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26272 for ipsec-outgoing; Mon, 23 Mar 1998 16:46:19 -0500 (EST) Message-ID: <3516DA06.B8BBBDE3@ire-ma.com> Date: Mon, 23 Mar 1998 16:54:14 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: vvkumar@lucent.com CC: ipsec@tis.com Subject: Re: DNS and VPN References: <35167DB4.7A82@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Kumar V. Vemuri wrote: > b. Recently, in the mailing list, there was a reference to the SKIX > (Symmetic Key Infrastructure Architecture) and X.17 in the context > of symmetric manual keying in IPSec. Could someone point me to > the appropriate IETF group that is working on this ? It is actually X9.17, which is used by some products to manage distribution of symmetric keys. SKIX - is a name for ficticious IETF WG (like AKULA, or DOORAK, etc). So, I suggested to start this WG to people who want to use manual keing for commercial use and to use X9.17 as a starting point. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 23 17:00:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26349 for ipsec-outgoing; Mon, 23 Mar 1998 16:59:20 -0500 (EST) Message-ID: <3516DD14.D23C6BDE@ire-ma.com> Date: Mon, 23 Mar 1998 17:07:16 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Dave Carrel CC: Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: is manual keying mandatory References: <199803232019.MAA28635@weenie.redbacknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave Carrel wrote: > Can you give any reason why > you CAN NOT do manual keying?? Here are the reasons: - there is no "standard" key distribution mechanism for symmetric keys (I guess I can get on the phone with another guy and negotiate key values) - there is no "standard" mechanism for negotiation key lifetimes (should I also use the phone?) - how to re-key? - (get on the phone again?) - what is the encapsulation context - tunnel/transport? (my phone bill is getting higher?) etc, etc, etc. ------ Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 23 17:29:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26554 for ipsec-outgoing; Mon, 23 Mar 1998 17:28:21 -0500 (EST) Message-Id: <199803232240.OAA28802@weenie.redbacknetworks.com> To: bkavsan@ire-ma.com cc: Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com From: Dave Carrel Subject: Re: is manual keying mandatory In-reply-to: Your message of "Mon, 23 Mar 1998 17:07:16 EST." <3516DD14.D23C6BDE@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28799.890692858.1@RedBackNetworks.com> Date: Mon, 23 Mar 1998 14:40:58 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Can you give any reason why > > you CAN NOT do manual keying?? > > Here are the reasons: > - there is no "standard" key distribution mechanism for symmetric keys (I gue > ss I > can get on the phone with another guy and negotiate key values) > - there is no "standard" mechanism for negotiation key lifetimes (should I al > so > use the phone?) > - how to re-key? - (get on the phone again?) > - what is the encapsulation context - tunnel/transport? (my phone bill is get > ting > higher?) > etc, etc, etc. These are all good reasons for why you don't WANT to base a product on manual keying. But every time you tried to give a reason why you can't do it, you have included in parentheses an example of how you COULD do it. So in other words, you have not answered the question nor contributed anything new to the discussion. We all know why manual keying doesn't scale and we all know why it's impractical in most real world situations. The point isn't that manual keying is a great thing. (I don't personally think it needs to be in the documents. BUT IT IS! And I know that everyone could actually implement if they would just stop whining.) The point is that it can be done and we need to stop trying to find one more reason to delay the documents. 'nuff said. Dave From owner-ipsec Mon Mar 23 17:29:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26555 for ipsec-outgoing; Mon, 23 Mar 1998 17:28:22 -0500 (EST) Date: Mon, 23 Mar 1998 17:42:01 -0500 (EST) From: bede@mitre.org (Bede McCall) Message-Id: <199803232242.RAA19845@zorch.mitre.org> To: sned@cisco.com CC: tytso@MIT.EDU, ipsec@tis.com In-reply-to: <2.2.32.19980323193903.006e5768@trix.cisco.com> (message from Steve Sneddon on Mon, 23 Mar 1998 11:39:03 -0800) Subject: RE: is manual keying mandatory Sender: owner-ipsec@ex.tis.com Precedence: bulk Maybe I'm missing something, but I can't understand the reason for such dogged insistence on eliminating manual keying as a "MUST" at this late date. The specs don't mandate that manual keying be the only kind of keying, and it's a given that manual keying won't scale (a scalable manual keying implementation never having been part of the mandate in any case :-). Given that manual keying is perhaps the simplest and first part of the specs to be implemented by most companies, I can't imagine how it could require any extra effort to code or support in fielded products. You'll undoubtedly want to discourage its use in fielded products outside of a small number of cases (e.g., for debugging or very small collections of hosts) which reduces your product support obligation for manual keying to a little extra ink on paper --- if even that much, assuming your documentation is online. Lastly, merely stating that there is a cogent case for not requiring such a basic feature is a far cry from presenting a cogent case --- and in any event this case, cogent or otherwise, should have been presented long ago. At this point, this issue with manual keying is just a red herring. -- Bede McCall The MITRE Corporation Tel: (781) 271-2839 202 Burlington Road FAX: (781) 271-2423 Bedford, Massachusetts 01730-1420 From owner-ipsec Mon Mar 23 17:39:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26635 for ipsec-outgoing; Mon, 23 Mar 1998 17:39:20 -0500 (EST) To: bkavsan@ire-ma.com Cc: Dave Carrel , Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: is manual keying mandatory References: <199803232019.MAA28635@weenie.redbacknetworks.com> <3516DD14.D23C6BDE@ire-ma.com> From: EKR Date: 23 Mar 1998 14:54:08 -0800 In-Reply-To: Bronislav Kavsan's message of "Mon, 23 Mar 1998 17:07:16 -0500" Message-Id: <3hg4pqar3.fsf@kmac.terisa.com> Lines: 23 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bronislav Kavsan writes: > Here are the reasons: > - there is no "standard" key distribution mechanism for symmetric keys (I guess I > can get on the phone with another guy and negotiate key values) > - there is no "standard" mechanism for negotiation key lifetimes (should I also > use the phone?) > - how to re-key? - (get on the phone again?) > - what is the encapsulation context - tunnel/transport? (my phone bill is getting > higher?) > etc, etc, etc. These are operational reasons why it's inconvenient for USERS to do manual keying. They don't have anything to do with why implementers can't do manual keying, which is the question at hand. What, precisely, is so incredibly difficult about adding this to one's implementation that people are willing to make a big deal over this, instead of just letting the settled issue stay settled? -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From owner-ipsec Mon Mar 23 17:39:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26636 for ipsec-outgoing; Mon, 23 Mar 1998 17:39:21 -0500 (EST) Message-ID: <3516E69B.F369012@ire-ma.com> Date: Mon, 23 Mar 1998 17:47:55 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Dave Carrel CC: Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: is manual keying mandatory References: <199803232240.OAA28802@weenie.redbacknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave Carrel wrote: > We all know why manual keying doesn't scale and we > all know why it's impractical in most real world situations. Just admitting this makes this MUST a big joke....As far as the danger of delaying the documents - I agree - we shouldn't delay. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 23 18:13:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26878 for ipsec-outgoing; Mon, 23 Mar 1998 18:11:21 -0500 (EST) Date: Mon, 23 Mar 1998 18:24:22 -0500 (EST) From: bede@mitre.org (Bede McCall) Message-Id: <199803232324.SAA19889@zorch.mitre.org> To: mcr@sandelman.ottawa.on.ca CC: ipsec@tis.com In-reply-to: <199803232007.PAA00766@morden.sandelman.ottawa.on.ca> (message from Michael Richardson on Mon, 23 Mar 1998 15:07:28 -0500) Subject: RE: is manual keying mandatory Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 23 Mar 1998 15:07:28 -0500 From: Michael Richardson [ . . . ] Like I said: you can burry your manual keying interface behind a tty based command line interface that speaks only EBCDIC if you want, and is available only on Thursdays with full moons. So long as someone who arrives at a certification lab has a EBCDIC terminal with them, it won't matter. Just because it is in the spec doesn't mean you have to have it in your GUI. [ . . . ] Clearly, this kind of approach is disingenuous at best and doesn't make for either credible compliance with the spec or a sound implementation since you end up with embedded "living dead" code. One could end up having nightmares about hordes of undocumented features skulking in the shadows of every IPSec implementation's Anxiety Closet. A much better idea: explain what it's for in plain, honest language and figuratively advise your customers to use the feature only on Thursdays with full moons, and then only if their blood alcohol content is under .03 (...legal even in Sweden, I think). -- Bede McCall The MITRE Corporation Tel: (781) 271-2839 202 Burlington Road FAX: (781) 271-2423 Bedford, Massachusetts 01730-1420 From owner-ipsec Mon Mar 23 19:11:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27298 for ipsec-outgoing; Mon, 23 Mar 1998 19:08:19 -0500 (EST) Message-Id: <199803240019.TAA16721@relay.hq.tis.com> To: bkavsan@ire-ma.com cc: Dave Carrel , Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: is manual keying mandatory In-reply-to: Your message of "Mon, 23 Mar 1998 17:47:55 EST." <3516E69B.F369012@ire-ma.com> Date: Mon, 23 Mar 1998 16:21:06 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Yup, this is the conversation we had last year. And probably the year before that... What a waste of recycled bits. Derrell From owner-ipsec Mon Mar 23 20:03:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27618 for ipsec-outgoing; Mon, 23 Mar 1998 20:01:20 -0500 (EST) Message-Id: <199803240113.UAA18189@jekyll.piermont.com> To: bkavsan@ire-ma.com cc: Dave Carrel , Steve Sneddon , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: is manual keying mandatory In-reply-to: Your message of "Mon, 23 Mar 1998 17:47:55 EST." <3516E69B.F369012@ire-ma.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 23 Mar 1998 20:13:07 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bronislav Kavsan writes: > Dave Carrel wrote: > > > We all know why manual keying doesn't scale and we > > all know why it's impractical in most real world situations. > > Just admitting this makes this MUST a big joke... It wasn't MUST on the basis that people were going to use it on large networks. It was MUST for very different reasons. In any case, I believe the topic is quite dead. Perry From owner-ipsec Mon Mar 23 20:06:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27660 for ipsec-outgoing; Mon, 23 Mar 1998 20:05:19 -0500 (EST) Message-ID: <3517089A.1D96CD8B@ire-ma.com> Date: Mon, 23 Mar 1998 20:13:01 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Bede McCall CC: mcr@sandelman.ottawa.on.ca, ipsec@tis.com Subject: Re: is manual keying mandatory References: <199803232324.SAA19889@zorch.mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bede McCall wrote: > A much better idea: explain what it's for in plain, honest language > and figuratively advise your customers to use the feature only on > Thursdays with full moons, and then only if their blood alcohol > content is under .03 (...legal even in Sweden, I think). I like this idea! Or even better - make this feature available only to IPsec certification sober bodies :) Slava Kavsan IRE From owner-ipsec Mon Mar 23 20:13:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27700 for ipsec-outgoing; Mon, 23 Mar 1998 20:11:19 -0500 (EST) Message-Id: <2.2.32.19980324012214.00766db8@trix.cisco.com> X-Sender: sned@trix.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Mar 1998 17:22:14 -0800 To: bkavsan@ire-ma.com From: Steve Sneddon Subject: Re: is manual keying mandatory Cc: Dave Carrel , "Theodore Y. Ts'o" , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I totally agree - no changes & no delay. I wasn't proposing changing the MUST. I was only trying to understand the parameters on what had to "work" in order for an implementation to be called "compliant". I think I understand that now from the information from the respondents, and the lack thereof from others. Thanks folks, and sorry for any consternation I may have caused. At 05:47 PM 3/23/98 -0500, Bronislav Kavsan wrote: >Dave Carrel wrote: > >> We all know why manual keying doesn't scale and we >> all know why it's impractical in most real world situations. > >Just admitting this makes this MUST a big joke....As far as the danger of delaying >the documents - I agree - we shouldn't delay. >-- >Bronislav Kavsan >IRE Secure Solutions, Inc. >100 Conifer Hill Drive Suite 513 >Danvers, MA 01923 >voice: 978-739-2384 >http://www.ire.com > > > > > From owner-ipsec Mon Mar 23 23:55:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29075 for ipsec-outgoing; Mon, 23 Mar 1998 23:52:19 -0500 (EST) Date: Tue, 24 Mar 98 04:50:51 GMT Standard Time From: Ran Atkinson Subject: Re: is manual keying mandatory To: Steve Sneddon Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3516DD14.D23C6BDE@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Without manual keying, multicast sessions cannot be protected. While other rationales exist for supporting manual keying, that is a _sufficient_ justification for making it mandatory to implement. More to the point, those of you trying to sell your products through my employer to our customers (that's nearly all of you, including MS and Cisco) will find we aren't very interested in an product that doesn't include support for manual keying. Manual key management isn't hard to build and no one has to use it, so marketing arguments just don't hold water. Ran From owner-ipsec Tue Mar 24 07:28:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02004 for ipsec-outgoing; Tue, 24 Mar 1998 07:25:22 -0500 (EST) Message-Id: <3.0.1.32.19980324172015.006c65cc@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 24 Mar 1998 17:20:15 +0500 To: Bill Sommerfeld From: K SrinivasRao Subject: Re: Deletion of SA Cc: ipsec@tis.com In-Reply-To: <199803231722.RAA06346@orchard.arlington.ma.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:22 PM 3/23/98 -0500, Bill Sommerfeld wrote: >> K> negotiated a new SA and will use that for future >> K> communications. Should H1 send a delete payload to delete H2's >> >> Yes. That should occur as part of the new SA being setup. >> A question though: is a "delete" too strong here? Perhaps a "please >> delete this SA in X seconds" would be more appropriate? As a notify >> perhaps? That would allow SA's to be negotiated in advance of being >> used, and it also allows the network to drain. >> Someone tell me that this is already addressed, but I just missed >> that part :-) > >Alternatively, you could put the burden of not sending the delete >until the *sender* has reason to believe that all relevant traffic has >drained from the net... > >For instance, in the case of per-connection keying, the sender could >send a delete once the connection closed.. In the case of per-connection keying, the connection is closed only when the application stops running. But here the case is different. The application has still packets to send, but the SA has run out of bytes(Note: we considered the case when SA has life time in byte counts) and has to be renegotiated. Hence the H1(sender) can't wait till the connection closes for sending a delete payload to H2. SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Tue Mar 24 07:30:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02018 for ipsec-outgoing; Tue, 24 Mar 1998 07:29:23 -0500 (EST) Message-Id: <3.0.1.32.19980324174344.00689200@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 24 Mar 1998 17:43:44 +0500 To: "Scott G. Kelly" From: K SrinivasRao Subject: Re: Deletion of SA Cc: ipsec@tis.com In-Reply-To: <3516BECE.20F233B5@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:58 AM 3/23/98 -0800, Scott G. Kelly wrote: >Michael Richardson wrote: >> >> >>>>> "K" == K SrinivasRao writes: >> K> since it has not received all the messages. Now, if this SA in >> K> H2 is not shared between security policy entries, it will >> K> remain forever (until the system reboots) as H1 would have >> >> H2 may have a (configurable) maximum lifetime on all SA's as well. >I >> think this would be a prudent implementation detail. >> >> K> negotiated a new SA and will use that for future >> K> communications. Should H1 send a delete payload to delete H2's >> >> Yes. That should occur as part of the new SA being setup. >> A question though: is a "delete" too strong here? Perhaps a "please >> delete this SA in X seconds" would be more appropriate? As a notify >> perhaps? That would allow SA's to be negotiated in advance of being >> used, and it also allows the network to drain. >> Someone tell me that this is already addressed, but I just missed >> that part :-) >> >> K> negotiation of a new SA to send this packet on. How does H2 >> K> delete the SA it has? By getting a delete payload from H1? Or, >> K> it expires in the normal way? >> >> I think a sender should always try and send a delete payload when >it >> removes an outgoing SA. >> > >This issue raises some confusion, and I'm also uncertain as to whether >the current document adequately addresses it. If there are SA's in both >directions between H1 and H2, and H1 sends a delete payload to H2, >which >SA may it apply to? If we say it only applies to the SA into H1 from H2 >(H1's INBOUND SA), no ambiguity exists. However, there may be ambiguity >if we permit H1 to also delete SA's which are outbound with respect to >H1. This is because the delete payload permits multiple SPI's to be >specified, but gives no mechanism for specifying which SPI is which. >Since the SPI's are generated independently, they could (in theory, at >least) be identical. Since an SA is uniquely identified only by the triple (SPI, DestAddr, IPSEC Protocol), when we send only the SPI value in the delete payload, it does not determine the SA uniquely. We can get the destination address from the datagram (extracting the sender and receiver from the delete payload datagram) but we do not know the IPSEC protocol. Thus, if we have more than one SA between the same two hosts with different protections, we might have identical SPI values for the SAs (this does not violate the uniqueness requirement). So, how do we determine which SA to delete? Also, since a single ISAKMP negotiation results in 2 SAs - one outgoing and the other incoming - we should be deleting both the SAs of this pair in both H1 and H2 (I think)? >It seems the only thing permitted by the protocol as it currently >stands >is for H1 to delete the INBOUND SA (from H2 to H1), and to send a >notify >payload with perhaps NOTIFY-SA-LIFETIME in it to delete the OUTBOUND >SA. Thank U Srinu From owner-ipsec Tue Mar 24 07:43:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02123 for ipsec-outgoing; Tue, 24 Mar 1998 07:41:23 -0500 (EST) Message-Id: <199803232240.OAA06543@hsmpka.eng.sun.com> Date: Mon, 23 Mar 1998 14:40:07 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: Please review draft-ietf-pppext-l2tp-sec-03.txt To: ipsec@tis.com, rgm-sec@htt-consult.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: g+o1j7Mc0yuHwucL4cb/eg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk > X-Sender: rgm-sec@homebase.htt-consult.com > Date: Thu, 19 Mar 1998 12:36:26 -0500 > To: ipsec@tis.com > From: Robert Moskowitz > Subject: Please review draft-ietf-pppext-l2tp-sec-03.txt > Mime-Version: 1.0 > > I know we are busy, but the L2TP crowd is working on their use of IPsec for > protecting L2TP sessions. > > I do not mean at all to question the abilities of the L2TP wg, but I > suspect that there are many people here that are not on that list, and may > want to study this, the first use of IPsec by another wg. > > One interesting comment I have of this draft, is it does not actually > reference any of the IPsec documents. Bob, I believe that you meant draft-ietf-pppext-l2tp-security-0x.txt. The draft you mentioned discussed security if no IP is available (i.e. L2TP over native ATM). PatC From owner-ipsec Tue Mar 24 11:50:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04154 for ipsec-outgoing; Tue, 24 Mar 1998 11:40:27 -0500 (EST) Message-ID: <3517E56C.47E0AEB5@redcreek.com> Date: Tue, 24 Mar 1998 08:55:08 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: K SrinivasRao CC: ipsec@tis.com Subject: Re: Deletion of SA References: <3.0.1.32.19980324174344.00689200@192.9.200.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk K SrinivasRao wrote: > Since an SA is uniquely identified only by the triple (SPI, DestAddr, IPSEC > Protocol), when we send only the SPI value in the delete payload, it does > not determine the SA uniquely. We can get the destination address from the > datagram (extracting the sender and receiver from the delete payload > datagram) but we do not know the IPSEC protocol. Actually, we do know the protocol, as it is part of the payload, which consists of DOI, Protocol-Id, SPI size, and number of SPI's. > Thus, if we have more than > one SA between the same two hosts with different protections, we might have > identical SPI values for the SAs (this does not violate the uniqueness > requirement). So, how do we determine which SA to delete? > Yes, this is the question I'm asking. > Also, since a single ISAKMP negotiation results in 2 SAs - one outgoing and > the other incoming - we should be deleting both the SAs of this pair in > both H1 and H2 (I think)? Again, this is a question, but it's not very clear what the answer should be. The problem, as noted above, is that the SA is identified by the triple: (SPI, Protocol, and DestIP). When you receive the delete payload, which address do you use for DestIP? And assuming we decide to use the source of the payload for DestIP w.r.t. one of the SPI's, and the target of the payload for DestIP w.r.t. another SPI in the payload, which SPI is which? From owner-ipsec Thu Mar 26 07:43:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28015 for ipsec-outgoing; Thu, 26 Mar 1998 07:35:05 -0500 (EST) From: owner-ipsec@ex.tis.com Date: Thu, 26 Mar 1998 13:31:52 +0800 (HKT) Message-Id: <199803260531.NAA17126@cssu282.cs.ust.hk> To: IETF-Announce@es.net, dns-security@tis.com, ipsec@ans.net, announcements.chi@xerox.com, confctrl@isi.edu, tccc@ieee.org, giga@tele.pitt.edu, comswtc@gmu.edu, multicomm@cc.bellcore.com, commsoft@cc.bellcore.com Subject: call for papers (special issue of JPDC) Cc: iahmad@cs.ust.hk, fcmlau@cs.hku.hk X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Colleagues: Please distribute the following call for papers to other colleagues. Thank you. Ishfaq ####################################################################### # # # Journal of Parallel and Distributed Computing # # # # Call for Papers # # A Special Issue Focusing on # # Software Support for Distributed Computing # # # ####################################################################### Distributed and networked computer systems such as clusters of workstations are becoming the computational resource of choice for researchers working in the area of parallel processing. There are several economic and technical reasons motivating the increasing usage of such systems. However, in order for such systems to behave like a single system in a seamless and transparent fashion, considerable research is required for efficient management of resources, operating system support, programming tools, and fast communication. Papers are solicited for a special issue of the Journal of Parallel and Distributed Computing tentatively scheduled to be published in September, 1999. The purpose of this special issue is to focus on the recent developments as well as newly proposed approaches and experimental results that can help to solve computationally intensive problems across distributed platforms. Topics of interest include (but are not limited to): o Distributed system architectures o Operating system supports o Efficient communication, interfaces and libraries, o Scheduling, data distribution, and load balancer, o Experimental mapping/allocation algorithms o Task migration facilities o Experimental software tools for programming o Building Applications on networked systems o Distributed shared-memory on a workstation cluster o Distributed file server and I/O o Fault tolerance issues o Performance considerations Schedule: -------------------------------------------------- | Submission deadline: October 1, 1998. | | Notification of Acceptance: April 1, 1999. | | Target month of Special Issue: September 1999 | -------------------------------------------------- Authors should follow the Information for Authors at the end of each issue of JPDC when preparing their manuscripts for submission. An electronic copy of the manuscript, in Postscript format and viewable with ghostview, should be submitted via electronic mail to one of the guest editors by October 1, 1998. Alternatively, five copies of the complete manuscript can be sent to arrive by the same deadline. Submission should include authors names, affiliations, addresses, fax and phone numbers, email addresses, on the cover page. Only original manuscript will be considered. All papers will undergo a peer review process. Authors will be notified of the final publication decision by April 1, 1999. ####################################################################### # Guest Editors, Journal of Parallel and Distributed Computing # # # # Ishfaq Ahmad # # Department of Computer Science # # Hong Kong University of Science and Technology # # Clear Water Bay, Kowloon, Hong Kong # # Ph: (852) 2358-6980, Fax: (852) 2358-1477 # # E-mail: iahmad@cs.ust.hk # # # # Francis C.M. Lau # # Department of Computer Science # # The University of Hong Kong # # Pokfulam Road, Hong Kong # # Tel: (852) 2859-2170, Fax: (852) 2559-8447 # # E-mail: fcmlau@cs.hku.hk # # # # # ####################################################################### ----- End Included Message ----- From owner-ipsec Thu Mar 26 11:58:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00184 for ipsec-outgoing; Thu, 26 Mar 1998 11:56:26 -0500 (EST) Message-Id: <199803261710.MAA25501@relay.rv.tis.com> Date: Thu, 26 Mar 98 12:08:21 EST From: Karen Seo To: rohit@trinc.com cc: ipsec@tis.com Subject: Re: Wrong pointer ?? Sender: owner-ipsec@ex.tis.com Precedence: bulk Rohit Aradhya, >>In IpSec-Architecture-mar98 draft >>Section B.3.4 Per socket maintainence of pmtu data >> have the follwing para >>"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. " >> >> I think the references shown, (Section B.2.2 and Section B.2.3) should >>be Section B.3.2 and Section B.3.3 , Right ? You're right. We'll change it in the next draft. Thank you, Karen From owner-ipsec Thu Mar 26 14:22:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01208 for ipsec-outgoing; Thu, 26 Mar 1998 14:20:29 -0500 (EST) Message-Id: <199803261926.LAA04909@red.mtv.fiberlane.com> X-Mailer: exmh version 2.0.1 12/23/97 To: iesg@ns.ietf.org cc: ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Fri, 20 Mar 1998 15:08:18 EST." <199803202008.PAA28002@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Mar 1998 11:26:26 -0800 From: Greg Minshall Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear IESG, I have one serious concern about the IP Security Architecture, which is the fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. I think this is a significant issue in a number of areas related to operating and managing the internet (and smaller intranets). For example, these days we are able to measure traffic growth by application type ("how much of the traffic is HTTP traffic and how is that changing over time?" is typical of the questions we ask there). When debugging problems, correlating packets observed with known application behaviours ("oh, yes, that must be from a buggy version of TN3270") is often useful. We occasionally would like to give different classes of service to different application types. While it is quite possible that the removal of port numbers from the cleartext payload will *not* adversely affect the operating of the internet, i worry that it may impact things negatively. If i were to summarize what i would like to see done, it would be to provide room in the cleartext portion of the IPSEC header for "32 bits of source and destination port numbers (or their equivalent) in protocols that have the concept of port numbers", along with "advice to implementors" that the ultimate receiver should use these bits, if not zero, to replace the port numbers carried within the encrypted payload. (Applications worried about port-based traffic analysis would be able to use zeroes in the cleartext header.) This issue was raised (several years ago) within the IPSEC working group. After a reasonable discussion, the working group decided to leave the port numbers encrypted. I think that from the IPSEC working group's point of view, this makes sense (maximum security). I am hoping that from the point of view of the entire IETF, we may be able to decide that managing the network is important enough to move the port numbers into the clear. Thanks very much for your consideration in this matter, Greg Minshall From owner-ipsec Thu Mar 26 14:50:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01434 for ipsec-outgoing; Thu, 26 Mar 1998 14:50:29 -0500 (EST) Message-ID: From: Roy Pereira To: "'Greg Minshall'" Cc: "'ipsec@tis.com'" Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 26 Mar 1998 15:08:33 -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 does exist a balacing act between manageability and security, but IPSec was meant to be as secure as possible. I beleive that most customers will want to hide the port numbers along with the identities of the protected systems, ie. hide as much as possible. By adding ports to the ESP header, you would also have to add yet another field for the protocol being protected as well, since the next protocol field in ESP might be pointing to another ESP/AH or IPComp header. This is five extra bytes (protocol + source/dest port) that most people in the working group would not be happy with. >-----Original Message----- >From: Greg Minshall [SMTP:minshall@fiberlane.com] >Sent: Thursday, March 26, 1998 2:26 PM >To: iesg@ns.ietf.org >Cc: ipsec@tis.com; ietf@ns.ietf.org >Subject: Re: Last Call: Security Architecture for the Internet Protocol to >Proposed Standard > >Dear IESG, > >I have one serious concern about the IP Security Architecture, which is the >fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. > >I think this is a significant issue in a number of areas related to operating >and managing the internet (and smaller intranets). For example, these days >we >are able to measure traffic growth by application type ("how much of the >traffic is HTTP traffic and how is that changing over time?" is typical of >the >questions we ask there). When debugging problems, correlating packets >observed with known application behaviours ("oh, yes, that must be from a >buggy version of TN3270") is often useful. We occasionally would like to >give >different classes of service to different application types. > >While it is quite possible that the removal of port numbers from the >cleartext >payload will *not* adversely affect the operating of the internet, i worry >that it may impact things negatively. > >If i were to summarize what i would like to see done, it would be to provide >room in the cleartext portion of the IPSEC header for "32 bits of source and >destination port numbers (or their equivalent) in protocols that have the >concept of port numbers", along with "advice to implementors" that the >ultimate receiver should use these bits, if not zero, to replace the port >numbers carried within the encrypted payload. (Applications worried about >port-based traffic analysis would be able to use zeroes in the cleartext >header.) > >This issue was raised (several years ago) within the IPSEC working group. >After a reasonable discussion, the working group decided to leave the port >numbers encrypted. I think that from the IPSEC working group's point of >view, >this makes sense (maximum security). I am hoping that from the point of view >of the entire IETF, we may be able to decide that managing the network is >important enough to move the port numbers into the clear. > >Thanks very much for your consideration in this matter, > >Greg Minshall > > > > > From owner-ipsec Thu Mar 26 16:16:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02098 for ipsec-outgoing; Thu, 26 Mar 1998 16:14:34 -0500 (EST) X-Sender: dnessett@mail.tdc.3com.com Message-Id: In-Reply-To: <882565D3.006D1B7F.00@hqinbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Mar 1998 13:21:30 -0800 To: Greg Minshall , iesg@ns.ietf.org From: "dan_nessett" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com, ietf@ns.ietf.org Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, I'm not sure what the correct procedure is for addressing IESG last call comments, so I am sending this to the same lists as you. I don't believe it would be difficult to create a "header", much like AH, that would be filled in with the UDP/TCP port information (and any other information that is encrypted, but found useful for network management purposes). This header could be included in the scope of AH authentication data, so it couldn't be changed by an intruder (unless AH wasn't present). However, I don't think the receiver should replace the port information protected by an ESP header by the port information carried in the clear. I suggest the following slight modification to that rule. If the management header is present and protected by AH, the ports in the management header and ESP protected data must match. Otherwise, the packet is presented for normal IPsec processing. If network administrators are burdened by the lack of port information in packets, they can always configure their networks to discard packets that do not have a protected management header. The advantage of this approach is it allows the management header definition and IPsec promotion to proposed standard to proceed independently. The only change necessary to IPsec is to add the management header to the list of "immutable" fields over which AH authentication codes are computed, once it is defined. Dan Nessett At 7:26 PM +0000 3/26/98, Greg Minshall wrote: >Dear IESG, >I have one serious concern about the IP Security Architecture, which is the >fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. >I think this is a significant issue in a number of areas related to >operating >and managing the internet (and smaller intranets). For example, these days >we >are able to measure traffic growth by application type ("how much of the >traffic is HTTP traffic and how is that changing over time?" is typical of >the >questions we ask there). When debugging problems, correlating packets >observed with known application behaviours ("oh, yes, that must be from a >buggy version of TN3270") is often useful. We occasionally would like to >give >different classes of service to different application types. >While it is quite possible that the removal of port numbers from the >cleartext >payload will *not* adversely affect the operating of the internet, i worry >that it may impact things negatively. >If i were to summarize what i would like to see done, it would be to >provide >room in the cleartext portion of the IPSEC header for "32 bits of source >and >destination port numbers (or their equivalent) in protocols that have the >concept of port numbers", along with "advice to implementors" that the >ultimate receiver should use these bits, if not zero, to replace the port >numbers carried within the encrypted payload. (Applications worried about >port-based traffic analysis would be able to use zeroes in the cleartext >header.) >This issue was raised (several years ago) within the IPSEC working group. >After a reasonable discussion, the working group decided to leave the port >numbers encrypted. I think that from the IPSEC working group's point of >view, >this makes sense (maximum security). I am hoping that from the point of >view >of the entire IETF, we may be able to decide that managing the network is >important enough to move the port numbers into the clear. >Thanks very much for your consideration in this matter, >Greg Minshall From owner-ipsec Thu Mar 26 17:55:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02754 for ipsec-outgoing; Thu, 26 Mar 1998 17:53:28 -0500 (EST) Date: Thu, 26 Mar 1998 18:07:21 -0500 Message-Id: <9803262307.AA01547@kona.> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: iesg@ns.ietf.org, minshall@fiberlane.com Cc: ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: <199803202008.PAA28002@ns.ietf.org> <199803261926.LAA04909@red.mtv.fiberlane.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk I would support the concern that Greg raised. There is an increased use of finer-grained traffic classification, in which port numbers play a role. It is true that, for maximum security, this information may want to be hidden. Greg recognized that in his suggestion that the port number copy in the security header could be supplied as all zero. If the port number is concealed (either with IPSec as it is currently defined, or with zeroed port numbers in Greg's suggestion) then a traffic classifier would have no port information and would have to classify all that traffic as "other" or "unknown application". This may be acceptable in many cases. By creating an *option* of supplying port information to the classifier, it allows a user to give up a small amount of security and gain the benefit of being classified into a different traffic category that has different (presumably better) service. I believe this is a valuable option. Paul Koning Xedia Corporation From owner-ipsec Thu Mar 26 18:02:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02857 for ipsec-outgoing; Thu, 26 Mar 1998 18:02:28 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: updated draft-ietf-ipsec-ciph-cbc-03.txt Date: Thu, 26 Mar 1998 18:19:54 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; name="draft-ietf-ipsec-ciph-cbc-03.txt" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft R. Adams Expires in six months Cisco Systems Inc. March 25, 1998 The ESP CBC-Mode Cipher Algorithms Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or 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. Abstract This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. R. Pereira, R. Adams [Page 1] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 Table of Contents 1. Introduction...................................................2 1.1 Specification of Requirements...............................2 2. Cipher Algorithms..............................................3 2.1 Mode........................................................3 2.2 Key Size....................................................3 2.3 Weak Keys...................................................4 2.4 Block Size and Padding......................................6 2.5 Rounds......................................................6 2.6 Backgrounds.................................................6 2.7 Performance.................................................9 3. ESP Payload....................................................9 3.1 ESP Environmental Considerations............................9 3.2 Keying Material............................................10 4. Security Considerations.......................................10 5. References....................................................10 6. Acknowledgments...............................................12 7. Editors' Addresses............................................12 1. Introduction The Encapsulating Security Payload (ESP) [Kent98] provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of CBC-mode cipher algorithms. While this document does not describe the use of the default cipher algorithm DES, the reader should be familiar with that document. [Madson98] It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP Encapsulating Security Payload (ESP)" [Kent98] documents. Furthermore, this document is a companion to [Kent98] and MUST be read in its context. 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. R. Pereira, R. Adams [Page 2] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2. Cipher Algorithms All symmetric block cipher algorithms share common characteristics and variables. These include mode, key size, weak keys, block size, and rounds. All of which will be explained below. While this document illustrates certain cipher algorithms such as Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV], and RC5 [Baldwin96], any other block cipher algorithm may be used with ESP if all of the variables described within this document are clearly defined. 2.1 Mode All symmetric block cipher algorithms described or insinuated within this document use Cipher Block Chaining (CBC) mode. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's blocksize. The IV is XOR'd with the first plaintext block, before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted. More information on CBC mode can be obtained in [Schneier95]. 2.2 Key Size Some cipher algorithms allow for variable sized keys, while others only allow a specific key size. The length of the key correlates with the strength of that algorithm, thus larger keys are always harder to break than shorter ones. This document stipulates that all key sizes MUST be a multiple of 8 bits. This document does specify the default key size for each cipher algorithm. This size was chosen by consulting experts on the algorithm and by balancing strength of the algorithm with performance. R. Pereira, R. Adams [Page 3] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 +==============+==================+=================+==========+ | Algorithm | Key Sizes (bits) | Popular Sizes | Default | +==============+==================+=================+==========+ | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | +--------------+------------------+-----------------+----------+ | RC5 | 40 to 2040 | 40, 128, 160 | 128 | +--------------+------------------+-----------------+----------+ | IDEA | 128 | 128 | 128 | +--------------+------------------+-----------------+----------+ | Blowfish | 40 to 448 | 128 | 128 | +--------------+------------------+-----------------+----------+ | 3DES [2] | 192 | 192 | 192 | +--------------+------------------+-----------------+----------+ Notes: [1] With CAST-128, keys less than 128 bits MUST be padded with zeros in the rightmost, or least significant, positions out to 128 bits since the CAST-128 key schedule assumes an input key of 128 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', it would be padded to produce a key with a size of 128 bits '3B5D831CFE000000'. [2] The first 3DES key is taken from the first 64 bits, the second from the next 64 bits, and the third from the last 64 bits. Implementations MUST take into consideration the parity bits when initially accepting a new set of keys. Each of the three keys is really 56 bits in length with the extra 8 bits used for parity. The reader should note that the minimum key size for all of the above cipher algorithms is 40 bits, and that the authors strongly advise that implementations do NOT use key sizes smaller than 40 bits. 2.3 Weak Keys Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested. Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature. New weak keys might be discovered, so this document does not in any way contain all possible weak keys for these ciphers. Please check with other sources of cryptography such as [MOV] and [Schneier] for further weak keys. R. Pereira, R. Adams [Page 4] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 CAST-128: No known weak keys. RC5: No known weak keys when used with 16 rounds. IDEA: IDEA has been found to have weak keys. Please check with [MOV] and [Schneier] for more information. Blowfish: Weak keys for Blowfish have been discovered. Weak keys are keys that produce the identical entries in a given S-box. Unfortunately, there is no way to test for weak keys before the S- box values are generated. However, the chances of randomly generating such a key are small. 3DES: DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible. For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys. However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property. R. Pereira, R. Adams [Page 5] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2.4 Block Size and Padding All of the algorithms described in this document use a block size of eight octets (64 bits). Padding is used to align the payload type and pad length octets as specified in [Kent98]. Padding must be sufficient to align the data to be encrypted to an eight octet (64 bit) boundary. 2.5 Rounds This variable determines how many times a block is encrypted. While this variable MAY be negotiated, a default value MUST always exist when it is not negotiated. +====================+============+======================+ | Algorithm | Negotiable | Default Rounds | +====================+============+======================+ | CAST-128 | No | key<=80 bits, 12 | | | | key>80 bits, 16 | +--------------------+------------+----------------------+ | RC5 | No | 16 | +--------------------+------------+----------------------+ | IDEA | No | 8 | +--------------------+------------+----------------------+ | Blowfish | No | 16 | +--------------------+------------+----------------------+ | 3DES | No | 48 (16x3) | +--------------------+------------+----------------------+ 2.6 Backgrounds CAST-128: The CAST design procedure was originally developed by Carlisle Adams and Stafford Travares at Queen's University, Kingston, Ontario, Canada. Subsequent enhancements have been made over the years by Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 is the result of applying the CAST Design Procedure as outlined in [Adams97]. R. Pereira, R. Adams [Page 6] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 RC5: The RC5 encryption algorithm was developed by Ron Rivest for RSA Data Security Inc. in order to address the need for a high- performance software and hardware ciphering alternative to DES. It is patented (pat.no. 5,724,428). A description of RC5 may be found in [MOV] and [Schneier]. IDEA: Xuejia Lai and James Massey developed the IDEA (International Data Encryption Algorithm) algorithm. The algorithm is described in detail in [Lai], [Schneier] and [MOV]. The IDEA algorithm is patented in Europe and in the United States with patent application pending in Japan. Licenses are required for commercial uses of IDEA. For patent and licensing information, contact: Ascom Systec AG, Dept. CMVV Gewerbepark, CH-5506 Magenwil, Switzerland Phone: +41 64 56 59 83 Fax: +41 64 56 59 90 idea@ascom.ch http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html Blowfish: Bruce Schneier of Counterpane Systems developed the Blowfish block cipher algorithm. The algorithm is described in detail in [Schneier93], [Schneier95] and [Schneier]. 3DES: This DES variant, colloquially known as "Triple DES" or as DES- EDE3, processes each block three times, each time with a different key. This technique of using more than one DES operation was proposed in [Tuchman79]. R. Pereira, R. Adams [Page 7] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 P1 P2 Pi | | | IV->->(X) +>->->->(X) +>->->->(X) v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k1->| E | ^ k1->| E | ^ k1->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k2->| D | ^ k2->| D | ^ k2->| D | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k3->| E | ^ k3->| E | ^ k3->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | +>->->+ +>->->+ +>->-> | | | C1 C2 Ci The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algorithm [FIPS-46]. The "outer" chaining technique is used. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 byte) plaintext block (P1). The keyed DES function is iterated three times, an encryption (Ek1) followed by a decryption (Dk2) followed by an encryption (Ek3), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3. For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES-EDE3 encryption function generates the ciphertext (Ci) for that block. To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR the previous ciphertext block. Note that when all three keys (k1, k2 and k3) are the same, DES- EDE3-CBC is equivalent to DES-CBC. This property allows the DES- EDE3 hardware implementations to operate in DES mode without modification. For more explanation and implementation information for Triple DES, see [Schneier95]. R. Pereira, R. Adams [Page 8] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 2.7 Performance For a comparison table of the estimated speed of any of these and other cipher algorithms, please see [Schneier97] or for an up-to- date performance comparison, please see [Bosseleaers]. 3. ESP Payload The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [Kent98], is broken down according to the following diagram: +---------------+---------------+---------------+---------------+ | | + Initialization Vector (8 octets) + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (variable length) ~ | | +---------------------------------------------------------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The IV field MUST be same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random. Common practice is to use random data for the first IV and the last block of encrypted data from an encryption process as the IV for the next encryption process. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. 3.1 ESP Environmental Considerations Currently, there are no known issues regarding interactions between these algorithms and other aspects of ESP, such as use of certain authentication schemes. R. Pereira, R. Adams [Page 9] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 3.2 Keying Material The minimum number of bits sent from the key exchange protocol to this ESP algorithm must be greater or equal to the key size. The cipher's encryption and decryption key is taken from the first bits of the keying material, where represents the required key size. 4. Security Considerations Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. The case for using random values for IVs has been refined with the following summary provided by Steve Bellovin. Refer to [Bell97] for further information. For further security considerations, the reader is encouraged to read the documents that describe the actual cipher algorithms. 5. References [Adams97] C. Adams, "The CAST-128 Encryption Algorithm", RFC2144, 1997. [Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-04 [Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC- Pad, and RC5-CTS Algorithms", RFC2040, October 1996 [Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}). [Bosselaers]A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/ [Bradner97] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997 R. Pereira, R. Adams [Page 10] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 [Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, pp. 224-230. [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v2-04 [Lai] X. Lai, "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. [Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", draft-ietf-ipsec-ciph- des-expiv-02 [MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. ISBN 0-8493- 8523-7 [Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471- 12845-7 [Schneier93]B. Schneier, "Description of a New Variable-Length Key, 64-Bit Block Cipher", from "Fast Software Encryption, Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, pp. 191-204. http://www.counterpane.com/bfsverlag.html [Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One Year Later", Dr. Dobb's Journal, September 1995, http://www.counterpane.com/bfdobsoyl.html [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", draft-ietf-ipsec-doc-roadmap-02 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. R. Pereira, R. Adams [Page 11] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 6. Acknowledgments This document is a merger of most of the ESP cipher algorithm documents. This merger was done to facilitate greater understanding of the commonality of all of the ESP algorithms and to further the development of these algorithm within ESP. The content of this document is based on suggestions originally from Stephen Kent and subsequent discussions from the IPSec mailing list as well as other IPSec drafts. Special thanks to Carlisle Adams and Paul Van Oorschot both of Entrust Technologies who provided input and review of CAST. Thanks to all of the editors of the previous ESP 3DES documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. Thanks to Brett Howard from TimeStep for his original work of ESP- RC5. Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel for their input on IDEA and other ciphers. 7. Editors' Addresses Roy Pereira TimeStep Corporation +1 (613) 599-3610 x 4808 Rob Adams Cisco Systems Inc. +1 (408) 457-5397 Contributors: Robert W. Baldwin or RSA Data Security, Inc. +1 (415) 595-8782 Greg Carter Entrust Technologies +1 (613) 763-1358 R. Pereira, R. Adams [Page 12] Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 Rodney Thayer rodney@sabletech.com Sable Technology Corporation +1 (617) 332-7292 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira, R. Adams [Page 13] From owner-ipsec Thu Mar 26 20:25:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03795 for ipsec-outgoing; Thu, 26 Mar 1998 20:24:30 -0500 (EST) Date: Fri, 27 Mar 1998 03:37:38 +0200 (EET) Message-Id: <199803270137.DAA25986@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@tis.com, ipsec@ns.ncsa.com Subject: SSH ISAKMP/Oakley interoperability test site updated to latest drafts X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min Sender: owner-ipsec@ex.tis.com Precedence: bulk I updated the SSH ISAKMP/Oakley interoperability test site to latest drafts, and now it also have some more compatibility options. It should also now have better bandwidth than earlier, so if you had problems earlier you should try again now. The URL for the test site is . Here is update announcement text: ---------------------------------------------------------------------- This site was already announced in the Washington IETF IPSec session, and has been operational since then, but this is official announcement for its availability for testing. The SSH ISAKMP/Oakley test site is web based test site for ISAKMP/Oakley servers and it allows your implementation to perform negotiations against the test server. It gives you sufficient debugging output, so you can resolve most problems yourself; we are happy to work with you on the remaining ones (send mail to isakmp-support@ssh.fi). For demonstration purposes, you can also put our implementation negotiating against itself by giving 194.100.55.1 as the IP address for the other end and using different port number for each end. I've now configured the system so that you can also use port 500 for testing at the SSH end. So if you couldn't test earlier because you couldn't configure the remote port, now you can also use port 500. Because only one user can be testing in the same port at same time (the test servers are each completely separate from each other, but running on same machine), it would be good to use some other port if you can, and leave port 500 for those who cannot choose... The SSH ISAKMP/Oakley test site supports latest drafts (isakmp-09, oakley-02, isakmp-oakley-07, doi-08), and following options in those drafts: - Several compatibility flags. - Authentication with Pre-Shared keys and limited support for DSA/RSA signatures and RSA encryption authentications. Authentication via signatures or encryption is slightly limited because you have to configure your own system so it trusts our test CA key (certificate for it can be found on the main page) or just trusts any certificate sent by the other end (you also need to put the "trust all certificates" flag on in SSH end so it will trust your certificates). The certificate sent by the other end must have the correct IP address in the alt name field. We can also manually do some CA operations here, so send mail to isakmp-support@ssh.fi if you want to do even more complicated certificate testing. - Both responder and initiator ends. - Both Main mode and Aggressive mode. - New group mode between main or aggressive mode and quick mode. - Quick mode. - Encryption algorithms: DES, Blowfish, 3DES, and CAST-128. - Hash algorithms: MD5, and SHA - Diffie-Hellman Groups: 1, 2, private group arguments given in ISAKMP proposal, and private group negotiated in new group mode (for quick mode). It also supports 1536 bit modp group created by Richard Schroeppel and posted to linux-ipsec list. This is numbered to be group 5. - With or without PFS in quick mode. The ISAKMP/Oakley test site is NOT connected to an IPSec engine so it will just print out the resulting keys after negotiation, so you can check them (note, that it will print just raw key material, parity bits etc are fixed in the IPSec engine level, not in this level). If you have any comments, problems, enchancements etc please send mail to isakmp-support@ssh.fi. I will try to add some more help texts to the pages later, but I think implementators should be able to understand the user interface and debug output already. I really hope this service will be usefull to IPSec community. For more information about SSH ipsec see http://www.ssh.fi/ipsec.html -- kivinen@ssh.fi Work : +358-9-4354 3207 SSH Communications Security http://www.ssh.fi/ From owner-ipsec Thu Mar 26 20:28:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03811 for ipsec-outgoing; Thu, 26 Mar 1998 20:28:29 -0500 (EST) Message-ID: From: JGC To: Paul Koning , iesg@ns.ietf.org, minshall@fiberlane.com Cc: ipsec@tis.com, ietf@ns.ietf.org Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 26 Mar 1998 17:45:28 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The issue that Greg brings up is very important. My company relies on port information heavily for analysis of protocols and applications and if this information is obscured it becomes difficult to accurately report on the different applications that are running. The option to supply port information means that security can be downgraded (i.e. the ports can be revealed) when a management application needs to run (for troubleshooting purposes, for example) and then can easily be switched on. This would be a very valuable service. In addition some devices characterize traffic priority based on ports (and other information) and in the presence of an IPSEC packet these devices would not work (which is of course a classic example of the security/functionality trade off). In addition a way to read the full packet information at an appropriate point in the protocol stack (post decryption) will probably be important for some vendors, or the ability to do their own decryption. John Graham-Cumming Optimal Networks -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Thursday, March 26, 1998 3:07 PM To: iesg@ns.ietf.org; minshall@fiberlane.com Cc: ipsec@tis.com; ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard I would support the concern that Greg raised. There is an increased use of finer-grained traffic classification, in which port numbers play a role. It is true that, for maximum security, this information may want to be hidden. Greg recognized that in his suggestion that the port number copy in the security header could be supplied as all zero. If the port number is concealed (either with IPSec as it is currently defined, or with zeroed port numbers in Greg's suggestion) then a traffic classifier would have no port information and would have to classify all that traffic as "other" or "unknown application". This may be acceptable in many cases. By creating an *option* of supplying port information to the classifier, it allows a user to give up a small amount of security and gain the benefit of being classified into a different traffic category that has different (presumably better) service. I believe this is a valuable option. Paul Koning Xedia Corporation From owner-ipsec Thu Mar 26 22:34:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04579 for ipsec-outgoing; Thu, 26 Mar 1998 22:33:31 -0500 (EST) Message-Id: <199803270347.WAA05071@istari.sandelman.ottawa.on.ca> To: Greg Minshall CC: ipsec@tis.com, iesg@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 11:26:26 PST." <199803261926.LAA04909@red.mtv.fiberlane.com> Date: Thu, 26 Mar 1998 22:47:12 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Greg" == Greg Minshall writes: Greg> operating and managing the internet (and smaller intranets). For Greg> example, these days we are able to measure traffic growth by Greg> application type ("how much of the traffic is HTTP traffic and how Greg> is that changing over time?" is typical of the questions we ask This provides classification data on application type. That is one use... and I tend to agree with you. Greg> there). When debugging problems, correlating packets observed with Greg> known application behaviours ("oh, yes, that must be from a buggy Greg> version of TN3270") is often useful. We occasionally would like to How does having the port numbers help here? I'm not being critical, I'm just trying to understand if this is really a different use of the port numbers. Greg> While it is quite possible that the removal of port numbers from Greg> the cleartext payload will *not* adversely affect the operating of Greg> the internet, i worry that it may impact things negatively. I'm afraid that a lot of us want to keep our traffic patterns private. AH does provide for counting of traffic, and may see significant use for securing TCP sessions against flooding. Greg> If i were to summarize what i would like to see done, it would be Greg> to provide room in the cleartext portion of the IPSEC header for Greg> "32 bits of source and destination port numbers (or their Oops, no changing bits on the wire at this point, PLEASE. Greg> equivalent) in protocols that have the concept of port numbers", Greg> along with "advice to implementors" that the ultimate receiver Greg> should use these bits, if not zero, to replace the port numbers Greg> carried within the encrypted payload. (Applications worried about Greg> port-based traffic analysis would be able to use zeroes in the Greg> cleartext header.) Why should the authenticated port numbers be replaced with unauthenticated ones? That seems very wrong to me. I think perhaps you really want an IP option (not sure if it should be hop-by-hop or destination... probably destination) that provides a "service number" --- HTTP would always use 80, even if the actual HTTP server was on a different port. Greg> I am hoping that from the point of view of the entire IETF, we may Greg> be able to decide that managing the network is important enough to Greg> move the port numbers into the clear. I understand that you want metering. For the inital adopters of IPsec, the VPN people, this is entirely unacceptable. Further, for the purposes of metering, the packets are not "HTTP" or "SMTP" packets, but "VPN" packets, and the ESP header type pretty much tells you that. For later adopters of IPsec, AH may predominate, either because the application layer has its own encryption system, and one is simply protecting the transport (e.g. CORBA or SSL over TCP), or it may be public data anyway. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNRshP9iXVu0RiA21AQEzTgL/ewdreQsV/SnsdXx9WZCho0T8gqFqCrUP rbvdDhkfUdOr39rVYrv9ZYrb40ebRc2a2K6ir9WgLgZmZu0UG9trfgdQVnSciGYi 5/K7YHlPSvfJXM8Kn5bnKQRXPXHhJRHJ =Y4bI -----END PGP SIGNATURE----- From owner-ipsec Thu Mar 26 22:40:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04607 for ipsec-outgoing; Thu, 26 Mar 1998 22:40:31 -0500 (EST) Message-Id: <199803270353.WAA05108@istari.sandelman.ottawa.on.ca> To: Paul Koning cc: iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 18:07:21 EST." <9803262307.AA01547@kona.> Date: Thu, 26 Mar 1998 22:53:50 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> I would support the concern that Greg raised. Paul> There is an increased use of finer-grained traffic classification, Paul> in which port numbers play a role. I believe that IPv6 has a flow label specifically designed for this. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Thu Mar 26 23:53:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05052 for ipsec-outgoing; Thu, 26 Mar 1998 23:50:31 -0500 (EST) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'iesg@ns.ietf.org'" Cc: ipsec@tis.com Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 26 Mar 1998 21:04:20 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk The IPSEC group should be commended for getting this large body of work to this phase. Onto comments. Disclaimers apply. My list is ordered. This number 1 topic is an old one, but given that we are really at the beginning of an era of standardized IPSEC it seems worth discussing and understanding what we are all commiting to. comment 1) Many people who are in the middle of implementing IPSEC AH are discovering the ugliness of this thing. Many are wondering in the privacy of their own development shops why we don't simply eliminate this AH thing and build the equivalent functionality into a set of ESP transforms. This would result in a cleaner set of implementations and probably smaller, cheaper, better silicon and code. In my own casual survey I have yet to run into anyone who feels strongly about keeping and/or using AH. Our experience at Microsoft working with hardware folks (chip, cards, motherboards, smartcards, etc.) who are working on IPSEC is that they would like to worry about one form of encapsulation, and they would like to put the AH ICV at the end of the packet ala IPSEC ESP. COMMENT 2) It is not clear if one would call it a protocol bug or not, but as currently spec'd it is possible for two peers to get into the following state: a) SAs established based on data flow triggering from A to B, A is the initiator (e.g. policy on A: do IPSEC for traffic to peer B) b) A crashes c) B holds an SA and believes the other side (A) is still able to undo IPSEC traffic on the SA that was wiped out on the reboot of A. All IPSEC'd traffic from B to A is unusable and nothing drives the establishment of new SAs btw A and B since A has no traffic destined for B and B already has what it thinks are valid SAs to A. there are several proposals for peer recovery floating around, but without it the spec seems incomplete. comment 3) Calling something "The Internet Key Exchange" seems a little out of place given the wild mileau of Key exchanges floating around in IETF working groups, let alone on the Internet at large. If AH moves to PS, customers will expect it to be part of ALL implementations. This is the time to simplify IPSEC. cheers, peter > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ns.ietf.org] > Sent: Friday, March 20, 1998 12:08 PM > Cc: ipsec@tis.com > Subject: Last Call: Security Architecture for the Internet Protocol > to Proposed Standard > > > The IESG has received a request from the IP Security Protocol Working > Group to consider publication of the following Internet-Drafts as > Proposed Standards: > > o Security Architecture for the Internet Protocol > > o IP Authentication Header > > o The Use of HMAC-MD5-96 within ESP and AH > > o The Use of HMAC-SHA-1-96 within ESP and AH > > o The ESP DES-CBC Cipher Algorithm With Explicit IV > > o IP Encapsulating Security Payload (ESP) > > o The Internet IP Security Domain of Interpretation for ISAKMP > > o Internet Security Association and Key Management Protocol (ISAKMP) > > o The Internet Key Exchange (IKE) > > o The NULL Encryption Algorithm and Its Use With IPsec > > > > The IESG will also consider publication of the following > Internet-Drafts as Informational RFCs: > > o IP Security Protocol Working Group to consider IP Security Document > Roadmap > > o The OAKLEY Key Determination Protocol > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 11, 1998. > > Files can be obtained via: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-05.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.tx > t > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.tx > t > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-00.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt From owner-ipsec Fri Mar 27 00:05:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA05156 for ipsec-outgoing; Fri, 27 Mar 1998 00:04:35 -0500 (EST) Message-Id: <199803270518.AAA29715@jekyll.piermont.com> To: Paul Koning cc: iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 18:07:21 EST." <9803262307.AA01547@kona.> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Mar 1998 00:18:07 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul Koning writes: > I would support the concern that Greg raised. > > There is an increased use of finer-grained traffic classification, in > which port numbers play a role. > > It is true that, for maximum security, this information may want to be > hidden. Greg recognized that in his suggestion that the port number > copy in the security header could be supplied as all zero. 1) Our packets are already too long, thanks to IPSec. Another four bytes is going to be killer on slow links. 2) In general, it isn't a good idea to give people overly many security knobs to tweak. Most of the time you want to defeat traffic analysis anyway, and given that you are going to want to recommend that people run without revealing their ports, "What is the point?" > By creating an *option* of supplying port information to the > classifier, it allows a user to give up a small amount of security and > gain the benefit of being classified into a different traffic category > that has different (presumably better) service. Its actually a fairly high amount of security. Were I attacking someone's traffic, gaining information on which TCP connection is which is invaluable. I might be able to extract that from timing information already, but this way I'm *certain* to be able to extract it, and have lots of nice known plaintext with it. Even if I can't break the traffic, the traffic analysis information alone might be sufficient to gain lots of interesting information, and I don't think the benefit is actually that important in context. Perry From owner-ipsec Fri Mar 27 00:14:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA05212 for ipsec-outgoing; Fri, 27 Mar 1998 00:14:32 -0500 (EST) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D41@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'Greg Minshall'" , iesg@ns.ietf.org Cc: ipsec@tis.com, ietf@ns.ietf.org Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 26 Mar 1998 21:27:23 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, (call the protocol police, 3 alarm layer violation in progress ... :-)) The 32 bit hack probably will not be enough. Folks have proposed the use of SNOOPing protocols that need to look at the TCP seq numbers passing by to enhance the performance of TCP on wireless/mobile links. I would suggest a separate ESP transform instead of mucking up the IPSEC architecture in general. IP proto issues arise ... While I am not fond of the idea of this form of "management" I agree that many people have become dependant on the use of port numbers for managing their networks (firewalls, filters, etc.) cheers, peter > -----Original Message----- > From: Greg Minshall [SMTP:minshall@fiberlane.com] > Sent: Thursday, March 26, 1998 11:26 AM > To: iesg@ns.ietf.org > Cc: ipsec@tis.com; ietf@ns.ietf.org > Subject: Re: Last Call: Security Architecture for the Internet > Protocol to Proposed Standard > > Dear IESG, > > I have one serious concern about the IP Security Architecture, which is > the > fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. > > I think this is a significant issue in a number of areas related to > operating > and managing the internet (and smaller intranets). For example, these > days we > are able to measure traffic growth by application type ("how much of the > traffic is HTTP traffic and how is that changing over time?" is typical of > the > questions we ask there). When debugging problems, correlating packets > observed with known application behaviours ("oh, yes, that must be from a > buggy version of TN3270") is often useful. We occasionally would like to > give > different classes of service to different application types. > > While it is quite possible that the removal of port numbers from the > cleartext > payload will *not* adversely affect the operating of the internet, i worry > > that it may impact things negatively. > > If i were to summarize what i would like to see done, it would be to > provide > room in the cleartext portion of the IPSEC header for "32 bits of source > and > destination port numbers (or their equivalent) in protocols that have the > concept of port numbers", along with "advice to implementors" that the > ultimate receiver should use these bits, if not zero, to replace the port > numbers carried within the encrypted payload. (Applications worried about > > port-based traffic analysis would be able to use zeroes in the cleartext > header.) > > This issue was raised (several years ago) within the IPSEC working group. > > After a reasonable discussion, the working group decided to leave the port > > numbers encrypted. I think that from the IPSEC working group's point of > view, > this makes sense (maximum security). I am hoping that from the point of > view > of the entire IETF, we may be able to decide that managing the network is > important enough to move the port numbers into the clear. > > Thanks very much for your consideration in this matter, > > Greg Minshall > > From owner-ipsec Fri Mar 27 00:24:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA05264 for ipsec-outgoing; Fri, 27 Mar 1998 00:24:33 -0500 (EST) Message-Id: <199803270536.AAA29753@jekyll.piermont.com> To: JGC cc: Paul Koning , iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 17:45:28 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Mar 1998 00:36:57 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk JGC writes: > The option to supply port information means that security can be > downgraded (i.e. the ports can be revealed) when a management > application needs to run (for troubleshooting purposes, for example) and > then can easily be switched on. You can do that by turning off ESP and switching to AH for a while if you need to for troubleshooting. You don't need to ruin the protocol to do that. > This would be a very valuable service. In addition some devices > characterize traffic priority based on ports (and other information) > and in the presence of an IPSEC packet these devices would not work > (which is of course a classic example of the security/functionality > trade off). I dunno what the lost functionality is. You can still label your packets with TOS markings. Perry From owner-ipsec Fri Mar 27 00:38:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA05343 for ipsec-outgoing; Fri, 27 Mar 1998 00:37:32 -0500 (EST) Message-Id: <199803270550.VAA12880@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Peter Ford Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: Your message of "Thu, 26 Mar 1998 21:04:20 PST." <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Mar 1998 21:50:48 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter, > comment 3) Calling something "The Internet Key Exchange" seems a little out > of place given the wild mileau of Key exchanges floating around in IETF > working groups, let alone on the Internet at large. The other front runner was KEG-- The Key Exchange Gestalt. I happen to think that gestalt is a nice way to describe it but I just couldn't call this protocol KEG with a straight face (and I doubt you could either). Perhaps if we renamed IPSec to be the Basic Encryption Encoding Rules.... I'm not quite sure I understand what you mean by the "wild mileau of Key exchanges floating arount in IETF working groups". Care to expand on that? Dan. From owner-ipsec Fri Mar 27 01:26:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05652 for ipsec-outgoing; Fri, 27 Mar 1998 01:24:32 -0500 (EST) Date: Thu, 26 Mar 1998 22:36:23 -0800 (PST) Message-Id: <199803270636.WAA21606@servo.qualcomm.com> From: Phil Karn To: minshall@fiberlane.com CC: iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-reply-to: <199803261926.LAA04909@red.mtv.fiberlane.com> (message from Greg Minshall on Thu, 26 Mar 1998 11:26:26 -0800) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk >I have one serious concern about the IP Security Architecture, which is the >fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. This is a deliberate feature, not a bug. Actually, it's not even a "feature" per se -- it's an inherent property of encryption just above the IP layer, which is what IPSEC is all about. Encryption just above IP is in keeping with the well-established security principle of "need to know". IP is itself designed such that all the information a router really needs to know -- and nothing else -- is contained in the IP header. So only it needs to be in the clear, and everything above it can be encrypted. (Actually, this is not *quite* true -- the Protocol field is interpreted only by the destination host, so it doesn't really belong in the IP header. But IPSEC fixes this by replacing the IP header Protocol field with "ESP" and moving the "real" Protocol value into the encrypted IPSEC header.) As an aside, I've noticed that well-layered protocols lend themselves well to effective security mechanisms. Conversely, ill-layered protocols are hard to secure. A major side benefit of the widespread deployment of encryption is to force our protocols to be better layered. In turn, this makes them easier to secure. I consider this a Good Thing both ways. IPSEC is especially useful for constructing virtual private networks over the public Internet. The IPSEC tunnels carrying packets between the "islands" of the virtual private network will therefore carry IP packets in their payloads, the entire contents of which will be encrypted. Only the IP addresses of the tunnel endpoints are (and need be) in the clear. An attacker cannot determine the identities of the end systems using the tunnel or even how many are in each "island" (except as can possibly be inferred by traffic analysis). This helps protect those end systems from being identified and targeted for attack by other means. (It's well known (see Bellovin and Cheswick) that hosts "protected" by firewalls tend to let their own host-based security mechanisms atrophy, making them "chewy" targets to an attacker that can find some other means of reaching them.) Another example of the utility of IPSEC is in protecting the identity of a Mobile IP user. If the user runs his own foreign agent in combination with IPSEC, then an eavesdropper can only determine that someone belonging to a certain home agent is active from a certain area. He cannot identify the specific user, because the Mobile IP user's permanent IP address is encrypted inside the IPSEC tunnel created between his foreign and home agents. If the home agent serves many users (or if its packets are further protected by separate IPSEC tunnels), even greater protection is obtained. Even when IPSEC is used on an end-to-end basis, with the transport protocol header immediately following the ESP header, encryption just above IP is still beneficial. It prevents a potential attacker from learning the nature of the applications being run on the machine or even whether it is acting as client or server (though this could probably be inferred by the timing of the packets exchanged). This makes it that much harder for an attacker to know which services he should attack. In sum, by encrypting everything not absolutely essential for an IP router to do its job, IPSEC is the single strongest Internet security tool one can conceive of short of generating decoy traffic to thwart traffic analysis. But it will probably not replace other security mechanisms. PGP, SSH and SSL will continue to be widely used wherever the end hosts support them. Much traffic that is non-sensitive (such as public web objects) will remain in the clear (though encryption has utility even here as a means of protecting the reader's identity.) Those monitoring net traffic will still be able to distinguish these applications from each other and from IPSEC ESP and AH. Phil From owner-ipsec Fri Mar 27 01:48:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05808 for ipsec-outgoing; Fri, 27 Mar 1998 01:48:36 -0500 (EST) Date: Thu, 26 Mar 1998 23:00:07 -0800 (PST) Message-Id: <199803270700.XAA21670@servo.qualcomm.com> From: Phil Karn To: pkoning@xedia.com CC: iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-reply-to: <9803262307.AA01547@kona.> (message from Paul Koning on Thu, 26 Mar 1998 18:07:21 -0500) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk >By creating an *option* of supplying port information to the >classifier, it allows a user to give up a small amount of security and >gain the benefit of being classified into a different traffic category >that has different (presumably better) service. I believe this is a >valuable option. Other, far better-layered mechanisms already exist to categorize traffic with various levels of service. The TOS field in the IP header is the prime example. Also, policy routing based on IP source and destination addresses is also possible. Admittedly, both these mechanisms raise difficult security issues of their own if the economic incentives to abuse them are ever created. E.g., if Internet backbones were to interpret the TOS Precedence bits as a queuing priority indicator, charging by the packet for high priority traffic while continuing to deliver routine traffic on a best-effort basis for free, then there would be an incentive to use false IP source addresses on high precedence packets to avoid charges. The use of IPSEC by end systems or border routers neither creates nor eliminates such issues. But one can certainly conceive of applying IPSEC to them. E.g., an IPSEC tunnel from end user to carrier gateway could authenticate the precedence fields on encapsulated packets that are extracted and routed at high priority by the carrier. These packets could in turn contain further layers of IPSEC encryption operating on an end-to-end basis to protect against eavesdropping within (or by) the carrier. IPSEC was originally designed to protect hosts on small private networks from the big bad public network. But it's also possible to use it to protect (parts of) the public network itself from all those hosts on private networks. It's really a very flexible protocol. It just takes a little imagination and creativity in using it. Phil From owner-ipsec Fri Mar 27 02:00:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA05867 for ipsec-outgoing; Fri, 27 Mar 1998 02:00:31 -0500 (EST) Date: Thu, 26 Mar 1998 23:10:52 -0800 (PST) Message-Id: <199803270710.XAA21783@servo.qualcomm.com> From: Phil Karn To: jgc@optimal.com CC: pkoning@xedia.com, iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-reply-to: (message from JGC on Thu, 26 Mar 1998 17:45:28 -0800) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk >The issue that Greg brings up is very important. My company relies on >port information heavily for analysis of protocols and applications and >if this information is obscured it becomes difficult to accurately >report on the different applications that are running. IPSEC is most often implemented on border routers between private subnets and the public Internet to protect inter-subnet traffic between hosts that can't protect themselves on an end-to-end basis. (It seems less likely that IPSEC will replace existing end-to-end encryption mechanisms like PGP, SSH and SSL where they are already implemented.) In such "tunnel" configurations, the packets are still available in plaintext within the private networks, where they can be monitored and debugged by the operators of those networks. Similarly, any information needed by the subnet's internal and border routers for traffic classification is still available. Only the external, public part of the path is encrypted. Phil From owner-ipsec Fri Mar 27 02:17:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA05987 for ipsec-outgoing; Fri, 27 Mar 1998 02:15:36 -0500 (EST) Date: Thu, 26 Mar 1998 23:26:47 -0800 (PST) Message-Id: <199803270726.XAA21829@servo.qualcomm.com> From: Phil Karn To: peterf@microsoft.com CC: minshall@fiberlane.com, iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-reply-to: <8D8EF175E72CD111805800805F3198EE03925D41@red-msg-46.dns.microsoft.com> (message from Peter Ford on Thu, 26 Mar 1998 21:27:23 -0800) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk >The 32 bit hack probably will not be enough. Folks have proposed the use of >SNOOPing protocols that need to look at the TCP seq numbers passing by to >enhance the performance of TCP on wireless/mobile links. Indeed. This is yet another reason to avoid such hacks, which I feel are a bad idea anyway. (The requirements of special links, such as radio channels, are IHMO better addressed with mechanisms operating down at those levels, not with hacks to an Internet standard transport protocol that must, by its very nature, remain generic. But I digress.) As I said earlier, one of the side benefits of encryption is to promote cleaner protocol layering, which is itself a worthwhile goal. >While I am not fond of the idea of this form of "management" I agree that >many people have become dependant on the use of port numbers for managing >their networks (firewalls, filters, etc.) Interesting examples. A firewall that filters on port numbers is a security hack that is obviated by IPSEC. If I give you the means to authenticate every packet you let into your network, doesn't that eliminate the need for a conventional packet filter? Actually, an IPSEC gateway can *augment* a packet filter. Instead of making ad-hoc filtering decisions on unauthenticated header information that can easily be spoofed, you can make them on the basis of cryptographic authentication that tells you -- quite reliably -- WHO sent you this packet in addition to WHAT he sent you. Isn't that what you really want to know? Phil From owner-ipsec Fri Mar 27 03:53:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA06665 for ipsec-outgoing; Fri, 27 Mar 1998 03:50:31 -0500 (EST) From: "Alexei V. Vopilov" To: "Roy Pereira" , "'Greg Minshall'" Cc: "IPsec MailList" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Fri, 27 Mar 1998 12:03:33 +0300 Message-ID: <01bd595f$3845b6e0$95883ac0@alx-home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 DAA06662 Sender: owner-ipsec@ex.tis.com Precedence: bulk At least two things get affected on intermediate routers due to presence of IPsec traffic going through. 1. Fine grained Statistic counting 2. Traffic Inspection on packet per packet basis First issue can be partially resolved by having protocol support logically equivalent to: Host A negotiates a SA destined to Host B with Router R. Tricky logic, but can be technically achieved with modification of current ISAKMP. While this might open a new sort of attacks (I don't care), the router R can further differentiate IPsec traffic by SPI value found in there. Note that fine grained SAs must be used to handle different priorities/precise statistics for traffic going through router R. Second issue can be resolved only under an assumption that host A and B will reveal information to R that is equivalent to having the case: SA: A to B = AH(A->B, application data)) SA: A to R = ESP(A->R, AH(A->B, application data)) SA: R to B = ESP(R->B, AH(B->A, application data)) SA: B to A = AH(B->A, application data)) SA: B to R = ESP(B->R, AH(B->A, application data)) SA: R to a = ESP(R->A, AH(B->A, application data)) Nothing prevents to have this done based on current specs though nothing is in the specs to simplify such a policy management. --- Alexei --- -----Original Message----- From: Roy Pereira To: 'Greg Minshall' Cc: 'ipsec@tis.com' Date: 27 ìàðòà 1998 ã. 0:41 Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard :There does exist a balacing act between manageability and security, but :IPSec was meant to be as secure as possible. I beleive that most :customers will want to hide the port numbers along with the identities :of the protected systems, ie. hide as much as possible. : :By adding ports to the ESP header, you would also have to add yet :another field for the protocol being protected as well, since the next :protocol field in ESP might be pointing to another ESP/AH or IPComp :header. This is five extra bytes (protocol + source/dest port) that :most people in the working group would not be happy with. : :>-----Original Message----- :>From: Greg Minshall [SMTP:minshall@fiberlane.com] :>Sent: Thursday, March 26, 1998 2:26 PM :>To: iesg@ns.ietf.org :>Cc: ipsec@tis.com; ietf@ns.ietf.org :>Subject: Re: Last Call: Security Architecture for the Internet Protocol to :>Proposed Standard :> :>Dear IESG, :> :>I have one serious concern about the IP Security Architecture, which is the :>fact that IPSEC packets encrypt the TCP/UDP port numbers in packets. :> :>I think this is a significant issue in a number of areas related to operating :>and managing the internet (and smaller intranets). For example, these days :>we :>are able to measure traffic growth by application type ("how much of the :>traffic is HTTP traffic and how is that changing over time?" is typical of :>the :>questions we ask there). When debugging problems, correlating packets :>observed with known application behaviours ("oh, yes, that must be from a :>buggy version of TN3270") is often useful. We occasionally would like to :>give :>different classes of service to different application types. :> :>While it is quite possible that the removal of port numbers from the :>cleartext :>payload will *not* adversely affect the operating of the internet, i worry :>that it may impact things negatively. :> :>If i were to summarize what i would like to see done, it would be to provide :>room in the cleartext portion of the IPSEC header for "32 bits of source and :>destination port numbers (or their equivalent) in protocols that have the :>concept of port numbers", along with "advice to implementors" that the :>ultimate receiver should use these bits, if not zero, to replace the port :>numbers carried within the encrypted payload. (Applications worried about :>port-based traffic analysis would be able to use zeroes in the cleartext :>header.) :> :>This issue was raised (several years ago) within the IPSEC working group. :>After a reasonable discussion, the working group decided to leave the port :>numbers encrypted. I think that from the IPSEC working group's point of :>view, :>this makes sense (maximum security). I am hoping that from the point of view :>of the entire IETF, we may be able to decide that managing the network is :>important enough to move the port numbers into the clear. :> :>Thanks very much for your consideration in this matter, :> :>Greg Minshall :> :> :> :> :> : From owner-ipsec Fri Mar 27 09:13:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08639 for ipsec-outgoing; Fri, 27 Mar 1998 09:07:34 -0500 (EST) Message-Id: <199803271421.JAA01982@jekyll.piermont.com> To: "Alexei V. Vopilov" cc: "Roy Pereira" , "'Greg Minshall'" , "IPsec MailList" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Fri, 27 Mar 1998 12:03:33 +0300." <01bd595f$3845b6e0$95883ac0@alx-home> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Mar 1998 09:21:04 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Alexei V. Vopilov" writes: > First issue can be partially resolved by having protocol > support logically equivalent to: > Host A negotiates a SA destined to Host B with Router R. Repulsive and dangerous to security. > Tricky logic, but can be technically achieved with modification > of current ISAKMP. While this might open a new sort of attacks > (I don't care), the router R can further differentiate IPsec traffic > by SPI value found in there. The "(I don't care)" worries me here. > Second issue can be resolved only under an assumption that host A and B > will reveal information to R that is equivalent to having the case: Sharing keys with intermediate routers is also a really, really, amazingly bad idea from a security standpoint. To recap, the two problems you are solving are: > 1. Fine grained Statistic counting Which doesn't strike me as so worthy a goal as to make security compromises necessary, and: > 2. Traffic Inspection on packet per packet basis Which also doesn't strike me as that important a goal in context. Perry From owner-ipsec Fri Mar 27 09:19:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08789 for ipsec-outgoing; Fri, 27 Mar 1998 09:17:32 -0500 (EST) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Fri, 27 Mar 1998 16:35:53 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Roy Pereira cc: "IPSEC Mailing List (E-mail)" Subject: Re: updated draft-ietf-ipsec-ciph-cbc-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 26 Mar 1998, Roy Pereira wrote: > IDEA: > > IDEA has been found to have weak keys. Please check with [MOV] and > [Schneier] for more information. As Bart already mentioned, there'll be a new paper by Philip Hawkes on Eurocrypt '98 about a broader class of weak keys of IDEA (the class is still not big enough to be a practical threat (of size 2^63)). [Schneier] does not even list the keys being known at this time. May be the above should be reworded as: IDEA has been found to have weak keys. [MOV] and [Schneier] cover the state of art in 1996. As of 1998, broader classes of weak keys have been found, but the attacks are not practical. > +--------------------+------------+----------------------+ > | IDEA | No | 8 | > +--------------------+------------+----------------------+ Btw, read Hawkes about the perils of four-round IDEA. > For a comparison table of the estimated speed of any of these and > other cipher algorithms, please see [Schneier97] or for an up-to- > date performance comparison, please see [Bosseleaers]. Correct spelling: [Bosselaers]. Probably we should contact and notice him before using his website as a link in the draft. The numbers on his homepage are from an yet unpublished paper. He himself or Bart can give the exact reference. Helger From owner-ipsec Fri Mar 27 09:19:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08788 for ipsec-outgoing; Fri, 27 Mar 1998 09:17:31 -0500 (EST) From: Adam Shostack Message-Id: <199803271424.JAA22332@homeport.org> Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: <199803270726.XAA21829@servo.qualcomm.com> from Phil Karn at "Mar 26, 98 11:26:47 pm" To: karn@qualcomm.com (Phil Karn) Date: Fri, 27 Mar 1998 09:24:21 -0500 (EST) Cc: peterf@microsoft.com, minshall@fiberlane.com, iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn wrote: | Interesting examples. A firewall that filters on port numbers is a | security hack that is obviated by IPSEC. If I give you the means to | authenticate every packet you let into your network, doesn't that | eliminate the need for a conventional packet filter? It does not. I may well want to control packets entering my network by destination. Authenticating the inbound packets does not provide this. However, its a poor security policy which exposes some ports on an insecure machine to attack. A packet screen is a useful line of defense for a network, and preventing unauthenticated, and/or packets going to unacceptable destinations is a useful way to reduce your security exposure to the internet. So usefulness of a packet filter is not eliminated. | Actually, an IPSEC gateway can *augment* a packet filter. Instead of | making ad-hoc filtering decisions on unauthenticated header | information that can easily be spoofed, you can make them on the basis | of cryptographic authentication that tells you -- quite reliably -- | WHO sent you this packet in addition to WHAT he sent you. Isn't that | what you really want to know? I agree wholeheartedly here. If port filtering is an essential part of your security scheme, I'd suggest either redesigning your scheme, or tunnelling to the firewall, decrypting, and then making your filtering decisions. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-ipsec Fri Mar 27 09:21:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08812 for ipsec-outgoing; Fri, 27 Mar 1998 09:19:32 -0500 (EST) Message-Id: To: Peter Ford cc: "'Greg Minshall'" , iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 21:27:23 PST." <8D8EF175E72CD111805800805F3198EE03925D41@red-msg-46.dns.microsoft.com> Date: Fri, 27 Mar 1998 09:28:26 -0500 From: "Mike O'Dell" Sender: owner-ipsec@ex.tis.com Precedence: bulk it's much worse than that - i know of router-oid hardware which will not only snuffle TCP state, it will parse HTTP state and HTML constructs on the fly and do unspeakable things based on that information. i believe the harder we make such things the better we'll sleep (grin) -mo From owner-ipsec Fri Mar 27 10:51:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09504 for ipsec-outgoing; Fri, 27 Mar 1998 10:47:35 -0500 (EST) Message-Id: <3.0.5.32.19980327100548.0094cda0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 10:05:48 -0500 To: Phil Karn From: Bob Natale Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com In-Reply-To: <199803270710.XAA21783@servo.qualcomm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >At 11:10 PM 3/26/98 -0800, Phil Karn wrote: Hi Phil, I apologize in advance for this (hopefully minor) sidebar... I've pared down the cc: list in the hopes of minimizing the pain. >(It seems less likely that IPSEC will replace existing end-to-end >encryption mechanisms like PGP, SSH and SSL where they are already >implemented.) Can anyone point me to a good reference that might compare these three alternatives (or a subset of them, and/or any similarly end-to-end schemes)...esp., what are their relative strengths and weaknesses and/or suitability for particular types of applications or situations? Thanks. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From owner-ipsec Fri Mar 27 11:42:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10040 for ipsec-outgoing; Fri, 27 Mar 1998 11:39:35 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'Peter Ford'" , "'iesg@ns.ietf.org'" Cc: "'ipsec@tis.com'" Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Fri, 27 Mar 1998 08:41:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk I fully agree with Peter's first comment. It is a problem to implement AH in hardware on the fly, because you have to hold the entire packet till Integrity check is completed (the signature is placed at the beginning of the packet). The same functionality as AH can be achieved by implementing ESP in tunnel mode. In most cases, ESP with NULL encryption will suffice anyway. Therefore, either AH should be removed entirely, or at least it should not be considered mandatory to implement. The following paragraph is from a mail to this working group by Steve Bellovin. --- Steve's paragraph --- You can use AH+ESP to protect the IP header, or you could use ESP in tunnel mode, even between two end hosts. While some of us do indeed feel that we should not have two such similar options, there was no consensus on eliminating AH+ESP, or on eliminating AH altogether, in favor of ESP with a null encryption transform. --- End of quote --- Baiju -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Peter Ford Sent: Thursday, March 26, 1998 9:04 PM To: 'iesg@ns.ietf.org' Cc: ipsec@tis.com Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard The IPSEC group should be commended for getting this large body of work to this phase. Onto comments. Disclaimers apply. My list is ordered. This number 1 topic is an old one, but given that we are really at the beginning of an era of standardized IPSEC it seems worth discussing and understanding what we are all commiting to. comment 1) Many people who are in the middle of implementing IPSEC AH are discovering the ugliness of this thing. Many are wondering in the privacy of their own development shops why we don't simply eliminate this AH thing and build the equivalent functionality into a set of ESP transforms. This would result in a cleaner set of implementations and probably smaller, cheaper, better silicon and code. In my own casual survey I have yet to run into anyone who feels strongly about keeping and/or using AH. Our experience at Microsoft working with hardware folks (chip, cards, motherboards, smartcards, etc.) who are working on IPSEC is that they would like to worry about one form of encapsulation, and they would like to put the AH ICV at the end of the packet ala IPSEC ESP. COMMENT 2) It is not clear if one would call it a protocol bug or not, but as currently spec'd it is possible for two peers to get into the following state: a) SAs established based on data flow triggering from A to B, A is the initiator (e.g. policy on A: do IPSEC for traffic to peer B) b) A crashes c) B holds an SA and believes the other side (A) is still able to undo IPSEC traffic on the SA that was wiped out on the reboot of A. All IPSEC'd traffic from B to A is unusable and nothing drives the establishment of new SAs btw A and B since A has no traffic destined for B and B already has what it thinks are valid SAs to A. there are several proposals for peer recovery floating around, but without it the spec seems incomplete. comment 3) Calling something "The Internet Key Exchange" seems a little out of place given the wild mileau of Key exchanges floating around in IETF working groups, let alone on the Internet at large. If AH moves to PS, customers will expect it to be part of ALL implementations. This is the time to simplify IPSEC. cheers, peter > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ns.ietf.org] > Sent: Friday, March 20, 1998 12:08 PM > Cc: ipsec@tis.com > Subject: Last Call: Security Architecture for the Internet Protocol > to Proposed Standard > > > The IESG has received a request from the IP Security Protocol Working > Group to consider publication of the following Internet-Drafts as > Proposed Standards: > > o Security Architecture for the Internet Protocol > > o IP Authentication Header > > o The Use of HMAC-MD5-96 within ESP and AH > > o The Use of HMAC-SHA-1-96 within ESP and AH > > o The ESP DES-CBC Cipher Algorithm With Explicit IV > > o IP Encapsulating Security Payload (ESP) > > o The Internet IP Security Domain of Interpretation for ISAKMP > > o Internet Security Association and Key Management Protocol (ISAKMP) > > o The Internet Key Exchange (IKE) > > o The NULL Encryption Algorithm and Its Use With IPsec > > > > The IESG will also consider publication of the following > Internet-Drafts as Informational RFCs: > > o IP Security Protocol Working Group to consider IP Security Document > Roadmap > > o The OAKLEY Key Determination Protocol > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 11, 1998. > > Files can be obtained via: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-05.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.tx > t > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.tx > t > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-00.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt From owner-ipsec Fri Mar 27 11:46:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10117 for ipsec-outgoing; Fri, 27 Mar 1998 11:43:34 -0500 (EST) From: Barney Wolff To: ipsec@tis.com Date: Fri, 27 Mar 1998 11:51 EST Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Content-Type: text/plain Message-ID: <351bd9900.5337@databus.databus.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Thu, 26 Mar 1998 21:50:48 -0800 > From: Daniel Harkins > > The other front runner was KEG-- The Key Exchange Gestalt. I happen to > think that gestalt is a nice way to describe it but I just couldn't call > this protocol KEG with a straight face (and I doubt you could either). > Perhaps if we renamed IPSec to be the Basic Encryption Encoding Rules.... I would have thought Keys for Internet Security Services. Or perhaps not. Barney Wolff From owner-ipsec Fri Mar 27 12:54:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10740 for ipsec-outgoing; Fri, 27 Mar 1998 12:50:36 -0500 (EST) From: Dan McDonald Message-Id: <199803271803.KAA01691@kebe.eng.sun.com> Subject: Re: Last Call: Security Architecture for the Internet Protocol to To: baiju.v.patel@intel.com (Patel, Baiju V) Date: Fri, 27 Mar 1998 10:03:49 -0800 (PST) Cc: peterf@microsoft.com, iesg@ns.ietf.org, ipsec@tis.com In-Reply-To: from "Patel, Baiju V" at Mar 27, 98 08:41:24 am 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 One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing. I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng MS UMPK17-202 || NOT NECESSARILY SUN'S! Extension: x86815 |"rising falling at force ten WWW: http://jurassic.eng/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Fri Mar 27 13:03:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10815 for ipsec-outgoing; Fri, 27 Mar 1998 13:00:36 -0500 (EST) Message-Id: <199803271811.NAA16678@relay.hq.tis.com> To: Peter Ford cc: "'iesg@ns.ietf.org'" , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 21:04:20 PST." <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.microsoft.com> Date: Fri, 27 Mar 1998 10:11:33 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter, > a) SAs established based on data flow triggering from A to B, A is the > initiator (e.g. policy on A: do IPSEC for traffic to peer B) > b) A crashes > c) B holds an SA and believes the other side (A) is still able to undo > IPSEC traffic on the SA that was wiped out on the reboot of A. All IPSEC'd > traffic from B to A is unusable and nothing drives the establishment of new > SAs btw A and B since A has no traffic destined for B and B already has what > it thinks are valid SAs to A. > > there are several proposals for peer recovery floating around, but without > it the spec seems incomplete. If an IPSEC implementation is being pelted with SPI's that it doesn't understand from a particular source, a reasonable thing for it to do might be to turn around and initiate to the host who's sending it all that traffic it doesn't understand. In the subsequent Main Mode exchange, an INITIAL-CONTACT Notify message can be used to inform the host who didn't reboot that previous SA's it holds to the new peer are now invalid. This can be implemented today. I do not believe that there would be concensus to make this mandatory however. > If AH moves to PS, customers will expect it to be part of ALL > implementations. This is the time to simplify IPSEC. No, three years ago was the time to simplify AH/ESP. Now is the time to finish this work and get on with more interesting problems. Though I personally agree with you that there's no need for two slightly different authentication protocols, the fact of the matter is that we collectively settled on the current drafts and now have rough concensus and running code. These drafts are not elegant, but I believe that they do now satisfy the stated requirements for an IP-level security protocol for the Internet. Derrell From owner-ipsec Fri Mar 27 13:26:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11053 for ipsec-outgoing; Fri, 27 Mar 1998 13:23:37 -0500 (EST) Message-Id: <199803271835.NAA12039@postal.research.att.com> To: Dan McDonald cc: baiju.v.patel@intel.com (Patel, Baiju V), peterf@microsoft.com, iesg@ns.ietf.org, ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Date: Fri, 27 Mar 1998 13:35:57 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing. In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'. When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it. I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens. Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing. I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH. All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it. From owner-ipsec Fri Mar 27 13:36:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11139 for ipsec-outgoing; Fri, 27 Mar 1998 13:33:37 -0500 (EST) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D43@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'Phil Karn'" , jgc@optimal.com Cc: pkoning@xedia.com, iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Fri, 27 Mar 1998 10:47:06 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil At least one company is planning on shipping a high volume product that makes it easy to use IPSEC end to end in transport mode. I note there are other end system companies who are already shipping IPSEC in this manner. Over time I expect that E2E will be the dominant model. In the mean time I agree with your observation that Tunnel mode dominates. Your proposed partitioning does not solve the problem the SNOOP guys have on the public network where they want a proxy at the base station (public side) to massage and manipulate packets based on TCP seq #s to better accomodate losses and handoffs of mobile stations. We could probably have an interesting debate as to whether SNOOP is the best way to go... cheers, peter > -----Original Message----- > From: Phil Karn [SMTP:karn@qualcomm.com] > Sent: Thursday, March 26, 1998 11:11 PM > To: jgc@optimal.com > Cc: pkoning@xedia.com; iesg@ns.ietf.org; minshall@fiberlane.com; > ipsec@tis.com; ietf@ns.ietf.org; karn@qualcomm.com > Subject: Re: Last Call: Security Architecture for the Internet > Protocol to Proposed Standard > > >The issue that Greg brings up is very important. My company relies on > >port information heavily for analysis of protocols and applications and > >if this information is obscured it becomes difficult to accurately > >report on the different applications that are running. > > IPSEC is most often implemented on border routers between private > subnets and the public Internet to protect inter-subnet traffic > between hosts that can't protect themselves on an end-to-end > basis. (It seems less likely that IPSEC will replace existing > end-to-end encryption mechanisms like PGP, SSH and SSL where they are > already implemented.) > > In such "tunnel" configurations, the packets are still available in > plaintext within the private networks, where they can be monitored and > debugged by the operators of those networks. Similarly, any > information needed by the subnet's internal and border routers for > traffic classification is still available. Only the external, public > part of the path is encrypted. > > Phil From owner-ipsec Fri Mar 27 15:01:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11697 for ipsec-outgoing; Fri, 27 Mar 1998 14:57:46 -0500 (EST) Date: Fri, 27 Mar 1998 15:11:13 -0500 Message-Id: <199803272011.PAA00945@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Helger Lipmaa Cc: Roy Pereira , "IPSEC Mailing List" In-Reply-To: Helger Lipmaa's message of Fri, 27 Mar 1998 16:35:53 +0200 (EET), Subject: Re: updated draft-ietf-ipsec-ciph-cbc-03.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 27 Mar 1998 16:35:53 +0200 (EET) From: Helger Lipmaa Correct spelling: [Bosselaers]. Probably we should contact and notice him before using his website as a link in the draft. The numbers on his homepage are from an yet unpublished paper. He himself or Bart can give the exact reference. Given how ephemeral web pages can be, I'd be very hesitate citing a web pages as a reference. - Ted From owner-ipsec Fri Mar 27 15:18:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11871 for ipsec-outgoing; Fri, 27 Mar 1998 15:15:40 -0500 (EST) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'Steve Bellovin'" , "'Dan McDonald'" Cc: "'baiju.v.patel@intel.com'" , "'iesg@ns.ietf.org'" , "'ipsec@tis.com'" Subject: RE: Last Call: Security Architecture for the Internet Protocol to Date: Fri, 27 Mar 1998 12:28:33 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >All that notwithstanding, this is not a new issue. We've been over > this ground before in the working group. Several of us, myself > included, suggested deleting AH. We lost. Fine; so be it. Let's ship > the documents and be done with it. No, saying that it is fine is not okay given that there is now an order more experience in building these implementations and from my own personal polling the utility of some of this stuff is questionable (I am picking on AH as a tanglible large item to jettison from this ark). No one is stopped from building and shipping product; the documents should be right, not expedient. IPSEC as currently spec'd is HUUUUUUGGGGGGGEEEEEEEEEEEEEEEEE. The amount of MUSTs in the current IPSEC Architecture document is unnecessary (and I paraphrase here): host implementations MUST have certain mgmt interfaces, manual keying is a MUST, etc., etc. The minimal IPSEC implementation that complies to all of the gorp in these documents is unnecessary for many interesting generally consumer based applications. The specs can be pared down so that smaller, cheaper, better implementations are possible and they meet all of the MUSTs in the specifications. AH is a RIPE target for such pruning. As Steve notes (and as I noted in my original posting) this is an old issue. When reading the spec from the perspective of a really cheap IP based device the specs are outdated with a focus on Router and "Host" implementations. What is galling is that there is functionality mandated that will probably not prove useful. Of course, if the bulk of the people who are building this stuff remain silent and on the sidelines the powerful process of inertia will take over and yet another ITU^H^HETF standard will be on its way out the chute. Folks will elect to build the subset they need and deprecate the meaning of "IPSEC standards based". This is particular disconcerting given the coupling of IPSEC to IPv6. This is not to say that AH should disappear completely. A few MAYs would give it comfortable quarters in the specs. rant, rant, rant, peter > -----Original Message----- > From: Steve Bellovin [SMTP:smb@research.att.com] > Sent: Friday, March 27, 1998 10:36 AM > To: Dan McDonald > Cc: baiju.v.patel@intel.com; Peter Ford; iesg@ns.ietf.org; ipsec@tis.com > Subject: Re: Last Call: Security Architecture for the Internet > Protocol to > > One of the biggest reasons we have AH is because there _are_ > some things in the middle of the "IP header" that need to be > authenticated for them to be simultaneously safe and useful. > The biggest example of this is source routing. > > In my opinion -- and I've posted this before -- there's nothing in the > IP header that's both interesting and protected. You can't protect the > source routing option, since the next-hop pointer changes en route. > Appendix A of the AH draft recognizes that, and lists it as 'mutable -- > zeroed'. > > When you look over the list of IP header fields and options that are > either immutable or predictable, you find that the only things that are > really of interest are the source and destination addresses and the > security label. To the extent that we want to protect the addresses -- > a point that's very unclear to me -- they're bound to the security > association. The security label certainly should be. If you're using > security labels (almost no one does) and you don't have the facilities > to bind it at key management time, use tunnel mode and be done with it. > > I'll admit that I've never been in the operations business, but > I've been told that source routing is a very useful tool for > diagnosing some classes of problems. AH allows source routing > to be useful again w/o opening the holes it opens. > > Well, yes, but not for the reason you specify. The problem with source > routing is that it makes address-spoofing trivial. With AH, people > will either verify certificate names -- the right way to do things -- > or they'll bind a certificate to the source address, and use AH to > verify the legitimacy of it. The route specified has nothing to do > with it, and ESP with null encryption does the same thing. > > I don't like AH, either in concept or design (and in particular I don't > like the way it commits layer violations). Its only real use, as I see > it, is to answer Greg Minshall's objections -- it leaves the port > numbers in the clear, and visible in a context-independent fashion. > With null encryption, the monitoring station has to know that that was > selected. But I'm very far from convinced that these issues are > important enough to justify AH. > > All that notwithstanding, this is not a new issue. We've been over > this ground before in the working group. Several of us, myself > included, suggested deleting AH. We lost. Fine; so be it. Let's ship > the documents and be done with it. From owner-ipsec Fri Mar 27 15:26:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12012 for ipsec-outgoing; Fri, 27 Mar 1998 15:23:40 -0500 (EST) From: "Alexei V. Vopilov" To: Cc: "Roy Pereira" , "'Greg Minshall'" , "IPsec MailList" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Fri, 27 Mar 1998 23:37:06 +0300 Message-ID: <01bd59c0$1bbce8c0$95883ac0@alx-home> 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 :> First issue can be partially resolved by having protocol :> support logically equivalent to: :> Host A negotiates a SA destined to Host B with Router R. : :Repulsive and dangerous to security. Security of what: A, B or R? :> Tricky logic, but can be technically achieved with modification :> of current ISAKMP. While this might open a new sort of attacks :> (I don't care), the router R can further differentiate IPsec traffic :> by SPI value found in there. : :The "(I don't care)" worries me here. Once the functionality is claimed to be in the spec, I would take care about clearing corresponded security issues. Anyway, IMO, preventing attacks on a security system splits on 10% of good underlined specs and the rest 90% of how these specs were implemented. :> Second issue can be resolved only under an assumption that host A and B :> will reveal information to R that is equivalent to having the case: : :Sharing keys with intermediate routers is also a really, really, :amazingly bad idea from a security standpoint. I meant not 'sharing keys', but having nested SAs, terminating at different end points. :To recap, the two problems you are solving are: : :> 1. Fine grained Statistic counting : :Which doesn't strike me as so worthy a goal as to make security :compromises necessary, and: I don't have these problems for at least 6 months ;-), just helping people on the list who asked about _their_ problems. :> 2. Traffic Inspection on packet per packet basis : :Which also doesn't strike me as that important a goal in context. Whenever people want port information to be revealed for filtering purposes I'm just noting that ports information works for (1). It _does_ not work for filtering purposes (2), because 'Port' does not mean 'Service', right? : :Perry I would vote to _not_ invent any new payloads for reasons explained (may be not clear) herein. --Alexei From owner-ipsec Fri Mar 27 17:01:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12629 for ipsec-outgoing; Fri, 27 Mar 1998 16:57:40 -0500 (EST) Message-ID: <351C2432.CF89D5E3@redcreek.com> Date: Fri, 27 Mar 1998 14:12:02 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter Ford wrote: > > IPSEC as currently spec'd is HUUUUUUGGGGGGGEEEEEEEEEEEEEEEEE. IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > > The amount of MUSTs in the current IPSEC Architecture document is > unnecessary (and I paraphrase here): host implementations MUST have certain > mgmt interfaces, manual keying is a MUST, etc., etc. > The amount of MUSTs in the current spec are necessary if you want your network to be SSSSEEEECCCCUUURRRREEE. > Of course, if the bulk of the people who are building this stuff remain > silent and on the sidelines the powerful process of inertia will take over > and yet another ITU^H^HETF standard will be on its way out the chute. Folks > will elect to build the subset they need and deprecate the meaning of "IPSEC > standards based". This is particular disconcerting given the coupling of > IPSEC to IPv6. I think what you mean to say is that if the bulk of us mind our own business the powerful process of microsoft will take over and yet another IETF standard will be ignored by microsoft. From owner-ipsec Fri Mar 27 18:34:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13250 for ipsec-outgoing; Fri, 27 Mar 1998 18:28:42 -0500 (EST) Date: Fri, 27 Mar 1998 18:43:08 -0500 Message-Id: <199803272343.SAA01006@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Draft agenda for IPSEC working group meeting in LA Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk My apologies for posting this rather late. Both Bob and myself were rather swamped this week. Please send any comments on this proposed agenda to Bob and myself. Thanks!! - Ted IPSEC wg Agenda DRAFT Thursday, April 2, 1998 1530 -- 1730 Emerald Bay Room 1530 -- 1535 Agenda Bashing (5 min) Ted Ts'o/Bob Moskowitz 1535 -- 1555 Interoperability issues uncovered at the Raleigh bake-off (20 min) Roy Pereira/TimeStep 1555 -- 1615 CA Interoperability issues (20 min) (TBA) 1615 -- 1625 IPsec-WIT (IPsec Web-based Interoperability Tool) (10 min) Robert Glenn/NIST 1625 -- 1635 IPSec configuration (isakmp-cfg) (10 min) Roy Pereira/TimeStep 1635 -- 1640 Smart card/RADIUS support in ISAKMP (5 min) Roy Pereira/TimeStep 1640 -- 1645 IPSec policy modeling (5 min) Roy Pereira/TimeStep 1645 -- 1705 Elliptic Curve Cryptography in IPSec (20 min) Paul Lambert or Bill Anderson/Certicom, Inc. 1705 -- 1725 Secure Multicast Issues (20 min) Ran Canetti/IBM From owner-ipsec Fri Mar 27 20:29:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13960 for ipsec-outgoing; Fri, 27 Mar 1998 20:25:41 -0500 (EST) From: Dan McDonald Message-Id: <199803280138.RAA02845@kebe.eng.sun.com> Subject: AH Last Call complaint: No source route protection in IPv4! To: ipsec@tis.com Date: Fri, 27 Mar 1998 17:38:15 -0800 (PST) Cc: iesg@ietf.org X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! Mohan and I have were going over the latest batches on the IPsec mailing list about AH, and we realized that there is something missing from the current AH draft: IPv4 SOURCE ROUTING IS NOT PROTECTED BY AH IN ITS CURRENT REVISION. Thanks to Steve Bellovin for pointing out that it is not currently included in AH. This is a big mistake (IMHO), because source routes in IPv4 _can_ be predicted with the same reliability that the type 0 routing header in IPv6 can. I think that before the draft be altered to include IPv4 source routing headers (both loose and strict). The replacement text should go in Appendix A1, and it should closely resemble the text for the type 0 IPv6 routing header. And for those who think I'm rabblerousing, I have included the original note from 1995 on this subject, which had no negative followups to it as far as I could tell. BTW, this is from the archives at ftp.ans.net, before IPsec moved to its current home @tis.com. Please note that the thinking at the time was based on deployed implementations of routers. I've looked at our code and BSD, and they both do the predictable thing in their forwarding path. I'd appreciate any verification by major router vendors. See you in LA! Dan ===================== (Cut up to and including here.) ===================== Forwarded message: >From ipsec-request@ans.net Thu Sep 7 16:21:19 1995 Message-Id: <199509071622.AA60862@interlock.ans.net> From: Ran Atkinson Date: Thu, 7 Sep 1995 12:21:19 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: possible AH & IPv4 compromise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Folks, Bill Simpson was in town in late August and unexpectedly telephoned me and then dropped by NRL 30 minutes later for a chat about IPv4 options and AH. This discussion largely consisted of Bill "educating" me about things. It turns out that the way one might read LSRR's specification is not the way it has been implemented in most systems that implement it. It has been implemented so that the addresses recorded are NOT the arriving interfaces of the listed intermediate systems but instead the next-hop after leaving each listed intermediate system. This last isn't predictable in the general case. I can see both interpretations in the text of RFC-791, but what matters is what has been implemented. Similarly, SSRR originally lists the inbound address of each intermediate hop but records the outbound address of each intermediate hop (at least in real world implementations). Again, this makes SSRR unpredictable in the general case. RFC-791 does appear to say this upon re-reading, but it is too subtly worded for my taste. This leaves only IPSO/BSO, IPSO/ESO, SATID, NOP and EOL as the only really invariant options. Of these, EOL and NOP don't impact security. The software that Bill has mentioned that did reorder IPv4 options is now ancient and has long been superceded by software releases that do not reorder IPv4 options. None of the major router vendors (by market share) ever used the particular implementation that Bill cited. I believe that implementations that reorder IP options are broken (ignoring security, it is a PAINFUL performance hit) and should be ignored in our mulling things over. Bill, Craig, and I think we have a compromise position on IPv4 AH processing. At least one router vendor that Bill talks with has also agreed that this is reasonable. I am altering the freely distributable NRL implementation to reflect this compromise. The compromise goes like this: Included in AH computation: IP Version IP Header Length Total Length Ident Protocol Source Address Destination Address IPSO/BSO IPSO/ESO CIPSO (Option # available from Assigned Numbers, Option Length should be in the usual place) SATNET ID Zeroed for AH computation: TOS (enough real world routers munge this one that it ought to be excluded even though router munging of this sort really is evil) Frag Offset Flags Field TTL IP-layer Checksum All existing documented IP options other than IPSO/*, CIPSO, and SATNET ID Ran rja@cs.nrl.navy.mil On behalf of Bill, Craig, and Ran... From owner-ipsec Sat Mar 28 12:29:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18938 for ipsec-outgoing; Sat, 28 Mar 1998 12:19:51 -0500 (EST) Message-Id: <199803281732.MAA04193@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: AH Last Call complaint: No source route protection in IPv4! In-reply-to: Your message of "Fri, 27 Mar 1998 17:38:15 PST." <199803280138.RAA02845@kebe.eng.sun.com> Date: Sat, 28 Mar 1998 12:32:16 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: Dan> Hello! Dan> Mohan and I have were going over the latest batches on the IPsec Dan> mailing list about AH, and we realized that there is something Dan> missing from the current AH draft: Dan> IPv4 SOURCE ROUTING IS NOT PROTECTED BY AH IN ITS CURRENT REVISION. Dan> Thanks to Steve Bellovin for pointing out that it is not currently Dan> included in AH. This is a big mistake (IMHO), because source routes Dan> in IPv4 _can_ be predicted with the same reliability that the type 0 Dan> routing header in IPv6 can. It was originally protected in the RFC transforms. We realized a snag when implementing it, which was brought up at the Detroit interop, and I think later caused it to be removed again from the drafts. Dan> followups to it as far as I could tell. BTW, this is from the Dan> archives at ftp.ans.net, before IPsec moved to its current home Dan> @tis.com. Thank you for the pointer. I am adding this to http://www.sandelman.ottawa.on.ca/ipsec in MHonArc format. Dan> Please note that the thinking at the time was based on deployed Dan> implementations of routers. I've looked at our code and BSD, and Dan> they both do the predictable thing in their forwarding path. I'd Dan> appreciate any verification by major router vendors. My reading of BSD code says that Ran's note is correct. What is your notion? Ran> It turns out that the way one might read LSRR's specification is not Ran> the way it has been implemented in most systems that implement it. * Ran> It has been implemented so that the addresses recorded are NOT the * Ran> arriving interfaces of the listed intermediate systems but instead * Ran> the next-hop after leaving each listed intermediate system. This * Ran> last isn't predictable in the general case. I can see both Ran> interpretations in the text of RFC-791, but what matters is what has Ran> been implemented. Ran> Similarly, SSRR originally lists the inbound address of each Ran> intermediate hop but records the outbound address of each Ran> intermediate hop (at least in real world implementations). Again, Ran> this makes SSRR unpredictable in the general case. RFC-791 does Ran> appear to say this upon re-reading, but it is too subtly worded for Ran> my taste. ... Ran> Bill, Craig, and I think we have a compromise position on IPv4 AH Ran> processing. At least one router vendor that Bill talks with has Ran> also agreed that this is reasonable. I am altering the freely Ran> distributable NRL implementation to reflect this compromise. This suggests that we can now do AH over source routing? :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNR00HtiXVu0RiA21AQFZLwMAjd3TU4FsvdO7560qLLz5ljJEeJrG0JJ/ 3b35D1ENpmn7mgbpIunvCJM1prBE3Cvf/Fth6Df0hp+xy7AMsqA8ubKQijlRn+D0 QjTClYxCackMG5a9O+9FcNTMWRE+BnB+ =KAUq -----END PGP SIGNATURE----- From owner-ipsec Sat Mar 28 16:06:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20097 for ipsec-outgoing; Sat, 28 Mar 1998 16:01:44 -0500 (EST) Date: Sat, 28 Mar 1998 16:16:00 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199803282116.QAA27354@mimosa.com> To: ipsec@tis.com Subject: ISAKMP SPI Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-isakmp-09.txt section 2.4 "Identifying Security Associations" says: During phase 1 negotiations, the initiator and responder cookies deter- mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie. This seems like a useless option. Surely things would be simpler if we just require the SPI field to be 0. Otherwise, each implementation has to optionally accept this content-free field, and, if diligent, check it for correctness. Does this serve any purpose? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Sat Mar 28 22:26:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22065 for ipsec-outgoing; Sat, 28 Mar 1998 22:21:48 -0500 (EST) Date: Sat, 28 Mar 1998 22:34:40 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199803290334.WAA29357@earth.hpc.org> To: plambert@certicom.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199803210201.TAA13609@baskerville.CS.Arizona.EDU> Subject: Re: is manual keying mandatory (fwd) Sender: owner-ipsec@ex.tis.com Precedence: bulk > >>From a practical standpoint, Diffie-Hellman is > >extremely expensive in lessor-powered CPU's > This is good reason retain and fix the elliptic curve options in Oakley. > It's much faster and a better system solution than manual keys. > Paul Can't be faster than pre-distributed manual keys, of course. And the conservative "fix" Certicom recommends will slow down EC's quite a bit. Hilarie From owner-ipsec Sun Mar 29 00:15:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA22581 for ipsec-outgoing; Sun, 29 Mar 1998 00:10:49 -0500 (EST) Message-Id: <3.0.5.32.19980327090644.009718e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 09:06:44 -0800 To: Peter Ford , "'iesg@ns.ietf.org'" From: Robert Moskowitz Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com In-Reply-To: <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:04 PM 3/26/98 -0800, Peter Ford wrote: Peter, thank you for your comments. >comment 1) Many people who are in the middle of implementing IPSEC AH are >discovering the ugliness of this thing. Many are wondering in the privacy of >their own development shops why we don't simply eliminate this AH thing and >build the equivalent functionality into a set of ESP transforms. This >would result in a cleaner set of implementations and probably smaller, >cheaper, better silicon and code. In my own casual survey I have yet to run >into anyone who feels strongly about keeping and/or using AH. This is an interesting item. The workgroup has gone back and forth on it. There are some that feel that the functionality of AH, authenticating the IP header is very valuable, others that feel it brings too little value and is a protocol violation. So in the end, we have two was to only authenticate. BTW, this does present a marketing problem where use of ESP does not assure privacy (see ID on NULL-ESP ;). There is one strong argument for AH: It is a smaller header than ESP with NULL-ESP and some slow connections will value that. This might also be valuable for embedded systems, like assembly line robotics that only need packet authentication (you don't want just anyone programming those things), but you don't need privacy (ladder logic is rarely proprietary). Another strong argument for AH was export. The assumption is that AH will always be exportable. Getting an export license for an ESP implementation that only does NULL-ESP might be a little hard. It might be interesting to have discussions at Chicago if AH should remain a MUST, but we need some field experience for that decision. >comment 3) Calling something "The Internet Key Exchange" seems a little out >of place given the wild mileau of Key exchanges floating around in IETF >working groups, let alone on the Internet at large. You mean you don't like IKE :) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Sun Mar 29 00:15:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA22582 for ipsec-outgoing; Sun, 29 Mar 1998 00:10:49 -0500 (EST) Message-Id: <3.0.5.32.19980327091636.009729c0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 09:16:36 -0800 To: Phil Karn , pkoning@xedia.com From: Robert Moskowitz Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-Reply-To: <199803270700.XAA21670@servo.qualcomm.com> References: <9803262307.AA01547@kona.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:00 PM 3/26/98 -0800, Phil Karn wrote: >>By creating an *option* of supplying port information to the >>classifier, it allows a user to give up a small amount of security and >>gain the benefit of being classified into a different traffic category >>that has different (presumably better) service. I believe this is a >>valuable option. > >Other, far better-layered mechanisms already exist to categorize >traffic with various levels of service. The TOS field in the IP header >is the prime example. Also, policy routing based on IP source and >destination addresses is also possible. There is serious discussion to use TOS for DIFSRV, IPsec systems could set TOS for this based on a DIFSRV BCP. >IPSEC was originally designed to protect hosts on small private >networks from the big bad public network. But it's also possible to >use it to protect (parts of) the public network itself from all those >hosts on private networks. It's really a very flexible protocol. >It just takes a little imagination and creativity in using it. Phil, I only viewed this as a deployment issue. It will be on all hosts in time (thank you Peter...). I evaluated a pre-IPsec product for our Payroll system. The only reason it was not done was that the systems were Win 3.1 with Novell's IP stack on ODI. This gave the client a little too much instablity. We are on the hook to still secure that, now that the users are all on Win95. We also did an auth only implementation between some plant robotics and the production engineers, this allowed us to eliminate the Allen-Bradley DataHighway stuff. As my ex-colleagues move forward on their boarder-level rollouts, they are already chomping at the bit for end-to-end IPsec, at least auth only. the reason is IPsec in gateway mode has to trust the hosts' IP addresses, but idea when you don't control the client's network. Oh, I should mention that my interest from day 1 was not intra-corporate VPNs, but rather inter-corporate VPNs. these are much more needed.... The number of industries that are talking to me about how they can leverage IPsec for this use further validates my view of the use of IPsec. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Sun Mar 29 00:15:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA22608 for ipsec-outgoing; Sun, 29 Mar 1998 00:11:45 -0500 (EST) Message-Id: <3.0.5.32.19980327091834.00971bd0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 09:18:34 -0800 To: Phil Karn , jgc@optimal.com From: Robert Moskowitz Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: pkoning@xedia.com, iesg@ns.ietf.org, minshall@fiberlane.com, ipsec@tis.com, ietf@ns.ietf.org, karn@qualcomm.com In-Reply-To: <199803270710.XAA21783@servo.qualcomm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:10 PM 3/26/98 -0800, Phil Karn wrote: > >In such "tunnel" configurations, the packets are still available in >plaintext within the private networks, where they can be monitored and >debugged by the operators of those networks. Similarly, any >information needed by the subnet's internal and border routers for >traffic classification is still available. Only the external, public >part of the path is encrypted. Many of my network security colleagues look at this as a short-term interim item. End-to-end is where we want to go. This makes some interesting challenges for addressing (I got to see what the NAT people are going to say about IPsec...). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Sun Mar 29 01:05:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA22880 for ipsec-outgoing; Sun, 29 Mar 1998 01:00:43 -0500 (EST) Message-Id: <3.0.3.32.19980328215511.00986b80@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 28 Mar 1998 21:55:11 -0800 To: Peter Ford , "'Steve Bellovin'" , "'Dan McDonald'" From: Alex Alten Subject: RE: Last Call: Security Architecture for the Internet Protocol to Cc: "'baiju.v.patel@intel.com'" , "'iesg@ns.ietf.org'" , "'ipsec@tis.com'" In-Reply-To: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:28 PM 3/27/98 -0800, Peter Ford wrote: > >Steve, > >>All that notwithstanding, this is not a new issue. We've been over >> this ground before in the working group. Several of us, myself >> included, suggested deleting AH. We lost. Fine; so be it. Let's ship >> the documents and be done with it. > >No, saying that it is fine is not okay given that there is now an order more >experience in building these implementations and from my own personal >polling the utility of some of this stuff is questionable (I am picking on >AH as a tanglible large item to jettison from this ark). No one is stopped >from building and shipping product; the documents should be right, not >expedient. > As you know I posted a list of my key objections to IPSEC. It is interesting to see how other's like Greg Minshall and yourself are finding problems very similiar to some of the ones I noted. However at this point I will back Steve Bellovin on saying let's ship it. One of the great things about the IETF standards process is that a new protocol must prove itself out in the cold, cruel world. If this is a good design, then it will do well. It not, then we will all probably know it within two years. After having participated somewhat in one of the three attempts at SNMP security, I suspect that we might have a ways to go yet with designing and implementing IP security. As an analogy, even the US Constitution of 1787 (ratified in 1788) was the final product of a prior failed attempt, the Articles of Confederation of 1777 (ratified in 1781), and as the result of experience with several state constitutions, in particular the New York Constitution of 1777. - Alex P.S. Thank you Phil Karn for your succinct explanation of the underlying original design objectives of IPSEC. This explains the strong bias for host-to-host security. -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sun Mar 29 02:37:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA23425 for ipsec-outgoing; Sun, 29 Mar 1998 02:33:44 -0500 (EST) Message-Id: <3.0.3.32.19980328232738.009148b0@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 28 Mar 1998 23:27:38 -0800 To: Robert Moskowitz , Peter Ford , "'iesg@ns.ietf.org'" From: Alex Alten Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com In-Reply-To: <3.0.5.32.19980327090644.009718e0@homebase.htt-consult.com> References: <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:06 AM 3/27/98 -0800, Robert Moskowitz wrote: >At 09:04 PM 3/26/98 -0800, Peter Ford wrote: > > >Another strong argument for AH was export. The assumption is that AH will >always be exportable. Getting an export license for an ESP implementation >that only does NULL-ESP might be a little hard. > Yes, I imagine it will be quite hard without some sort of key escrow. This in my opinion will seriously hobble IPSEC's deployment. I'm not kidding about this. The US Commerce department will not back down on this. The reason is because they have already approved some unrestricted key length export licenses for world wide shipment (except the forbidden 5). Some, like TIS's RecoverKey(tm), use 3rd party key escrow. This puts them in a very strong position for the foreseeable future. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sun Mar 29 09:23:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25352 for ipsec-outgoing; Sun, 29 Mar 1998 09:18:44 -0500 (EST) Message-ID: <351E59A8.C2A1A9CC@ire-ma.com> Date: Sun, 29 Mar 1998 09:24:41 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Robert Moskowitz CC: Peter Ford , "'iesg@ns.ietf.org'" , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: <3.0.5.32.19980327090644.009718e0@homebase.htt-consult.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz wrote: > Another strong argument for AH was export. The assumption is that AH will > always be exportable. Getting an export license for an ESP implementation > that only does NULL-ESP might be a little hard. Neither AH nor NULL-ESP provide data confidentiality - why is the former protocol less difficult to export than the latter? > It might be interesting to have discussions at Chicago if AH should remain > a MUST, but we need some field experience for that decision. Question: if AH becomes non-MUST - does it mean that SA Bundles (both Transport Adjacency and Iterative Tunneling) will also become non-MUST? This will result in significant simplification of IPsec complient implementations. Slava Kavsan IRE From owner-ipsec Sun Mar 29 14:22:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26994 for ipsec-outgoing; Sun, 29 Mar 1998 14:14:55 -0500 (EST) Date: Sun, 29 Mar 98 19:10:04 GMT Daylight Time From: Ran Atkinson Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <351E59A8.C2A1A9CC@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Sun, 29 Mar 1998 09:24:41 -0500 Bronislav Kavsan wrote: > Neither AH nor NULL-ESP provide data confidentiality - why is the former protocol > less difficult to export than the latter? Because AH has no specified mode where it is capable of providing confidentiality. In practice, it is easier to make the case for export of AH than for any form of ESP. One could argue that the clue level of bureaucrats in various parts of various governments (hint: this isn't a US-only issue) is too low. However, I'll also note that the provided security properties of AH are different than the provided security properties of ESP with NULL encryption -- this difference is particularly large in the IPv6 world where optional headers were designed with security in mind. Its fascinating to watch how IPv4-only the discussions about AH have been over the past several months. At one time, people speculated that ESP/AH would only be implemented for IPv6 in practice. > > It might be interesting to have discussions at Chicago if AH should remain > > a MUST, but we need some field experience for that decision. > > Question: if AH becomes non-MUST - does it mean that SA Bundles (both Transport > Adjacency and Iterative Tunneling) will also become non-MUST? This will result in > significant simplification of IPsec complient implementations. Note that for IPv4, both ESP and AH are optional -- no one has to implement either AH or ESP or ISAKMP/IKE. For IPv6, the IETF community made a decision after much acrimony that IPsec security was must implement. AH provides security for optional IPv6 headers that ESP with NULL encryption cannot provide. Ran rja@inet.org From owner-ipsec Sun Mar 29 17:58:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28046 for ipsec-outgoing; Sun, 29 Mar 1998 17:53:47 -0500 (EST) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D4D@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'Alex Alten'" , "'Robert Moskowitz'" , "'iesg@ns.ietf.org'" Cc: "'ipsec@tis.com'" Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Sun, 29 Mar 1998 15:07:03 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk We could be confusing functionality with mechanism. I am in full support of providing authentication functionality for IP packets. In my initial note (that was probably written in too great of haste) I hypothesize that AH is not a great way to implement this functionality (misplacement of the ICV is at the top of my hit list) and given that we have ESP we can get authentication functionality through an appropriate ESP. To cover the export issue we can have transforms that do NULL encryption (here he goes again lighting another fuse ...) and simply provide authenticity/identity, integrity and anti-replay in an ESP. If we need to cover headers we can discuss if this is done by changing the way ESP is defined (e.g. an ESP that covers headers) or via encapsulation and subsequent ESP. My sense of history is that the old AH vs ESP design came from the desire to cut and paste security functionality as in getting the full power set of authentication and encryption. Mr. Bellovin did an admirable job of documenting that cut and paste in design can result in cut and paste in attack. We have fixed some of this in ESP; why not go the entire length? (I will admit now that I get on/off the IPSEC mailing list based on its monsoonal behaviours and have not read EVERY posting on the IPSEC list). We certainly do not want a coupling of the form "policy to mechanism" as in AH is good for export, ESP is bad for export, especially from an export or use/filtering perspective. with regards, peter > -----Original Message----- > From: Alex Alten [SMTP:Andrade@ix.netcom.com] > Sent: Saturday, March 28, 1998 11:28 PM > To: Robert Moskowitz; Peter Ford; 'iesg@ns.ietf.org' > Cc: ipsec@tis.com > Subject: RE: Last Call: Security Architecture for the Internet > Protocol to Proposed Standard > > At 09:06 AM 3/27/98 -0800, Robert Moskowitz wrote: > >At 09:04 PM 3/26/98 -0800, Peter Ford wrote: > > > > > >Another strong argument for AH was export. The assumption is that AH > will > >always be exportable. Getting an export license for an ESP > implementation > >that only does NULL-ESP might be a little hard. > > > > Yes, I imagine it will be quite hard without some sort of key escrow. > This in my opinion will seriously hobble IPSEC's deployment. I'm not > kidding about this. The US Commerce department will not back down on > this. > The reason is because they have already approved some unrestricted key > length export licenses for world wide shipment (except the forbidden 5). > Some, like TIS's RecoverKey(tm), use 3rd party key escrow. This puts them > > in a very strong position for the foreseeable future. > > - Alex > > -- > Alex Alten > Andrade@Netcom.Com > P.O. Box 11406 > Pleasanton, CA 94588 USA > (510) 417-0159 From owner-ipsec Sun Mar 29 19:04:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28366 for ipsec-outgoing; Sun, 29 Mar 1998 19:01:50 -0500 (EST) From: John Ioannidis Date: Sun, 29 Mar 1998 19:13:27 -0500 (EST) Message-Id: <199803300013.TAA24780@bual.research.att.com> To: Andrade@ix.netcom.com, iesg@ns.ietf.org, peterf@microsoft.com, rgm-sec@htt-consult.com Cc: ipsec@tis.com Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk The IPSEC group has been in existence for six years now (counting from the lunch BOF at the '92 San Diego IETF). All the issues we're discussing in this round of exchanges have already been beaten to death several times over. IPSEC is as good as it is going to get; we can't be all things to all people, but we are definitely enough things to most people! Let's leave it at that, push the protocol further into the standards track, and move on. We can certainly put our time to more productive use than arguing over which bits go where. /ji From owner-ipsec Sun Mar 29 21:53:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA29298 for ipsec-outgoing; Sun, 29 Mar 1998 21:50:45 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <8D8EF175E72CD111805800805F3198EE03925D3F@red-msg-46.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Mar 1998 21:54:52 -0500 To: Peter Ford From: Stephen Kent Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter, >comment 1) Many people who are in the middle of implementing IPSEC AH are >discovering the ugliness of this thing. Many are wondering in the privacy of >their own development shops why we don't simply eliminate this AH thing and >build the equivalent functionality into a set of ESP transforms. This >would result in a cleaner set of implementations and probably smaller, >cheaper, better silicon and code. In my own casual survey I have yet to run >into anyone who feels strongly about keeping and/or using AH. Yes, AH is ugly, but one cannot achieve the same effects via ESP, even now that we have an authentication-only mode of ESP. If one requires integrity and authenticity for portions of the IP header, and one wants to do this without tunneling, then AH is the protocol of choice. As others have noted, there have been vocal supporters for AH in the past, hence its continued existence and its status as a required part of IPsec. >Our experience at Microsoft working with hardware folks (chip, cards, >motherboards, smartcards, etc.) who are working on IPSEC is that they >would like to worry about one form of encapsulation, and they would like to >put the AH ICV at the end of the packet ala IPSEC ESP. A pure encapsulation approach would be nicer, in many respects. I'd have to defer to Ran on why that approach was not considered viable. >COMMENT 2) It is not clear if one would call it a protocol bug or not, but >as currently spec'd it is possible for two peers to get into the following >state: > >a) SAs established based on data flow triggering from A to B, A is the >initiator (e.g. policy on A: do IPSEC for traffic to peer B) >b) A crashes >c) B holds an SA and believes the other side (A) is still able to undo >IPSEC traffic on the SA that was wiped out on the reboot of A. All IPSEC'd >traffic from B to A is unusable and nothing drives the establishment of new >SAs btw A and B since A has no traffic destined for B and B already has what >it thinks are valid SAs to A. > >there are several proposals for peer recovery floating around, but without >it the spec seems incomplete. Yes, this can happen, in the case of a unidirectional data flow. IPsec has avoided triggering SA establishment based on receipt of unsolicited traffic, to minimize denial of service attacks, so the obvious solution is not one that the WG wishes to pursue. More sophisitcated approaches are being explored, as you note. Is the spec incomplete? Yes, in this respect, and we also don't support broadcast in a scaleable fashion, and there are several other features we would like to have now but the WG has elected to postpone these for the next pass on the protocols. >comment 3) Calling something "The Internet Key Exchange" seems a little out >of place given the wild mileau of Key exchanges floating around in IETF >working groups, let alone on the Internet at large. It could be renamed, but a strong Republication faction will be disappointed :-)! > >If AH moves to PS, customers will expect it to be part of ALL >implementations. This is the time to simplify IPSEC. Customers should expect Ah in all implementations; it's an integral part of the current standard. If we let folks pick and choose only those parts that they feel are relevant to them, their products, their market, then we will limit interoperability. That's not consistent with the general IETF standards approach. Steve From owner-ipsec Sun Mar 29 23:29:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29741 for ipsec-outgoing; Sun, 29 Mar 1998 23:24:45 -0500 (EST) Message-ID: <351F21C4.446B@cs.umass.edu> Date: Sun, 29 Mar 1998 23:38:28 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: pau@watson.ibm.com Subject: Re: new IKE draft References: <9803161550.AA26962@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen wrote on 16 Mar 1998: > Actually, for stronger securuty, I think the input to > RSA encryption should not be longer than 2/3 of the size of the modulus. Coppersmith's attack from Eurocrypt `96 imposes this security condition when the public exponent is e=3. As his paper notes, there are security tradeoffs between the amount (and location) of padding and the size of the public exponent. For some realistic modulus and public exponent sizes (e.g. e=3, |N| = 1024 bits), the minimum 64 bits of PKCS #1 padding isn't enough to prevent an attack when the adversary knows a good chunk of the plaintext. This means trouble for the encryption of long identities in the original PK Encryption Mode of authentication when the peer's public key has a very small e, and the adversary has a manageable set of identity guesses to check. One way to patch this hole would be to increase the minimum padding length. This would mean IKE would no longer be doing vanilla PKCS #1 encryption block formatting. An alternative is to impose a minimum size for the public exponent in RSA keys used with the original Encryption mode. The adversary's task is easiest when the ID payload is the longest allowed by PKCS #1 (i.e. k-11 octets in length) and the adversary knows all but a single bit of the ID payload. Thus only 65 bits of the input to encryption are unknown to the adversary. Conservatively the public exponent e should satisfy 65 >= n^(1/e), where n is the modulus. (This errs on the side of safety, since the padding and payload aren't contiguous in PKCS #1, and the padding isn't the most significant block of bits in the plaintext. But I think this is not too far off the mark.) For example, for n approximately 2^1024, the requirement would be e > 170. I mildly prefer the latter option. What does the WG think? I don't believe these attacks pose a threat to the encryption of nonces in the original and Revised PK Encryption Modes of authentication. Since the nonces are randomly generated, the adversary won't start with any partial information on the nonces. So there's no realistic foothold for a stereotyped message attack. Because the nonces are random and sufficiently large, the adversary essentially has no hope of finding groups of ciphertext susceptible to related message attacks. -- Lewis http://www.cs.umass.edu/~lmccarth/ From owner-ipsec Mon Mar 30 01:43:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA00513 for ipsec-outgoing; Mon, 30 Mar 1998 01:39:49 -0500 (EST) Message-Id: <3.0.5.32.19980328224247.009b8120@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 28 Mar 1998 22:42:47 -0800 To: "Scott G. Kelly" , Peter Ford , ipsec@tis.com From: Robert Moskowitz Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <351C2432.CF89D5E3@redcreek.com> References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:12 PM 3/27/98 -0800, Scott G. Kelly wrote: > >I think what you mean to say is that if the bulk of us mind our own >business the powerful process of microsoft will take over and yet >another IETF standard will be ignored by microsoft. this comment is inappropriate on this list. BTW, there are other vendors that make comments about this and other parts of the spec. We are going out to Proposed Standard with the MUSTs, and SHOULDs, and MAYs as they are. Field experience over the next fe months MAY result in some changes as we prepare for Draft Standard. And IMHBO, only this discussion on AH is a candidate for such a change. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Mar 30 07:27:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02882 for ipsec-outgoing; Mon, 30 Mar 1998 07:22:45 -0500 (EST) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Fri, 27 Mar 1998 23:44:22 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: "Theodore Y. Ts'o" cc: Roy Pereira , IPSEC Mailing List Subject: Re: updated draft-ietf-ipsec-ciph-cbc-03.txt In-Reply-To: <199803272011.PAA00945@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 27 Mar 1998, Theodore Y. Ts'o wrote: > Correct spelling: [Bosselaers]. Probably we should contact and notice him > before using his website as a link in the draft. The numbers on his homepage > are from an yet unpublished paper. He himself or Bart can give the exact > reference. > > Given how ephemeral web pages can be, I'd be very hesitate citing a web > pages as a reference. Actually this was my point: we should ask for the exact reference of the paper, where these citations are from. Currently, it's: @unpublished{BoPrRi98, author = {Bart Preneel and Vincent Rijmen and Antoon Bosselaers}, title = {{Recent developments in the design of conventional algorithms}}, year = 1998, note = {Unpublished} } Bart etc should know better which reference they would prefer (on the other hand, WWW would be more dynamic hopefully). Helger From owner-ipsec Mon Mar 30 07:34:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03265 for ipsec-outgoing; Mon, 30 Mar 1998 07:33:45 -0500 (EST) Message-Id: <3.0.5.32.19980327095130.00a0a160@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 09:51:30 -0800 To: JGC , Paul Koning , iesg@ns.ietf.org, minshall@fiberlane.com From: Robert Moskowitz Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com, ietf@ns.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:45 PM 3/26/98 -0800, JGC wrote: >The issue that Greg brings up is very important. My company relies on >port information heavily for analysis of protocols and applications and >if this information is obscured it becomes difficult to accurately >report on the different applications that are running. > For this note, I am taking my co-chair hat off, and dusting off my now old user hat (that Stetson was getting a little worn out ;). >From as far back as Danvers IETF (yo Jim ;) we warned what IPsec would mean to the Internet and called on other groups to start designing for IPsec deployment. Other than the beginnings from DIFSRV, there has been no interaction. In fact we recently had to call a special get together of IPsec and CA developers to work out interoperablity between 2 security components! FOlks, the community has spent FIVE YEARS working on IPsec (from the first swIPe work). You all knew this was coming. It is needed even if you have above-transport security (TLS, SSH). Once the APIs (PF_KEY, CDSA, etc) link into IPsec, we amy see it as the predominate security methodlogy in Intranets and Inter-company traffic. It is time for the other IETF areas that IPsec will impact to get ready to work with IPsec, not agan it. It is almost as if some people were expecting IPsec to fail so they ignored it.... :( From owner-ipsec Mon Mar 30 11:16:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05551 for ipsec-outgoing; Mon, 30 Mar 1998 11:14:50 -0500 (EST) Message-ID: <33ECD307.BB2A1EE3@redcreek.com> Date: Sat, 09 Aug 1997 20:28:55 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Last Call: Security Architecture for the Internet Protocolto] Content-Type: multipart/mixed; boundary="------------10FB227FF16E49E7A062399B" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------10FB227FF16E49E7A062399B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------10FB227FF16E49E7A062399B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <33ECD1DD.D567E26A@redcreek.com> Date: Sat, 09 Aug 1997 20:23:57 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Moskowitz Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> <3.0.5.32.19980328224247.009b8120@homebase.htt-consult.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Moskowitz wrote: > At 02:12 PM 3/27/98 -0800, Scott G. Kelly wrote: > > > >I think what you mean to say is that if the bulk of us mind our own > >business the powerful process of microsoft will take over and yet > >another IETF standard will be ignored by microsoft. > > this comment is inappropriate on this list. BTW, there are other vendors > that make comments about this and other parts of the spec. I agree, and apologize. It was nearing the end of a frustrating afternoon, and I fired that off without due thought. Scott --------------10FB227FF16E49E7A062399B-- From owner-ipsec Mon Mar 30 12:52:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06289 for ipsec-outgoing; Mon, 30 Mar 1998 12:48:54 -0500 (EST) Message-ID: <33ECE90D.C06D59A5@redcreek.com> Date: Sat, 09 Aug 1997 22:02:53 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Last Call: Security Architecture for the Internet Protocol to] Content-Type: multipart/mixed; boundary="------------CB411209942317E45A4DEDDE" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------CB411209942317E45A4DEDDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------CB411209942317E45A4DEDDE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <33ECD546.65FFE4C8@redcreek.com> Date: Sat, 09 Aug 1997 20:38:30 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Paul Koning Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> <351C2432.CF89D5E3@redcreek.com> <9803301353.AA10616@kona.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Koning wrote: > Scott> The amount of MUSTs in the current spec are necessary if you > Scott> want your network to be SSSSEEEECCCCUUURRRREEE. > > Do you really believe that? If so, I'm worried. > > In fact, a big security spec is less likely to be secure than a small > one, given that the number of bugs increases with size (often more > than linearly). > I've apologized elsewhere for the tone of my post. My underlying motivation for the comments above is partly that this 'spec' has been worked on by some of the world's foremost security people, and I am confident that most of the unnecessary junk has already been cut from the design. I am not a security expert (yet), so I may be incorrect. However, viewing many of the names on this list in the appropriate historical perspective lends credence to the notion that, for the most part, this protocol suite has been very well thought out. As mentioned in related posts, time will tell. --------------CB411209942317E45A4DEDDE-- From owner-ipsec Mon Mar 30 12:57:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06351 for ipsec-outgoing; Mon, 30 Mar 1998 12:56:55 -0500 (EST) Message-ID: <33ECEAE0.99EA3579@redcreek.com> Date: Sat, 09 Aug 1997 22:10:40 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> <351C2432.CF89D5E3@redcreek.com> <9803301353.AA10616@kona.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm following up to add some perspective to my earlier posts on the complaints that the spec is bloated with unnecessary MUSTS, etc, From owner-ipsec Mon Mar 30 13:05:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA06443 for ipsec-outgoing; Mon, 30 Mar 1998 13:04:56 -0500 (EST) Message-ID: <33ECECA7.BF00EEAB@redcreek.com> Date: Sat, 09 Aug 1997 22:18:15 +0000 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Paul Koning CC: ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <8D8EF175E72CD111805800805F3198EE03925D4B@red-msg-46.dns.microsoft.com> <351C2432.CF89D5E3@redcreek.com> <9803301353.AA10616@kona.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry about the last incomplete post - new laptop, no mouse, etc. I'm following up to add some perspective to my earlier posts on the complaints that the spec is bloated with unnecessary MUSTS, etc. Having personally implemented prototypes based upon the last few rounds of drafts, I can state the following authoritatively: while it may be difficult to implement all the MUSTS, it is not impossible. Further, at least for the ones I've thought carefully about, there is a sound technical basis for them. If you search the archives, you will find the arguments upon which they are based. If you can find specific MUST's which have not been discussed to consensus, these are valid targets. Otherwise, we should be moving these drafts forward, rather than rehashing old issues. From owner-ipsec Mon Mar 30 13:31:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA06677 for ipsec-outgoing; Mon, 30 Mar 1998 13:30:54 -0500 (EST) Message-Id: <199803301844.NAA11774@istari.sandelman.ottawa.on.ca> To: "Scott G. Kelly" CC: ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-reply-to: Your message of "Sat, 09 Aug 1997 22:18:15 -0000." <33ECECA7.BF00EEAB@redcreek.com> Date: Mon, 30 Mar 1998 13:44:15 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> least for the ones I've thought carefully about, there is a sound Scott> technical basis for them. If you search the archives, you will find the Scott> arguments upon which they are based. If you can find specific MUST's which Scott> have not been discussed to consensus, these are valid targets. Otherwise, I wonder if a list of MUSTs, and URLs pointing to archives would be a useful thing. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Mon Mar 30 14:55:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07329 for ipsec-outgoing; Mon, 30 Mar 1998 14:47:54 -0500 (EST) Message-ID: <351FF8A0.71D75429@ire-ma.com> Date: Mon, 30 Mar 1998 14:55:12 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: IKE SA Lifetime question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Could someone point me to a draft-standard discussing IKE SA (Phase 1 SA) Lifetime (as opposed to Phase 2 SA Lifetime)? Is there such "thing"? Is is negotiable? Is it a Local Policy matter? How is the Kbytes-based life type used to calculate traffic volume? etc, etc. Thank you, -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 30 15:08:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07497 for ipsec-outgoing; Mon, 30 Mar 1998 15:04:55 -0500 (EST) Message-ID: <351FFCD6.3DE33CF3@ire-ma.com> Date: Mon, 30 Mar 1998 15:13:11 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: "Scott G. Kelly" , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: <199803301844.NAA11774@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > I wonder if a list of MUSTs, and URLs pointing to archives would be a > useful thing. ABSOLUTELY!!! As well as SHOULDs and MAYs. It would very nice to have a summary of these requirements in some concise form on the Web accompanied by the references to the supporting documents. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Mar 30 17:52:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08651 for ipsec-outgoing; Mon, 30 Mar 1998 17:48:58 -0500 (EST) Message-Id: <199803302302.SAA21125@relay.rv.tis.com> Date: Mon, 30 Mar 98 17:56:12 EST From: Charles Lynn To: Dan McDonald cc: ipsec@tis.com, iesg@ietf.org Subject: Re: AH Last Call complaint: No source route protection in IPv4! Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan, > IPv4 SOURCE ROUTING IS NOT PROTECTED BY AH IN ITS CURRENT REVISION. Yes, that is correct. As Ran pointed out in the message you quoted: > It turns out that the way one might read LSRR's specification is > not the way it has been implemented in most systems that implement > it. It has been implemented so that the addresses recorded are > NOT the arriving interfaces of the listed intermediate systems > but instead the next-hop after leaving each listed intermediate system. > This last isn't predictable in the general case. A better way to phrase "next-hop after leaving each listed intermediate system" would be to say the "IP address of the exit interface of the intermediate system". In the IPv4 loose (or strict) source and record route option, the IP addresses in the source route are "mutable and unpredictable", due to the entry addresses being replaced with the exit addresses (the "and record route" part of the options). The exit address is the address that must be used, in IPv4, in order to be able to cause the return packets to follow the reversed source route. Note that the IP address of the entry interface may not be routable from the network cloud attached to the exit interface and vice versa, e.g., think NAT. In contrast, in the (IPv6) Routing Extension Header, version 0, the addresses listed are "routing domain" or "cluster" addresses, not "interface" addresses. AS the packet traverses the internet, the addresses are moved, but not changed -- "mutable but predictable". However, one has in general given up the ability to specify "routers", and, when IPSec AH is used, the ability to do some forms of address translation. I believe that the statement: > This is a big mistake (IMHO), because source routes in IPv4 _can_ be > predicted with the same reliability that the type 0 routing header in IPv6 > can. is not correct. To do so would require the end systems to second guess how the internet routing system is going to route packets -- something that will be even harder to do when QOS routing becomes more common. Thus the statement: > which had no negative followups is consistent with the statement that the addresses in a IPv4 source and record route option are mutable and not predictable. In general, IPSec AH cannot be used (for either IPv4 or the version 0 Routing Extension Header) to authenticate that the route taken by an IP datagram is the same as the path recorded in the source route. With IPSec AH, one is only assured, in the case of the version 0 Routing Extension Header, that the receiver received what the sender expected the receiver to receive; for IPv4 source routing, one cannot even believe the addresses recorded in the source routing option, since the sender could not, in general, predict them. How much "trust" is one willing to put into the intermediate systems and the routers that interconnect them? The only way that I see to make sure that a packet reached each of the intermediate systems listed in a source route is if one has some sort of shared secret with those systems and they are required to demonstrate that they know that secret, and even then, one has to trust the intermediate systems to keep the secret and do the correct processing. One way to do that is to use the version 0 Routing Extension Header with the IPSec "mode" (transport or tunnel) which is not described in the current IPSec documents; maybe we could call it "Routing Header mode". Routing Header mode places the IPSec extension header(s) [either AH or ESP with authentication] between the IP header and the Routing Extension Header (yes, I'm still talking about an IPv4 header -- as well as IPv6). When placed in that position, there would be a separate SA for each leg of the source route. Note that Routing Header mode has many of the properties of "transport mode": no extra IP header is added, and it is implemented in security gateways. We have plenty of work to do in IPSecond. > I've looked at our code and BSD, and they both do the predictable > thing in their forwarding path. NetBSD inserts the exit interface, as did SunOS (TM) and cisco (TM) routers the last time I tried them. So I guess you mean that in those cases where you know the contents of the routing table in the intermediate systems listed in the IPv4 source and record route option, and how that system will route your particular packet, you can predict what will end up in the option at the receiver. Not a general solution (or something I would want to burden AH with trying to figure out :-). Charlie From owner-ipsec Mon Mar 30 19:06:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09168 for ipsec-outgoing; Mon, 30 Mar 1998 19:03:55 -0500 (EST) Message-Id: <199803310017.TAA12818@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Summary of issues from RTP (second edition) From: "Michael C. Richardson" Date: Mon, 30 Mar 1998 19:17:27 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk I will update this list again on the 27th. I have taken the list, removed the headers, signatures, and reworded some parts. Please let me know if I've screwed up what you are saying.} 1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when offered different sizes. (2 octets was required for the IPcomp people) 2. ISAKMP payloads had to be in the order they are documented in the draft. Most ISAKMP payloads may be sent in any order. The exception is that there is a proscribed relationship between some payloads (i.e. proposal payloads, transform payloads, etc) 3. IP address in CERTs. Some people expected strings, other expected 4 octets in ipAddress. If string, then is it: CN vs Unstructured or subjectAltName. One response: "It is never a string when encoded in subjectAltName." "I believe consensus was that if IP Addresses (or dns name or rfc822) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG." 4. Some implementations are sending a replay protection number of 0 when manually keying. "I was under the impression sequence # 0 should NEVER go on the wire, but hey, what do I know?" 5. (see #14) 6. Some vendors used old isakmp-08 certificate request format, but the data attrbute used in the payload was incorrectly formatted (or missing). {ed note: isakmp-09 was not publically available for the interop} 7. Some vendors did not like getting a key hash payload in rsa encryption mode. 8. Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received. Only the single payload should be discarded. 9. Some vendors did not like receiving certificate request payloads when using pre shared keys. (The isakmp draft says certificate requests payloads can exist in any message). 10. Some vendors did not like receiving certificate request payloads at any time. 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4 bytes. Q: Does the spec allow this? A: There was some argument about whether this is REQUIRED. {ed: It would seem to fall into the "be conservative in what you generate and liberal in what you accept" } 12. Some vendors expected to see client ID's in phase 2. This caused quick mode to complete, but fail to install the SA properly. 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies. This caused premature termination of the negotiation. Speculation that some vendors may terminate on any unknown status-level information notifications. 14. Some vendors were not sending both the AH Transform type (e.g. AH_MD5) AND the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the the Transform type and the Authentication Algorithm attribute. To quote a better description: "1) some people were not sending the Auth(HMAC-*) attribute, and yet expecting the resulting transform to be HMAC-*. 2) some people would *reject* an AH transform with an Auth(HMAC) attribute! This is clearly an error!" 15. Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET. {ed: Clearly IP4_ADDR_RANGE of 192.168.34.0 -> 192.168.34.255 is equivalent to IP4_ADDR_SUBNET of 192.168.34.0/24. ed: I'm confused. Where is this defined? Did ISAKMP 09 remove all but ADDR and ADDR_SUBNET???} 16. Some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces. The new IKE document does state: The length of nonce payload MUST be between 8 and 256 bytes inclusive. {ed: I received nothing about any wire level transform level issues. This is probably good.} :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Mon Mar 30 20:20:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09523 for ipsec-outgoing; Mon, 30 Mar 1998 20:17:56 -0500 (EST) Message-Id: <199803310056.TAA04910@thunk.orchard.arlington.ma.us> From: Bill Sommerfeld To: iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Thu, 26 Mar 1998 11:26:26 PST." <199803261926.LAA04909@red.mtv.fiberlane.com> Date: Mon, 30 Mar 1998 19:56:34 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Since often things seem to turn on the volume (or mass) of commentary, I think I'll weigh in here.. A number of folks have argued for adding various layers of "transparency" to the ipsec, for a variety of reasons: 1) management wiretapping. 2) differential handling based on protocol. 3) protocol spoofing for long-latency networks. None of these seem to justify this, and there are alternate means of accomplishing these.. 1) Wiretapping is exactly what this set of protocols was intended to prevent (duh!)... conceivably, facilities for wiretapping traffic (a la RMON), both before encryption and after decryption, could be built into end systems, and enabled only when suitable cryptographic authorization is presented by the management station.. however, I can't imagine situations where I would want to turn that on in production systems.. 2) The proposed mechanism (putting a copy of port numbers outside the crypto) is essentially a "new" mechanism, requiring new handling in routers, and could just as well be replaced by code which sets the appropriate TOS/precedence bits. Also, if fine-grained (e.g., connection-oriented) keying is in use, different flows could be distinguished by the SPI (which, for ESP, is conveniently the same size and in the same place as the port pair..) 3) IMHO, protocol spoofing (e.g., forging TCP acks in the middle of the network) is simply evil.... - Bill From owner-ipsec Tue Mar 31 02:06:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA11611 for ipsec-outgoing; Tue, 31 Mar 1998 02:03:54 -0500 (EST) Message-Id: <199803310715.CAA15246@smb.research.att.com> To: ablair@erols.com cc: Bill Sommerfeld , iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Mon, 30 Mar 1998 23:15:11 -0800 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk My understanding is that the TCP Over Satellite WG is considering the use of spoofing (at least as a research topic). I presume this means that IPSec and spoofing to improve performance on a long latency satellite network are incompatible. Is there any way to maintain security and still do TCP spoofing for satellites (i.e., could you elaborate on the evil)? You're right -- IPsec will not permit window-size spoofing. To understand why, imagine that an enemy were to play games with window sizes -- probably sending small ones, but just large enough to avoid tickling the silly window syndrome code; slamming the window shut (remember that closed windows are probed very infrequently); opening it wide and then slamming it shut (against the spec, but is your stack robust enough to cope?), etc. It's an interesting question how to have both good security and how to play such TCP games. There are other issues between IPsec and ECN; I spoke at that BoF today. From owner-ipsec Tue Mar 31 07:34:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14156 for ipsec-outgoing; Tue, 31 Mar 1998 07:32:56 -0500 (EST) Message-ID: <35207D29.4E146A86@erols.com> Date: Tue, 31 Mar 1998 00:20:41 -0500 From: Alan Blair Reply-To: ablair@erols.com X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Bill Sommerfeld CC: iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: <199803310056.TAA04910@thunk.orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk My understanding is that the TCP Over Satellite WG is considering the use of spoofing (at least as a research topic). I presume this means that IPSec and spoofing to improve performance on a long latency satellite network are incompatible. Is there any way to maintain security and still do TCP spoofing for satellites (i.e., could you elaborate on the evil)? Alan Bill Sommerfeld wrote: > Since often things seem to turn on the volume (or mass) of commentary, > I think I'll weigh in here.. > > A number of folks have argued for adding various layers of > "transparency" to the ipsec, for a variety of reasons: > 1) management wiretapping. > 2) differential handling based on protocol. > 3) protocol spoofing for long-latency networks. > > None of these seem to justify this, and there are alternate means of > accomplishing these.. > > 1) Wiretapping is exactly what this set of protocols was intended to > prevent (duh!)... conceivably, facilities for wiretapping traffic (a > la RMON), both before encryption and after decryption, could be built > into end systems, and enabled only when suitable cryptographic > authorization is presented by the management station.. however, I > can't imagine situations where I would want to turn that on in > production systems.. > > 2) The proposed mechanism (putting a copy of port numbers outside the > crypto) is essentially a "new" mechanism, requiring new handling in > routers, and could just as well be replaced by code which sets the > appropriate TOS/precedence bits. Also, if fine-grained (e.g., > connection-oriented) keying is in use, different flows could be > distinguished by the SPI (which, for ESP, is conveniently the same > size and in the same place as the port pair..) > > 3) IMHO, protocol spoofing (e.g., forging TCP acks in the middle of > the network) is simply evil.... > > - Bill -- The best way to predict the future is to invent it From owner-ipsec Tue Mar 31 18:21:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18494 for ipsec-outgoing; Tue, 31 Mar 1998 18:13:05 -0500 (EST) Message-Id: <199803312216.RAA13945@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com, tcp-over-satellite@achtung.sp.trw.com CC: "Steven M. Bellovin" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-reply-to: Your message of "Mon, 30 Mar 1998 23:15:11 PST." <199803310715.CAA15246@smb.research.att.com> Date: Tue, 31 Mar 1998 17:16:16 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Steven" == Steven M Bellovin writes: Steven> You're right -- IPsec will not permit window-size Steven> spoofing. To understand why, imagine that an enemy were Are there not TCP options that allow the window size to be expanded? I realize that those options are not widely deployed. I will postulate this: - real systems without the expanded window size options probably don't have IPsec either. - VPN gateways already have a machine at each end that could do the window-size spoofing, and in the case of per-host keying, already have almost all the state as well. Seems like a neat value add to me. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [