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(actio