From owner-ipsec Wed Oct 1 07:38:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA01649 for ipsec-outgoing; Wed, 1 Oct 1997 07:37:14 -0400 (EDT) Date: Wed, 1 Oct 1997 13:42:14 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199710011042.NAA09308@ee.technion.ac.il> To: dharkins@cisco.com Subject: Re: change in isakmp/oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > Is the (non)mixing of Ni and Nr in encryption mode authentication broken > or does it just reenforce the brokenness of certain (as yet unnamed) prfs? It may be closer to the latter, but still a MUST to fix. You have no "right" to give future implementations a rope to hung themselves.. We have put a lot of effort to have the protocol as robust as possible. Security is not only resistance to known attacks, but resistance to tomorrow's attacker as well. And the specifications should be complete enough to provide robustness "against" tomorrow's implementers too. Hugo From owner-ipsec Wed Oct 1 13:33:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04270 for ipsec-outgoing; Wed, 1 Oct 1997 13:31:45 -0400 (EDT) Message-Id: <199710011733.KAA17139@dharkins-ss20> To: Hugo Krawczyk From: dharkins@ipsec.com Cc: ipsec@tis.com Subject: Re: change in isakmp/oakley In-Reply-To: Your message of "Wed, 01 Oct 1997 13:42:14 +0300." <199710011042.NAA09308@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 1997 10:33:08 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo, > > Is the (non)mixing of Ni and Nr in encryption mode authentication broken > > or does it just reenforce the brokenness of certain (as yet unnamed) prfs? > > It may be closer to the latter, but still a MUST to fix. > You have no "right" to give future implementations a rope to > hung themselves.. I'm not claiming a right to anything (except to own handguns and assault weapons). In fact, I'm particularly agnostic on the whole issue-- which just might be a first for me :-) But I haven't really seen a groundswell of support or opposition and that's a bit disheartening. Can somebody out there in ipsec-land who gives a damn either way speak up? I'm willing to change the draft if enough people say it's important. I'm also willing to leave it alone and let people negotiate ROT-13 for encryption and the futuristic-key-truncating MAC for authentication (using private use attributes of course-- I wouldn't include them in the draft) if they're that stupid. Speak up now, please. Dan. ---------------------------------------------------------------------------- --- Dan Harkins | E-mail: dharkins@ipsec.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (408) 526-4952 San Jose, CA 95134-1706 | ICBM: 37.45N, 122.03W U.S. of A. | http://www.beer.org/~dharkins ---------------------------------------------------------------------------- --- For your safety and the safety of others: concealed carry, and strong crypto. ---------------------------------------------------------------------------- --- From owner-ipsec Wed Oct 1 13:42:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04359 for ipsec-outgoing; Wed, 1 Oct 1997 13:41:45 -0400 (EDT) Message-Id: <3.0.32.19971001105102.00988840@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 01 Oct 1997 10:51:03 -0700 To: wdm@epoch.ncsc.mil, ipsec@tis.com From: John Burke Subject: Items for ISAKMP draft. Cc: eugenep@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Points for the ISAKMP draft: o Clarify what is legal in an SA response attribute list. I think the belief is abroad, though I can't find it in ISAKMP v-08, that a responder must return exactly the attribute list sent in an accepted Transform without modification. We here would be happiest if it acknowledged that Negotiable attributes can exist, these attributes can be returned with a value permitted by the DOI's specific rules, and success of the SA means the returned value is accepted. There was totally unnecessary fol-de-rol on the list about how you can't reduce Lifetimes, with truly strange alternate suggestions made, due to this not being in the ISAKMP draft. Alternatively this could all be left to the DOI's. Doug: could you communicate directly with Derrell Piper on this point and resolve it between you in the next drafts of ISAKMP and DOI? (Look at the new, gratuitous prescription in DOI v-04 for Notification of Lifetime). o Need definite statement about whether payload order is restricted. The sense of discussion on the list apparently has been that generally one should permit payloads in any order but position of certain payloads should be prescribed: SA, HASH, SIG. I would think the ISAKMP doc should say that for exchanges defined by another document, order restrictions are entirely up to that document, and otherwise order is free; then it should make definite statements about the Exchanges which appear in it: Base Mode, ID-Protect, and Aggressive. Since Oakley uses variations on the prescribed exchanges, the Oakley Resolution document would then need its own clear statements that its restrictions/freedoms are the same as ISAKMP, or stating exceptions. This is the place which currently affects implementors. From owner-ipsec Wed Oct 1 14:07:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04533 for ipsec-outgoing; Wed, 1 Oct 1997 14:06:45 -0400 (EDT) Message-Id: <3.0.32.19971001111738.00993540@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 01 Oct 1997 11:17:38 -0700 To: ipsec@tis.com From: John Burke Subject: Re: change in isakmp/oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk To give the take of an implementor and non-cryptographer on this: It seems appropriate that the draft should indicate the direction for future transforms that may be cut-and-pasted in, to increase the chance it will get done right. Hugo wants, as I understand him, that the draft should tell those who propose additions, that their hashes must assure the Ni|Nr not be truncated. A lot of the points of protocol are piddlies, and people will get them right by convergence pretty quick. The crypto formulas, on the other hand, give too great an opportunity to incorporate non-obvious security holes not discovered except by the legendary adversary who is the reason for our existence (cripes, is that teleological or whut?). I say better we write all we can in warning to those making the likely future additions. Can others please give us further encouragement on this? At 10:33 AM 10/1/97 -0700, dharkins@ipsec.com wrote: > Hugo, > >> > Is the (non)mixing of Ni and Nr in encryption mode authentication broken >> > or does it just reenforce the brokenness of certain (as yet unnamed) prfs? >> >> It may be closer to the latter, but still a MUST to fix. >> You have no "right" to give future implementations a rope to >> hung themselves.. > > I'm not claiming a right to anything (except to own handguns and assault >weapons). In fact, I'm particularly agnostic on the whole issue-- which >just might be a first for me :-) > > But I haven't really seen a groundswell of support or opposition and that's >a bit disheartening. Can somebody out there in ipsec-land who gives a damn >either way speak up? > > I'm willing to change the draft if enough people say it's important. I'm >also willing to leave it alone and let people negotiate ROT-13 for encryption >and the futuristic-key-truncating MAC for authentication (using private use >attributes of course-- I wouldn't include them in the draft) if they're that >stupid. > > Speak up now, please. > > Dan. > >---------------------------------------------------------------------------- >--- >Dan Harkins | E-mail: dharkins@ipsec.com >Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 >170 W. Tasman Drive | fax: +1 (408) 526-4952 >San Jose, CA 95134-1706 | ICBM: 37.45N, 122.03W >U.S. of A. | http://www.beer.org/~dharkins >---------------------------------------------------------------------------- >--- >For your safety and the safety of others: concealed carry, and strong crypto. >---------------------------------------------------------------------------- >--- > > > > From owner-ipsec Wed Oct 1 14:48:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04738 for ipsec-outgoing; Wed, 1 Oct 1997 14:47:15 -0400 (EDT) To: dharkins@ipsec.com Cc: Hugo Krawczyk , ipsec@tis.com Subject: Re: change in isakmp/oakley References: <199710011733.KAA17139@dharkins-ss20> From: EKR Date: 01 Oct 1997 11:58:22 -0700 In-Reply-To: dharkins@ipsec.com's message of Wed, 01 Oct 1997 10:33:08 -0700 Message-Id: <34t71ux81.fsf@kmac.terisa.com> Lines: 30 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ipsec@ex.tis.com Precedence: bulk dharkins@ipsec.com writes: > Hugo, > > > > Is the (non)mixing of Ni and Nr in encryption mode authentication broken > > > or does it just reenforce the brokenness of certain (as yet unnamed) prfs? > > > > It may be closer to the latter, but still a MUST to fix. > > You have no "right" to give future implementations a rope to > > hung themselves.. > > I'm not claiming a right to anything (except to own handguns and assault > weapons). In fact, I'm particularly agnostic on the whole issue-- which > just might be a first for me :-) > > But I haven't really seen a groundswell of support or opposition and that's > a bit disheartening. Can somebody out there in ipsec-land who gives a damn > either way speak up? Seems to me that there are any number of ways for people who want to add new algorithms to go wrong and we can't protect against them all. Why should this one get special treatment? Provided that it's strong with the current algorithm set, I say leave it alone. -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From owner-ipsec Wed Oct 1 15:33:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05037 for ipsec-outgoing; Wed, 1 Oct 1997 15:33:15 -0400 (EDT) Message-ID: <3432A7CE.167E@cs.umass.edu> Date: Wed, 01 Oct 1997 15:43:10 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: Dan Harkins Subject: Re: change in isakmp/oakley References: <199710011733.KAA17139@dharkins-ss20> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > But I haven't really seen a groundswell of support or opposition and > that's a bit disheartening. Can somebody out there in ipsec-land who > gives a damn either way speak up? Perhaps this thread should also visit the isakmp-oakley list? > I'm willing to change the draft if enough people say it's important. > I'm also willing to leave it alone and let people negotiate ROT-13 for > encryption and the futuristic-key-truncating MAC for authentication > (using private use attributes of course-- I wouldn't include them in > the draft) if they're that stupid. For what it may be worth, I'd like to see the draft change, either now or later (see below). Does anyone have code that uses something other than HMAC as the prf? If not, maybe a procedurally useful compromise would be to specify HMAC as a SHOULD for the prf in this version of ISAKMP/Oakley, and in some later v2 add in the machinery to mangle key material into the right sizes for other possible prfs. Among other things, this assumes that (a) keying HMAC with constructions like Ni|Nr is secure [which I think is true] and (b) recommending a particular prf won't muck up backwards compatibility for later versions, even if HMAC becomes broken for this purpose. [I'm not at all sure the latter is a good assumption.] This wouldn't change any code for people already using HMAC exclusively as their prf, and punts on the key-resizing issue by disallowing prfs with key size restrictions. Comments? -Lewis From owner-ipsec Wed Oct 1 17:56:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05970 for ipsec-outgoing; Wed, 1 Oct 1997 17:52:14 -0400 (EDT) Message-Id: <199710012157.OAA19127@pita.cisco.com> To: EKR cc: dharkins@ipsec.com, Hugo Krawczyk , ipsec@tis.com Subject: Re: change in isakmp/oakley In-reply-to: Your message of "01 Oct 1997 11:58:22 PDT." <34t71ux81.fsf@kmac.terisa.com> Date: Wed, 01 Oct 1997 14:57:03 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > But I haven't really seen a groundswell of support or opposition and that's > a bit disheartening. Can somebody out there in ipsec-land who gives a damn > either way speak up? No one can prevent folks from writing insecure prf's or bad ciphers. You can define the properties of a prf or cipher that secure instantiations should exhibit. Lopping off key bits just seems wrong and I would support adding text to the prf section of the upcoming resolution document to say, "don't do that." However, given that Hugo has not shown any problems with the current prf's that are defined, I would leave the current definition as is. Derrell From owner-ipsec Wed Oct 1 18:03:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA06061 for ipsec-outgoing; Wed, 1 Oct 1997 18:03:44 -0400 (EDT) Date: Wed, 1 Oct 1997 18:13:48 -0400 Message-Id: <199710012213.SAA12014@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: dharkins@ipsec.com Cc: Hugo Krawczyk , ipsec@tis.com In-Reply-To: dharkins@ipsec.com's message of Wed, 01 Oct 1997 10:33:08 -0700, <199710011733.KAA17139@dharkins-ss20> Subject: Re: change in isakmp/oakley Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: dharkins@ipsec.com Date: Wed, 01 Oct 1997 10:33:08 -0700 But I haven't really seen a groundswell of support or opposition and that's a bit disheartening. Can somebody out there in ipsec-land who gives a damn either way speak up? I'm willing to change the draft if enough people say it's important. I'm also willing to leave it alone and let people negotiate ROT-13 for encryption and the futuristic-key-truncating MAC for authentication (using private use attributes of course-- I wouldn't include them in the draft) if they're that stupid. Let me add my own request to Dan's ---- if someone of the other cryptographers who hang out on ipsec would comment, I would greatly appreciate it..... - Ted From owner-ipsec Wed Oct 1 19:28:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA06508 for ipsec-outgoing; Wed, 1 Oct 1997 19:24:17 -0400 (EDT) Message-Id: <2.2.32.19971001233500.006c355c@pop.erols.com> X-Sender: tbartee@pop.erols.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 1997 19:35:00 -0400 To: ipsec@tis.com From: Thomas Bartee Subject: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk Several contributors to the SA-SPI discussion effort have expressed concern that the Corporations mentioned in my examples were from the Military-Industrial complex and were not typical. In fact they were as far from this area as I could manage. Among the firms referenced were Amgen, Genzyme, Polaroid, Kodak, Solomon Industries, Hickok, Honeywell, and Genelabs. It is my observation that commercial international concerns are at least as concerned with security as the Military-Industrial complex. A look at current litigation at GM, Kodak, VW, and other firms would seem to confirm this. Also, large multinational corporations must protect themselves since divisions and projects are spread out and there is no simple inside and outside. The same applies to smaller firms which often do business with several larger firms and are expected to keep the work and transaction details carefully protected. A good example is the biotech firms where product development must be carefully protected and success or failure can depend on this protection. These firms are often divided into separate development areas, which have funding from and interaction with larger (well-financed) pharmaceutical corporations. I appreciate that there is an effort to "crash out" such documents as ARCH, ESP, AH, ISAKAMP, OAKLEY, DOMAIN, etc. (and I apologize for adding to the general glut of responses.) The question remains: How can business requirements be managed in a less than simple environment where contractor channels need to be easily opened and closed, and new projects started and old terminated without untoward management strains. All this should be done without passing access control (based on other than simple address-based key management) off to something lurking outside a tunnel-like environment? In looking for answers, we notice Steve Kent's comments on the possible use of a blank section in the architecture document. This looked like a real possibility, however, work on this section will apparently be deferred to later versions . Fortunately, we notice the security domain draft has in Section 4.6.1 two fields (with associated length fields) which can be used for (1) security levels, and, (2) categories. There are several things to be noticed concerning the term "security categories." (First, lets note that the term "security markings" is generally used to delineate security categories like "Company Confidential", "Release to Camera Production", "Release to Hickok Accounting", etc.) I'll use names like these for categories as a help in writing. There are two basic types of categories. These are often called "compartments" and "release markings". 1. Compartments are normally taken to be "all or nothing" markings. Lets consider the simple case of a single organization and its employees (or departments) which need to communicate. Among the compartments we find: "Camera-Engineering", "New-PL-Project", and "Shutter-Design". These markings name compartments which are a particular kind of category, and if a document has all three compartment names on it, an employee must be in all three compartments to have a right to the information in this area. (Perhaps the best known philosopher (he was Austrian) of this century worked on representation techniques like this and their meanings (also on language games and truth tables.) There is an English film about him which is good silly fun if you are not easily shocked. Does anyone know philosopher-logician and who directed the film? We note the last Security Intellectual Prize went to Steve Goldhaber for Clockwork Orange and Soldier of Orange (Soldaat von Orange.)) If we consider the bit map representation in the domain document, and if we assume the first three bits represent these compartment markings, communications would require 1s in these positions when establishing a connection to exchange the document. The beauty of the bit map is: an access determination can be made by a program blindly performing a simple logical operation on the two fields and then testing for 1s in the result. This can be done with three or four machine language instructions for up to 64 markings (categories-compartments.) The test can be made without the testing program knowing anything about what the markings are, leaving the system managers to establish their communications networking as required. This, of course, assumes system managers have some easy way to set up the compartments and their names.) 2. Levels are subcategories of compartments. If Level A is higher than Level B then any entity with an A marking can communicate using B markings (as can, of course, those with Bs.) If B is higher than C then A can use A, C, or B; B can use B or C; and C only can use C. This means levels can be placed in compartment bit maps with no alteration of the simple program steps which were used for compartments in general. For the above we have 111 for A, 011 for B, and 001 for C. (If you're not familiar with this, try it. I'm not suggesting the domain protocol be modified by omitting the level field, just showing possibilities.) 3. The type of commercial marking not covered above is generally called a "release category" (for historical reasons, among others.) This is an OR operation from a logical viewpoint while compartments are ANDed. Typical markings would be "Release to Genzyme", "Release to Production", "Release to Accounting", "Release to France," etc. We note that studies indicate release markings are at least as much used as compartments and are possibly more used. Processing is as fast as for compartments. They should not be ignored. It is not possible to mix compartment and release markings in a single bit map and process with the simple steps described above. Possible alternatives for fixing the domain document so program developers can be assured of interoperability are: (a) divide the bit map field length in two and place compartment bits in the first half and release bits in the second half. This means that programs written to comply with the standard must process the halves separately. (b) Have an extra length field that gives the length of the compartment field (or release) markings. (c) Decide once and for all which part of the field is for compartments and which is for release markings and fix the length. (d) Have separate fields for compartment and release markings, including length fields. The above will result in approved (OK) standards programs which can process without additional information, simplifying standard compliant program preparation. It also helps clarify what the standard means. My choice would be (d), which allows programs to process the fields without further information exchange and also gives maximum freedom of category representation. It would also not be a bad idea to label the fields. Lets hear from those who understand the above and see possibilities. A little care might expand markets. From owner-ipsec Wed Oct 1 20:44:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA06895 for ipsec-outgoing; Wed, 1 Oct 1997 20:43:16 -0400 (EDT) Message-ID: <01BCCE93.164A1740.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'ipsec'" Subject: ISAKMP/Oakley does not allow negotiation on PFS requirement. Date: Wed, 1 Oct 1997 17:54:34 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk With ISAKMP/Oakley, we have a choice of requiring PFS. However, it does not provide any means of negotiating PFS. So, if initiator would prefer that PFS is not a requirement, but will accommodate responders desires for PFS, there is no easy way of communicating this to the responder. In this situation, initiator has no choice but to require PFS. If it does include KE in the phase 2 message, responder will assume that PFS is required by initiator. If it does not include KE in the message, and responder requires PFS, phase 2 fails. It is my opinion that as part of the ISAKMP/Oakley SA negotiation, the requirements for PFS must be negotiated. So that before starting phase 2, the communicating peers know each others requirements for PFS and agree upon on that is acceptable to both. Baiju From owner-ipsec Wed Oct 1 21:24:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA07088 for ipsec-outgoing; Wed, 1 Oct 1997 21:24:17 -0400 (EDT) Message-Id: <199710020134.SAA17414@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "baiju@mailbox.jf.intel.com" Cc: "'ipsec'" Subject: Re: ISAKMP/Oakley does not allow negotiation on PFS requirement. In-Reply-To: Your message of "Wed, 01 Oct 1997 17:54:34 PDT." <01BCCE93.164A1740.baiju@mailbox.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 1997 18:34:30 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, There's no way to inform the peer of what you want before you inform him of what you want. If the responder requires PFS and the initiator didn't offer it I'd imagine a notify message (attributes not supported) would be sent back. This is the same as an encryption algorithm. If you will only do 3DES and I send you DES (while I do support 3DES I chose not to offer it because this is session is not hypercritical and I chose to maximize on speed) you won't accept it. I don't think that information regarding PFS can be exchanged in phase 1 in anticipation of a phase 2 exchange because I don't know what the phase 2 exchange is before it happens. I might have policy configured to require PFS on telnets to a host behind my IPSec-aware router but not for ftps to a different host behind it. If I don't know what the next phase 2 exchange is going to be for I can't accurately tell you what I want. I might require PFS; I might not. If you, as an initiator, would prefer not to do PFS but would accomodate a responder's desire to do so there is, indeed, no way for you to do this since you must already have done a modular exponentiation and passed a Diffie-Hellman public value to the responder for the exchange to take place. You could always send a KE payload and double all SA offers-- one with a group description indicating PFS, another without-- and see what the responder decides. This would mean you might do alot of unnecessary exponentiation but with your new 300MHz processors it's not a problem, right? :-) Of course we could add another roundtrip message to Quick Mode as a basic "here's what I'm going to ask you for, what do you think about it before negotiation begins" but it already takes long enough to acquire the SAs and I'd rather not delay it any more. Since we have a mechanism to deal with this issue I'm even more hesitant to change anything. Dan. P.S. You could use SKIP's algorithm discovery protocol to probe the peer for what he supports! > With ISAKMP/Oakley, we have a choice of requiring PFS. However, it does > not provide any means of negotiating PFS. > > So, if initiator would prefer that PFS is not a requirement, but will > accommodate responders desires for PFS, there is no easy way of communicating > this to the responder. > > In this situation, initiator has no choice but to require PFS. If it does > include KE in the phase 2 message, responder will assume that PFS is required > by initiator. If it does not include KE in the message, and responder > requires PFS, phase 2 fails. > > It is my opinion that as part of the ISAKMP/Oakley SA negotiation, the > requirements for PFS must be negotiated. So that before starting phase 2, > the communicating peers know each others requirements for PFS and agree upon > on that is acceptable to both. From owner-ipsec Wed Oct 1 22:11:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA07286 for ipsec-outgoing; Wed, 1 Oct 1997 22:10:15 -0400 (EDT) Date: Thu, 2 Oct 97 01:53:56 GMT Daylight Time From: Ran Atkinson Subject: Re: SAs and SPIs To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19971001233500.006c355c@pop.erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't support Tom Bartee's proposed changes. I think the current DOI is perfectly fine for commercial use and Internet use. I don't want progress to be delayed further by more changes now. "Release markings" are a rat hole that we could spend years debating. I'd prefer to not go there for now. RFC-1825 had language that was minimally sufficient for the MLS environment. I'd suggest retaining that language in the ARCH document -- only for those systems that claim to provide MLS. The previous language specifically said the MLS details _weren't_ applicable if the implementation didn't claim to provide MLS, which seems right to me. I think the WG's primary obligation at this point is to get documents that are "good enough" (where that is != perfect) out as standards-track RFCs. Ran rja@inet.org From owner-ipsec Thu Oct 2 09:52:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA11478 for ipsec-outgoing; Thu, 2 Oct 1997 09:50:16 -0400 (EDT) Message-Id: <199710021336.JAA03055@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-01.txt Date: Thu, 02 Oct 1997 09:36:41 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-ietf-ippcp-protocol-01.txt Pages : 8 Date : 01-Oct-97 Author's Note: IP Payload Compression is a spin-off of IPSec This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippcp-protocol-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-protocol-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971001094431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971001094431.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Oct 2 10:13:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11657 for ipsec-outgoing; Thu, 2 Oct 1997 10:13:17 -0400 (EDT) Message-Id: <97Oct2.102317edt.11651@janus.tor.securecomputing.com> To: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Notify code(s) missing? From: "C. Harald Koch" Date: Thu, 2 Oct 1997 10:23:11 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In , It Is Written: If ISAKMP is acting as a proxy negotiator on behalf of another party the identities of the parties MUST be passed as IDui and then IDur. Local policy will dictate whether the proposals are acceptible for the identities specified. If IDs are not exchanged, the negotiation is assumed to be done on behalf of each ISAKMP peer. If an ID range (see Appendix A of [Pip96]) is not acceptable (for example, the specified subnet is too large) a BAD_ID_RANGE notify message followed by an acceptible ID range, in an ID payload, MUST be sent. However, I can't find the definition of "BAD_ID_RANGE" in any of the documents. Since DOI-4 is the first to define DOI specific Notifies, I suspect this is a minor editorial oversight; can we add it to the list? Similarly, for "5.5 New Group Mode": ... If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to GROUP_NOT_ACCEPTABLE (13). GROUP_NOT_ACCEPTABLE isn't defined anywhere, but Notify 13 is "ATTRIBUTES-NOT-SUPPORTED". Are they intended to be the same or different? Thanks, -- Harald Koch From owner-ipsec Thu Oct 2 12:41:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12569 for ipsec-outgoing; Thu, 2 Oct 1997 12:38:49 -0400 (EDT) Message-Id: <199710021648.JAA02437@pita.cisco.com> To: "C. Harald Koch" cc: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: Notify code(s) missing? In-reply-to: Your message of "Thu, 02 Oct 1997 10:23:11 EDT." <97Oct2.102317edt.11651@janus.tor.securecomputing.com> Date: Thu, 02 Oct 1997 09:48:32 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, Since both of these errors apply specifically to ISAKMP/Oakley and not to base ISAKMP (which isn't Oakley or IPSEC specific), I would expect them to be defined either in the resolution or, preferrably, in the IPSEC DOI. (I think BAD_ID_RANGE might have been in a pre-draft of ISAKMP-08, but we cculdn't remember what it was there for and we took it back out...) If there are no objections, I'll add both to the IPSEC DOI. Derrell From owner-ipsec Thu Oct 2 18:11:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14996 for ipsec-outgoing; Thu, 2 Oct 1997 18:07:55 -0400 (EDT) Message-Id: <199710022218.PAA18142@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Hugo Krawczyk Cc: ipsec@tis.com Subject: Re: change in isakmp/oakley In-Reply-To: Your message of "Wed, 01 Oct 1997 13:42:14 +0300." <199710011042.NAA09308@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Oct 1997 15:18:14 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo, > > Is the (non)mixing of Ni and Nr in encryption mode authentication broken > > or does it just reenforce the brokenness of certain (as yet unnamed) prfs? > > It may be closer to the latter, but still a MUST to fix. > You have no "right" to give future implementations a rope to > hung themselves.. > > We have put a lot of effort to have the protocol as robust as > possible. Security is not only resistance to known attacks, > but resistance to tomorrow's attacker as well. And the specifications > should be complete enough to provide robustness "against" > tomorrow's implementers too. You're suggesting making this this modification to prevent a future prf, that shortens its key if the key is too big, from resulting in a weakening of the protocol. Since we're talking about hypothetical functions what about a prf which uses a shorter key than it's output and also truncates its key. We already have a prf which uses a larger key than it produces as output (3DES-CBC-MAC) and since we're dealing in hypotheticals I don't think I'm out in left field on this. To prevent a weakening of the protocol and still accomodate these prfs should every instance of prf generation hash the key? For instance, SKEYID_d is created like so: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) where SKEYID = prf( some authentication specific stuff here ) Now your concern about key truncation in the prf, taken a step further to accomodate those prfs which use a shorter key than their output, would lead us to the following: SKEYID_d = prf(hash(SKEYID | something), g^xy | CKY-I | CKY-R | 0) to allow for proper mixing of the key before hashing. I hope you see the tremendous rewrite necessary to accomodate future, prfs which, in my opinion are already broken because they truncate the key. In 100% of the cases (I feel confident in saying that because I don't think anyone would use a prf which truncates the key) there will be unnecessary hashing of keys before sending them to the prf (which in the case of HMAC does hashing anyway if the key is "too big"). You've said that the protocol isn't broken but should be changed to accomodate broken prfs. In spite of your insistance I'm going to respectfully decline your suggestion. There's been several emails to the list (I'd kinda hoped for more) and I've received private ones which I will share with you if you like (and the author doesn't mind) and they're all of the mind to just leave the document the way it is. I'll add verbage noting known security problems with prfs which truncate their key but we already allow people to shoot themselves in the foot (they can negotiate ROT-13, or-- this is coming on April 1st, 1998-- the new, triple-ROT-13 with derived IV) and 2 bullet holes in a foot are just as painful as 1. regards, Dan. From owner-ipsec Fri Oct 3 00:32:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16699 for ipsec-outgoing; Fri, 3 Oct 1997 00:27:52 -0400 (EDT) Message-Id: <199710030435.AAA10950@relay.rv.tis.com> Date: Fri, 3 Oct 97 0:29:59 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Internet Drafts -- AH and ESP specs Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, We just submitted drafts of the AH and ESP specs to the IETF Secretariat for posting for working group Last Call. The following list is a summary/guide to the changes we've made in response to the group's feedback on the end of July drafts. (This does not include fixes for minor typos, etc.) Note that items 1-7 apply to both AH and ESP, items 8-9 apply to only AH, and items 10-11 apply to only ESP. Thank you, Karen ------------------------------------------------------------------------------- AH and ESP ========== 1. Re-organized processing section of the documents: - to have an Algorithms section - so that Outbound and Inbound processing sections are more parallel. Outbound Inbound --------- ------- SA Lookup Reassembly (if needed) Encryption (if ESP) SA Lookup Seq Number Generation Sequence Number Verification ICV Calculation ICV Verification Fragmentation (if needed) Decryption (if ESP) AH -- Changed from (some lower level sections are not shown): 3. Authentication Header Processing...........................6 3.1 Authentication Header Location........................6 3.2 Outbound Packet Processing............................8 3.2.1 Security Association Lookup......................8 3.2.2 Sequence Number Generation.......................8 3.2.3 Integrity Check Value Calculation................9 3.2.3.1 Handling Mutable Fields.....................9 3.2.3.2 Padding....................................11 3.2.3.3 Authentication Algorithms..................12 3.2.4 Fragmentation...................................12 3.3 Inbound Packet Processing............................13 3.3.1 Reassembly......................................13 3.3.2 Security Association Lookup.....................13 3.3.3 Sequence Number Verification....................13 3.3.4 Integrity Check Value Verification..............14 to (some lower level sections are not shown): 3. Authentication Header Processing...........................6 3.1 Authentication Header Location........................6 3.2 Authentication Algorithms.............................8 3.3 Outbound Packet Processing............................9 3.3.1 Security Association Lookup......................9 3.3.2 Sequence Number Generation.......................9 3.3.3 Integrity Check Value Calculation...............10 3.3.3.1 Handling Mutable Fields....................10 3.3.3.2 Padding....................................12 3.3.4 Fragmentation...................................13 3.4 Inbound Packet Processing............................14 3.4.1 Reassembly......................................14 3.4.2 Security Association Lookup.....................14 3.4.3 Sequence Number Verification....................14 3.4.4 Integrity Check Value Verification..............15 ESP -- Changed from: 3. Encapsulating Security Protocol Processing.................7 3.1 ESP Header Location...................................7 3.2 Outbound Packet Processing...........................10 3.2.1 Security Association Lookup.....................10 3.2.2 Sequence Number Generation......................10 3.2.3 Packet Encryption...............................10 3.2.3.1 Scope of Encryption.........................10 3.2.3.2 Encryption Algorithms.......................11 3.2.4 Integrity Check Value Calculation...............11 3.2.4.1 Scope of Authentication Protection.........11 3.2.4.2 Authentication Padding.....................11 3.2.4.3 Authentication Algorithms..................12 3.2.5 Fragmentation...................................12 3.3 Inbound Packet Processing............................12 3.3.1 Pre-ESP Processing Overview.....................12 3.3.2 Security Association Lookup.....................12 3.3.3 Sequence Number Verification....................13 3.3.4 Integrity Check Value Verification..............14 3.3.5 Packet Decryption...............................15 to: 3. Encapsulating Security Protocol Processing.................7 3.1 ESP Header Location...................................7 3.2 Algorithms...........................................10 3.2.1 Encryption Algorithms...........................10 3.2.2 Authentication Algorithms.......................10 3.3 Outbound Packet Processing...........................11 3.3.1 Security Association Lookup.....................11 3.3.2 Packet Encryption...............................11 3.3.3 Sequence Number Generation......................12 3.3.4 Integrity Check Value Calculation...............12 3.3.5 Fragmentation...................................13 3.4 Inbound Packet Processing............................13 3.4.1 Reassembly......................................13 3.4.2 Security Association Lookup.....................13 3.4.3 Sequence Number Verification....................14 3.4.4 Integrity Check Value Verification..............15 3.4.5 Packet Decryption...............................15 ------------------------------------------------------------------------------- 2. Reworded definition of SPI. AH -- Section "2.4 Security Parameters Index (SPI), changed from: "The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header with which this security header is associated, and relative to the security protocol employed." to: The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol, uniquely identifies the Security Association for this datagram. ESP -- Section "2.1 Security Parameters Index", changed from: "The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header with which this security header is associated, and relative to the security protocol employed." to: The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol, uniquely identifies the Security Association for this datagram. ------------------------------------------------------------------------------- 3. Changed AH and ESP diagrams to more closely conform with the IPv6 spec (see July 1997 version, page 8) AH -- Section "3.1 Authentication Header Location", changed: AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers to: AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |rtg, fragmentation | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP -- Section "3.1 ESP Header Location", changed: AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP| |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| to: |<---- authenticated ---->| AFTER APPLYING ESP ----------------------------------------------------------- IPv6 | orig |hop-by-hop, dest*, | |dest| | | ESP | ESP| |IP hdr|rtg, fragmentation |ESP|opt*|TCP|Data|Trailer|Auth| ----------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ------------------------------------------------------------------------------- 4. Clarified AH and ESP explanation for zero SPI.... AH -- Section "2.4 Security Parameters Index", changed: (A zero value may be used for local debugging purposes, but no AH packets should be transmitted with a zero SPI value.) to: The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. ESP -- Section "2.1 Security Parameters Index" (A zero value may be used for local debugging purposes, but no AH packets should be transmitted with a zero SPI value.) to: The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. ------------------------------------------------------------------------------- 5. For *transport* mode, changed the AH and ESP documents to state that with regard to nesting of AH and ESP headers: o Security policy determines the order of application. o The following 3 cases MUST be supported: 1. [IP][AH][upper] 2. [IP][ESP][upper] 3. [IP][AH][ESP][upper] o Arbitrary nesting is allowed -- it is a MAY generate for senders and a SHOULD accept for receivers. *WARNING*: The flexibility to have arbitrary nesting was requested by several folks on the WG list but will require extra care by implementors. Specifically, arbitrary nesting will require the implementors to ensure that any mutable "AH protected" fields outside/above the AH header, i.e., IP length, IP Next Protocol and any IPsec headers, are appropriately handled by Outbound and Inbound processing as the headers are nested and unnested. Implementations also will need to take into account the rules for IPv6 header extension processing. This complexity will apply to: 4. [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper] Nesting involving only ESP headers should not be problematic: 5. [IP][ESP][ESP]...[ESP][upper] At present, the following changes have been made to the AH and ESP specs. For AH -- Section "3.1 Authentication Header Location", paragraph 2, changed from: In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted, e.g., ESP. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol.... to: In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before (outside of) any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol... The following text has been added after the diagram of applying AH in transport mode to an IPv6 packet: If more than one IPsec header/extension is required: o the order of application of the security headers MUST be defined by security policy o The following 3 cases MUST be supported: 1. [IP][AH][upper] 2. [IP][ESP][upper] 3. [IP][AH][ESP][upper] o arbitrary nesting is allowed -- Senders MAY generate arbitrary nestings of IPsec headers and Receivers SHOULD accept arbitrary nestings of IPsec headers. Also in Section "3.2 Outbound Packet Processing" (now called 3.3), added the following as a second paragraph. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.) Also, in Section "3.3 Inbound Packet Processing" (now called 3.4), added the following as a first paragraph to the section. If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. For ESP -- Section "3.1 ESP Header Location", paragraph 2, changed from: In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted, e.g., AH. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol.... to: In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. The following text has been added after the diagram of applying ESP in transport mode to an IPv6 packet: If more than one IPsec header/extension is required: o the order of application of the security headers MUST be defined by security policy o The following 3 cases MUST be supported: 1. [IP][AH][upper] 2. [IP][ESP][upper] 3. [IP][AH][ESP][upper] o arbitrary nesting is allowed -- Senders MAY generate arbitrary nestings of IPsec headers and Receivers SHOULD accept arbitrary nestings of IPsec headers. Also in Section "3.2 Outbound Packet Processing", (now called section 3.3) added the following sentence at the end of the first paragraph: "If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy." ------------------------------------------------------------------------------- 6. Modified Sequence Number text in the following sections. (The left section numbers are from after the re-organization mentioned above. The "was" numbers are the section numbers from the versions distributed to the working group in July.) Section AH was ESP was ---------------------------- ----- ----- ----- ----- Sequence Number 2.5 2.2 Sequence Number Generation 3.3.2 3.2.2 3.3.3 3.2.2 Sequence Number Verification 3.4.3 3.3.3 3.4.3 3.3.3 to convey to the reader that: For Sender: - If anti-replay has been enabled, the transmitted Sequence Number must never be allowed to cycle. In this case, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA (with a new SPI and a new key)) prior to the transmission of the 2^32nd packet on an SA. - Only if anti-replay has been enabled, is a counter overflow an auditable event for the sender. - If anti-replay has not been enabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. Text has been included saying: "NOTE: If the receiver does NOT notify the sender that anti-replay is enabled, then the sender may overflow the counter and may send packets that the receiver will reject." For Receiver: - Receiver SHOULD notify sender if anti-replay is enabled. - Receiver does NOT notify sender of window size. - Default (required minimum) receive window-size is 32, recommended is 64, other sizes >32 are allowed. The following text was chosen: "A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver." ------------------------------------------------------------------------------- 7. Updated the references on mandatory-to-implement algorithms; changed all previous mentions of these algorithms to point to Section 5. "Conformance Requirements." As a result also had to change the text that explained about truncation to the leftmost 96 bits since it originally mentioned the default algorithms. AH: 3.2 Authentication Algorithms ..... The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. Note: Where an algorithm yields more than 96 bits, the output of the computation is truncated to the leftmost 96 bits. Other sections were changed too. 5. Conformance Requirements..... A compliant AH implementation MUST support the following mandatory-to-implement algorithms: - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] Added references: "[MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, 7/2/97." "[MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, 7/2/97." ESP: Changed the mandatory-to-implement encryption algorithms from DES-CBC with implicit IV generation to DES-CBC with explicit IV; updated the reference; changed all previous references to these algorithms to point to Section 5. "Conformance Requirements." Other sections were changed too. 3.2 Algorithms....."The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported." 3.2.2 Authentication Algorithms... Note: Where an algorithm yields more than 96 bits, the output of the computation is truncated to the leftmost 96 bits. In Section "5. Conformance Requirements"..... "A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] Deleted: "[MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", RFC-xxxx, August 1997." Added: "[MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", 07/02/1997." "[MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, 7/2/97." "[MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, 7/2/97." ------------------------------------------------------------------------------- AH only ======= 8. Clarified explanation for how Payload Length is calculated. Section "2.2 Payload Length", changed from: This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion (as defined in the original AH spec) of AH is not counted. (Since the Sequence Number field is always present, the fixed portion of AH is now three 32-bit words. However, the "minus 2" length adjustment has been retained for backwards compatibility.) to: This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) ------------------------------------------------------------------------------- 9. Clarified that the AH ICV covers the header itself. Inserted the following text after 3.3.3 "Integrity Check Value Calculation": "The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit Deleted the first two sentences of 3.3.3.1 Handling Mutable Fields, paragraph 1, leaving: If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field is also set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. ------------------------------------------------------------------------------- ESP only ======== 10. Made section "3.3.1 Pre-ESP Processing Overview" (now called "3.4.1 Reassembly") parallel to the AH section "3.3.1 Reassembly" (now called 3.4.1 Reassembly"), by changing: "If required, reassembly is performed prior to ESP processing." to: "If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID." ------------------------------------------------------------------------------- 11. Made discussion of 3.2.3 Packet Encryption (now called 3.3.2) more parallel to the discussion of 3.3.5 Packet Decryption (now called 3.4.5). From owner-ipsec Fri Oct 3 08:25:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA19150 for ipsec-outgoing; Fri, 3 Oct 1997 08:21:44 -0400 (EDT) Date: Fri, 3 Oct 1997 14:25:14 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199710031125.OAA21448@ee.technion.ac.il> To: dharkins@cisco.com Subject: Re: change in isakmp/oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, your message and resolution on this issue tempts me to write a long message about the wisdom of designing cryptography "by rough consensus". Fortunately, I will save you (and myself) from such a useless and doomed-to-fail sermon. I don't have the writing skills and the time to represent correctly these issues. Also, it would be quite unfair to relate these complaints precisely to you, probably the best partner I had in my 3+ years working in this WG. (Not that you haven't given me a hard time in many issues, but you were very fair, open and reasonable.) Also, relative to my expectations from ipsec key exchange a couple of years ago I can't complain about the end results. Still, after so much effort it is hard to accept that we are going to leave unnecessary holes in the protocol. (I am talking about a correction not about improvements, of which I could offer several but will not, in favor of the rough consensus, of course). As I said in previous messages the example of truncation is just an example. There are some other more "sophisticated" reasons that call for this change. One of these reasons is that we do not know how to provide a satisfactory security analysis of the protocol without this change. And being the change as simple as it is (yes, I know that it will "break" existing implementations; I also know that they will be fixed in one week with no damage to anyone) that should be enough of a reason. Another reason is that the only external review that I am aware of on this protocol has been the review of SKEME. So we shouldn't be departing unnecessarily from that design. Lastly, forget about the truncation example if you want. Notice the bigger picture: we face a case where the attacker can influence the authentication key by choosing Nr. Thus, by not hashing Ni and Nr we are opening an opportunity for this attacker to break the authentication. (As another not-totally convincing example, but maybe of some didactic value, think of 3DES with two keys, i.e ENC(K1, DEC(K2, ENC(K2, data))), as the prf, and K1=Ni K2=Nr; in this case the attacker reduces the strength of authentication to that of single DES). And there is more to it, for example attacks where the adversary EVE tries to learn something about Ni by intercepting Pubkey_r in its way from I to R; then replays this encryption as coming from herself to I; and finally learns some information on Ni from the response of R (which in this case will include the prf keyed with Ni and some Nr' that R sends to Eve). Does it help Eve? Not, PROVIDED that Ni and Nr' are cryptographically mixed. (Oops, that stupid mixing again...) That's it. Now the ball is in your hands (as it has always been). Just one favor please: in the revised encryption mode (which eventually I hope will replace the other one) define SKEYID as prf(hash(Ni|Nr), CKY-I | CKY-R). In this case there is no problem of broken implementations as it is a *new* addition to the draft. And assuming that you'll leave the current encryption mode, put some note (e.g in the "security considerations" section) warning about the mixing issue. You will not regret it. Hugo PS: you said that following the same logic you will end having to specify things like: > SKEYID_d = prf(hash(SKEYID | something), g^xy | CKY-I | CKY-R | 0) The answer is no, you don't need to do that. The prf key for deriving SKEYID_d is SKEYID is itself an output of the prf (with another key). To get SKEYID_d to serve directly as a key to the prf, you just need to generate it with the right length. But this problem is already solved in the draft using feedback mode. The problem we face now is different: that is, how to deal with length variable keys (not with length variable outputs) to generate SKEYID. And, in particular, for the encryption mode we deal with the problem of "key mixing" (preventing one party from influencing the key more than the other). But I believe that I've said that before... Time to shut up. From owner-ipsec Fri Oct 3 09:37:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19600 for ipsec-outgoing; Fri, 3 Oct 1997 09:36:57 -0400 (EDT) Message-Id: <199710031332.JAA02809@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-00.txt Date: Fri, 03 Oct 1997 09:32:52 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ISAKMP Configuration Mode Author(s) : R. Pereira, S. Anand Filename : draft-ietf-ipsec-isakmp-mode-cfg-00.txt Pages : 7 Date : 02-Oct-97 This document describes a new ISAKMP mode that allows configuration items to be set by using both push/acknowledge and request/reply paradigms. 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-isakmp-mode-cfg-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971002095615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971002095615.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Oct 3 09:37:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19594 for ipsec-outgoing; Fri, 3 Oct 1997 09:35:57 -0400 (EDT) Message-Id: <199710031332.JAA02770@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-00.txt Date: Fri, 03 Oct 1997 09:32:45 -0400 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-00.txt Pages : 14 Date : 02-Oct-97 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 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-ciph-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-cbc-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971002095211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971002095211.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Oct 3 12:09:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20604 for ipsec-outgoing; Fri, 3 Oct 1997 12:07:00 -0400 (EDT) Message-ID: <01BCCFDD.4F392B40.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'ipsec'" Subject: Comments on ISAKMP and Oakley resolution document. Date: Fri, 3 Oct 1997 09:18:06 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk 1. Is the value SAp in HASH_I the SA payload as sent by the initiator and SAp in HASH_R the SA payload sent by the responder? It seems like many people have implemented there ISAKMP/Oakley with above interpretation. However, SAp defined in section 3.2 clearly states that it is SA payload sent by the initiator. Could someone please clarify this? 2. Examples of phase 1 (e.g., section 5.8.1) shows SPI to be 8 bytes. Since SPI has no interpretation (that I know of) in phase 1, SPI size should be set to 0 and SPI field should not exist. Many implementations ignore non-zero SPI's. However, there is no reason to show something in the example that is not required. 3. In section 5.4 HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. Gives an impression that somehow header (not just MID should be included in the HASH(1). Also, it gives an impression that if you took MID, and rest of the payload (excluding padding) and computed hash you will be all set. After reading this, any optional payloads were transmitted with the message, they will also be included in the hash computation. At the same time, HASH(1) is defined as HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) Which clearly says that different payloads of ISAKMP/Oakley must be hashed in a particular order (not necessarily the order of transmission of these payloads). One of the two definitions need to be changes. This definition excludes anything except what is specified. One of the two need to be fixed. Same comments hold for HASH(2) description. Baiju From owner-ipsec Fri Oct 3 12:54:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20917 for ipsec-outgoing; Fri, 3 Oct 1997 12:53:58 -0400 (EDT) Message-Id: <199710031704.KAA19290@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "baiju@mailbox.jf.intel.com" Cc: "'ipsec'" Subject: Re: Comments on ISAKMP and Oakley resolution document. In-Reply-To: Your message of "Fri, 03 Oct 1997 09:18:06 PDT." <01BCCFDD.4F392B40.baiju@mailbox.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Oct 1997 10:04:14 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, > 1. Is the value SAp in HASH_I the SA payload as sent by the initiator and > SAp in HASH_R the SA payload sent by the responder? It seems like many > people have implemented there ISAKMP/Oakley with above interpretation. > However, SAp defined in section 3.2 clearly states that it is SA payload > sent by the initiator. > > Could someone please clarify this? The whole point of including SAp in the hash is to prevent a man-in-the-middle attack against the initial offer (which would otherwise be unauthenticated). If the responder only included his response it would not preclude such an attack (and would, in fact, be pointless). So, as defined in the draft, SAp is the entier body of the SA payload sent by the initiator. If anyone implemented otherwise they wouldn't interoperate and judging by the very high degree of ISAKMP interoperability at the last IPSec bakeoff I think everybody is doing it this way. > 2. Examples of phase 1 (e.g., section 5.8.1) shows SPI to be 8 bytes. Since > SPI has no interpretation (that I know of) in phase 1, SPI size should be > set to 0 and SPI field should not exist. Many implementations ignore non-zero > SPI's. However, there is no reason to show something in the example that is > not required. I've removed that but I know of implementations which send 8 bytes of zero. You can say that that is pointless (and I wouldn't argue with you) but some do and you shouldn't barf if they send it to you. > 3. In section 5.4 > HASH(1) is the prf over the message id (M-ID) from the ISAKMP > header concatenated with the entire message that follows the hash > including all payload headers, but excluding any padding added for > encryption. > > Gives an impression that somehow header (not just MID should be included in > the HASH(1). Also, it gives an impression that if you took MID, and rest > of the payload (excluding padding) and computed hash you will be all set. > After reading this, any optional payloads were transmitted with the message, > they will also be included in the hash computation. > > At the same time, HASH(1) is defined as > > HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) > > Which clearly says that different payloads of ISAKMP/Oakley must be hashed > in a particular order (not necessarily the order of transmission of these > payloads). One of the two definitions need to be changes. This definition > excludes anything except what is specified. One of the two need to be > fixed. Same comments hold for HASH(2) description. The "entire message following the hash" cannot include the header because the header precedes the hash. If you can think of a better way to describe this please let me know. The contents of HASH(1) (and HASH(2) too) are defined in text. The illustration is "for the above exchange". The draft only states that the HASH payload must be first and IDui must precede IDur, not that any of the other payloads have any specific order. The illustration is just that. If you send the KE before the nonce then you should hash the "entire message following the hash" into HASH(1) and that message would have the KE before Ni. Your impression is correct. If you took the M-ID and the rest of the payload (excluding the padding) and computed the hash you would be all set. I'll add "nothing in this illustration should be construed as mandating a particular order to payloads outside that already specified in this draft" if it will dispell this belief. Dan. From owner-ipsec Fri Oct 3 12:57:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20930 for ipsec-outgoing; Fri, 3 Oct 1997 12:57:27 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Karen Seo'" , "'ipsec@tis.com'" Subject: RE: Internet Drafts -- AH and ESP specs Date: Fri, 3 Oct 1997 11:53:43 -0400 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 On Friday, October 03, 1997 12:30 AM, Karen Seo [SMTP:kseo@bbn.com] wrote: > > - Receiver SHOULD notify sender if anti-replay is enabled. I had thought that we dropped REPLAY negotitation? In fact REPLAY negotiation has not been part of the last three ANX interoperability tests, nor is it in the last few DOI documents. From owner-ipsec Fri Oct 3 17:30:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22690 for ipsec-outgoing; Fri, 3 Oct 1997 17:28:27 -0400 (EDT) Date: Fri, 3 Oct 1997 17:38:34 -0400 Message-Id: <199710032138.RAA13644@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Roy Pereira Cc: "'Karen Seo'" , "'ipsec@tis.com'" In-Reply-To: Roy Pereira's message of Fri, 3 Oct 1997 11:53:43 -0400, Subject: Re: Internet Drafts -- AH and ESP specs Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Roy Pereira Date: Fri, 3 Oct 1997 11:53:43 -0400 > > - Receiver SHOULD notify sender if anti-replay is enabled. I had thought that we dropped REPLAY negotitation? In fact REPLAY negotiation has not been part of the last three ANX interoperability tests, nor is it in the last few DOI documents. As near as I can tell, the consensus/compromise which was reached was that we would drop replay window size negotiation and notification. What's at issue here is a notify message indicating the presence of anti-replay protection by the receiver. As far as I can tell, there hasn't been significant discussion on this topic either way on the mailing list, up to now. Thus, it's hard to judge consensus on this topic, unless one applies the "silence gives assent" standard. My _personal_ belief is that adding a replay notify message is relatively harmless, and may in some cases give useful information to the sender. In any case, adding a notify message shouldn't cause interopability problems, since the transmission of the notify message is not mandatory. (And implementations should be able to deal with notify message types which they don't understand, right? It sould only result in an entry in the audit log.) - Ted From owner-ipsec Fri Oct 3 17:32:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22722 for ipsec-outgoing; Fri, 3 Oct 1997 17:31:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Oct 1997 16:37:10 -0400 To: Roy Pereira From: Stephen Kent Subject: RE: Internet Drafts -- AH and ESP specs Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, The AH and ESP specs call for the receiver to use a NOTIFY to inform the sender of the receiver's intent to employ anti-replay measures, so it is not a negotiation. If you look at the last messages on the topic, dated 8/26 (from Dan Harkins( and 8/28 (from me), the resolution was to make use of this form of notification (proposed by Dan), and the only unresolved point was whether to make the transmission of the NOTIFY a MUST or a SHOULD. Steve From owner-ipsec Fri Oct 3 18:54:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23184 for ipsec-outgoing; Fri, 3 Oct 1997 18:53:30 -0400 (EDT) Message-ID: <01BCD016.1698C5A0.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'Daniel Harkins'" Cc: "'ipsec'" Subject: RE: ISAKMP/Oakley does not allow negotiation on PFS requirement. Date: Fri, 3 Oct 1997 16:04:26 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk See my comments below. -----Original Message----- From: Daniel Harkins [SMTP:dharkins@cisco.com] Sent: Wednesday, October 01, 1997 6:35 PM To: baiju@mailbox.jf.intel.com Cc: 'ipsec' Subject: Re: ISAKMP/Oakley does not allow negotiation on PFS requirement. Baiju, There's no way to inform the peer of what you want before you inform him of what you want. If the responder requires PFS and the initiator didn't offer it I'd imagine a notify message (attributes not supported) would be sent back. [Baiju V. Patel] PFS is not a negotiation attribute (it is not really part of any payload), so attribute not supported may be misleading. Just as part of the curiosity, would I use protocol type as ISAKMP? This is the same as an encryption algorithm. If you will only do 3DES and I send you DES (while I do support 3DES I chose not to offer it because this is session is not hypercritical and I chose to maximize on speed) you won't accept it. [Baiju V. Patel] Not really, the initiator can specify 3DES and DES in order of preference and the responder can respond with either one. In case of PFS, you do not have a choice. It also leaves room for confusion. I don't think that information regarding PFS can be exchanged in phase 1 in anticipation of a phase 2 exchange because I don't know what the phase 2 exchange is before it happens. I might have policy configured to require PFS on telnets to a host behind my IPSec-aware router but not for ftps to a different host behind it. If I don't know what the next phase 2 exchange is going to be for I can't accurately tell you what I want. I might require PFS; I might not. [Baiju V. Patel] Agreed. If you, as an initiator, would prefer not to do PFS but would accomodate a responder's desire to do so there is, indeed, no way for you to do this since you must already have done a modular exponentiation and passed a Diffie-Hellman public value to the responder for the exchange to take place. You could always send a KE payload and double all SA offers-- one with a group description indicating PFS, another without-- and see what the responder decides. This would mean you might do alot of unnecessary exponentiation but with your new 300MHz processors it's not a problem, right? :-) [Baiju V. Patel] I guess there are ways of getting where you want to be (as you specified above). There may still be a clarification needed for the following situation: Initiator sends KE but responder decides that it does not care to send KE because PFS is not important to the responder. Since KE is optional in both cases, this is a legal exchange. a. Does this imply that the if initiator could accommodate communication without PFS, both sides MUST compute keying material with understanding that PFS is not required. b. Sender send a notification saying attribute not supported because the respond did not respond with appropriate KE? c. The responder must either include KE in response or send a notification (mandate that for exchange to be successful, either KE in first and second message must be present or none). d. Sender includes in its proposal (SA) in phase 2 a parameter which tells the responder that PFS is not required by initiator but is included in the message just in case! e. Something else (e.g., it is clear to me, leave it alone)! Of course we could add another roundtrip message to Quick Mode as a basic "here's what I'm going to ask you for, what do you think about it before negotiation begins" but it already takes long enough to acquire the SAs and I'd rather not delay it any more. Since we have a mechanism to deal with this issue I'm even more hesitant to change anything. [Baiju V. Patel] Agreed. Dan. P.S. You could use SKIP's algorithm discovery protocol to probe the peer for what he supports! > With ISAKMP/Oakley, we have a choice of requiring PFS. However, it does > not provide any means of negotiating PFS. > > So, if initiator would prefer that PFS is not a requirement, but will > accommodate responders desires for PFS, there is no easy way of communicating > this to the responder. > > In this situation, initiator has no choice but to require PFS. If it does > include KE in the phase 2 message, responder will assume that PFS is required > by initiator. If it does not include KE in the message, and responder > requires PFS, phase 2 fails. > > It is my opinion that as part of the ISAKMP/Oakley SA negotiation, the > requirements for PFS must be negotiated. So that before starting phase 2, > the communicating peers know each others requirements for PFS and agree upon > on that is acceptable to both. From owner-ipsec Fri Oct 3 18:54:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23183 for ipsec-outgoing; Fri, 3 Oct 1997 18:53:28 -0400 (EDT) Message-ID: <01BCD016.14673FA0.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'Daniel Harkins'" Cc: "'ipsec'" Subject: RE: Comments on ISAKMP and Oakley resolution document. Date: Fri, 3 Oct 1997 15:29:59 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, thanks for the clarifications. Baiju -----Original Message----- From: Daniel Harkins [SMTP:dharkins@cisco.com] Sent: Friday, October 03, 1997 10:04 AM To: baiju@mailbox.jf.intel.com Cc: 'ipsec' Subject: Re: Comments on ISAKMP and Oakley resolution document. Baiju, > 1. Is the value SAp in HASH_I the SA payload as sent by the initiator and > SAp in HASH_R the SA payload sent by the responder? It seems like many > people have implemented there ISAKMP/Oakley with above interpretation. > However, SAp defined in section 3.2 clearly states that it is SA payload > sent by the initiator. > > Could someone please clarify this? The whole point of including SAp in the hash is to prevent a man-in-the-middle attack against the initial offer (which would otherwise be unauthenticated). If the responder only included his response it would not preclude such an attack (and would, in fact, be pointless). So, as defined in the draft, SAp is the entier body of the SA payload sent by the initiator. If anyone implemented otherwise they wouldn't interoperate and judging by the very high degree of ISAKMP interoperability at the last IPSec bakeoff I think everybody is doing it this way. > 2. Examples of phase 1 (e.g., section 5.8.1) shows SPI to be 8 bytes. Since > SPI has no interpretation (that I know of) in phase 1, SPI size should be > set to 0 and SPI field should not exist. Many implementations ignore non-zero > SPI's. However, there is no reason to show something in the example that is > not required. I've removed that but I know of implementations which send 8 bytes of zero. You can say that that is pointless (and I wouldn't argue with you) but some do and you shouldn't barf if they send it to you. > 3. In section 5.4 > HASH(1) is the prf over the message id (M-ID) from the ISAKMP > header concatenated with the entire message that follows the hash > including all payload headers, but excluding any padding added for > encryption. > > Gives an impression that somehow header (not just MID should be included in > the HASH(1). Also, it gives an impression that if you took MID, and rest > of the payload (excluding padding) and computed hash you will be all set. > After reading this, any optional payloads were transmitted with the message, > they will also be included in the hash computation. > > At the same time, HASH(1) is defined as > > HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) > > Which clearly says that different payloads of ISAKMP/Oakley must be hashed > in a particular order (not necessarily the order of transmission of these > payloads). One of the two definitions need to be changes. This definition > excludes anything except what is specified. One of the two need to be > fixed. Same comments hold for HASH(2) description. The "entire message following the hash" cannot include the header because the header precedes the hash. If you can think of a better way to describe this please let me know. The contents of HASH(1) (and HASH(2) too) are defined in text. The illustration is "for the above exchange". The draft only states that the HASH payload must be first and IDui must precede IDur, not that any of the other payloads have any specific order. The illustration is just that. If you send the KE before the nonce then you should hash the "entire message following the hash" into HASH(1) and that message would have the KE before Ni. Your impression is correct. If you took the M-ID and the rest of the payload (excluding the padding) and computed the hash you would be all set. I'll add "nothing in this illustration should be construed as mandating a particular order to payloads outside that already specified in this draft" if it will dispell this belief. Dan. From owner-ipsec Fri Oct 3 19:23:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23306 for ipsec-outgoing; Fri, 3 Oct 1997 19:22:56 -0400 (EDT) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" Subject: Expiry based on traffic (kilobytes) Date: Fri, 3 Oct 1997 15:18:16 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that the wording surounding how to expire an SA based on traffic should be clearified. While one can use common sense to figure out this issue for an Oakley SA, the IPSec SA is trickier. The problem is how does the traffic get counted. [1] Do we add all of the IP packet, or just the section that the SA secured (since an IP packet might have more than one SA transform it). [2] Do we also add up the byte count from incoming packets? [3] If so, do we count all of the packet, or just the section that was protected by the SA? From owner-ipsec Fri Oct 3 19:33:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23359 for ipsec-outgoing; Fri, 3 Oct 1997 19:32:57 -0400 (EDT) From: Cheryl Madson Message-Id: <199710032343.QAA28024@trix.cisco.com> Subject: Re: Expiry based on traffic (kilobytes) To: rpereira@TimeStep.com (Roy Pereira) Date: Fri, 3 Oct 1997 16:43:05 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: from "Roy Pereira" at Oct 3, 97 03:18:16 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I think that the wording surounding how to expire an SA based on traffic > should be clearified. While one can use common sense to figure out this > issue for an Oakley SA, the IPSec SA is trickier. > > The problem is how does the traffic get counted. > > [1] Do we add all of the IP packet, or just the section that the SA > secured (since an IP packet might have more than one SA transform it). I just count the section that the SA secured. > [2] Do we also add up the byte count from incoming packets? I do, to get a general indication of the volume for a pipe where traffic is greater in one direction than the other ("I'm using this key this much") . But because of potential packet loss on the net, your figure may not be "accurate" w.r.t. the sender. > [3] If so, do we count all of the packet, or just the section that was > protected by the SA? > Just the section that the SA secured. - C From owner-ipsec Sat Oct 4 10:54:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26838 for ipsec-outgoing; Sat, 4 Oct 1997 10:47:24 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Stephen Kent'" , "'Daniel Harkins'" , "'Theodore Y. Ts'o'" Cc: "'ipsec@tis.com'" Subject: RE: Internet Drafts -- AH and ESP specs Date: Sat, 4 Oct 1997 10:59:03 -0400 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 Stephen, I'm just wondering if we should be adding anything to the protocol this late, and perhaps this should go in IPSecond? I also don't see why we would wish to send a whole ISAKMP Notify message just to state that we are using replay. Why not just place an attribute in the transform that states "Yes, I'm using replay". This attribute would merely be informational. We once had this "Replay attribute", but it was used for negotiation. But again, I'm against adding anything to the protocol at this late stage. On Friday, October 03, 1997 4:37 PM, Stephen Kent [SMTP:kent@bbn.com] wrote: > Roy, > > The AH and ESP specs call for the receiver to use a NOTIFY to > inform the sender of the receiver's intent to employ anti-replay measures, > so it is not a negotiation. If you look at the last messages on the topic, > dated 8/26 (from Dan Harkins( and 8/28 (from me), the resolution was to > make use of this form of notification (proposed by Dan), and the only > unresolved point was whether to make the transmission of the NOTIFY a MUST > or a SHOULD. > > Steve > > From owner-ipsec Sat Oct 4 15:07:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28033 for ipsec-outgoing; Sat, 4 Oct 1997 15:06:27 -0400 (EDT) Message-Id: <97Oct4.151658edt.11649@janus.tor.securecomputing.com> To: Stephen Kent cc: Roy Pereira , "'ipsec@tis.com'" Subject: Re: Internet Drafts -- AH and ESP specs References: In-reply-to: kent's message of "Fri, 03 Oct 1997 16:37:10 -0400". 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2889.875992591.1@rafael.tornd.securecomputing.com> Date: Sat, 4 Oct 1997 15:16:31 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > The AH and ESP specs call for the receiver to use a NOTIFY to > inform the sender of the receiver's intent to employ anti-replay measures, In which case, this NOTIFY message is *also* missing from the DOI... :-) -- Harald From owner-ipsec Sat Oct 4 16:27:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28342 for ipsec-outgoing; Sat, 4 Oct 1997 16:26:56 -0400 (EDT) Message-Id: <199710042035.QAA29759@coredump.cis.upenn.edu> To: Roy Pereira cc: "'IPSEC Mailing List'" Subject: Re: Expiry based on traffic (kilobytes) In-reply-to: Your message of "Fri, 03 Oct 1997 15:18:16 EDT." Date: Sat, 04 Oct 1997 16:35:29 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , Roy Pereira writes: >[1] Do we add all of the IP packet, or just the section that the SA >secured (since an IP packet might have more than one SA transform it). >[2] Do we also add up the byte count from incoming packets? >[3] If so, do we count all of the packet, or just the section that was >protected by the SA? [1] Just the section that the SA secured; if the SA includes both encryption and authentication, then only the encrypted bytes should be counted. [2] Incoming packets correspond to a different SA (since we have one SA for each direction). You count those for their respective SA. Or did i misunderstand the question ? [3] Same as [1] Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNDaokL0pBjh2h1kFAQGxpgP+JziqHKrx+tUO0T0tLvTenjRaqS1ZtKER HpL99SbixfZ+4S1UA3LmNse5izAXeGdiAr1ZDoS09B5XhkIW47jXF9EDvQ0o32Ce E8qJV6o6ByzaquFj+NtNrSxmRgHwhfAlL4aT1XtdsDimlhx0tBBDWIZ0XtsvGyOw 241P1SQxVPk= =WCIe -----END PGP SIGNATURE----- From owner-ipsec Sun Oct 5 11:43:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02706 for ipsec-outgoing; Sun, 5 Oct 1997 11:35:53 -0400 (EDT) Date: Sun, 5 Oct 1997 17:41:08 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199710051441.RAA14198@ee.technion.ac.il> To: ipsec@tis.com, mcr@sandelman.ottawa.on.ca Subject: Re: change in isakmp/oakley Cc: daw@cs.berkeley.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk A correction and a couple of additional examples: Michael Richardson noted the following typo in a previous message of mine: >>think of 3DES with two keys, i.e ENC(K1, DEC(K2, ENC(K2, data))), as > > Surely, you mean: > ENC(K1, DEC(K2, ENC(K1, data))) > > because DEC(K2, ENC(K2, data)) is the identity function. > Of course, Michael, you are right. Thanks! Dave Wagner (thanks Dave!) has pointed out to me the relevance of related-key attacks (see his paper with Kelsey and Schneier in Crypto'96) to the scenario that we are discussing in isakmp/oakley. In common use of block-ciphers for encryption many of these attacks are impractical since they can easily be avoided by a reasonable choice of keys. However, when part of the key might have been chosen by the attacker the story is a very different one. That's the story that we need to solve here. As Dave notices some of these attacks (in particular for 3DES) become applicable here. I can add a similar remark concerning weak keys. Recently there was a discussion as for whether one needs to check for weak keys in 3DES. Many pointed out that such a check is unnecessary since the probability to pick such a key is negligible. They were right, since the assumption was that the party interested in the security chooses them at random. But what about the attacker choosing part of the key? As an example consider an extremely secure block cipher (or keyed hash for this ppurpose) that uses 256 bit keys, but it has a "negligible" set of weak keys: whenever the 128 right-most bits of the key are zeros the function becomes the identity function. Is this a problem? Usually not. For a randomly chosen key to fall in that set the probability is 2^{-128}. However, what if the first half is Ni and the second half is Nr? Clearly, the attacker can choose Nr=0! Well, hope this adds some clarity to my previous sketchy arguments. Hope also that it convinces somebody to make the (small) required change to the spec. Hugo From owner-ipsec Sun Oct 5 13:02:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03059 for ipsec-outgoing; Sun, 5 Oct 1997 13:00:25 -0400 (EDT) Message-Id: <199710051707.NAA18206@postal.research.att.com> To: Hugo Krawczyk cc: ipsec@tis.com, mcr@sandelman.ottawa.on.ca, daw@cs.berkeley.edu Subject: Re: change in isakmp/oakley Date: Sun, 05 Oct 1997 13:07:01 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave Wagner (thanks Dave!) has pointed out to me the relevance of related-key attacks (see his paper with Kelsey and Schneier in Crypto' 96) to the scenario that we are discussing in isakmp/oakley. In common use of block-ciphers for encryption many of these attacks are impractical since they can easily be avoided by a reasonable choic e of keys. However, when part of the key might have been chosen by the attacker the story is a very different one. That's the story that we need to so lve here. As Dave notices some of these attacks (in particular for 3DES) become applicable here. Maybe I'm missing something, but in this case the attacker is the other party to the conversation -- who by definition will know the full key. Unless your attack endangers the long-term public key, I fail to see its relevance. From owner-ipsec Sun Oct 5 14:16:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03478 for ipsec-outgoing; Sun, 5 Oct 1997 14:13:56 -0400 (EDT) Message-Id: <199710051823.LAA21468@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Hugo Krawczyk Cc: ipsec@tis.com, mcr@sandelman.ottawa.on.ca, daw@cs.berkeley.edu Subject: Re: change in isakmp/oakley In-Reply-To: Your message of "Sun, 05 Oct 1997 17:41:08 +0300." <199710051441.RAA14198@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 05 Oct 1997 11:23:16 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo, I might be missing something here but if you consider a participant in the exchange an "attacker" then aren't all bets off? He can just leak the key directly instead of choosing a "weak" component (like one of the nonces) of a key. If I want a 3rd party to be able to decrypt our conversation I'll probably just tell her the key instead of choosing a weak key component to allow her to spend significantly less resources cracking our key (but still have to spend a significant amount of resources). Dan. > Dave Wagner (thanks Dave!) has pointed out to me the relevance of > related-key attacks (see his paper with Kelsey and Schneier in Crypto'96) > to the scenario that we are discussing in isakmp/oakley. > In common use of block-ciphers for encryption many of these attacks > are impractical since they can easily be avoided by a reasonable choice of keys. > However, when part of the key might have been chosen by the attacker > the story is a very different one. That's the story that we need to solve > here. As Dave notices some of these attacks (in particular for 3DES) > become applicable here. > > I can add a similar remark concerning weak keys. Recently there was a > discussion as for whether one needs to check for weak keys in 3DES. > Many pointed out that such a check is unnecessary since the probability > to pick such a key is negligible. They were right, since the assumption > was that the party interested in the security chooses them at random. > But what about the attacker choosing part of the key? > > As an example consider an extremely secure block cipher > (or keyed hash for this ppurpose) that uses 256 bit keys, > but it has a "negligible" set of weak keys: whenever the 128 > right-most bits of the key are zeros the function becomes the > identity function. > Is this a problem? > Usually not. For a randomly chosen key to fall in that set the probability > is 2^{-128}. > However, what if the first half is Ni and the second half is Nr? > Clearly, the attacker can choose Nr=0! > > Well, hope this adds some clarity to my previous sketchy arguments. > Hope also that it convinces somebody to make the (small) > required change to the spec. > > Hugo From owner-ipsec Sun Oct 5 17:43:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04243 for ipsec-outgoing; Sun, 5 Oct 1997 17:40:57 -0400 (EDT) Date: Sun, 5 Oct 1997 17:50:53 -0400 Message-Id: <199710052150.RAA13929@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: A little document editing nit.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been informed by a little bird that a certain member on the IESG (not our esteemed Security AD) has a habit of voting Discuss on documents who contain definitions of MUST, SHOULD, MAY, etc. instead of referencing RFC 2119. The stated rationale that is given is that IETF standards ought to be using a consistent meaning for these words, and the best way to do this is to define them by reference instead of having each document define them explicitly. Personally, I think this is a little bit silly (as long as the definitions are consistent, who cares whether they are incorporated by value or by reference), but in the interests of avoiding some last minute frustration and delay, document editors of all IPSEC documents are hereby strongly encouraged to replace definitions of MUST, SHOULD, MAY, etc. with text that reads something like this: NB: 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]. Many, but not all of the ipsec drafts already reference RFC-2119. If you are a document editor, please check your documents and make sure that if your document uses MUST, SHOULD, MAY, etc. that you reference RFC-2119. Thanks!! - Ted From owner-ipsec Sun Oct 5 18:02:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04380 for ipsec-outgoing; Sun, 5 Oct 1997 18:02:22 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 5 Oct 1997 18:12:41 -0400 To: Roy Pereira From: Stephen Kent Subject: RE: Internet Drafts -- AH and ESP specs Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, As I mentioned in the messages that I cited, this is not new. Dan Harkins suggested the use of a NOTIFY for this purpose almost 6 weeks ago. I was surprized that it didn't make it into the latest DOI, which I looked at just this week. There are other things "missing" from the DOI, which were discussed in Munich. For example, the architecture document, going as far back as its predecessor (authored by Ran last November), calls for several forms of SA granularity that are not currenetly supported. Derrell and I spoke briefly about this in Munich after the WG meeting and I expected the new DOI would incorporate new facilities to support these selectors. But that too slipped through the cracks. I'm not blaming Derrell, I'm just pointing out that there are some loose ends to be tied down and the matter I have raised is not new. Steve >I'm just wondering if we should be adding anything to the protocol this >late, and perhaps this should go in IPSecond? > >I also don't see why we would wish to send a whole ISAKMP Notify message >just to state that we are using replay. Why not just place an attribute >in the transform that states "Yes, I'm using replay". This attribute >would merely be informational. We once had this "Replay attribute", but >it was used for negotiation. > >But again, I'm against adding anything to the protocol at this late >stage. From owner-ipsec Sun Oct 5 18:57:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04579 for ipsec-outgoing; Sun, 5 Oct 1997 18:56:21 -0400 (EDT) Message-ID: <34381D60.167E@cs.umass.edu> Date: Sun, 05 Oct 1997 19:06:08 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: isakmp-oakley cookie notation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd like to suggest that an explanation of the notation CKY-I, CKY-R be added to the isakmp-oakley draft. Currently these only seem to appear in the document in the equations for some value computations, but not in any accompanying text. The text from the Oakley draft is: Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random numbers. The generation method must ensure with high probability that the numbers used for each IP remote address are unique over some time period, such as one hour. -Lewis From owner-ipsec Mon Oct 6 06:52:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA07990 for ipsec-outgoing; Mon, 6 Oct 1997 06:49:48 -0400 (EDT) Date: Mon, 6 Oct 1997 12:54:51 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199710060954.MAA24133@ee.technion.ac.il> To: dharkins@cisco.com, smb@research.att.com Subject: Re: change in isakmp/oakley Cc: daw@cs.berkeley.edu, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve and Dan both have a similar question > Maybe I'm missing something, but in this case the attacker is the other > party to the conversation -- who by definition will know the full key. Here is an example scenario: 1) an excellent block cipher with security of (at least) 128 bits and keys of length 256 is used as a prf. The only "weakness" known for the cipher is that keys with the last half bits fixed to zero act as the identity function (or any other insecure transformation of the data). [As said in my previous message this is NO real weakness for a block cipher, keyed-hash or prf.] 2) encryption mode of isakmp/oakley is used with this prf. Nonces are defined to be 128 bits each in this case. The key SKEYID to the prf as currently defined is Ni|Nr (concatenation of the nonces) 3) I is willing to initiate a key exchange with R using the legitimate public key of R denoted pk_R. (For simplicity we can assume aggressive mode but it is not essential for the example; also notice that I describe below only the minimal information relevant to the attack) I chooses a random 128-bit Ni and cookie CKY-I and sends to R: pk_R and CKY-I (as well as g^xi, etc). The message is intercepted by Eve who responds to I (claiming to be R) in the following way: Eve chooses Nr=0...0 and a random value CKY-R. Sends pk_I and CKY-R to I. Even if she DOES NOT KNOW Ni she can compute SKEYID = prf(Ni|Nr, CKY-I | CKY-R) = prf(Ni|0, CKY-I | CKY-R) = CKY-I | CKY-R (notice that here we use that Nr=0 and that this results in the identity function, and that the values of the cookies are public!) Knowing SKEYID Eve succeeds in impersonating R without having any idea on the value of R's public key. She just needs to reply with HASH_R =prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) which depends on SKEYID, that she knows, and the other public information. Makes sense now? I hope this help clarifying some of the issues. In the above attack the attacker does not need to learn anything about Ni. As I hinted to in a previous message, more sophisticated attacks can be though of where the attacker learns some information about Ni (even without knowing pk_R) by replying an encryption of Ni produced by I and getting back information on some value Ni|Nr'. As my philosophical remark of the day, let me stress that it is a big mistake to design cryptography solely based on the *absence* of a "practical enough" attack today. The only way to design good cryptography for the years to come is to have a good analytical basis on which to claim the security. Since I need the mixing of Ni and Nr to provide that analysis, then the mixing should be there. The examples of attacks that I give are for illustration only, not intended as the *exhaustive* listing of all the possible attacks. (A list which I do not know myself!) And, yes, I know, it breaks a couple of implementations of the encryption mode. So repair them. No big deal. (Do not forget that security-wise the encryption mode provides the best advantages. Especially, the *combined* hardness of DH and of PK encryption. So we better do it right.) Hugo PS: 1) If anyone wants an even better solution than mixing at a higher editorial/implementation cost, I can offer that to you: do not mix; just use unidirectional SKEYID keys: SKEYID-I and SKEYID-R (using Nr and Ni respectively). Now all the derivatives _e _a _d are unidirectional too. And that can only help security. But I know it is too late now to do that, as it was too late 2 years ago too... 2) it just occured to me that the attack described above would be much harder with the revised encryption mode, since there Eve will need knowledge of pk_R to learn the value g^xi involved in the computation of HASH-R. Just another example on the benefits of this mode. 3) Dan: I notice that the draft uses the symbol g^xy to denote the DH key. But it uses g^xi and g^xr to denote the individual exponents. Some clarification (or change of notation) is needed. From owner-ipsec Mon Oct 6 10:29:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09640 for ipsec-outgoing; Mon, 6 Oct 1997 10:28:32 -0400 (EDT) Message-Id: <2.2.32.19971006143901.006c7b14@pop.erols.com> X-Sender: tbartee@pop.erols.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Oct 1997 10:39:01 -0400 To: ipsec@tis.com From: Thomas Bartee Subject: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk This is in response to Ran Atkinson's comments on my SA-SPI note. First, I did not propose a specific change in the DOI standard. I was simply adding some information concerning security categories and their usage. Further, I specifically said I appreciate the need to "crash out" current drafts. At this point in time people will almost surely a) support their software even if it is clear improvements might be made, and, b) resist any change that might invoke a delay. We are all hoping the IPSEC will be a big success and the e-mail comments I have seen tend to be constructive. IPSEC is building on TCP/IP in support of which I played an early (and I'd like to think important) role when its use was hotly contested. Given the information in the note I wrote plus what follows, the author(s) of the DOI standard are on their own. First, to make what follows easier to read, let me mention that in an earlier SA-SPI note I pointed out that "Security Categories" are of two types "Release Categories" and "Restrictive" or "Compartment" categories and that these are different. I also pointed out that both can be readily represented in bit maps but that operating procedures for both are different and so programs must know which is being processed. I further pointed out that the DOI has a single field called Security Categories in which either type of category could be placed (or both) and that this might lead to problems if implementers used different strategies. Now, in Ran Atkinson's note he seems to acknowledge the existence of both types of category but called the release category a "rat's nest" which can be endlessly discussed. This is, of course, his opinion: no supporting evidence is given, so I have written the following short response to Ran in defense of "Release Categories" and their associated "Release Markings." The current IEEE (802) LAN security standard has both Release Categories and Compartment (Restrictive) Categories in separate fields as does the National Institute for Standards and Technology "Security Label for Information Transfer (FIPS PUB 188.) The US Government Military Standard also has both Release and Compartment (Restrictive) categories in separate fields, as does the CIPSO. There appears to be no standard with one and not with the other. The new US Government Orders and the new US Security Directives have very explicit Release Categories (markings), as did earlier versions. There are hundreds of thousands (and probably millions) of documents around bearing release markings and these regularly traverse networks. Like it or not, companies continue to release information to specific subcontractors, and, for example, Biotechs and Pharmaceuticals continue to release specific test results to the FDA. Further, Release Markings and the Release Category are probably easier to understand and use than compartment markings. We simply release to whomever we think appropriate. "Release to Canada" and "Release to France" seem logically straightforward as do "Release to Biogen" and "Release to FDA." Finally, let me again note that the current DOI has a single field containing security "categories." It does not specify which kind of category, leaving implementers to do as they will with the bit map, using it for either type of category, or for both. This could lead to compatibility problems or possible misuse of the field. Since there are so many standards containing both and so many users who are familiar with two category types, this possibility seems real. This may not be the time to decide on a fix because of the obvious short-term software protective problems, but I think the subject should clearly be discussed for further versions. The above is intended as informative and is hopefully useful. It does not contain a specific proposal. As Jack Webb often said "Just the facts, Mam." From owner-ipsec Mon Oct 6 12:34:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10475 for ipsec-outgoing; Mon, 6 Oct 1997 12:30:00 -0400 (EDT) Message-Id: <3.0.32.19971006093951.00939c40@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 06 Oct 1997 09:39:52 -0700 To: angelos@dsl.cis.upenn.edu From: John Burke Subject: Re: Expiry based on traffic (kilobytes) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, There is a further complication in IPSEC SA's established by ISAKMP: the SA's are unidirectional but ISAKMP only negotiates one bi-directional set of values. We can presume I suppose this means the same lifetime byte limit goes on both unidirectional SA's, but it seems to me it should be made explicit in ISAKMP, or rather in the IP DOI. John B. At 04:35 PM 10/4/97 EDT, Angelos D. Keromytis wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >In message timestep.com>, Roy Pereira writes: >>[1] Do we add all of the IP packet, or just the section that the SA >>secured (since an IP packet might have more than one SA transform it). >>[2] Do we also add up the byte count from incoming packets? >>[3] If so, do we count all of the packet, or just the section that was >>protected by the SA? > >[1] Just the section that the SA secured; if the SA includes both >encryption and authentication, then only the encrypted bytes should be >counted. > >[2] Incoming packets correspond to a different SA (since we have one >SA for each direction). You count those for their respective SA. Or >did i misunderstand the question ? > >[3] Same as [1] > >Cheers, >- -Angelos > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: noconv >Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > >iQCVAwUBNDaokL0pBjh2h1kFAQGxpgP+JziqHKrx+tUO0T0tLvTenjRaqS1ZtKER >HpL99SbixfZ+4S1UA3LmNse5izAXeGdiAr1ZDoS09B5XhkIW47jXF9EDvQ0o32Ce >E8qJV6o6ByzaquFj+NtNrSxmRgHwhfAlL4aT1XtdsDimlhx0tBBDWIZ0XtsvGyOw >241P1SQxVPk= >=WCIe >-----END PGP SIGNATURE----- > > From owner-ipsec Mon Oct 6 13:08:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10756 for ipsec-outgoing; Mon, 6 Oct 1997 13:07:58 -0400 (EDT) From: Cheryl Madson Message-Id: <199710061717.KAA02490@trix.cisco.com> Subject: Re: Expiry based on traffic (kilobytes) To: jburke@cylink.com (John Burke) Date: Mon, 6 Oct 1997 10:17:47 -0700 (PDT) Cc: angelos@dsl.cis.upenn.edu, ipsec@tis.com In-Reply-To: <3.0.32.19971006093951.00939c40@192.43.161.2> from "John Burke" at Oct 6, 97 09:39:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Angelos, > > There is a further complication in IPSEC SA's established by ISAKMP: the > SA's are unidirectional but ISAKMP only negotiates one bi-directional set > of values. We can presume I suppose this means the same lifetime byte > limit goes on both unidirectional SA's, but it seems to me it should be > made explicit in ISAKMP, or rather in the IP DOI. > > John B. > I've always treated it where the SAs which are created together are siblings, they will share the same lifetime, and they will die together, regardless of what causes one SA to terminate (aging, clearing of part of the SADB, or any unnatural causes). To me, this belongs in the security architecture document... - C From owner-ipsec Mon Oct 6 18:29:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12918 for ipsec-outgoing; Mon, 6 Oct 1997 18:26:06 -0400 (EDT) From: Dan McDonald Message-Id: <199710062236.PAA20141@kebe.eng.sun.com> Subject: Re: Expiry based on traffic (kilobytes) To: ipsec@tis.com Date: Mon, 6 Oct 1997 15:36:31 -0700 (PDT) In-Reply-To: <199710061717.KAA02490@trix.cisco.com> from "Cheryl Madson" at Oct 6, 97 10:17:47 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > There is a further complication in IPSEC SA's established by ISAKMP: the > > SA's are unidirectional but ISAKMP only negotiates one bi-directional set > > of values. We can presume I suppose this means the same lifetime byte > > limit goes on both unidirectional SA's, but it seems to me it should be > > made explicit in ISAKMP, or rather in the IP DOI. > > > > John B. > > > > I've always treated it where the SAs which are created together are > siblings, they will share the same lifetime, and they will die > together, regardless of what causes one SA to terminate (aging, > clearing of part of the SADB, or any unnatural causes). Hmmm, I dunno about linking SA pairs so close at the hip. Consider the bulk-transfer case where one SA gets its bytes lifetime depleted considerably faster than the other SA. Sure, the subsequent renegotiation may create additional pairs, but that's no reason to kill the one that hasn't expired yet. If there's an issue of time, slap a time limit along with the bytes. Whichever one (too much time or too many bytes) hits first kills the SA. BTW, I have to say that one should count bytes "treated" by an SA, not "untreated" bytes. For AH, this includes whole packets. For ESP, this includes only the ESP header and ESP data. Just my $0.02 on this. Dan From owner-ipsec Tue Oct 7 02:36:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA15483 for ipsec-outgoing; Tue, 7 Oct 1997 02:34:20 -0400 (EDT) Message-Id: <199710070649.CAA15157@relay.hq.tis.com> Date: Tue, 7 Oct 97 2:32:35 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec Architecture -- proposed changes Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In response to discussions at Munich and later comments from the working group, here's a list of proposed changes for the IPsec Architecture document. (It does not include minor edits -- typos, simple clarifications, address changes, etc.) Many of these items are offered for discussion and are not meant to be a final resolutions drawn from mailing list consensus. Please let us know by 10/13 of any issues we've missed and any feedback you have on the items below. Thank you, Karen ============================================================================= 1. Which documents should contain references to current default algorithms (mandatory-to-implement)? We currently have: - AH mandatories in AH, Arch (and DOI). - ESP mandatories in ESP, Arch (and DOI). Per discussion on 7/22 between Rodney Thayer, Ted Tso... We propose to leave the references in the AH, ESP, and Architecture documents. ============================================================================= 2. How should we handle the security gateway problem -- discovery of the security gateway, verification of its authenticity and authorization, etc.? Per discussion at Munich IETF... In section 4.6.3 "Locating a Security Gateway", we propose to: - remove the [NOTE: This topic is still under discussion...] on page 18. - leave the problem description in place (pages 18-19) - remove the rest of the section and replace it with: "To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure: o the SAs to use for a communication association to the destination host. In the example above, this would mean a tunnel mode SA from H1 to SG1 and a transport mode SA from H1 to H2. o the SAs to use if the path to the destination host fails. In the example above, this would mean a tunnel mode SA from H1 to SG2 and a transport mode SA from H1 to H2. o the requisite information for locating, authenticating and verifying the authorization of the relevant security gateways. In the example above, the relevant security gateways would be SG1 and SG2. This document does not address the issue of how to automate the discovery/verification of security gateways." ============================================================================= 3. How should we handle MLS issues? Per discussion at the Munich IETF and following up on email to the list (8/19, Steve Kent), we propose to defer this problem to another document that will be issued later. The following text will be included in Section 10. "Use in systems supporting information flow security": "The use of IPsec in an MLS environment imposes additional requirements on IPsec implemntations. A separate document will address these requirements." ============================================================================= 4. Clarification about using a different SPI when a new SA is created because of rekeying... Following up on discussion on the mailing list (8/6, Bill Sommerfeld, Catherine Gibson, Dan McDonald), we propose to include text in the section 4.6 "SA Establishment", before 4.6.1 "Manual Techniques" and 4.6.2 "Automatic Techniques -- Key Mgt Protocol Requirements" that says: "The rekeying of an SA implies creation of a new SA with a new SPI." ============================================================================= 5. Should the IPsec architecture enable an application, which is using a single socket to communicate with multiple peers, to use different security policies for different peers? From observations by Charlie Lynn -- "UDP sockets may, and do, switch destination addresses on a packet by packet basis. SAs would also have to correspondingly change on a packet by packet basis based on the packet's destination (and maybe other things)...People are already thinking about how applications might specify security policy requirements, e.g., the 8/1/97 draft-metz-net-security-api-00.txt, "Network Security API for Sockets." To address this concern, we propose to add the following text to section 4.4.1, "Security Policy Database", paragraph 3, after sentence 1. "This interface must allow the user/application to specify a set of policies that can be invoked on a packet by packet basis for a single socket, e.g., for UDP traffic. Also, the system administrator MUST be able to specify whether or not a user/application can circumvent system policies." ============================================================================= 6. Should AH/ESP be a selector? What should this selector be called? Per suggestion from Charlie Lynn, we propose that AH and ESP be allowed as selector inputs, and that the name for this selector be "IPsec Protocols". A new selector paragraph will be added to section 4.4.3 "Selectors": "IPsec protocol (AH or ESP or AH/ESP): If present, this is obtained from the IPv4 "Protocol" field or the IPv6 "Next Header" field. [REQUIRED for all implementations] NOTE: These fields could contain a Transport Protocol, Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. And while IPv6 recommends a particular order for extension headers, it also specifies that the implementation must be prepared to accept them in any order. So to check for the existence of an IPsec header, a system has to chain through the packet headers checking the Protocol/Next Header field until it has checked all that are not opaque." ============================================================================= 7. Should the "Transport Protocol" selector be required only for systems supporting IPv6, and be optional for IPv4? Per suggestion from the working group and given the proposal to add IPsec protocol as a selector (see above), we propose to modify the Transport Protocol paragraphs of section 4.4.3 "Selectors" as follows: - At the end of the paragraph on "Transport Protocol", change "[REQUIRED for all implementations]" to "[REQUIRED for IPv6 implementations, MAY be supported in IPv4 implementations] - Change the first Transport Protocol paragraph by rewording the first 2 sentence and deleting the last 3 sentences. Leave the second paragraph as is. This results in: "Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. These fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. [REQUIRED for all implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Next Protocol" field until it encounters either one it recognizes as a transport protocol or until it reaches one that isn't on its list of extension headers." ============================================================================= 8. Additional selector changes -- adding TOS and renaming IPv6 "Priority" to "Class". Based on discussion at the Munich IETF, we propose to add TOS for IPv4 as a selector and change the IPv6 Priority field to "Class" to match the IPv6 spec. This involves changing Section 4.4.3 "Selectors" by: Adding the text: "IPv4 Type of Service (TOS): Obtained from IP header [REQUIRED for all systems that implement IPv4]" Changing "IPv6 Priority..." to "IPv6 Class..." ============================================================================= 9. Additional warnings that certain selectors may not always be accessible.... Per suggestion in private email from a working group member, we propose to make the following changes to section 4.4.3 "Selectors": Paragraph 1 (An SA (or SA bundle) may be...) after the third sentence, insert the text: "In the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or bump in the wire implementation, the transport layer protocol and ports may be opaque, thus making them unavailable for use as selectors." Paragraph 9 (Source and Destination (TCP/UDP) Ports...) at the end, add the text: "Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header." The proposed paragraph from item (7) on "Transport Protocol", add the text: "Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header." ============================================================================= 10. How should we handle header copying in tunnel mode? Per discussion at the Munich IETF, we propose to use an approach similar to that described in RFC 2003 "IP Encapsulation with IP". This RFC minimizes the complexity of this problem by generally not copying options, e.g., source routing. Since RFC 2003 does not address IPv6 and to avoid having to worry about the text in RFC 2003 that is not needed by the IPsec architecture document, we propose to write text that is modeled after RFC 2003 rather than to simply refer the reader to RFC2003. ICMP processing -- Section 6.1.1 DF bit and 6.1.2 Path MTU Discovery, leave text as is. Appendix B "Analysis/Discussion of PMTU/DF/Fragmentation Issues", leave text as is. Inbound processing -- Section 5.2 "Processing Inbound IPsec Traffic, add the text: "The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be done as described in the tables in Section 5.1. Outbound processing -- Section 5.1.2 "Header construction for tunnel mode", o Delete the first (parenthetical) paragraph, "There are a variety..." o Replace the rest of the section with: "This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP": - The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. - The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. - No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. - If need be, other protocol headers such as the IP Authentication header [1] may be inserted between the outer IP header and the inner IP header. The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner): 5.1.2.1 IPv4 -- Header construction for tunnel mode <-------- How Outer Hdr Relates to Inner Hdr ---------> IPv4 Outer Hdr at Encapsulator Inner Hdr at Decapsulator Header fields version 4 or 6 (1) no change header length constructed no change TOS copied from inner hdr no change total length constructed no change ID constructed no change flags (DF,MF) constructed, DF copie no change fragmt offset constructed no change TTL copy from inner header (2) copy from outer hdr (2) & decrement before forwarding decrement before forwarding protocol AH, ESP, routing hdr no change checksum constructed no change src address constructed (3) no change dest address constructed (3) no change Options never copied no change 1. The IP version in the encapsulating header can be different from the value in the inner header. 2. In order to support dynamic (rather than manual) set up of tunnels, the TTL (or hop count) must be processable by the receiver without requiring coordination with the sender, etc. In particular multicast traffic should not require preconfigured tunnels. The TTL (or hop count) is decremented at each hop in the tunnel as well as at the encapsulator and decapsulator. 3. src and dst addresses depend on the SA, which is used to determine the dst address which in turn determines which src address (net interface) is used to forward the packet. 5.1.2.2 IPv6 -- Header construction for tunnel mode See previous section 5.1.2 for notes indicated by (#). <-------- How Outer Hdr Relates to Inner Hdr ---------> IPv6 Outer Hdr at Encapsulator Inner Hdr at Decapsulator Header fields: version 6 no change priority copy or configure no change flow id copy or configure no change len construct no change next header AH,ESP,routing hdr no change hop count copy from inner hdr (2) & copy from outer hdr (2) & decrement before forwarding decrement before forwarding src address constructed (3) no change dest address constructed (3) no change Extension headers never copied no change ============================================================================= 11. Multicast clarification. Following up on discussion at the Munich IETF, we propose to modify Section 4.7 "Security Associations and Multicast": a) delete the last 2 sentences of paragraph 2, which describe the case of using asymmetric cryptographic algorithsm. b) replace the third paragraph with "Other cases of multicast will be addressed in other documents." ============================================================================= 12. How should we ensure interoperable mapping of key material to keys? We propose adding the following text to Section 4.6.2 "Automatic Techniques -- Key Mgt Protocol Requirements" "Multiple keys may be needed for a single ESP SA, either because the encryption algorithm uses multiple keys (e.g., triple DES) or because both encryption and authentication algorithms are employed. The Key Management System may provide a seprate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption keys MUST be taken from the first (left-most, high-order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys, the specification for the encryption algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm." ============================================================================= 13. In *TRANSPORT MODE*, allowing arbitrary ordering of IPsec headers. Following up on the mailing list discussion on nesting IPsec headers (8/22 to 8/30), we propose to modify the Architecture document by: a) Adding a section in Outbound Processing --> 5.1.3, "Header nesting for transport mode" that says: "If more than one IPsec header/extension is required: o the order of nesting of the security headers MUST be defined by security policy o The following 3 cases MUST be supported: 1. [IP][AH][upper] 2. [IP][ESP][upper] 3. [IP][AH][ESP][upper] o arbitrary nesting is allowed -- Senders MAY generate arbitrary nestings of IPsec headers and Receivers SHOULD accept arbitrary nestings of IPsec headers. Support for arbitrary nesting requires that implementations ensure that any mutable "AH protected" fields outside/above the AH header, i.e., IP length, IP Next Protocol and any IPsec headers, are appropriately handled by Outbound and Inbound processing as the headers are nested and unnested. To ensure interoperability, the implementation should ignore the existence (i.e., neither zero the contents nor try to predict the contents) of IPsec headers to be applied later when o constructing an IPsec header o adjusting the IP length and IP Next Protocol in the IP header or immediately preceding IP extension header This will apply to: [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper] Nesting involving only ESP headers should not be problematic: [IP][ESP][ESP]...[ESP][upper] (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.)" b) In Section 5.2 "Processing Inbound IPsec Traffic", adding the following text: "If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed." ============================================================================= 14. Revision of Section 4. "Security Associations" Following up on discussions at the Munich IETF, subsequent email, etc., this section will be rewritten to: o remove the Security Association Map (section 4.4.2 "Security Association Outbound Processing) from the design because of problems identified by several people on the list. o revise the Selectors section to reconcile the selectors for SAs defined in the IPsec Architecture document, the ID ranges for SAs defined in the IPsec DOI for ISAKMP, and the name forms in certificates. o add the following attributes to the Security Association Database: - Anti-replay window size - Largest valid (has passed ICV check) sequence number seen (receiver only) - Sequence Number counter (sender only) o address the question "Should the architecture allow a single SA to alternate between transport and tunnel mode for different packets?" Following up on email from Dan McDonald (9/21)... "It is my opinion that, while there are processing differences between transport and tunnel modes of IPsec, to explicitly distinguish them as an SA attribute is wrong. They should be "Selectors" in your abstraction of the Security Policy Database. I may wish to use a pair of SAs for both tunnel mode and transport mode simultaneously. The differences between tunnel and transport mode are important, but they should be indicated with respect to processing and policy decision making, rather than be an explicit SA attribute." We propose to: - add IPsec protocol mode (transport or tunnel) to the Security Policy Database (SPD). - remove the "IPsec protocol mode (transport or tunnel)" as an SA attribute from Section 4.4.4 "Security Association Database (SAD)" ============================================================================= 15. Per email from Dan McDonald 9/21... We propose to give GKMP as an example of work in progress for multicast key distribution in section 4.7. However, per IETF requirements for RFCs, we won't be able to formally cite it unless there is an RFC. ============================================================================= 16. Per email from Dan McDonald 9/21... We propose to add a note to the appendix on PMTU/DF processing: "If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments." ============================================================================= 17. Per Dan McDonald 9/21... Text will be added to section 11. "Performance Issues": "The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the 1st packet." ============================================================================= 18. Should the IPsec architecture support enforcement of receiver-specified security policies? Per Charlie Lynn, "There is a need for a mechanism for a receiver to specify what IPsec services MUST be present for a given traffic stream, based on (post-IPsec processing) packet selectors." Per Dan McDonald 9/21, "Consider the security gateway example... -- SG ==(The Internet)== SG' -- ...SG may accept legitimate SA establishment requests from parties other than SG'. If this is so, it is CRUCIAL that SG take care that a malicious party M doesn't use its legitimate SAs to tunnel forged packets from a.b.d.X to a.b.c.Y. A naive SG implementation may say "Oh, it was decrypted, of COURSE I can forward the inner packet" regardless of WHICH PEER SG sent it." [I.e., there's another security gateway SG" which has an SA with SG. And M is behind SG" but pretending to be a host behind SG'.] To address their concerns, we propose to make the following changes o modify section 4.4.1 "The Security Policy Database (SPD)" - end of paragraph 2, add the sentence: "This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. - paragraph 3, 1st sentence, change from "For every IPsec implementation, there MUST be some form of administrative interface...." to "For every IPsec implementation, there MUST be some form of administrative interface for both outbound and inbound traffic ... o include the following text in section 5.2 "Processing Inbound Traffic": "For each packet, its SA attributes (IPsec protocol, etc.) must be recorded to allow them to be checked against the receiver's security policy. Care must be taken to do this for all IPsec headers that are present including those that are nested. After all IPsec processing has been completed, the receiver looks up the packet's selectors in its inbound security policy database and verifies that the required IPsec protection was present in the given packet. If not, it discards the packet." From owner-ipsec Tue Oct 7 02:58:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA15640 for ipsec-outgoing; Tue, 7 Oct 1997 02:58:19 -0400 (EDT) Message-Id: <199710070713.DAA15269@relay.hq.tis.com> Date: Tue, 7 Oct 97 2:59:12 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec mandatory authentication algorithms Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, There's an inconsistency between the AH and ESP specs and the DOI. The AH and ESP specs list 2 mandatory authentication algorithms: - HMAC with MD5 - HMAC with SHA-1 The DOI lists 1 mandatory authentication algorithm: - HMAC with MD5 and 1 "strongly encouraged" authentication algorithm: - HMAC with SHA-1 We pinged Derrell, Bob, and Ted and no particular reason to use one or the other approach turned up. So please let us know which approach you'd prefer (and why) by 10/13. If we don't hear from anyone, we'll make the architecture document match the DOI, i.e., 1 mandatory and one strongly encouraged. Thank you, Karen From owner-ipsec Tue Oct 7 09:30:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18263 for ipsec-outgoing; Tue, 7 Oct 1997 09:27:52 -0400 (EDT) Message-Id: <199710071335.JAA23914@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-01.txt Date: Tue, 07 Oct 1997 09:35:12 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-01.txt Pages : 20 Date : 06-Oct-97 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-v2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971006155500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971006155500.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Oct 7 10:29:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18674 for ipsec-outgoing; Tue, 7 Oct 1997 10:28:55 -0400 (EDT) Message-Id: <97Oct7.103921edt.11650@janus.tor.securecomputing.com> To: ipsec@tis.com Cc: Karen Seo Subject: Re: IPsec mandatory authentication algorithms References: <199710070713.DAA15269@relay.hq.tis.com> In-reply-to: kseo's message of "Tue, 07 Oct 1997 02:59:12 -0400". <199710070713.DAA15269@relay.hq.tis.com> From: "C. Harald Koch" Date: Tue, 7 Oct 1997 10:38:32 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710070713.DAA15269@relay.hq.tis.com>, Karen Seo writes: > Folks, > > There's an inconsistency between the AH and ESP specs and the DOI. If I remember correctly, the original reason for mandating MD5 was backwards compatability with previous implementations. However, with the sequence number field and the new 96-bit truncated digests, we've *completely* broken backwards compatability; the requirement is gone. The cryptographic community appears to have declared MD5 anywhere from suspect to compromised, depending on their level of paranoia. Therefore, I'd recommend making HMAC with SHA-1 *mandatory*, and possibly even specify that it should be preferred when negotiating. Whether or not HMAC with MD5 is also mandatory is less important to me... :-) -- C. Harald Koch From owner-ipsec Tue Oct 7 10:29:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18675 for ipsec-outgoing; Tue, 7 Oct 1997 10:28:56 -0400 (EDT) Message-Id: <97Oct7.103923edt.11652@janus.tor.securecomputing.com> To: ipsec@tis.com Cc: Karen Seo Subject: Re: IPsec Architecture -- proposed changes References: <199710070649.CAA15157@relay.hq.tis.com> In-reply-to: kseo's message of "Tue, 07 Oct 1997 02:32:35 -0400". <199710070649.CAA15157@relay.hq.tis.com> From: "C. Harald Koch" Date: Tue, 7 Oct 1997 10:38:35 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk I like most of the changes, however: In message <199710070649.CAA15157@relay.hq.tis.com>, Karen Seo writes: > > <-------- How Outer Hdr Relates to Inner Hdr ---------> > IPv4 Outer Hdr at Encapsulator Inner Hdr at Decapsulator > Header fields > TTL copy from inner header (2) copy from outer hdr (2) & > decrement before forwarding decrement before forwarding This makes traceroute output look really weird when going through a tunnel. The question is, should a tunnel look like a single IP hop or not? I'm of the VPN religion, and so I believe that tunnels should look like a direct (one hop) link between the two hosts/routers. Comments? > 12. How should we ensure interoperable mapping of key material to keys? > > We propose adding the following text to Section 4.6.2 "Automatic > Techniques -- Key Mgt Protocol Requirements" The replacement text doesn't handle the case where *both* the encryption and authentication algorithms use variable length keys, e.g. RC5 with HMAC-SHA1-96. Currently, none of the auth algorithm documents specify a key length; there's a defacto standard to use the hash algorithm's digest size, but it's not documented anywhere. ISAKMP allows you to negotiate the length of variable keys for encryption, but not for simultaneous authentication. This problem needs to be dealt with *somewhere*; I would put it within the ISAKMP series somewhere. -- Harald Koch From owner-ipsec Tue Oct 7 10:57:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18926 for ipsec-outgoing; Tue, 7 Oct 1997 10:56:22 -0400 (EDT) Date: Tue, 07 Oct 1997 10:56:48 -0400 From: "Freedman, Jerome" Subject: RE: IPsec Architecture -- proposed changes To: ipsec@tis.com, "C. Harald Koch" Cc: Karen Seo Message-id: <8D3B7E46799CCF118D9D00805FE28A1E020480A0@ndhm06.ndhm.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain Content-transfer-encoding: 7BIT X-Priority: 3 Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes >I like most of the changes, however: >In message <199710070649.CAA15157@relay.hq.tis.com>, Karen Seo writes: >> >> <-------- How Outer Hdr Relates to Inner Hdr ---------> > >>IPv4 Outer Hdr at Encapsulator Inner Hdr at > Decapsulator > >> Header fields >> TTL copy from inner header (2) copy from outer hdr (2) & >> decrement before forwarding decrement before forwarding >This makes traceroute output look really weird when going through a tunnel. >The question is, should a tunnel look like a single IP hop or not? I'm of >the VPN religion, and so I believe that tunnels should look like a direct >(one hop) link between the two hosts/routers. >Comments? I'll ad my one cent ( I don't actively participate much but I feel strongly here). I agree. I go to the same VPN church as Mr. Koch. Jerry Freedman, Jr GTE Gov't Systems From owner-ipsec Tue Oct 7 11:41:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19174 for ipsec-outgoing; Tue, 7 Oct 1997 11:40:22 -0400 (EDT) Message-Id: <199710071547.LAA03894@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IPsec Architecture -- proposed changes In-reply-to: Your message of "Tue, 07 Oct 1997 10:38:35 EDT." <97Oct7.103923edt.11652@janus.tor.securecomputing.com> Date: Tue, 07 Oct 1997 11:47:18 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "C" == C Harald Koch writes: C> This makes traceroute output look really weird when going C> through a tunnel. The question is, should a tunnel look like a C> single IP hop or not? I'm of the VPN religion, and so I believe C> that tunnels should look like a direct (one hop) link between C> the two hosts/routers. C> Comments? Okay, which end decrements then? The far end is the one "forwarding" so it should do it. The near end can be thought to be forwarding as well. For diagnostic purposes, I'd rather have both end points. It should be noted that the ICMP reply should have a public address, or router id for it. We have not yet resolved a question I raised awhile ago: how are ICMP's from distant routers (beyond the "far" router) allowed to enter the tunnel? please see: http://www.sandelman.ottawa.on.ca/ipsec/1997/07/msg00022.html and you might recall: http://www.sandelman.ottawa.on.ca/ipsec/1997/07/msg00023.html C> documented anywhere. ISAKMP allows you to negotiate the length C> of variable keys for encryption, but not for simultaneous C> authentication. This problem needs to be dealt with C> *somewhere*; I would put it within the ISAKMP series somewhere. I agree that there is missing text. :!mcr!: | Network security programming, currently Michael Richardson | on contract with SSH IPSEC (http://www.ssh.fi/) WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNDpZhKZpLyXYhL+BAQG0qgMAjinaJj5NHzZ+ObNvuUC7y66XZ1pwzuTW zDDXh1BEkLzUk1xvNS9im+32GVVlIyvhB3WQPqCTULjqQGefU1EV2inxG+KB/l0r pl9TnZOUjTxsSgzTErPQJHhiFXqgP6vi =sX99 -----END PGP SIGNATURE----- From owner-ipsec Tue Oct 7 11:54:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19275 for ipsec-outgoing; Tue, 7 Oct 1997 11:53:54 -0400 (EDT) From: Cheryl Madson Message-Id: <199710071603.JAA20103@trix.cisco.com> Subject: Re: IPsec Architecture -- proposed changes To: chk@utcc.utoronto.ca (C. Harald Koch) Date: Tue, 7 Oct 1997 09:03:58 -0700 (PDT) Cc: ipsec@tis.com, kseo@bbn.com In-Reply-To: <97Oct7.103923edt.11652@janus.tor.securecomputing.com> from "C. Harald Koch" at Oct 7, 97 10:38:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I like most of the changes, however: > > In message <199710070649.CAA15157@relay.hq.tis.com>, Karen Seo writes: > > > > <-------- How Outer Hdr Relates to Inner Hdr ---------> > > IPv4 Outer Hdr at Encapsulator Inner Hdr at Decapsulator > > Header fields > > TTL copy from inner header (2) copy from outer hdr (2) & > > decrement before forwarding decrement before forwarding > > This makes traceroute output look really weird when going through a tunnel. > The question is, should a tunnel look like a single IP hop or not? I'm of > the VPN religion, and so I believe that tunnels should look like a direct > (one hop) link between the two hosts/routers. > > Comments? > The tunnel should have it's own TTL. This is consistent with how other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853 for examples. > > > 12. How should we ensure interoperable mapping of key material to keys? > > > > We propose adding the following text to Section 4.6.2 "Automatic > > Techniques -- Key Mgt Protocol Requirements" > > The replacement text doesn't handle the case where *both* the encryption and > authentication algorithms use variable length keys, e.g. RC5 with > HMAC-SHA1-96. Currently, none of the auth algorithm documents specify a key > length; there's a defacto standard to use the hash algorithm's digest size, > but it's not documented anywhere. ISAKMP allows you to negotiate the length > of variable keys for encryption, but not for simultaneous authentication. > This problem needs to be dealt with *somewhere*; I would put it within the > ISAKMP series somewhere. > Sorry. The auth draft *does* specify it: look at the first paragraph of section 3: 3. Keying Material HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is specified in [RFC-2104], for use with either ESP or AH a fixed key length of 160-bits MUST be supported. A key length of 160-bits was chosen based on the recommendations in [RFC-2104] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength). The same for MD5. These are *not* variable-key-length transforms. There is nothing that suggests that other key sizes are even a MAY, apart from the reader recalling the history of the older AH drafts. I suppose a wordsmith revision could say "this and only this" or something which makes the MUST more of a MUST... ;-). - C From owner-ipsec Tue Oct 7 12:11:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19353 for ipsec-outgoing; Tue, 7 Oct 1997 12:09:25 -0400 (EDT) Message-Id: <97Oct7.122003edt.11653@janus.tor.securecomputing.com> To: Cheryl Madson cc: ipsec@tis.com, kseo@bbn.com Subject: Re: IPsec Architecture -- proposed changes References: <199710071603.JAA20103@trix.cisco.com> In-reply-to: cmadson's message of "Tue, 07 Oct 1997 12:03:58 -0400". <199710071603.JAA20103@trix.cisco.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, 7 Oct 1997 12:19:13 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710071603.JAA20103@trix.cisco.com>, Cheryl Madson writes: > > The tunnel should have it's own TTL. This is consistent with how > other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853 > for examples. Just to be clear, we're agreeing, right? both RFC 2003 and 1853 say that you do *not* copy TTLs from inside to outside, but instead decrement the *inner* TTL when (encapsulating as fowarding) and when (forwarding after decapsulating), which incidentally produces useful traceroute info :-) > Sorry. The auth draft *does* specify it: look at the first paragraph > of section 3: > > 3. Keying Material > > HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is > specified in [RFC-2104], for use with either ESP or AH a fixed key > length of 160-bits MUST be supported. A key length of 160-bits was > chosen based on the recommendations in [RFC-2104] (i.e. key lengths > less than the authenticator length decrease security strength and > keys longer than the authenticator length do not significantly > increase security strength). > > The same for MD5. These are *not* variable-key-length transforms. I understand that *now*, but I didn't until this message. > There is nothing that suggests that other key sizes are even a MAY, > apart from the reader recalling the history of the older AH drafts. I > suppose a wordsmith revision could say "this and only this" or > something which makes the MUST more of a MUST... ;-). In this case I'd change "160-bits must be supported" to "160-bits must be used". "Supported" implies that other key lengths are allowed, which is where I (and others I discussed this with) all went astray. I know it's a nitpick, but it *did* mislead several of us who are familiar with both previous documents *and* with the variable-length keys of the hash algorithms. -- Harald From owner-ipsec Tue Oct 7 12:12:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19359 for ipsec-outgoing; Tue, 7 Oct 1997 12:10:53 -0400 (EDT) Message-Id: <3.0.3.32.19971007121622.00c3f960@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 07 Oct 1997 12:16:22 -0400 To: "C. Harald Koch" , ipsec@tis.com From: Robert Moskowitz Subject: Re: IPsec mandatory authentication algorithms Cc: Karen Seo In-Reply-To: <97Oct7.103921edt.11650@janus.tor.securecomputing.com> References: <199710070713.DAA15269@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:38 AM 10/7/97 -0400, C. Harald Koch wrote: > >The cryptographic community appears to have declared MD5 anywhere from >suspect to compromised, depending on their level of paranoia. Well, actually, I have old messages from Hugo stating that HMAC addresses these concerns. And the workgroup came to the conclusion that HMAC-MD5 and HMAC-SHA1 were equally secure. Then once we truncated both to 96 bits, well is there a difference anymore, other than MD5 is consistantly reported as faster than SHA1... >Therefore, I'd recommend making HMAC with SHA-1 *mandatory*, and possibly >even specify that it should be preferred when negotiating. Thus many of us feel that MD5 is the mandatory, as the SHA1 does not seem to bring technical value. >Whether or not HMAC with MD5 is also mandatory is less important to me... :-) > And I feel the same about SHA1... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Oct 7 12:12:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19379 for ipsec-outgoing; Tue, 7 Oct 1997 12:11:24 -0400 (EDT) Message-Id: <97Oct7.122221edt.11652@janus.tor.securecomputing.com> To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: IPsec Architecture -- proposed changes References: <199710071547.LAA03894@istari.sandelman.ottawa.on.ca> In-reply-to: Your message of "Tue, 07 Oct 1997 11:47:18 -0400". <199710071547.LAA03894@istari.sandelman.ottawa.on.ca> 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, 7 Oct 1997 12:21:28 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710071547.LAA03894@istari.sandelman.ottawa.on.ca>, "Michael C. Richardson" writes: > > Okay, which end decrements then? > The far end is the one "forwarding" so it should do it. > The near end can be thought to be forwarding as well. Agreed, they're *both* forwarding the packet; one into the tunnel, and one out of the tunnel. RFC 2003 specifies good behaviour TTL handling with IP in IP tunneling. > We have not yet resolved a question I raised awhile ago: how are > ICMP's from distant routers (beyond the "far" router) allowed to enter > the tunnel? Agreed :-) -- Harald From owner-ipsec Tue Oct 7 12:29:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19481 for ipsec-outgoing; Tue, 7 Oct 1997 12:26:55 -0400 (EDT) Organization: ESAT, K.U.Leuven, Belgium Date: Tue, 7 Oct 1997 18:35:15 +0200 (METDST) From: Bart Preneel To: Robert Moskowitz cc: "C. Harald Koch" , ipsec@tis.com, Karen Seo Subject: Re: IPsec mandatory authentication algorithms In-Reply-To: <3.0.3.32.19971007121622.00c3f960@dilbert.is.chrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I consider myself to be a member of the cryptographic community, and I seriously question the statement that HMAC-MD5 and HMAC-SHA1 are equally secure. Using HMAC-MD5 is a best a well calculated risk (something like using RSA-512). Remember that only a limited effort has been spent on the cryptanalysis of MD5 (where would we be without Hans Dobbertin?). While it is correct that HMAC requires properties from MD5 that are weaker than collision resistance, that does not imply that it is safe to assume that MD5 has these properties. I would hesitate to use HMAC-MD5 unless I could switch overnight to HMAC-SHA1. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Tue, 7 Oct 1997, Robert Moskowitz wrote: > At 10:38 AM 10/7/97 -0400, C. Harald Koch wrote: > > > >The cryptographic community appears to have declared MD5 anywhere from > >suspect to compromised, depending on their level of paranoia. > > Well, actually, I have old messages from Hugo stating that HMAC addresses > these concerns. And the workgroup came to the conclusion that HMAC-MD5 and > HMAC-SHA1 were equally secure. Then once we truncated both to 96 bits, > well is there a difference anymore, other than MD5 is consistantly reported > as faster than SHA1... > > >Therefore, I'd recommend making HMAC with SHA-1 *mandatory*, and possibly > >even specify that it should be preferred when negotiating. > > Thus many of us feel that MD5 is the mandatory, as the SHA1 does not seem > to bring technical value. > > >Whether or not HMAC with MD5 is also mandatory is less important to me... :-) > > > And I feel the same about SHA1... > > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > From owner-ipsec Tue Oct 7 12:49:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19582 for ipsec-outgoing; Tue, 7 Oct 1997 12:44:26 -0400 (EDT) Message-Id: <3.0.3.32.19971007125015.00b9ab40@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 07 Oct 1997 12:50:15 -0400 To: Bart Preneel From: Robert Moskowitz Subject: Re: IPsec mandatory authentication algorithms Cc: "C. Harald Koch" , ipsec@tis.com, Karen Seo In-Reply-To: References: <3.0.3.32.19971007121622.00c3f960@dilbert.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:35 PM 10/7/97 +0200, Bart Preneel wrote: > >I would hesitate to use HMAC-MD5 unless I could switch overnight >to HMAC-SHA1. > Well you could. Just change your policy, and your next Oakley Main Mode SHOULD negotiate HMAC-SHA1... BTW, most of the vendors that attended the Ottawa workshop were implementing both HMAC-MD5 and HMAC-SHA1. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Oct 7 13:31:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19863 for ipsec-outgoing; Tue, 7 Oct 1997 13:29:23 -0400 (EDT) From: Cheryl Madson Message-Id: <199710071739.KAA24434@trix.cisco.com> Subject: Re: IPsec Architecture -- proposed changes To: chk@utcc.utoronto.ca (C. Harald Koch) Date: Tue, 7 Oct 1997 10:39:16 -0700 (PDT) Cc: cmadson@cisco.com, ipsec@tis.com, kseo@bbn.com In-Reply-To: <97Oct7.122003edt.11653@janus.tor.securecomputing.com> from "C. Harald Koch" at Oct 7, 97 12:19:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > In message <199710071603.JAA20103@trix.cisco.com>, Cheryl Madson writes: > > > > The tunnel should have it's own TTL. This is consistent with how > > other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853 > > for examples. > > Just to be clear, we're agreeing, right? both RFC 2003 and 1853 say that you > do *not* copy TTLs from inside to outside, but instead decrement the *inner* > TTL when (encapsulating as fowarding) and when (forwarding after > decapsulating), which incidentally produces useful traceroute info :-) That's what I meant -- don't try to massively diverge from the tunnel behavior that is already in use by other tunnelling mechanisms, unless there is a compelling security reason to do so. I haven't had the cycles to sit down and compare what's in the architecture draft with any of the tunnel RFCs. Although I'm not fully certain that any one of these RFCs is considered the "standard" one to use (meaning that I am not willing to point to one to simply incorporate by reference), we probably should try to keep in line with the tunnel docs. I think it will make our collective lives easier. > > > There is nothing that suggests that other key sizes are even a MAY, > > apart from the reader recalling the history of the older AH drafts. I > > suppose a wordsmith revision could say "this and only this" or > > something which makes the MUST more of a MUST... ;-). > > In this case I'd change "160-bits must be supported" to "160-bits must be > used". "Supported" implies that other key lengths are allowed, which is > where I (and others I discussed this with) all went astray. > Since I see that the draft spells out that "no other authenticator sizes are supported", the same should be done for the key length. - C From owner-ipsec Tue Oct 7 13:40:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19923 for ipsec-outgoing; Tue, 7 Oct 1997 13:38:55 -0400 (EDT) Message-Id: <3.0.3.32.19971007134756.032a619c@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 07 Oct 1997 13:47:56 -0400 To: "C. Harald Koch" From: Matt Thomas Subject: Re: IPsec Architecture -- proposed changes Cc: ipsec@tis.com In-Reply-To: <97Oct7.122221edt.11652@janus.tor.securecomputing.com> References: <199710071547.LAA03894@istari.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:21 PM 10/7/97 -0400, C. Harald Koch wrote: >In message <199710071547.LAA03894@istari.sandelman.ottawa.on.ca>, "Michael C. Richardson" writes: >> >> Okay, which end decrements then? >> The far end is the one "forwarding" so it should do it. >> The near end can be thought to be forwarding as well. > >Agreed, they're *both* forwarding the packet; one into the tunnel, and one >out of the tunnel. RFC 2003 specifies good behaviour TTL handling with IP in >IP tunneling. No! If the de-encapsulator is the destination of the tunnelled packet then he is not forwarding it and therefore should not be decrementing the TTL. Only if he would forward the packet on must he decrement the TTL. -- 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 Tue Oct 7 14:20:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20286 for ipsec-outgoing; Tue, 7 Oct 1997 14:18:26 -0400 (EDT) Message-Id: <97Oct7.142924edt.11652@janus.tor.securecomputing.com> To: Matt Thomas cc: ipsec@tis.com Subject: Re: IPsec Architecture -- proposed changes References: <3.0.3.32.19971007134756.032a619c@ranier.altavista-software.com> In-reply-to: matt.thomas's message of "Tue, 07 Oct 1997 13:47:56 -0400". <3.0.3.32.19971007134756.032a619c@ranier.altavista-software.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, 7 Oct 1997 14:28:32 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.3.32.19971007134756.032a619c@ranier.altavista-software.com>, Matt Thomas writes: > No! If the de-encapsulator is the destination of the tunnelled packet > then he is not forwarding it and therefore should not be decrementing the > TTL. Only if he would forward the packet on must he decrement the TTL. Agreed. RFC2003 covers this, which is why I referenced it. I won't re-quote it here. Encapsulation and forwarding *are* treated separately WRT TTL processing; the net result is what you would expect if the tunnel were simply a layer 2 connection between the tunnel endpoints. From owner-ipsec Wed Oct 8 04:33:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24893 for ipsec-outgoing; Wed, 8 Oct 1997 04:28:05 -0400 (EDT) Date: Wed, 8 Oct 1997 10:32:49 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199710080732.KAA06195@ee.technion.ac.il> To: chk@utcc.utoronto.ca, ipsec@tis.com, rgm3@chrysler.com Subject: Re: IPsec mandatory authentication algorithms Cc: kseo@bbn.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > >Well, actually, I have old messages from Hugo stating that HMAC addresses >these concerns. And the workgroup came to the conclusion that HMAC-MD5 and >HMAC-SHA1 were equally secure. Then once we truncated both to 96 bits, >well is there a difference anymore, other than MD5 is consistantly reported >as faster than SHA1... Careful, Bob. I've NEVER said that HMAC-MD5 and HMAC-SHA1 are EQUALLY secure. There is NO evidence that that is the case. Actually, all evidence points to the possibility that SHA1 is more secure. This is a proven fact for the use of these functions for collision-resistance (e.g, for their use with signatures). In this case MD5 should be considered broken while SHA1 not. For use of these functions with HMAC the situation is different. None of these two candidates are broken in this case. However, this is not a basis to claim that they are *equally* secure. I append a message of mine to this list from (exactly) 1.5 year ago in which I do recommend keeping MD5 for use with HMAC based on the fact that MD5 is faster than SHA (by a factor of 2) and that SO FAR the known attacks on MD5 do not seem to endanger this use of the function. However, one reason that I feel comfortble making this recommendation is the fact that ipsec design does allow for what Bart Preneel put as "switching overnight to HMAC-SHA1" (and that authentication, differently than encryption, does not have a backwards compromise effect; see below). I always thought that the best way to guarantee that implementations are ready for a fast switch to SHA1 would be to mandate both transforms. If this is done (I do not see the downside of it) an editorial note could be put in the document saying that the security of SHA1 is probably better than that of MD5 (even for use with HMAC) and therefore applications where the security level is fundamentally more important than performance should use SHA1. However, for those implementations where the superior speed of MD5 is significant (and I personally know of such applications) could use HMAC-MD5. To the point: I'm voting to keep both as mandatory. > >Thus many of us feel that MD5 is the mandatory, as the SHA1 does not seem >to bring technical value. Hope that the above correct this feeling. There is a technical value for SHA1. Basically, it it hard to conceive that one day HMAC-SHA1 is broken but HMAC-MD5 is not. The other way is more plaussible (though not plaussible enough in the short term as to completely drop the use of MD5 *for this particular application with HMAC*) LAST REMARK: all of the above (and below) refers to the use of HMAC as a message authentication code in AH and ESP. Not as a pseudorandom function as needed in isakmp/oakley. For that use our analytical results of these functions are much weaker. As I said many times, for that use I'd prefer 3DES (and that's one of my reasons to "push" the general notion of prf instead of just keyed-hash as well as to oppose wiring in in the isakmp/oakley spec the use of HMAC as the only prf.) When using HMAC as a prf I do recommend using SHA1 since in that case we need to be particularly cautious (the "backwards compromise" problem does arise there) and also the performance difference of MD5 and SHA1 is not that essential there. [Sorry for diverging to this issue. Just to make sure that you do not apply the reasoning in one case to the other] Below is my old message. Hugo From: HUGO at watson.ibm.com Date: Wed, 8 May 96 16:32:58 EDT To: IPSEC@TIS.COM Subject: HMAC-MD5: to be or not to be? As it has been already announced in this list, MD5 is broken for collisions (Hans Dobbertin has extended his own techniques used against MD4 to attack MD5 as well). MD5 needs to be dropped (hope everyone already did) from any use that requires resistance to collisions by plain MD5. One application that is NOT broken with Dobbertin's attack is HMAC with MD5. Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses secret IVs and hides the result of the inner iterated function. The question is whether the new attack has a significant potential of being developed further to break also HMAC-MD5. Beyond our own assessment we have got the opinion of a few first line cryptographers that they see no way to make these techniques work against the use of MD5 in HMAC. With permission of Hans Dobbertin I reproduce this note he sent to me over the weekend in response to my question of whether he sees any application of his results to break HMAC-MD5: Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST) From: Hans Dobbertin <> To: "H.Krawczyk" Hi Hugo, I looked in your paper which you have sent me in January. To answer your question I can assure you that I cannot image any way to attack MD5 as it is used in HMAC. To be more precise, from the recent attack on MD5 (compress) one cannot derive any reservation against the use of MD5 in this context. (Perhaps one could argue that the randomness of MD5 is not sufficiently investigated ..., but that is another question, and I personally do not see a problem here.) Best regards, Hans This does not mean in any way that HMAC-MD5 is going to be secure forever. It is only to stress that the new attack is not necessarily a reason to drop MD5 from its current use in IPSEC. I believe that we can keep using it until new developments will bring HMAC-MD5 closer to a break. Remember this "principle" from draft-ietf-ipsec-hmac-md5-txt.00: Message authentication, as opposed to encryption, has a "transient" effect. A published breaking of a message authentication scheme would lead to the replacement of that scheme, but would have no adversarial effect on information authenticated in the past. This is in sharp contrast with encryption, where information encrypted today may suffer from exposure in the future if, and when, the encryption algorithm is broken. Following this principle I believe we can keep enjoying the better speed of MD5 at least for some time (weeks? months? years? who knows?) Just to stress this: there is NO known security advantage in keeping MD5 relative to going to SHA-1. The only issue here is performance. It is there where the trade-off seems to favor MD5 right now. [some technical issues on the analysis of HMAC removed] Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always very attentive to updates from the cryptanalytic front.) Hugo From owner-ipsec Wed Oct 8 10:40:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27324 for ipsec-outgoing; Wed, 8 Oct 1997 10:38:07 -0400 (EDT) Date: Wed, 8 Oct 1997 10:39:32 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199710081439.KAA02627@argon.ncsc.mil> To: wdm@epoch.ncsc.mil Subject: Re: SA payloads and Next payload Cc: ipsec@tis.com, ietf-pkix@tandem.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, I've had a request from a customer to add the capability to transmit X.509 Attribute Certificates within the ISAKMP Certificate payload. Attribute Certs allow authorization information (which may change frequently) to be attached to base certs (which are normally updated much less frequently), and they allow the authorization administrator to operate independently of the Certificate Authority. Attribute Certificates are defined in the ISO/ITU X.509 standard, but have not yet been profiled in the PKIX document series. There is support for doing so, but no one has yet volunteered to do the writing :-). I propose adding the following line to the Cert Encoding field of the ISAKMP Certificate payload: __________Certificate_Type___________Value___ X.509 Certificate - Attribute 10 Regards, Dave Kemp ----- Begin Included Message ----- 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 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 RESERVED 10- 255 o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. ----- End Included Message ----- From owner-ipsec Wed Oct 8 11:24:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27526 for ipsec-outgoing; Wed, 8 Oct 1997 11:23:39 -0400 (EDT) Message-ID: From: Roy Pereira To: "'dpkemp@missi.ncsc.mil'" , "'wdm@epoch.ncsc.mil'" Cc: "'ipsec@tis.com'" Subject: RE: SA payloads and Next payload Date: Wed, 8 Oct 1997 11:34:41 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I would also propose this addition to the document. Attribute Certificates are very handy... On Wednesday, October 08, 1997 10:40 AM, dpkemp@missi.ncsc.mil [SMTP:dpkemp@missi.ncsc.mil] wrote: > Doug, > > I've had a request from a customer to add the capability to transmit > X.509 Attribute Certificates within the ISAKMP Certificate payload. > Attribute Certs allow authorization information (which may change > frequently) to be attached to base certs (which are normally updated > much less frequently), and they allow the authorization administrator > to operate independently of the Certificate Authority. > > Attribute Certificates are defined in the ISO/ITU X.509 standard, but > have not yet been profiled in the PKIX document series. There is > support for doing so, but no one has yet volunteered to do the > writing :-). > > I propose adding the following line to the Cert Encoding field of the > ISAKMP Certificate payload: > > __________Certificate_Type___________Value___ > X.509 Certificate - Attribute 10 > > > Regards, > Dave Kemp > From owner-ipsec Wed Oct 8 12:10:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27783 for ipsec-outgoing; Wed, 8 Oct 1997 12:05:39 -0400 (EDT) Date: Wed, 8 Oct 97 15:58:07 GMT Daylight Time From: Ran Atkinson Subject: Re: IPsec Architecture -- proposed changes To: ipsec@tis.com, Karen Seo Cc: kseo@bbn.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199710070649.CAA15157@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk 1) I object to the deferral of MLS text and its removal from the Architecture specification at this time. There exists at least one MLS implementation of IPsec that was done based on the text in RFC-1825~1827. I am aware of a second independent MLS implementation in progress. Those implementers report that they have found the RFC text to be _minimal but sufficient_. Instead, I propose that the existing MLS text be retained, possibly adding a note that further development of the MLS portion of the specification is anticipated as part of the editorial changes going from Proposed Standard to Draft Standard. Removing the MLS text from the current specifications and deferring it to some later draft is counter-productive and is unfair to the existing MLS IPsec implementations. Part of the long-standing agreements on these revisions was to avoid unnecessary changes that would delay forward progress. I believe the MLS text deferral represents such an unnecessary change. 2) With respect to work in progress for multicast key distribution, I will note that GKMP has been present in RFC form for several months now. I will also note that relevant work by A. Ballardie ("Scalable Multicast Key Distribution") has been present in RFC form for over a year. I would suggest citing both the GKMP work and also the Ballardie work. Ran rja@inet.org From owner-ipsec Wed Oct 8 12:49:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28037 for ipsec-outgoing; Wed, 8 Oct 1997 12:44:38 -0400 (EDT) Message-Id: <199710081652.MAA27072@postal.research.att.com> To: Ran Atkinson cc: ipsec@tis.com, Karen Seo Subject: Re: IPsec Architecture -- proposed changes Date: Wed, 08 Oct 1997 12:52:47 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk 2) With respect to work in progress for multicast key distribution, I will note that GKMP has been present in RFC form for several months now. I will also note that relevant work by A. Ballardie ("Scalable Multicast Key Distribution") has been present in RFC form for over a year. I would suggest citing both the GKMP work and also the Ballardie work. The GKMP RFCs are experimental, I believe. And it isn't clear to me that they're the right architecture. From owner-ipsec Wed Oct 8 13:35:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28374 for ipsec-outgoing; Wed, 8 Oct 1997 13:34:09 -0400 (EDT) Message-Id: <3.0.3.32.19971008134014.00cd0730@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 08 Oct 1997 13:40:14 -0400 To: Steven Bellovin , Ran Atkinson From: Robert Moskowitz Subject: Re: IPsec Architecture -- proposed changes Cc: ipsec@tis.com, Karen Seo In-Reply-To: <199710081652.MAA27072@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:52 PM 10/8/97 -0400, Steven Bellovin wrote: > 2) With respect to work in progress for multicast key > distribution, I will note that GKMP has been present in > RFC form for several months now. I will also note that > relevant work by A. Ballardie ("Scalable Multicast Key > Distribution") has been present in RFC form for over a year. > I would suggest citing both the GKMP work and also the > Ballardie work. > >The GKMP RFCs are experimental, I believe. And it isn't clear to me >that they're the right architecture. > I've had similar comments from others. It would be nice if we could get some of the people that have issues on multicast to get with Steve. It is time to start planning the IPsecond BOF. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Oct 8 13:39:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28418 for ipsec-outgoing; Wed, 8 Oct 1997 13:39:42 -0400 (EDT) Message-Id: <199710081727.NAA06203@inner.net> To: ipsec@tis.com Subject: Removal of MLS X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 08 Oct 1997 13:27:54 -0400 From: Craig Metz Sender: owner-ipsec@ex.tis.com Precedence: bulk Removal of MLS/security label requirements from the current IPsec specs will interfere with several IPsec implementations and will increase yet again the number of real-world problems that IPsec does not solve. -Craig From owner-ipsec Wed Oct 8 13:50:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28492 for ipsec-outgoing; Wed, 8 Oct 1997 13:49:38 -0400 (EDT) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" , "'dpkemp@missi.ncsc.mil'" Cc: "'ipsec@tis.com'" , "'ietf-pkix@tandem.com'" Subject: RE: SA payloads and Next payload Date: Wed, 8 Oct 1997 13:53:44 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I had asked for this awhile back, but think it was only in a private email. Whatever the case I'll second the request now. Thanks. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil] >Sent: Wednesday, October 08, 1997 10:39 AM >To: wdm@epoch.ncsc.mil >Cc: ipsec@tis.com; ietf-pkix@tandem.com >Subject: Re: SA payloads and Next payload > >Doug, > >I've had a request from a customer to add the capability to transmit >X.509 Attribute Certificates within the ISAKMP Certificate payload. >Attribute Certs allow authorization information (which may change >frequently) to be attached to base certs (which are normally updated >much less frequently), and they allow the authorization administrator >to operate independently of the Certificate Authority. > >Attribute Certificates are defined in the ISO/ITU X.509 standard, but >have not yet been profiled in the PKIX document series. There is >support for doing so, but no one has yet volunteered to do the >writing :-). > >I propose adding the following line to the Cert Encoding field of the >ISAKMP Certificate payload: > > __________Certificate_Type___________Value___ > X.509 Certificate - Attribute 10 > > From owner-ipsec Wed Oct 8 13:52:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28543 for ipsec-outgoing; Wed, 8 Oct 1997 13:52:07 -0400 (EDT) Message-Id: <3.0.3.32.19971008140045.031ea300@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 08 Oct 1997 14:00:45 -0400 To: kseo@bbn.com From: Matt Thomas Subject: Re: IPsec Architecture -- proposed changes Cc: Ran Atkinson , ipsec@tis.com In-Reply-To: References: <199710070649.CAA15157@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:58 PM 10/8/97 Time, Ran Atkinson wrote: [snip] >Removing the MLS text from the current specifications and >deferring it to some later draft is counter-productive and >is unfair to the existing MLS IPsec implementations. Part >of the long-standing agreements on these revisions was to >avoid unnecessary changes that would delay forward progress. >I believe the MLS text deferral represents such an unnecessary >change. I'd like chime in and support Ran. As someone working for a vendor which sells MLS products, having a description of how IPsec plays with MLS (even as minimal as exists currently) is required in implementing our non-MLS IPsec support since the non-MLS support will be the basis of any MLS IPsec support. -- 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 Wed Oct 8 16:00:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA29336 for ipsec-outgoing; Wed, 8 Oct 1997 15:59:09 -0400 (EDT) Message-Id: <199710082005.NAA10379@pita.cisco.com> cc: Matt Thomas , ipsec@tis.com Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 17 Sep 1997 13:54:58 PDT." <199709172054.NAA04672@pita.cisco.com> Date: Wed, 08 Oct 1997 13:05:33 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > Matt, > > >Be careful. If your ISAKMP daemon dies and restarts AND your IPSEC SAs > >are kept elsewhere (kernel, another daemon, whatever) you only want to > >the remote ISAKMP daemon to forget about ISAKMP SAs. It should leave > >the IPSEC SAs alone. > > Oh yeah, agreed. Actually, let's revisit this. How would you propose to differentiate between a host that has actually rebooted and lost both its ISAKMP and IPSEC SA's from one where only the ISAKMP service has been restarted? Is it really worth having two separate Notification status messages? > >The messages (I'd call it RESTART) should send include the DOI for which > >the SAs should be forgotten. Multiple RESTART notification payloads can > >be included if more than one DOI needs to flushed. > > The DOI is included in the Notification Payload. If you wanted to flush > more than one DOI, you could include more than one Notification Payload > in a single informational exchange. > > Assuming we went this route... > > Derrell I've written the following so far, which assumes one message for both: 4.6.3.3 INITIAL-CONTACT The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system. The receiver of this Notification Message might then elect to delete any existing SA's it has for the sending system under the assumption that the sending system has rebooted and no longer has access to the orignal SA's and their associated keying material. When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload). From owner-ipsec Wed Oct 8 16:12:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29415 for ipsec-outgoing; Wed, 8 Oct 1997 16:12:37 -0400 (EDT) Message-Id: <3.0.3.32.19971008162213.0078d8bc@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 08 Oct 1997 16:22:13 -0400 To: Derrell Piper From: Matt Thomas Subject: Re: Daemon Recovery Cc: ipsec@tis.com In-Reply-To: <199710082005.NAA10379@pita.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:05 PM 10/8/97 -0700, Derrell Piper wrote: >> Matt, >> >> >Be careful. If your ISAKMP daemon dies and restarts AND your IPSEC SAs >> >are kept elsewhere (kernel, another daemon, whatever) you only want to >> >the remote ISAKMP daemon to forget about ISAKMP SAs. It should leave >> >the IPSEC SAs alone. >> >> Oh yeah, agreed. > >Actually, let's revisit this. How would you propose to differentiate >between a host that has actually rebooted and lost both its ISAKMP and >IPSEC SA's from one where only the ISAKMP service has been restarted? Is >it really worth having two separate Notification status messages? It's worth having the functionality but it's not required to have two different messages. Use the DOI already present in the notify message to define the scope of what SA's should be nuked. If the system rebooted and lost all SA's, send two notify's -- one for the ISAKMP DOI and one for the Internet DOI. >I've written the following so far, which assumes one message for both: > > 4.6.3.3 INITIAL-CONTACT > > The INITIAL-CONTACT status message may be used when one side wishes to > inform the other that this is the first SA being established with the > remote system. The receiver of this Notification Message might then elect > to delete any existing SA's it has for the sending system that belong to the DOI of the Notification Message > under the > assumption that the sending system has rebooted and no longer has access to > the orignal SA's and their associated keying material. When used, the > content of the Notification Data field SHOULD be null (i.e. the Payload > Length should be set to the fixed length of Notification Payload). I think the added text will cover both cases. -- 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 Wed Oct 8 19:02:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00388 for ipsec-outgoing; Wed, 8 Oct 1997 19:01:06 -0400 (EDT) Message-Id: <199710082311.QAA14578@pita.cisco.com> To: Matt Thomas cc: ipsec@tis.com Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 08 Oct 1997 16:22:13 EDT." <3.0.3.32.19971008162213.0078d8bc@ranier.altavista-software.com> Date: Wed, 08 Oct 1997 16:11:02 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >It's worth having the functionality but it's not required to have >two different messages. Use the DOI already present in the notify >message to define the scope of what SA's should be nuked. If the >system rebooted and lost all SA's, send two notify's -- one for the >ISAKMP DOI and one for the Internet DOI. Ah, I see the confusion. There isn't a separate DOI for ISAKMP. You say that the message is directed at an ISAKMP SA if the message ID field (back in the generic ISAKMP header) is zero. I'm going to leave it a single message for now, with the assumption being that this is being sent because the host rebooted and lost all state. That's the problem we're most concerned with. Derrell From owner-ipsec Wed Oct 8 19:10:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00440 for ipsec-outgoing; Wed, 8 Oct 1997 19:10:06 -0400 (EDT) Message-Id: <3.0.3.32.19971008191912.00772ab4@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 08 Oct 1997 19:19:12 -0400 To: Derrell Piper From: Matt Thomas Subject: Re: Daemon Recovery Cc: ipsec@tis.com In-Reply-To: <199710082311.QAA14578@pita.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:11 PM 10/8/97 -0700, Derrell Piper wrote: >>It's worth having the functionality but it's not required to have >>two different messages. Use the DOI already present in the notify >>message to define the scope of what SA's should be nuked. If the >>system rebooted and lost all SA's, send two notify's -- one for the >>ISAKMP DOI and one for the Internet DOI. > >Ah, I see the confusion. There isn't a separate DOI for ISAKMP. You say >that the message is directed at an ISAKMP SA if the message ID field (back >in the generic ISAKMP header) is zero. > >I'm going to leave it a single message for now, with the assumption being >that this is being sent because the host rebooted and lost all state. >That's the problem we're most concerned with. Not me. I'm more concerned with restarting my isakmp daemon (which won't affect my IPsec SAs since they will kernel resident and will survive the death of isakmpd). Then make the notification message data contain 1 to N protocol values (one per octet) indicating for what protocol what SAs must be nuked. With that you can specify ISAKMP (or AH or ESP or IPCOMP or ...). -- 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 Wed Oct 8 19:22:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00504 for ipsec-outgoing; Wed, 8 Oct 1997 19:21:37 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Matt Thomas'" , "'Derrell Piper'" Cc: "'ipsec@tis.com'" Subject: RE: Daemon Recovery Date: Wed, 8 Oct 1997 19:29:09 -0400 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 How are we going to trust these messages, if ISAKMP has lost its states? On Wednesday, October 08, 1997 7:19 PM, Matt Thomas [SMTP:matt.thomas@altavista-software.com] wrote: > At 04:11 PM 10/8/97 -0700, Derrell Piper wrote: > >>It's worth having the functionality but it's not required to have > >>two different messages. Use the DOI already present in the notify > >>message to define the scope of what SA's should be nuked. If the > >>system rebooted and lost all SA's, send two notify's -- one for the > >>ISAKMP DOI and one for the Internet DOI. > > > >Ah, I see the confusion. There isn't a separate DOI for ISAKMP. You say > >that the message is directed at an ISAKMP SA if the message ID field (back > >in the generic ISAKMP header) is zero. > > > >I'm going to leave it a single message for now, with the assumption being > >that this is being sent because the host rebooted and lost all state. > >That's the problem we're most concerned with. > > Not me. I'm more concerned with restarting my isakmp daemon (which won't > affect my IPsec SAs since they will kernel resident and will survive the > death of isakmpd). > > Then make the notification message data contain 1 to N protocol values > (one per octet) indicating for what protocol what SAs must be nuked. > With that you can specify ISAKMP (or AH or ESP or IPCOMP or ...). > -- > 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 Wed Oct 8 20:08:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA00757 for ipsec-outgoing; Wed, 8 Oct 1997 20:08:06 -0400 (EDT) Message-Id: <199710090017.RAA16043@pita.cisco.com> To: Roy Pereira cc: "'Matt Thomas'" , "'ipsec@tis.com'" Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 08 Oct 1997 19:29:09 EDT." Date: Wed, 08 Oct 1997 17:17:52 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy and Matt, The Notification Message in question is associated with a new ISAKMP SA between the two hosts. It's secured by the new ISAKMP SA. It's not relevant here just what caused the new SA to be established. It could have happened from either side for a variety of reasons. If you restart your ISAKMP deamon, as Matt's suggesting, then one of two things happens: 1) if the host who rebooted re-initiates, the other side presumably just responds to him and communication is established under the new SA's; 2) if the host who didn't reboot initiates, say because a Phase II SA expired and we need a new QM, then the host who did reboot is going to send an INVALID-COOKIE in response to the QM proposal. If the host who gets the INVALID-COOKIE is smart, he's probably going to assume that the other host has restarted and initiate a new Main Mode with him. Assuming that then completes, the old SA's can be tossed. It's the first case this notification message addresses: it allows the host who did not reboot to purge its stale IPSEC SA's for a zombie association. Does this make sense to the other ISAKMP developers here? Derrell From owner-ipsec Thu Oct 9 07:50:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04330 for ipsec-outgoing; Thu, 9 Oct 1997 07:47:38 -0400 (EDT) Message-ID: From: Greg Carter To: "'Roy Pereira'" , "'Derrell Piper'" Cc: "'Matt Thomas'" , "'ipsec@tis.com'" Subject: RE: Daemon Recovery Date: Thu, 9 Oct 1997 07:51:05 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Derrell, You previously stated: Ah, I see the confusion. There isn't a separate DOI for ISAKMP. You say that the message is directed at an ISAKMP SA if the message ID field (back in the generic ISAKMP header) is zero. However below you state that new ISAKMP SA's are established, therefore the notify would be protected under that SA. If it is the Message-ID field would be a random number for the IV seed/sync. The protocol ID field in the notify payload should do the trick, although you might want to add text that when sent for this message type the SPI length and value should be zero (or ignored). If you want to specify that only ISAKMP SAs were lost send protocol ID == PROTO_ISAKMP, if you want to specify all set it to 0 or define a new value PROTO_ALL? Having said that I am fine with the interpretation meaning 'purge all' and not interpreting the protocol ID field of the notify payload. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Derrell Piper[SMTP:piper@cisco.com] >Sent: Wednesday, October 08, 1997 8:17 PM >To: Roy Pereira >Cc: 'Matt Thomas'; 'ipsec@tis.com' >Subject: Re: Daemon Recovery > >Roy and Matt, > >The Notification Message in question is associated with a new ISAKMP SA >between the two hosts. It's secured by the new ISAKMP SA. It's not >relevant here just what caused the new SA to be established. It could >have happened from either side for a variety of reasons. > >If you restart your ISAKMP deamon, as Matt's suggesting, then one of two >things happens: 1) if the host who rebooted re-initiates, the other side >presumably just responds to him and communication is established under the >new SA's; 2) if the host who didn't reboot initiates, say because a Phase >II SA expired and we need a new QM, then the host who did reboot is going >to send an INVALID-COOKIE in response to the QM proposal. If the host who >gets the INVALID-COOKIE is smart, he's probably going to assume that the >other host has restarted and initiate a new Main Mode with him. Assuming >that then completes, the old SA's can be tossed. > >It's the first case this notification message addresses: it allows the host >who did not reboot to purge its stale IPSEC SA's for a zombie association. > >Does this make sense to the other ISAKMP developers here? > >Derrell > From owner-ipsec Thu Oct 9 07:55:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04445 for ipsec-outgoing; Thu, 9 Oct 1997 07:54:39 -0400 (EDT) Message-Id: <199710091159.EAA23640@pita.cisco.com> To: Greg Carter cc: "'Roy Pereira'" , "'Matt Thomas'" , "'ipsec@tis.com'" Subject: Re: Daemon Recovery In-reply-to: Your message of "Thu, 09 Oct 1997 07:51:05 EDT." Date: Thu, 09 Oct 1997 04:59:31 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, Thanks for the correction. Derrell >However below you state that new ISAKMP SA's are established, therefore >the notify would be protected under that SA. If it is the Message-ID >field would be a random number for the IV seed/sync. From owner-ipsec Thu Oct 9 08:23:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA04679 for ipsec-outgoing; Thu, 9 Oct 1997 08:22:37 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <199710070649.CAA15157@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Oct 1997 08:33:36 -0400 To: Ran Atkinson From: Stephen Kent Subject: Re: IPsec Architecture -- proposed changes Cc: ipsec@tis.com, Karen Seo Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, The MLS-related text from the last draft that you authored was not complete and it spread throughout the old text. It cannot be carried forward into the new text without significant additional work, both editorial and technical. Since we are under considerable pressure to get this document out, we don't have the time to do the necessary work to create and integrate new material. Spreading out the MLS-relevant text into the re-organized document would make the new document hard to read, so I'm not in favor of that. Consolidating it into a separate section, which is what we had planned when we developed the outline for the first draft that we published (in late July) requires more work than we can offer. If you or other with interest in this aspect of the architecture cabn supply appropriate text we could incorporate it, but I don't want to incorporate something superficial. I question the notion that the assertion that the previous text was "mininmal but sufficient." Sufficient to enable independently developed, interoperable implementations over a range of MLS environments, or sufficient for one vendor to develop an implementation that works in a small set of MLS contexts? The former is the goal for RFCs; the latter is much easier to accomplish and is characteristic of all the network layer, MLS security devices that I've seen over that last 20 years. I agree with Steve Bellovin's observation that the current multicast technology is not sufficiently mature to warrent inclusion at this time. The GKMP work may be good, but the RFC is experimental. The CBT multicast design of Ballardie distributes keying material to routers along a multicast path. This would be appropriate a a means of controlling access to multicast groups for resource control purposes, but it is not an ideal approach for confidentiality, integrity and authenticity of multicast traffic per se. A more recent paper by a Stanford PhD student suggests an analogous approach, but with distributed multicast controllers, rather that routers. There is sufficient uncertainty here to warrent deferring standardization for now. Finally, you repeat your comment that a major constraint on the rewrites of the IPsec document set was that no changes be made that were not backward compatible. While I agree that this was the initial intent, the WG has agreed to a number of changes over the last year, as more details were worked out in analysis and implementation, so that this intial goal is not really applicable. Thus I would not refer to it as a basis for evaluating the suitability of inclusion or exclusion of any material at this point. Steve Steve From owner-ipsec Fri Oct 10 09:44:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA12928 for ipsec-outgoing; Fri, 10 Oct 1997 09:36:18 -0400 (EDT) Message-Id: <199710101333.JAA04372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-05.txt Date: Fri, 10 Oct 1997 09:33:29 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-05.txt Pages : 25 Date : 09-Oct-97 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. Internet-Drafts are available by anonymous FTP. Login 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-ipsec-doi-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-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: <19971009103236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971009103236.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Oct 10 16:47:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15520 for ipsec-outgoing; Fri, 10 Oct 1997 16:45:33 -0400 (EDT) Date: Fri, 10 Oct 1997 16:55:17 -0400 Message-Id: <199710102055.QAA27279@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Seo Cc: rgm3@chrysler.com, skent@bbn.com, kseo@bbn.com Cc: ipsec@tis.com In-Reply-To: Karen Seo's message of Sun, 5 Oct 97 19:27:35 EDT, <9710052335.AA23859@MIT.EDU> Subject: Re: IPsec -- SPI ranges Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Sun, 5 Oct 97 19:27:35 EDT From: Karen Seo Norm has raised the question: "I thought there were distinct SPI ranges for manually and automatically configured SAs." I found email from Bill Simpson stating that SPI values from 256-65535 are reserved for manual configuration, but the initial drafts I obtained back in February don't show this. Is there working group agreement on whether to set aside separate ranges of SPIs for manual and automated key management? If not, could you resolve this so we can update the AH/ESP/Arch specs accordingly? Hi Karen, Sorry for the delay in getting back to you. It's been a busy week, and I haven't had time to do the necessary research until now. As far as I can tell, there's been no discussion on the IPSEC working group mailing list to have a separate SPI range for manually configured SA's. Some of Bill Simpson's drafts did reserve the SPI ranges from 256-65535 for manual configuration, but none of his drafts which made such a claim were under formally consideration by the working group, and to my knowledge I haven't seen any request for this from the working group. I've cc'ed this message to the ipsec mailing list. If someone has a very good reason to want this speak up now. - Ted From owner-ipsec Fri Oct 10 17:18:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15736 for ipsec-outgoing; Fri, 10 Oct 1997 17:17:33 -0400 (EDT) Date: Fri, 10 Oct 1997 17:28:10 -0400 Message-Id: <199710102128.RAA27287@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: Ran Atkinson , ipsec@tis.com, Karen Seo In-Reply-To: Stephen Kent's message of Thu, 9 Oct 1997 08:33:36 -0400, Subject: Re: IPsec Architecture -- proposed changes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk There are certain parts of this discussion from both Ran and Steve which don't make complete sense to me. Ran: The text you are referring to is section 5.4 of RFC 1825, right? Quite frankly, the text doesn't say much. It says that AH authenticates explicit labels, and you can have implicit labels associated with SA's/SPI's. It says that you should different encryption keys for different comparments/security levels. All of this seems pretty common sense to me. Would MLS implementations really be hurt if the MLS text was moved into a full MLS spec which would be fleshed out in a new working group (the proposed IPSECond wg, for example)? Steve: I don't understand your remark that the MLS-related text is "spread throughout the old text". It seemed to me it was localized to section 5.4 of RFC 1825. Granted that there's probably more --- perhaps a lot more --- one could say about MLS and IPSEC than was said in RFC 1825, what problems do you forsee with simply including section 5.4 with minimal changes into the security architecture document? As should be pretty obvious from my questions to both Ran and Steve, I don't particularly care exactly how we resolve the MLS issue, but I (and presumably the whole working group) *would* like for it to be resolved, one way or the other. - Ted From owner-ipsec Fri Oct 10 19:53:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA16402 for ipsec-outgoing; Fri, 10 Oct 1997 19:51:32 -0400 (EDT) Message-Id: <199710102359.TAA03524@relay.rv.tis.com> Date: Fri, 10 Oct 97 20:00:46 EDT From: Charles Lynn To: ipsec@tis.com Subject: Re: IPsec Architecture -- proposed changes Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, A couple comments on encapsulation. > The question is, should a tunnel look like a single IP hop or not? I'm of > the VPN religion, and so I believe that tunnels should look like a direct > (one hop) link between the two hosts/routers. VPNs are certainly one important area that the working group is to address, but not the only one. The working group is to try and make the services provided by IP secure, not to depreciate services that are not "easy" to secure. We should make sure that we do not overly constrain interaction between individual hosts or a host and, e.g., a server run by some business (apt to be much more common than (configured) VPNs if the internet becomes a commercial success). IPSec is using the mechanism of encapsulating a datagram with another IP header and AH and or ESP headers because it is an efficient mechanism to specify the source routing needed to get a datagram to the right system (destination security gateway), and to identify the security headers that it should process (all those up to the next IP header). Thus the IPSec use of encapsulation has different motivations and goals than, for example, the tunneling used in the MBONE to get through routers that do not support multicast. In the MBONE context, the tunnel should look like a layer two point-to-point link to the multicast routing layer, so that multicast traffic can be correctly forwarded. It is also needed in order to make expanding searches, etc. work correctly. > This makes traceroute output look really weird when going through a tunnel. If most of the connectivity problems one has to diagnose are before or after the security gateways, then seeing the hops between them would not be an issue. My experience has been that connectivity problems are more often "in the cloud" than in the organizations at either end. The ability to diagnose things between security gateways will be even more important until we get all the path MTU issues resolved and the code working. Things that make diagnosis of problems harder for the users are not a win, in my opinion. I think that by treating security encapsulations as "tunnels", with nothing between the security association endpoints visible to the end user, and a separate TTL, we will be making it harder to maintain the existing IP services if not break them altogether (think multicast :-(). I thus think that it is important that security encapsulators and decapsulators look just like one more system along a path that a datagram follows. To do otherwise is to make a subtle change the basic internet architecture, which I do not think we have addressed and understand. Charlie From owner-ipsec Fri Oct 10 23:05:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17311 for ipsec-outgoing; Fri, 10 Oct 1997 23:02:03 -0400 (EDT) Message-Id: <97Oct10.231221edt.11649@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: IPsec Architecture -- proposed changes References: <199710102359.TAA03524@relay.rv.tis.com> In-reply-to: Your message of "Fri, 10 Oct 1997 20:00:46 -0400". <199710102359.TAA03524@relay.rv.tis.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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2423.876539551.1@rafael.tornd.securecomputing.com> Date: Fri, 10 Oct 1997 23:12:32 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk Nice idea. However, since the packets that generate the "TTL expired" message are encrypted, it's kinda difficult (read impossible) to figure out who the *original* unencapsulated packet came from, and so return the TTL expired message. Net result: a traceroute output with lots of "* * *" lines, which is *not* productive to diagnostics. To go back to your original point: if you want source routing, use source routing. If you want tunnelling, do tunnelling. Don't try to mix the two; you'll get the worst of both worlds. We don't know what to do with multicast in an IPsec context. Leave it for IPsecond. The outer TTL should not be copied to the inner TTL on decapsulation. -- Harald Koch In message <199710102359.TAA03524@relay.rv.tis.com>, Charles Lynn writes: > > > This makes traceroute output look really weird when going through a tunnel. > > If most of the connectivity problems one has to diagnose are before or > after the security gateways, then seeing the hops between them would > not be an issue. My experience has been that connectivity problems > are more often "in the cloud" than in the organizations at either end. > The ability to diagnose things between security gateways will be even > more important until we get all the path MTU issues resolved and the > code working. Things that make diagnosis of problems harder for the > users are not a win, in my opinion. > > I think that by treating security encapsulations as "tunnels", with > nothing between the security association endpoints visible to the end > user, and a separate TTL, we will be making it harder to maintain the > existing IP services if not break them altogether (think multicast > :-(). I thus think that it is important that security encapsulators > and decapsulators look just like one more system along a path that a > datagram follows. To do otherwise is to make a subtle change the > basic internet architecture, which I do not think we have addressed > and understand. From owner-ipsec Fri Oct 10 23:07:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17325 for ipsec-outgoing; Fri, 10 Oct 1997 23:05:33 -0400 (EDT) Message-Id: <97Oct10.231516edt.11649@janus.tor.securecomputing.com> To: "Theodore Y. Ts'o" cc: Karen Seo , rgm3@chrysler.com, skent@bbn.com, ipsec@tis.com Subject: Re: IPsec -- SPI ranges References: <199710102055.QAA27279@dcl.MIT.EDU> In-reply-to: tytso's message of "Fri, 10 Oct 1997 16:55:17 -0400". <199710102055.QAA27279@dcl.MIT.EDU> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2452.876539728.1@rafael.tornd.securecomputing.com> Date: Fri, 10 Oct 1997 23:15:28 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710102055.QAA27279@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes: > > Some of Bill Simpson's drafts did reserve the SPI ranges from > 256-65535 for manual configuration, but none of his drafts which made > such a claim were under formally consideration by the working group, and > to my knowledge I haven't seen any request for this from the working > group. I've cc'ed this message to the ipsec mailing list. If someone > has a very good reason to want this speak up now. I use the 256-65535 convention in my implementations. However, I don't see a need to standardize this; "pick a number between 256 and 2^32 -1" has a small probability of colliding with an existing manual SA. Given a collision, I'd do the same as with weak keys; fail the SA and re-start the SA negotiation (Phase 2 in the case of ISAKMP). -- Harald From owner-ipsec Sat Oct 11 12:27:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20414 for ipsec-outgoing; Sat, 11 Oct 1997 12:20:33 -0400 (EDT) Date: Sat, 11 Oct 97 16:17:25 GMT Daylight Time From: Ran Atkinson Subject: Re: IPsec -- SPI ranges To: "C. Harald Koch" Cc: ipsec@tis.com, Karen Seo , rgm3@chrysler.com, skent@bbn.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <97Oct10.231516edt.11649@janus.tor.securecomputing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, Also, many (most ?) implementations which retain a central storage for IPsec SAs can often determine the SPI collision _before_ sending the SPI back to the remote end (via Photuris, ISAKMP, whatever) so that the KM exchange gets delayed 1-2 seconds (while the receiving end selects another SPI that really isn't in use) but the KM exchange does not ever need to be repeated. Not all implementations will have that property, but those that do might try the above approach. Ran From owner-ipsec Sat Oct 11 13:51:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20760 for ipsec-outgoing; Sat, 11 Oct 1997 13:47:08 -0400 (EDT) Message-Id: <199710111801.OAA18801@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IPsec -- SPI ranges In-reply-to: Your message of "Sat, 11 Oct 1997 16:17:25 EST." Date: Sat, 11 Oct 1997 14:01:06 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Ran" == Ran Atkinson writes: Ran> storage for IPsec SAs can often determine the SPI collision Ran> _before_ sending the SPI back to the remote end (via Ran> Photuris, ISAKMP, whatever) so that the KM exchange gets Ran> delayed 1-2 seconds (while the receiving end selects another We always ask the SA database engine to allocate a new SPI. Ran> Not all implementations will have that property, but those Ran> that do might try the above approach. There is also an issue with dividing the SPI space up: Attacker: "oh look. Manually keyed SPIs. These should be worth attacking." :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Sat Oct 11 15:15:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21218 for ipsec-outgoing; Sat, 11 Oct 1997 15:10:07 -0400 (EDT) From: Cheryl Madson Message-Id: <199710111919.MAA04539@trix.cisco.com> Subject: Re: IPsec -- SPI ranges To: rja@inet.org (Ran Atkinson) Date: Sat, 11 Oct 1997 12:19:26 -0700 (PDT) Cc: chk@utcc.utoronto.ca, ipsec@tis.com, kseo@bbn.com, rgm3@chrysler.com, skent@bbn.com In-Reply-To: from "Ran Atkinson" at Oct 11, 97 04:17:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk On the subject of SPIs: At the last bakeoff I encountered a few parties who simply started their SPIs from 256. The SPIs really should (must?) be random. At the moment, if you give me (your) SPI, and I already happen to have it in my SADB (say you restarted your SADB and I didn't), I will reject it due to a duplicate SPI. I suppose I *could* tear down the old SA in favor of the new one, but I haven't convinced myself yet that this is a good idea. On my side, I'll randomly generate an SPI, check that it's > 255, and check for collisions. I also do not recognize a separate range for manually-keyed SAs, although I can understand where it could be a problem to install manual SAs on an already-running system, in case the SPI that you chose was alraedy in use (remember, you need to coordinate the SPI value with someone else). As I use randomly-generated SPIs for non-manually keyed SAs, I figure that the chance of collision is low, so I haven't considered it to be a serious problem. - C From owner-ipsec Sun Oct 12 18:11:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27491 for ipsec-outgoing; Sun, 12 Oct 1997 18:03:37 -0400 (EDT) Message-Id: <199710122213.PAA24340@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: proposed changes to ISAKMP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Oct 1997 15:13:38 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The following are the changes to v4 of the ISAKMP/Oakley draft I've made so far. It's now v5. * Added a table of contents * Added two new (optional) authentication methods: the revised public-key encryption method; and a kerberos authentication method. * cleaned up various spelling mistakes and typos. * clarification on group offers. If a group is specified using its description (Group Description attribute) then other group attributes like Group Prime or Group Type are not allowed. * added 2 new optional Diffie-Hellman groups, a EC2N group with field element size 155 and a EC2N group with field element size 185. * fixed problem with KEYMAT definition when it's expanded-- it didn't have the protocol included. * added a clarification on the use of proxy IDs in Quick Mode which states: "The proxy identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. Local policy will determine whether packets which do not match the proxy information on which a tunnel was created will be forwarded upon leaving the tunnel." The 2nd part might actually belong in the Architecture Draft and I'll entertain offers from Steve Kent to remove this text and have it added there but I think there is a general confusion on this capability and it should be clarified (some people had mentioned situations where "I don't 'do proxy' but the other guy does" as if it was some additional capability like doing Aggressive Mode). In fact, it might make sense to say that if proxy identities are used in negotiation of tunnels that traffic which does not match that information MUST NOT be stuffed in the tunnel. * added clarification on the M-ID used in Informational Exchanges. The M-ID of this exchange is unique and MUST NOT be the same as that used by a phase 2 exchange which prompted the Informational Exchange. * fixed the spi size problem in the payload explosion section. * added phase 1 attributes for GSS Identity Name and Field Element Size. Overloaded Group Prime attribute to also be Irreducible Polynomial. * and finally, due to Hugo's further clarification of the necessity of changing the way SKEYID is generated for authentication with public key encryption, I changed it to be his second request (it's a prf but the key is a hash of the nonces) instead of the first (it's the hash of the information). It looks like this: SKEYID = prf(hash(Ni | Nr), CKY-I | CKY-R) I don't think this will break too much since I know of only two implementations of authentication with public key encryption (one is mine) and in spite of the offers for testing there was no demonstrated interoperability of this at the last IPSec bakeoff at TimeStep. TBD: weak key checks. There was much discussion about the wisdom of having weak key checks in documents. Ideally ISAKMP/Oakley will be used for more than IPSec so I'm going to leave them unless there is a loud and immediate outcry. The last discussion devolved into thread completely off the original topic so I basically ignored it. If anyone has any major comments on this draft, if anyone feels it is no where near ready, I ask you to please send me your concerns. I've heard lots of vague gripes and statements of serious problems with this draft but I've received nothing substantial. Speak now, please! I-- and actually the entire WG-- cannot wait any longer. Barring anything serious the draft will go out later this week. Dan. From owner-ipsec Sun Oct 12 19:04:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27696 for ipsec-outgoing; Sun, 12 Oct 1997 19:02:32 -0400 (EDT) Date: Mon, 13 Oct 1997 02:12:21 +0300 (EET DST) Message-Id: <199710122312.CAA00749@pilari.ssh.fi> From: Tero Kivinen To: anx-sec@dot.netrex.net Cc: ipsec@tis.com Subject: PFS negotiation In-Reply-To: <3.0.32.19971012175953.009c6bb0@cale.checkpoint.com> References: <3.0.32.19971012175953.009c6bb0@cale.checkpoint.com> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 10 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Shamir writes: > 1) In aggressive mode, how can two parties negotiate the Diffie-Hellman > group? Since the key payload is sent in the same packet as the SA payload, > and you can't have two key payloads, I'm not sure this can be done. You don't negotiate it. You just have to select such group that you know the another end supports, and you should only include that group in your SA proposal. I assume you have to get information what groups the other end supports / wants to use by some other means (from configuration data, remember what groups was selected in last main mode negotiation etc). Or you can just try with the group you want and if the other ends answers with notification ATTRIBUTES-NOT-SUPPORTED then you just try another group. This is almost the same issue than the one with hash / encryption algorithm negotiation in aggressive mode when authenticating with rsa encryption (old or revised). You need to send hash of the key using negotiated algorithm before you have received anything from the other end (or with revised you need to encrypt data using negotiated encryption algorithm). I assume the draft should say something about that to clarify this issue more. > 2) In quick mode, how can two parties negotiate the use of PFS? If > they decide to use PFS, how can they negotiate the Diffie-Hellman group? > In the latter case the resolution draft (ver. 4) states (section 5.4): "If a > KE payload is sent, a Diffie-Hellman group ... MUST be sent as attributes > of the SA being negotiated". This implies that it is illegal to have two > proposals, one with a group attribute and one without. I think that is correct. So you don't negotiate the PFS, the initiator selects wheter it wants to use PFS or not. > Is this something that should be fixed, or is the intent that the initiator > always decides which group to use and whether to use PFS? The responder can always answer with notification saying ATTRIBUTES-NOT-SUPPORTED and then the initiator can retry without PFS. -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Mon Oct 13 07:46:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA01582 for ipsec-outgoing; Mon, 13 Oct 1997 07:44:00 -0400 (EDT) Message-Id: <3.0.32.19971012183931.009c3210@cale.checkpoint.com> X-Sender: roy@cale.checkpoint.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 12 Oct 1997 18:39:31 +0100 To: "rwt@vpnet.com" From: Roy Shamir Subject: Re: What do you do in case of initiate collisions? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk We've also been giving this some thought. Solution a) will cause unnecessary delays. The problem with b) is that the simultaneous negotiations may result in two different SAs (e.g. one ESP and one AH). So it might not be wise to break one of the negotiations off. (This is a problem especially for phase 2 negotiations where it makes sense to have multiple IPSEC SAs between two machines.) Solution d) breaks things up when the deletes are sent simultaneously. In this case, you go back to solution a). Therefore, we like solution c) best. It did cause some interoperability problems in the ANX bakeoff, since some implementations didn't support this, and deleted the first SA pair that was negotiated when they finished negotiating the second pair. Maybe it should be explicitly added to the ISAKMP docs as a MUST. Roy Shamir Check Point Software Tech. Ltd. At 09:09 AM 10/10/97 -0700, you wrote: >We're running into a bit of a problem and haven't found any specific >answers. Basically, we need to know how people are resolving the >problem where two systems start overlapping exchange sessions to >each other (the cross in the mail syndrome). > >It looks something like this > >A ----> B (A initiates a session with B) >A <---- B (B initiates a session with A) >A <---- B (B responds to A's initial request) >A ----> B (A responds to B's initial request) >etc.. > >This problem results in an ambiguity at the creation of the ISAKMP SA's or, >if it occurs during QM exchanges, the creation of two pairs of IPSEC SA's >(one for each of the exchanges). There are a variety of ways to resolve this > >a) both back off and retry later. >b) collision resolution based on IP address or cookie comparison, etc. >c) just keep both pairs of SA's around and assume any of them can be used > until they naturally age out. This means that you may be sending on one set > of SA's and receiving on another; does this break anything? >d) generate both pairs of IPSEC SA's and send a DELETE for the outbound SA > you won't use (and a DELETE for the corresponding inbound SA after receiving > the outbound SA DELETE). Since this may delete one side from each pair of > the SA's, does this break anything? >d) ignore the whole thing and hope it will go away, etc :^) >e) etc. > >Has there been a consensus on how to handle this case? If not, what are people >doing to handle this case. > >Also, it would seem that the handling should be different for the ISAKMP SA's >than for the IPSEC SA's or any other SA's created under the ISAKMP SA >umbrella. And does anyone's ISAKMP implementation allow more than one >ISAKMP SA per host (ie., per src.-dst. pair)? > >Thanks, >rwt >--- >Robert Tashjian >VPNet Technologies, Inc. >rwt@vpnet.com > > > From owner-ipsec Mon Oct 13 07:46:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA01573 for ipsec-outgoing; Mon, 13 Oct 1997 07:43:01 -0400 (EDT) Message-Id: <3.0.32.19971012175953.009c6bb0@cale.checkpoint.com> X-Sender: roy@cale.checkpoint.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 12 Oct 1997 17:59:53 +0100 To: ipsec@tis.com From: Roy Shamir Subject: PFS negotiation Cc: anx-sec@dot.netrex.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Two related questions: 1) In aggressive mode, how can two parties negotiate the Diffie-Hellman group? Since the key payload is sent in the same packet as the SA payload, and you can't have two key payloads, I'm not sure this can be done. 2) In quick mode, how can two parties negotiate the use of PFS? If they decide to use PFS, how can they negotiate the Diffie-Hellman group? In the latter case the resolution draft (ver. 4) states (section 5.4): "If a KE payload is sent, a Diffie-Hellman group ... MUST be sent as attributes of the SA being negotiated". This implies that it is illegal to have two proposals, one with a group attribute and one without. Is this something that should be fixed, or is the intent that the initiator always decides which group to use and whether to use PFS? Roy Shamir Check Point Software Tech. Ltd. From owner-ipsec Mon Oct 13 10:34:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA02859 for ipsec-outgoing; Mon, 13 Oct 1997 10:32:39 -0400 (EDT) Date: Mon, 13 Oct 1997 10:38:50 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199710131438.KAA19995@earth.hpc.org> To: roy@CheckPoint.COM Cc: ipsec@tis.com In-reply-to: Yourmessage <199710131211.FAA04024@baskerville.CS.Arizona.EDU> Subject: Re: What do you do in case of initiate collisions? Sender: owner-ipsec@ex.tis.com Precedence: bulk > >We're running into a bit of a problem and haven't found any specific > >answers. Basically, we need to know how people are resolving the > >problem where two systems start overlapping exchange sessions to > >each other (the cross in the mail syndrome). > > > >It looks something like this > > > >A ----> B (A initiates a session with B) > >A <---- B (B initiates a session with A) Can A simply assume that B is responding? > >And does anyone's ISAKMP implementation allow more than one > >ISAKMP SA per host (ie., per src.-dst. pair)? I certainly hope so; if it isn't clear that this is required, then the specification should be changed (the implementation must support it, though the policy may limit it). Also, is it clear that the identities in the pairs need not be based on IP addresses? Hilarie From owner-ipsec Mon Oct 13 11:25:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03189 for ipsec-outgoing; Mon, 13 Oct 1997 11:24:04 -0400 (EDT) Date: Mon, 13 Oct 1997 18:33:52 +0300 (EET DST) Message-Id: <199710131533.SAA14861@pilari.ssh.fi> From: Tero Kivinen To: Daniel Harkins Cc: ipsec@tis.com Subject: proposed changes to ISAKMP/Oakley In-Reply-To: <199710122213.PAA24340@dharkins-ss20> References: <199710122213.PAA24340@dharkins-ss20> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 25 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > * clarification on group offers. If a group is specified using its > description (Group Description attribute) then other group attributes > like Group Prime or Group Type are not allowed. So you cannot give a "name" to private group when doing phase I negotiation with group information? I think it would be nice to be able to send new group in the phase I negotiation and use that also in phase II without negotiating the group again in phase II new group mode negotiation. (== allow group description, but say it MUST be on private range if other the group is described in place). > * added clarification on the M-ID used in Informational Exchanges. The > M-ID of this exchange is unique and MUST NOT be the same as that > used by a phase 2 exchange which prompted the Informational Exchange. Some of the vendors in interop used Message ID 0 in informal exchanges when something happens goes wrong with the exchange quite early (say the first packet is invalid etc). I assume the M-ID of informal exchange MUST be unique also in phase I? Did you add any clarification of the calculation of authentication hash? Most of the vendors in interop used only IP address instead of full ID payload (without generic headers, but with protocol and port number). I had to add compat option for that in interop... HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) ^^^^ HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) ^^^^ [I also would like to have lengths of the data added to authentication hash, so it would clearly remove all kind of attacks where man in the middle tries to move data from one payload to another (there was similar case in early draft of ssh 2 protocol where you really could even use it to do successfull attack. I haven't found a any way to use it in isakmp/oakley, but it gives me bad feelings that some might find out attack using that).] > I don't think this will break too much since I know of only two > implementations of authentication with public key encryption (one > is mine) and in spite of the offers for testing there was no > demonstrated interoperability of this at the last IPSec bakeoff at > TimeStep. Our implemntation also supports authentication with public key encryption, but I don't think that will be big change. There are also some other things that should have some text in the draft: 1) The oakley draft specifies the format of variable lenght integers, but that format is NOT used by isakmp/oakley. The isakmp/oakley draft should say how variable length integers are send in KE payloads (length in payload length, data directly in payload, no extra padding), and how they should be added to HASH (are leading zeros allowed in g^x) 2) Clarify the text in authentication with public key encryption about the negotiated hash / encryption algorighm when using aggressive mode (no negotiation of SA done yet). 3) Now it is allowed from initiator to send SA proposal that will have several authentication methods offered to responder. This is fine in main mode, but in aggressive mode the initial packets sent by initiator differs when authenticating with public key encryption or when authentication with other authentication methods. I don't know if this should be allowed or disallowed by draft, but I would like to see something about it in the draft. 4) Draft should state clearly that there is only one cipher context/IV shared in both directions. At least I automatically assumed there is one cipher context/IV for encryption and one for decryption (ie separate contexts for each direction). -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Mon Oct 13 12:04:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA03362 for ipsec-outgoing; Mon, 13 Oct 1997 12:03:35 -0400 (EDT) Message-Id: <199710131613.JAA25632@pita.cisco.com> To: Daniel Harkins cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-reply-to: Your message of "Sun, 12 Oct 1997 15:13:38 PDT." <199710122213.PAA24340@dharkins-ss20> Date: Mon, 13 Oct 1997 09:13:42 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Would you also entertain the notion of mandating that the SA payload be first in all Phase I exchanges? Derrell From owner-ipsec Mon Oct 13 13:54:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04057 for ipsec-outgoing; Mon, 13 Oct 1997 13:53:06 -0400 (EDT) Message-Id: <199710131803.LAA24862@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tero Kivinen Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Mon, 13 Oct 1997 18:33:52 +0300." <199710131533.SAA14861@pilari.ssh.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 11:03:03 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero, > > * clarification on group offers. If a group is specified using its > > description (Group Description attribute) then other group attributes > > like Group Prime or Group Type are not allowed. > > So you cannot give a "name" to private group when doing phase I > negotiation with group information? I think it would be nice to be > able to send new group in the phase I negotiation and use that also in > phase II without negotiating the group again in phase II new group > mode negotiation. (== allow group description, but say it MUST be on > private range if other the group is described in place). New Groups are negotiated using New Group Mode and that has to be after the ISAKMP SA has been established and authenticated. You can still define a group in phase 1 by using, for example, the type and prime (for a MODP group) but I'd wonder why you'd just accept a prime like that and not do some sort of checking. What this prevents is someone passing additional group attributes along with an established, defined, group. If the group description is 2 and I pass you a prime as well you should refuse this (even if the prime I send you is the same as the one defined for group 2). Allowing such a capability will force implementations to do rediculous checking for absolutely no reason. If a group can be defined in shorthand (with only the description) it makes no sense to allow additional attributes even if they merely enforce the attributes already associated with the group. > > * added clarification on the M-ID used in Informational Exchanges. The > > M-ID of this exchange is unique and MUST NOT be the same as that > > used by a phase 2 exchange which prompted the Informational Exchange. > > Some of the vendors in interop used Message ID 0 in informal exchanges > when something happens goes wrong with the exchange quite early (say > the first packet is invalid etc). I assume the M-ID of informal > exchange MUST be unique also in phase I? For Informational exchanges that happen before the ISAKMP SA has been established this is correct. The draft states that if the ISAKMP SA hasn't yet been established that the Informational Exchange is passed in the clear. In that case it wouldn't really matter what the M-ID was. > Did you add any clarification of the calculation of authentication > hash? Most of the vendors in interop used only IP address instead of > full ID payload (without generic headers, but with protocol and port > number). I had to add compat option for that in interop... > > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) > ^^^^ > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) > ^^^^ Thank you! I forgot to mention that. It says: "The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R." I also forgot to mention that I added text that allows conformant implement- ations to limit the number of SAs it will inspect for negotiation since there is no limit on the number of offers I can send you in the SA payload. The following text was added to section "5. Exchanges": "Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons." > [I also would like to have lengths of the data added to authentication > hash, so it would clearly remove all kind of attacks where man in the > middle tries to move data from one payload to another (there was > similar case in early draft of ssh 2 protocol where you really could > even use it to do successfull attack. I haven't found a any way to use > it in isakmp/oakley, but it gives me bad feelings that some might find > out attack using that).] I don't understand what you mean by having the lengths included. Do you want the ISKAMP generic header of the D-H public values and the IDs to be included? I don't see a point but I'm not a cryptographer. Can you explain this attack? > There are also some other things that should have some text in the > draft: > > 1) The oakley draft specifies the format of variable lenght > integers, but that format is NOT used by isakmp/oakley. The > isakmp/oakley draft should say how variable length integers > are send in KE payloads (length in payload length, data > directly in payload, no extra padding), and how they should > be added to HASH (are leading zeros allowed in g^x) The base ISAKMP draft defines this. There would be no padding added unless this was the last payload in a Quick Mode exchange and it was necessary for encryption. > 2) Clarify the text in authentication with public key > encryption about the negotiated hash / encryption algorighm > when using aggressive mode (no negotiation of SA done yet). > > 3) Now it is allowed from initiator to send SA proposal that > will have several authentication methods offered to > responder. This is fine in main mode, but in aggressive > mode the initial packets sent by initiator differs when > authenticating with public key encryption or when > authentication with other authentication methods. I don't > know if this should be allowed or disallowed by draft, but > I would like to see something about it in the draft. I'll state the limitations on Aggressive Mode. It's not just in authentication with public key encryption. There's no negotiation of the group either. I don't think it's a matter of allowing or disallowing this. Aggressive Mode is just that. It assumes quite a bit. I'll but the following text in section "5. Exchanges" after the paragraph that describes Aggressive Mode: "Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie-Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher cannot be negotiated. For situations where the rich attribute negotiation capabilities of ISAKMP/Oakley are required Main Mode may be required." Let me know how that sounds. Suggested text is greatly appreciated if this is not adequate. > 4) Draft should state clearly that there is only one cipher > context/IV shared in both directions. At least I > automatically assumed there is one cipher context/IV > for encryption and one for decryption (ie separate contexts > for each direction). Can you tell me where you think this should go? Along with the description of IV generation for phase 1 (in Appendix B)? Dan. From owner-ipsec Mon Oct 13 14:25:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04273 for ipsec-outgoing; Mon, 13 Oct 1997 14:24:51 -0400 (EDT) Message-Id: <199710131832.LAA24886@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Derrell Piper Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Mon, 13 Oct 1997 09:13:42 PDT." <199710131613.JAA25632@pita.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 11:32:31 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, > Would you also entertain the notion of mandating that the SA payload be > first in all Phase I exchanges? It may get terribly bored. I'm not much of a host. :-) In section "5. Exchanges" right before "5.1 ISAKMP/Oakley Phase 1...." I'll add: "The SA payload must precede all other payloads in a phase 1 exchange". In section "5.6 Phase 2 - Quick Mode" I'll change: "In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header." to "In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH." To clear up any confusion on the hash payloads of Quick Mode I also added the following paragraph after the definition of HASH(1-3): "With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example." Dan. From owner-ipsec Mon Oct 13 16:26:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04833 for ipsec-outgoing; Mon, 13 Oct 1997 16:25:07 -0400 (EDT) Message-Id: <199710132035.NAA25111@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Mon, 13 Oct 1997 14:52:24 EDT." <199710131852.OAA09044@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 13:35:30 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I receive a unicast mail (not sent to the list) suggesting new terminology when describing ISAKMP payloads. The existing terminology overloads a single payload identifier: Ni is represented as the entire message including the ISAKMP generic header and it's also represented as just the body of the payload-- the nonce itself. This is confusing. The suggestion is to say that b

means the body of the message only and not including the generic header. There is already limited notation to describe the body of the SA payload-- SAp-- but that too is somewhat confusing. I'd rather not precede the payload notation with a qualifier so, unless there is opposition, I'll change the notation to use the trailing '_b' to define just the body of the payload. Ni is the entire nonce, generic header and all. Ni_b is just the nonce, no generic header. IDii_b is the ID minus the generic header. This works nicely as it includes the type, port and protocol by definition and that information must be included in HASH_I and HASH_R now. Dan. From owner-ipsec Mon Oct 13 16:52:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05017 for ipsec-outgoing; Mon, 13 Oct 1997 16:52:38 -0400 (EDT) Message-Id: <3.0.32.19971013140414.0096dc60@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 13 Oct 1997 14:04:15 -0700 To: Daniel Harkins From: John Burke Subject: Re: proposed changes to ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, If you allow people to define a new group during Phase I setup, then you have the Group Description and other attributes (Prime, Type, etc.) in the SA. Now, if it is possible for parties to retain a Group definition over Phase I re-establishment, then you the Responder would not know whether the Initiator is starting from boot; if it is, then it is going to repeat Group Description, Prime, Type, etc., and you would have to accept it or this wouldn't work. (We have not yet said that everyone who starts up has to send the Restart Notification which was being discussed.) Or is it considered that Phase I wipes the slate clean and all non-standard groups have to be renegotiated? In that case the restriction makes sense; but the spec doesn't say such slate-cleaning is required. Re checking when you get a Group definition: any system which accepts a group definition from another has to either a) trust that party specifically to define a good group, or b) check the group. For Phase I clearly it's b. Checking: if the Group Description is one I've seen before, then I can check if the attributes duplicate what I have (zilch cost), and a match would save me any costly math checks. Summary: I don't see why group parameter attributes should be forbidden. Maybe some discussion of how a system should protect itself should be there? But the spec doesn't presently attempt that level of instruction to the reader. I would agree that group-parameter attributes should be forbidden for the standard groups. Best regards, John Burke. At 11:03 AM 10/13/97 -0700, Daniel Harkins wrote: > Tero, > >> > * clarification on group offers. If a group is specified using its >> > description (Group Description attribute) then other group attributes >> > like Group Prime or Group Type are not allowed. >> >> So you cannot give a "name" to private group when doing phase I >> negotiation with group information? I think it would be nice to be >> able to send new group in the phase I negotiation and use that also in >> phase II without negotiating the group again in phase II new group >> mode negotiation. (== allow group description, but say it MUST be on >> private range if other the group is described in place). > >New Groups are negotiated using New Group Mode and that has to be after >the ISAKMP SA has been established and authenticated. You can still define >a group in phase 1 by using, for example, the type and prime (for a MODP >group) but I'd wonder why you'd just accept a prime like that and not do >some sort of checking. > >What this prevents is someone passing additional group attributes along with >an established, defined, group. If the group description is 2 and I pass >you a prime as well you should refuse this (even if the prime I send you >is the same as the one defined for group 2). Allowing such a capability >will force implementations to do rediculous checking for absolutely no reason. >If a group can be defined in shorthand (with only the description) it >makes no sense to allow additional attributes even if they merely enforce >the attributes already associated with the group. > >> > * added clarification on the M-ID used in Informational Exchanges. The >> > M-ID of this exchange is unique and MUST NOT be the same as that >> > used by a phase 2 exchange which prompted the Informational Exchange. >> >> Some of the vendors in interop used Message ID 0 in informal exchanges >> when something happens goes wrong with the exchange quite early (say >> the first packet is invalid etc). I assume the M-ID of informal >> exchange MUST be unique also in phase I? > >For Informational exchanges that happen before the ISAKMP SA has been >established this is correct. The draft states that if the ISAKMP SA hasn't >yet been established that the Informational Exchange is passed in the clear. >In that case it wouldn't really matter what the M-ID was. > >> Did you add any clarification of the calculation of authentication >> hash? Most of the vendors in interop used only IP address instead of >> full ID payload (without generic headers, but with protocol and port >> number). I had to add compat option for that in interop... >> >> HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) >> ^^^^ >> HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) >> ^^^^ > >Thank you! I forgot to mention that. It says: > "The entire ID payload (including ID type, port, and protocol > but excluding the generic header) is hashed into both HASH_I > and HASH_R." > >I also forgot to mention that I added text that allows conformant implement- >ations to limit the number of SAs it will inspect for negotiation since there >is no limit on the number of offers I can send you in the SA payload. The >following text was added to section "5. Exchanges": > > "Main Mode, Aggressive Mode, and Quick Mode do security > association negotiation. There is no limit on the number of > offers the initiator may send to the responder but conformant > implementations MAY choose to limit the number of offers it > will inspect for performance reasons." > >> [I also would like to have lengths of the data added to authentication >> hash, so it would clearly remove all kind of attacks where man in the >> middle tries to move data from one payload to another (there was >> similar case in early draft of ssh 2 protocol where you really could >> even use it to do successfull attack. I haven't found a any way to use >> it in isakmp/oakley, but it gives me bad feelings that some might find >> out attack using that).] > >I don't understand what you mean by having the lengths included. Do you want >the ISKAMP generic header of the D-H public values and the IDs to be included? >I don't see a point but I'm not a cryptographer. Can you explain this attack? > >> There are also some other things that should have some text in the >> draft: >> >> 1) The oakley draft specifies the format of variable lenght >> integers, but that format is NOT used by isakmp/oakley. The >> isakmp/oakley draft should say how variable length integers >> are send in KE payloads (length in payload length, data >> directly in payload, no extra padding), and how they should >> be added to HASH (are leading zeros allowed in g^x) > >The base ISAKMP draft defines this. There would be no padding added unless >this was the last payload in a Quick Mode exchange and it was necessary >for encryption. > >> 2) Clarify the text in authentication with public key >> encryption about the negotiated hash / encryption algorighm >> when using aggressive mode (no negotiation of SA done yet). >> >> 3) Now it is allowed from initiator to send SA proposal that >> will have several authentication methods offered to >> responder. This is fine in main mode, but in aggressive >> mode the initial packets sent by initiator differs when >> authenticating with public key encryption or when >> authentication with other authentication methods. I don't >> know if this should be allowed or disallowed by draft, but >> I would like to see something about it in the draft. > >I'll state the limitations on Aggressive Mode. It's not just in authentication >with public key encryption. There's no negotiation of the group either. >I don't think it's a matter of allowing or disallowing this. Aggressive >Mode is just that. It assumes quite a bit. I'll but the following text >in section "5. Exchanges" after the paragraph that describes Aggressive Mode: > > "Security Association negotiation is limited with Aggressive Mode. > Due to message construction requirements the group in which the > Diffie-Hellman exchange is performed cannot be negotiated. In > addition, different authentication methods may further constrain > attribute negotiation. For example, authentication with public > key encryption cannot be negotiated and when using the revised > method of public key encryption for authentication the cipher > cannot be negotiated. For situations where the rich attribute > negotiation capabilities of ISAKMP/Oakley are required Main Mode > may be required." > >Let me know how that sounds. Suggested text is greatly appreciated if this >is not adequate. > >> 4) Draft should state clearly that there is only one cipher >> context/IV shared in both directions. At least I >> automatically assumed there is one cipher context/IV >> for encryption and one for decryption (ie separate contexts >> for each direction). > >Can you tell me where you think this should go? Along with the description >of IV generation for phase 1 (in Appendix B)? > > Dan. > > > From owner-ipsec Mon Oct 13 16:56:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05036 for ipsec-outgoing; Mon, 13 Oct 1997 16:56:37 -0400 (EDT) From: pau@watson.ibm.com Date: Mon, 13 Oct 1997 17:04:31 -0400 Message-Id: <9710132104.AA24098@secpwr.watson.ibm.com> To: kivinen@ssh.fi, dharkins@cisco.com Subject: Re: proposed changes to ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: 9j8J7bdYP5EMQniZQlLwIQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I'll state the limitations on Aggressive Mode. It's not just in authentication > with public key encryption. There's no negotiation of the group either. > I don't think it's a matter of allowing or disallowing this. Aggressive > Mode is just that. It assumes quite a bit. I'll but the following text > in section "5. Exchanges" after the paragraph that describes Aggressive Mode: > > "Security Association negotiation is limited with Aggressive Mode. > Due to message construction requirements the group in which the > Diffie-Hellman exchange is performed cannot be negotiated. In > addition, different authentication methods may further constrain > attribute negotiation. For example, authentication with public > key encryption cannot be negotiated and when using the revised > method of public key encryption for authentication the cipher > cannot be negotiated. For situations where the rich attribute > negotiation capabilities of ISAKMP/Oakley are required Main Mode > may be required." > > Let me know how that sounds. Suggested text is greatly appreciated if this > is not adequate. Dan, I would not suggest the exact wording, but I would say the hash algorithm should not be negotiated neither for revised encryption mode; since the hash algorithm may imply the prf which is used to derive the symmetric encryption keys. Personally, I would really like to see only one proposal with one transform when using aggressive mode. If much time has to be spent on negotiation, main mode may very well be used. (This is my personal opinion only. I am NOT suggesting putting this restriction in the draft. Although I feel all implementors will like it.) Pau-Chen From owner-ipsec Mon Oct 13 18:48:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA05610 for ipsec-outgoing; Mon, 13 Oct 1997 18:44:06 -0400 (EDT) Message-Id: <199710132254.PAA25264@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Burke Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Mon, 13 Oct 1997 14:04:15 PDT." <3.0.32.19971013140414.0096dc60@192.43.161.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 15:54:06 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk John, > If you allow people to define a new group during Phase I setup, then you > have the Group Description and other attributes (Prime, Type, etc.) in the > SA. Now, if it is possible for parties to retain a Group definition over > Phase I re-establishment, then you the Responder would not know whether the > Initiator is starting from boot; if it is, then it is going to repeat Group > Description, Prime, Type, etc., and you would have to accept it or this > wouldn't work. (We have not yet said that everyone who starts up has to > send the Restart Notification which was being discussed.) I'm lost here. You define new groups-- with the Group Description-- in New Group Mode. That is not a phase 1 mode. But nothing in the spec says that you can't define a group by its component parts-- like Group Type and Group Prime-- if you so desire. In fact, it expressly allows you to do so. I personally won't accept them because I don't have the resources to throw at checking on the fly whether the group is strong enough. You might. > Or is it considered that Phase I wipes the slate clean and all non-standard > groups have to be renegotiated? In that case the restriction makes sense; > but the spec doesn't say such slate-cleaning is required. I'm not sure which slate you're referring to. A phase 1 exchange establishes the ISAKMP SA. Another phase 1 exchange would do the same. Nobody is wiping any slates. > Re checking when you get a Group definition: any system which accepts a > group definition from another has to either a) trust that party > specifically to define a good group, or b) check the group. For Phase I > clearly it's b. Checking: if the Group Description is one I've seen > before, then I can check if the attributes duplicate what I have (zilch > cost), and a match would save me any costly math checks. If it's a defined Group Description (either through the ones defined in the draft or via ones that you've accepted in New Group Mode) then why pass more attributes? It's not zilch cost. I don't see the benefit in allowing someone to say that the Diffie-Hellman group to choose is "Group Description One" with "Group Type MODP" and Group Prime "" but I do see a cost. It's the cost of checking and verifying that what you're sending me is the same as what I already know. Why do you want to be able to do this? > Summary: I don't see why group parameter attributes should be forbidden. > Maybe some discussion of how a system should protect itself should be > there? But the spec doesn't presently attempt that level of instruction to > the reader. They're forbidden because they burden the receiver and provide no benefit. They're also a receipe for error. > I would agree that group-parameter attributes should be forbidden for the > standard groups. That is exactly it! If the group is known by a Group Descriptor (whether because it's one defined in the draft-- there are now 4 groups-- or whether it's one you have via New Group Mode-- then that's all you use to identify it. If it's not then you can define it by it's component parts. Perhaps if I quote the draft you can tell me if it's unclear. In the section that describes the attributes that must be negotiated in phase 1 it says: "The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.7). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group." and section 5.7 says: "Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A and Group Curve B-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation." Both these parts have been in the draft for a while. I added the last sentence to the 1st part (which prompted this discussion) and wordsmithed the 2nd to include EC2N groups since the original text was MODP-specific. Dan. From owner-ipsec Mon Oct 13 19:16:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05780 for ipsec-outgoing; Mon, 13 Oct 1997 19:16:36 -0400 (EDT) Message-ID: <3442AE2A.237C@cs.umass.edu> Date: Mon, 13 Oct 1997 19:26:34 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: Tero Kivinen Subject: Re: proposed changes to ISAKMP/Oakley References: <199710122213.PAA24340@dharkins-ss20> <199710131533.SAA14861@pilari.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen writes: > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) > ^^^^ > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) > ^^^^ > > [I also would like to have lengths of the data added to authentication > hash, so it would clearly remove all kind of attacks where man in the > middle tries to move data from one payload to another (there was > similar case in early draft of ssh 2 protocol where you really could > even use it to do successfull attack. I haven't found a any way to use > it in isakmp/oakley, but it gives me bad feelings that some might find > out attack using that).] Could you clarify the type of attack you have in mind? In SSL 2.0 the length of the data padding is sent unauthenticated in the clear, but is nevertheless trusted by the receiver. This lets an adversary blur the boundary between the end of the data and the start of the padding. (due to Paul Kocher?) In ISAKMP/Oakley each side computes HASH_{I,R} by applying the prf to a sequence of fields that does not (AFAIK) explicitly include the lengths of the fields. (SAp, as I understand it, omits the ISAKMP header fields that give length information.) This suggests that an adversary could attempt to modify the cleartext values and field lengths in some SA, KE, and ID payloads and ISAKMP headers, and thereby cause the legitimate parties to authenticate a "wrong" set of values in HASH_{I,R}. Let's examine the possibilities. ISAKMP specifies the length of each cookie (Sec 3.1), and presumably everyone can deduce the expected length of each public exponential from the group descriptor. This leaves SAp, IDii, and IDir. For HASH_I, the initiator knows the correct length of its own identity IDii. Meanwhile the responder knows the correct expected length of SAp, because it generated that itself. For HASH_R the responder knows the correct lengths of both SAp and IDir. So an attacker might try to adjust the SAp value received by the initiator ("SAp_at_I"), the IDir value received by the initiator ("IDir_at_I"), and the IDii value received by the responder ("IDii_at_R"). To make both pairs of authentication hashes match, the tampering must satisfy (SAp_at_I | IDii) = (SAp | IDii_at_R) and (SAp_at_I | IDir_at_I) = (SAp | IDir). For authentication with signatures or with a preshared key, the useful (to an attacker) choices of different ISAKMP identities would seem to be very limited. The attacker would not learn the agreed session key if this worked, but perhaps could cause one or both legitimate parties to accept a mistaken identity for the peer. The correct SAp and the modified SAp_at_I would need to specify reasonably compatible sets of transforms, or the whole conversation will fall apart. Now it would be interesting to see whether the SAp might be modified, subject to the constraints above, so as to alter the group choice and thus cast the lengths of the public exponentials into doubt.... -Lewis From owner-ipsec Mon Oct 13 21:01:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA06322 for ipsec-outgoing; Mon, 13 Oct 1997 20:59:36 -0400 (EDT) Message-ID: <3442C600.2988@rcom.sei.co.jp> Date: Tue, 14 Oct 1997 10:21:19 +0900 From: Shin Yoshida Reply-To: yoshida@rcom.sei.co.jp Organization: Sumitomo Electric X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@tis.com Subject: Re: What do you do in case of initiate collisions? References: <199710131438.KAA19995@earth.hpc.org> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie Orman wrote: > > > >We're running into a bit of a problem and haven't found any specific > > >answers. Basically, we need to know how people are resolving the > > >problem where two systems start overlapping exchange sessions to > > >each other (the cross in the mail syndrome). > > > > > >It looks something like this > > > > > >A ----> B (A initiates a session with B) > > >A <---- B (B initiates a session with A) > > Can A simply assume that B is responding? If the request packet from B proposes two or more transforms, how should A respond to the "response"? Shin From owner-ipsec Mon Oct 13 21:36:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06483 for ipsec-outgoing; Mon, 13 Oct 1997 21:35:35 -0400 (EDT) Message-Id: <199710140145.SAA25453@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yoshida@rcom.sei.co.jp Cc: Hilarie Orman , ipsec@tis.com Subject: Re: What do you do in case of initiate collisions? In-Reply-To: Your message of "Tue, 14 Oct 1997 10:21:19 +0900." <3442C600.2988@rcom.sei.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 18:45:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shin, > > > >We're running into a bit of a problem and haven't found any specific > > > >answers. Basically, we need to know how people are resolving the > > > >problem where two systems start overlapping exchange sessions to > > > >each other (the cross in the mail syndrome). > > > > > > > >It looks something like this > > > > > > > >A ----> B (A initiates a session with B) > > > >A <---- B (B initiates a session with A) > > > > Can A simply assume that B is responding? > > If the request packet from B proposes two or more > transforms, how should A respond to the "response"? He should respond the same way as if this message from A was the only one. Depending on the proposal #'s in the SA you decide whether it's a logical AND or a logical OR of the transforms and select accordingly. The fact that A is simultaneously initiating with B will also not impact this one bit. Each side chooses a M-ID to identify the transient state that a Quick Mode entails. A knows that the first message from B is, in fact, a new initial request and not a response to his initial request. The two exchanges progress independently. Dan. From owner-ipsec Tue Oct 14 00:26:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA07250 for ipsec-outgoing; Tue, 14 Oct 1997 00:25:05 -0400 (EDT) Message-ID: <3442F71E.AB2@rcom.sei.co.jp> Date: Tue, 14 Oct 1997 13:46:40 +0900 From: Shin Yoshida Reply-To: yoshida@rcom.sei.co.jp Organization: Sumitomo Electric X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: What do you do in case of initiate collisions? References: <199710140145.SAA25453@dharkins-ss20> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: : > > > > >We're running into a bit of a problem and haven't found any specific > > > > >answers. Basically, we need to know how people are resolving the > > > > >problem where two systems start overlapping exchange sessions to > > > > >each other (the cross in the mail syndrome). > > > > > > > > > >It looks something like this > > > > > > > > > >A ----> B (A initiates a session with B) > > > > >A <---- B (B initiates a session with A) > > > > > > Can A simply assume that B is responding? > > > > If the request packet from B proposes two or more > > transforms, how should A respond to the "response"? > > He should respond the same way as if this message from A was the only one. > Depending on the proposal #'s in the SA you decide whether it's a logical > AND or a logical OR of the transforms and select accordingly. > > The fact that A is simultaneously initiating with B will also not impact > this one bit. Each side chooses a M-ID to identify the transient state > that a Quick Mode entails. A knows that the first message from B is, in > fact, a new initial request and not a response to his initial request. > The two exchanges progress independently. I know the two exchanges progress independently. The problem is I don't want two set of SAs, and I'd like to know how people would get only one set of SAs. I think Lewis McCarthy wrote: > If so, we could just make a rule that > (say) the party with the lexicographically "larger" ID drops its > session initiation, and continues with the session initiated by the > "smaller" ID'ed party. could be the answer of my question. And I'd like to see this kind of words in the document. Shin From owner-ipsec Tue Oct 14 01:39:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA07540 for ipsec-outgoing; Tue, 14 Oct 1997 01:38:05 -0400 (EDT) Message-Id: <199710140548.WAA25536@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yoshida@rcom.sei.co.jp Cc: ipsec@tis.com Subject: Re: What do you do in case of initiate collisions? In-Reply-To: Your message of "Tue, 14 Oct 1997 13:46:40 +0900." <3442F71E.AB2@rcom.sei.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 1997 22:48:12 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > I know the two exchanges progress independently. > The problem is I don't want two set of SAs, and > I'd like to know how people would get only one > set of SAs. Well I can tell you how we do it, your mileage may vary. Put jitter on your timer (either add or subtract some small random interval to your timeout) so that it is highly unlikely that both sides will begin initiation at the same time. In the highly unlikely case that both do then the last set of SAs stuffed in your SADB become paramount (you start using the outbound SA for outbound packets) and you prematurely age the previous set-- don't just remove them, give them some unrealisticly low age like 20 seconds. This problem really arises when your implementation speaks to a sibling since both will begin negotiation at approximately the same time (like 45 seconds before the in-use SAs die or 30 seconds or 62 seconds or whatever) but when you speak to another vendor it shouldn't happen. When do you begin negotiation of a new set? It's probably different than ours which is probably different than . And if you add jitter to your timer it's not an issue. You have to realize that both sides must be kicked at times whose difference is not greater than the time it takes a packet to transverse the net from one host to another. That can happen. It doesn't happen alot but it does happen. And when it does it's not really a problem. Dan. From owner-ipsec Tue Oct 14 08:30:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09910 for ipsec-outgoing; Tue, 14 Oct 1997 08:27:14 -0400 (EDT) Date: Tue, 14 Oct 1997 15:36:27 +0300 (EET DST) Message-Id: <199710141236.PAA13733@pilari.ssh.fi> From: Tero Kivinen To: Daniel Harkins Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: <199710131803.LAA24862@dharkins-ss20> References: <199710131533.SAA14861@pilari.ssh.fi> <199710131803.LAA24862@dharkins-ss20> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 19 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > > 1) The oakley draft specifies the format of variable lenght > > integers, but that format is NOT used by isakmp/oakley. The > > isakmp/oakley draft should say how variable length integers > > are send in KE payloads (length in payload length, data > > directly in payload, no extra padding), and how they should > > be added to HASH (are leading zeros allowed in g^x) > The base ISAKMP draft defines this. There would be no padding added unless > this was the last payload in a Quick Mode exchange and it was necessary > for encryption. I was not talking about payload paddings, I was talking about padding the variable length integer in the payload and encoding of it in the payload. The isakmp draft just says the key exchange payload contains the key exchange data that is specified by the doi and the associated key exchange algorithm. The oakley draft says: ] In the following we indicate where each OAKLEY field appears in the ] ISAKMP message structure. These are recommended only; the Resolution ] document will be the final authority on this mapping. ] CKY-I ISAKMP header ] CKY-R ISAKMP header ] MSGTYPE Message Type in ISAKMP header ] GRP SA payload, Proposal section ] g^x (or g^y) Key Exchange Payload, encoded as a variable precision integer ... and then it defines encoding for variable precision integers as following: ]APPENDIX C Encoding a variable precision integer. ] ] ] Variable precision integers will be encoded as a 32-bit length field ] followed by one or more 32-bit quantities containing the ] representation of the integer, aligned with the most significant bit ] in the first 32-bit item. ] ] 1 2 3 ] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ! length ! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ! first value word (most significant bits) ! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ! ! ] ~ additional value words ~ ] ! ! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ] An example of such an encoding is given below, for a number with 51 ] bits of significance. The length field indicates that 2 32-bit ] quantities follow. The most significant non-zero bit of the number ] is in bit 13 of the first 32-bit quantity, the low order bits are in ] the second 32-bit quantity. ] ] 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 ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ! 1 0! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x! ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, that the length field have the number of 32 bit words and the integer itself is always prefixed with zeros so its length will be will be multiple of 32 bits. So when I read those drafts I assumed that this encoding was used, because the isakmp-oakley draft or doi didn't say anything to modify this. Also if we interpret the value in KE payload as variable precision integer it value remains same even if we add the zeros in front of it. This means the Diffie-Hellman might succeed (if we don't check the length in bytes, but check that value is smaller than p), but then we have to use the form transmitted on wire (with leading bytes of zeros) in hash, not the variable precision integer used in Diffie-Hellman calculations. BTW, if I understand isakmp-08 correctly it says the complete message (but not the payloads inside the message) MUST be padded to 4 byte boundary (that is before encryption padding is added): ] 3 ISAKMP Payloads ... ] changes (see Section 4) are shown using network octet ordering. Addition- ] ally, all ISAKMP messages MUST be aligned at 4-octet multiples. > Let me know how that sounds. Suggested text is greatly appreciated if this > is not adequate. Sounds good. > > 4) Draft should state clearly that there is only one cipher > > context/IV shared in both directions. At least I > > automatically assumed there is one cipher context/IV > > for encryption and one for decryption (ie separate contexts > > for each direction). > Can you tell me where you think this should go? Along with the description > of IV generation for phase 1 (in Appendix B)? Yes, just adding something at end of this paragraph in appendix B: ... ] pad since this reflects the size of the cyphertext. Subsequent ] messages MUST use the last CBC encryption block from the previous ] message as their initialization vector. -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Oct 14 08:59:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10135 for ipsec-outgoing; Tue, 14 Oct 1997 08:56:47 -0400 (EDT) Date: Tue, 14 Oct 1997 16:06:24 +0300 (EET DST) Message-Id: <199710141306.QAA14026@pilari.ssh.fi> From: Tero Kivinen To: Lewis McCarthy Cc: IP Security List Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: <3442AE2A.237C@cs.umass.edu> References: <199710122213.PAA24340@dharkins-ss20> <199710131533.SAA14861@pilari.ssh.fi> <3442AE2A.237C@cs.umass.edu> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 19 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy writes: > ISAKMP specifies the length of each cookie (Sec 3.1), and presumably > everyone can deduce the expected length of each public exponential > from the group descriptor. This leaves SAp, IDii, and IDir. I first concerned about the g^xi and g^xr, but I couldn't find any way to attack them (even against code that doesn't chack that g^x < p). So I started to think about the SAp and ID pairs too. > (SAp_at_I | IDir_at_I) = (SAp | IDir). For authentication with > signatures or with a preshared key, the useful (to an attacker) choices > of different ISAKMP identities would seem to be very limited. The > attacker would not learn the agreed session key if this worked, but > perhaps could cause one or both legitimate parties to accept a mistaken > identity for the peer. The correct SAp and the modified SAp_at_I would > need to specify reasonably compatible sets of transforms, or the whole > conversation will fall apart. I didn't have time to check if one can really do any real attacks using this, but it gives me bad feelings that someone might someday find attack to use this. Adding the lengths to HASH now would make sure no one will find such attack later. If someone finds such attack later modifying the protocol will be much harder then... > Now it would be interesting to see whether the SAp might be modified, > subject to the constraints above, so as to alter the group choice and > thus cast the lengths of the public exponentials into doubt.... -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Oct 14 09:20:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10394 for ipsec-outgoing; Tue, 14 Oct 1997 09:19:12 -0400 (EDT) Date: Tue, 14 Oct 1997 16:28:32 +0300 (EET DST) Message-Id: <199710141328.QAA14220@pilari.ssh.fi> From: Tero Kivinen To: Daniel Harkins Cc: John Burke , ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: <199710132254.PAA25264@dharkins-ss20> References: <3.0.32.19971013140414.0096dc60@192.43.161.2> <199710132254.PAA25264@dharkins-ss20> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 20 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > > I would agree that group-parameter attributes should be forbidden for the > > standard groups. > That is exactly it! If the group is known by a Group Descriptor (whether > because it's one defined in the draft-- there are now 4 groups-- or whether > it's one you have via New Group Mode-- then that's all you use to > identify it. I was thinking about doing implicit new group mode negotiation when negotiating the Isakmp SA when defining the group by its component parts. Then it would be easier if I could use the same group also in phase II directly. Now I have to do following: 1) Negotiate Isakmp SA with group(modp, 2, p) 2) Make new group mode negotiation to renegotiate group(modp, 2, p) and give it private group number 52312. 3) Start Quick mode negotiation using group 52312. If the group descriptor number is allowed also in when negotiating Isakmp SA then it would go like this: 1) Negotiate Isakmp SA with group(modp, 2, p) and give it private group number 52312. 2) Start Quick mode negotiation using group 52312. I agree that sending ANY parameters for any standard group should be considered as an error. Ie I would change it not to forbid group descriptor when there are paramters, I would change it to forbid the group parameters when the group descriptor is not private group. > Perhaps if I quote the draft you can tell me if it's unclear. In the section > that describes the attributes that must be negotiated in phase 1 it says: > > "The Diffie-Hellman group MUST be either specified using a defined > group description (section 6) or by defining all attributes of a > group (section 5.7). Group attributes (such as group type or > prime-- see Appendix A) MUST NOT be offered in conjunction with a > previously defined group." So this forbids to have any group attributes when using predefined group. I assume that the predefined group here means the groups defined in the draft (or reserved by draft, ie 1-32767)? -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Oct 14 12:25:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11632 for ipsec-outgoing; Tue, 14 Oct 1997 12:21:55 -0400 (EDT) Message-ID: In-Reply-To: <199710122213.PAA24340@dharkins-ss20> References: Conversation <199710122213.PAA24340@dharkins-ss20> with last message <199710122213.PAA24340@dharkins-ss20> To: Daniel Harkins Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Re: proposed changes to ISAKMP/Oakley Date: Tue, 14 Oct 97 18:31:50 PDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In "proposed changes to ISAKMP/Oakley", Daniel Harkins wrote: > * added 2 new optional Diffie-Hellman groups, a EC2N group with field > element size 155 and a EC2N group with field element size 185. > Hi Dan, I suggest to add not only EC2N groups but also elliptic curve groups over GF[p] with an odd prime p because these curves seem to be more favourable: EC groups over GF[p] can easily be implemented by using only ordinary modular arithmetic originally developed for RSA for example. Furthermore in contrast to char 2, use of this type of curves seems to be widely free of patents. Michael From owner-ipsec Tue Oct 14 13:36:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12076 for ipsec-outgoing; Tue, 14 Oct 1997 13:32:26 -0400 (EDT) Message-Id: <199710141742.KAA26559@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: more...changes to ISAMKP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Oct 1997 10:42:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I received another unicast email in which the author raised an issue regarding the use of the DOI in ISAKMP/Oakley. Right now we have just the IPSec DOI. Eventually (I hope), we'll have the SNMPv3 DOI, the BGP DOI, the RIPv2 DOI, etc. Any service that needs an authenticated key for whatever purpose can defined a magic number range, claim a DOI value and we're off.... With that in mind the issue is one of crossing one's streams so to speak. If I initiate an exchange for IPSec I'm gonna set the DOI field of the phase 1 offer to the value for the IPSec DOI. Then when we negotiate the actual IPSec SAs I do the same. But what if we negotiate "SAs" for the BGP DOI. We're doing that under the protection of the ISAKMP SA that was created with the IPSec DOI. Problem? I dunno. This has been raised as a problem though. So, I'd like to make a proposal for a change. I haven't made the change and I won't unless I get some backing. The ISAKMP/Oakley draft will define a DOI value of 0 as being perfectly acceptable for phase 1 offers. In that case the situation is similarly 0. This will state that the ISAKMP SA is free to protect any other DOI in phase 2 without fear of crossing one's streams and the calamity that will befall one who does. If the DOI value in the phase 1 offer is other than 0 it will be up to the implementation to declare whether it is acceptable to use this ISAKMP SA to protect the services of other DOIs whose values don't match the phase 1 DOI value. It will be legal to restrict an IPSec DOI-established ISAKMP SA to only establish IPSec SAs. Then if a need for a SNMPv3 "SA" arrives, an entire phase 1 + phase 2 will have to be performed and now there'll be 2 ISAKMP SAs-- one only for IPSec; one only for SNMP. This won't affect bits-on-the-wire because we have just the IPSec DOI right now and the behaviour we're engaging in now is perfectly acceptable. When new DOIs become available implementations which support them will have to take this new concept into account. What say you? Dan. From owner-ipsec Tue Oct 14 15:39:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12849 for ipsec-outgoing; Tue, 14 Oct 1997 15:34:27 -0400 (EDT) Date: Tue, 14 Oct 1997 15:44:38 -0400 (EDT) Message-Id: <199710141944.PAA23447@carp.morningstar.com> From: Ben Rogers To: Daniel Harkins Cc: ipsec@tis.com Subject: more...changes to ISAMKP/Oakley In-Reply-To: <199710141742.KAA26559@dharkins-ss20> References: <199710141742.KAA26559@dharkins-ss20> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > I received another unicast email in which the author raised an issue > regarding the use of the DOI in ISAKMP/Oakley. > > Right now we have just the IPSec DOI. Eventually (I hope), we'll have > the SNMPv3 DOI, the BGP DOI, the RIPv2 DOI, etc. Any service that needs > an authenticated key for whatever purpose can defined a magic number > range, claim a DOI value and we're off.... > > With that in mind the issue is one of crossing one's streams so to speak. > If I initiate an exchange for IPSec I'm gonna set the DOI field of the > phase 1 offer to the value for the IPSec DOI. Then when we negotiate the > actual IPSec SAs I do the same. But what if we negotiate "SAs" for the > BGP DOI. We're doing that under the protection of the ISAKMP SA that was > created with the IPSec DOI. Problem? I dunno. This has been raised as a > problem though. > > So, I'd like to make a proposal for a change. I haven't made the change > and I won't unless I get some backing. > > The ISAKMP/Oakley draft will define a DOI value of 0 as being perfectly > acceptable for phase 1 offers. In that case the situation is similarly 0. ... As the author of the unicast email in question I am, of course, in favor of seeing this change. I would suggest, on top of this change, adding an additional document to the group of "near standards track" drafts. This document would outline an ISAKMP/Oakley DOI, for use in negotiating Phase 1 ISAKMP/Oakley SA's. If there is enough support, I'd be more than happy to write such a document myself. If this is an acceptable move to the group, I'd like to further suggest that the IPsec DOI and ISAKMP/Oakley documents be modified to deprecate the PROTO_ISAKMP number and to suggest that the Phase 1 negotiation of the ISAKMP/Oakley SA be logically detached from the negotiation of the IPsec SA. I have been bothered that IPsec itself has to do the work to negotiate the ISAKMP SA (which should be logically different modules) which provided the essential motivation for this suggestion. I know that we are not supposed to change bits on the wire, so it seems that the best we can do is to deprecate the value with the hope that it will eventually weed itself out. Comments? ben From owner-ipsec Tue Oct 14 16:20:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13137 for ipsec-outgoing; Tue, 14 Oct 1997 16:19:57 -0400 (EDT) Message-ID: <01BCD8A5.42DE4E40.rwt@vpnet.com> From: Robert Tashjian Reply-To: "rwt@vpnet.com" To: "'ipsec@tis.com'" , "'anx-sec'" Subject: Re: What do you do in the case of initiate collisions? Date: Tue, 14 Oct 1997 13:29:55 -0700 Organization: VPNet Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I originally posted this only to the anx-sec list, but it seems to have migrated to the ipsec list. Here's the original text and some additional information on the problem. We run into the collision problem because 1) we have a lot of bi- directional traffic from multple hosts, and 2) we added a network delay of about 5-10 seconds to simulate latency. That latency number could be a lot worse. We were looking at the {power fail, 8am Monday morning} problem. In the case where an ISAKMP SA between hosts does not exist, A and B start to negotiate within the latency window: A ---> B {HDR, SA} where Ci = cookie_a, Cr = 0, MID = 0 B ---> A {HDR, SA} where Ci = cookie_b, Cr = 0, MID = 0 because at this point, B hasn't received A's request and vice-versa. A ---> B {HDR, SA} where Ci = cookie_b, Cr = cookie_a, MID = 0 B ---> A {HDR, SA} where Ci = cookie_a, Cr = cookie_b, MID = 0 Unless there is some protocol, such as x.25 address comparison, to deterministically decide which SA request to drop, I can't see anyway to avoid creating two ISAKMP SA's. I don't think this is a security problem, because both hosts have agreed to the proposals, but it's kind of a pain because now you have two ISAKMP SA's and you have to decide between them. Another issue, the Cisco reference implementation generates a single stamp to be used in generating the cookie. In order to support multiple ISAKMP SA's between hosts, we will generate a cookie based on the the remote ip address and a thing stored in our ISAKMP SA. Will this break anybody's implementation? -- Original Message Follows -- We're running into a bit of a problem and haven't found any specific answers. Basically, we need to know how people are resolving the problem where two systems start overlapping exchange sessions to each other (the cross in the mail syndrome). It looks something like this A ----> B (A initiates a session with B) A <---- B (B initiates a session with A) A <---- B (B responds to A's initial request) A ----> B (A responds to B's initial request) etc.. This problem results in an ambiguity at the creation of the ISAKMP SA's or, if it occurs during QM exchanges, the creation of two pairs of IPSEC SA's (one for each of the exchanges). There are a variety of ways to resolve this a) both back off and retry later. b) collision resolution based on IP address or cookie comparison, etc. c) just keep both pairs of SA's around and assume any of them can be used until they naturally age out. This means that you may be sending on one set of SA's and receiving on another; does this break anything? d) generate both pairs of IPSEC SA's and send a DELETE for the outbound SA you won't use (and a DELETE for the corresponding inbound SA after receiving the outbound SA DELETE). Since this may delete one side from each pair of the SA's, does this break anything? d) ignore the whole thing and hope it will go away, etc :^) e) etc. Has there been a consensus on how to handle this case? If not, what are people doing to handle this case. Also, it would seem that the handling should be different for the ISAKMP SA's than for the IPSEC SA's or any other SA's created under the ISAKMP SA umbrella. And does anyone's ISAKMP implementation allow more than one ISAKMP SA per host (ie., per src.-dst. pair)? Thanks, rwt --- Robert Tashjian VPNet Technologies, Inc. rwt@vpnet.com From owner-ipsec Tue Oct 14 16:48:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13289 for ipsec-outgoing; Tue, 14 Oct 1997 16:44:30 -0400 (EDT) Message-Id: <199710142055.NAA26788@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "rwt@vpnet.com" , anx-sec@dot.netrex.net Cc: "'ipsec@tis.com'" Subject: Re: What do you do in the case of initiate collisions? In-Reply-To: Your message of "Tue, 14 Oct 1997 13:29:55 PDT." <01BCD8A5.42DE4E40.rwt@vpnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Oct 1997 13:55:09 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert, > We run into the collision problem because 1) we have a lot of bi- > directional traffic from multple hosts, and 2) we added a network > delay of about 5-10 seconds to simulate latency. That latency > number could be a lot worse. We were looking at the {power fail, > 8am Monday morning} problem. > > In the case where an ISAKMP SA between hosts does not exist, A and > B start to negotiate within the latency window: > > A ---> B {HDR, SA} where Ci = cookie_a, Cr = 0, MID = 0 > B ---> A {HDR, SA} where Ci = cookie_b, Cr = 0, MID = 0 > because at this point, B hasn't received A's request and vice-versa. > > A ---> B {HDR, SA} where Ci = cookie_b, Cr = cookie_a, MID = 0 > B ---> A {HDR, SA} where Ci = cookie_a, Cr = cookie_b, MID = 0 > > Unless there is some protocol, such as x.25 address comparison, to > deterministically decide which SA request to drop, I can't see anyway > to avoid creating two ISAKMP SA's. I don't think this is a security > problem, because both hosts have agreed to the proposals, but it's > kind of a pain because now you have two ISAKMP SA's and you have > to decide between them. You can't really just decide to delete one anyway-- in my opinion. If one side wanted PFS for identities as well as keys he'd remove the ISAKMP SA as soon as the IPSec SAs were established. The other side may have no such requirement on the IPSec SAs it's creating. (Imagine the 1st is for telnet to a sensitive machine and is 3DES w/HMAC-SHA; the other is just for ftp to a different host and is AH-HMAC-MD5. Pardon my router-centric frame of mind). The choice is easy. If you created it use it. You can modify your reaper (assuming you've got a reaper) that could reap duplicate ISAKMP SAs regardless of their lifetime if you really don't like having duplicates lying around. > Another issue, the Cisco reference implementation generates a single > stamp to be used in generating the cookie. In order to support multiple > ISAKMP SA's between hosts, we will generate a cookie based on the > the remote ip address and a thing stored in our ISAKMP SA. Will this > break anybody's implementation? Ah, the good old cisco reference implementation.... I'll be changing that realsoonnow. The cookie just has to be unique for the peer. This can be done by setting the first 1/2 of the cookie to be random noise and the rest to the hash of the stamp + the peer's address + whatever else you feel like including in your cookies. That way in your example above the cookie_a that is the result of A's initiation would be different than the cookie_a that is the result of A's response to B's initiation. In fact, it would be different than another cookie_a that is the result of another initiation by A. Since your construction of the cookie is completely up to you it shouldn't break anybody's implementations. Dan. From owner-ipsec Tue Oct 14 20:03:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA14269 for ipsec-outgoing; Tue, 14 Oct 1997 19:59:35 -0400 (EDT) Message-ID: <01BCD8C4.2C2A71A0.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'Daniel Harkins'" , "ipsec@tis.com" Subject: RE: more...changes to ISAMKP/Oakley Date: Tue, 14 Oct 1997 11:36:21 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk I support this proposal. Baiju ----------------------------------------------------------------------------------------- Baiju V. Patel 503 264 2422 -----Original Message----- From: Daniel Harkins [SMTP:dharkins@cisco.com] Sent: Tuesday, October 14, 1997 10:43 AM To: ipsec@tis.com Subject: more...changes to ISAMKP/Oakley I received another unicast email in which the author raised an issue regarding the use of the DOI in ISAKMP/Oakley. Right now we have just the IPSec DOI. Eventually (I hope), we'll have the SNMPv3 DOI, the BGP DOI, the RIPv2 DOI, etc. Any service that needs an authenticated key for whatever purpose can defined a magic number range, claim a DOI value and we're off.... With that in mind the issue is one of crossing one's streams so to speak. If I initiate an exchange for IPSec I'm gonna set the DOI field of the phase 1 offer to the value for the IPSec DOI. Then when we negotiate the actual IPSec SAs I do the same. But what if we negotiate "SAs" for the BGP DOI. We're doing that under the protection of the ISAKMP SA that was created with the IPSec DOI. Problem? I dunno. This has been raised as a problem though. So, I'd like to make a proposal for a change. I haven't made the change and I won't unless I get some backing. The ISAKMP/Oakley draft will define a DOI value of 0 as being perfectly acceptable for phase 1 offers. In that case the situation is similarly 0. This will state that the ISAKMP SA is free to protect any other DOI in phase 2 without fear of crossing one's streams and the calamity that will befall one who does. If the DOI value in the phase 1 offer is other than 0 it will be up to the implementation to declare whether it is acceptable to use this ISAKMP SA to protect the services of other DOIs whose values don't match the phase 1 DOI value. It will be legal to restrict an IPSec DOI-established ISAKMP SA to only establish IPSec SAs. Then if a need for a SNMPv3 "SA" arrives, an entire phase 1 + phase 2 will have to be performed and now there'll be 2 ISAKMP SAs-- one only for IPSec; one only for SNMP. This won't affect bits-on-the-wire because we have just the IPSec DOI right now and the behaviour we're engaging in now is perfectly acceptable. When new DOIs become available implementations which support them will have to take this new concept into account. What say you? Dan. From owner-ipsec Wed Oct 15 16:45:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20824 for ipsec-outgoing; Wed, 15 Oct 1997 16:35:17 -0400 (EDT) Message-ID: <34452E43.E1A08959@newoak.com> Date: Wed, 15 Oct 1997 16:57:39 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: more...changes to ISAMKP/Oakley X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I think the change as proposed by Dan (i.e., allowing a DOI value of zero for Phase 1 negotiations) is fine. OTOH, I'm having a difficult time seeing the need for a separate ISAKMP/Oakley DOI, or for eliminating/deprecating PROTO_ISAKMP. Using a DOI of zero in Phase 1 should achieve whatever "logical separation" between IPsec and ISAKMP might be desired. PROTO_ISAKMP is defined as a reserved value across all DOIs (see the isakmp-08 draft, section A.2.2), and I see no reason why that should not continue to be the case. Unless there's some additional justification for these changes, I'd rather see things remain as they are. -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Oct 15 20:10:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21890 for ipsec-outgoing; Wed, 15 Oct 1997 20:03:50 -0400 (EDT) Message-Id: <199710160014.RAA27847@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: smamros@newoak.com (Shawn Mamros) Cc: ipsec@tis.com Subject: Re: more...changes to ISAMKP/Oakley In-Reply-To: Your message of "Wed, 15 Oct 1997 16:57:39 EDT." <34452E43.E1A08959@newoak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 1997 17:14:05 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > I think the change as proposed by Dan (i.e., allowing a DOI value of > zero for Phase 1 negotiations) is fine. Great. I think we have critical mass-- 4 people! > OTOH, I'm having a difficult time seeing the need for a separate > ISAKMP/Oakley DOI, or for eliminating/deprecating PROTO_ISAKMP. > Using a DOI of zero in Phase 1 should achieve whatever "logical > separation" between IPsec and ISAKMP might be desired. PROTO_ISAKMP > is defined as a reserved value across all DOIs (see the isakmp-08 > draft, section A.2.2), and I see no reason why that should not > continue to be the case. Unless there's some additional justification > for these changes, I'd rather see things remain as they are. Agreed. So then, how does this sound everyone: "This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non-ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST97] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA." Dan. From owner-ipsec Wed Oct 15 20:22:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA22033 for ipsec-outgoing; Wed, 15 Oct 1997 20:22:20 -0400 (EDT) Message-Id: <199710160029.RAA16933@pita.cisco.com> To: Daniel Harkins cc: smamros@newoak.com (Shawn Mamros), ipsec@tis.com Subject: Re: more...changes to ISAMKP/Oakley In-reply-to: Your message of "Wed, 15 Oct 1997 17:14:05 PDT." <199710160014.RAA27847@dharkins-ss20> Date: Wed, 15 Oct 1997 17:29:25 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk This new text works for me. Derrell From owner-ipsec Wed Oct 15 21:31:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA22343 for ipsec-outgoing; Wed, 15 Oct 1997 21:28:49 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199710122213.PAA24340@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 1997 21:37:24 -0400 To: Daniel Harkins From: Stephen Kent Subject: Re: proposed changes to ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, * added a clarification on the use of proxy IDs in Quick Mode which states: "The proxy identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. Local policy will determine whether packets which do not match the proxy information on which a tunnel was created will be forwarded upon leaving the tunnel." The 2nd part might actually belong in the Architecture Draft and I'll entertain offers from Steve Kent to remove this text and have it added there but I think there is a general confusion on this capability and it should be clarified (some people had mentioned situations where "I don't 'do proxy' but the other guy does" as if it was some additional capability like doing Aggressive Mode). In fact, it might make sense to say that if proxy identities are used in negotiation of tunnels that traffic which does not match that information MUST NOT be stuffed in the tunnel. I was planning to put similar text in the architecure document, but not necessarily with the same spin. I had received a couple of suggetsions that this be mandatory, not just a local option. It is applicable not only to proxy tunnel SAs, but to any SA, to detect an attempt by an authorized sender from spoofing packets from another source, right? Maybe we need to solicit WG opinion on this Steve From owner-ipsec Thu Oct 16 18:05:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA29594 for ipsec-outgoing; Thu, 16 Oct 1997 18:01:06 -0400 (EDT) From: pau@watson.ibm.com Date: Thu, 16 Oct 1997 18:12:08 -0400 Message-Id: <9710162212.AA25066@secpwr.watson.ibm.com> To: ipsec@tis.com Subject: Re: more...changes to ISAMKP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: VR0VSPOfoazUm1siCiVdKQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan's new text is fine with me. Pau-Chen From owner-ipsec Thu Oct 16 18:22:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA29715 for ipsec-outgoing; Thu, 16 Oct 1997 18:22:36 -0400 (EDT) From: pau@watson.ibm.com Date: Thu, 16 Oct 1997 18:34:09 -0400 Message-Id: <9710162234.AA22512@secpwr.watson.ibm.com> To: dharkins@cisco.com Subject: Re: more...changes to ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: BwIr9W2/M+kXeMpRRtgsvw== Sender: owner-ipsec@ex.tis.com Precedence: bulk I just sent a note saying Dan's text is OK with me. But on 2nd thought, I would like to suggest 2 clarifications: 1. DOI defines the syntax and semantics of identities. So when using DOI 0, should we also use the ID's defined in the internet DOI ? 2. Right now the ISAKMP/OAKLEY draft clearly defines how phase II uses phase I's results. If we want to decouple phase I from phase II, we probably should state clearly the results of phase I and their usages in a manner indepedent of the phase II protocol. Pau-Chen From owner-ipsec Thu Oct 16 19:41:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00057 for ipsec-outgoing; Thu, 16 Oct 1997 19:39:05 -0400 (EDT) From: Cheryl Madson Message-Id: <199710162349.QAA22385@trix.cisco.com> Subject: Comments on AH and ESP drafts To: ipsec@tis.com Date: Thu, 16 Oct 1997 16:49:32 -0700 (PDT) Cc: cmadson@cisco.com (Cheryl Madson) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It's possible that I may have more comments after I finish reading the other drafts and correlating them back to these drafts. I haven't had the cycles to read all of the recent email discussing the drafts, so if there is duplication here, sorry about that. I understand that some of the things that I'm commenting on have probably existed in the drafts for some time; unfortunately I don't always catch these, even with doing detailed reads ;-(. - C Many of these comments apply to both drafts, so I'll list those first. 1. Put in the boilerplate paragraph from RFC2119 (the one stating that readers should refer to 2119 for the definitions for MUST, etc.). [All of us should simply stick that paragraph into our respective documents and be done with it.] 2. Replay: in general, I had thought that the compromise proposal (receiver notifying sender of replay support) seemed reasonable. However, now as I read the specifics that have been put into these drafts, I want to revisit the topic. As a NOTIFY message is not a "guaranteed delivery" message, having the sender simply not do a sequence number rollover check because it didn't receive said message is a bad idea. The responder may have been a good citizen and sent the notify, but something may have prevented its delivery. I personally think it would be much cleaner for the sender to assume that the receiver will enforce replay, and assume that when the sender cycles through the sequence number space, if the sender does not force the creation of a new SA, that the receiver will drop packets (and audit) when it detects said cycling. The only place where the sender should not perform such a rollover check is for manually-keyed/installed/whatever SAs. If the receiver so chooses, it can still notify the sender of support (or better yet, lack thereof) for replay. 3. Size of authentication data: scattered throughout these drafts is the mention of "if algorithm yields more than 96 bits, the output is truncated". While it's been agreed to be approrpriate (and a good idea cryptographically) in the context of the HMAC auth algorithms, this may be completely off-base for any other type of auth algorithm. Yes, there has been a desire to limit the number of combinations of variables; I think we've been addressing that with the algorithm drafts. But I don't think we've intended it to be a universal rule. I think it's OK to state that the *default* auth data size is 96 bits, but remove the text that seems to indicate that 96 bits is the *only* size. [The main transform layout text is reasonably general in this regard -- we could talk about the default size there if so desired. Or if we don't talk about a default size, maybe we should remove the reference to "96 bits is the default auth data size as is stated in the base drafts" from the auth algorith drafts ;-).] 4. In the section on ICV verification, instead of the specific reference to 96 bits: replace with text saying "compare the result with the saved value, using the comparison rules defined by the authentication algorithm specification." 5. In the section on sequence number verification, the first sentence should state: "though its use may be enabled or disabled by the receiver on a per-SA basis." 6. Nesting of transforms. I know this was a topic on the list a while back, but I didn't have the cycles to think much about it, beyond having some nagging feeling about it that I couldn't put into words. (a) There are words to the effect of "the security policy MUST define the order of transforms". That's fine, but there's a good chance that I can't *negotiate* this with my peer. Why? From what I can tell, there is not a universal assumption of order in specifying the transforms in the proposal. In other words, "AH + ESP" is considered to be the same as "ESP + AH" for most implementors, meaning that the packets will be encapsulated as IP + AH + ESP. How will I be able to specify to my peer my desired order of IP + AH + ESP + ESP + AH, for example? Removing the ordering requirement would be a bad idea, I think. As a receiver, who only knows that I need to do (2 AHs and 2 ESPs), I may have to do a significant amount of unnecessary processing before determining that this was a malformed packet. As a receiver, it would be in my best interest to enforce a ordering, so if that first ESP was followed by an AH in the above example, I could declare the packet to be in error and not work on it anymore. (b) This nesting seems to only be specified for transport mode. Why is that? I can't convince myself of the usefulness of the general case, so I can't see where it's useful for one mode but not the other. (c) If there *is* going to be nesting such as above, the AH draft should be more careful about specifying the scope of the authentication calculation. Actually, it may be cleaner to remove the discussion of "ignoring the outer IPSEC headers in the AH calculation", and simply treat this as an interative process, where the AH is calculated on the "full" packet at the point of header insertion. Right now the supporting text on AH calculation is "partially" sensitive to nesting, but the concept is not consistently applied (some of the text refers to "partial" while other text refers to the full packet). [If a simple iterative approach is taken, it needs to be noted that as AH headers are "consumed" by the receiver, the ip->tl of the outer header *must* be adjusted so that the inner AH calculations are successful.] (d) I haven't understood the reasons *why* for such a nesting between the same source and destination IPSEC system. I can understand nesting of the type where one of the endpoints varies between the "inner" and "outer" nesting (for example, where a system that is an endpoint for both an IPSEC transport mode connection as well as an endpoint for an intervening tunnel: it builds a transport mode IPSEC packet to send to its final destination, but then has to reencapsulate it in tunnel mode to get it through the tunnel). But this particular style of nesting hasn't made sense to me. >From what I recall of the previous discussion, there wasn't much justification as to why this was desirable/needed, it seemed to be more along the line of "this could be an OK thing to do". The complexity of this worries me, and if we do support it, it needs to be better fleshed out, IMO. (e) In the AH draft, in the section on outbound packet processing, the last paragraph worries me. Especially the last sentence: "(While a native IP or bump-in-the stack implementation could predict the contents of later IPSEC headers that it applies itself, it won't be possible for it to predict any IPSEC headers added by a bump-in-the-wire implementation between the host and the network.)" I interpret this as a single IPSEC endpoint (single IP address) has multiple entities adding IPSEC headers to a single packet that is going to the same destination. These headers may or may not be separated by intervening IP headers. My issues: (1) given the above, how does this all get coordinated via ISAKMP? Separate negotiations won't work, as the receiver won't know that these are linked together, and won't build the correct sequence of headers for the return trip. (2) If I was worried about the general complexity of nesting before, I'm much more worried after reading this. Now for comments specific to the ESP draft: 1. Section 2, footnote to packet layout: here we state that the cryptographic synchronization data is a part of the Payload Data (fine), but elsewhere we state that the padding is done taking the size of the payload data field into account. That's OK if the (explicit) IV size is the same as the block size, but if it isn't, that could result in incorrect padding processing. The text that talks about padding processing should be more explicit in saying that the size of the Payload Data for padding purposes includes only the "to be encrypted data" portion of the Payload Data, or "everything except the IV". 2. Section 2.4 states that the Pad Length and Next Header fields should be right-aligned within a 4-byte word. Why? They will be stripped off of the end of the decapsulated packet. The reason given is that the ciphertext should terminate on a 4-byte boundary. To me, the only reason that I could come up with is to force alignment of the following authentication data field. Whether or not this is the case, some rationale for this padding requirement should be given. 3. While on the subject of alignment: I don't see a discussion of wanting to ensure that the *start* of the ciphertext should be aligned on a 64-bit boundary for IPv6 packets. In other words, 32-bit inline IVs may not be a good thing. If the IPv6-knowledgeable folks can give an opinion on this, and if they do strongly encourage alignment, something should be stated to make this a requirement for cipher algorithm writers (either in the ESP draft itself or the framework document). 4. Section 3.3.4. Insert the following (text in parenthesis): "implicit padding MUST be appended to the end of the ESP packet (logically after the Next Header field), prior to ICV" 5. Section 3.4.5, bullet item 2: if the receiver knows what the padding values will be (e.g. the WK padding is used), the receiver may check the padding values instead of simply ignoring them. Someone argued that using a WK padding scheme would help to check for decryption failures. 6. Section 3.4.5, paragraph starting "If authentication has been selected, ICV verification SHOULD be performed before decryption." This statement could be misconstrued. I think the intention is that the ICV verfication MUST be completed before the decryption completes, in the case where the steps are run in "parallel". 7. Same section: dicussion of detection of decryption failures could mention the use of the padding check. From owner-ipsec Fri Oct 17 16:33:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06723 for ipsec-outgoing; Fri, 17 Oct 1997 16:29:11 -0400 (EDT) From: Dan McDonald Message-Id: <199710172028.NAA06292@kebe.eng.sun.com> Subject: Proposed MLS section - "5.4 bis" To: ipsec@tis.com Date: Fri, 17 Oct 1997 13:28:44 -0700 (PDT) Cc: danmcd@kebe.eng.Sun.COM (Dan McDonald) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! The following proposed text consolidates and clarifies Multi-Level Secure (MLS)-specific text for the IP Security Architecture document. It is the output of a small team which met here at Sun on 10/16/97. Contrary to popular belief, MLS systems have significant deployment in the commercial sector (including Banking and Health Care). Members of this team include IPsec and MLS OS implementors from various commercial firms and the US DoD. The members of the team reached smooth consensus on the following text, which is designed to be a standalone section in the IP Security Architecture document. The text is based on section 5.4 of RFC 1825, hence the name "5.4 bis". It is intended to show IPsec's extensibility into MLS domains, without constraining the work that will be needed to fully integrate IPsec into an MLS environment. None of the following text applies to non-MLS systems, so anyone who is NOT doing an MLS implementation does not have to concern {him,her}self with the points raised below. Thanks! (NOTE: All names are in first-name alphabetical order.) THE TEAM (* == co-authors at the 10/16 meeting) =============================================== C. S. Lin (csl@cup.hp.com) * Dan McDonald (danmcd@eng.sun.com) * David Kemp (dpkemp@missi.ncsc.mil) Doug Hosking (???@cup.hp.com) * Gary Winiger (gww@ebay.sun.com) Gary Lowell (glowell@engr.sgi.com) * Mohan Parthasarathy (mohanp@eng.sun.com) * Matt Thomas (matt.thomas@altavista-software.com) * Ran Atkinson (rja@inet.org) p.s. Please send replies to the list and/or to all of the authors. I ask this because I will be virtually incommunicado for the next week. ===================== (Cut up to and including here.) ===================== 5.4 Use in Compartmented or Multi-Level Networks A multi-level secure (MLS) network is one where a single network is used to communicate data with different sensitivity information (e.g., Unclassified, Company Proprietary, Secret) [DoD85] [DoD87]. The IP security mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which ordinary users are incapable of controlling or violating [BL73]. This section pertains only to the use of these IP security mechanisms in MLS environments. Nothing in this section applies to systems not claiming to provide MLS. As used in this section, "sensitivity information" might include implementation-defined sensitivity levels, categories, and/or releasability information. The Authentication Header can be used to provide strong authentication among hosts in a single-level network. The Authentication Header can also be used to provide strong assurance for both mandatory access control decisions in multi-level networks and discretionary access control decisions in all kinds of networks. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header is used to provide authentication for the entire packet, including cryptographic binding of the sensitivity information to the IP header and user data. This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though it is not trustworthy because there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both. Encryption is very useful and desirable even when all of the hosts are within a protected environment. The Internet-standard encryption algorithm could be used, in conjunction with appropriate key management, to provide strong Discretionary Access Controls (DAC) in conjunction with either implicit or explicit sensitivity information (such as IPSO provides for IPv4 [Ken91]). Some environments might consider the Internet-standard encryption algorithm sufficiently strong to provide Mandatory Access Controls (MAC). Full encryption SHOULD be used for all communications between multi-level computers or compartmented mode workstations even when the computing environment is considered to be protected. 5.4.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide full multi-level secure networking. In this case each SA (or SA bundle) MUST be used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance". 5.4.2 Sensitivity Consistency Checking An MLS implementation MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet will arrive, or to which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix. The checking SHOULD be done on both inbound and outbound processing. 5.4.3 Additional MLS Attributes for Security Association Databases Section 4.4 details three Security Association databases. The first two, the Security Policy Database (SPD) and the Security Association Map (SAM), are used primarily for outbound traffic, though the SPD is also consulted after IPsec inbound processing, but before the IP datagram is passed to an application or forwarding engine. Both the SPD and the SAM use common selectors. MLS networking introduces an additional selector: - Sensitivity information. The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 5.4.1. The exact syntax of the sensitivity information is implementation defined. The third database is the Security Association Database (SAD). One additional SAD attribute is: - Sensitivity information. Sensitivity information is needed in the model shown in [BL73]. 5.4.4 Additional Inbound Processing Steps for MLS Networking After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity with the interface or address/prefix as described in section 5.4.2 before delivering the datagram to an upper-layer protocol. The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. 5.4.5 Additional Outbound Processing Steps for MLS Networking An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section X.Y.Z. When consulting the SPD or the SAM to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 5.4.2. 5.4.6 Additional MLS Processing for Security Gateways An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment. A security gateway MAY act as an outbound proxy for creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or perhaps the whole originating network has sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards. Similarly such a gateway SHOULD accept and process inbound AH and or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network. REFERENCES [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973. [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991. From owner-ipsec Fri Oct 17 19:11:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07509 for ipsec-outgoing; Fri, 17 Oct 1997 19:09:13 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199710162349.QAA22385@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Oct 1997 19:22:50 -0400 To: Cheryl Madson From: Stephen Kent Subject: Re: Comments on AH and ESP drafts Cc: ipsec@tis.com, cmadson@cisco.com (Cheryl Madson) Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl, Thanks for the detailed feedback on the AH and ESP specs. Below are responses to your comments: >1. Put in the boilerplate paragraph from RFC2119 (the one stating >that readers should refer to 2119 for the definitions for MUST, etc.). >[All of us should simply stick that paragraph into our respective >documents and be done with it.] Yes, that will be done. >2. Replay: in general, I had thought that the compromise proposal >(receiver notifying sender of replay support) seemed reasonable. >However, now as I read the specifics that have been put into these >drafts, I want to revisit the topic. > >As a NOTIFY message is not a "guaranteed delivery" message, >having the sender simply not do a sequence number rollover check >because it didn't receive said message is a bad idea. The responder >may have been a good citizen and sent the notify, but something >may have prevented its delivery. > >I personally think it would be much cleaner for the sender to >assume that the receiver will enforce replay, and assume that >when the sender cycles through the sequence number space, if >the sender does not force the creation of a new SA, that the receiver >will drop packets (and audit) when it detects said cycling. > >The only place where the sender should not perform such a rollover >check is for manually-keyed/installed/whatever SAs. > >If the receiver so chooses, it can still notify the sender of >support (or better yet, lack thereof) for replay. The ultimate responsibility for preventing replay lies with the receiver, so even if the NOTIFY is lost (in the current design), the receiver will not accept messages that appear to be replayed, even if they are just the result of counter overflow at the sender. Note that the AH and ESP specs don't call for counter overflow to trigger creation of a new SA; the counter overflow check is primarily an input to the audit mechanism and a backup to reduce the likelihood that packets will be sent that will be rejected. (Can't one cause the sender to create a new SA based on an algorithm-specific packet count trigger that is independent of sender checking of the AR counter?) Consider both choices of defaults for the sender: if the default is AR OFF (no counter checking), then the sender may continue to send packets while the receiver rejects them, and some trigger must be invoked to create a new SA to fix the problem; if the default is AR ON, then the sender may stop sending packets prematurely (given that the receiver was not checking) and some trigger must be invoked to create a new SA, as above. (But, to make this second default work one would have to special-case manual keying, which makes it not so clean ...) So the current text adopts the first default and uses NOTIFY to increase the likelihood that the sender and receiver have the same AR status notion, but it's imperfect because the NOTIFY is unreliable (and because sending the NOTIFY is a SHOULD, not a MUST). Without a reliable assertion of the receiver's AR status to the sender, we can only err in one direction or the other. If, on the other hand, we could have AR OFF as the default (to satisfy the manual keying case), the sender could negotiate AR ON, and the receiver could accept or reject the proposa. Then we would have a reliable, deterministic way for both ends to know the AR status and avoid these problems. We can live with the uncertainty implied by either of the non-negotiated choices, on the assumption that sender overflow is rare, i.e., lots of packets have to be sent before the problem arises. This is consistent with other design decisions we're making in IPsec, e.g., the race conditions in ISAKMP that have been discussed recently. Absent a compelling reason to choose one default vs. the other, let's stick with what we have now. >3. Size of authentication data: scattered throughout these drafts >is the mention of "if algorithm yields more than 96 bits, the output >is truncated". > >While it's been agreed to be approrpriate (and a good idea >cryptographically) in the context of the HMAC auth algorithms, >this may be completely off-base for any other type of auth algorithm. >Yes, there has been a desire to limit the number of combinations >of variables; I think we've been addressing that with the algorithm >drafts. But I don't think we've intended it to be a universal >rule. > >I think it's OK to state that the *default* auth data size is 96 >bits, but remove the text that seems to indicate that 96 bits is the >*only* size. [The main transform layout text is reasonably general >in this regard -- we could talk about the default size there if so >desired. Or if we don't talk about a default size, maybe we should >remove the reference to "96 bits is the default auth data size as >is stated in the base drafts" from the auth algorith drafts ;-).] Yes, this has been pointed out and has been changed. The 96-bit size is applicable to the default authentication algorithms, but other algorithms may define other auth data lengths. >4. In the section on ICV verification, instead of the specific >reference to 96 bits: replace with text saying "compare the result >with the saved value, using the comparison rules defined by the >authentication algorithm specification." > Good point. For a public key auth algorithm, the comparison procedure would be different. >5. In the section on sequence number verification, the first >sentence should state: "though its use may be enabled or disabled >by the receiver on a per-SA basis." The "per-receiver" clarification is appropriate and we'll make the change. >6. Nesting of transforms. I know this was a topic on the list a >while back, but I didn't have the cycles to think much about it, >beyond having some nagging feeling about it that I couldn't put >into words. Yes, there has been a lot of traffic on this topic, but I'd still rather spend the time to get it right, so your comments are still important. >(a) There are words to the effect of "the security policy MUST >define the order of transforms". That's fine, but there's a good >chance that I can't *negotiate* this with my peer. > >Why? From what I can tell, there is not a universal assumption of >order in specifying the transforms in the proposal. In other >words, "AH + ESP" is considered to be the same as "ESP + AH" for >most implementors, meaning that the packets will be encapsulated >as IP + AH + ESP. Then maybe this is a limitation of ISAKMP that needs to be addressed. Just as you have found it hard to find the time to review the AH and ESP specs, as the folks who have rewritten them (and the arch doc) from scratch, we've found it hard to make the time to review the ISAKMP, Oakley interpretation, and the IPsec DOI documents. There is a difference between the security functions afforded by different orderings of AH and ESP, so I think we need to be able to express the ordering requirements of the entity that will be sending traffic over the SA being established. >How will I be able to specify to my peer my desired order of > IP + AH + ESP + ESP + AH, for example? > >Removing the ordering requirement would be a bad idea, I think. >As a receiver, who only knows that I need to do (2 AHs and 2 ESPs), >I may have to do a significant amount of unnecessary processing >before determining that this was a malformed packet. As a receiver, >it would be in my best interest to enforce a ordering, so if that >first ESP was followed by an AH in the above example, I could declare >the packet to be in error and not work on it anymore. Agreed. >(b) This nesting seems to only be specified for transport mode. Why is >that? I can't convince myself of the usefulness of the general case, >so I can't see where it's useful for one mode but not the other. We'll review the wording. Arbitrary nesting is an issue for both tunnel and transport modes, but transport mode is more complicated when the same IP header is covered by multiple layers of AH. >(c) If there *is* going to be nesting such as above, the AH draft >should be more careful about specifying the scope of the authentication >calculation. Actually, it may be cleaner to remove the discussion >of "ignoring the outer IPSEC headers in the AH calculation", and >simply treat this as an interative process, where the AH is >calculated on the "full" packet at the point of header insertion. Right >now the supporting text on AH calculation is "partially" sensitive >to nesting, but the concept is not consistently applied (some of >the text refers to "partial" while other text refers to the full >packet). > >[If a simple iterative approach is taken, it needs to be noted that as >AH headers are "consumed" by the receiver, the ip->tl of the outer >header *must* be adjusted so that the inner AH calculations are >successful.] Charlie Lynn expressed the same notion in one of his messages, in response to a question from a WG member about how to do the processing. We'll make sure the final text expresses this notion of intertive processing and "discarding" of "consumed" headers at the receiver, if we retain the arbitrary nesting facility. >(d) I haven't understood the reasons *why* for such a nesting >between the same source and destination IPSEC system. I can >understand nesting of the type where one of the endpoints varies >between the "inner" and "outer" nesting (for example, where a system >that is an endpoint for both an IPSEC transport mode connection as >well as an endpoint for an intervening tunnel: it builds a transport >mode IPSEC packet to send to its final destination, but then has to >reencapsulate it in tunnel mode to get it through the tunnel). But >this particular style of nesting hasn't made sense to me. I have mixed feelings about this myself. I'm not in favor or arbitrary nesting, because of the potential complexity, but Charlie and a few other folks have argued in favor of allowing it, e.g., to accommodate the use of an outboard BITW implementation in conjunction with an integrated IPsec implementation, when each was ignorant of the presence of the other. I'd prefer to establish a limited set of ordered combinations of AH and ESP, in tunnel and transport modes, tailored to demonstrable, agreed upon host and gateway requirements. But, the WG has to decide on this and the traffic favored the sort of unconstrained nesting that Charlie proposed, so ... >>From what I recall of the previous discussion, there wasn't much >justification as to why this was desirable/needed, it seemed to >be more along the line of "this could be an OK thing to do". The >complexity of this worries me, and if we do support it, it needs >to be better fleshed out, IMO. The major motivation cited is a clause in the IPv6 spec about repeated extension headers, and the generic "be conservative in what you send but liberal in what you accept" admonition (attributed to Jon Postel). >(e) In the AH draft, in the section on outbound packet processing, >the last paragraph worries me. Especially the last sentence: "(While >a native IP or bump-in-the stack implementation could predict the >contents of later IPSEC headers that it applies itself, it won't >be possible for it to predict any IPSEC headers added by a >bump-in-the-wire implementation between the host and the network.)" > >I interpret this as a single IPSEC endpoint (single IP address) has >multiple entities adding IPSEC headers to a single packet that is >going to the same destination. These headers may or may not be >separated by intervening IP headers. See the example cited above as a motivation for this text. >My issues: (1) given the above, how does this all get coordinated >via ISAKMP? Separate negotiations won't work, as the receiver won't >know that these are linked together, and won't build the correct >sequence of headers for the return trip. (2) If I was worried >about the general complexity of nesting before, I'm much more >worried after reading this. > Interesting point. Whether the other end can build the correct sequence of headers for the return path would be a function of how the packets were mapped onto the SAs that all terminate at the same endpoint. I gather the argument is that unless multiple SAs are negotiated at the same time in ISAKMP, there is no way for IPsec to link together the SAs, even if they specify all the same selectors for outbound traffic. We need to resolve this, and that may provide a rationale for being more restrictive in allowable IPsec header nesting. > >Now for comments specific to the ESP draft: > >1. Section 2, footnote to packet layout: here we state that the >cryptographic synchronization data is a part of the Payload Data >(fine), but elsewhere we state that the padding is done taking the >size of the payload data field into account. > >That's OK if the (explicit) IV size is the same as the block size, but >if it isn't, that could result in incorrect padding processing. > >The text that talks about padding processing should be more explicit >in saying that the size of the Payload Data for padding purposes >includes only the "to be encrypted data" portion of the Payload Data, >or "everything except the IV". Good point. We'll reword to emphasize that the padding (for encryption algorithm purposes) computation applies to the plaintext portion of the payload, exclusive of the IV (if present). >2. Section 2.4 states that the Pad Length and Next Header fields >should be right-aligned within a 4-byte word. Why? They will be >stripped off of the end of the decapsulated packet. The reason >given is that the ciphertext should terminate on a 4-byte boundary. >To me, the only reason that I could come up with is to force >alignment of the following authentication data field. Whether or >not this is the case, some rationale for this padding requirement >should be given. Yes, the rationale is for alignment of the authentication data field. We can add that rationale. >3. While on the subject of alignment: I don't see a discussion of >wanting to ensure that the *start* of the ciphertext should be >aligned on a 64-bit boundary for IPv6 packets. In other words, >32-bit inline IVs may not be a good thing. If the IPv6-knowledgeable >folks can give an opinion on this, and if they do strongly encourage >alignment, something should be stated to make this a requirement >for cipher algorithm writers (either in the ESP draft itself or >the framework document). For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. This is an issue that needs to be addressed on a per-algorithm basis, and might even be per-implementation in reality, so other than a note about the possible pitfalls here, I'm not sure what to do. >4. Section 3.3.4. Insert the following (text in parenthesis): > >"implicit padding MUST be appended to the end of the ESP packet >(logically after the Next Header field), prior to ICV" OK, we will clarify the position of the implicit padding. >5. Section 3.4.5, bullet item 2: if the receiver knows what the >padding values will be (e.g. the WK padding is used), the receiver >may check the padding values instead of simply ignoring them. >Someone argued that using a WK padding scheme would help to >check for decryption failures. I think the agreement has been that checking for WK padding was optional at the receiver. We didn't require checking as that really is not a decryption failure but rather a (generally weak) form of integrity checking. Since we have an explicit integrity/authentication facility, the WG wanted to downplay the use of this field for that purpose. We can revise the text in this bullet to state that inbound processing of the padding is specific to the encryption algorithm spec, instead of just calling for the padding to be removed. >6. Section 3.4.5, paragraph starting "If authentication has been >selected, ICV verification SHOULD be performed before decryption." > >This statement could be misconstrued. I think the intention is >that the ICV verfication MUST be completed before the decryption >completes, in the case where the steps are run in "parallel". Good point. We want to allow parallel decryption and authentication and a note to that effect will be included. >7. Same section: dicussion of detection of decryption failures >could mention the use of the padding check. See my comments above about decryption failures vs. integrity check failures. Steve From owner-ipsec Sat Oct 18 14:51:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12274 for ipsec-outgoing; Sat, 18 Oct 1997 14:48:39 -0400 (EDT) Message-Id: <3.0.1.32.19971018115848.00755764@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 18 Oct 1997 11:58:48 -0700 To: kent@bbn.com From: Bob Monsour Subject: Re: Comments on AH and ESP drafts Cc: Cheryl Madson , ipsec@tis.com, cmadson@cisco.com (Cheryl Madson) In-Reply-To: References: <199710162349.QAA22385@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:22 PM 10/17/97 -0400, Stephen Kent wrote: [big snip] >>5. Section 3.4.5, bullet item 2: if the receiver knows what the >>padding values will be (e.g. the WK padding is used), the receiver >>may check the padding values instead of simply ignoring them. >>Someone argued that using a WK padding scheme would help to >>check for decryption failures. > >I think the agreement has been that checking for WK padding was optional at >the receiver. We didn't require checking as that really is not a >decryption failure but rather a (generally weak) form of integrity >checking. Since we have an explicit integrity/authentication facility, the >WG wanted to downplay the use of this field for that purpose. We can >revise the text in this bullet to state that inbound processing of the >padding is specific to the encryption algorithm spec, instead of just >calling for the padding to be removed. If the ESP draft is changed to state that "...inbound processing of the padding is specific to the encryption algorithm spec", then I suggest that, like padding values themselves, the default inbound processing remains in the ESP draft and allows alternate inbound processing that can be specified in the encryption algorithm specs; otherwise the algorithm specs will have to be updated to be explicit about the way they handle padding on receipt. Regardless, the handling of padding MUST be tied to the encryption algorithm as that is the only method that both parties know what to do (unless an ISAKMP "padding handling" attribute were to be added created; NOT something I'm suggesting). -Bob From owner-ipsec Mon Oct 20 12:00:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24055 for ipsec-outgoing; Mon, 20 Oct 1997 11:51:44 -0400 (EDT) Message-Id: <344B7F4D.B8D7C736@zk3.dec.com> Date: Mon, 20 Oct 1997 11:57:01 -0400 From: "Eric L. Wong" X-Mailer: Mozilla 4.03 [en] (Win95; U) Mime-Version: 1.0 To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Comments on AH and ESP drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > >(d) I haven't understood the reasons *why* for such a nesting > >between the same source and destination IPSEC system. I can > >understand nesting of the type where one of the endpoints varies > >between the "inner" and "outer" nesting (for example, where a system > >that is an endpoint for both an IPSEC transport mode connection as > >well as an endpoint for an intervening tunnel: it builds a transport > >mode IPSEC packet to send to its final destination, but then has to > >reencapsulate it in tunnel mode to get it through the tunnel). But > >this particular style of nesting hasn't made sense to me. > > I have mixed feelings about this myself. I'm not in favor or arbitrary > nesting, because of the potential complexity, but Charlie and a few other > folks have argued in favor of allowing it, e.g., to accommodate the use of > an outboard BITW implementation in conjunction with an integrated IPsec > implementation, when each was ignorant of the presence of the other. I'd > prefer to establish a limited set of ordered combinations of AH and ESP, in > tunnel and transport modes, tailored to demonstrable, agreed upon host and > gateway requirements. But, the WG has to decide on this and the traffic > favored the sort of unconstrained nesting that Charlie proposed, so ... > > This is making a working IPSec (system A) to work with a misconfigured IPSec system (system B). I think this is wrong. The misconfigured system will have SAs in two separate spaces, in the BITW IPSec and also in the native IPSec. When system A initiates the connection, it has only one set of SA bundle attributes and will not work with system B, one of the IPSec processing (most likely the BITW IPsec) will consume the headers and the other would fail the policy check. When system B initiates the connection, it may work due to two separate key negotiations and system A process the headers intertively (ignoring the local policy). However; this is a side effect of a misconfigure remote system. It will not work with manually configured SA, unless someone goes thru the trouble of configuring both SAs in the native and the BITW IPsec. Am I missing something? From owner-ipsec Mon Oct 20 16:52:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25827 for ipsec-outgoing; Mon, 20 Oct 1997 16:50:45 -0400 (EDT) Message-Id: <199710202101.OAA02410@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Wed, 15 Oct 1997 21:37:24 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 14:01:07 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >> * added a clarification on the use of proxy IDs in Quick Mode which states: >> "The proxy identities are used to identify and direct traffic >> to the appropriate tunnel in cases where multiple tunnels exist >> between two peers and also to allow for unique and shared SAs with >> different granularities. Local policy will determine whether packets >> which do not match the proxy information on which a tunnel was created >> will be forwarded upon leaving the tunnel." >> >> The 2nd part might actually belong in the Architecture Draft and >> I'll entertain offers from Steve Kent to remove this text and have >> it added there but I think there is a general confusion on this >> capability and it should be clarified (some people had mentioned >> situations where "I don't 'do proxy' but the other guy does" as if >> it was some additional capability like doing Aggressive Mode). >> In fact, it might make sense to say that if proxy identities are >> used in negotiation of tunnels that traffic which does not match >> that information MUST NOT be stuffed in the tunnel. >> > I was planning to put similar text in the architecure document, but not > necessarily with the same spin. I had received a couple of suggetsions > that this be mandatory, not just a local option. It is applicable not only > to proxy tunnel SAs, but to any SA, to detect an attempt by an authorized > sender from spoofing packets from another source, right? Maybe we need to > solicit WG opinion on this The spin isn't all that critical as long as the idea is conveyed and you can probably convey it better than I. I'll remove the 2nd part from the ISAKMP/Oakley draft. I would agree that this should be mandatory. If constraints (like proxy ids) are given during negotiation they must be respected by all parties to the negotiation. Any other WG members have an opinion either way? Dan. From owner-ipsec Mon Oct 20 17:05:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25930 for ipsec-outgoing; Mon, 20 Oct 1997 17:05:14 -0400 (EDT) Message-Id: <97Oct20.171553edt.11660@janus.tor.securecomputing.com> To: Daniel Harkins cc: Stephen Kent , ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: <199710202101.OAA02410@dharkins-ss20> In-reply-to: dharkins's message of "Mon, 20 Oct 1997 17:01:07 -0400". <199710202101.OAA02410@dharkins-ss20> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 20 Oct 1997 17:15:11 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710202101.OAA02410@dharkins-ss20>, Daniel Harkins writes: > > I would agree that this should be mandatory. If constraints (like proxy ids) > are given during negotiation they must be respected by all parties to the > negotiation. Any other WG members have an opinion either way? What about when they are *not* given? Many people seem to be refusing all non-local packets in that case. It would be nice if people's policy engines would simply allow all traffic between two routers to be protected without negotiating specific proxy-IDs. This is (once again :-) the concept of treating a tunnel as a logical, point-to-point link between two gateways. Comments? -- Harald From owner-ipsec Mon Oct 20 17:20:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25982 for ipsec-outgoing; Mon, 20 Oct 1997 17:19:47 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Oct20.171553edt.11660@janus.tor.securecomputing.com> References: dharkins's message of "Mon, 20 Oct 1997 17:01:07 -0400". <199710202101.OAA02410@dharkins-ss20> <199710202101.OAA02410@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 17:30:20 -0400 To: "C. Harald Koch" From: Stephen Kent Subject: Re: proposed changes to ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, >> I would agree that this should be mandatory. If constraints (like proxy ids) >> are given during negotiation they must be respected by all parties to the >> negotiation. Any other WG members have an opinion either way? > >What about when they are *not* given? Many people seem to be refusing all >non-local packets in that case. It would be nice if people's policy engines >would simply allow all traffic between two routers to be protected without >negotiating specific proxy-IDs. This is (once again :-) the concept of >treating a tunnel as a logical, point-to-point link between two gateways. The arch doc draft required that traffic be mapped to SAs based on "selectors" and my suggestion is that all traffic emerging from an SA ought to be checked against the set of selectors specified when the SA was created. This should apply to manually keyed SAs as well as ISAKMP SAs. I'm less comfortable with the use of the term "proxy ID" as per ISAKMP, as it is specific to that key management method. Steve From owner-ipsec Mon Oct 20 17:23:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26033 for ipsec-outgoing; Mon, 20 Oct 1997 17:23:17 -0400 (EDT) Message-Id: <199710202132.OAA25509@pita.cisco.com> To: Daniel Harkins cc: Stephen Kent , ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-reply-to: Your message of "Mon, 20 Oct 1997 14:01:07 PDT." <199710202101.OAA02410@dharkins-ss20> Date: Mon, 20 Oct 1997 14:32:47 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >I would agree that this should be mandatory. If constraints (like proxy ids) >are given during negotiation they must be respected by all parties to the >negotiation. Any other WG members have an opinion either way? I'd prefer mandatory and I think this belongs in the arch document too. Derrell From owner-ipsec Mon Oct 20 17:25:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26051 for ipsec-outgoing; Mon, 20 Oct 1997 17:25:47 -0400 (EDT) Message-Id: <199710202135.OAA02476@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "C. Harald Koch" Cc: Stephen Kent , ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Mon, 20 Oct 1997 17:15:11 EDT." <97Oct20.171553edt.11660@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 14:35:51 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, > In message <199710202101.OAA02410@dharkins-ss20>, Daniel Harkins writes: > > > > I would agree that this should be mandatory. If constraints (like proxy ids) > > are given during negotiation they must be respected by all parties to the > > negotiation. Any other WG members have an opinion either way? > > What about when they are *not* given? Many people seem to be refusing all > non-local packets in that case. It would be nice if people's policy engines > would simply allow all traffic between two routers to be protected without > negotiating specific proxy-IDs. This is (once again :-) the concept of > treating a tunnel as a logical, point-to-point link between two gateways. If you don't negotiate proxy ids but your ENCAPSULATION_MODE attribute specifies tunnel mode then I guess you can stuff anything in that tunnel. Lots of people may consider it a local policy decision on whether to accept anything out of the tunnel though. You could negotiate a proxy id's type of IP_ADDR_SUBNET with the addr 0.0.0.0 and the mask 255.255.255.255 and have port and protocol both zero and probably achieve what you're looking for. In that case if someone accepted it they'd be acknowledging that anything can come down the pipe. Dan. From owner-ipsec Mon Oct 20 18:57:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26513 for ipsec-outgoing; Mon, 20 Oct 1997 18:56:15 -0400 (EDT) Message-Id: <199710202311.TAA01642@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-reply-to: Your message of "Mon, 20 Oct 1997 17:15:11 EDT." <97Oct20.171553edt.11660@janus.tor.securecomputing.com> Date: Mon, 20 Oct 1997 19:10:59 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "C" == C Harald Koch writes: C> What about when they are *not* given? Many people seem to be C> refusing all non-local packets in that case. It would be nice C> if people's policy engines would simply allow all traffic C> between two routers to be protected without negotiating C> specific proxy-IDs. This is (once again :-) the concept of C> treating a tunnel as a logical, point-to-point link between two C> gateways. The link gets the packets there, but does your policy actually allow you to do anything with them? You might just drop them on the "outside" of a firewall and send things up through the proxies, and do various levels of authentication (with or without the IPsec IDs involved), or you can "bypass" the firewall components and forward the packets. This whole issue is something that that I think will become part of the VPN charter. :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNEvlAaZpLyXYhL+BAQHNUAL/fVE7ZgZSPw/YA36kw+em2zourhmWs0BY 8/YmT2J5oOfqxE4DLIVLUakGlkQG+cKDHzhSV4JVE8UPMGdSihI/GYEqb2HL8i/6 Jah24NAR/kjD+n4UKabDFjMKZEXtW5K0 =GcP5 -----END PGP SIGNATURE----- From owner-ipsec Mon Oct 20 19:53:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA26821 for ipsec-outgoing; Mon, 20 Oct 1997 19:51:17 -0400 (EDT) Message-Id: <199710210005.UAA01689@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-reply-to: Your message of "Mon, 20 Oct 1997 14:32:47 PDT." <199710202132.OAA25509@pita.cisco.com> Date: Mon, 20 Oct 1997 20:05:37 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Derrell" == Derrell Piper writes: >> I would agree that this should be mandatory. If constraints >> (like proxy ids) are given during negotiation they must be >> respected by all parties to the negotiation. Any other WG >> members have an opinion either way? Derrell> I'd prefer mandatory and I think this belongs in the arch Derrell> document too. Please go read draft-richardson-ipsec-icmp-filter-00.txt. If you decide to select the option in 2.1, then please read draft-richardson-ipsec-pmtu-discov-00.txt, and particularly think about v6. If you decide to pick option 2.4, ask yourself about R1 generating ICMP host unreachable or net unreachable. This is IPsecond work. I'd prefer that the IPsec documents not preclude overspecify policy. Let the VPN documents do that for gateways. Let's not forget that IPsec is more than just VPN (or, will be, one hopes) :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNEvxz6ZpLyXYhL+BAQF/GQMAkw7iM8da3x2esXD2u4ESIGcAL3EKYQMS T1tuYSpZjv1kuV7/cAB6H/7Cw7gAgxXdfM31Ow0DshpgD4t8ZVPcIRchmckq3WLn zzPx6yA4cU4KlKfEe8XaJhGagNQHZDgp =I1SR -----END PGP SIGNATURE----- From owner-ipsec Tue Oct 21 07:21:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00757 for ipsec-outgoing; Tue, 21 Oct 1997 07:19:44 -0400 (EDT) Message-Id: <199710202112.OAA02430@dharkins-ss20> To: ipsec@tis.com Subject: draft of the ISAKMP/Oakley draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 14:12:55 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk In lieu of change bars (I'm not nearly that sophisticated in nroff) here's a summary of changes from ISAKMP/Oakley v4 to make ISAKMP/Oakley v5 followed by the actual draft itself. I'd like to send this off to Cynthia ASAP so please take a look at this and send me your comments. Dan. * Added a table of contents * Changed payload notation: _b means just the body of the payload while refers to the body + the generic header. * Mandated that the 1st payload of a phase 1 exchange must be a SA payload. * Clarified construction of HASH(1-3) payloads to note that aside from the HASH, SA, and optional ID payloads there are no restrictions on payload ordering and therefore the HASHs can differ from the illustration. * Noted the limitations that Aggressive Mode places on negotiations. * Added two new (optional) authentication methods: the revised public-key encryption method; and a kerberos authentication method. * cleaned up various spelling mistakes and typos. * clarification on group offers. If a group is specified using its description (Group Description attribute) then other group attributes like Group Prime or Group Type are not allowed. * added 2 new optional Diffie-Hellman groups, a EC2N group with field element size 155 and a EC2N group with field element size 185. * fixed problem with KEYMAT definition when it's expanded-- it didn't have the protocol included. * added a clarification on the use of proxy identities. * added clarification on the M-ID used in Informational Exchanges. The M-ID of this exchange is unique and MUST NOT be the same as that used by a phase 2 exchange which prompted the Informational Exchange. * fixed the spi size problem in the payload explosion section. * added phase 1 attributes for GSS Identity Name and Field Element Size. Overloaded Group Prime attribute to also be Irreducible Polynomial. * changed the reference for CAST and Oakley, and bumped the version number of the base ISAKMP draft and the DOI. * noted in KE notation that there is no special encoding required for this payload (note that this is different than Oakley but I don't see this as a problem. In fact, I'm not sure this clarification is necessary since multivendor interoperation has been going on for quite some time, but it was requested). * noted in Appendix B that there is a single bidirectional cipher/IV context in both phase 1 and phase 2. * added verbage noting that in phase 1 a DOI value of zero (with the situation also zero) is acceptable and such an ISAKMP SA can be used to provide SAs for all services that are defined by a DOI. Also that compliant implementations can constrain phase 2 exchanges to be only for the same DOI in which the phase 1 exchange was done. * changed the way SKEYID is generated for authentication with public key encryption. * weak key checks for phase 1 are still in there. So, here it is.... --------------------------- snippity snip ------------------------------- IPSEC Working Group D. Harkins, D. Carrel INTERNET-DRAFT cisco Systems draft-ietf-ipsec-isakmp-oakley-05.txt October 1997 The resolution of ISAKMP with Oakley Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table Of Contents 1 Abstract 2 Discussion 3 Terms and Definitions 3.1 Requirements Terminology 3.2 Notation 3.3 Perfect Forward Secrecty 3.4 Security Association 4 Introduction 5 Exchanges 5.1 Authentication with Digital Signatures 5.2 Authentication with Public Key Encryption 5.3 A Revised method of Authentication with Public Key Encryption 5.4 Authentication with a Pre-Shared Key 5.5 Authentication with GSSAPI 5.6 Quick Mode 5.7 New Group Mode 5.8 ISAKMP Informational Exchanges Harkins, Carrel [Page 1] INTERNET DRAFT October 1997 6 Oakley Groups 6.1 First Oakley Group 6.2 Second Oakley Group 6.3 Third Oakley Group 6.4 Fourth Oakley Group 7 Payload Explosion of Complete Exchange 7.1 Phase 1 with Main Mode 7.2 Phase 2 with Quick Mode 8 Perfect Forward Secrecy Example 9 Implementation Hints 10 Security Considerations 11 Acknowledgments 12 References Appendix A Appendix B 1. Abstract [MSST97] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Harkins, Carrel [Page 2] INTERNET DRAFT October 1997 2. Discussion This draft describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. Processes which implement this draft can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network. Proxy negotiation is supported. Proxy mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in proxy mode, the identities of the end parties remain hidden. This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol. Likewise, this does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces. 3. Terms and Definitions 3.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 3.2 Notation The following notation is used throughout this draft. HDR is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption. SA is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.

_b indicates the body of payload

-- the ISAKMP generic payload is not included. SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all Harkins, Carrel [Page 3] INTERNET DRAFT October 1997 transforms offered by the Initiator. CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header. g^xi and g^xr are the Diffie-Hellman public values of the initiator and responder respectively. g^xy is the Diffie-Hellman shared secret. GIi and GIr are identity name strings for the GSSAPI initiator and responder GSSAPI endpoints. These name strings are private to GSSAPI. GSSi and GSSr are the initiator and responder GSSAPI tokens generated by the local GSSAPI's using gss_init_sec_context and gss_accept_sec_context respectively. GSSIi and GSSIr are the concatenation of optional GSSAPI identity strings and either GSSi or GSSr for the initiator and responder respectively. KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding used for the data of a KE payload. Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and responder respectively. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. SIG is the signature payload. The data to sign is exchange- specific. CERT is the certificate payload. HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. The contents of the hash are specific to the authentication method. prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]). Harkins, Carrel [Page 4] INTERNET DRAFT October 1997 SKEYID is a string derived from secret material known only to the active players in the exchange. SKEYID_e is the keying material used by the ISAKMP SA to protect it's messages. SKEYID_a is the keying material used by the ISAKMP SA to authenticate it's messages. SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations. y indicates that "x" is encrypted with the key "y". --> signifies "initiator to responder" communication (requests). <-- signifies "responder to initiator" communication (replies). | signifies concatenation of information-- e.g. X | Y is the concatentation of X with Y. [x] indicates that x is optional. Payload encryption (when noted by a '*' after the ISAKMP header) MUST begin immediately after the ISAKMP header. When communication is protected, all payloads following the ISAKMP header MUST be encrypted. Encryption keys are generated from SKEYID_e in a manner that is defined for each algorithm. 3.3 Perfect Forward Secrecy When used in the draft Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys. Perfect Forward Secrecy for both keys and identities is provided in this protocol. (Sections 5.6 and 8). 3.4 Security Association A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. Harkins, Carrel [Page 5] INTERNET DRAFT October 1997 4. Introduction Oakley defines a method to establish an authenticated key exchange. This includes how payloads are constructed, the information they carry, the order in which they are processed and how they are used. While Oakley defines "modes", ISAKMP defines "phases". The relationship between the two is very straightforward. ISAKMP's phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" MUST ONLY be used in phase 1. Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. "New Group Mode" is not really a phase 1 or phase 2. It follows phase 1, but serves to establish a new group which can be used in future negotiations. "New Group Mode" MUST ONLY be used after phase 1. The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes. With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. "Main Mode" for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further. Developer hints for doing these optimizations are included below. It should also be noted that using public key encryption to authenticate an Aggressive Mode exchange will still provide identity protection. Harkins, Carrel [Page 6] INTERNET DRAFT October 1997 This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non- ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST97] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA. If a DOI of zero is used for establishment of a phase 1 SA, the syntax of the identity payloads used in phase 1 is that defined in [MSST97] not from any DOI-- e.g. [Pip97]-- which may further expand the syntax and semantics of identities. The following attributes are used by ISAKMP/Oakley and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.) - encryption algorithm (e.g. DES, IDEA, Blowfish). - hash algorithm (e.g. MD5, SHA) - authentication method (e.g. DSS sig, RSA sig, RSA encryption, pre-shared key) - information about a group over which to do Diffie-Hellman. - prf (e.g. 3DES-CBC-MAC) All of these attributes are mandatory and MUST be negotiated except for the "prf". The "prf" MAY be negotiated, but if it is not, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non-mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes. The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.7). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange). ISAKMP/Oakley implementations MUST support the following attribute values: Harkins, Carrel [Page 7] INTERNET DRAFT October 1997 - DES-CBC with a weak, and semi-weak, key check (weak and semi- weak keys are referenced in [Sch96] and listed in Appendix A). The key is derived according to Appendix B. - MD5 and SHA. - Authentication via pre-shared keys. The Digital Signature Standard SHOULD be supported; RSA-- both signatures and authentication with public key encryption-- SHOULD be supported; GSSAPI MAY be supported. - MODP over the default group (see below). ECP and EC2N groups MAY be supported. The ISAKMP/Oakley modes described here MUST be implemented whenever the IETF IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes described here. 5. Exchanges There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be implemented. In addition, Quick Mode MUST be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. In additon, New Group Mode SHOULD be implemented as a mechanism to define private groups for Diffie-Hellman exchanges. Implementations MUST NOT switch exchange types in the middle of an exchange. Exchanges conform to standard ISAKMP [MSST97] payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.g a notify response is sent when, for example, a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc. The SA payload MUST precede all other payloads in a phase 1 exchange. Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order. Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose. The XCHG for Main Mode is ISAKMP Identity Protect. Harkins, Carrel [Page 8] INTERNET DRAFT October 1997 Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message is not sent under protection of the ISAKMP SA allowing each party to postpone exponentiation, if desired, until negotiation of this exchange is complete. Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated. For situations where the rich attribute negotiation capabilities of ISAKMP/Oakley are required Main Mode may be required. Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG values for Quick Mode and New Group Mode are defined in Appendix A. Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons. Five different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, pre-shared key, or GSSAPI. The value SKEYID is computed seperately for each authentication method. For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) For GSSAPI: SKEYID = prf(Ni_b | Nr_b, g^xy) The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) Harkins, Carrel [Page 9] INTERNET DRAFT October 1997 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B). To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b [ | GSSIi ]) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b [ | GSSIr ]) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. For authentication using GSSAPI, the GSSAPI package on either side provides authentication of the GSSAPI identities, and HASH_I and HASH_R are used to bind the GSSAPI identities and tokens to the Main Mode exchange. Each side MUST specify the GSS_C_MUTUAL_FLAG to request mutual authentication between the two GSSAPI packages. A provision is defined for the GSSAPI peers to exchange GSSAPI identities during Main Mode, at the expense of identity protection for the GSSAPI endpoint identities. As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption (if the algorithm supports it). Following are Phase 1 exchanges with different authentication options. 5.1 ISAKMP/Oakley Phase 1 Authenticated With Signatures Using signatures, the ancillary information exchanged during the second roundtrip are nonces; the exchange is authenticated by signing a mutually obtainable hash. Main Mode with signature authentication is described as follows: Initiator Responder ---------- ----------- Harkins, Carrel [Page 10] INTERNET DRAFT October 1997 HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In general the signature will be over HASH_I and HASH_R as above using the negotiated prf, or the HMAC version of the negotiated hash function (if no prf is negotiated). However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e.g. DSS is only defined with SHA's 160 bit output). In this case, the signature will be over HASH_I and HASH_R as above, except using the HMAC version of the hash algorithm associated with the signature method. The negotiated prf and hash function would continue to be used for all other prescribed pseudo- random functions. Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format. DSS signatures MUST be encoded as r followed by s. One or more certificate payloads MAY be optionally passed. 5.2 Phase 1 Authenticated With Public Key Encryption Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange. Harkins, Carrel [Page 11] INTERNET DRAFT October 1997 In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained. In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's public key. If the authentication method is public key encryption, the nonce and identity payloads MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear. When using encrytion for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Pubkey_r, Pubkey_r --> HDR, SA, KE, PubKey_i, <-- PubKey_i, HASH_R HDR, HASH_I --> Where HASH(1) is a hash (using the negotiated hash function) of the certificate which the initiator is using to encrypt the nonce and identity. RSA encryption MUST be encoded in PKCS #1 format. While only the body of the ID and nonce payloads is encrypted, the encrypted data must be Harkins, Carrel [Page 12] INTERNET DRAFT October 1997 preceded by a valid ISAKMP generic header. The payload length is the length of the entire encrypted payload plus header. The PKCS #1 encoding allows for determination of the actual length of the cleartext payload upon decryption. Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. This exchange was motivated by [Kra96]. Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode. 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption Authentication with Public Key Encryption has significant advantages over authentication with signatures (see section 5.2 above). Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations. In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. As with the public key encryption method of authentication (section 5.2), a HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e.g. if the certificate is not for signatures only, either due to certificate restrictions or algorithmic restrictions). If the HASH payload is sent it MUST be the first payload of the second message exchange and MUST be followed by the encrypted nonce. If the HASH payload is not sent, the first payload of the second message exchange MUST be the encrypted nonce. In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond. Harkins, Carrel [Page 13] INTERNET DRAFT October 1997 When using the revised encryption mode for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i, [<Ke_i] --> HDR, PubKey_i, Ke_r, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with the revised encryption method is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] Pubkey_r, Ke_i, Ke_i [, Ke_i ] --> HDR, SA, PubKey_i, Ke_r, Ke_r, <-- HASH_R HDR, HASH_I --> where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to the symmetric encryption algorithm negotiated in the SA payload exchange. Only the body of the payloads are encrypted (in both public key and symmetric operations), the generic payload headers are left in the clear. The payload length includes that added to perform encryption. The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed: Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R) The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. If the output of Harkins, Carrel [Page 14] INTERNET DRAFT October 1997 the negotiated prf is greater than or equal to the key length requirements of the cipher, Ke_i and Ke_r are derived from the most significant bits of Ne_i and Ne_r respectively. If the desired length of Ke_i and Ke_r exceed the output of the prf the necessary number of bits is obtained by repeatedly feeding the results of the prf back into itself and concatenating the result until the necessary number has been achieved. For example, if the negotiated encryption algorithm requires 320 bits of key and the output of the prf is only 128 bits, Ke_i is the most significant 320 bits of K, where K = K1 | K2 | K3 and K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) K3 = prf(Ne_i, K2) For brevity, only derivation of Ke_i is shown; Ke_r is identical. The length of the value 0 in the computation of K1 is a single octet. Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be discarded after use. Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements. All payloads-- in whatever order-- following the encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the direction. If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce-- and after the ephemeral symmetric cipher key, Ke_i, can be computed-- is set to 0. The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. 5.4 Phase 1 Authenticated With a Pre-Shared Key A key derived by some out-of-band mechanism may also be used to authenticate the exchange. The actual establishment of this key is out of the scope of this document. When doing a pre-shared key authentication, Main Mode is defined as follows: Initiator Responder Harkins, Carrel [Page 15] INTERNET DRAFT October 1997 ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R Aggressive mode with a pre-shared key is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. 5.5 ISAKMP/Oakley Phase 1 Authenticated With GSSAPI Using GSSAPI, the ancillary information exchanged during the second roundtrip are GSSAPI tokens; the exchange is authenticated in GSSAPI and the GSSAPI tokens are bound to the exchange using HASH_I and HASH_R. If the GSSAPI requires that the initiator and responder have prior knowledge of the GSSAPI endpoint names for each peer, this information may be exchanged during the first round trip (by including the GSS Identity Name attribute in the SA) at the expense of identity protection for the GSSAPI endpoints. When the GSSAPI requires the exchange of identity names, Aggressive Mode cannot be used. Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni, GSSi --> <-- HDR, KE, Nr, GSSr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R Harkins, Carrel [Page 16] INTERNET DRAFT October 1997 Aggressive mode using GSSAPI is defined as Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii, GSSi --> <-- HDR, SA, KE, Nr, IDir, GSSr, HASH_R HDR, HASH_I --> 5.6 Phase 2 - Quick Mode Quick Mode is not a complete exchange itself, but is used as part of the ISAKMP SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs. The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. This HASH authenticates the message and also provides liveliness proofs. Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. While use of the key exchange payload with Quick Mode is optional it MUST be supported. Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material. If a KE payload is sent, a Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be sent as attributes of the SA being negotiated. If ISAKMP is acting as a proxy negotiator on behalf of another party the identities of the parties MUST be passed as IDui and then IDur. Local policy will dictate whether the proposals are acceptible for the identities specified. If IDs are not exchanged, the negotiation MAY assumed to be done on behalf of each ISAKMP peer. If an ID range (see Appendix A of [Pip97]) is not acceptable (for example, the specified subnet is too large) a INVALID-ID-INFORMATION notify message followed (18) by an acceptible ID range, in an ID payload, SHOULD be sent. The proxy identities are used to identify and direct traffic to the Harkins, Carrel [Page 17] INTERNET DRAFT October 1997 appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDui, IDur ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDui, IDur ] HDR*, HASH(3) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. HASH(3)-- for liveliness-- is the prf over the value zero represented as a single octet, followed by a concatenation of the message id and the two nonces-- the initiator's followed by the responder's-- minus the payload header. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDui | IDur ]) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example. If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman Harkins, Carrel [Page 18] INTERNET DRAFT October 1997 exchange of this Quick Mode. In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words, KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. This keying material (whether with PFS or without, and whether derived directly or through concatenation) MUST be used with the negotiated SA. It is up to the service to define how keys are derived from the keying material. In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, the exponential (g(qm)^xy) is irretreivably removed from the current state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) continue to protect and authenticate the ISAKMP SA and SKEYID_d continues to be used to derive keys. Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDui, IDur ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDui, IDur ] HDR*, HASH(3) --> The keying material is derived identically as in the case of a single Harkins, Carrel [Page 19] INTERNET DRAFT October 1997 SA. In this case (negotiation of two SA payloads) the result would be four security associations-- two each way for both SAs. 5.7 New Group Mode New Group Mode MUST NOT be used prior to establishment of an ISAKMP SA. The description of a new group MUST only follow phase 1 negotiation. (It is not a phase 2 exchange, though). Initiator Responder ----------- ----------- HDR*, HASH(1), SA --> <-- HDR*, HASH(2), SA where HASH(1) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the entire SA proposal, body and header, as the data; HASH(2) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the reply as the data. In other words the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA) HASH(2) = prf(SKEYID_a, M-ID | SA) The proposal will specify the characteristics of the group (see appendix A, "Attribute Assigned Numbers"). Group descriptions for private Groups MUST be greater than or equal to 2^15. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). ISAKMP implementations MAY require private groups to expire with the SA under which they were established. Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A and Group Curve B-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. 5.8 ISAKMP Informational Exchanges This protocol protects ISAKMP Informational Exchanges when possible. Once the ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated) ISAKMP Information Exchanges, when used with this protocol, are as follows: Harkins, Carrel [Page 20] INTERNET DRAFT October 1997 Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete Payload and HASH(1) is the prf output, using SKEYID_a as the key, and a M-ID unique to this exchange concatenated with the entire informational payload (either a Notify or Delete) as the data. In other words, the hash for the above exchange is: HASH(1) = prf(SKEYID_a, M-ID | N/D) As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload. 6 Oakley Groups With ISAKMP/Oakley, the group in which to do the Diffie-Hellman exchange is negotiated. Four groups-- values 1 through 4-- are defined below. The attribute class for "Group" is defined in Appendix A. All values 2^15 and higher are used for private group identifiers. For a discussion on the strength of the default Oakley groups please see the Security Considerations section below. 6.1 First Oakley Default Group Oakley implementations MUST support a MODP group with the following prime and generator. This group is assigned id 1 (one). The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is: 2. 6.2 Second Oakley Group ISAKMP/Oakley implementations MUST support a MODP group with the Harkins, Carrel [Page 21] INTERNET DRAFT October 1997 following prime and generator. This group is assigned id 2 (two). The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2 (decimal) 6.3 Third Oakley Group ISAKMP/Oakley implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 3 (three). The curve is based on the Galois Field GF[2^155]. The field element size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Element Size: 155 Group Prime/Irreducible Polynomial: 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). 6.4 Fourth Oakley Group ISAKMP/Oakley implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 4 (four). The curve is based on the Galois Field GF[2^185]. The field element size is 185. The irreducible polynomial for the field is: Harkins, Carrel [Page 22] INTERNET DRAFT October 1997 u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Element Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9 The data in the KE payload when using this group will be identical to that as when using Oakley Group 3 (three). Other groups can be defined using New Group Mode. These default groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. 7. Payload Explosion for a Complete ISAKMP/Oakley Exchange This section illustrates how the ISAKMP/Oakley protocol is used to: - establish a secure and authenticated channel between ISAKMP processes (phase 1); and - generate key material for, and negotiate, an IPsec SA (phase 2). Harkins, Carrel [Page 23] INTERNET DRAFT October 1997 7.1 Phase 1 using Main Mode The following diagram illustrates the payloads exchanged between the two parties in the first round trip exchange. The initiator MAY propose several proposals; the responder MUST reply with one. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_SA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (IPsec DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ prefered SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ alternate SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The responder replies in kind but selects, and returns, one transform proposal (the ISAKMP SA attributes). Harkins, Carrel [Page 24] INTERNET DRAFT October 1997 The second exchange consists of the following payloads: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_KE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The shared keys, SKEYID_e and SKEYID_a, are now used to protect and authenticate all further communication. Note that both SKEYID_e and SKEYID_a are unauthenticated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_ID and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SIG ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data of the ISAKMP negotiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ signature verified by the public key of the ID above ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The key exchange is authenticated over a signed hash as described in section 5.1. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. (For brevity, certificate payloads were not exchanged). 7.2 Phase 2 using Quick Mode The following payloads are exchanged in the first round of Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested authentication. Harkins, Carrel [Page 25] INTERNET DRAFT October 1997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ keyed hash of message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 8 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (8 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_MD5 | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of source for which ISAKMP is a proxy ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of destination for which ISAKMP is a proxy ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.6 above. The responder replies with a similar message which only contains one Harkins, Carrel [Page 26] INTERNET DRAFT October 1997 transform-- the selected AH transform. Upon receipt, the initiator can provide the key engine with the negotiated security association and the keying material. As a check against replay attacks, the responder waits until receipt of the next message. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.6 above. 8 Perfect Forward Secrecy Example This protocol can provide PFS of both keys and identities. The identies of both the ISAKMP negotiating peer and, if applicable, the identities for whom the peers are negotiating can be protected with PFS. To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following: o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state. Since the key for use in the non-ISAKMP SA was derived from the single ephemeral Diffie-Hellman exchange PFS is preserved. To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP security association, it in not necessary to do a phase 1 exchange if an ISAKMP SA exists between the two peers. A single Quick Mode in which the optional KE payload is passed, and an additional Diffie- Hellman exchange is performed, is all that is required. At this point the state derived from this Quick Mode must be deleted from the ISAKMP SA as described in section 5.6. Harkins, Carrel [Page 27] INTERNET DRAFT October 1997 9. Implementation Hints Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as the Phase 1 state remains cached, and PFS is not needed, Phase 2 can proceed without any exponentiation. How many Phase 2 negotiations can be performed for a single Phase 1 is a local policy issue. The decision will depend on the strength of the algorithms being used and level of trust in the peer system. An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. An optimization that is often useful is to establish Security Associations with peers before they are needed so that when they become needed they are already in place. This ensures there would be no delays due to key management before initial data transmission. This optimization is easily implemented by setting up more than one Security Association with a peer for each requested Security Association and caching those not immediately used. Also, if an ISAKMP implementation is alerted that a SA will soon be needed (e.g. to replace an existing SA that will expire in the near future), then it can establish the new SA before that new SA is needed. The base ISAKMP specification describes conditions in which one party of the protocol may inform the other party of some activity-- either deletion of a security association or in response to some error in the protocol such as a signature verification failed or a payload failed to decrypt. It is strongly suggested that these Informational exchanges not be responded to under any circumstances. Such a condition may result in a "notify war" in which failure to understand a message results in a notify to the peer who cannot understand it and sends his own notify back which is also not understood. 10. Security Considerations This entire draft discusses a hybrid protocol, combining parts of Oakley and parts of SKEME with ISAKMP, to negotiate, and derive keying material for, security associations in a secure and authenticated manner. Harkins, Carrel [Page 28] INTERNET DRAFT October 1997 Confidentiality is assured by the use of a negotiated encryption algorithm. Authentication is assured by the use of a negotiated method: a digital signature algorithm; a public key algorithm which supports encryption; or, a pre-shared key. The confidentiality and authentication of this exchange is only as good as the attributes negotiated as part of the ISAKMP security association. Repeated re-keying using Quick Mode can consume the entropy of the Diffie- Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This draft does not prescribe such a limit. Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again. The strength of a key derived from a MODP Diffie-Hellman exchange depends on the size of the prime used and also the inherent strength of the group. The first default Oakley group for Diffie-Hellman exchanges defined in this document provides enough strength for DES-- 56 bits-- with an exponent no less than 160 bits. The second default Oakley group for Diffie-Hellman exchanges defined in this document provides around 80 bits of strength with an exponent no less than 160 bits. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in ISAKMP/Oakley which prohibits using stronger groups nor is there anything which will dilute the strength obtained from stronger groups. In fact, the extensible framework of ISAKMP/Oakley encourages the definition of more groups; use of elliptical curve groups will greatly increase strength using much smaller numbers. For situations where defined groups provide insufficient strength New Group Mode can be used to exchange a Diffie-Hellman group which provides the necessary strength. In is incumbent upon implementations Harkins, Carrel [Page 29] INTERNET DRAFT October 1997 to check the primality in groups being offered and independently arrive at strength estimates. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents must not be derived from long-lived secrets like the seed to a pseudo-random generator. 11. Acknowledgements This document is the result of close consultation with Hugo Krawczyk, Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and Jeff Turner. It relies on protocols which were written by them. Without their interest and dedication, this would not have been written. We would also like to thank Cheryl Madson, Harry Varnis, and Elfed Weaver for technical input. 12. References [Acm97] Adams, C.M., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [MSST97] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 2, draft-ietf-ipsec-oakley-02.txt [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-04.txt. [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. Harkins, Carrel [Page 30] INTERNET DRAFT October 1997 Appendix A This is a list of DES Weak and Semi-Weak keys. The keys come from [Sch96]. All keys are listed in hexidecimal. DES Weak Keys 0101 0101 0101 0101 1F1F 1F1F E0E0 E0E0 E0E0 E0E0 1F1F 1F1F FEFE FEFE FEFE FEFE DES Semi-Weak Keys 01FE 01FE 01FE 01FE 1FE0 1FE0 0EF1 0EF1 01E0 01E0 01F1 01F1 1FFE 1FFE 0EFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE F1FE FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 F101 FE1F FE1F FE0E FE0E 1F01 1F01 0E01 0E01 FEE0 FEE0 FEF1 FEF1 Attribute Assigned Numbers Attributes negotiated during phase one use the following definitions. Phase two attributes are defined in the applicable DOI specification (for example, IPsec attributes are defined in the IPsec DOI), with the exception of a group description when Quick Mode includes an ephemeral Diffie-Hellman exchange. Attribute types can be either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the base ISAKMP specification. Harkins, Carrel [Page 31] INTERNET DRAFT October 1997 Attribute Classes class value type ------------------------------------------------------------------- Encryption Algorithm 1 B Hash Algorithm 2 B Authentication Method 3 B Group Description 4 B Group Type 5 B Group Prime/Irreducible Polynomial 6 V Group Generator One 7 V Group Generator Two 8 V Group Curve A 9 V Group Curve B 10 V Life Type 11 B Life Duration 12 B/V PRF 13 B Key Length 14 B Field Element Size 15 B GSS Identity Name 16 B/V Class Values - Encryption Algorithm DEC-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 values 7-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties. - Hash Algorithm MD5 1 SHA 2 Tiger 3 values 4-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties. - Authentication Method pre-shared key 1 DSS signatures 2 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 Harkins, Carrel [Page 32] INTERNET DRAFT October 1997 Authentication with GSSAPI 6 values 7-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties. - Group Description default 768-bit MODP group (section 6.1) 1 alternate 1024-bit MODP group (section 6.2) 2 .sp EC2N group on GP[2^155] (section 6.3) 3 .sp EC2N group on GP[2^185] (section 6.4) 4 values 5-32767 are reserved. Values 32768-65535 are for private use among mutually consenting parties. - Group Type MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3 values 4-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties. - Life Type seconds 1 kilobytes 2 values 3-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties. For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected. - PRF 3DES-CBC-MAC 1 values 2-65000 are reserved. Values 65001-65535 are for private use among mutually consenting parties - Key Length When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). - GSS Identity Name Harkins, Carrel [Page 33] INTERNET DRAFT October 1997 When using the GSSAPI authentication mode, the GSS Identity Name attribute may be used to pass the GSSAPI endpoint names for the initiator and responder. The format for these name strings are private to GSSAPI. Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Harkins, Carrel [Page 34] INTERNET DRAFT October 1997 Appendix B This appendix describes encryption details to be used ONLY when encrypting ISAKMP messages. When a service (such as an IPSEC transform) utilizes ISAKMP to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. ISAKMP does not purport to ever produce keys that are suitable for any encryption algorithm. ISAKMP produces the requested amount of keying material from which the service MUST generate a suitable key. Details, such as weak key checks, are the responsibility of the service. Use of negotiated PRFs may require the PRF output to be expanded. For instance, 3DES-CBC-MAC produces 8 bytes of output which must be used as a key to another 3DES-CBC-MAC function call. The output of a PRF is expanded by feeding back the results of the PRF into itself to generate successive blocks. These blocks are concatenated until the requisite number of bytes has been acheived. For example, for pre- shared key authentication with 3DES-CBC-MAC as the negotiated PRF: BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) and SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 so therefore to derive SKEYID_d: BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R) BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R) BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R) and SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 Subsequent PRF derivations are done similarly. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Harkins, Carrel [Page 35] INTERNET DRAFT October 1997 Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the cyphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. Note that the final phase 1 CBC output block, the result of encryption/decryption of the last phase 1 message, must be retained in the ISAKMP SA state to allow for generation of unique IVs for each Quick Mode. Each phase 2 exchange generates IVs independantly to prevent IVs from getting out of sync when two different Quick Modes are started simultaneously. In both phases, there is a single bidirectional cipher/IV context. Having each phase 2 exchange maintain a unique context prevents IVs from getting out of sync. The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above. The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material Harkins, Carrel [Page 36] INTERNET DRAFT October 1997 derived above. The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. The key for RC5-R16-B64-CBC is the negotiated key size, or the first sixteen (16) bytes of a key (if no key size is negotiated) derived from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived above. The number of rounds MUST be 16 and the block size MUST be 64. The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV is the first eight (8) bytes of the IV material derived above. The key for CAST-CBC is either the negotiated key size, or the first sixteen (16) bytes of a key derived in the aforementioned pseudo- random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. Support for algorithms other than DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims. Harkins, Carrel [Page 37] INTERNET DRAFT October 1997 Authors' Addresses: Dan Harkins cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America +1 408 526 4000 Dave Carrel 76 Lippard Ave. San Francisco, CA 94131-2947 United States of America +1 415 337 8469 Authors' Note: The authors encourage independent implementation, and interoperability testing, of this hybrid protocol. Harkins, Carrel [Page 38] From owner-ipsec Tue Oct 21 11:06:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02194 for ipsec-outgoing; Tue, 21 Oct 1997 11:03:56 -0400 (EDT) Message-Id: <97Oct21.111457edt.11651@janus.tor.securecomputing.com> To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: <199710202311.TAA01642@istari.sandelman.ottawa.on.ca> In-reply-to: Your message of "Mon, 20 Oct 1997 19:10:59 -0400". <199710202311.TAA01642@istari.sandelman.ottawa.on.ca> 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, 21 Oct 1997 11:14:12 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199710202311.TAA01642@istari.sandelman.ottawa.on.ca>, "Michael C. Richardson" writes: > > The link gets the packets there, but does your policy actually allow > you to do anything with them? In my case, yes. We have a fairly sophisticated policy engine for deciding what 'group' traffic belongs to, and allowing proxying and/or forwarding of packets. One of the group selectors is the SA used to auth/decrypt a packet. But that's irrelevant; my issue is that I don't want to be required to negotiate a separate SA for each pair of networks (or worse, pair of hosts) on opposites sides of a "tunnel". That way lies resource exhaustion. But it appears that many people want to *require* this as part of their policy engines. I agree; this is something that will be worked out in the VPN work. -- Harald From owner-ipsec Tue Oct 21 11:32:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02347 for ipsec-outgoing; Tue, 21 Oct 1997 11:29:55 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Oct21.111457edt.11651@janus.tor.securecomputing.com> References: Your message of "Mon, 20 Oct 1997 19:10:59 -0400". <199710202311.TAA01642@istari.sandelman.ottawa.on.ca> <199710202311.TAA01642@istari.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 11:41:33 -0400 To: "C. Harald Koch" From: Stephen Kent Subject: Re: proposed changes to ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, >> >> The link gets the packets there, but does your policy actually allow >> you to do anything with them? > >In my case, yes. We have a fairly sophisticated policy engine for deciding >what 'group' traffic belongs to, and allowing proxying and/or forwarding of >packets. One of the group selectors is the SA used to auth/decrypt a packet. > >But that's irrelevant; my issue is that I don't want to be required to >negotiate a separate SA for each pair of networks (or worse, pair of hosts) >on opposites sides of a "tunnel". That way lies resource exhaustion. But it >appears that many people want to *require* this as part of their policy >engines. > >I agree; this is something that will be worked out in the VPN work. What I proposed for inbound processing does not require a separate SA per network pair. It requires that the receiver check the inbound packets against the set of selectors used to map traffic to the SA in question. So, if one maps traffic for a range of IP addresses to a single SA, one checks to make sure that the packets emitted from that SA contain an IP source address consistent with the selector set. This is not just a VPN issue, the same concerns apply to host SAs. Steve From owner-ipsec Tue Oct 21 13:52:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03159 for ipsec-outgoing; Tue, 21 Oct 1997 13:47:28 -0400 (EDT) Message-Id: <97Oct21.135835edt.11651@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: In-reply-to: kent's message of "Tue, 21 Oct 1997 11:41:33 -0400". From: "C. Harald Koch" Date: Tue, 21 Oct 1997 13:57:51 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > > What I proposed for inbound processing does not require a separate SA per > network pair. It requires that the receiver check the inbound packets > against the set of selectors used to map traffic to the SA in question. > So, if one maps traffic for a range of IP addresses to a single SA, one > checks to make sure that the packets emitted from that SA contain an IP > source address consistent with the selector set. This is not just a VPN > issue, the same concerns apply to host SAs. I understand this. The arch document is fine; the problem is ISAKMP proxy IDs and how the relate to SA policy. My policy engine supports this kind of discrimination and check, at least for IP addresses. My issues are: 1) other people appear to be expecting ISAKMP to advertise proxy_ids, *and* to use those proxy_ids as selectors, as you describe. 2) I'm not sure how to 'advertise' my policy with ISAKMP exchanges. If I attempt to negotiate an ISAKMP Phase 2 exchange *without* proxy_ids, or with a different ID than the remote was expecting, then the SA is denied by the remote, since it doesn't match their policy. So in order to fully interoperate, I *must* negotiate a proxy_id with an SA, and then only use that SA for traffic related to the proxy_id. Since the most common ID used is ID_IPV4_ADDR, this leads to an SA per host-pair. Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large numbers of networks behind their security gateways. I like Dan's 0/0 proxy_id; I don't know how many other's would accept it, though (How many of you would?). Here's another question: how many of you link ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET, and ID_IPV4_ADDR_RANGE in your policy engines? e.g. if you're expecting a subnet, and I send you a host within that subnet, will you accept the SA and use it? -- Harald From owner-ipsec Tue Oct 21 15:14:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03851 for ipsec-outgoing; Tue, 21 Oct 1997 15:12:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <344B7F4D.B8D7C736@zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 15:20:25 -0400 To: "Eric L. Wong" From: Stephen Kent Subject: Re: Comments on AH and ESP drafts Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric, >This is making a working IPSec (system A) to work with a >misconfigured IPSec system (system B). I think this is wrong. >The misconfigured system will have SAs in two separate spaces, >in the BITW IPSec and also in the native IPSec. > >When system A initiates the connection, it has only one set of SA >bundle attributes and will not work with system B, one of the IPSec >processing (most likely the BITW IPsec) will consume the headers >and the other would fail the policy check. > >When system B initiates the connection, it may work due to two >separate key negotiations and system A process the headers intertively >(ignoring the local policy). However; this is a side effect of >a misconfigure remote system. It will not work with manually >configured SA, unless someone goes thru the trouble of configuring >both SAs in the native and the BITW IPsec. > >Am I missing something? The proponents of this approach would argue that supporting the BITW IPsec along with the native IPsec in system B is a feature that makes IPsec more flexible. There is nothing intrinsically wrong with being able to support such a configuration; it just makes life more complex and, as Cheryl pointed out, ISAKMP is not capable of coordinating the SAs at the other end, thus arguing against support for such complex configurations at the current stage of Ipsec evolution. The resolution that I would suggest for this sort of situation is to restrict the MUST support set of SA types for now, with the intent of expanding this in IPSecond. Steve From owner-ipsec Wed Oct 22 02:13:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06858 for ipsec-outgoing; Wed, 22 Oct 1997 02:09:32 -0400 (EDT) Date: Wed, 22 Oct 97 06:01:00 GMT Daylight Time From: Ran Atkinson Subject: Re: Proxy & ISAKMP/Oakley To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199710202135.OAA02476@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 20 Oct 1997 14:35:51 -0700 Daniel Harkins wrote: > If you don't negotiate proxy ids but your ENCAPSULATION_MODE attribute > specifies tunnel mode then I guess you can stuff anything in that tunnel. > Lots of people may consider it a local policy decision on whether to accept > anything out of the tunnel though. Disagree. Negotiating no Proxy-ID for an SA using Tunnel-mode should have the semantic that only the Sender-ID can use that tunnel. Lack of a Proxy-ID means there is no proxy in use for that SA. For reference, the semantics should be: Proxy-ID: Identity of entity performing IPsec on behalf of sender, if none the sender is performing its own IPsec. Sender-ID: Identity of sender of original traffic. > You could negotiate a proxy id's type of IP_ADDR_SUBNET with the addr > 0.0.0.0 and the mask 255.255.255.255 and have port and protocol both zero and > probably achieve what you're looking for. In that case if someone accepted > it they'd be acknowledging that anything can come down the pipe. Maybe agree. When one wants a wide-open tunnel (never a really wise policy IMHO), one MUST negotiate a (Proxy-ID == IPsec tunnel start point) and (Source-ID == IP_ADDR_SUBNET 0.0.0.0/32 as noted by Dan). It is actually important that these semantics be clearly described somewhere. If implementations don't use the same semantics, then badness is a high probability outcome. All IMHO. Ran From owner-ipsec Wed Oct 22 02:16:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06937 for ipsec-outgoing; Wed, 22 Oct 1997 02:15:05 -0400 (EDT) Date: Wed, 22 Oct 97 06:10:30 GMT Daylight Time From: Ran Atkinson Subject: Re: proposed changes to ISAKMP/Oakley To: Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I disagree that the concept of a Proxy-ID is in any way unique to ISAKMP/Oakley. The concept of a Proxy-ID is general enough to be widely useful, IMHO. I'd suggest it would be useful to define as an optional-to- implement part of an IPsec Security Association with a clear standard definition. While not all KM techniques might support it, more than one manual keying implementation supports the concept and many KM techniques are capable of supporting the concept. All PF_KEY implementations should be supporting Proxy-IDs and PF_KEY is independent of the KM protocol, for example. IMHO, omitting explicit definition of the Proxy-ID from the formal definition of an IPsec SA is likely to lead to reduced security in the operational Internet. Including it is likely to enhance security in the deployed operational Internet. Regards, Ran From owner-ipsec Wed Oct 22 02:22:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06993 for ipsec-outgoing; Wed, 22 Oct 1997 02:21:05 -0400 (EDT) Date: Wed, 22 Oct 97 06:15:30 GMT Daylight Time From: Ran Atkinson Subject: Re: proposed changes to ISAKMP/Oakley To: "Michael C. Richardson" , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199710210005.UAA01689@istari.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 20 Oct 1997 20:05:37 -0400 "Michael C. Richardson" wrote: > I'd prefer that the IPsec documents not preclude overspecify > policy. Let the VPN documents do that for gateways. Let's not forget > that IPsec is more than just VPN (or, will be, one hopes) Michael, I agree that overspecification would be bad. In the scenario being discussed, however, the two parties had already negotiated the policy. Your suggestion is that one party should then be standards-conforming while not conforming to the policy it just agreed to with the remote end. This does not seem right. Policy drives what attributes are sent via ISAKMP/Oakley and what the values of those attributes are. Conforming implementations that don't like the proposed policy are free to decline to complete the KM negotiation or to terminate that KM exchange and start a new KM exchange with a policy that would be agreeable to that node. However, once the policy has been mutually negotiated via ISAKMP, both sides must be required to adhere to the negotiated policy. Note that none of my verbage says anything about what policies any particular box might consider acceptable. IMHO, the matter of what policy is acceptable is purely up to the local administrator and is not the business of an IETF VPN WG or any other standards body. All IMHO, Ran rja@home.net From owner-ipsec Wed Oct 22 02:36:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA07075 for ipsec-outgoing; Wed, 22 Oct 1997 02:34:05 -0400 (EDT) Date: Wed, 22 Oct 97 06:22:08 GMT Daylight Time From: Ran Atkinson Subject: Re: proposed changes to ISAKMP/Oakley To: "C. Harald Koch" , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <97Oct21.135835edt.11651@janus.tor.securecomputing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Tue, 21 Oct 1997 13:57:51 -0400 "C. Harald Koch" wrote: > 1) other people appear to be expecting ISAKMP to advertise proxy_ids, *and* > to use those proxy_ids as selectors, as you describe. > 2) I'm not sure how to 'advertise' my policy with ISAKMP exchanges. Source-ID with IP_SUBNET style identity with prefix 0.0.0.0 and netmask of 255.255.255.255. Request for Dan H. &/or Steve Kent: Please document this in the ISAKMP/Oakley spec or the IPsec Architecture Spec. The latter is IMHO really the right place since deployed manual keying supports Proxy-IDs and non-ISAKMP KM protocols might well support ISAKMP/Oakley. Obviously support for Proxy-IDs would be optional-to-implement for nodes not implementing a KM protocol that required them. The Proxy-ID is the identity of the entity that is performing outbound IPsec on behalf of the originator of the IP packet. The Proxy-ID is *NOT* the identity of the original cleartext IP packets. If Dan's document defines Proxy-ID differently, then it has changed the years-old definition of the term Proxy-ID and we should correct this before RFC. Please lets not change the standard terminology in the middle of things. :-) > If I attempt to negotiate an ISAKMP Phase 2 exchange *without* proxy_ids, or > with a different ID than the remote was expecting, then the SA is denied by > the remote, since it doesn't match their policy. Moreover, it doesn't match the policy that you negotiated with them. > So in order to fully interoperate, I *must* negotiate a proxy_id with an SA, > and then only use that SA for traffic related to the proxy_id. Almost. Change it to "...only use that SA for traffic related to the Source-ID." > Since the > most common ID used is ID_IPV4_ADDR, this leads to an SA per host-pair. Nothing says you cannot use an ID of ID_IPv4_ADDR however, so that isn't a real issue. > Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large > numbers of networks behind their security gateways. Thanks to the wonders of CIDR, things generally aren't as bad as you imply. > I like Dan's 0/0 proxy_id; I don't know how many other's would accept it, > though (How many of you would?). Again, its the (Source-ID == 0.0.0.0/32) that you mean (not Proxy-ID). > Here's another question: how many of you > link ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET, and ID_IPV4_ADDR_RANGE in your > policy engines? e.g. if you're expecting a subnet, and I send you a host > within that subnet, will you accept the SA and use it? Please note that I won't buy products that lack an administrative knob permitting me to cause the implementation to refuse all requests with a Source-ID of 0.0.0.0/32. I might or might not be a majority, but I'm sure I'm not entirely alone. In general, vendors that want to sell lots of product will let the box administrators have lots of policy knobs. Regards, Ran rja@inet.org From owner-ipsec Wed Oct 22 02:37:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA07089 for ipsec-outgoing; Wed, 22 Oct 1997 02:36:05 -0400 (EDT) Date: Wed, 22 Oct 97 06:34:29 GMT Daylight Time From: Ran Atkinson Subject: Re: Comments on AH and ESP drafts To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm with Eric. If a BITW implementation can't conform to the long-standing specs, then its broken. Watering down the provided/specified mandatory capabilities in order to accomodate broken implementations is a bad road for the IETF to travel. Ran rja@home.net From owner-ipsec Wed Oct 22 03:26:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07369 for ipsec-outgoing; Wed, 22 Oct 1997 03:22:33 -0400 (EDT) Message-Id: <199710220732.AAA04782@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: "C. Harald Koch" , ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley In-Reply-To: Your message of "Wed, 22 Oct 1997 06:22:08 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Oct 1997 00:32:45 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, > The Proxy-ID is the identity of the entity that is performing outbound > IPsec on behalf of the originator of the IP packet. The Proxy-ID is > *NOT* the identity of the original cleartext IP packets. If Dan's > document defines Proxy-ID differently, then it has changed the years-old > definition of the term Proxy-ID and we should correct this before RFC. Well, ahh, uummm, the proxy-id, as defined in the document, is the identity that the ISAKMP peer is proxying (ouch) for. Whether that breaks years-old definitions or not, that's the way it's written. Granted this doesn't jive quite well with the PF_KEY notion of a "proxy sockaddr" but I've known that for a while. PF_KEY also only defines a single "proxy". That's a limitation as well. So the naming of ISAKMP/Oakley is 1) different; and 2) more powerful than PF_KEY. > Please lets not change the standard terminology in the middle of things. :-) I don't particularly like "proxy identities". If you have a different term I'd be happy to entertain a change. But I think whether it's called blah or foo or proxy id, the information passed in those payloads is the identities for whom this negotiation is performed and not the identity of the ISAKMP peer. The peer's identity is determined by the cookies in the ISAKMP header. This doesn't mean that a compliant implementation can't take this blob-- of foo or blah or "proxy identity"-- and map it into the PF_KEY proxy sockaddr field (although since PF_KEY only allows a single sockaddr for this purpose I wonder how that mapping is done). This seems to be a semantic issue which can be solved by changing terminology somewhere. If anybody has any ideas-- either for PF_KEY or ISAKMP/Oakley-- now's the time.... > Please note that I won't buy products that lack an administrative knob > permitting me to cause the implementation to refuse all requests with > a Source-ID of 0.0.0.0/32. I might or might not be a majority, but > I'm sure I'm not entirely alone. In general, vendors that want to sell > lots of product will let the box administrators have lots of policy knobs. Fine. I know a certain router vendor which can satisfy this capability (hint: it's the one that's not selling to that copying company). A user has the ability to specify which traffic requires which policy. But is the semantics of what a "proxy" is a determining factor of what you'll buy or is the functionality the determining factor? Dan. From owner-ipsec Wed Oct 22 08:12:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08982 for ipsec-outgoing; Wed, 22 Oct 1997 08:09:05 -0400 (EDT) From: Tim Bass (IETF) Message-Id: <199710221211.IAA19909@linux.silkroad.com> Subject: Re: proposed changes to ISAKMP/Oakley To: rja@inet.org (Ran Atkinson) Date: Wed, 22 Oct 1997 08:11:35 -0400 (EDT) Cc: chk@utcc.utoronto.ca, ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Oct 22, 97 06:22:08 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large > > numbers of networks behind their security gateways. > > Thanks to the wonders of CIDR, things generally aren't as bad as you imply. The historical IETF RFCs were quite clear that CIDR should not be viewed as a long term solution for routing scalability issues. So, if we are going to use 'long standing tradition' as a basis for design requirements (as we are reading in this thread) then CIDR should not be mentally coupled or technically coupled with IPSEC. -Tim From owner-ipsec Wed Oct 22 11:08:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10118 for ipsec-outgoing; Wed, 22 Oct 1997 11:06:16 -0400 (EDT) Message-Id: <97Oct22.111724edt.11655@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: Proxy & ISAKMP/Oakley References: <199710202135.OAA02476@dharkins-ss20> In-reply-to: Your message of "Wed, 22 Oct 1997 02:01:00 -0400". 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: Wed, 22 Oct 1997 11:16:32 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Ran Atkinson writes: > > It is actually important that these semantics be clearly described somewhere. > If implementations don't use the same semantics, then badness is a high > probability outcome. Maybe I'm being unclear, but this is exactly the issue I'm wrestling with right now. -- Harald From owner-ipsec Wed Oct 22 11:08:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10127 for ipsec-outgoing; Wed, 22 Oct 1997 11:06:47 -0400 (EDT) Message-Id: <97Oct22.111750edt.11655@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: <97Oct21.135835edt.11651@janus.tor.securecomputing.com> In-reply-to: Your message of "Wed, 22 Oct 1997 02:22:08 -0400". From: "C. Harald Koch" Date: Wed, 22 Oct 1997 11:16:58 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > If I attempt to negotiate an ISAKMP Phase 2 exchange *without* proxy_ids, or > > with a different ID than the remote was expecting, then the SA is denied by > > the remote, since it doesn't match their policy. > > Moreover, it doesn't match the policy that you negotiated with them. I haven't negotiated any policy here; I've advertised a proposal, and had it refused because the proxy_id was unacceptable (but of course, I don't necessarily *know* that, depending on whether or not the remote sends a meaningful NOTIFY message.) My problem is that I can't *negotiate* policy here. I have to *advertise* a proxy_id that matches the other guys policy in order to have the SA accepted. Granted, if he denies the SA, then he should attempt a negotiation and advertise an acceptable proxy_id, but then he has to advertise one that *I* will accept. This quickly leads to non-interoperability between different vendors, or a proliferation of too-specific SAs. [ I could go so far as to assert that ISAKMP is an advertisment protocol, not a negotiation protocol; there's no defined semantics for what to do when two sides disagree on various parameters. ] What I'm trying to understand, right now, is what I have to advertise in order for my SAs to be accepted by other implementors' policy engines. > Source-ID with IP_SUBNET style identity with prefix 0.0.0.0 and netmask > of 255.255.255.255. That means you'll only accept packets with a source address of "0.0.0.0", which is (mostly) and invalid address: RFC 1122, section 3.2.1.3: (a) { 0, 0 } This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address. I believe you mean prefix 0.0.0.0 netmask 0.0.0.0, often written in CIDR speak as 0.0.0.0/0, or simply 0/0. > > Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large > > numbers of networks behind their security gateways. > > Thanks to the wonders of CIDR, things generally aren't as bad as you imply. Yes they are. CIDR is a response to routing scalability for the global Internet (and the RFCs say it is supposed to be a temporary measure). Since renumbering IPv4 hosts is *hard*, many people are dealing with CIDR (and provider based addressing) by using NAT technology. These people want to run IP Security gateways on their NATs, to connect the interior networks to each other. And, IME, Those interior network addresses are not CIDR compatible. -- Harald From owner-ipsec Wed Oct 22 12:40:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10730 for ipsec-outgoing; Wed, 22 Oct 1997 12:36:47 -0400 (EDT) Message-ID: <344E2DF0.D74@fet.com> Date: Wed, 22 Oct 1997 09:46:40 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > IMHO, omitting explicit definition of the Proxy-ID from the formal > definition of an IPsec SA is likely to lead to reduced security in > the operational Internet. Including it is likely to enhance security > in the deployed operational Internet. Agreed - but perhaps it should be noted that there are actually 2 proxies involved in some situations: USER1===|===SGW1--(INTERNET)--SGW2===|===USER2 Assume no SA exists between any of the systems above. USER1 attempts to reach USER2 via the path given. SGW1, upon receiving the first packet from USER1, notes that no SA exists. From its policy db, SGW1 notes that SGW2 is a proxy for USER2, and so begins ISAKMP negotiation with SGW2. In this case, there are 2 proxies involved: SGW1 and SGW2. SGW2 must recognize that it is acting as a proxy for USER2 in this negotiation, and also that SGW1 is a proxy for USER1. While in some cases policy may obviate the need for this knowledge (that SGW1 proxies for USER1) on SGW2's part, this should not be assumed. These two proxies should have unique names. From owner-ipsec Thu Oct 23 09:26:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17079 for ipsec-outgoing; Thu, 23 Oct 1997 09:18:49 -0400 (EDT) Message-ID: To: dharkins@cisco.com Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Re: draft of the ISAKMP/Oakley draft Date: Thu, 23 Oct 97 14:35:18 PDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan, I have two comments on your new draft. 1) A reference for the GSSAPI stuff is missing. 2) Last week I sent an e-mail to you and the list suggesting to add EC groups over GF(p) to the ISAKMP/Oakley draft. Up to now I haven't received any comment. Perhaps I should clarify my point: I believe that elliptic curves will be very important in the future and I support the addition of elliptic curve groups as optional D-H groups in the draft. However, I think that one should add examples for both 'types' of these curves, i.e., curves over GF(2^N) as well as curves over GF(p). GF(p) curves are more favourable in the ISAKMP/Oakley context because they are easier to implement since the necessary mod p arithmetic must always be supported by an ISAKMP/Oakley implementation. For curves over GF(2^N) an additional GF(2^N) arithmetic must be implemented. Furthermore, there are several patents covering different aspects of GF(2^N) arithmetic. I would appreciate a comment from you. Michael P.S. If you don't have examples for 'strong' curves over GF(p) we can provide them. From owner-ipsec Thu Oct 23 11:49:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17918 for ipsec-outgoing; Thu, 23 Oct 1997 11:45:32 -0400 (EDT) Date: Thu, 23 Oct 97 15:38:57 GMT Daylight Time From: Ran Atkinson Subject: Re: proposed changes to ISAKMP/Oakley To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199710220732.AAA04782@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 22 Oct 1997 00:32:45 -0700 Daniel Harkins wrote: > I don't particularly like "proxy identities". If you have a different term > I'd be happy to entertain a change. But I think whether it's called blah or > foo or proxy id, the information passed in those payloads is the identities > for whom this negotiation is performed and not the identity of the ISAKMP > peer. The peer's identity is determined by the cookies in the ISAKMP header. > This doesn't mean that a compliant implementation can't take this blob-- of > foo or blah or "proxy identity"-- and map it into the PF_KEY proxy sockaddr > field (although since PF_KEY only allows a single sockaddr for this purpose > I wonder how that mapping is done). > > This seems to be a semantic issue which can be solved by changing terminology > somewhere. If anybody has any ideas-- either for PF_KEY or ISAKMP/Oakley-- > now's the time.... After reading Dan H's draft in closer detail again, I concur that the capabilities there are fine. Not clear to me whether its better or not, but its clearly sufficient. The model is different, but that is mostly irrelevant because the two models can be mapped 1:1 trivially. What I'd suggest is that we wordsmith here a bit to try to minimise terminology-induced confusion. Perhaps the term Proxy-ID in ISAKMP/Oakley could be changed to something like "Client Identity" since in the ISAKMP/Oakley model, the entity whose identity is in the "Source Identity" field is _always_ the IPsec/ISAKMP entity. The other field in ISAKMP/Oakley is blank when the IPsec/ISAKMP entity is acting on its own behalf, but non-blank when the IPsec/ISAKMP entity is proxying on behalf of some other client node. :-) > > Please note that I won't buy products that lack an administrative knob > > permitting me to cause the implementation to refuse all requests with > > a Source-ID of 0.0.0.0/32. I might or might not be a majority, but > > I'm sure I'm not entirely alone. In general, vendors that want to sell > > lots of product will let the box administrators have lots of policy knobs. > > Fine. I know a certain router vendor which can satisfy this capability > (hint: it's the one that's not selling to that copying company). A user has > the ability to specify which traffic requires which policy. Cool. > But is the semantics of what a "proxy" is a determining factor of what > you'll buy or is the functionality the determining factor? Technical capabilities are the determining factor, so long as the vendor has clearly documented their semantics and knobs so that the administrator can find/configure the knobs correctly. I suspect that this won't be a problem for some router vendors by release time. :-) Ran rja@home.net From owner-ipsec Thu Oct 23 12:02:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18001 for ipsec-outgoing; Thu, 23 Oct 1997 12:01:02 -0400 (EDT) Date: Thu, 23 Oct 97 15:56:52 GMT Daylight Time From: Ran Atkinson Subject: correction on Proxy IPsec To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The other night while typing without enough coffee I made a confusing typo. The corrected text is something like this: The capability of supporting Proxy IPsec and having Proxy-IDs (or Client-IDs) in a KM protocol is NOT unique to ISAKMP/Oakley. It is a feature in a number of extant manually-keyed IPsec implementations. It also is a feature in other non-IETF KM protocols in the past. So I believe that the Proxy-ID attribute should be retained as an (optional-to-use) part of the IPsec Security Association defined in the Architecture document. Without retaining that, we lose an important operational capability in the IPsec standard. Apologies for my earlier mistyping. Ran rja@inet.org From owner-ipsec Thu Oct 23 12:41:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18214 for ipsec-outgoing; Thu, 23 Oct 1997 12:38:01 -0400 (EDT) Message-ID: <344F7FE1.2C67@cs.umass.edu> Date: Thu, 23 Oct 1997 12:48:33 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: proposed changes to ISAKMP/Oakley References: Conversation <199710122213.PAA24340@dharkins-ss20> with last message <199710122213.PAA24340@dharkins-ss20> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Bungert writes: > I suggest to add not only EC2N groups but also elliptic curve > groups over GF[p] with an odd prime p because these curves seem > to be more favourable: EC groups over GF[p] can easily be > implemented by using only ordinary modular arithmetic originally > developed for RSA for example. Furthermore in contrast to char 2, > use of this type of curves seems to be widely free of patents. Please correct me if I'm mistaken, but I'm under the impression that EC operations over GF(p) (for large prime p) are noticeably more computationally expensive than the EC operations over fields of characteristic 2, for fields offering comparable cryptographic strength. This sacrifice in run-time efficiency should be considered in balance with the cited advantages of operating mod p. I'd be happy to see some EC groups defined over GF(p) for ISAKMP/Oakley, but it's unclear to me thus far that using such groups is ultimately more favorable. -Lewis From owner-ipsec Thu Oct 23 14:06:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA18749 for ipsec-outgoing; Thu, 23 Oct 1997 14:01:33 -0400 (EDT) Date: Thu, 23 Oct 1997 14:08:03 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199710231808.OAA11978@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: draft of the ISAKMP/Oakley draft X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Michael Bungert > > 2) Last week I sent an e-mail to you and the list suggesting to add > EC groups over GF(p) to the ISAKMP/Oakley draft. Up to now I > haven't received any comment. I am surprised that HO has not replied to your last message. But since there has been no discussion, I'll second the request to add EC over GF(p). From owner-ipsec Thu Oct 23 14:11:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA18820 for ipsec-outgoing; Thu, 23 Oct 1997 14:09:57 -0400 (EDT) Message-Id: <199710231818.LAA07232@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Michael Bungert Cc: ipsec@tis.com Subject: Re: draft of the ISAKMP/Oakley draft In-Reply-To: Your message of "Thu, 23 Oct 1997 14:35:18 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Oct 1997 11:18:03 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > I have two comments on your new draft. > > 1) A reference for the GSSAPI stuff is missing. OK. > 2) Last week I sent an e-mail to you and the list suggesting to add > EC groups over GF(p) to the ISAKMP/Oakley draft. Up to now I > haven't received any comment. Perhaps I should clarify my point: > I believe that elliptic curves will be very important in the future > and I support the addition of elliptic curve groups as optional > D-H groups in the draft. However, I think that one should add > examples for both 'types' of these curves, i.e., curves over GF(2^N) > as well as curves over GF(p). GF(p) curves are more favourable in > the ISAKMP/Oakley context because they are easier to implement > since the necessary mod p arithmetic must always be supported by > an ISAKMP/Oakley implementation. > For curves over GF(2^N) an additional GF(2^N) arithmetic must be > implemented. Furthermore, there are several patents covering > different aspects of GF(2^N) arithmetic. > > I would appreciate a comment from you. > > P.S. If you don't have examples for 'strong' curves over GF(p) we > can provide them. I agree that it would be nice to have examples of all types of groups in the draft but... I can't escape the thought that there should be some Informational RFC somewhere that describes 'strong' groups. It has GF[p] groups, and better GF[2^N] groups and a 2048-bit MODP group and.... The reserved Group Description number space can be signed over to this RFC. I'd even entertain the thought of moving all but one group from the ISAKMP/Oakley draft there. I'd rather that the ISAKMP/Oakley draft not include too many groups (and it does already) because it's a distraction from the protocol definition. It has the capability to use bigger, faster, stronger groups if they exist. And they should exist in some Informational RFC that cryptographers and number theorists can all throw darts at. Dan. From owner-ipsec Thu Oct 23 15:56:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19396 for ipsec-outgoing; Thu, 23 Oct 1997 15:51:38 -0400 (EDT) Date: Thu, 23 Oct 1997 15:57:35 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199710231957.PAA24952@earth.hpc.org> To: Michael.Bungert@mchp.siemens.de Cc: ipsec@tis.com In-reply-to: Yourmessage <199710231403.HAA05935@baskerville.CS.Arizona.EDU> Subject: Re: draft of the ISAKMP/Oakley draft Sender: owner-ipsec@ex.tis.com Precedence: bulk I think you've got the patent situation backwards. It's GF[2^n] that is unencumbered. The available performance information indicates GF[2^n] can be exceedingly fast; I've not seen anything documenting comparable performance gains for GF[p]. The GF[2^N] arithmetic is not a killer ... who can object to shift and XOR? Hilarie > 2) Last week I sent an e-mail to you and the list suggesting to add > EC groups over GF(p) to the ISAKMP/Oakley draft. Up to now I > haven't received any comment. Perhaps I should clarify my point: > I believe that elliptic curves will be very important in the future > and I support the addition of elliptic curve groups as optional > D-H groups in the draft. However, I think that one should add > examples for both 'types' of these curves, i.e., curves over GF(2^N) > as well as curves over GF(p). GF(p) curves are more favourable in > the ISAKMP/Oakley context because they are easier to implement > since the necessary mod p arithmetic must always be supported by > an ISAKMP/Oakley implementation. > For curves over GF(2^N) an additional GF(2^N) arithmetic must be > implemented. Furthermore, there are several patents covering > different aspects of GF(2^N) arithmetic. From owner-ipsec Thu Oct 23 16:12:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19497 for ipsec-outgoing; Thu, 23 Oct 1997 16:09:05 -0400 (EDT) Message-Id: <344FAD6C.6405EA3C@zk3.dec.com> Date: Thu, 23 Oct 1997 16:02:52 -0400 From: "Eric L. Wong" X-Mailer: Mozilla 4.03 [en] (Win95; I) Mime-Version: 1.0 To: Ran Atkinson , dharkins@cisco.com Cc: ipsec@tis.com Subject: Re: proposed changes to ISAKMP/Oakley References: <199710220732.AAA04782@dharkins-ss20> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > : > : > After reading Dan H's draft in closer detail again, I concur that > the capabilities there are fine. Not clear to me whether its better > or not, but its clearly sufficient. > > The model is different, but that is mostly irrelevant because the > two models can be mapped 1:1 trivially. > > What I'd suggest is that we wordsmith here a bit to try to minimise > terminology-induced confusion. > > Perhaps the term Proxy-ID in ISAKMP/Oakley could be changed to > something like "Client Identity" since in the ISAKMP/Oakley model, > the entity whose identity is in the "Source Identity" field is > _always_ the IPsec/ISAKMP entity. The other field in ISAKMP/Oakley > is blank when the IPsec/ISAKMP entity is acting on its own behalf, > but non-blank when the IPsec/ISAKMP entity is proxying on behalf > of some other client node. :-) > : > : I think, IDui and IDur should also change to IDci and IDcr. From owner-ipsec Fri Oct 24 12:18:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26032 for ipsec-outgoing; Fri, 24 Oct 1997 12:10:55 -0400 (EDT) Message-ID: In-Reply-To: <199710231957.PAA24952@earth.hpc.org> References: Conversation <199710231403.HAA05935@baskerville.CS.Arizona.EDU> with last message <199710231957.PAA24952@earth.hpc.org> To: Hilarie Orman Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Re: draft of the ISAKMP/Oakley draft Date: Fri, 24 Oct 97 18:21:03 PDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, > I think you've got the patent situation backwards. It's GF[2^n] that > is unencumbered. I know that Certicom has patents in the field of elliptic curves over GF(2^N). I don't know patents for elliptic curves over GF(p). If you know some, please tell me. > The available performance information indicates GF[2^n] can be exceedingly > fast; I've not seen anything documenting comparable performance gains > for GF[p]. > > The GF[2^N] arithmetic is not a killer ... who can object to shift and XOR? > I do not object to shift and XOR, but an implementation of elliptic curves over GF(p) does not require any additional field arithmetic because the mod p arithmetic has always to be implemented. I do not suggest to remove GF(2^N) curves I suggest to add GF(p) curves. GF(2^N) arithmetic is very fast in hardware. Perhaps you know running times showing that software realizations of curves over GF(2^N) are also considerably faster than those of curves over GF(p). If so I am very interested in these numbers. Michael From owner-ipsec Fri Oct 24 12:22:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26134 for ipsec-outgoing; Fri, 24 Oct 1997 12:22:23 -0400 (EDT) Message-ID: In-Reply-To: <199710231818.LAA07232@dharkins-ss20> References: Conversation with last message <199710231818.LAA07232@dharkins-ss20> To: Daniel Harkins Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Re: draft of the ISAKMP/Oakley draft Date: Fri, 24 Oct 97 18:32:36 PDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, thank you for your reply. I have suggested the addition of GF(p) curves because I think that if an IETF standard recommends elliptic curves then both types (GF(p) and GF(2^N)) should be recommended. Obviously, my suggestion is supported by others but I can also agree to your proposal of having an Informational RFC describing strong groups and removing all but one mod p group from the ISAKMP/Oakley draft. Michael From owner-ipsec Fri Oct 24 12:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26309 for ipsec-outgoing; Fri, 24 Oct 1997 12:49:24 -0400 (EDT) Date: Fri, 24 Oct 1997 12:55:43 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199710241655.MAA23605@earth.hpc.org> To: Michael.Bungert@mchp.siemens.de Cc: ipsec@tis.com In-reply-to: Yourmessage Subject: Re: draft of the ISAKMP/Oakley draft Sender: owner-ipsec@ex.tis.com Precedence: bulk NeXT holds a patent on crypto uses of GF[p] where p is near a power of 2. See Schroeppel et al. in Crypto '95 for timings for GF[2^n]. Recent work improves on these times by using nested field extensions. All the methods are derived from public domain work and are not subject to patent. I don't have a comprehensive list of all patents regarding crypto with GF[2^n], but my understanding as of a year ago was that those that existed were relevant to hardware, not software. Maybe a posting of current relevant patents and titles would be of interest. If you have pointers to timings for GF[p] I'd be interested. Hilarie From owner-ipsec Fri Oct 24 14:06:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26824 for ipsec-outgoing; Fri, 24 Oct 1997 14:03:25 -0400 (EDT) Message-Id: <3.0.3.32.19971024140648.039dc0f0@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 24 Oct 1997 14:06:48 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: survey is on web site Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The survey information is on Ted's web site, see . A few people have sent me mail in the last couple of days, this will be updated, and I do not believe I've lost anything. As always, elvis and a few others didn't answer. "If you tested with someone, bug them to send in the form". From owner-ipsec Mon Oct 27 07:54:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14012 for ipsec-outgoing; Mon, 27 Oct 1997 07:41:25 -0500 (EST) From: "Alexander Galitsky" To: "Jim Thompson" , Cc: , , "Sergei Ryabko" , "Alexei Lesnykh" , , "Alexander Galitsky" Subject: Re: fyi Date: Sat, 25 Oct 1997 14:33:03 +0300 Message-ID: <01bce139$c156adc0$cec0bec2@sashaG.elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id GAA01509 Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk We will be happy to give all update about our IPsec progress in our FortE+ product line family: FortE+ Client and Terminal FortE+ Branch and Server FortE+ Enterprise Thanks Jim. We will pay more attention to IPsec society. --Sasha ************************************************************************** Alexander (Sasha) V. Galitsky, PhD phone +7 095 531 4633 President & CEO fax +7 095 531 2403 ELVIS Plus Centralny Prospect 11 email sasha@elvis.ru Moscow-Zelenograd, 103460 http://www.elvis-plus.com Russian Federation ************************************************************************** -----Original Message----- From: Jim Thompson To: sasha@elvis.ru Date: 24 ÏËÔÑÂÒÑ 1997 Ç. 23:28 Subject: fyi >>From rodney@sabletech.com Fri Oct 24 14:16:30 1997 >>X-PGP-Key: >>X-Sender: rodney@pop.pn.com >>Date: Fri, 24 Oct 1997 14:06:48 -0400 >>To: ipsec@tis.com >>From: Rodney Thayer >>Subject: survey is on web site >>Mime-Version: 1.0 >> >>The survey information is on Ted's web site, see >>. >> >>A few people have sent me mail in the last couple of days, this will be >>updated, and I do not believe I've lost anything. >> >>As always, elvis and a few others didn't answer. "If you tested with >>someone, bug them to send in the form". >> >> > From owner-ipsec Mon Oct 27 07:58:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14260 for ipsec-outgoing; Mon, 27 Oct 1997 07:58:32 -0500 (EST) From: "Alexei V. Vopilov" To: "SKIP-info MailList" , "IPsec MailList" Cc: "Alexei V. Vopilov" Subject: Inline SA Bootstrap protocol Date: Mon, 27 Oct 1997 15:58:24 +0300 Message-ID: <01bce2d8$02a348c0$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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 Hello, all An off-topic section -------------------- I see many people worldwide being involved in the ipsec discussion. I will greatly appreciate if someone familiar with US law clarifies (via direct reply) the legal aspects of ipsec contribution by non-US people in form like this memo. The difference (if any) to do this as not employed person (like me now) vice an employee working for non-US company would be helpful as well. Thank you in advance. Abstract -------- This memo proposes so-called Inline SA Bootstrap scheme. The inline SA bootstrap protocol allows create/re-key/synchronize particular SAs at the cost of (possible) exposure of Key Identifiers. The scheme is explained here based on the reference to the known SKIP-07 draft. Bill Sommerfeld, the author of the ...inline-isakmp-01.txt might want to inspect this memo for using the idea of SKIP protocol number (and it header) for inline SA bootstrap under ISAKMP protocol. Thank you, Bill, for valuable systematization of the questions to be addressed to inline SA setup problem. Hope that you might use some tips presented below during further development of your spec. The memo is, as well, an attempt to bring SKIP protocol on the list of RFC 1825-conformable and it serves for further development of this specification. The memo is sent to both ipsec and skip-info mailing lists and can be converted into one, two or zero drafts depending on your, folk, interest. Introduction ------------ This memo employs some of Bill Sommerfeld ideas, such as - Sending inbound SA SPI with the first packet of the bi- directional connection. - Implicit acknowledgement about a SA creation and inclusion the requested SPI value right in the backward traffic of particular connection. This memo defines in-band keying header format and proposes the framing model for inline SA setup protocol. Proposed scheme differs from Bill's by staying independent from ISAKMP/Oakley protocols and by using ESP/AH headers themselves to carry in-bound SPI value(s). The proposed scheme can be used for bi- and unidirectional traffic and might simplify such things as SA recovering and re-keying procedures. Most important security aspects are covered herein as well. Core idea --------- Suppose that two communicating parties use DH-type public keys for IPsec communication. If these DH keys are authenticated and assigned with identifiers, the parties can safely calculate shared secret based on DH algorithm. To setup particular SA the parties now need a context that includes at minimum: - Starting and Destination points of a SA. - Optional tunneling addresses. - Key ID of an Initiator. - Key ID of a Responder. - Core SA attributes, such ESP or AH protection, tunneling or transport mode and specific transforms identifiers. - SA session key. - SA scope, such as the IP protocol, source and destination ports. - SPI values (to be selected by a network data receiver). Assume that other SA attributes such as replay protection window, SA lifetime, etc can be assigned with default values. Let's propose the following framing of inline SA context. a) All but IPsec specific attributes are to be derived from native IP datagram. b) All security related attributes are derived from just introduced SA inline context header being included in the IP datagram along with optional application data. c) Some SPI values are to be reserved for carrying the inline SA protocol signals. To simplify things with SA inline header structure, the SKIP header format has been selected for scheme demonstration. Fortunately, SKIP header format contains all attributes required for the proposed protocol. The SKIP header will be referred to as SA_INLINE_CONTEXT hereinafter. Note: I'm not introducing here a new inline SA context header format to not enter in the discussion about it completeness and proven security (just trying to let already developed stuff serve people better ;-). In short, the Inline SA signals can be encoded with the help of reserved SPI values placed into ESP/AH headers following the SA_INLINE_CONTEXT header. For example, during normal SKIP operation the ESP/AH SPIs found there are set to reserved SKIP_SPI==1 constant as indication on SKIP as keying material source. Keeping it as is, let's introduce one more reserved SPI value == FORWARD_SA_REQUEST to serve as a command to convert SA_INLINE_CONTEXT framing into the plain ESP/AH. Having met with the FORWARD_SA_REQUEST SPI value along with SA_INLINE_CONTEXT header, a responder must consult with local security policy and, if it not refuses the proposal perform: - Create a SA template. - Select desired SPI value. - Send an Acknowledge with include SPI value back to the initiator. Upon getting the ACK receipt, the initiator fixes SPI value for unidirectional traffic and starts sending pure RFC 1825 packets (i.e. without SA_INLINE_CONTEXT header). Upon receiving the first packet of plain ESP/AH format, the responder fixes SA template to become just normal SA context. An initiator might want to request two SAs at once for bidirectional traffic when it sends inline SA request described above. It can be done by an initiator with the following algorithm: - Create forward SA template. - Create backward SA template. - Select SPI for the backward SA. - Send this SPI value instead of the FORWARD_SA_REQUEST one as a request for creating two SAs at once. In that case, the responder will acknowledge both SAs by sending ACK signal to the initiator. Thus, for bi-directional traffic two SAs can be created at the cost of only two packets roundtrip. If the inline SA request packet contains both ESP and AH headers, then two forward and two backward SAs will be created. In turn, all the transactions above additionally can carry an application data like FTP, NFS, PING, etc. Note: If SA_INLINE_REQUEST does not employ MAC transform, the extended scheme must be used instead of this simple one. (See Re:Hiding party identifiers and other stuff) A number of critical issues do arise with the proposed scheme, consequently: 1. The format of ACK packet. 2. Tolerance to replay attacks. 3. An inline SA Re-keying Procedure. 4. Hiding party identifiers and other stuff. 5. Interaction with ISAKMP or other Key Management application. The resolving of these issues extends the inline SA bootstrap scheme with additional data structures and adds extra logic to the protocol itself. Re: The format of ACK signal ---------------------------- Now, it's a time to reserve one more SPI value called FORWARD_SA_ACK. The algorithm to construct the SA ACK packet by the responder is as followed: - Create SA_INLINE_CONTEXT from the one containing FORWARD_SA_REQUEST SPI value. - Use Destination Key ID from the original SA_INLINE_CONTEXT header as Source Key ID in the new one. - The same is for Source Key ID from the original SA_INLINE_CONTEXT header. - Generate random packet encryption key and encrypt it using long-term shared secret between initiator and responder. - Set SPI value(s) in the new SA_INLINE_CONTEXT to have reserved FORWARD_SA_ACK constant(s). - Place the IP protocol number in the NEXT field of ESP/AH header. - Compose the inner datagram derived from the received FORWARD_SA_ACK packet as per examples below: Received Request packet format: [Original outer IP], [Original SA_INLINE_CONTEXT (SKIP)], [ESP (SPI= FORWARD_SA_REQUEST, Next = TCP)], [Encrypted TCP header, Encrypted TCP data] [ESP trailer][Opt MAC Data] Sent ACK packet format: [Outer IP header] [Constructed BACK_SA_INLINE_CONTEXT], [NEW_ESP (SPI= FORWARD_SA_ACK, Next = IP)] [Original outer IP], [Original SA_INLINE_CONTEXT (SKIP)], [ESP (SPI= responder-assigned SPI, Next = TCP)], [DECRYPTED TCP header, OPTIONAL TCP data] Above example shows an ACK on created transport mode SA, next is for ACK on tunneling SA request. Received inline SA request packet format: [Original outer IP], [Original SA_INLINE_CONTEXT (SKIP)], [ORIGINAL_ESP (SPI= FORWARD_SA_REQUEST, Next = IP)], [Encrypted inner IP header], [Encrypted TCP header, Encrypted TCP data] [ESP trailer][Opt MAC Data] Inline SA creation ACK packet format: [Outer IP header] [Constructed BACK_SA_INLINE_CONTEXT], [NEW_ESP (SPI= FORWARD_SA_ACK, Next = IP)] [Original outer IP], [original SA_INLINE_CONTEXT (SKIP)], [ORIGINAL_ESP (SPI= responder-assigned SPI, Next = IP)], [DECRYPTED inner IP header], [DECRYPTED TCP header, OPTIONAL TCP data] The remaining steps are: - Encrypt/Authenticate NEW_ESP datagram according to the BACK_SA_INLINE_CONTEXT rules - Send resulting packet to the initiator Note 1: Information presented in the scope of ORIGINAL_ESP header of ACK packet is not encrypted, so does not comply with respective RFC! If it seems inappropriate, a IP protocol type has to be introduced. Note 2: OPTIONAL application data can be just excluded, since remaining fields serve as comprehensive selector for the SA template saved on the initiator side. Note 3: The original outer IP header, the decrypted inner IP header and the decrypted application protocol header must be sent back unmodified. Even the IP checksum and length fields! Note 4: The described ACK signal must not carry any application data sent by an application to the responder side. Implicit ACK signal ------------------- When an initiator wants to request both forward and backward SAs, he selects backward SPI and sends it inside the inline SA request packet. A receiver of such packet treats the presence of non-reserved SPI value along with SA_INLINE_CONTEXT header as a request to create SAs for both directions. This case works only when both parties are ware that an application on responder side will definitely reply upon the receiving first packet from the connection initiator. This reply is generated, in turn, not by IPsec itself, but by an application and serves as implicit acknowledgement on the backward SA creation as well as carries the SPI value for the forward SA requested of the initiator. All backward packets must always include SA_INLINE_CONTEXT header until the initiator will start sending plain RFC1825 datagrams. The exact operation modes and algorithm identifiers for the backward SA are chosen by a responder. Re: Tolerance to replay attacks ------------------------------- Well, this very important issue must be always considered when implementing described protocol. First proposed replay protection scheme works under the following assumptions: a) SA_INLINE_CONTEXT implements coarse grained replays protection b) An implementation caches all SPI values proposed by remote systems during the period, when SA_INLINE_CONTEXT replay protection mechanism does not work. c) An implementation must silently drop all SA requests and ACK packets having SPI values found in cache. Fortunately, SKIP protocol employs coarse-grained replay protection besides one-hour time interval. If SAs establishment rate is two per second, the cache must support 2*3600=7200 SPI entries. Note 1: Replayed Acknowledgments can be recognized within protocol state machine. Note 2: An implementation must not produce the same SPI values within two hours interval. First scheme won't work in case when machine has been just rebooted, so the SPI cache is lost. It can be reactivated based on facts: a) At least one 'right' SA has been established by the remote node. b) The current IP-ID value of the remote IP implementation has been captured upon completion of (a). c) The ID counter of IP datagrams sent by the remote node is expected to be monotonically increased within some predefined window. Second replay protection scheme works independently from the first one. In addition, it can be used to catch the fact (a) mentioned above at the cost of dropping application data sent in the inline SA requests. Dropped packets either will be reposted by an application or do not have much value. In short, for unidirectional inline SA requests, the algorithm for the responder is: - Send generated SPI value and ACK packet as usually, but block application data from being passed upstream. - If 'old' SA for the requested IP protocol and ports exists, continue to accept traffic on it. - Continue apply above techniques for all further requests. - Fix new SA only when received and successfully checked first packet of plain ESP/AH format that employs generated SPI in effect. - Delete 'old' SA if it exists. For bidirectional inline SA requests apply: - Create two SA templates, but do not activate them. - Continue accept data sent under 'old' SAs (if any exists). - Continue drop application data found in inline SA requests. - On each inline SA request continue send generated SPI value along with ACK packet from within ipsec engine. - Wait for the first successfully received packet of plain ESP/AH format. - Activate both SAs. Summarizing this section, to successfully prevent replaying attacks under inline SA bootstrap protocol an implementation must either always support SPI values cache or employ extended scheme done at the cost of possible losing some IP datagrams. Re: An inline SA re-keying procedure ------------------------------------ The proposed protocol allows change current keys on the fly. If a party wants to change the session Key for particular SA, it sends inline SA requests as described before. The receiver of such requests must create new SA context and reply with new generated SPI value. Upon protocol completion, old SA is destroyed. Note 1: If an initiator sends proposal on re-creation the backward SA as well, the responder must either spawn corresponded outgoing connection into separate SA or refuse entire request. Note 2: It is possible design inline SA error notification similar to the ACK packet format at the cost of one more reserved SPI value. Re: Hiding party identifiers and other stuff -------------------------------------------- Although the inline SA bootstrap protocol makes the SA context visible to eyedropper it can be improved at the minimal cost for an implementation. The way to get additional security is encapsulation of inline SA bootstrap packets. For the host ipsec implementation the SA initiator likely will be a user who wants get access to secured resources of remote server (responder). IMO, the server must have at least one well-known and authenticated Public-Key identifier. Otherwise, even ISAKMP cam meet definite problem to setup it master SA the right way. The most important thing here seems to hide identities of the SA initiator (i.e. user). Following this goal, a SA initiator generates DH key (under SKIP SA_INLINE_CONTEXT case) and composes the following inline SA request packet: [Outer IP] [SA_INLINE_CONTEXT (generated Key ID-i, known Key ID-r)], [ESP (SPI=SKIP_SPI, next header = SKIP/IP)], { [Optional IP header], [SA_INLINE_CONTEXT (original Key ID-i, any Key ID-r)], [ESP (SPI=FORWARD_SA_REQUEST/BOTH_SA_REQUEST, next header = IP], {{[Inner IP, application data]}} } {:} Bracketed data are protected based on generated Key of the initiator and well-known key of the responder. {{:}} Bracketed data additionally is protected by original Key of the initiator and any from Keys of the responder. Since the outer SA_INLINE_CONTEXT contains just SKIP_SPI value, a responder will not try to complete inline SA bootstrap protocol on it. However, the responder must send an ACK packet under additional protection of the received, outer SA_INLINE_CONTEXT header. Generated Key ID must be cryptographically bundled with generate Public Key. For example, so-called UDH certificate format as per SKIP drafts proposes using of MD5 hash over DH Public-Key and other attributes. A party can retrieve this certificate via online request to the remote node. Re: Interaction with ISAKMP or other Key Management application. ---------------------------------------------------------- Inline SA bootstrap scheme can work together with any Key Management application and provide benefits both for KM application functionality and overall system security. For example, the ISAKMP situation includes possibility of negotiation a SA context using protocol/port wildcards. However, it is not possible add/delete particular connection to/from SA context without reestablishing entire Security Association. With inline SA bootstrap protocol, one can provide fine runtime tuning the explicit set of protocols/ports, which are bundled to specific SA. Next issue comes from SA re-keying procedure. If the encryption key lifetime set say, to 512Kb of transferred data, the re-keying procedure may take place every 0.5 sec for 10Mbits-network carrier. From other hand, if 600 SAs were established for a long period and the encryption key lifetime was set to 5 min, the re-keying procedure needs to be applied as well twice per second regardless of underlined network bandwidth. In turn, one SA re-keying will take two SPI delete/create operations. With using inline SA bootstrap, parties, if won't to expose their identifiers, can negotiate fictive IDs to use in the SA_INLINE_HEADER when changing their session key. The parties need not enter in the mutual authentication each time the key will be changed. A message for SKIP people ------------------------- IMO, SKIP protocol remains valuable alternative to the session-oriented Key Management since it stays closer to stateless IP network protocol nature. Whenever the unreliable datagram scope is considered as critical environment to operate on, SKIP provides the best performance/reliability characteristics. However, it does not fit into RFC 1825 requirements. Consequently, it needs further development of it basic specification as well as various extensions, which will make independent implementation more robust and interoperable. By the way, in the official IETF drafts archive SKIP specification is marked as obsolete. Moreover, it text is no more available for downloading. For this reason, could someone answer following questions? - Is it still on the public domain? - Will SUN keep it in the list of proposed IETF standards? - If above is yes, is there any author who will take care about development of the next version, is it possible to contact him? A message for all ipsec-oriented folk ------------------------------------- To date plenty companies have done implementation of core IPsec engine. However, most of them employ only shared secret management capability. With using inline SA bootstrap scheme it would be possible design extended SA management even staying only with shared secret keys. It is easy to see that INLINE_SA_HEADER can carry an index of that shared secret and SA context information to perform requests for particular SA management without entering in complicated application level KM negotiations. If the whole scheme will not be compromised by you, ipsec people, it can be used successfully for many things, which currently are marked as "TBD" in the respective drafts. I have found following areas: - The discovering security gateways - The synchronization of lost ISAKMP state - The ability to have multiple master ISAKMP SAs established between the same parties - A SA negotiation via a proxy party - The support for broadcast and multicast IPsec communications Most of the above mentioned schemes can be implemented at the cost of additional reserved SPI values and with using the same framing model. Let me know, if possible, your opinion. Regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture & Development Consultant. --- From owner-ipsec Mon Oct 27 11:10:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15437 for ipsec-outgoing; Mon, 27 Oct 1997 11:08:29 -0500 (EST) Date: Mon, 27 Oct 97 16:07:34 GMT Standard Time From: Ran Atkinson Subject: Re: Inline SA Bootstrap protocol To: "Alexei V. Vopilov" , IPsec MailList , SKIP-info MailList Cc: "Alexei V. Vopilov" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <01bce2d8$02a348c0$LocalHost@ppalx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, I'd suggest that all inline proposals be deferred for IPsecond or a future ISAKMP WG. Ran rja@inet.org From owner-ipsec Mon Oct 27 14:16:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16633 for ipsec-outgoing; Mon, 27 Oct 1997 14:14:04 -0500 (EST) From: Will Fiveash Message-Id: <199710271925.NAA39928@vulcan.austin.ibm.com> Subject: More Proxy ID questions To: ipsec@ex.tis.com (IETF IPSEC) Date: Mon, 27 Oct 1997 13:25:14 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL32 (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've been watching the discussion about Phase II Proxy IDs with interest and have a couple of questions regarding the processing of these IDs. As a preface to my questions, my understanding of the uses of Proxy IDs is 1; to specify the selector(s) that the Initiator and Responder will use to associate particular IP packets to the tunnel utilizing the SA(s) negotiated in Phase II. And 2; to determine the appropriate Security Policy for use in negotiation. What does it mean when the Initiator sends a IDui, IDur and the Responder doesn't send any IDs? Does this imply that the Responder will be using the vaules in the ID payloads sent by the Initiator as selectors for that particular SA? What should happen when the Initiator sends a IDui, IDur and the Responder sends IDui, IDur that differ from the Initiator's IDs? Is this an error? Also, in our implementation, if the selector IP addresses are different from the IP addresses associated with the Phase II (IPSec) SA then tunnel mode must be used so that the system that receives a IPSec packet can locate the correct SA. If this is universally true across the various implementations then shouldn't the draft-ietf-ipsec-isakmp-oakley specify that the Encapsulation Mode MUST be tunnel? My concern is that if this isn't specified this could be a source of numerous tunnel configuration errors. -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 VNET: FIVEASH AT AUSTIN Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Mon Oct 27 18:43:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18063 for ipsec-outgoing; Mon, 27 Oct 1997 18:40:33 -0500 (EST) Message-Id: <199710272359.PAA08503@mailsun2.us.oracle.com> Date: 27 Oct 97 13:48:16 -0800 From: "PALAMBER.US.ORACLE.COM" To: alx@elnet.msk.ru Subject: US Export Law and the IETF Cc: ipsec@tis.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex, Here's a quick summary of the impact of US export laws on the IPsec mailing list: US Export Law and the IETF US citizens are restricted from discussing export controlled "technical information" except in a standards forum. Controlled technical information includes the description of cryptographic algorithms and protocols that might be used to construct a product that would be subject to US export controls. The intent of this law is to prevent export regulations from being circumvented by exporting the design information. The IETF is an international standards organization and details of security standards including cryptographic algorithms and protocols can be freely discussed in this forum. This includes e-mail discussions and IETF meeting held in international locations. Encryption proposals, implementation discussions, security protocol designs may all be discussed in the IETF when they are part of the standards process. Working cryptographic software cannot be posted on any IETF mailing list by a US citizen or any employee of a US owned subsidiary. Paul PS: These are my opinions of the US export regulations and should not be considered as a position of my company. I am not a lawyer and you use this advice at your own risk. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (650) 506-0370 500 Oracle Parkway, M/S 5op10 Fax: Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com PGP: F4 B9 3B 17 BD 49 3B 0C 9E B9 95 E2 42 CA 02 E3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Mon Oct 27 19:31:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18307 for ipsec-outgoing; Mon, 27 Oct 1997 19:31:04 -0500 (EST) Message-Id: <97Oct27.194136est.11649@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: quiet and last calls From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8451.877999274.1@rafael.tornd.securecomputing.com> Date: Mon, 27 Oct 1997 19:41:15 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk It's quiet around here... Whatever happened to "we're going to last call right after the ANX workshop"? Are we still waiting for the adjusted Security Architecture? (everything else is out, I believe). -- C. Harald Koch "Madness takes its toll. Please have exact change." -Karen Murphy From owner-ipsec Tue Oct 28 01:10:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA19931 for ipsec-outgoing; Tue, 28 Oct 1997 01:08:11 -0500 (EST) Date: Tue, 28 Oct 1997 01:18:30 -0500 Message-Id: <199710280618.BAA24149@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: AH/ESP Last Call Results Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, As you know, Bob Mosckowitz and I started a working group last call on a series of documents, including the AH/ESP drafts, on October 6, 1997. This last call period ended on October 17, 1997. These are the results of the last call. During this period, a number of issues were brought up; most of them were non-controversial, and those suggestions were adopted without. There were three issues, however, which were did attract a fair amount of discussion. Those three issues have been identified below, with a proposed resolution, which was based on what seemed to represent most amount of consensus. If you have strong feelings with one of these proposed resolutions to these issues below (and ideally if you have strongs and new technical arguments which for some reason didn't reach the working group during the last call period), please state them now. If we hear no objections, though, this is how we plan to proceed towards making the final adjustments before these two drafts are declared to be done and ready to be shipped to the IESG. Many thanks to Karen Seo who was invaluable to us in helping to prepare this document. - Ted =============================================================================== PENDING Both AH and ESP --------------- 1. Sequence Number and Anti-replay Service -- 3 options have been proposed over the past several months. (B) was chosen over (A) back about 2 months ago. (B) is what's in the text at present. (B) is a perhaps bit better than (C) but both are pretty similar. It seems simplest at present to stick with (B). S = Sender AR = anti-replay R = Receiver Seq# = sequence number Sender Default To initiate AR Pro Con ------- ------------------ ----------------------- ----------------------- A) AR OFF S negotiates AR ON, - Deterministic, reli- Have to change Oakley/ R accepts/rejects able way for S & R to ISAKMP know AR status - Handles manual keying B) AR OFF R SHOULD notify S - Handles manual keying - NOTIFY is unreliable, that AR is ON - No changes to Oakley/ so S may continue to ISAKMP send while R rejects C) AR ON R MAY notify S that - No changes to Oakley/ - NOTIFY is unreliable, AR is ON or OFF ISAKMP so S may stop sending - Does not rely on when didn't need to unreliable NOTIFY to - Requires special case get S to monitor Seq# for manual keying PROPOSED RESOLUTION: Use option (b), leaving text as is. 2. Nesting of IPsec headers -- several issues have been raised during working group last call. A) How does OAKLEY/ISAKMP support specification of the ordering of nested IPsec headers, e.g., AH + ESP vs ESP + AH? B) Should IPsec support arbitrary nesting or a limited set of ordered combinations of AH and ESP, in tunnel and transport modes? If not, - how do we propose to support the IPv6's requirement that systems accept arbitrary combinations of extension headers? - how do we propose to handle the situation of a BITW implementation adding additional IPsec headers after the host implementation (native or BITS) has added IPsec headers? - should we address arbitrary nesting in IPsecond? C) Do we need to add text clarifying how to handle nested headers by iteratively processing them -- discarding consumed headers, adjusting the mutable fields of the outer header, etc. NOTE: The following text is in the Architecture document not in the AH/ESP document. It was included as a warning to the reader in the AH/ESP draft announcement, but not in the drafts. Support for arbitrary nesting requires that implementations ensure that any mutable "AH protected" fields outside/above the AH header, i.e., IP length, IP Next Protocol and any IPsec headers, are appropriately handled by Outbound and Inbound processing as the headers are nested and unnested. To ensure interoperability, the implementation should ignore the existence (i.e., neither zero the contents nor try to predict the contents) of IPsec headers to be applied later when o constructing an IPsec header o adjusting the IP length and IP Next Protocol in the IP header or immediately preceding IP extension header This will apply to: [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper] Nesting involving only ESP headers should not be problematic: [IP][ESP][ESP]...[ESP][upper] D) Do we need to add text clarifying that these issues apply to multiple nested headers for a single tunnel? PROPOSED RESOLUTION: i. Define a small set of mandatory cases that must be supported. Starting with a packet [IP1][upper].... Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Plus any combination of one of the above Tunnel cases followed by one the above Transport cases, i.e., 4 then 1, 4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3. ii. Postpone figuring out how to handle other cases (mods to Oakley/ISAKMP, clarifications for processing, etc.) to IPsecond: iii. Address (C), and (D) above as appropriate given this resolution. 3. HMAC-MD5 and HMAC-SHA --- which is mandatory, and which is strongly suggested. There is a discrepancy between the various drafts as to which the above two algorithms are mandotory, and which are "strongly suggested". A) The DOI lists 1 mandatory authentication algorithm: - HMAC with MD5 and 1 "strongly encouraged" authentication algorithm: - HMAC with SHA-1 B) The AH and ESP specs list 2 mandatory authentication algorithms: - HMAC with MD5 - HMAC with SHA-1 There was quite a bit of discussion of this on the list, with the last message coming from Hugo who stated that he felt that HMAC-SHA *was* stronger than HMAC-MD5, and that while the current (partial) attacks on MD5 do not affect HMAC-MD5, HMAC-SHA was definitely stronger, and he only felt comfortable suggesting the use of HMAC-MD5 if it was also possible to "quickly switch" to HMAC-SHA if further cryptographic advances made this advisable. Given that nearly all the vendors had implemented both in their implementations, either choice did not appear to make much real difference to implementors. PROPOSED RESOLUTION: That the AH and ESP specs require both HMAC-MD5 and HMAC-SHA to be required, and that the DOI be changed to also state that both algorithms are required. =============================================================================== RESOLVED Both AH and ESP --------------- 1. Add reference to RFC 2119 for definitions of keywords. Added the following paragraph at the end of the Introduction: "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]." Added the following text to the References: "[Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997." 2. Change text for Sequence Number Verification: AH: From: (3.4.3 Sequence Number Verification) All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. To: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. ESP: From: (3.4.3 Sequence Number Verification) All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. To: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. 3. Modify text on ICV re: o length and truncation -- clarify that 96 bits is appropriate for the default HMAC algorithms, but is not the general case. o clarify that inbound checking of ICV is algorithm dependent AH From: (2.6 Authentication Data) This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.3.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. To: This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.3.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps to use for validation. From: (3.2 Authentication Algorithms) The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. Note: Where an algorithm yields more than 96 bits, the output of the computation is truncated to the leftmost 96 bits. To: The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. From: (3.4.4 Integrity Check Value Verification, 3rd paragraph) Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the saved value. Note that if the output of the authentication algorithm is greater than 96 bits, the output should be truncated to the leftmost 96 bits. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) To: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) ESP From: (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 depends upon the authentication function selected. However, where the algorithm yields more than 96 bits, the output of the computation is truncated to the leftmost 96 bits. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. To: 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 depends upon 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 to use for validation. From: (3.2.2 Authentication Algorithms) The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. Note: Where an algorithm yields more than 96 bits, the output of the computation is truncated to the leftmost 96 bits. To: The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. From: (3.4.4 Integrity Check Value Verification, paragraph 3) Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value. Note that if the output of the authentication algorithm is greater than 96 bits, the output should be truncated to the leftmost 96 bits. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) To: Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) AH Only ------- 1. Modify AH section on ICV calculation to make clear what value should reside in the IP base header for Protocol or Next Header. Specifically, change: From: (3.3.3.1.1.1 Base Header Fields) The IPv4 base header fields are classified as follows: Immutable ..... Protocol ..... To: The IPv4 base header fields are classified as follows: Immutable ..... Protocol (This should be the value for the next header, e.g., AH or ESP.) ..... From: (3.3.3.1.2.1 Base Header Fields) The IPv6 base header fields are classified as follows: Immutable ..... Next Header ..... To: The IPv6 base header fields are classified as follows: Immutable ..... Next Header (This should be the value for the next extension header, e.g., AH, ESP, Destination Options, etc.) ..... ESP Only -------- 1. [Sch94] was not referenced. Delete the following text from the Reference Section: "[Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2" 2. Clarify how inbound processing of encryption "Padding" field is handled. Change... From: (3.4.5 Packet Decryption) The receiver: ...... 2. removes/ignores any padding ...... To: The receiver: ...... 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. ...... 3. Clarify that Padding is calculated using only the "to be encrypted portion of the Payload Data." Change... From: (2.4 "Padding (for Encryption)") The transmitter MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. To: The transmitter MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). 4. Provide rationale for terminating Pad Length and Next Header fields on 4-byte boundary... Change... From: (2.4 "Padding (for Encryption)") Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above. To: Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. 5. Add the following note to (2.3 "Payload Data"): Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be handled." 6. Change 3.3.4 "Integrity Check Value Calculation", paragraph 2 -- clarify placement of implicit padding. From: For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet prior to ICV computation. ... To: For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, (after the Next Header field) prior to ICV computation. ... 7. Clarify Section 3.4.5 -- if run in parallel, verification must be *completed* before decryption. From: If authentication has been selected, ICV verification SHOULD be performed before decryption. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. Note: The receiver MAY start decryption in parallel with authentication, but care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. To: If authentication has been selected, verification and decryption MAY be done serially or in parallel. If done serially, then ICV verification SHOULD be performed first. If done in parallel, verification SHOULD be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. Note: If the receiver does decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. From owner-ipsec Tue Oct 28 11:42:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23561 for ipsec-outgoing; Tue, 28 Oct 1997 11:26:03 -0500 (EST) Message-ID: In-Reply-To: <199710241655.MAA23605@earth.hpc.org> References: Conversation with last message <199710241655.MAA23605@earth.hpc.org> To: Hilarie Orman Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Re: draft of the ISAKMP/Oakley draft Date: Tue, 28 Oct 97 17:34:45 PST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, We do not yet have a comprehensive list of patents regarding elliptic curve cryto systems. I don't have a published list of reliable running times for elliptic curves over GF(p) but our implementations show that timings comparable to yours published on crypto '95 should be possible. BTW, it might be prudent to avoid GF(2^N) fields with nested subextensions because this additional structure could be used for attacks in the future. Again, my argument for the addition of GF(p) curves is not a better performance than GF(2^N) curves but the fact that GF(p) curves do not require an additional arithmetic because the mod p arithmetic is always implemented. Therefore, GF(p) curves offer a simple migration from mod p to elliptic curve crypto systems. Michael From owner-ipsec Tue Oct 28 18:41:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26112 for ipsec-outgoing; Tue, 28 Oct 1997 18:40:26 -0500 (EST) Date: Tue, 28 Oct 1997 18:50:53 -0500 Message-Id: <199710282350.SAA13577@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Issue with GSSAPI and the ISAKMP/Oakley resolution document Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, My apologies for not having a chance to look at this sooner, but Morton's law has unfortunately been applying in my life --- when it rains, it pours.... I've been looking over the GSSAPI authentication in the ISAKMP/Oakley document, and I think there's a potential problem in that the text appears to assume that a GSSAPI exchange is a single round-trip. In fact, a GSSAPI mechanism can have any number of whole (or a half) round trip. So if hosts A and B are engaging in a GSSAPI exchange, all of the following might happen, depending on the GSSAPI mechanism: A --> B A --> B B --> A A --> B B --> A A --> B A --> B B --> A A --> B B --> A etc. The text seems to presume the second case above, which is A sends a token to B, and then B sends a token back to A. However, this is not general enough. In fact, Mike Swift from Microsoft just submitted a GSSAPI mechanism for supporting Kerberos 5 user-to-user authentication which requires two full round trips of token exchanges (draft-ietf-cat-user2user-00.txt). This may simply require a simple textual fix to the GSSAPI section of ISAKMP/Oakley. However, the fix may be more complex than that, since the ISAKMP/Oakley document appears to assume a fixed number of round-trips, and the GSSAPI mechanism violates this assumption. - Ted From owner-ipsec Wed Oct 29 07:27:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29977 for ipsec-outgoing; Wed, 29 Oct 1997 07:24:01 -0500 (EST) Message-Id: <3.0.3.32.19971029073301.00aa5690@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 29 Oct 1997 07:33:01 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: WG Last Call Results Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and I discussed the status of the documents on Oct 27th. This is our view of where we are: draft-ietf-ipsec-isakmp-08.txt DONE draft-ietf-ipsec-oakley-02.txt DONE draft-ietf-ipsec-ipsec-doi-04.txt draft-ietf-ipsec-ipsec-doi-05.txt DONE draft-ietf-ipsec-doc-roadmap-01.txt DONE draft-ietf-ipsec-esp-v2-00.txt updated: draft-ietf-ipsec-esp-v2-01.txt Open items draft-ietf-ipsec-auth-header-01.txt updated: draft-ietf-ipsec-auth-header-02.txt Open items draft-ietf-ipsec-auth-hmac-md5-96-00.txt draft-ietf-ipsec-auth-hmac-md5-96-01.txt TBP, then DONE draft-ietf-ipsec-auth-hmac-sha196-00.txt draft-ietf-ipsec-auth-hmac-sha196-01.txt TBP, then DONE draft-ietf-ipsec-ciph-des-expiv-00.txt DONE (Note: TBP == To Be Published) Thus all of the above, other than ESP and AH are completed. draft-ietf-ipsec-isakmp-oakley-05.txt was published on 10/20. We should finish it up for last call on 11/3. We are working on finalizing changes for draft-ietf-ipsec-arch-sec-01.txt It looks like the last IESG teleconference call before DC is 11/20. We need to finish all of these documents by 11/7 if we are going to give Jeff enough time to prepare the balloting. PLEASE EVERYONE!!!! Give all of these documents one final combing for conflicting statements. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Oct 29 15:15:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02898 for ipsec-outgoing; Wed, 29 Oct 1997 15:08:11 -0500 (EST) Message-ID: <6B5344C210C7D011835C0000F8012766829A71@EXNA01> From: "Linn, John" To: ipsec@tis.com, "'Theodore Y. Ts'o'" Subject: RE: Issue with GSSAPI and the ISAKMP/Oakley resolution document Date: Wed, 29 Oct 1997 15:19:40 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Ted's point about the variable-hop issue. I'll also observe a couple of other specific clarifications wrt the GSSAPI integration as discussed: Page 10 states: For authentication using GSSAPI, the GSSAPI package on either side provides authentication of the GSSAPI identities, and HASH_I and HASH_R are used to bind the GSSAPI identities and tokens to the Main Mode exchange. Each side MUST specify the GSS_C_MUTUAL_FLAG to request mutual authentication between the two GSSAPI packages. A provision is defined for the GSSAPI peers to exchange GSSAPI identities during Main Mode, at the expense of identity protection for the GSSAPI endpoint identities. The GSS_C_MUTUAL_FLAG is input only by the context initiator (to solicit a mutual authentication response from the target), not by the target. Page 16 states: If the GSSAPI requires that the initiator and responder have prior knowledge of the GSSAPI endpoint names for each peer, this information may be exchanged during the first round trip (by including the GSS Identity Name attribute in the SA) at the expense of identity protection for the GSSAPI endpoints. When the GSSAPI requires the exchange of identity names, Aggressive Mode cannot be used. Any GSSAPI context initiator must have prior knowledge of the name of the target to which it's initiating a context, in order to input that name to GSS_Init_sec_context(). GSSAPI doesn't require that a target have prior knowledge of the name of an initiator which is establishing a context to it; instead, the initiator's name is delivered to the target as a result of context establishment. --jl John Linn, writing as an individual from RSA Laboratories East, Bedford, MA, USA > ---------- > From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] > Sent: Tuesday, October 28, 1997 6:50 PM > To: ipsec@tis.com > Subject: Issue with GSSAPI and the ISAKMP/Oakley resolution > document > > Hi all, > > My apologies for not having a chance to look at this sooner, but > Morton's law has unfortunately been applying in my life --- when it > rains, it pours.... > > I've been looking over the GSSAPI authentication in the > ISAKMP/Oakley document, and I think there's a potential problem in > that > the text appears to assume that a GSSAPI exchange is a single > round-trip. In fact, a GSSAPI mechanism can have any number of whole > (or a half) round trip. So if hosts A and B are engaging in a GSSAPI > exchange, all of the following might happen, depending on the GSSAPI > mechanism: > > A --> B > > A --> B B --> A > > A --> B B --> A A --> B > > A --> B B --> A A --> B B --> A > > etc. > > The text seems to presume the second case above, which is A sends a > token to B, and then B sends a token back to A. > > However, this is not general enough. In fact, Mike Swift from > Microsoft just submitted a GSSAPI mechanism for supporting Kerberos 5 > user-to-user authentication which requires two full round trips of > token > exchanges (draft-ietf-cat-user2user-00.txt). > > This may simply require a simple textual fix to the GSSAPI > section of ISAKMP/Oakley. However, the fix may be more complex than > that, since the ISAKMP/Oakley document appears to assume a fixed > number > of round-trips, and the GSSAPI mechanism violates this assumption. > > - Ted > From owner-ipsec Wed Oct 29 21:24:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05159 for ipsec-outgoing; Wed, 29 Oct 1997 21:21:46 -0500 (EST) Message-Id: <3.0.1.32.19971029182922.00706788@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Oct 1997 18:29:22 -0800 To: "Theodore Y. Ts'o" From: Bob Monsour Subject: Re: AH/ESP Last Call Results Cc: ipsec@tis.com In-Reply-To: <199710280618.BAA24149@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:18 AM 10/28/97 -0500, Theodore Y. Ts'o wrote: [snip] >RESOLVED [snip] >ESP Only >-------- >2. Clarify how inbound processing of encryption "Padding" field is > handled. Change... > > From: (3.4.5 Packet Decryption) > The receiver: > ...... > 2. removes/ignores any padding > ...... > > To: > The receiver: > ...... > 2. processes any padding as specified in the encryption > algorithm specification. The default action is to remove/ignore > any padding. While not a major issue, this is not quite consistent with the text in the Padding definition in section 2.4, where it says: If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. The inconsistency has to do with the "SHOULD inspect" part; the remove/ignore is not the default action. I'd suggest remove the "SHOULD INSPECT" and replace with a default of remove/ignore. Regards, -Bob ---------------------------------------------------------------- Bob Monsour Hi/fn Inc. rmonsour@hifn.com 2105 Hamilton Avenue 408-558-8065 Suite 230 408-558-8074 fax San Jose, CA 95125 ---------------------------------------------------------------- From owner-ipsec Thu Oct 30 16:24:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA11361 for ipsec-outgoing; Thu, 30 Oct 1997 16:15:08 -0500 (EST) Message-ID: <6B5344C210C7D011835C0000F8012766829A7A@EXNA01> From: "Linn, John" To: Daniel Harkins , "'Michael Bungert'" Cc: ipsec@tis.com Subject: RE: draft of the ISAKMP/Oakley draft Date: Thu, 30 Oct 1997 16:26:15 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk As a point of comparative information, IEEE P1363 and ANSI X9 groups working with elliptic curve cryptography have supported both GF(p) and GF(2^n) curves to a level parallel with one another. --jl John Linn (linn@rsa.com), writing as an individual from RSA Laboratories East, Bedford, MA, USA > ---------- > From: Michael Bungert[SMTP:Michael.Bungert@mchp.siemens.de] > Sent: Friday, October 24, 1997 8:32 PM > To: Daniel Harkins > Cc: ipsec@tis.com > Subject: Re: draft of the ISAKMP/Oakley draft > > Dan, > > thank you for your reply. I have suggested the addition of GF(p) > curves because I think that if an IETF standard recommends > elliptic curves then both types (GF(p) and GF(2^N)) should be > recommended. > Obviously, my suggestion is supported by others but I can also > agree to your proposal of having an Informational RFC describing > strong groups and removing all but one mod p group from the > ISAKMP/Oakley draft. > > Michael > From owner-ipsec Thu Oct 30 19:48:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12617 for ipsec-outgoing; Thu, 30 Oct 1997 19:46:09 -0500 (EST) Date: Thu, 30 Oct 1997 19:57:04 -0500 Message-Id: <199710310057.TAA14230@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bob Monsour Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Bob Monsour's message of Wed, 29 Oct 1997 18:29:22 -0800, <3.0.1.32.19971029182922.00706788@earthlink.net> Subject: Re: AH/ESP Last Call Results Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 29 Oct 1997 18:29:22 -0800 From: Bob Monsour While not a major issue, this is not quite consistent with the text in the Padding definition in section 2.4, where it says: If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. The inconsistency has to do with the "SHOULD inspect" part; the remove/ignore is not the default action. I'd suggest remove the "SHOULD INSPECT" and replace with a default of remove/ignore. Thanks for catching that. I propose changing the "SHOULD inspect" to "MAY inspect"; that should make the text consistent. Comments? - Ted From owner-ipsec Thu Oct 30 19:53:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12662 for ipsec-outgoing; Thu, 30 Oct 1997 19:52:09 -0500 (EST) Message-Id: <199710310102.RAA16442@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Re: AH/ESP Last Call Results In-Reply-To: Your message of "Tue, 28 Oct 1997 01:18:30 EST." <199710280618.BAA24149@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 1997 17:02:56 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I can't say I have strong feelings anymore about replay (I feel like I punched myself out actually) but I want to make one more comment. > Both AH and ESP > --------------- > 1. Sequence Number and Anti-replay Service -- 3 options have been > proposed over the past several months. (B) was chosen over (A) back > about 2 months ago. (B) is what's in the text at present. (B) is > a perhaps bit better than (C) but both are pretty similar. It seems > simplest at present to stick with (B). > > S = Sender AR = anti-replay > R = Receiver Seq# = sequence number > > Sender > Default To initiate AR Pro Con > ------- ------------------ ---------------------- ----------------------- > A) AR OFF S negotiates AR ON,- Deterministic, reli- Have to change Oakley/ > R accepts/rejects able way for S & R to ISAKMP > know AR status > - Handles manual keying > > B) AR OFF R SHOULD notify S - Handles manual keying - NOTIFY is unreliable, > that AR is ON - No changes to Oakley/ so S may continue to > ISAKMP send while R rejects > > C) AR ON R MAY notify S that - No changes to Oakley/- NOTIFY is unreliable, > AR is ON or OFF ISAKMP so S may stop sending > - Does not rely on when didn't need to > unreliable NOTIFY to - Requires special case > get S to monitor Seq# for manual keying Anti-replay protection is "the right thing". We should assume the other guy is always doing the right thing. Since it's in the receiver's best interest to do anti-replay protection I see no reason why S should assume it is not being done by R. I am unaware of any implementation that does not support replay (not counting the ones that only support the deprecated transforms) and, in fact, does not _do_ replay by default. The con for B is large I think. It is larger than the 1st con for C. Since S is not going to wrap but still has more packets to send it will initiate another negotiation to acquire new SAs. I don't see the case where S stops sending when R doesn't require it happening in the real world. This is not really a con. The 2nd con for C seems slight to me as well. Manual keying is really for bootstrapping, testing, and small scale situations. It doesn't scale to the big-I Internet. I don't really see a problem requiring a special case for this. In the event of sequence number rollover I'd rather see the worst case scenario (where the two sides are not doing the same thing) be a seemless transition to new SAs without packet loss instead of an abrupt termination of the connection. I hum loudly for C (and in C too :-). I'd also like to note that it isn't necessarily the notify that is unreliable. It is the exchange that a notify is usually passed in that is unreliable-- the Informational Exchange. There is no reason why a conformant implementation (in this case R) can't chain the notify payload to the response message which contains the SA(s) in question. It seem the logical place for it in fact. "Here's what I like from your offer. An oh, by the way, I'm not doing replay." The receipt of the notify payload can be guaranteed-- but that doesn't mean that SHOULD should become MUST. Dan. From owner-ipsec Thu Oct 30 21:04:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA13014 for ipsec-outgoing; Thu, 30 Oct 1997 21:01:10 -0500 (EST) Date: Thu, 30 Oct 1997 21:11:39 -0500 Message-Id: <199710310211.VAA14254@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Daniel Harkins Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Daniel Harkins's message of Thu, 30 Oct 1997 17:02:56 -0800, <199710310102.RAA16442@dharkins-ss20> Subject: Re: AH/ESP Last Call Results Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 30 Oct 1997 17:02:56 -0800 From: Daniel Harkins Anti-replay protection is "the right thing". We should assume the other guy is always doing the right thing..... I hum loudly for C (and in C too :-). Dan, You make a number of good points. However, given that this is after the last call period, if we're going to change the text, I would think that we need to get a lot of hums from others very quickly, and no strenuous objections. If not, we should probably leave things the way they are. At some point, we need to shoot the engineers and just ship the product.... - Ted From owner-ipsec Fri Oct 31 07:37:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15774 for ipsec-outgoing; Fri, 31 Oct 1997 07:33:47 -0500 (EST) Message-Id: <3.0.3.32.19971031065957.03546a64@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 31 Oct 1997 06:59:57 -0500 To: "Theodore Y. Ts'o" From: Matt Thomas Subject: Re: AH/ESP Last Call Results Cc: ipsec@tis.com In-Reply-To: <199710310102.RAA16442@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:02 PM 10/30/97 -0800, Daniel Harkins wrote: >> C) AR ON R MAY notify S that - No changes to Oakley/- NOTIFY is unreliable, >> AR is ON or OFF ISAKMP so S may stop sending >> - Does not rely on when didn't need to >> unreliable NOTIFY to - Requires special case >> get S to monitor Seq# for manual keying >I hum loudly for C (and in C too :-). I hum for C as well. We've exerted so much effort to add AR (because of its importance), it should be the default. -- 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 Fri Oct 31 12:22:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17582 for ipsec-outgoing; Fri, 31 Oct 1997 12:18:33 -0500 (EST) From: ajaber@certicom.com X-Lotus-FromDomain: CERTICOM To: Michael.Bungert@mchp.siemens.de cc: ipsec@tis.com Message-ID: <85256541.004E3D41.00@domino_c02.certicom.com> Date: Fri, 31 Oct 1997 09:22:26 -0400 Subject: Re: draft of the ISAKMP/Oakley draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael.Bungert@mchp.siemens.de on 10/23/97 02:35:18 PM > GF(p) curves are more favourable in the ISAKMP/Oakley context because > they are easier to implement since the necessary mod p arithmetic must > always be supported by an ISAKMP/Oakley implementation. > > For curves over GF(2^^N) an additional GF(2^^N) arithmetic must be > implemented. Furthermore, there are several patents covering > different aspects of GF(2^^N) arithmetic. > > I would appreciate a comment from you. > > Michael Elliptic Curve Cryptography should be given every consideration by the IETF. It is the technology that will provide long term Security under all application environments over the INTERNET. The need for Elliptic Curve Cryptography will become more important as more elements of the INTERNET and Intranets go Wireless. Both implementations over GF(p) and GF(2^^N) should be considered from efficiency point of view, there are very efficient Implementations over GF(2^^N) in both hardware and software. The availability of mod p arithmetic for implementation is not a convincing argument to drop GF(2^^N) and only propose GF(p). As was mentiond in Eurocrypt GF(2^^N) can be implemented using mod p too. As for the patents issues, it is imprtant to note that any existing or pending patents in GF(2^^N) or GF(p) are on Implementation only and not over the Mathematical Concepts. The mathematics is free there for any body who wants to implement. There are FREE Implementations as well as Commercial ones. The Patent issues should be undertood in this context. I believe the issues of patents over ECC should not be viewed as the issue of Patents in Legacy Algorithms like DH(now free) and RSA, in the Legacy Systems the Mathematical Concepts where patented and Royalties will be claimed when ever and implementaion is done while in ECC the case is VERY different. Regards Adel Jaber/Certicom WWW.CERTICOM.COM From owner-ipsec Fri Oct 31 17:15:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA19027 for ipsec-outgoing; Fri, 31 Oct 1997 17:03:09 -0500 (EST) Date: Fri, 31 Oct 1997 17:09:29 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199710312209.RAA19782@earth.hpc.org> To: ajaber@certicom.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199710311755.KAA01455@baskerville.CS.Arizona.EDU> Subject: Re: draft of the ISAKMP/Oakley draft Sender: owner-ipsec@ex.tis.com Precedence: bulk > Elliptic Curve Cryptography should be given every consideration by > the IETF. It is the technology that will provide long term Security > under all application environments over the INTERNET. The need for > Elliptic Curve Cryptography will become more important as more > elements > of the INTERNET and Intranets go Wireless. I don't follow the above. How does any of this motivate ECC over modular exponentiation, for example? > Both implementations over GF(p) and GF(2^^N) should be considered from > efficiency point of view, there are very efficient Implementations > over GF(2^^N) in both hardware and software. The availability of > mod p arithmetic for implementation is not a convincing argument to > drop GF(2^^N) and only propose GF(p). As was mentiond in Eurocrypt > GF(2^^N) can be implemented using mod p too. No one has proposed dropping GF[2^n], as far as I know. However, I don't believe that GF[p] has enough demonstrated merit to be included in an IETF standard. I could certainly be persuaded by running code and blazingly fast times. > As for the patents issues, it is imprtant to note that any existing > or pending patents in GF(2^^N) or GF(p) are on Implementation only > and not over the Mathematical Concepts. The mathematics is free there > for any body who wants to implement. There are FREE Implementations > as well as Commercial ones. The Patent issues should be undertood > in this context. It's my understanding, as a non-lawyer, acting on my own mathematical understanding and with advice from others, that there is a patent on an efficient software implementation of key exchange using GF[p]. The patent issue should be understood in this context, i.e. cryptographic uses of GF[p]. Because efficiency should be an important consideration for the IETF, I view the encumbrance on what may be the most efficient implementation of an algorithm to be a matter for consideration by this group. I also encourage others to investigate the patent situation and report back. > I believe the issues of patents over ECC should not be viewed as > the issue of Patents in Legacy Algorithms like DH(now free) and RSA, > in the Legacy Systems the Mathematical Concepts where patented and > Royalties will be claimed when ever and implementaion is done while > in ECC the case is VERY different. You may well be wrong. Hilarie > Regards > Adel Jaber/Certicom > WWW.CERTICOM.COM