From owner-ipsec@lists.tislabs.com Tue Jun 1 09:47:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13419; Tue, 1 Jun 1999 09:47:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29674 Tue, 1 Jun 1999 09:31:52 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEAD00@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Tue, 1 Jun 1999 09:42:47 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFAEAD00@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEAC34.A26F2080" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEAC34.A26F2080 Content-Type: text/plain; charset="iso-8859-1" Dan and Dave, Overall, I think it's a great improvement over RFC2409, and will go along way in helping reduce confusion. However, I have a number of comments on this document. There are three slightly larger concerns, and bunch of minor ones (mainly typo corrections). 1) Use of the term "protection suite" I am both concerned and confused by the use of the term "protection suite" in this document. As it turns out, this term has been re-defined from that in ISAKMP (RFC2408) to refer to only the services provided by a phase 1 SA. (See section 3.1 of draft-ietf-ipsec-ike-01.txt.) On this issue, what is the purpose of adding any new definition of these services? If that is necessary, why change the existing definition of protection suite? Why not find a term that won't result in ambiguity and confusion. To clarify the existing definition of "protection suite", see section 2.1 of RFC2408: Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole. Also see the discussion in section 4.2 of RFC2408 and the example in section 4.2.1 of RFC2408. All of these quite clearly indicate that the term "protection suite" applies to phase 2 SA establishment. While I agree that it does not necessarily preclude phase 1 SA establishment, I do not see the need to apply it to that case only, as draft-ietf-ipsec-ike-01.txt appears to do. Also, the use of the term "protection suite" is a very good way to refer to a subset of SA bundles where the SAs in the bundle are negotiated using a single SA payload. This allows them to be differentiated from SA bundles that are negotiated by the effective recursion of policy to packets that are IPSec processed. As such, I think the use of "protection suite" in this document is confusing and should be changed to align with RFC2408, or it should be removed altogether. 2) Use of the term "state" Normally, "state" implies a state machine. Obviously, there are state machines involved in SA negotiation, especially since ISAKMP packets can only be identified by context (after parsing cookies and message IDs). However, this document uses the term "state" to describe the collection of keying material values that are generated or created at SA negotiation. Normally, I wouldn't be too concerned about the use of the term state, however, it would have been nice if the states during SA negotiation had been defined. This sentiment was stated to me by the co-author of the MIBs, since he felt it would nice to put that in the MIBs. If that ever became defined, then the meaning of the term state would be overloaded and ambiguous. In any case, during development/testing of SA negotiators, one might say "what state is it in" expecting a response of "it's in the 'proposals sent' state" yet get a response of "there isn't any state yet"... Wouldn't a term like "keying material" or "calculation value" or some other term than "state" be more appropriate? 3) Acknowledged Information Exchange I'm glad to see this was added. The use of an acknowledged delete mechanism will go a long way to improve SA management. How does an implementation know when a peer supports this exchange? It seems to me that instead of giving it its own exchange number, all that's been done is the addition of a Nonce payload to the existing informational exchange. Is this a backwards compatibility attempt? For example, I send an acknowledged delete three times and get no response (since the peer ignores the nonce) and assume the peer doesn't understand, and from then on I use the unacknowledged informational exchanges? If this is the case, this should be spelled out in the document. Also, it is noted in the security considerations section that "The acknowledged Informational exchange is open to replay attacks." Is it any more susceptible than the unacknowledged informational exchange? If not, then a similar warning about the unacknowledged exchange should be added. One question that seems to be asked a lot is what SPIs are specified in the delete payload. Since IKE specifically creates two phase 2 SAs, it is appropriate that it explicitly state that the delete payload contains the SPI (and protocol) of the inbound SA of the sender, and that the receiver of a delete should delete his outbound SA and his corresponding inbound SA without sending a delete. Further, for "protection suites" as defined by RFC2408, it should be stated explicitly that the deletion of any one of the SAs in the suite means the entire suite is being deleted. Other Comments ============== (Changes I would make related to the protection suite issue described above are not added here.) 1) In section 2.4, the explanation of how cookies stay constant is better, but still confusing. Specifically, "...cookie order does not swap even if the direction of the Phase 1 SA switches." is confusing since a phase 1 SA is bi-directional once established. Perhaps "...cookie order does not swap even when the original responder initiates an exchange within the phase 1 SA." or something like that would be clearer. 2) In section 3.2, I'd like to see an explicit statement (first paragraph) that payload order within the SA payload may be changed by the responder. We saw a lot of this at interoperability workshops when it came to protection suite negotiation (IPCOMP and ESP and AH). Here, the proposal payloads that had the same proposal number were frequently re-ordered by the responder. 3) Also in section 3.2, there are comments related to automatic range selection of attributes. While I think this is a good idea under many circumstances, I'm concerned that if this isn't explicitly spelled out where it is possible, there will be problems. For example, is SHA-1 considered stronger than MD5? Some papers suggest that it is. So should I allow SHA if the peer proposes it but my local policy says MD5? What if I have hardware acceleration for MD5 but not SHA? Then the peers will start using more and more of my resources. Similar examples could be made for Blowfish versus CAST, especially when key sized can be specified. How does an implementation decide what is more secure? Bottom line: Where it's possible, if it's part of the standard, spell it out. Otherwise leave it up to local policy to allow it or not. 4) Section 4.2, paragraph 2. Should "Phase 1 exchange" on the second line of that paragraph not be "Phase 1 SA"? 5) Section 6.1, paragraph 3. Should "...and encapsulating them in the single SA payload." not be "...and encapsulating them in the single proposal payload."? Otherwise, there's a contradiction in that paragraph. 6) Section 6.2, paragraph 7 appears to be missing a word in the first line. 7) Section 6.2, paragraph 10, second line "send" should be "sent". 8) Section 6.4, paragraph 2, third line "the the" should be "to the". 9) Section 8, paragraph 4 describes identity PFS and states that the phase 1 SA should be deleted after generating the phase 2 SA. Would it not be permissible to keep the phase 1 as long as it is used for management of itself and the phase 2 SA it generated, such as sending deletes? Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 ------_=_NextPart_000_01BEAC34.A26F2080 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjENAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAEACQAqAC8AAgBBAQEggAMADgAAAM8HBgAB AAkAKgAvAAIAQQEBCYABACEAAAAxNjZBQjY5QTFCMThEMzExOEE1ODAwODBDNzk0NUU2QwANBwEE gAEALwAAAENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaXBzZWMtaWtlLTAxLnR4dCAobG9uZykALRAB DYAEAAIAAAACAAIAAQOQBgD0FAAALQAAAAsAAgABAAAAQAA5AKDmYqI0rL4BHgBwAAEAAAAvAAAA Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1pcHNlYy1pa2UtMDEudHh0IChsb25nKQAAAgFxAAEAAAAW AAAAAb6sNFQUmrZqGhgbEdOKWACAx5RebAAAHgAxQAEAAAAJAAAAVEpFTktJTlMAAAAAAwAaQAAA AAAeADBAAQAAAAkAAABUSkVOS0lOUwAAAAADABlAAAAAAAIBCRABAAAAIBAAABwQAABJIQAATFpG dUJ8ov0DAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMB AgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAun YwEwLCBEA5EAcGQdIXZlriwKogqECoBPHdByB0CAbCwgSSB0aAuAIGsgaXQnBCBhIO0JwWEFQAdw cANgHdAHgA0CMCAg4QXAUkZDMvg0MDkfMB1yA/AfECAwJm8dYBewbmcicGF5wx/AA6BoZWxwC4Aj QBMYIRrQZSAFoG5mdQMAkAIgLiBIb3dlnx7RHzIT4B3QIBFudQbQ6RKBb2YksW0hEgQgAiDjH2IE IGRvYyagISElUP0eClQj0BggHWAp0R9wCdEAIHNsaWdodGzzI4ALYHJnEoEkwSSQBKBScyIkYnUr wGgm8m3vC4AFsQIgB5EoAMALgCsBOHR5cCLgBaEYIGN0ESUhcykuHgoxKSA+VRQQJvIfcCohBJBt IF4iIMEOsC7jKpB1H9Bl9iIeCh9QYTEwBuAfcCuW7wmAHWMkxDRBYi4hMNE08e8wjzGcI5In/UEE IB/QH2D3CHAGMQhgdB8wJ/M2YxPg7wQgJsAJ8CRBLQEBC4A0QQ8DUh9hIHIDoElTQUusTVAtsCG0 ODAwdCLg/RggZhKBPdECIC4SNjEUENxydg3gB5EgwmkBADUjrSAgcDqxJKAxBgBBJVDOKAZgPwIx tDMuQPAnAXZkHvABgC0IkAAwQuBwi0GhQuBrO1AwMS4M0H0osCkeCzf1BAEKUB8wd3c8UzpBNjFw CHAuYDXEYfxkZCQSAHAjgC2AB+A7c98f0DHSNfQ1wT8mPx9ANgLXRjQtgD9xcwrAeUXyI4D/E9Ej MCoiJKAOwAQALvAjMfdIfDbOSjBXS8EtMAVAO5HXNFE2VDxDdwIgJwVAGCDtMhBsPHMzUGIqwDIh QFH/NIclIijrLnErMQaQNVRMr7tI9Da/Ih8wFBBBiDJCNFU9RToeCiBaEFAxeFP9MiI6EMBOD0ZS ICAqsFUgfzXmQaEIcS5AWbc/JzxDbe8lAAVAJsAdYHALUAiQNSP+dlRRCGAEIF2mW3MoUAbw8nMl UCBGBbBZtw7AM1D/C1BF4UBxW54AwEvRLxFc9fxERQXwCfAFAC5QMcM8kns9EGYQUB31WhEdckOw eZE0QU1ENWblQUg44f8ioTX1Vng5ER1RZKZfpFm3/nQgUjRCIAIAkCMwY6A1oD9IsWJhKaBFc0r4 OuFjYf81sl2vPycjoUegASApwSExv2FPBCBvsCOxJjIyEGIq8P9sKAuANmEA0C7zIiRUs3IBPy7g J6FHYWtcHWEHQHl6/zREWbce0QaQYFJtQ0YQBvD2ZS9baaBzIuBXojYiR6CfBPAlACUSI5JBpjQu FEB/WKh2CGNkfQ1Ye2mKNcFx91xDVDAgYHIrAU/BDeBs8f88NDYvNzlgFDpBIuBAlBRB71tgB5AB kVzhaCiDHgpPMP8DECSgMzEJwjw1BUAoQAeR/09ySwYDEGGyBZAKQAEAQIn/hywfMihAT2N75i2A NEE90f9gEiOBOUEi4DxDb7A1wi4B/yIhKCFCr0O3YAKC0YYzKED/es858jWfhJ83siACHtEjgN8i 0ARwI1M92mtCYhQRJvL7hwEsgWRjoAQgRhApwpWi/zzQavOVoppEKfMtgCLQLvC/bPMlAUfCbYaH AQqweRew/0eAJVBucx8BJYBGczwhIuD/X+Fx550UO/OaGTxDnI01Rf12lGkmQS7BCHB8w03iBvD3 DeCYcwqwY0OwJ5Gih2cg/QZgYz+iSyIJgJPMYSEa0P5oHziU+ZY/N89GQyTFR8P3HZCHoAhgbCxh JKFMA470/yqxA6AD8DOhPUUfMAWxOTG/rigYIARgHdA0UVFgbytg9ZWhci9bMjA/qsCHQTJN/k4F sADAHxBLgbTVIJKGAz9rQbTyZQET0DuhJVBPYn8/UGEBkMKykinkt8tq8nb/BvCx8iOhhwGcxiUh HzAHkP2TEGMHMSsBbZEkkTzFpkb/c7I+k1/hP/GhAXnTNUEkwX0OsyiRURKBCrGdgwWgbz5rt2Md gQeBS1BMMUlE/y8xJWisPDTxRnS0ipNjB5D/BQFf4ZWiF5FjoDG0JwFoYf8kEgDAleEHMWCxCkGi aStg/y2AHvBtAgWxBQBs5QVAu7z/L1u2CB9QUMCuUVDixsKYEP8zygbgOdCU75XytOMfMHqA/yWV OTHOAyYUOvMDACSRBpD/PtS08ighCHEjMbu8JhGucv87ETt1nwUUEKEBIRMjYGEh37TyjvMHgDU2 BaAtb8AfcOMtQpWETUlCLBG9ZJWx/z4gUWLSVtNzhlLP0zxk2mb/JVBKViWib4PY8Tt1lNObtP8H gABwJBLQj9JlX+EhYp7C/zRFUcRhAd4xHVJL0UCxHzCv1KUBAB3QF7BwIRIv1GH/VTOZ5JzGBbAs ES1xLQEq0fsqkCNxIkYTt8RFcjxyq+D/DsC80VUzICBRIS5gAICqhHsf05ulJyDBRwEHQNdUJ/+3 tKvgaIAFQLJx6w65ZAQAz1DiR/K3xO5BIi7xUIgb/84WUAUqsEOwqsDIHavgBbH6Im+wbChgC2Ax w8kT9JP/e7DY8TORPjJQNQOgtqZf4X8EYCnSYCDs4QchTvEeCjOts7BBpmAtMHdjoGSvAs/kgAIQ tiExw0V4S/Qye/4nlhBtwNYRPdF75CgR2BL/R4HW5NAnHUL6ag8QY6Bk4v8FkEwBBACWECKHKyAj Jj3R/yCljIIIIcLBh88lcYok/9H/tyIhA9Wk+nKasmsikxASgf8yEGAgF8FGclyRDsBL9Eox/Y4j bYYz2PE8RVUgIGDKkb0nEGekkCQS6gInkndrIP8JBiaFIiEioTxCH/HWROgy/0ZlR4JI1iAgtgC9 gp6Vj8S/VNm9cPtHyOEJBi9bSQiV/SAgYqZRI2AbMK0iILC8QbdR4CqwUjJ0leAgsHRKMP9ikWNI H1DXcTRS//8BAipE39eiwiTugi0w6ygovWRGk/8H4q+R+GFGdC0wK8GzsOOT/0WxCmMcZYoyUOKa Uc9Ah0H/T9AiJDv1OxFYMamglTLQA/8EEPpqEk9MA0ogMnuVgm6U/8bz5QMn864ovMHHUcqRz9H/ m6U4Z5Pf6fOKY7tUXWplRN8f4bxDYSMxwzxDIv8iGJv/+ykS+UZS5hDgQj3if3Do4f8WkaZRYlCr 4BRxOTHksvhT/07AfIAxUBYBbdH3UyH/Iw//CRhCcE9x4AVtcuhwVEECwf/PUEezz7g0rAy3rij+ tERs34Iy5pIthgnXeBJzQ7BP4v+fkEZDRhNnYBRxucO80nnTlyhmAOSel1O9dEtFQHb/9PGLUcrk pqFQwIZ5deEqhP/4qYmn6nGlwewAvTK304PH+0GcwENhCuGbFEAAwMFP0f9h1rOwlXW9cM+xT9GH AV037x/SdfaD5aTRZaSR2hMQQP8A1a4lANUIws/BTFfjkgjC/XNgcus0fGASE0xXr9LPwu8YEp2U ANSy20bUsLKSqYD/+0Gqz7dwhbGREd+kYIKwJ/+w69hVRzlITA/W8IEO0pV1/5tpZLXgwcUEoPIz E2TSl2HfeBDlhADyO/32s0P2YMSCmnNnlD1je4gaKEMkNP/N1rgR82GJcPVBjuRqHF/3/x5g33LG hM+D0vGcgz9B/rPT21GJcC4piBoxs7Dkgft9RoCANJTURzIEAQ/G0bH/wbeM0SwkICE/U3gQFqEN kb+cEOlSAfKtR0JxQ0ksdKf/cy90P3lg8ULBxLChH+EFk/d5B44DFVBw3sIGAZWEfGD3pNEPxpWi UIwod5DsALhA/7dwMiBktK0bvWQHsYwoYGJ8aS14pxLxEHOHN9biUP/PQIwgkfByr4EfdM9133bv /3fyB2OVosqwr5C9cBLxUoX/HKLg4J0DwiKAFzAHr9Kbpf+MGHrm9iWpwgKw80PdM+JXHmPHYJyB ss9sCTMuMv2pgSf7AIvk/cQYYUc2t7T9xIMo37AgAcEywsDKUHyw/7Ow3TMQxoOUiUmeaLgRvyOv rsajxYbHw0BXJ4FhBYD/PxS0E59C3WLFYTDBylAWJf3iUHIyANnwf/AHVNJB30OXphJnftVKKKdQ Q0++Ac3jkkVKkOODQUjDMu/R/2zk7NYQtqal1gLT899Sn9fvDUSvwO/SIMBlPRHEoL0x/RnwLYOT ll+NbfoiKjG7cv+Ou7loFbFiw2Zq2cH2YLxB/mNmYDrEAOHHhxaRxqHZ0L96wZeQFLAz0SGQiWJr JYf7EECdAG+7Yd+QEEAfwwPi/ywhX8Ao8SAS2zBFYf0izwj/3TQldx+CRzonuQdh7+I/U//tAb1g M8G5RgHjPoFXETPBDwoAVWwXOkXBU0hBLf99ECxGyzER4OzgE3H24fdi6E1ENQmAU/ZiwUCZgfnt UXVnJGHdFj9SQnH9wf8nFCGQQ7EFcbhR07YH06IU9wXB0kFwgm3o8AKA9PG0cf9HYbLh6OBlgLpD rICxRCGQ/9LTfMAVcBVRLjLbMMdgLLT/VrO6QXBzd1K4UQmALhGJlf8H4f5RAfIgEQhw0DHIQ/hj /+Oh+FMLYb+x6zHkMK9wesH/8YpCkDgUF2UVkoylZiDfkP1Ws0K9cUOAOxD1oB/xe9DxYoBBU1SP YOtBQKFDs/cHY/OhfCF6WMH08BhwJ3T/QLSfEQV/BoffkENgy1HpI+9FwTL0K8L5TEIq8KoR8zH9 39A6rHGz5A5BtIh4MdU0/8ZSTOYgIhVh2uEnstvSs4H/3jBiM5QwG6GNIcIR2+EIMP8xAr/rqcK9 Y9hi3wB3UaXL6jQd4FMtRTSPQpJXbKH7fSC81CJ5tjAG9JErV1LB/9RjeTSTI95Wd1I+gd93UaCK IvlbNd1INi4x3hr/jzDe9/FRHgIYIPTwf/D1M/8CoTlRsGArRmCxM9GU6DIh/+L250/oX+lkn94y IAmA2Of/tQUOQRBAScLDMA+gbFRBI9viKqXLNuUK3gs3ReKNMf8+NjgQtKFUs5oxQQeR9NRyzaXL N/L/3lYxMNfh4SneIhgSWCA7GPrydOsAZFr+OOUKbNHeOSaT9kH6pDlS7zlR+0sRRPxcOd1IWYHe OD40aMcyYVBgX6EWYVBG/lMd81qDoNWJvDsJYPUQMP5mmUEawZzgwzLsNES5l4H/OzNHAeL1mYH1 gzPDPmBmQP8xUImrWEE/MFSyMmNFwSGx/yChFzGvAfmAkYRuAdZQqvF/XNKhZETIMnIIxS7A1+F1 3zAgWDJUZlBkJIxUGkBkWuYtFaAUVyBKGCBuoC0B5xbvF0MUsWVTUKB3wGKQTnKG8MM0ZLR0ahaE QH+HkLqwPUAxUIMRsGAXR2hBcCBwOi8vdxxQLhMaimS1NjGmkTU5OQQtMx3AMCB4NDPGMAPAF0xG YXjUsB27CjdktH0hgAMA3j+vbwAACwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAWA CCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADw EwAAHgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAMAAoAIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAG AAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAA HgAIgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACYAIIAYAAAAAAMAAAAAA AABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEA AAAAAAAACwALgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAAyACyAGAAAAAADAAAAAAAAA RgAAAAAFiAAAAAAAAAsAQYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwDxPwkEAAADAP0/ 5AQAAAMAJgAAAAAAAwA2AAAAAAADAIAQ/////wIBRwABAAAAOwAAAGM9VVM7YT0gO3A9VGltZVN0 ZXAgQ29ycG9yYTtsPUVYQ0hBTkdFLTk5MDYwMTEzNDI0N1otMzY3MzQAAB4AOEABAAAACQAAAFRK RU5LSU5TAAAAAB4AOUABAAAACQAAAFRKRU5LSU5TAAAAAEAABzAA52KiNKy+AUAACDCAIG+iNKy+ AR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAC8AAABDb21tZW50cyBvbiBkcmFmdC1pZXRmLWlwc2Vj LWlrZS0wMS50eHQgKGxvbmcpAAAeADUQAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgw NUZCQkFEREZBRUFEMDBAZXhjaGFuZ2U+AAAACwApAAAAAAALACMAAAAAAAMABhCxvsS6AwAHECQY AAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREFOQU5EREFWRSxPVkVSQUxMLElUSElOS0lU U0FHUkVBVElNUFJPVkVNRU5UT1ZFUlJGQzI0MDksQU5EV0lMTEdPQUxPTkdXQVlJTkhFTFBJTkdS RURVQ0VDT05GVVNJT05ITwAAAAACAX8AAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgw NUZCQkFEREZBRUFEMDBAZXhjaGFuZ2U+AAAA47E= ------_=_NextPart_000_01BEAC34.A26F2080-- From owner-ipsec@lists.tislabs.com Tue Jun 1 11:29:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16818; Tue, 1 Jun 1999 11:29:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00222 Tue, 1 Jun 1999 12:00:55 -0400 (EDT) Date: Tue, 1 Jun 1999 19:09:44 +0300 (EET DST) Message-Id: <199906011609.TAA32477@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: Comments on draft-ietf-ipsec-ike-01.txt (long) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFAEAD00@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFAEAD00@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3) Acknowledged Information Exchange > > I'm glad to see this was added. The use of an acknowledged delete mechanism > will go a long way to improve SA management. > > How does an implementation know when a peer supports this exchange? It seems > to me that instead of giving it its own exchange number, all that's been > done is the addition of a Nonce payload to the existing informational > exchange. It has its own exchange number: ---------------------------------------------------------------------- Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Acknowledged Informational 34 ---------------------------------------------------------------------- So if other end returns invalid exchange type, then it doesn't support it... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 1 11:31:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16841; Tue, 1 Jun 1999 11:31:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00256 Tue, 1 Jun 1999 12:06:18 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEAE24@exchange> From: Tim Jenkins To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Tue, 1 Jun 1999 12:17:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oops; missed that. But that brings up another question: Would it not be appropriate for this new exchange to have been defined as part of ISAKMP, and therefore be available to other protocols that use ISAKMP? (Yes, I know this document is not son-of-isakmp, it's son-of-ike...) --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: June 1, 1999 12:10 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > > 3) Acknowledged Information Exchange > > > > I'm glad to see this was added. The use of an acknowledged > delete mechanism > > will go a long way to improve SA management. > > > > How does an implementation know when a peer supports this > exchange? It seems > > to me that instead of giving it its own exchange number, > all that's been > > done is the addition of a Nonce payload to the existing > informational > > exchange. > > It has its own exchange number: > ---------------------------------------------------------------------- > Additional Exchanges Defined-- XCHG values > > Quick Mode 32 > New Group Mode 33 > Acknowledged Informational 34 > ---------------------------------------------------------------------- > > So if other end returns invalid exchange type, then it doesn't support > it... > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Tue Jun 1 16:40:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26673; Tue, 1 Jun 1999 16:40:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01369 Tue, 1 Jun 1999 17:48:38 -0400 (EDT) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <85256783.00789284.00@d54mta05.raleigh.ibm.com> Date: Tue, 1 Jun 1999 17:58:16 -0400 Subject: More comments on draft-ietf-ipsec-ike-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here are a few comments that I found when I read through the subject draft: 1. Reference "HC98" is not listed in the section 11. I assume that this should be a reference to RFC 2409. 2. (Grammar & style) Section 3.2 lists 3 exchanges (Main mode, aggressive mode, and quick mode). Then it obliquely refers to 3 more, which are not listed. I'd prefer to see an explicit listing of the other three: New Group, Acknowledged Informational, and Unacknowledged Informational. 3. (Grammar & Style) Section 2.5 mentions 4 "distinct methods of authentication", but only explicitly names two of them. Again, I'd prefer to see all methods listed. From perusing Appendix A, I beliive that there are actually 7 distinct methods: 1) preshared key, 2) DSS Signature, 3) RSA Signature, 4) Encryption with RSA, 5) Revised Encryption with RSA, 6) Encryption with El-Gamal, and 7) Revised Encryption with El-Gamal. 4. I do not recall any discussion on the mailing list about adding the two newly defined authentication methods that are based on use of El-Gamal, which is listed as a "SHOULD" in the section 3.1. What was the rationale for doing so? And is there a reference to El-Gamal or a comparison of its merits relative to RSA encryption? 5. In the formulas in Section 4.1 for I-digest and R-digest,the identity fields are shown as ID_i1 and ID_r1. But in RFC 2409, the equivalent terms were IDIDii_b and IDir_b, indicating that the ISAKMP generic header was not included. Hence, I believe that the draft should have used notiation IDi1_b and IDr1_b. Was it the intent in the new draft to explicitly inlcude the ISAKMP generic header in these digests? 5. I would prefer to see a slightly expanded definiton for SKEYID_e: "the keying material used to protect the confidentiality of IKE messages" makes it a little clearer that this keying material is used just for IKE messages and not for user traffic. 6. In section 6 (Quick Mode), the formula for the HASH( ) values uses the RFC 2409 notation (IDci and IDcr). This should be changed to IDi2 and IDr2. 7. (Nomenclature) Since they are described in the body of 6.4, 6.4.1, and 6.4.2 as "informational exchanges", it would be clearer to change the heading of section 6 to read "Informational Exchanges" rather than its current wording of "Nofitication Exchanges". 8. Appendix A lists Additional XCHG values for Quick Mode, New Group Mode, and Acknowledged Informational. Shouldn't there also be a value to denote Unacknowledged Informational? 9. I agree with Tim Jenkins' previously posted comment relative to section 3.2, "attributes with negotiable ranges". The current text, as written, is too vague to be of use, and is really delivng into policy issues. I am perhaps a little more rigid than Tim--I think that the last two paragraphs of section 3.2 should be deleted in their entirety, as it is not in the scope of the IKE spec to define acceptable policy. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development, Dept JEUA,, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-441-7288, External 1-919-543-7288 From owner-ipsec@lists.tislabs.com Tue Jun 1 19:07:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA03760; Tue, 1 Jun 1999 19:07:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01539 Tue, 1 Jun 1999 19:59:28 -0400 (EDT) Message-Id: <199906020007.RAA24642@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Tue, 01 Jun 1999 09:42:47 EDT." <319A1C5F94C8D11192DE00805FBBADDFAEAD00@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24639.928282071.1@network-alchemy.com> Date: Tue, 01 Jun 1999 17:07:51 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 01 Jun 1999 09:42:47 EDT you wrote > > 1) Use of the term "protection suite" > > I am both concerned and confused by the use of the term "protection suite" > in this document. As it turns out, this term has been re-defined from that > in ISAKMP (RFC2408) to refer to only the services provided by a phase 1 SA. > (See section 3.1 of draft-ietf-ipsec-ike-01.txt.) The abstract of this draft explicitly says that where there are conflicts it will be supreme. > On this issue, what is the purpose of adding any new definition of these > services? If that is necessary, why change the existing definition of > protection suite? Why not find a term that won't result in ambiguity and > confusion. > > To clarify the existing definition of "protection suite", see section 2.1 of > RFC2408: > > Protection Suite: A protection suite is a list of the security > services that must be applied by various security protocols. For > example, a protection suite may consist of DES encryption in IP ESP, > and keyed MD5 in IP AH. All of the protections in a suite must be > treated as a single unit. This is necessary because security > services in different security protocols can have subtle > interactions, and the effects of a suite must be analyzed and > verified as a whole. I was under the impression that this was confusing people and hence decided to spell out what the term means to IKE. If DES in ESP is a protection suite what about the lifetime of the ESP offer? Is that part of the protection suite as defined by RFC2408? That's not explicitly spelled out and people asked me about it. I happen to agree with them. That text doesn't really capture the meaning of the term and is open to interpretation. > Also see the discussion in section 4.2 of RFC2408 and the example in section > 4.2.1 of RFC2408. All of these quite clearly indicate that the term > "protection suite" applies to phase 2 SA establishment. > > While I agree that it does not necessarily preclude phase 1 SA > establishment, I do not see the need to apply it to that case only, as > draft-ietf-ipsec-ike-01.txt appears to do. The DOI defines what IKE negotiates in phase 2. Would it be better if I called a protection suite "an collection of attributes that are negotiated as a single unit"? And then said that during phase one the components of such a suite is and leave it up to a DOI to define the term if it so chooses? > Also, the use of the term "protection suite" is a very good way to refer to > a subset of SA bundles where the SAs in the bundle are negotiated using a > single SA payload. This allows them to be differentiated from SA bundles > that are negotiated by the effective recursion of policy to packets that are > IPSec processed. This is a slippery slope. If I now state that a protection suite is a subset of a bundle of SAs then what sort of subset? 3 offers out of the 5 in the bundle? Is that a protection suite? And I don't think that's the correct meaning. Even if all 3 of the five were ANDed together, it's still 3 protection suites. Perhaps you can come up with another term to describe a subset of a bundle. > As such, I think the use of "protection suite" in this document is confusing > and should be changed to align with RFC2408, or it should be removed > altogether. RFC2408 is confusing and I was asked about it many times. I'm addressing that issue. At the last bakeoff someone was passing a message ID in the SPI field of an notify message. This was justified by noting that nothing expressly prohibits such behavior. When things reach this state I think we've gotta spell everything out in gory detail and RFC2408 doesn't to the job. Does my suggested modification come closer to what you think it should say? > 2) Use of the term "state" > > Normally, "state" implies a state machine. Obviously, there are state > machines involved in SA negotiation, especially since ISAKMP packets can > only be identified by context (after parsing cookies and message IDs). > However, this document uses the term "state" to describe the collection of > keying material values that are generated or created at SA negotiation. It's "state" as in "IKE is a state-ful protocol as opposed to SKIP which is a state-less protocol" (or so they said). And it's more than just keying material. > 3) Acknowledged Information Exchange > > I'm glad to see this was added. The use of an acknowledged delete mechanism > will go a long way to improve SA management. > > How does an implementation know when a peer supports this exchange? It seems > to me that instead of giving it its own exchange number, all that's been > done is the addition of a Nonce payload to the existing informational > exchange. > > Is this a backwards compatibility attempt? For example, I send an > acknowledged delete three times and get no response (since the peer ignores > the nonce) and assume the peer doesn't understand, and from then on I use > the unacknowledged informational exchanges? > > If this is the case, this should be spelled out in the document. I think Kivinen answered this, right? > Also, it is noted in the security considerations section that "The > acknowledged Informational exchange is open to replay attacks." Is it any > more susceptible than the unacknowledged informational exchange? If not, > then a similar warning about the unacknowledged exchange should be added. OK, good point. > One question that seems to be asked a lot is what SPIs are specified in the > delete payload. Since IKE specifically creates two phase 2 SAs, it is > appropriate that it explicitly state that the delete payload contains the > SPI (and protocol) of the inbound SA of the sender, and that the receiver of > a delete should delete his outbound SA and his corresponding inbound SA > without sending a delete. RFC2408 says it's the "sending entity's SPI". Is that not clear? > Further, for "protection suites" as defined by RFC2408, it should be stated > explicitly that the deletion of any one of the SAs in the suite means the > entire suite is being deleted. > > Other Comments > ============== > > (Changes I would make related to the protection suite issue described above > are not added here.) > > 1) In section 2.4, the explanation of how cookies stay constant is better, > but still confusing. Specifically, > "...cookie order does > not swap even if the direction of the Phase 1 SA switches." > is confusing since a phase 1 SA is bi-directional once established. Perhaps > "...cookie order does > not swap even when the original responder initiates an > exchange within the phase 1 SA." > or something like that would be clearer. OK, > 2) In section 3.2, I'd like to see an explicit statement (first paragraph) > that payload order within the SA payload may be changed by the responder. We > saw a lot of this at interoperability workshops when it came to protection > suite negotiation (IPCOMP and ESP and AH). Here, the proposal payloads that > had the same proposal number were frequently re-ordered by the responder. OK, you want that in ISAKMP or in IKE? > 3) Also in section 3.2, there are comments related to automatic range > selection of attributes. While I think this is a good idea under many > circumstances, I'm concerned that if this isn't explicitly spelled out where > it is possible, there will be problems. > > For example, is SHA-1 considered stronger than MD5? Some papers suggest that > it is. So should I allow SHA if the peer proposes it but my local policy > says MD5? What if I have hardware acceleration for MD5 but not SHA? Then the > peers will start using more and more of my resources. > > Similar examples could be made for Blowfish versus CAST, especially when key > sized can be specified. How does an implementation decide what is more > secure? > > Bottom line: Where it's possible, if it's part of the standard, spell it > out. Otherwise leave it up to local policy to allow it or not. I was spelling it out. I'm not even going to touch the issue of whether CAST is stronger-than, weaker-than, or equal-to blowfish. This text deals with attributes whose values are variable not with different attributes. It specifically says this in the text. Is blowfish with a 80 bit key "weaker than" blowfish with a 448 bit key? Is group 1 "weaker than" group 5? Or to put it another way, is there any reason to refuse to do blowfish with a 448 bit key if you would've proposed 80 had you initiated? I'm attempting to codify the behavior of certain implementations. Some people will not accept group 1 if they have group 2 configured but will happily accept group 5. That seems to be correct behavior. Similarly for variable length ciphers. If you're configured for 128 bit blowfish and someone asks you if you want to do 448 bit blowfish do you refuse? If so why? If not then where in the RFCs does it say that you can do this? > 4) Section 4.2, paragraph 2. Should "Phase 1 exchange" on the second line of > that paragraph not be "Phase 1 SA"? > > 5) Section 6.1, paragraph 3. Should "...and encapsulating them in the single > SA payload." not be "...and encapsulating them in the single proposal > payload."? Otherwise, there's a contradiction in that paragraph. Yes, thanks for catching that. > 6) Section 6.2, paragraph 7 appears to be missing a word in the first line. > > 7) Section 6.2, paragraph 10, second line "send" should be "sent". > > 8) Section 6.4, paragraph 2, third line "the the" should be "to the". > > 9) Section 8, paragraph 4 describes identity PFS and states that the phase 1 > SA should be deleted after generating the phase 2 SA. Would it not be > permissible to keep the phase 1 as long as it is used for management of > itself and the phase 2 SA it generated, such as sending deletes? Good point. What do other people think? Just prevent it from generating any other IPSec SAs or should it be deleted immediately? Dan. From owner-ipsec@lists.tislabs.com Tue Jun 1 19:21:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA07079; Tue, 1 Jun 1999 19:21:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01622 Tue, 1 Jun 1999 20:37:44 -0400 (EDT) Message-Id: <199906020046.RAA24704@potassium.network-alchemy.com> To: kunzinge@us.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: More comments on draft-ietf-ipsec-ike-00.txt In-reply-to: Your message of "Tue, 01 Jun 1999 17:58:16 EDT." <85256783.00789284.00@d54mta05.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24701.928284367.1@network-alchemy.com> Date: Tue, 01 Jun 1999 17:46:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 01 Jun 1999 17:58:16 EDT you wrote > > Here are a few comments that I found when I read through the subject draft: > > 1. Reference "HC98" is not listed in the section 11. I assume that this shou >ld > be a reference to RFC 2409. Right! Thanks for spotting that. Forgot my own RFC. > 2. (Grammar & style) Section 3.2 lists 3 exchanges (Main mode, aggressive mod >e, > and quick mode). Then it obliquely refers to 3 more, which are not listed. >I'd > prefer to see an explicit listing of the other three: New Group, Acknowledged > Informational, and Unacknowledged Informational. 3.2 describes attribute negotiation. I don't see what you're referring to. > 3. (Grammar & Style) Section 2.5 mentions 4 "distinct methods of > authentication", but only explicitly names two of them. Again, I'd prefer to > see all methods listed. From perusing Appendix A, I beliive that there are > actually 7 distinct methods: 1) preshared key, 2) DSS Signature, 3) RSA > Signature, 4) Encryption with RSA, 5) Revised Encryption with RSA, 6) Encrypt >ion > with El-Gamal, and 7) Revised Encryption with El-Gamal. Only 2? Section 2.5 says: There are four distinct methods of authentication in IKE: authentication with pre-shared keys, authentication with digital signatures, and two methods of authentication using public key encryption. Preshared keys is one, digital signatures is one, and two methods of public key encryption. That's 4. It mentions 4 because that's what's described in section 6.1. 6.1.1 is Main Mode and there are 4 distinct methods of authentication (6.1.1.1 through 6.1.1.4). Similarly for 6.1.2. > 4. I do not recall any discussion on the mailing list about adding the two ne >wly > defined authentication methods that are based on use of El-Gamal, which is > listed as a "SHOULD" in the section 3.1. What was the rationale for doing so? > And is there a reference to El-Gamal or a comparison of its merits relative t >o > RSA encryption? It came up during a thread with John Gilmore. Patent issues prevented a free implementation of IPSec/IKE from using RSA and El-Gamal is a fine way to address that need. Also, PGP 5.0 has El-Gamal keys and since it's possible to pass a PGP "certificate" it seems to make sense to have a well-defined way to do this. Do you have a problem with El-Gamal? > 5. In the formulas in Section 4.1 for I-digest and R-digest,the identity fiel >ds > are shown as ID_i1 and ID_r1. But in RFC 2409, the equivalent terms were > IDIDii_b and IDir_b, indicating that the ISAKMP generic header was not includ >ed. > Hence, I believe that the draft should have used notiation IDi1_b and IDr1_b. > Was it the intent in the new draft to explicitly inlcude the ISAKMP generic > header in these digests? That was an oversight on my part which was pointed out by Shawn Mamros. You should grab the -01.txt version of the draft. > 5. I would prefer to see a slightly expanded definiton for SKEYID_e: "the key >ing > material used to protect the confidentiality of IKE messages" makes it a > little clearer that this keying material is used just for IKE messages and no >t > for user traffic. OK, I'll add "of IKE messages." > 6. In section 6 (Quick Mode), the formula for the HASH( ) values uses the RFC > 2409 notation (IDci and IDcr). This should be changed to IDi2 and IDr2. Oops. I'll fix that. Thanks. > 7. (Nomenclature) Since they are described in the body of 6.4, 6.4.1, and 6. >4.2 > as "informational exchanges", it would be clearer to change the heading of > section 6 to read "Informational Exchanges" rather than its current wording o >f > "Nofitication Exchanges". OK. > 8. Appendix A lists Additional XCHG values for Quick Mode, New Group Mode, an >d > Acknowledged Informational. Shouldn't there also be a value to denote > Unacknowledged Informational? It's the ISAKMP Informational exchange. Perhaps that should be mentioned in 6.4.1. And I should probably mention in 6.1.2 that Aggressive Mode uses the ISAKMP Aggressive Exchange type. > 9. I agree with Tim Jenkins' previously posted comment relative to section 3. >2, > "attributes with negotiable ranges". The current text, as written, is too va >gue > to be of use, and is really delivng into policy issues. I am perhaps a littl >e > more rigid than Tim--I think that the last two paragraphs of section 3.2 shou >ld > be deleted in their entirety, as it is not in the scope of the IKE spec to > define acceptable policy. It's not saying what acceptable policy is, just what acceptable negotiation can be. There were a few people who just assumed that if Alice could success- fully initiate to Bob that therefore Bob must also be able to successfully initiate to Alice and if that didn't happen Alice was at fault. I asked Tim so I'll ask you too: if you're configured to offer blowfish with a 128 bit key and someone offers you blowfish with a 256 bit key what do you do? What do you do when you're configured to offer group 2 and someone offers you group 5? Also, if you feel that this should be removed in its entirety then how do you feel about section 4.5.4 of RFC2407? Is that an unacceptable foray into defining what acceptable policy can be? Dan. From owner-ipsec@lists.tislabs.com Wed Jun 2 08:58:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20684; Wed, 2 Jun 1999 08:58:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03374 Wed, 2 Jun 1999 09:24:16 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB15C@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Protection Suites in ... (was RE: Comments on draft-ietf-ipsec-ike-01.txt (long) ) Date: Wed, 2 Jun 1999 09:35:01 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFAEB15C@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEACFC.B728CD50" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEACFC.B728CD50 Content-Type: text/plain; charset="iso-8859-1" Still long, but only on the protection suite issue. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 1, 1999 8:08 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > On Tue, 01 Jun 1999 09:42:47 EDT you wrote > > > > 1) Use of the term "protection suite" > > > > I am both concerned and confused by the use of the term > "protection suite" > > in this document. As it turns out, this term has been > re-defined from that > > in ISAKMP (RFC2408) to refer to only the services provided > by a phase 1 SA. > > (See section 3.1 of draft-ietf-ipsec-ike-01.txt.) > > The abstract of this draft explicitly says that where there > are conflicts > it will be supreme. Even over RFFC2408? We really need that document to be updated then. That's not my point anyway. My point was that it appears that "protection suite" is being re-defined in a completely different way than RFC2408, and I don't see why. > > > On this issue, what is the purpose of adding any new > definition of these > > services? If that is necessary, why change the existing > definition of > > protection suite? Why not find a term that won't result in > ambiguity and > > confusion. > > (Above are my original questions; I didn't see a response to them.) I think my understanding of your position would be clearer if the above questions were answered. I'll expand them: 1) What is the purposes of defining any new term for the set of proposals and attributes offered for phase 1? 2) If question 1's answer is valid, why would the term "protection suite" be chosen when it quite clearly (IMHO) already has a very different and clear definition? (I realize that it's not clear to others.) > > To clarify the existing definition of "protection suite", > see section 2.1 of > > RFC2408: > > > > Protection Suite: A protection suite is a list of the security > > services that must be applied by various security protocols. For > > example, a protection suite may consist of DES > encryption in IP ESP, > > and keyed MD5 in IP AH. All of the protections in a suite must be > > treated as a single unit. This is necessary because security > > services in different security protocols can have subtle > > interactions, and the effects of a suite must be analyzed and > > verified as a whole. > > I was under the impression that this was confusing people and > hence decided > to spell out what the term means to IKE. If DES in ESP is a protection > suite what about the lifetime of the ESP offer? Is that part > of the protection > suite as defined by RFC2408? That's not explicitly spelled > out and people > asked me about it. I happen to agree with them. That text > doesn't really > capture the meaning of the term and is open to interpretation. If clarity of the existing definition is the problem, then that is what should be done. The existing changes will create more problems by re-defining it completely differently. Here's my definition of a protection suite: "A protection suite is an SA bundle in which the SAs in the bundle are negotiated using the same SA payload in the same quick mode." That definition is entirely consistent with RFC2408. RFC2408 also says that the individual SAs in a suite must be treated as a unit. This means that when one SA in a suite expires, all SAs must be expired. It also should mean, and this was demonstrated at interoperability workshops, that the encapsulation applies to the SAs as a group, or stated alternatively, to the suite as a whole. (In other words, there are no extra IP headers added between the headers added by the individual SAs in the protection suite.) > > > Also see the discussion in section 4.2 of RFC2408 and the > example in section > > 4.2.1 of RFC2408. All of these quite clearly indicate that the term > > "protection suite" applies to phase 2 SA establishment. > > > > While I agree that it does not necessarily preclude phase 1 SA > > establishment, I do not see the need to apply it to that > case only, as > > draft-ietf-ipsec-ike-01.txt appears to do. > > The DOI defines what IKE negotiates in phase 2. Would it be > better if I > called a protection suite "an collection of attributes that > are negotiated > as a single unit"? And then said that during phase one the > components of > such a suite is and leave it up to a DOI to > define the term > if it so chooses? That might be preferable. But to me (phase 1 aside), that's what RFC2408 has already done. And I still don't know why you want to apply the term to phase 1 anyway. > > > Also, the use of the term "protection suite" is a very good > way to refer to > > a subset of SA bundles where the SAs in the bundle are > negotiated using a > > single SA payload. This allows them to be differentiated > from SA bundles > > that are negotiated by the effective recursion of policy to > packets that are > > IPSec processed. > > This is a slippery slope. If I now state that a protection suite is a > subset of a bundle of SAs then what sort of subset? 3 offers > out of the > 5 in the bundle? Is that a protection suite? And I don't > think that's the > correct meaning. Even if all 3 of the five were ANDed > together, it's still > 3 protection suites. Perhaps you can come up with another > term to describe > a subset of a bundle. The protection suite is a result of the negotiation. If I propose (IPCOMP and ESP and AH) or (ESP or AH) to you, I'm offering you a choice of two protection suites. Hopefully, you'll respond with 1 of those, and the result will be that we create between us a single protection suite. That protection suite will contain either one or two SAs. What's slippery about this? > > > As such, I think the use of "protection suite" in this > document is confusing > > and should be changed to align with RFC2408, or it should be removed > > altogether. > > RFC2408 is confusing and I was asked about it many times. I'm > addressing > that issue. I've no problems with that: only that I don't think you're clarifying, but changing. > > At the last bakeoff someone was passing a message ID in the > SPI field of > an notify message. This was justified by noting that nothing > expressly > prohibits such behavior. When things reach this state I think > we've gotta > spell everything out in gory detail and RFC2408 doesn't to the job. I agree. Is there someone working on a next generation ISAKMP document? > > Does my suggested modification come closer to what you think > it should say? > I don't know. I don't think we're really that close in what we think a protection suite is. I think it's an SA bundle where the SAs in the bundle were negotiated using the same SA payload. I think that you think it's a collection of proposals (including transforms and attributes). To me, that's still just a proposal. To try and further clarify why I think this is important, I'll elaborate more on the differences between what I call a protection suite and SA bundles in general. To say that you support SA bundles (in general) means that you support: 1) Iterative SA negotiation with both a single peer and multiple peers, and 2) Protection suite negotiation. To do 1 above is a significantly different implementation issue than to do number 2 above, and a significantly different negotiation method. For example, a generic SA bundle that results in ESP and AH applied to the same packet could result from a policy like the following: H1 --- SG1 ----- SG2 --- H2 H1 <-> H2, all protocols : (ESP) tunnel SG1 <-> SG2, ESP protocol : (AH) transport For number two, a similar (but different result) comes from a policy of H1 <-> H2, all protocols : (ESP and AH) tunnel Both are SA bundles. The second is also a protection suite since it was negotiated in a single SA payload, and both SAs live and die at the same time. In the first case, the two SAs are independently negotiated and live and die completely independently. The AH SA might also carry traffic from other packets that ended up with ESP protection from hosts I didn't illustrate above. Those rules of negotiation and treatment of the SAs is important, and needs to be clearly spelled out, since it is different. This is why there were so many issues at the interoperability workshop with respect to IPCOMP: Does the IPCOMP SA proposal in the offered protection suite have to have the attributes of the protection suite? (I'm offering this question to illustrate the protection suite issue, not to start a discussion on this issue in this thread...) Has this clarified the issue for anyone??? Tim ------_=_NextPart_000_01BEACFC.B728CD50 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgMNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAIACQAjAAEAAwAOAQEggAMADgAAAM8HBgAC AAkAIwABAAMADgEBCYABACEAAABFOEZEN0EwNUU3MThEMzExOEE1QTAwODBDNzk0NUU2QwAzBwEE gAEAUwAAAFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFm dC1pZXRmLWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAfxsBDYAEAAIAAAACAAIAAQOQBgBoGAAA MQAAAAsAAgABAAAACwArAAAAAAADAC4AAAAAAEAAOQCwfhm3/Ky+AR4AcAABAAAAMAAAAENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtaXBzZWMtaWtlLTAxLnR4dCAobG9uZykgAAIBcQABAAAAGwAAAAG+ rIxIREQxcCkYVRHTk1AAEEtqqNgAGnh00AAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAA AB4AMEABAAAACQAAAFRKRU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAAD2EgAA8hIAAJcoAABMWkZ1 1ufIvwMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwEC AGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6dj ATAdBgB0AxADIBewbmcsmCBidQVAAiBseR4hwCB0aGUgcANgDrBGYx1AHoFzdWkOsCC7BAEKUC4K ogqECoAtISDTIGQHYSBKCfBrC4AEIE8ibyLDB2IdMGVwEiFymnAFsGEfUiBkdGoiBO5AHUAHgSQh LgWgIdAix4JoAkBwOi8vdyfQBi4mCiBkKDYxMymgIDU5OS0cIDEWUCB4NDMwNCLNRmFoeDogKTs3 IGogaj7WICEhISBPBRBnC4AHQMMF0AeQc2FnZS4zLbbWRgNhK5BEA5FICsAiI4ZbAMADEHRvOmQT 4RMlswfAdHcFsGstQQJsE9BlbXkuQ088TV0ttgZgAjArkEp1Km4e0DEd0DEpoDkggDg6MDggUE0t tp5UMdAjwiHmLbZDYyuQIwUgFBBjQGwEAHRzdSgBcwtgYjiwKKc0IXXOYiWAH0ArkFJlK5AIUN5t B4ACMAQgHoFkJLABgL4tCJAAMDvgOCI74GsvcOwwMSgADtEoHZIpcC229T3OTwOgVApQHdA84DSS QTUUMDk6NDJAoDdAIEVEVCB5CGAgXncfAi22PiguEDEpcFVbFBAeIGYeow6wciHQIo0e/iJB70JR SSBhIdDLBuAesCAFoG5jBJEJgM1GwG5H0EdRZnUUEEfQ/mIeYB6ySHFDiy22RF9FaY8LgB6hBAA7 gG9jdTsC/i4QwAQgH8AeoAhwBjEIYL50HdBMo0QDE+AEIGIJ4fs+NxggLQEBC4BHwQNSHqEDJMBL 20lTQUtNUMEroFJGQzI0NZApcPsxwFBBZhKBU3EeMx6yFBD8cnYN4AeRHvFU8AEAR9B7LbZIwWEe 4E9BNNEGAEE7IFVCQigGYFSiH0QzLk8/0EORO588qC4pPc5U+x7BORF0JLAfQEOETMJZUn4gDsAL UA3gH8AeUS9Aef9O0VFhQYAewBggHqJfQS22/wrAHtBIMl3xOKAttk3BA/D/HWFPgB+RHvAzQCBA PjUgZHxFdk+hVXASgVLgUvQ//CBXHtAYIAdAHlE0wEfB317DTPZTYmIhYmBkJMAJgLslFR7AbiBb XBAkwCcEINpuHxAgM1Ae4G8LgAVA2QBweXdegE1wTWm2amDjXqVNwWFwcGUgFABRSd1KvyIf8U9x C4BnUEpMca9WkCaRC1AUIGUeUWQGkP9TwTRRIGRqYVFCA6BS5R3Q50fyRrBM8G4nBUAUEB7Q/18Q M2AtXEV4P0FMoyADHdB/XxBrol6iHtEIcCSQQ2Rh/mRwkG6xajFlcQfgLbZQg38fwB9iQ5QUEEV4 VMZkwEmfQ6J2dDTAVREvQHJ5djL/HmAT0R2wX1NdsTiBbqJ4v/95wkV4Hv5kwX0RaWJQoUfR/0P0 XsRzExggH6AxsExiX9f/BtAuoB+xVnFIAEV4SDQfYfNXWCBqKEEG4GOwYENpoTsFsC6lcQpQfiEC IHM7/3LSVZBzJlaQg4EkkACAQ+H7U4AesW1a9iBkRrBMoSIQ/2mSNLAEgSZAR/FuokORQVH/BcB3 QXmEMrCDsEihYHFwIP9gUQXABpBnh1xBiDKJd0GAl18yAHGSYmRNcEknHWH3XcFH8ovSOiBqQyGB kHZ//ztBWSF5Q3gJRAMCEFPhVJP/XMIgZB7xd0EHQAQgR/IkwP1cgGkd8ZZzcMJQ4QWxVrX6PyBq Milwe6GJdjTgaTH7krRuQnYHQFWQfOSPlEPP9yTnbeWP8mh3UY9xZ/FNsg+JcB/CkCMeUShJTUju TylwB0BlEWQeYE9CVpD9ZAF5IGRwl0fkkDJ5KZw786PwZQNpel9Sa6NpNabE/1QCX3I4sIwrQkI2 YJARCsDfBpBI1H33eTxtLyId0C22+3NiWFYyWONFeFLllFVCTL0iwVAfCDoAH8ErkEGAb/9uQlaQ OHJDhjgxCHGFELM7+1THXsNtSHAFQGIhbAE4cP9IlJ7QBRAIYAQgt2a1M00A/wbwOLArQQWwszsO wEbQcBF/coG1P2mQcZFHUQCQtsRE3kUF8C22CfAFAHkFMB9i51IyUrDAUFAssztH8jywInlHwU1E NcGlQUj/TXEdYUOVvkhNoW+ivvW5pP+zO1yAZSBnUUbApQIAkB2w/3AgjZEfwLxhXBB1s3xIT3H8 Y2FJMrdvuHtMcaXou0+/BCDK8AOgE+CIQR+gYl4w/8csafEEkFyhicJyhH2zcLHfYPF3g8ZcR+EH QHmpEEfT/7M7ZAEGkLpSpPNfEAbwIEb/PihGsGtCjaMeowdwYnEEEP8fYl7DTKNrQoYVbrFsIJmQ /8kRR/IttmfxR4B5IV4QVaH/LbZTcYswcFDEwR4BdlOf58cHgAYiU3FJS0WTMcAk/0xxwhG2RKCO euEfs3ZTkWH/HgEesjhwU8AmAkOG4LKbA/97gV6lCrEFQS3FxO/h7E9R/1CGSMFS5WTAaPldyt3C Vbnv3hJH8tsEX9dzPLBH0OQR/+MUyWJGsBPgbBEekVOAL1D/CdFhwUchi9PqA6ARDtJ+lv5vB5CD RGUyLbbK8AUwCHD/fZTfMo5Fn+dH8kzBmZDvZP/Q82JxAZAfUiBbe6GsY4UR/0OVrS/Bgna1A2AC YDNAToLv72JRZ9nyXtJzojCPtXMB/2KxXBJ9931EkkEdUgUAyCL/aZAFsEHV+sVPYR5gUFZuot9N wW/vNFEeUCBbSF8xaTHfaaF5PL4vOqAgaiK1L7Y0/7SRB9Ad8EgAyRFMcV8QDeD/8FNXIcXzHrIJ lGzEYFI0wP5nCBAQ8MhC2qRUg0bQCrJ95dF5F7B3wAsGDdOjEWN7jVEVcS5FZWiY+Z00UWn/GCAe Ub+VZnLwI1LlTXBS5X2kUXPdkV6BZ4bedYIhaf1VgXUu4QrV0w7IC8lEybL/bMTfNV7VY9E0wQlh F1ldwf8ScdGixLEK0tOGHHSTIIyV/2oRFPP81N8y0bbZ9ejQ/9D/v7BcgchDg9JEAfXBJLCEwP84 cMu2MrL8wTgg+zLeddxB/2wAg6H207oF33MKlqTz79D9uwBw+zC8po3xyEMxsEeR//bRY7CjwPsx JhToR9ZWo+HnY9FfcoMRcmQj418xC+n/U4DxMVlQwdLm8HfAjdF3sv9IkjKRT5Lm4i2tSNP75RZ/ /+bsvuSrHrM4xKAVAlgh5uI9ikBzTRDZJExxWFY0Lv4yQ4IUZ9HlwIe9pDZZszj/NxFY5BPXxKhW 4aMcMOLPMP/ocRXXRAKzOK6fbjAliVa03zcwCWGdge5gtqFoTTOGvf9F0oGQYeDnAEax79NrhvHy n2lTfFZh4LuysKBsdejQ/1apszhCK/swcuJpUzU2ZYT/76G6IT1xZpNew/LYd2JUQf9ygWEXeRFZ X1pna/hTgEWQ89bPXBJET4ohbyP8Vd/B7wx4FzNBde7gV4+ja9HT0f+zNi6B0RGQkYoQ8tjrowXf /ecAIs9BzuFwIL6Ud5KaaK9L+wxN7VjIrCJkwEGT5P2+0WHcwGXFzjHa0pvTG1L/OEoCIhtRcQCW g+HoCmHGRuW2UTz68GFoY5aEgfVh/5AxiEFr0WcQ74NSA92Bfov/fZT1A7M2VoFr0RUBoiGWUuuc OxETbYkAaLnD2PFwwbtCUf2RQuNCFRDuMShHdvvaMNzBKSP0ngF2UgdkFGb/pOOkdf1jlGpeIoog fiHEsf1zBGtF4HiQfQKOsdfhE1H/Swef587AmRVsZnhA2iADfP+zsTRM+zMNIeQnoC5ARrZT/6VC JvBo4NuYdUHdcmrzdAf7hdLGQmKYtAlY/FKScgqf7wmziHKzNgyPYbM4yNUOKP8ZlBzycfD6Y3Py /SMC5lwc/maZgPUwfaizOF8DW40wJP/SRSjhASHOIdkz9JGZoOrx/3tzszbl4A/A9rC5JVuBszj9 weBTsKBXwkZCHldROsnU/10hIsBQAcqhkLD1wd/zSaD/ceIn84glV8+2Q+HofSYtUP8JlX1z+mOi cvySm5C2030E/eVAM5r0tmDr+vSUszbD4/9/aOVIkv+bMXC0cXTdB8nA3m4P0G1VmanO4HJG8blx +/Qk7uBF1ZCiwVnhxLGYIh/m01JwZOEusFuRQU5E/+vJzsD+0Cvy+zCpk3ETdeb3mCCTHrxRUCIw 7yG2YHJi/88yAiHJIWVQ8CNysCsk3Qf/c9Qg8TXQWjHtSJTf1qcQtv8yL7Y12QElALbXgNb28pGk H61xYVBHoHWKKuBQQ0++TcRA9VLgsvVSxGApJ2H/KtDks1Zgs0F1it2BcmFJgf4n9TDk8w1ScmIt UGjBuPHv9IMjYK1vvFFI9cHakPKh+8JFcmEnxLHZAWFR1HDwI/87A/BAaPHRuK7V/xMYUhrD/zzx yBMHZC6G2qBdGDJP8MS/rX//FDbgKAA9kAdkZROR/1ZRG1KzgbdyfvFv60Qw6jP/kLfjFhMQaTs0 K6SRYpFJgv+eZneXeL95wQ7i4PHxeM4g/0Ky4OLaZ3xJsxH8yP6USuT9IsBnChETmSdSaFP81+/g ///Q1ZDUuShho9WPDxRmzUr/9UPX1O3U7mZsAHUR5tDkAf+4sbWiWwcuMK7RzcpFFI7A9nX9kfc7 J2ThLOEAd/Al/VoAOk0DXvSdZp5kueJbkfn4I2Z5DVG5dVpR/oSgorvHT3YTQT5U+DAdomHt8P+1 4WiBbBAbUiDCDlDZ4ybR79iBDdD+0EmQRAsGdeaz0P9JoFJw65AY4PSQWwcb0EXh7+Ah5baDpSDC ah2RhUBOkP8wA+jSDWNfIaiyDVI4iPaR/47AEqGL91fgIIAioIzBYoP/z1Bu4BagJ3BUsftkDVGu kP/ycQpjroGSRMlWetcEgGTh3wyhKABh+FAQO/FlejLsFP/XoxvQeoDGYVJQwtH/QGRy7xRmRZLe 0yYUavrgb+tElf/YsfpjW5HkZyNx9IMb0htgX0/B/tAbYCFxQBJJCWBL77JRzLbHP3YEREWiBMEX oP5no+ATIR+xEADqoT3RQBL/p9M9EGjxfAKWxHJi8ZzRqP8VMWk11Jb4RnF42LHeq/Jx/1uRveG5 QV70ALMJ9L10nmP/C+XBP65xBaKeZKRjWPF9p/9+TzQ1f2mik4DfKYM5IILs/8lYbeYBqAt0WR2w 1B8RKtDfG8BHEutjTkAhQGYncN0R92RxLEVaFynA0WvybTdxFP/qYpvUFKOsbEvRxmKzEc2g/5dA qOLf5XITyViQNNhwYVD/l0BysbWC8+LjkMagIXKxpP/SkFuRNuE1dIVURkEud1LU/1czm98p8haG fan1AvtzGf//A2Fe9HJiwfBQAJcyfakVEV8lBrNgoGJalScZOnWKMf2zYEl4YQABZOF9oa+5usS/ xqCocr9XROBWYLMCba8BW8YgLkVz4IUWdzKzYFD/V+6vuhodScFsscagZOJdBP/QYP/DzRA9YYU3 HbLc8c0B/wAE2wNtQsMFUHNKoMzgz1D/VmBB0DQju8Q0vzXHLIpsEPe7cY72saRGs4Hs8BBgL1H/ u8H7VIuAC+neQ67UDVOyyP9LI+rCfCYQF4x0zWHPEq7V/4ajInGLZItw5ACh9FkxcfDXtjEqu3ZQ SDQALUcgDSCeR0cDRzM5EEciSDJGG/lG8TwtdkBIgLvAoWMiknfMwItgrpAg3dCzsrNgdP9/sMPw pPVHYkmiSAG7wLLC/0p2dlBLErNCFcMd4jy+OKX/t3E+Is3AalDf8Shw4PI1uP+u1LNgp9KukEQM 6AZJD0of70sksvdLqrGkQi2jW5F9qP/A0vmhE9C6koPjaJEif/mh/xUhZPPqIbGkiMn1Ab9Hgwj/ u8Qtkw0yi3Bk4bMChTB/8f/jNBBSDaXYcdix5oSiQC/A/+ERdLF3VMRViHP1AKogLnD/ZTE1Y4jJ Fndgu6fRL1HxQD/eEWUrWhRBAX2hUSBnaP+IYVsi//CgANhBKQCFUIuA/7GkhqOoxIx7ZXKBYag1 TTafE9WGo7uBjMGdYWlkcZF/saQY0epxHxI0FKxtB+Jy/88Q/pHKUSyKu+O94szzodX/DTMdqxZ3 w/Dq0J8RhOMHwP2gcHLeEfOz6tHXobvAXJf/roGFN4Ol6fIckA2niJGik/9bMdgTN0OukeM09QCp oZFh9ykA7mCLcHQcYfpR0dGoNf+6UhPRtMeyFN3Q/nO8IrIV/xCiGZXmZrXj6tFbjrGk7yH/N4Ez 4IW0vDEXCKHGnA8ocPe1q8bysaRxfYHK89ABcRn/h6+uRNshu8Cosfci8RGXQf+UVf+wqkDNsM3A FBLLxTdEv8u23kDwYTyQkWC0W0jW8f/L49/kQXN+AjdTFhHokbZwvcPwP5TQrHvYcLGkfZZgAAAe AEIQAQAAADYAAAA8MTk5OTA2MDIwMDA3LlJBQTI0NjQyQHBvdGFzc2l1bS5uZXR3b3JrLWFsY2hl bXkuY29tPgAAAAMA3j+vbwAACwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAWACCAG AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAA HgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAMAAoAIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAA AADAAAAAAAAARgAAAAARhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAI gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACYAIIAYAAAAAAMAAAAAAAABG AAAAADeFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA AAAACwALgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAAyACyAGAAAAAADAAAAAAAAARgAA AAAFiAAAAAAAAAsAmYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwBBgAggBgAAAAAAwAAA AAAAAEYAAAAABoUAAAAAAAADAPE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD///// AgFHAAEAAAA7AAAAYz1VUzthPSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9RVhDSEFOR0UtOTkwNjAy MTMzNTAxWi0zODEyNQAAHgA4QAEAAAAJAAAAVEpFTktJTlMAAAAAHgA5QAEAAAAJAAAAVEpFTktJ TlMAAAAAQAAHMBB3Frf8rL4BQAAIMFDNKLf8rL4BHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAUwAA AFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRm LWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAAB4ANRABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAAALACkAAAAAAAsAIwAAAAAAAwAGEA9+ 1XkDAAcQmxoAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABTVElMTExPTkcsQlVUT05MWU9O VEhFUFJPVEVDVElPTlNVSVRFSVNTVUUtLS1USU1KRU5LSU5TVElNRVNURVBDT1JQT1JBVElPTlRK RU5LSU5TQFRJTUVTVEVQQ09NSFRUUDovAAAAAAIBfwABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAACnsA== ------_=_NextPart_000_01BEACFC.B728CD50-- From owner-ipsec@lists.tislabs.com Wed Jun 2 09:16:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20892; Wed, 2 Jun 1999 09:16:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03423 Wed, 2 Jun 1999 09:49:25 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB177@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Wed, 2 Jun 1999 10:00:00 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFAEB177@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEAD00.34939A60" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEAD00.34939A60 Content-Type: text/plain; charset="iso-8859-1" Protection suite response not included here... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 1, 1999 8:08 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > On Tue, 01 Jun 1999 09:42:47 EDT you wrote > > > ... > > > One question that seems to be asked a lot is what SPIs are > specified in the > > delete payload. Since IKE specifically creates two phase 2 > SAs, it is > > appropriate that it explicitly state that the delete > payload contains the > > SPI (and protocol) of the inbound SA of the sender, and > that the receiver of > > a delete should delete his outbound SA and his > corresponding inbound SA > > without sending a delete. > > RFC2408 says it's the "sending entity's SPI". Is that not clear? Based on questions I get, it's not clear enough. It also doesn't say anything about the deletion of both SAs, since that's part of IKE. Or is it??? > > > Further, for "protection suites" as defined by RFC2408, it > should be stated > > explicitly that the deletion of any one of the SAs in the > suite means the > > entire suite is being deleted. > > This comment still stands, assuming a protection suite remains what I think it is. > > Other Comments > > ============== ... > > > 2) In section 3.2, I'd like to see an explicit statement > (first paragraph) > > that payload order within the SA payload may be changed by > the responder. We > > saw a lot of this at interoperability workshops when it > came to protection > > suite negotiation (IPCOMP and ESP and AH). Here, the > proposal payloads that > > had the same proposal number were frequently re-ordered by > the responder. > > OK, you want that in ISAKMP or in IKE? Well, it came to mind when I read the first paragraph in section 3.2. It looks to me like you're trying to clarify ISAKMP. If there's no new ISAKMP document, I'll take it in IKE. Otherwise, this and the paragraph in your draft should probably be in the new ISAKMP. > > > 3) Also in section 3.2, there are comments related to > automatic range > > selection of attributes. While I think this is a good idea > under many > > circumstances, I'm concerned that if this isn't explicitly > spelled out where > > it is possible, there will be problems. > > > > For example, is SHA-1 considered stronger than MD5? Some > papers suggest that > > it is. So should I allow SHA if the peer proposes it but my > local policy > > says MD5? What if I have hardware acceleration for MD5 but > not SHA? Then the > > peers will start using more and more of my resources. > > > > Similar examples could be made for Blowfish versus CAST, > especially when key > > sized can be specified. How does an implementation decide > what is more > > secure? > > > > Bottom line: Where it's possible, if it's part of the > standard, spell it > > out. Otherwise leave it up to local policy to allow it or not. > > I was spelling it out. I'm not even going to touch the issue > of whether > CAST is stronger-than, weaker-than, or equal-to blowfish. > This text deals > with attributes whose values are variable not with different > attributes. > It specifically says this in the text. > > Is blowfish with a 80 bit key "weaker than" blowfish with a > 448 bit key? > Is group 1 "weaker than" group 5? Or to put it another way, > is there any > reason to refuse to do blowfish with a 448 bit key if you > would've proposed > 80 had you initiated? > > I'm attempting to codify the behavior of certain implementations. Some > people will not accept group 1 if they have group 2 > configured but will > happily accept group 5. That seems to be correct behavior. > Similarly for > variable length ciphers. If you're configured for 128 bit blowfish and > someone asks you if you want to do 448 bit blowfish do you > refuse? If so > why? If not then where in the RFCs does it say that you can do this? > I understand what you're trying to do. However, my point is this: If it becomes part of the specification, then the specific cases where it should be done should be explicitly stated. You kind of make my point when you ask about the relative strength of different algorithms. And you weren't really spelling it out. You were saying that where you think the offer is stronger than your local policy requires, you should accept it. Charles Kunzinger's points are very good ones on this issue, also. If we can't make explicit non-debatable rules about this behaviour, we shouldn't specify it all. Here's a couple attempts at spelling it out (in part that illustrate the problems): When a proposal contains the same encryption algorithm as local policy requires, but differs only in the length, the proposal SHOULD be accepted if the offered key length is greater than that required by local policy. For the purposes of this rule, the DES series of algorithms are considered to have key lengths (from smaller to longer): DES40, DES, DESX, 2DES, 3DES (Is that even correct?) When a proposal contains a different group than that required by local policy, the proposal SHOULD be accepted if the offered group is stronger than that required by local policy. The strength of the currently defined groups (from weakest to strongest) is: Group 1, Group 2, .... (and it might get slippery here...) You know, the more I think about this, the less I like it. Also on this issue, I still don't understand why I would reject a proposal that proposes a longer lifetime than I allow, because I think you're adding that. If my policy says max 1 hour, and you propose 2 hours and I accept, why is there a problem as long I use my own lifetime and delete the SA after 1 hour? To you it looks like it expired prematurely. Even if you don't delete it and I do, is there still exposure? ... > > Dan. > Tim ------_=_NextPart_000_01BEAD00.34939A60 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgIOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAIACgAAAAAAAwDrAAEggAMADgAAAM8HBgAC AAoAAAAAAAMA6wABCYABACEAAABFRUZEN0EwNUU3MThEMzExOEE1QTAwODBDNzk0NUU2QwBABwEE gAEANAAAAFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWlwc2VjLWlrZS0wMS50eHQgKGxvbmcp IAA+EQENgAQAAgAAAAIAAgABA5AGAJgUAAA1AAAACwACAAEAAAADACYAAAAAAAsAKwAAAAAAAwAu AAAAAAADADYAAAAAAEAAOQCATIc0AK2+AR4AcAABAAAAMAAAAENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtaXBzZWMtaWtlLTAxLnR4dCAobG9uZykgAAIBcQABAAAAGwAAAAG+rIxIREQxcCkYVRHTk1AA EEtqqNgAHAnjAAAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAAAB4AMEABAAAACQAAAFRK RU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAAA+DgAAOg4AAGIcAABMWkZ1MfGoegMACgByY3BnMTI1 4jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMR JfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6djATCMIFADYA6wY3RpAiBQ IHN1aQ6wIBggc6ZwAiAUECBuHVAgC4BGYwpAAQBkIGgEkGXeLh/gCqIKhAqALSDQIBTpB2EgSgnw awuABCAiH6sicwdiUw6wcBIhch5wTHJhHZIgFHRqIbRAdx2QB4Ej0S4FoCGAIndoQQJAcDovL3cn gC4DJbogFCg2MTMpIFA1OTktHCAxFlB4EDQzMDQifUZheDQ6ICjrNyAaIBo+IOsg0SDQTwUQZwuA B0AF0GEHkHNhZ2Ut4y1mRmsDYStARAORSArAIdNbwwDAAxB0bzpkE+ElYwkHwHR3BbBrLUFsARPQ ZW15LkNPTR5dLWYGYAIwK0BKdW4ZHiAxLDSQKVA5IDioOjA4HSBNLWZUMYDnI3Ihli1mQ2MrQAUg FBBIY0BsBAB0cyexc50LYGI4YChXM9F1YiUwsx2AK0BSZStACFBtB4C3AjAEIB2xZCRgAYAtCJAv ADA7kDfSO5BrLyAwMcsnsA7RKBewbmcpIC1m9T1+TwOgVApQNLA8kDRCQTTEMDk6NDJAUDdAIEVE VCB5CGAg/ncdQi1mPd4f5z3YPtIeIO5xClAl8B2idBPgBUAUECcy8AQgMXAgYh4gYXNzPGAfgGEg F7Ae8QQgd/FFQlNQSQQgCsAeIC1m/x5gBZAGkAiQH4ALgEUhQYldAQBsFCAeIAqweRewYRxkLgYA HxEeIElLRUVIhmMHQGx5IAUAZf8kcAeRMlFKkBPgHqEUQDN3PEFzNLAeAEbxQZhhcP5wA2BPwAcw HhFFM06xDsD/C1AN4B4ATHEl8FAnSWFKJv8tZkqlTJACIQtxRcFJekeBfytQAHAfgE/BMXAXkSkg b/5mUjMLgAbgNGAfgE5gVnb/FBBVsASQNLBVoi1mUfcYIHlLYGl2EoFWgE8JSiZz2mgIYGwfgEo1 aEcBCGB/AlBXJlWiXKItZgWhHkRk/QuAZ1bpQZgD8EUwXOFYAwdfQls2Qz9SRkMyNFs1QS7weQQg HgAnVGMgbiJhRjQBHgB5ZEFHgSI/SxBHoUUzHtIfMEzAcj/9IBpCTYEfgB2xRKYEIFVwfS8QdE6S ZEFmt2UxCGBnLmhmEQVAB0BzRfBkb3EHkG4ndCAUY9FYgXn/RTBhg1cRUikdolaBBuBFMP9OVACQ S1JFMmRBCrEFQFaB30uRIAUuMEbyHgA/cbAtDH1BmEYIcElhWGECEAXAIvNV4h16cyJGMUohSOA0 cP0fgGJMgGNVTpNIF1vURhH/UZMLMUG2UOlR/G41bLE7Af8eIFaFTmFJJUgIHfMHgAYi/0lrZUJH 4R3kRwFGEF9CSjT3SwBBlyAaVFyiJkE6slGBfwMQAyBRkVWwToFGQB3gbf9hhHROHjExMQYxRzIg FFVw/Wzia06kIAtEI3OSOndBmL49igtCvXJPTbApIEkdwZEddTMuMjSwSScfgP84IDxgRdJFgViB UNdRhIKT/S1mKEjgFAAFQAqxLwAkYP1NYClBmEUzU3YFsASBYLP/fGVXcVN2AMBMgEYRE9E9MN91 9FjYHiYEgUsQV0GJLvD/B+BGpFaDRwFQggIwBJBP4P8EkAGgAxBlcUEwMnFbwTfQ/0chCfB22kxA B4BF0nRIl/k7HfM0cGeEkFARHaIoSWpQMzFQWINFR4BYg0H0SClLEEgfsTSwfJpPwv5vLvADIEql ZkRBmBPgH4D3V9OcoqInboPwRhCTwR+xv3PgGCBEoQIwTHEYIC2Tg/eWD5cZPf9LNLBBAwBwUiL3 mbNLgE5gS5/BBbGrUkug/2dLl9BMYE6TnJaEAR+Am5P/VXBMsaREkR0fAWwVjWhrA30XsG+bIK4j HiCOY0EBJ/FH4XRyeV9CReEfMArA/QaQeYZFq5NmEVaTGCBp0++eoQfgq4VroGOD8DQBjgL/gxEB kI6BHgAgFKwkSxCIg/8D8aEzmYJVsVJCsBpA8gXA7ztDbBVb1E/BYgGgTHFGEf98ZbaIi29BtikR MrBrcUkx/41btdNHw4JlBCAYIAtgeGG7RdItZmFc8ANxHZBjHjB/ldKX+UpBHYR7AgJABRBi/1zw B5CXsVygSlBpMYbEmWP/mYJpULJASREBAEagLWZXMd8SgQOBtLVB8kjAcrdRg0L/S2BOgY4gIYBT 8UtgBKDDkv9Qc5lFBABr4VDaSBlMYGhC/2ERm5EYIEGYTrNKkKJgAJD/AmChNEfhA/CDEUYRvTJK UP9FsIC4croFsQ7AnKALUD9B4UcBU0hBLT+AU/EAkH+nRCXwA2CV4QXARTEDoE34RDU/BgADcFLa mkEEIP0d4GcvEJFBo0yHJNgxW7b7VXBMUW8H4NYBzYRKgQng/wXAoiQHkU6xxyF9oKe4F7D/TEHR oVERyslj09fzx5DNZH9VcBPgWjCkEQsgqrDCQmP/S2BKUCRkc+PX8d4jLWYe0v/WAdggghCbsUlr 3SJHEYMF/XAxdW9BX2AEYMJCVbHn0/9Wgd5xHkEIYcwR079VEwdw/wMQanLVVIJCd8UAwAEAc+Pu QtwxSOBbwCBaMR3gBCDwQ0FTVDSwLWYeUUixz0xTm5M8YN/aaXofcUxA/wOgeAJIpqDh3EFroo8S B3D/1YE6sp8UBYHJYT3nRzNHAb/n0sVqt1AYIGdF1CxChJD/xJGOUTRwK0DHkKYCZCPRuP/Nkfk0 cCV8m4NSCxFvIc+y/7hnQfJc4blZRrBMwOHhTrH+dSPwReHfKkXS3BROsQWx/x7RqS9VcKqw2WHP sl9DcEH3/bLMYh7SZVow8VCe0LPl/zFwGtBu0Fazg9FH+FaBm5Hfc5I3B+4xRvLXFi3XojSw/6Xw uDEI5tUSpnDcEAjwRfH/7TVLEDWXXKIOs8lxa2D0d/9g0cbJRyHdse2g3BBEsUfDPw7gUAHSAR7D DYNfMGZm/x+xkFnG2gIHRWFL6mPTyHT/fHQMYgF/R6EK9g11NRAdEP+agDzg8AFkoAlk15N1UBau +S1mNDQ1UBfV9rdHoZGw/2EAI/A/gBhcHCTYEXExnOL/YRFOsarAbrGTskqw7mgMMn/CJMq4TLFr cEURRfDDQGb/53COk2ugGS8auc2CqnL0d/1b4ifh4d11eIcXoaQiqnL3sLB1EFASZPa3AgfMcQ3R /TLwcHSgs/XJMLSRUjNGEP/hwXSwWlJMkMzgVCLzDdsj+9hgUvdlT+DHwdKzECLiov8qABwX3LR2 MOHDHCRNyFPx/UwgZ/aBdgHQMoMBGjZNcO9PsOsgbJEvajVLEIIQRV3/XqM6ACs3C3jq9Uxxc/Ea Nv8Pl0pQPTBuwe9Au2DZQbWD57NFMhlz8jEyJAQWp1Wh/0gX2FF7ckZBXgAnkyS0qrT/IpMj5han IrEk2iIU2CC1of9rcPR4G1C1khAiSWHxUNBj/3xWY1F1gfKij7JsgVHzqnL/8TIisZli2CCpPIZG yjODQ//05LNPa6DyMwRxWGHecaUg/5nhICQF8PiwtaG4dngAgmH/8rH6qhNHdKKhQ3x0E0acgf/d wkS1vFx4AWuge4F3mHk563g0h3tZqoFrrnLosrgyv0w3m5Oqcj6hbTnDQ2nh4f/XETnkTtCK5BC4 3BAEwLSA927A05eK5EGggapzEPLOQf+vIRPTAv5WAqXzY9Gz4+Ey/0S0qnGK5MgWe5IQ4Qg615T/ u8P/i6ZSfxFvEapyvMSK5LcvVZvgh3tD4hHrwkvKMP56AzHM4PlTmeEPNczgdjD/yRM+YcjQIbLI hAYRg6HA0f+1g6XwiuTxMc5BVsOPVxAgvG4tdaC9YLggD+JyvPD/8rJYhX+zK2NzcAlC23XOMe+w 1fGzJIFbMmyHe6ECtiH/I8DsAS6CKbWZk149n2C7kf/6o6sEE9Dt8A3ww3F+CNM2/Ck6h4r4wvFQ hFOlJMyh7ywyffOklDngY7PAKgGfQf9bVz6R3x95YWS44/IQtGpyPzhhvfU51KFEoifccE9V/ExE lXF5JS9Uz/HctWIj/8/xGBI51dGBkbD+oJoB15T/YENktaeCeSV9Or8L1PO6s9+74N2kmTZusqFE RKAwNYH/tICJ9FtYwmXWhnklNfEww9+EWMjQkQDXMCmQc+yQz9GfHiOY8NdSeK2LMjQwt7Cri0GS I1i3sDKSQzOLQs+fcKMkBGQ2VT8peM953/964iPAELgcJIW/p4N9NJV1/9+EgO+B9YLPg9YcJAhJ jbb/mK+ZuIfflbHlQVmar2P2cf8RAjhhylATkM0CHCOPRgljf9nS22HXJHcgwKBNEZD8R+8cNLew qFTB4S6pcZOQunLzchHrEGdoL6EHIEZAZGB/M+BpstByqXGVC1WpECB3/5sk59PH9m8YmyTrwcjQ 2/D/svNmzVxlwNJqndvwdyDm0n9TMc5BSVvegAKBvOPDQGr/NpKWOGEmNWHddyPAkHT4Yf8Q4E/Q 2GHXo9v1fuHBUMRw//5hx/Y7BeygELDFMLZ4vwvfa+FMM2RjFBPskHgccWWh/0wBScI/YiYlMWG+ cvLC29P/L2NwUbSxBfBhJiCD0yZ89P8DQUkx/mHecdxA8VC4R0nCn8pQ/pB3ZOrg3JBhZoVyu75U 9rVUQXRyEdwwbz7B/7A1zmKGk3ggNbAN0PaBOGD92zBFBIIkpbOUxRX85sBU/0Ag1bPSVLM0VCEO oPaIGjT/qXGwvwHZkbE/sBVtxsXrAAUaNH3TEAAAHgBCEAEAAAA2AAAAPDE5OTkwNjAyMDAwNy5S QUEyNDY0MkBwb3Rhc3NpdW0ubmV0d29yay1hbGNoZW15LmNvbT4AAAADAN4/r28AAAsAA4AIIAYA AAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAAD AACACCAGAAAAAADAAAAAAAAARgAAAABShQAA8BMAAB4AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSF AAABAAAABAAAADguNQADAAKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsABIAIIAYAAAAA AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAeA CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ACIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAAmACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAKgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsAC4ALIAYAAAAAAMAAAAAAAABGAAAA AACIAAAAAAAACwAMgAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAAALAJmACCAGAAAAAADAAAAA AAAARgAAAACChQAAAQAAAAsAQYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwDxPwkEAAAD AP0/5AQAAAMAgBD/////AgFHAAEAAAA7AAAAYz1VUzthPSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9 RVhDSEFOR0UtOTkwNjAyMTQwMDAwWi0zODE1NwAAAgH5PwEAAABaAAAAAAAAANynQMjAQhAatLkI ACsv4YIBAAAAAAAAAC9PPVRJTUVTVEVQIENPUlBPUkFUSU9OL09VPVRJTUVTVEVQL0NOPVJFQ0lQ SUVOVFMvQ049VEpFTktJTlMAAAAeAPg/AQAAAA0AAABUaW0gIEplbmtpbnMAAAAAHgA4QAEAAAAJ AAAAVEpFTktJTlMAAAAAAgH7PwEAAABaAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9P PVRJTUVTVEVQIENPUlBPUkFUSU9OL09VPVRJTUVTVEVQL0NOPVJFQ0lQSUVOVFMvQ049VEpFTktJ TlMAAAAeAPo/AQAAAA0AAABUaW0gIEplbmtpbnMAAAAAHgA5QAEAAAAJAAAAVEpFTktJTlMAAAAA QAAHMOBghzQArb4BQAAIMGCakzQArb4BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAADAAAABD b21tZW50cyBvbiBkcmFmdC1pZXRmLWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpIAAeADUQAQAAADIA AAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZBRUIxNzdAZXhjaGFuZ2U+AAAACwAp AAAAAAALACMAAAAAAAMABhDeo337AwAHEN0RAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAA UFJPVEVDVElPTlNVSVRFUkVTUE9OU0VOT1RJTkNMVURFREhFUkUtLS1USU1KRU5LSU5TVElNRVNU RVBDT1JQT1JBVElPTlRKRU5LSU5TQFRJTUVTVEVQQ09NSFRUUDovL1dXVwAAAAACAX8AAQAAADIA AAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZBRUIxNzdAZXhjaGFuZ2U+AAAAGi0= ------_=_NextPart_000_01BEAD00.34939A60-- From owner-ipsec@lists.tislabs.com Wed Jun 2 10:53:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21849; Wed, 2 Jun 1999 10:53:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03760 Wed, 2 Jun 1999 11:29:07 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB246@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Cc: John.Shriver@intel.com, John Shriver Subject: New MIB Drafts Submitted Date: Wed, 2 Jun 1999 11:39:55 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFAEB246@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEAD0E.2996B800" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEAD0E.2996B800 Content-Type: text/plain; charset="iso-8859-1" Greetings, A new version of IPSec monitoring MIB document is available at , and has been submitted to the internet-drafts registry. Also, a new document, also part of the IPSec MIB series of documents has also been submitted. This document is the DOI-independent portion of the ISAKMP monitoring MIB, at . Due to the embedded page control characters, it should be transferred as BINARY, not text. Comments requested. Tim and John Note: I have received comments that the FTP server on the machine above does not respond to all types of FTP requests. I have tried to get this changed, but have had no luck yet. If you have trouble, email me and I will email copies back. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 ------_=_NextPart_000_01BEAD0E.2996B800 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjkPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAIACwAnADcAAwBKAQEggAMADgAAAM8HBgAC AAsAJwA3AAMASgEBCYABACEAAAAwNkZFN0EwNUU3MThEMzExOEE1QTAwODBDNzk0NUU2QwAdBwEE gAEAGQAAAE5ldyBNSUIgRHJhZnRzIFN1Ym1pdHRlZAB3CAENgAQAAgAAAAIAAgABA5AGABQIAAAt AAAACwACAAEAAABAADkAIOKFKQ6tvgEeAHAAAQAAABkAAABOZXcgTUlCIERyYWZ0cyBTdWJtaXR0 ZWQAAAAAAgFxAAEAAAAWAAAAAb6tDdrZBXr+CRjnEdOKWgCAx5RebAAAHgAxQAEAAAAJAAAAVEpF TktJTlMAAAAAAwAaQAAAAAAeADBAAQAAAAkAAABUSkVOS0lOUwAAAAADABlAAAAAAAIBCRABAAAA ZwMAAGMDAABkBQAATFpGdXOEH28DAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/z AFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIM YGMAULMLCQFkMzYWUAunYwEwFCBHCdF0C4BncyxHCqIKhAqAQSBuB9F2BwSQAJACICBvZiBJslAG YGMgBGADAHQFsAMdgQXQSUIgZG9jFnUHgAIwIAQAIGF2VwtwC2ACYGUhoHQd1DwhAYBwOi8vAdA2 LkAxOTEuNTkjcDSgOC9kcmEBgC0IkMsAMCSAcBQQYy0gBSUwMGliLTAjoAzQdD6zHcUAcGQgE+AE IGIJ4XAgc3ViJcACQAmAIPsgQChAaCIwC4AOsASgFCAuLSQzBCAYIGcEAHRyhHkuHdtsc28sIaDv HqMg9itRKyEgCrEFQB9x/yiCH6QgshQQCIEEIB9wHdQfIPYEICciLHMnbC4gVB5oIYEg+iiBHdRE T0lzJIAm8GVwCfABACFRcAcXwR81LUNTQUtNUD8f/StRIm8jfySKBABha7RtcClAaSUyJbQwJiPt KktEClAoRmUG0AmAAQD7JwAKsGciMAWgAjADYAMgPxPSANAo4R2wIXAFQHNofQhgbCcAJ2Ad1CoQ AHFmDwSQGCEhoAQgQklOQeRSWStQbm8FQA6yKkvtCFBtL1QYIHEKUCoAMQEfHdod1AdhIaAm8Upv aMsLkB3pTkEAZTofkCcR4x7wKbFjZWke8CcABaDPQmUogDZAKHNGVDUgLiH/HvEfYEVFKIIAwTFQ HrAhoL8G4EaxIPAHkUDyGCBzM+DPJvEoUQdAAyB0eTNgLnL3SIId1ELVczEgRnUqEAiQ/ygzPPBI MiGBE9EdkAmAK1D8YnUFQEaSHdQT4CcAQPDCIApAY2sgeRQgTgH9H4B5CGBONghgIhErUDxA/yHR H/AiMSbwHdRGcAPwTDGrU4QFoHAuUmIA0GsqS9YtVvBEOEoJ8GsLgAQgV1g/WJMHYlMOsHASIXKv M+E2QB8xPyVqV9RAHXDbB4FZ8S5HcViYaAJANvIed12gJiBb6R3UKDYxSDMpIDewOS0cIDFBFlB4 NDMwNFidRqxheEZQXws3Hdp9YzAAAwDeP69vAAALAAOACCAGAAAAAADAAAAAAAAARgAAAAADhQAA AAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYA AAAAUoUAAPATAAAeAAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUAAwACgAgg BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMABoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAJgAggBgAA AAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADiF AAABAAAAAQAAAAAAAAALAAuACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsADIALIAYAAAAA AMAAAAAAAABGAAAAAAWIAAAAAAAACwBBgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAPE/ CQQAAAMA/T/kBAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////AgFHAAEAAAA7AAAAYz1VUzthPSA7 cD1UaW1lU3RlcCBDb3Jwb3JhO2w9RVhDSEFOR0UtOTkwNjAyMTUzOTU1Wi0zODQxMAAAHgA4QAEA AAAJAAAAVEpFTktJTlMAAAAAHgA5QAEAAAAJAAAAVEpFTktJTlMAAAAAQAAHMPDohSkOrb4BQAAI MAC4likOrb4BHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAGQAAAE5ldyBNSUIgRHJhZnRzIFN1Ym1p dHRlZAAAAAAeADUQAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZBRUIy NDZAZXhjaGFuZ2U+AAAACwApAAAAAAALACMAAAAAAAMABhBpIxr3AwAHEPsCAAADABAQAAAAAAMA ERAAAAAAHgAIEAEAAABlAAAAR1JFRVRJTkdTLEFORVdWRVJTSU9OT0ZJUFNFQ01PTklUT1JJTkdN SUJET0NVTUVOVElTQVZBSUxBQkxFQVQ8RlRQOi8vMjA2MTkxNTkxNDgvRFJBRlQtSUVURi1JUFNF Qy1NTwAAAAACAX8AAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZBRUIy NDZAZXhjaGFuZ2U+AAAAIr4= ------_=_NextPart_000_01BEAD0E.2996B800-- From owner-ipsec@lists.tislabs.com Wed Jun 2 11:52:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22336; Wed, 2 Jun 1999 11:52:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03845 Wed, 2 Jun 1999 11:44:17 -0400 (EDT) Message-Id: <3.0.32.19990602114033.00a39230@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 02 Jun 1999 11:40:34 -0400 To: Dan Harkins From: Shawn Mamros Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I'm attempting to codify the behavior of certain implementations. Some >people will not accept group 1 if they have group 2 configured but will >happily accept group 5. That seems to be correct behavior. Similarly for >variable length ciphers. If you're configured for 128 bit blowfish and >someone asks you if you want to do 448 bit blowfish do you refuse? If so >why? If not then where in the RFCs does it say that you can do this? In addition to the concerns about this that Tim Jenkins stated, I'll add one more: A site admin running a box intending to support many IPSec and IKE SAs (where "many" could number in the hundreds or thousands) might be concerned about the performance of said box when running stronger ciphers, or when running larger D-H groups. In particular, if one is handling lots of rekeying operations and is using PFS, then D-H performance could become a concern. I could see where an admin might be concerned that D-H will "take too long" if an implementation automatically accepts group 5 when group 2 is configured, with no means provided to change that behavior, just because "the standard says so". Performance tradeoffs may be just as important, and perhaps even more so, than security tradeoffs to some people. I feel uncomfortable legislating behavior that might fly in the face of what end-users and end-administrators want to do. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Wed Jun 2 12:38:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22655; Wed, 2 Jun 1999 12:37:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04163 Wed, 2 Jun 1999 13:21:41 -0400 (EDT) Date: Wed, 2 Jun 1999 13:30:33 -0400 Message-Id: <199906021730.NAA16539@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <319A1C5F94C8D11192DE00805FBBADDFAEB177@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some comments triggered by what Tim said: In a sense the discussion about how to handle "stronger" proposals is innocuous since it contains the word "SHOULD". On the other hand, it still implies that something is recommended and encouraged when it isn't necessarily a good thing for some implementations. Shawn Mamros raised the good point of performance: if local policy is to use group 1 and group 5 is proposed, should it be accepted? Or 3DES in place of DES? Extra security is not free. Saying an implementation MAY do this is fine, but saying SHOULD may not be. It isn't clear from the text that it is only talking about parameters of a single system. For example, while it's clear that group 2 is stronger than group 1, it isn't clear whether how groups 2 and 3 compare. (Safest decision would be that they do not, so if I want 2 and 3 is proposed, I'll reject.) By the way, in his comments Tim referred to "2DES" (meaning "two key triple DES"). Currently that's not allowed for; it would be useful to have that option given that some countries give special treatment to below-128 bit ciphers but not to 168 bit ciphers. (Yes, I know from a practical point of view the difference in strength is not particularly interesting, but it's easier to add an option to a protocol spec than to change a government regulation.) On the subject of lifetime negotiation, I agree with Tim. That case is clearly different from the others in that each side can enforce a lifetime on its own. If I need a 1 hour lifetime, I should obviously propose that if initiating, but there is nothing that prevents me from deleting SAs after 1 hour even if 2 hours were negotiated. Since you can get the desired effect (lifetime limit) unilaterally, I see no reason to refuse such a proposal. It's fine to allow it to be rejected, but the draft *requires* it to be rejected and that's going too far. paul From owner-ipsec@lists.tislabs.com Wed Jun 2 12:48:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22787; Wed, 2 Jun 1999 12:48:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04204 Wed, 2 Jun 1999 13:31:32 -0400 (EDT) Message-Id: <199906021739.KAA26363@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Protection Suites in ... (was RE: Comments on draft-ietf-ipsec-ike-01.txt (long) ) In-reply-to: Your message of "Wed, 02 Jun 1999 09:35:01 EDT." <319A1C5F94C8D11192DE00805FBBADDFAEB15C@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26360.928345191.1@network-alchemy.com> Date: Wed, 02 Jun 1999 10:39:51 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A protection suite is not a bundle nor is it any subset of a bundle. You may wish to refer to it that way but I will, respectfully, say that you're wrong. A protection suite is an atomic offer. The whole concept of this suite was that very early on (perhaps before you took part in this group) people wanted to mix and match offers. One offer was 3DES and MD5 and group 2, the other was CAST, SHA, and group 1. So people wanted to accept a mix of 3DES, SHA, group 2. That is not allowed and the concept of the protection suite was defined to limit that. The protection suite is an atomic offer which must be negotiated in its entirety. RFC2408 is somewhat confusing. Maybe not to you, fine, but to plenty of other people. I'm attempting to rectify that situation. I have no idea whether RFC2408 will be revved but I don't want to leave the confusion in place. You seem upset that the definition explictly disallows your broad idea of what it was. Can you explain how this impacts your implementation? Are you somehow constrained because the term "protection suite" does not refer to a bundle of offers? Dan. On Wed, 02 Jun 1999 09:35:01 EDT you wrote > > > > On Tue, 01 Jun 1999 09:42:47 EDT you wrote > > > > > > 1) Use of the term "protection suite" > > > > > > I am both concerned and confused by the use of the term > > "protection suite" > > > in this document. As it turns out, this term has been > > re-defined from that > > > in ISAKMP (RFC2408) to refer to only the services provided > > by a phase 1 SA. > > > (See section 3.1 of draft-ietf-ipsec-ike-01.txt.) > > > > The abstract of this draft explicitly says that where there > > are conflicts > > it will be supreme. > > Even over RFFC2408? We really need that document to be updated > then. > > That's not my point anyway. My point was that it appears that > "protection suite" is being re-defined in a completely different > way than RFC2408, and I don't see why. > > > > > > On this issue, what is the purpose of adding any new > > definition of these > > > services? If that is necessary, why change the existing > > definition of > > > protection suite? Why not find a term that won't result in > > ambiguity and > > > confusion. > > > > > (Above are my original questions; I didn't see a response to them.) > > I think my understanding of your position would be clearer if > the above questions were answered. I'll expand them: > > 1) What is the purposes of defining any new term for the set of > proposals and attributes offered for phase 1? > > 2) If question 1's answer is valid, why would the term "protection > suite" be chosen when it quite clearly (IMHO) already has a very > different and clear definition? > > (I realize that it's not clear to others.) > > > > To clarify the existing definition of "protection suite", > > see section 2.1 of > > > RFC2408: > > > > > > Protection Suite: A protection suite is a list of the security > > > services that must be applied by various security protocols. For > > > example, a protection suite may consist of DES > > encryption in IP ESP, > > > and keyed MD5 in IP AH. All of the protections in a suite must be > > > treated as a single unit. This is necessary because security > > > services in different security protocols can have subtle > > > interactions, and the effects of a suite must be analyzed and > > > verified as a whole. > > > > I was under the impression that this was confusing people and > > hence decided > > to spell out what the term means to IKE. If DES in ESP is a protection > > suite what about the lifetime of the ESP offer? Is that part > > of the protection > > suite as defined by RFC2408? That's not explicitly spelled > > out and people > > asked me about it. I happen to agree with them. That text > > doesn't really > > capture the meaning of the term and is open to interpretation. > > If clarity of the existing definition is the problem, then that > is what should be done. The existing changes will create more > problems by re-defining it completely differently. > > Here's my definition of a protection suite: > > "A protection suite is an SA bundle in which the SAs in the bundle > are negotiated using the same SA payload in the same quick mode." > > That definition is entirely consistent with RFC2408. RFC2408 also says > that the individual SAs in a suite must be treated as a unit. This > means that when one SA in a suite expires, all SAs must be expired. > It also should mean, and this was demonstrated at interoperability > workshops, that the encapsulation applies to the SAs as a group, or > stated alternatively, to the suite as a whole. (In other words, there > are no extra IP headers added between the headers added by the > individual SAs in the protection suite.) > > > > > > Also see the discussion in section 4.2 of RFC2408 and the > > example in section > > > 4.2.1 of RFC2408. All of these quite clearly indicate that the term > > > "protection suite" applies to phase 2 SA establishment. > > > > > > While I agree that it does not necessarily preclude phase 1 SA > > > establishment, I do not see the need to apply it to that > > case only, as > > > draft-ietf-ipsec-ike-01.txt appears to do. > > > > The DOI defines what IKE negotiates in phase 2. Would it be > > better if I > > called a protection suite "an collection of attributes that > > are negotiated > > as a single unit"? And then said that during phase one the > > components of > > such a suite is and leave it up to a DOI to > > define the term > > if it so chooses? > > That might be preferable. But to me (phase 1 aside), that's what > RFC2408 has already done. > > And I still don't know why you want to apply the term to > phase 1 anyway. > > > > > > Also, the use of the term "protection suite" is a very good > > way to refer to > > > a subset of SA bundles where the SAs in the bundle are > > negotiated using a > > > single SA payload. This allows them to be differentiated > > from SA bundles > > > that are negotiated by the effective recursion of policy to > > packets that are > > > IPSec processed. > > > > This is a slippery slope. If I now state that a protection suite is a > > subset of a bundle of SAs then what sort of subset? 3 offers > > out of the > > 5 in the bundle? Is that a protection suite? And I don't > > think that's the > > correct meaning. Even if all 3 of the five were ANDed > > together, it's still > > 3 protection suites. Perhaps you can come up with another > > term to describe > > a subset of a bundle. > > The protection suite is a result of the negotiation. If I propose > > (IPCOMP and ESP and AH) or (ESP or AH) > > to you, I'm offering you a choice of two protection suites. Hopefully, > you'll respond with 1 of those, and the result will be that we create > between us a single protection suite. That protection suite will contain > either one or two SAs. > > What's slippery about this? > > > > > > As such, I think the use of "protection suite" in this > > document is confusing > > > and should be changed to align with RFC2408, or it should be removed > > > altogether. > > > > RFC2408 is confusing and I was asked about it many times. I'm > > addressing > > that issue. > > I've no problems with that: only that I don't think you're clarifying, > but changing. > > > > > At the last bakeoff someone was passing a message ID in the > > SPI field of > > an notify message. This was justified by noting that nothing > > expressly > > prohibits such behavior. When things reach this state I think > > we've gotta > > spell everything out in gory detail and RFC2408 doesn't to the job. > > I agree. Is there someone working on a next generation ISAKMP document? > > > > > Does my suggested modification come closer to what you think > > it should say? > > > > I don't know. I don't think we're really that close in what we think > a protection suite is. I think it's an SA bundle where the SAs in > the bundle were negotiated using the same SA payload. I think that > you think it's a collection of proposals (including transforms and > attributes). To me, that's still just a proposal. > > To try and further clarify why I think this is important, I'll elaborate > more on the differences between what I call a protection suite and > SA bundles in general. > > To say that you support SA bundles (in general) means that you support: > > 1) Iterative SA negotiation with both a single peer and multiple peers, > and > 2) Protection suite negotiation. > > To do 1 above is a significantly different implementation issue than > to do number 2 above, and a significantly different negotiation method. > > For example, a generic SA bundle that results in ESP and AH applied to > the same packet could result from a policy like the following: > > H1 --- SG1 ----- SG2 --- H2 > > H1 <-> H2, all protocols : (ESP) tunnel > SG1 <-> SG2, ESP protocol : (AH) transport > > For number two, a similar (but different result) comes from a policy of > > H1 <-> H2, all protocols : (ESP and AH) tunnel > > Both are SA bundles. The second is also a protection suite since it was > negotiated in a single SA payload, and both SAs live and die at the same > time. In the first case, the two SAs are independently negotiated and > live and die completely independently. The AH SA might also carry traffic > from other packets that ended up with ESP protection from hosts I didn't > illustrate above. > > Those rules of negotiation and treatment of the SAs is important, and > needs to be clearly spelled out, since it is different. This is why > there were so many issues at the interoperability workshop with respect > to IPCOMP: Does the IPCOMP SA proposal in the offered protection suite > have to have the attributes of the protection suite? (I'm offering this > question to illustrate the protection suite issue, not to start a > discussion on this issue in this thread...) > > Has this clarified the issue for anyone??? > > Tim > > ------_=_NextPart_000_01BEACFC.B728CD50 > Content-Type: application/ms-tnef > Content-Transfer-Encoding: base64 > > eJ8+IgMNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy > b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGAAIACQAjAAEAAwAOAQEggAMADgAAAM8HBgAC > AAkAIwABAAMADgEBCYABACEAAABFOEZEN0EwNUU3MThEMzExOEE1QTAwODBDNzk0NUU2QwAzBwEE > gAEAUwAAAFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFm > dC1pZXRmLWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAfxsBDYAEAAIAAAACAAIAAQOQBgBoGAAA > MQAAAAsAAgABAAAACwArAAAAAAADAC4AAAAAAEAAOQCwfhm3/Ky+AR4AcAABAAAAMAAAAENvbW1l > bnRzIG9uIGRyYWZ0LWlldGYtaXBzZWMtaWtlLTAxLnR4dCAobG9uZykgAAIBcQABAAAAGwAAAAG+ > rIxIREQxcCkYVRHTk1AAEEtqqNgAGnh00AAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAA > AB4AMEABAAAACQAAAFRKRU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAAD2EgAA8hIAAJcoAABMWkZ1 > 1ufIvwMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwEC > AGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6dj > ATAdBgB0AxADIBewbmcsmCBidQVAAiBseR4hwCB0aGUgcANgDrBGYx1AHoFzdWkOsCC7BAEKUC4K > ogqECoAtISDTIGQHYSBKCfBrC4AEIE8ibyLDB2IdMGVwEiFymnAFsGEfUiBkdGoiBO5AHUAHgSQh > LgWgIdAix4JoAkBwOi8vdyfQBi4mCiBkKDYxMymgIDU5OS0cIDEWUCB4NDMwNCLNRmFoeDogKTs3 > IGogaj7WICEhISBPBRBnC4AHQMMF0AeQc2FnZS4zLbbWRgNhK5BEA5FICsAiI4ZbAMADEHRvOmQT > 4RMlswfAdHcFsGstQQJsE9BlbXkuQ088TV0ttgZgAjArkEp1Km4e0DEd0DEpoDkggDg6MDggUE0t > tp5UMdAjwiHmLbZDYyuQIwUgFBBjQGwEAHRzdSgBcwtgYjiwKKc0IXXOYiWAH0ArkFJlK5AIUN5t > B4ACMAQgHoFkJLABgL4tCJAAMDvgOCI74GsvcOwwMSgADtEoHZIpcC229T3OTwOgVApQHdA84DSS > QTUUMDk6NDJAoDdAIEVEVCB5CGAgXncfAi22PiguEDEpcFVbFBAeIGYeow6wciHQIo0e/iJB70JR > SSBhIdDLBuAesCAFoG5jBJEJgM1GwG5H0EdRZnUUEEfQ/mIeYB6ySHFDiy22RF9FaY8LgB6hBAA7 > gG9jdTsC/i4QwAQgH8AeoAhwBjEIYL50HdBMo0QDE+AEIGIJ4fs+NxggLQEBC4BHwQNSHqEDJMBL > 20lTQUtNUMEroFJGQzI0NZApcPsxwFBBZhKBU3EeMx6yFBD8cnYN4AeRHvFU8AEAR9B7LbZIwWEe > 4E9BNNEGAEE7IFVCQigGYFSiH0QzLk8/0EORO588qC4pPc5U+x7BORF0JLAfQEOETMJZUn4gDsAL > UA3gH8AeUS9Aef9O0VFhQYAewBggHqJfQS22/wrAHtBIMl3xOKAttk3BA/D/HWFPgB+RHvAzQCBA > PjUgZHxFdk+hVXASgVLgUvQ//CBXHtAYIAdAHlE0wEfB317DTPZTYmIhYmBkJMAJgLslFR7AbiBb > XBAkwCcEINpuHxAgM1Ae4G8LgAVA2QBweXdegE1wTWm2amDjXqVNwWFwcGUgFABRSd1KvyIf8U9x > C4BnUEpMca9WkCaRC1AUIGUeUWQGkP9TwTRRIGRqYVFCA6BS5R3Q50fyRrBM8G4nBUAUEB7Q/18Q > M2AtXEV4P0FMoyADHdB/XxBrol6iHtEIcCSQQ2Rh/mRwkG6xajFlcQfgLbZQg38fwB9iQ5QUEEV4 > VMZkwEmfQ6J2dDTAVREvQHJ5djL/HmAT0R2wX1NdsTiBbqJ4v/95wkV4Hv5kwX0RaWJQoUfR/0P0 > XsRzExggH6AxsExiX9f/BtAuoB+xVnFIAEV4SDQfYfNXWCBqKEEG4GOwYENpoTsFsC6lcQpQfiEC > IHM7/3LSVZBzJlaQg4EkkACAQ+H7U4AesW1a9iBkRrBMoSIQ/2mSNLAEgSZAR/FuokORQVH/BcB3 > QXmEMrCDsEihYHFwIP9gUQXABpBnh1xBiDKJd0GAl18yAHGSYmRNcEknHWH3XcFH8ovSOiBqQyGB > kHZ//ztBWSF5Q3gJRAMCEFPhVJP/XMIgZB7xd0EHQAQgR/IkwP1cgGkd8ZZzcMJQ4QWxVrX6PyBq > Milwe6GJdjTgaTH7krRuQnYHQFWQfOSPlEPP9yTnbeWP8mh3UY9xZ/FNsg+JcB/CkCMeUShJTUju > TylwB0BlEWQeYE9CVpD9ZAF5IGRwl0fkkDJ5KZw786PwZQNpel9Sa6NpNabE/1QCX3I4sIwrQkI2 > YJARCsDfBpBI1H33eTxtLyId0C22+3NiWFYyWONFeFLllFVCTL0iwVAfCDoAH8ErkEGAb/9uQlaQ > OHJDhjgxCHGFELM7+1THXsNtSHAFQGIhbAE4cP9IlJ7QBRAIYAQgt2a1M00A/wbwOLArQQWwszsO > wEbQcBF/coG1P2mQcZFHUQCQtsRE3kUF8C22CfAFAHkFMB9i51IyUrDAUFAssztH8jywInlHwU1E > NcGlQUj/TXEdYUOVvkhNoW+ivvW5pP+zO1yAZSBnUUbApQIAkB2w/3AgjZEfwLxhXBB1s3xIT3H8 > Y2FJMrdvuHtMcaXou0+/BCDK8AOgE+CIQR+gYl4w/8csafEEkFyhicJyhH2zcLHfYPF3g8ZcR+EH > QHmpEEfT/7M7ZAEGkLpSpPNfEAbwIEb/PihGsGtCjaMeowdwYnEEEP8fYl7DTKNrQoYVbrFsIJmQ > /8kRR/IttmfxR4B5IV4QVaH/LbZTcYswcFDEwR4BdlOf58cHgAYiU3FJS0WTMcAk/0xxwhG2RKCO > euEfs3ZTkWH/HgEesjhwU8AmAkOG4LKbA/97gV6lCrEFQS3FxO/h7E9R/1CGSMFS5WTAaPldyt3C > Vbnv3hJH8tsEX9dzPLBH0OQR/+MUyWJGsBPgbBEekVOAL1D/CdFhwUchi9PqA6ARDtJ+lv5vB5CD > RGUyLbbK8AUwCHD/fZTfMo5Fn+dH8kzBmZDvZP/Q82JxAZAfUiBbe6GsY4UR/0OVrS/Bgna1A2AC > YDNAToLv72JRZ9nyXtJzojCPtXMB/2KxXBJ9931EkkEdUgUAyCL/aZAFsEHV+sVPYR5gUFZuot9N > wW/vNFEeUCBbSF8xaTHfaaF5PL4vOqAgaiK1L7Y0/7SRB9Ad8EgAyRFMcV8QDeD/8FNXIcXzHrIJ > lGzEYFI0wP5nCBAQ8MhC2qRUg0bQCrJ95dF5F7B3wAsGDdOjEWN7jVEVcS5FZWiY+Z00UWn/GCAe > Ub+VZnLwI1LlTXBS5X2kUXPdkV6BZ4bedYIhaf1VgXUu4QrV0w7IC8lEybL/bMTfNV7VY9E0wQlh > F1ldwf8ScdGixLEK0tOGHHSTIIyV/2oRFPP81N8y0bbZ9ejQ/9D/v7BcgchDg9JEAfXBJLCEwP84 > cMu2MrL8wTgg+zLeddxB/2wAg6H207oF33MKlqTz79D9uwBw+zC8po3xyEMxsEeR//bRY7CjwPsx > JhToR9ZWo+HnY9FfcoMRcmQj418xC+n/U4DxMVlQwdLm8HfAjdF3sv9IkjKRT5Lm4i2tSNP75RZ/ > /+bsvuSrHrM4xKAVAlgh5uI9ikBzTRDZJExxWFY0Lv4yQ4IUZ9HlwIe9pDZZszj/NxFY5BPXxKhW > 4aMcMOLPMP/ocRXXRAKzOK6fbjAliVa03zcwCWGdge5gtqFoTTOGvf9F0oGQYeDnAEax79NrhvHy > n2lTfFZh4LuysKBsdejQ/1apszhCK/swcuJpUzU2ZYT/76G6IT1xZpNew/LYd2JUQf9ygWEXeRFZ > X1pna/hTgEWQ89bPXBJET4ohbyP8Vd/B7wx4FzNBde7gV4+ja9HT0f+zNi6B0RGQkYoQ8tjrowXf > /ecAIs9BzuFwIL6Ud5KaaK9L+wxN7VjIrCJkwEGT5P2+0WHcwGXFzjHa0pvTG1L/OEoCIhtRcQCW > g+HoCmHGRuW2UTz68GFoY5aEgfVh/5AxiEFr0WcQ74NSA92Bfov/fZT1A7M2VoFr0RUBoiGWUuuc > OxETbYkAaLnD2PFwwbtCUf2RQuNCFRDuMShHdvvaMNzBKSP0ngF2UgdkFGb/pOOkdf1jlGpeIoog > fiHEsf1zBGtF4HiQfQKOsdfhE1H/Swef587AmRVsZnhA2iADfP+zsTRM+zMNIeQnoC5ARrZT/6VC > JvBo4NuYdUHdcmrzdAf7hdLGQmKYtAlY/FKScgqf7wmziHKzNgyPYbM4yNUOKP8ZlBzycfD6Y3Py > /SMC5lwc/maZgPUwfaizOF8DW40wJP/SRSjhASHOIdkz9JGZoOrx/3tzszbl4A/A9rC5JVuBszj9 > weBTsKBXwkZCHldROsnU/10hIsBQAcqhkLD1wd/zSaD/ceIn84glV8+2Q+HofSYtUP8JlX1z+mOi > cvySm5C2030E/eVAM5r0tmDr+vSUszbD4/9/aOVIkv+bMXC0cXTdB8nA3m4P0G1VmanO4HJG8blx > +/Qk7uBF1ZCiwVnhxLGYIh/m01JwZOEusFuRQU5E/+vJzsD+0Cvy+zCpk3ETdeb3mCCTHrxRUCIw > 7yG2YHJi/88yAiHJIWVQ8CNysCsk3Qf/c9Qg8TXQWjHtSJTf1qcQtv8yL7Y12QElALbXgNb28pGk > H61xYVBHoHWKKuBQQ0++TcRA9VLgsvVSxGApJ2H/KtDks1Zgs0F1it2BcmFJgf4n9TDk8w1ScmIt > UGjBuPHv9IMjYK1vvFFI9cHakPKh+8JFcmEnxLHZAWFR1HDwI/87A/BAaPHRuK7V/xMYUhrD/zzx > yBMHZC6G2qBdGDJP8MS/rX//FDbgKAA9kAdkZROR/1ZRG1KzgbdyfvFv60Qw6jP/kLfjFhMQaTs0 > K6SRYpFJgv+eZneXeL95wQ7i4PHxeM4g/0Ky4OLaZ3xJsxH8yP6USuT9IsBnChETmSdSaFP81+/g > ///Q1ZDUuShho9WPDxRmzUr/9UPX1O3U7mZsAHUR5tDkAf+4sbWiWwcuMK7RzcpFFI7A9nX9kfc7 > J2ThLOEAd/Al/VoAOk0DXvSdZp5kueJbkfn4I2Z5DVG5dVpR/oSgorvHT3YTQT5U+DAdomHt8P+1 > 4WiBbBAbUiDCDlDZ4ybR79iBDdD+0EmQRAsGdeaz0P9JoFJw65AY4PSQWwcb0EXh7+Ah5baDpSDC > ah2RhUBOkP8wA+jSDWNfIaiyDVI4iPaR/47AEqGL91fgIIAioIzBYoP/z1Bu4BagJ3BUsftkDVGu > kP/ycQpjroGSRMlWetcEgGTh3wyhKABh+FAQO/FlejLsFP/XoxvQeoDGYVJQwtH/QGRy7xRmRZLe > 0yYUavrgb+tElf/YsfpjW5HkZyNx9IMb0htgX0/B/tAbYCFxQBJJCWBL77JRzLbHP3YEREWiBMEX > oP5no+ATIR+xEADqoT3RQBL/p9M9EGjxfAKWxHJi8ZzRqP8VMWk11Jb4RnF42LHeq/Jx/1uRveG5 > QV70ALMJ9L10nmP/C+XBP65xBaKeZKRjWPF9p/9+TzQ1f2mik4DfKYM5IILs/8lYbeYBqAt0WR2w 1B8RKtDfG8BHEutjTkAhQGYncN0R92RxLEVaFynA0WvybTdxFP/qYpvUFKOsbEvRxmKzEc2g/5dA > qOLf5XITyViQNNhwYVD/l0BysbWC8+LjkMagIXKxpP/SkFuRNuE1dIVURkEud1LU/1czm98p8haG > fan1AvtzGf//A2Fe9HJiwfBQAJcyfakVEV8lBrNgoGJalScZOnWKMf2zYEl4YQABZOF9oa+5usS/ > xqCocr9XROBWYLMCba8BW8YgLkVz4IUWdzKzYFD/V+6vuhodScFsscagZOJdBP/QYP/DzRA9YYU3 > HbLc8c0B/wAE2wNtQsMFUHNKoMzgz1D/VmBB0DQju8Q0vzXHLIpsEPe7cY72saRGs4Hs8BBgL1H/ > u8H7VIuAC+neQ67UDVOyyP9LI+rCfCYQF4x0zWHPEq7V/4ajInGLZItw5ACh9FkxcfDXtjEqu3ZQ > SDQALUcgDSCeR0cDRzM5EEciSDJGG/lG8TwtdkBIgLvAoWMiknfMwItgrpAg3dCzsrNgdP9/sMPw > pPVHYkmiSAG7wLLC/0p2dlBLErNCFcMd4jy+OKX/t3E+Is3AalDf8Shw4PI1uP+u1LNgp9KukEQM > 6AZJD0of70sksvdLqrGkQi2jW5F9qP/A0vmhE9C6koPjaJEif/mh/xUhZPPqIbGkiMn1Ab9Hgwj/ > u8Qtkw0yi3Bk4bMChTB/8f/jNBBSDaXYcdix5oSiQC/A/+ERdLF3VMRViHP1AKogLnD/ZTE1Y4jJ > Fndgu6fRL1HxQD/eEWUrWhRBAX2hUSBnaP+IYVsi//CgANhBKQCFUIuA/7GkhqOoxIx7ZXKBYag1 > TTafE9WGo7uBjMGdYWlkcZF/saQY0epxHxI0FKxtB+Jy/88Q/pHKUSyKu+O94szzodX/DTMdqxZ3 > w/Dq0J8RhOMHwP2gcHLeEfOz6tHXobvAXJf/roGFN4Ol6fIckA2niJGik/9bMdgTN0OukeM09QCp > oZFh9ykA7mCLcHQcYfpR0dGoNf+6UhPRtMeyFN3Q/nO8IrIV/xCiGZXmZrXj6tFbjrGk7yH/N4Ez > 4IW0vDEXCKHGnA8ocPe1q8bysaRxfYHK89ABcRn/h6+uRNshu8Cosfci8RGXQf+UVf+wqkDNsM3A > FBLLxTdEv8u23kDwYTyQkWC0W0jW8f/L49/kQXN+AjdTFhHokbZwvcPwP5TQrHvYcLGkfZZgAAAe > AEIQAQAAADYAAAA8MTk5OTA2MDIwMDA3LlJBQTI0NjQyQHBvdGFzc2l1bS5uZXR3b3JrLWFsY2hl > bXkuY29tPgAAAAMA3j+vbwAACwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAWACCAG > AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAA > HgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAMAAoAIIAYAAAAAAMAAAAAA > AABGAAAAAAGFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAA > AADAAAAAAAAARgAAAAARhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAI > gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACYAIIAYAAAAAAMAAAAAAAABG > AAAAADeFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA > AAAACwALgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAAyACyAGAAAAAADAAAAAAAAARgAA > AAAFiAAAAAAAAAsAmYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwBBgAggBgAAAAAAwAAA > AAAAAEYAAAAABoUAAAAAAAADAPE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD///// > AgFHAAEAAAA7AAAAYz1VUzthPSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9RVhDSEFOR0UtOTkwNjAy > MTMzNTAxWi0zODEyNQAAHgA4QAEAAAAJAAAAVEpFTktJTlMAAAAAHgA5QAEAAAAJAAAAVEpFTktJ > TlMAAAAAQAAHMBB3Frf8rL4BQAAIMFDNKLf8rL4BHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAUwAA > AFByb3RlY3Rpb24gU3VpdGVzIGluIC4uLiAod2FzIFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRm > LWlwc2VjLWlrZS0wMS50eHQgKGxvbmcpICkAAB4ANRABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx > OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAAALACkAAAAAAAsAIwAAAAAAAwAGEA9+ > 1XkDAAcQmxoAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABTVElMTExPTkcsQlVUT05MWU9O > VEhFUFJPVEVDVElPTlNVSVRFSVNTVUUtLS1USU1KRU5LSU5TVElNRVNURVBDT1JQT1JBVElPTlRK > RU5LSU5TQFRJTUVTVEVQQ09NSFRUUDovAAAAAAIBfwABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTEx > OTJERTAwODA1RkJCQURERkFFQjE1Q0BleGNoYW5nZT4AAACnsA== > > ------_=_NextPart_000_01BEACFC.B728CD50-- From owner-ipsec@lists.tislabs.com Wed Jun 2 13:42:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23191; Wed, 2 Jun 1999 13:42:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04266 Wed, 2 Jun 1999 13:42:29 -0400 (EDT) Message-Id: <199906021750.KAA26407@potassium.network-alchemy.com> To: Shawn Mamros cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 11:40:34 EDT." <3.0.32.19990602114033.00a39230@bl-mail1.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26404.928345822.1@network-alchemy.com> Date: Wed, 02 Jun 1999 10:50:22 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's why it's a SHOULD not a MUST. People can continue to refuse offers of encryption algorithms with a longer key length if they wish. They could even panic their box upon receipt of such an offer and they would still be RFC-compliant! I just want to expressly state that it's OK to accept things that can be perceived as being more secure for attributes whose values can be a range since some people thought that that was not allowed. I'm not legislating any behavior. Dan. On Wed, 02 Jun 1999 11:40:34 EDT you wrote > >I'm attempting to codify the behavior of certain implementations. Some > >people will not accept group 1 if they have group 2 configured but will > >happily accept group 5. That seems to be correct behavior. Similarly for > >variable length ciphers. If you're configured for 128 bit blowfish and > >someone asks you if you want to do 448 bit blowfish do you refuse? If so > >why? If not then where in the RFCs does it say that you can do this? > > In addition to the concerns about this that Tim Jenkins stated, I'll > add one more: > > A site admin running a box intending to support many IPSec and IKE > SAs (where "many" could number in the hundreds or thousands) might > be concerned about the performance of said box when running stronger > ciphers, or when running larger D-H groups. In particular, if one > is handling lots of rekeying operations and is using PFS, then D-H > performance could become a concern. I could see where an admin might > be concerned that D-H will "take too long" if an implementation > automatically accepts group 5 when group 2 is configured, with no > means provided to change that behavior, just because "the standard > says so". > > Performance tradeoffs may be just as important, and perhaps even more > so, than security tradeoffs to some people. I feel uncomfortable > legislating behavior that might fly in the face of what end-users > and end-administrators want to do. > > -Shawn Mamros > E-mail to: smamros@nortelnetworks.com > From owner-ipsec@lists.tislabs.com Wed Jun 2 14:25:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23602; Wed, 2 Jun 1999 14:25:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04472 Wed, 2 Jun 1999 15:12:03 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB3C7@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Protection Suites in ... (was RE: Comments on draft-ietf-ipsec-ike-01.txt (long) ) Date: Wed, 2 Jun 1999 15:22:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 2, 1999 1:40 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Protection Suites in ... (was RE: Comments on > draft-ietf-ipsec-ike-01.txt (long) ) > > > A protection suite is not a bundle nor is it any subset of a bundle. > You may wish to refer to it that way but I will, > respectfully, say that > you're wrong. A protection suite is an atomic offer. The whole concept > of this suite was that very early on (perhaps before you took > part in this > group) people wanted to mix and match offers. One offer was > 3DES and MD5 > and group 2, the other was CAST, SHA, and group 1. So people > wanted to > accept a mix of 3DES, SHA, group 2. That is not allowed and > the concept > of the protection suite was defined to limit that. If you define a protection suite as an atomic offer, and that atomic offer may contain IPCOMP and ESP and AH (with the assorted transforms and attributes), then you and I are actually pretty much in agreement. I would actually call it a protection suite proposal or a protection suite offer. But in phase 1, why not just call this an SA offer? Could you not just define what an atomic phase 1 SA offer is without giving it a new name? > > The protection suite is an atomic offer which must be negotiated in > its entirety. RFC2408 is somewhat confusing. Maybe not to > you, fine, but > to plenty of other people. I'm attempting to rectify that situation. I've already said I agree with this attempt. But my original points were: 1) RFC2408 quite clearly refers to protection suites as being part of phase 2, both from the definition and the text and the examples I referred to earlier. 2) Your IKE draft quite clearly only refers to protections suites as being part of phase 1, and never mentions them in a phase 2 context. (More on that below...) If you're attempting to define what is an atomic SA offer, then call it that. Call it a protection suite offer to make it clear that the offer may propose multiple SAs (in phase 2) if you insist on using in phase 1 as well. > > I have no idea whether RFC2408 will be revved but I don't > want to leave > the confusion in place. > Re-using a term in what seems to be a completely different way when RFC2408 will also be valid will still leave confusion in place, even if you state that the new IKE supercedes anything contradictions. We have the opportunity to clear up this confusion without contradictions between documents. Wouldn't that be a better route? > You seem upset that the definition explictly disallows your > broad idea > of what it was. Can you explain how this impacts your > implementation? Are > you somehow constrained because the term "protection suite" > does not refer > to a bundle of offers? > > Dan. I've tried to point out the real differences between SA bundles negotiated using a single SA payload and SA bundles negotiated (functionally) by iteration. These differences are significant, and I think they should be stated explicitly, because this is where there is a lot confusion. Remember the debate about how to create SA bundles where some people said that separate negotiations of SAs with the same selectors and different protocols created a bundle? Also, while the handling of a single SA is relatively clear, the handling of SA bundles negotiated with a single SA payload is not. Based on what you said above, I think you're saying there is a need to explicitly define an atomic offer that cannot be pulled apart. I'm saying there is a need to explicitly define an SA bundle where the bundle is a result of an offer using a single SA payload. It seems we both like the term "protection suite" for that. I'm basing my case on the fact that RFC2408 (which may or may not be updated) already defines a protection suite as an SA bundle that was negotiated in a single SA payload, and even provide examples of exactly that. And intuitively, the term protection suite makes sense: it's a suite of SAs providing protection. In your case, protection suite means a suite of offers? Without the word "offers" in what I think you're defining a protection suite, it doesn't work as well. Things like this help add clarity: minimal overloading of meanings and reduced ambiguity. Maybe that was not the original intent of the definition of a protection suite. But new ipsec implementers should only need the RFCs to implement; the history behind them should not be a requirement in order to implement them. In any case, here's a proposed solution: If the definition of protection suite is expanded to allow it to mean both an atomic offer and the result of acceptance of an atomic offer in both phase 1 and phase 2, and I think we'll effectively have agreement. (Although I still think an offer should be called an offer, not a suite.) Alternatively, we could call what I want to call a protection suite a "super SA" or a "multi-SA" or something like that. No matter what we call it, it's still a subset of an SA bundle. We still need explicit rules about handling a protection suite, to reduce confusion about expiration when the protection suite contains multiple phase 2 SAs. Another thing which may be causing problems here is what seems to be an attempt to make IKE completely independent of the things it creates. That would be fine if we had a document that described SA management. But the only thing we have that attempts to deal with any of that is my re-keying document, which is not complete from a total SA management point of view. There are also private implementations of keep-alives, which are also part of that issue. So in the absence of a true SA management document, I tend to want to see the missing stuff placed in IKE, because that's who created the SAs. And to evolve this back to the protection suite issue, the management of SA bundles that are created with a single SA payload is different than SA bundles created by iterated negotiations. Therefore, I want to see that explicitly written somewhere. And I don't want to continually say "SA bundles that are created with a single SA payload". I want those to have their own name. And since that's what it looks like RFC2408 calls them, that's what I want to call them. Tim From owner-ipsec@lists.tislabs.com Wed Jun 2 14:43:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23743; Wed, 2 Jun 1999 14:43:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04530 Wed, 2 Jun 1999 15:51:45 -0400 (EDT) Message-ID: <005301bead33$0255b020$2e05010a@HEG> From: "Kalyan Chakravarthy Bade" To: "Dan Harkins" Cc: References: <319A1C5F94C8D11192DE00805FBBADDFAEB177@exchange> Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Wed, 2 Jun 1999 13:00:20 -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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The authentication method value for DH less RSA encryption is 6 and is clashing with the value of Encryption with El-Gamal. Which one has to be changed ? Kalyan kalyan@intotoinc.com From owner-ipsec@lists.tislabs.com Wed Jun 2 16:09:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA25025; Wed, 2 Jun 1999 16:09:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04672 Wed, 2 Jun 1999 17:00:49 -0400 (EDT) Message-Id: <199906022109.OAA26844@potassium.network-alchemy.com> To: Paul Koning cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 13:30:33 EDT." <199906021730.NAA16539@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26841.928357747.1@network-alchemy.com> Date: Wed, 02 Jun 1999 14:09:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The text specifically discusses "certain negotiable attributes [that] have ranges or multiple acceptable values." It's not discussing the relative strengths of different algorithms. Let me try a different tact: Does anyone think that an implementation should never accept an offer which contains a variable-length encryption algorithm which includes a key length greater than what it would have offered had it inititated? I'm assuming the answer is no. So I'm trying to note that such behavior is acceptable. You don't see a reason to refuse a lifetime offer of 2 hours if you're locally configured for 1 hour? Do you think that all vendors MUST accept any lifetime then? Your behavior is not prohibited, just that it is also not mandatory. The reaction to IKE is curious. Some people feel that every possible behavior must be explicitly spelled out. Remember the debate about the vendor ID payload? Some people said, "should I drop a connection because I don't recognize the peer's vendor ID payload? The correct behavior is not described in the RFC." Other people think that if it isn't prohibited then it's allowed. Like the vendor that was passing a message ID in the SPI field of a notify payload. I kinda thought that the SPI field was for SPIs but since it's not explicitly prohibited then this vendor thought it was OK. In attempting to satisfy both camps-- some want the freedom to cross the street by themselves, others want an escort-- I added text to allow what seems like perfectly common sense behavior. Regarding lifetimes, if the text in this draft is not acceptable than what about the text in section 4.5.4 of RFC2407? Don't people have a problem with option 1? So let me ask the entire working group: should vendors be prohibited from accepting a key length greater than what they have configured? Should they be prohibited from accepting a stronger group? Dan. On Wed, 02 Jun 1999 13:30:33 EDT you wrote > Some comments triggered by what Tim said: > > In a sense the discussion about how to handle "stronger" proposals is > innocuous since it contains the word "SHOULD". On the other hand, it > still implies that something is recommended and encouraged when it > isn't necessarily a good thing for some implementations. Shawn Mamros > raised the good point of performance: if local policy is to use group > 1 and group 5 is proposed, should it be accepted? Or 3DES in place of > DES? Extra security is not free. Saying an implementation MAY do > this is fine, but saying SHOULD may not be. > > It isn't clear from the text that it is only talking about parameters > of a single system. For example, while it's clear that group 2 is > stronger than group 1, it isn't clear whether how groups 2 and 3 > compare. (Safest decision would be that they do not, so if I want 2 > and 3 is proposed, I'll reject.) > > By the way, in his comments Tim referred to "2DES" (meaning "two key > triple DES"). Currently that's not allowed for; it would be useful to > have that option given that some countries give special treatment to > below-128 bit ciphers but not to 168 bit ciphers. (Yes, I know from a > practical point of view the difference in strength is not particularly > interesting, but it's easier to add an option to a protocol spec than > to change a government regulation.) > > On the subject of lifetime negotiation, I agree with Tim. That case > is clearly different from the others in that each side can enforce a > lifetime on its own. If I need a 1 hour lifetime, I should obviously > propose that if initiating, but there is nothing that prevents me from > deleting SAs after 1 hour even if 2 hours were negotiated. Since you > can get the desired effect (lifetime limit) unilaterally, I see no > reason to refuse such a proposal. It's fine to allow it to be > rejected, but the draft *requires* it to be rejected and that's going > too far. > > paul From owner-ipsec@lists.tislabs.com Wed Jun 2 16:24:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA25135; Wed, 2 Jun 1999 16:24:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04737 Wed, 2 Jun 1999 17:35:04 -0400 (EDT) Date: Wed, 2 Jun 1999 17:43:39 -0400 Message-Id: <199906022143.RAA29629@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906021730.NAA16539@tonga.xedia.com> <199906022109.OAA26844@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> The text specifically discusses "certain negotiable attributes Dan> [that] have ranges or multiple acceptable values." It's not Dan> discussing the relative strengths of different algorithms. I realize that. The key length case is clear. The group number case could be misinterpreted as a comparison among algorithms, since some groups are MODP and some are elliptic curve. The example is fine, but you might want to clarify that it doesn't apply to, say, a local policy for group 2 and a proposal of group 3. Dan> Let me try a different tact: Does anyone think that an Dan> implementation should never accept an offer which contains a Dan> variable-length encryption algorithm which includes a key length Dan> greater than what it would have offered had it inititated? I'm Dan> assuming the answer is no. So I'm trying to note that such Dan> behavior is acceptable. Sounds good to me. Dan> You don't see a reason to refuse a lifetime offer of 2 hours if Dan> you're locally configured for 1 hour? Do you think that all Dan> vendors MUST accept any lifetime then? Your behavior is not Dan> prohibited, just that it is also not mandatory. Yes to the former, no to the latter. But I see no reason to give second-class status to the former, which "should" is doing. Dan> ... Dan> Regarding lifetimes, if the text in this draft is not acceptable Dan> than what about the text in section 4.5.4 of RFC2407? Don't Dan> people have a problem with option 1? Yes. Which was the point, because it seems that the draft is recommending option 1 ("...that offer SHOULD be refused as it violates the local policy" -- top of page 8). Contrast that with 4.5.4 of RFC2047, which lists the 3 alternatives as equally acceptable. Dan> So let me ask the entire working group: should vendors be Dan> prohibited from accepting a key length greater than what they Dan> have configured? Should they be prohibited from accepting a Dan> stronger group? Was that ever a proposal? I don't remember that it was. I don't remember any comments saying it should be. paul From owner-ipsec@lists.tislabs.com Wed Jun 2 23:13:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA05844; Wed, 2 Jun 1999 23:13:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05350 Thu, 3 Jun 1999 00:15:45 -0400 (EDT) Message-Id: <199906030424.VAA04924@potassium.network-alchemy.com> To: Paul Koning cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 17:43:39 EDT." <199906022143.RAA29629@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4921.928383851.1@network-alchemy.com> Date: Wed, 02 Jun 1999 21:24:11 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the last bakeoff there was unanimous concent to mandate the use of the acknowledged informational exchange to send delete messages when deleteing an SA. At least there were lots of "yes"es and no "no"s when I asked and asked again just to make sure. If this text is added then the concern about accepting a phase 1 lifetime which is greater than the locally configured time goes away because you're guaranteed that the peer will receive your delete message. So I'll add such text and remove the lifetime discussion from 3.2. I will leave the SHOULD language for "negotiating up" the following: * encryption algorithms with a variable length key, block size, or number of rounds. * Diffie-Hellman groups of the same type. SHOULD is appropriate because, per RFC2119, in general it seems the right and prudent thing to do but there may exist valid reasons to not negotiate up and that behavior should be carefully considered before electing to do so. How does that sound? Dan. On Wed, 02 Jun 1999 17:43:39 EDT Paul Koning wrote > >>>>> "Dan" == Dan Harkins writes: > > Dan> The text specifically discusses "certain negotiable attributes > Dan> [that] have ranges or multiple acceptable values." It's not > Dan> discussing the relative strengths of different algorithms. > > I realize that. The key length case is clear. The group number case > could be misinterpreted as a comparison among algorithms, since some > groups are MODP and some are elliptic curve. The example is fine, but > you might want to clarify that it doesn't apply to, say, a local > policy for group 2 and a proposal of group 3. > From owner-ipsec@lists.tislabs.com Wed Jun 2 23:52:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA06090; Wed, 2 Jun 1999 23:51:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA05305 Wed, 2 Jun 1999 23:41:56 -0400 (EDT) Message-Id: <199906030349.UAA04816@potassium.network-alchemy.com> To: "Kalyan Chakravarthy Bade" cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 13:00:20 PDT." <005301bead33$0255b020$2e05010a@HEG> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4813.928381785.1@network-alchemy.com> Date: Wed, 02 Jun 1999 20:49:46 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The former. Value 6 is reserved to IANA by RFC2409. This draft is intended to depricate RFC2409 though and is intentionally consuming those numbers in order. Dan. On Wed, 02 Jun 1999 13:00:20 PDT you wrote > The authentication method value for DH less RSA encryption is 6 > and is clashing with the value of Encryption with El-Gamal. Which > one has to be changed ? > > Kalyan > kalyan@intotoinc.com > > From owner-ipsec@lists.tislabs.com Thu Jun 3 00:18:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA06324; Thu, 3 Jun 1999 00:18:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05512 Thu, 3 Jun 1999 01:06:44 -0400 (EDT) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 2 Jun 1999 22:01:23 -0700 (PDT) From: Glen Zorn To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft 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 Mon, 24 May 1999, Stephen Kent wrote: Sorry for the delayed response -- I've been traveling and otherwise occupied. > Glen, > > >> If I use a certificate in IKE that attests to my user name, not the name or > >> address of my computer, then I am doing user authentication. > > > >Sorry, apparently I did not make myself clear. I was using the term "user > >authentication" in the common sense -- that is to say, the sense that is > >understood in the 95+% of installations where PKI is not existent, let > >alone ubiquitous. In the day ("just around the corner" for the last 10 > >years or so) when PKI _is_ ubiquitous, you are absolutely correct. I am > >obviously somewhat skeptical that that day will come very soon, but I have > >been wrong before, so suppose I am wrong this time. In that case, the > >inclusion of XAUTH in IKE does nothing but add useless baggage to an > >already complex protocol. Conversely, suppose that I am right, and > >PKI is not ubiquitous for some lengthy period. In this case, the > >inclusion of XAUTH in IKE will likely slow PKI deployment and reduce the > >overall security of the system (through the use of comparatively weak > >user authentication methods). Either way, this is a bad idea. > > This has NOTHING to do with whether we have univerals PKIs or not. The > context we are discussing is a closed community of users who are authorized > to access resources. This set of users is well known, bounded, etc., > because the legacy systems you are so fond of can deal only with such > communities. Thus there is NO need for ubiquitous PKIs to support these > needs. No need to shout, Steve. > Organizations need only migrate their Radius databases to local PKI > databases. In fact, it is especially easy to support online issuance of > certs to users when you already have a legacy user authentication system. > Great! Sounds like we're in violent agreement that XAUTH is unnecessary, since the required infrastructure should be easy to install. > >> > >> You may have a point that IKE, given its existing complexity, is an > >> unfortunate place to add other forms of user auth, but please don't say > >> that it does not provide user auth under the right (existing) > >> circumstances. > >> > > > >The fact that these circumstances do _not_ exist in any widespread sense > >is the only possible rationale for the development of XAUTH, no? > > "Widespread sense?" I think there's confusion about the context of this > sentence. Fine. > > >> Also, because IPsec involves access control as a basic security service, if > >> the SPD entries take the form of user names, then it is preferable that IKE > >> be able to verify user identity, in order to support the access control > >> features of IPsec. > > > >Access control means many things to many people. In the scenario under > >discussion (remote access to some "home" network) it's hard to imagine > >administrators managing user-level access control via IPsec filters, > >especially if the home network is at all dynamic. > > Access control can be applied at various levels of granularity, true. I > know your preference here, since we've just concluded an extended debate on > this in the context of L2TP. You clearly didn't feel that IPsec access > control was useful, On the contrary, IPsec filtering is certainly useful, and not a bad hack (though rather difficult to configure). > and thus argued against pointing out the access control > differences between L2TP's use of IPsec vs. native IPsec use. Part of your > argument was that PPP implementations provide appropriate access controls, > even though such controls are not part of the standards. > Actually, my main point was that IPsec filtering is less a security feature than an efficiency hack. It should be obvious that equivalent packet filters applied _at either end_ of a tunnel will have the same effect on security; it _is_ more efficient (in terms of bandwidth) to apply the filters before the traffic enters the tunnel, however. Also, there are standards and standards; even though packet filtering in cisco routers is not "standard" I'll wager that there are far more people who can successfully configure a cisco filter than can configure IKE... > >> If another protocol is employed to veriy user identity, > >> then one creates a more complex interdependence between IPsec and the other > >> protocol, right? > > > >Not sure I understand. Is the "other protocol" RADIUS? If so, there is a > >much bigger problem then interdependence complexity, due to the severe and > >well-known security problems with the RADIUS protocol (especially in a > >proxied environment. > > I was not focusing on any specific authentication protocol, just making a > general observation. > Oh, OK. I'm still not sure that I see a great deal of complexity. It seems that the hardest thing would be to make sure that the SA goes away when the user logs off or if user auth fails. Is that required, though? > Steve > > P.S. Is there some reason you're using an ACM mbx vs. your Microsoft mbx? > Several, mostly having to do with personal convenience. From owner-ipsec@lists.tislabs.com Thu Jun 3 00:33:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA06527; Thu, 3 Jun 1999 00:33:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05610 Thu, 3 Jun 1999 01:33:11 -0400 (EDT) Message-Id: <199906030541.WAA05168@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 21:24:11 PDT." <199906030424.VAA04924@potassium.network-alchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5165.928388498.1@network-alchemy.com> Date: Wed, 02 Jun 1999 22:41:38 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lemme just note that the lifetime issue was discussed in Chicago almost a year ago. It was included on the IKE/DOI errata page for about that long and also discussed on the list. There was even a presentation-- in Orlando, I think-- that discussed it. Nobody seemed to have any problem with it... until now. Dan. On Wed, 02 Jun 1999 21:24:11 PDT I wrote > At the last bakeoff there was unanimous concent to mandate the use > of the acknowledged informational exchange to send delete messages > when deleteing an SA. At least there were lots of "yes"es and no > "no"s when I asked and asked again just to make sure. If this text > is added then the concern about accepting a phase 1 lifetime which > is greater than the locally configured time goes away because you're > guaranteed that the peer will receive your delete message. > > So I'll add such text and remove the lifetime discussion from 3.2. > I will leave the SHOULD language for "negotiating up" the following: > > * encryption algorithms with a variable length key, block size, > or number of rounds. > * Diffie-Hellman groups of the same type. > > SHOULD is appropriate because, per RFC2119, in general it seems the > right and prudent thing to do but there may exist valid reasons to not > negotiate up and that behavior should be carefully considered before > electing to do so. > > How does that sound? > > Dan. From owner-ipsec@lists.tislabs.com Thu Jun 3 06:23:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12333; Thu, 3 Jun 1999 06:23:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06220 Thu, 3 Jun 1999 07:10:18 -0400 (EDT) Message-Id: <199906031118.HAA02773@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-monitor-mib-01.txt Date: Thu, 03 Jun 1999 07:18:37 -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 Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-monitor-mib-01.txt Pages : 58 Date : 02-Jun-99 This document defines low level monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPSec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPSec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-01.txt 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-monitor-mib-01.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-monitor-mib-01.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: <19990602134730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-monitor-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990602134730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jun 3 06:44:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12518; Thu, 3 Jun 1999 06:44:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06362 Thu, 3 Jun 1999 07:46:25 -0400 (EDT) Message-Id: <199906031154.HAA03159@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-isakmp-di-mon-mib-00.txt Date: Thu, 03 Jun 1999 07:54:49 -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 : ISAKMP DOI-Independent Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-isakmp-di-mon-mib-00.txt Pages : 20 Date : 02-Jun-99 This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-00.txt 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-isakmp-di-mon-mib-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-ietf-ipsec-isakmp-di-mon-mib-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: <19990602134803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-di-mon-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990602134803.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jun 3 08:17:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13305; Thu, 3 Jun 1999 08:17:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06584 Thu, 3 Jun 1999 08:37:39 -0400 (EDT) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: ipsec@lists.tislabs.com Message-ID: <85256785.0042D6AE.00@zule.shiva.com> Date: Thu, 3 Jun 1999 08:39:47 -0400 Subject: Comments on Section 3.1 of new IKE draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 1. Section 3.1 says In addition, optional attributes may be negotiated. These include a lifetime and a pseudo-random function ("prf"). Something is wrong here, since the section is called "Mandatory Options." It is not clear here whether the intent is that it is optional to negotiate these items but that all implementations MUST be able to negotiate them, or whether the options truely are optional and an implementation is not conformant if it REQUIREs the peer to negotiate them. (I know "the answer" from the good ol' boy network, but the good ol' boy network is not part of the spec.) 2. Section 3.1. continues: In addition IKE implementations SHOULD support the following values: - CAST in CBC mode and Blowfish in CBC mode for encryption algorithm. - Tiger ([Tiger]) for hash algorithm. - Authentication using RSA and DSA signatures, and using RSA and El-Gamal public key encryption. - Groups 3 through 5 for Diffie-Hellman group. Charles Kunsinger already made the point that most of these have not been discussed on the list, and it is not self-evident whether any of these algorithms really rate a SHOULD. Without clear guidelines on when and why to use each of these algorithms, arbitrarily adding SHOULDs also arbitrarily decreases the overall managability of IKE implementations and and increases its overall complexity. Both of these decreases the overall security IKE affords. Decreasing managability decreases security because it adds more training and configuration cost, so increases the the number of places where an IPSec solution won't be deployed at all. Increasing complexity decreases security, because it becomes harder to verify our own implementations are bug free with regard to security issues. All of these need to be MAYs unless we can provide operational guidance for them. 3. One issue Section 3.1 raises by omission is the subject of default values for each of the options. We've talked about and rejected defaults before. I'm wondering whether we have made an error in our collective judgement and we need to do something here. There are three ways in which defaults might help: a. improve out-of-the-box interoperability; b. experience shows it is usually easier to move from a known working configuration to another working configuration than to build a new configuration from scratch; c. experience shows it is can be much easier to debug problems by moving to a known working configuration, trouble-shooting there, and then applying (b), than to trouble-shoot an arbitrary configuration. Even if this reasoning is correct, the IKE specification may not be the right place to document the defaults. We have rejected defaults before because it is never clear that good defaults today will be good ones tomorrow. Maybe we need a separate document a la the "profiles" or implementers' agreement from the ISO days. The profile document would have a prescribed finite lifetime, just like DES or IETF drafts, to account for the fact that security requirements change? Profiles could help in a lot more areas than just defaults. From the bake-offs we know that having well-defined profiles speeds configuration in general. From owner-ipsec@lists.tislabs.com Thu Jun 3 09:33:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13975; Thu, 3 Jun 1999 09:33:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06805 Thu, 3 Jun 1999 09:51:52 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D074@md-exchange1.nai.com> From: "Mason, David" To: "'Dan Harkins'" , Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 3 Jun 1999 06:57:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >So I'll add such text and remove the lifetime discussion from 3.2. >I will leave the SHOULD language for "negotiating up" the following: I'd prefer to have it be a MAY because if A can successfully initiate with B, B SHOULD be able to successfully initiate with A and more often than not "negotiating up" will only allow successful initiations from the stronger side. Of course this could be handled by the weaker side maintaining a "negotiated up" database to be consulted before rekeys that it initiates and in the initial contact case every possible combination of "stronger" attributes could be offered (but for group selection this will only work for Main Mode and not Quick Mode). -dave From owner-ipsec@lists.tislabs.com Thu Jun 3 09:33:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13983; Thu, 3 Jun 1999 09:33:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06854 Thu, 3 Jun 1999 10:07:55 -0400 (EDT) From: pau@watson.ibm.com Date: Thu, 3 Jun 1999 10:15:15 -0400 Message-Id: <9906031415.AA22386@secpwr.watson.ibm.com> To: ipsec@lists.tislabs.com Subject: A question on SA establishment in RFC 2408 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apology if this question has been raised before. Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA establishment, in its last paragraph before section 4.2.1, it states : ".......The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. ..." My question is about the word "SHOULD". This word means the responder does not have to retain the proposal and transform numbers. If it does not retain the numbers, then what numbers should be used in the "proposal number" and "transform number" fields in the proposal and transform payloads sent from the responder to the initiator ? A related and more fundamental question is that how the initiator could determine if the responder retains the numbers or not ? Thanks in advance. Pau-Chen From owner-ipsec@lists.tislabs.com Thu Jun 3 10:03:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14206; Thu, 3 Jun 1999 10:03:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07102 Thu, 3 Jun 1999 11:01:57 -0400 (EDT) Message-Id: <3.0.5.32.19990603181256.00a81bb0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Jun 1999 18:12:56 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: A question on SA establishment in RFC 2408 In-Reply-To: <9906031415.AA22386@secpwr.watson.ibm.com> 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 LAA07099 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:15 3.6.1999 -0400, you wrote: > > > My apology if this question has been raised before. > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA establishment, > in its last paragraph before section 4.2.1, it states : > > ".......The responder > SHOULD retain the Proposal # field in the Proposal payload and the > Transform # field in each Transform payload of the selected Proposal. > ..." > > My question is about the word "SHOULD". This word means the responder > does not have to retain the proposal and transform numbers. If it does > not retain the numbers, then what numbers should be used in the > "proposal number" and "transform number" fields in the proposal and > transform payloads sent from the responder to the initiator ? > You are free to use whatever you like. You may return the original numbers, or 0 or 1 or 42. > A related and more fundamental question is that how the initiator > could determine if the responder retains the numbers or not ? It can't. The initiator has to match the returned proposal against the proposals that it sent. Please notice that the responder might return something the initiator did not propose. Or it might return all proposals the initiator sent. > > > Thanks in advance. > > > Pau-Chen > > Jörn From owner-ipsec@lists.tislabs.com Thu Jun 3 10:42:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14494; Thu, 3 Jun 1999 10:42:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07352 Thu, 3 Jun 1999 11:39:10 -0400 (EDT) Date: Thu, 3 Jun 1999 11:47:38 -0400 Message-Id: <199906031547.LAA01181@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David_Mason@nai.com Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <447A3F40A07FD211BA2700A0C99D759B05D074@md-exchange1.nai.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mason," == Mason, David writes: >> So I'll add such text and remove the lifetime discussion from 3.2. >> I will leave the SHOULD language for "negotiating up" the >> following: Mason,> I'd prefer to have it be a MAY because if A can successfully Mason,> initiate with B, B SHOULD be able to successfully initiate Mason,> with A and more often than not "negotiating up" will only Mason,> allow successful initiations from the stronger side. I prefer Dan's proposal. While it makes sense not to require negotiating up, it seems right to recommend it. The argument about symmetry is not all that convincing. Is it better for the sake of symmetry for A to refuse to talk to B (on the grounds that B couldn't talk to A)? I don't think so. I'd rather have connectivity. But of course you're free to make the other choice. paul From owner-ipsec@lists.tislabs.com Thu Jun 3 11:25:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14861; Thu, 3 Jun 1999 11:25:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07665 Thu, 3 Jun 1999 12:33:49 -0400 (EDT) Date: Thu, 3 Jun 1999 12:42:44 -0400 Message-Id: <199906031642.MAA03525@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ddp@network-alchemy.com Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906022109.OAA26844@potassium.network-alchemy.com> <199906031638.JAA21094@gallium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derrell" == Derrell D Piper writes: >> So let me ask the entire working group: should vendors be >> prohibited from accepting a key length greater than what they have >> configured? Should they be prohibited from accepting a stronger >> group? Derrell> Absolutely not and I'd go so far as to make it a SHOULD Derrell> instead of a MAY. Agreed. (I hope I didn't come across earlier as arguing the opposite...) paul From owner-ipsec@lists.tislabs.com Thu Jun 3 11:31:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14936; Thu, 3 Jun 1999 11:31:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07652 Thu, 3 Jun 1999 12:30:35 -0400 (EDT) Message-Id: <199906031638.JAA21094@gallium.network-alchemy.com> To: Dan Harkins cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 02 Jun 1999 14:09:07 PDT." <199906022109.OAA26844@potassium.network-alchemy.com> Date: Thu, 03 Jun 1999 09:38:54 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > So let me ask the entire working group: should vendors be prohibited from > accepting a key length greater than what they have configured? Should they > be prohibited from accepting a stronger group? Absolutely not and I'd go so far as to make it a SHOULD instead of a MAY. We're trying to design good security, not workarounds for bad implementations. Derrell From owner-ipsec@lists.tislabs.com Thu Jun 3 12:30:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA16033; Thu, 3 Jun 1999 12:30:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07864 Thu, 3 Jun 1999 13:26:47 -0400 (EDT) From: pau@watson.ibm.com Date: Thu, 3 Jun 1999 13:34:09 -0400 Message-Id: <9906031734.AA20398@secpwr.watson.ibm.com> To: ipsec@lists.tislabs.com, joern.sierwald@datafellows.com Subject: Re: A question on SA establishment in RFC 2408 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: HyUGXbSvrjSRIFuA+oaefw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA07861 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Thu Jun 3 11:56:09 1999 > Message-Id: <3.0.5.32.19990603181256.00a81bb0@smtp.datafellows.com> > X-Sender: joern@smtp.datafellows.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) > Date: Thu, 03 Jun 1999 18:12:56 +0300 > To: ipsec@lists.tislabs.com > From: Joern Sierwald > Subject: Re: A question on SA establishment in RFC 2408 > In-Reply-To: <9906031415.AA22386@secpwr.watson.ibm.com> > 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 LAA07099 > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > Content-Length: 1300 > Status: RO > > At 10:15 3.6.1999 -0400, you wrote: > > > > > > My apology if this question has been raised before. > > > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA establishment, > > in its last paragraph before section 4.2.1, it states : > > > > ".......The responder > > SHOULD retain the Proposal # field in the Proposal payload and the > > Transform # field in each Transform payload of the selected Proposal. > > ..." > > > > My question is about the word "SHOULD". This word means the responder > > does not have to retain the proposal and transform numbers. If it does > > not retain the numbers, then what numbers should be used in the > > "proposal number" and "transform number" fields in the proposal and > > transform payloads sent from the responder to the initiator ? > > > You are free to use whatever you like. > You may return the original numbers, or 0 or 1 or 42. > > > A related and more fundamental question is that how the initiator > > could determine if the responder retains the numbers or not ? > It can't. The initiator has to match the returned proposal against > the proposals that it sent. Please notice that the responder might > return something the initiator did not propose. Or it might return > all proposals the initiator sent. Then that statement in section 4.2 of RFC2408 would be practically useless. Since then the initiator would not be able to use these numbers sent by the responder in any effective way. Also, if I read RFC2409 correctly, the responder is supposed to choose only one proposal, which may contain multiple proposal payloads with the same propsoal number, and choose only one transform within each proposal payload. The responder should not return all proposals sent by the initiator. Did I miss anything ? Just my $0.02 opinion. Pau-Chen > > > > > > > Thanks in advance. > > > > > > Pau-Chen > > > > > Jörn > > From owner-ipsec@lists.tislabs.com Thu Jun 3 12:39:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA16101; Thu, 3 Jun 1999 12:39:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07993 Thu, 3 Jun 1999 13:54:18 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC0410DF@new-exc1.ctron.com> From: "Bassett, John Robert" To: "'Paul Koning'" , David_Mason@nai.com Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 3 Jun 1999 19:02:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Doesn't this cause problems when B decides to rekey the SA (e.g. because most of the traffic is B->A) ? If A rejects the proposal because the parameters are too weak it could be a long time before A decides to rekey and the SA becomes usable again. If this is the case I'd rather the system tell me immediately that it won't work rather than at 2am tommorow when it decides to rekey. John -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Thursday, June 03, 1999 4:48 PM To: David_Mason@nai.com Cc: dharkins@network-alchemy.com; ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) >>>>> "Mason," == Mason, David writes: >> So I'll add such text and remove the lifetime discussion from 3.2. >> I will leave the SHOULD language for "negotiating up" the >> following: Mason,> I'd prefer to have it be a MAY because if A can successfully Mason,> initiate with B, B SHOULD be able to successfully initiate Mason,> with A and more often than not "negotiating up" will only Mason,> allow successful initiations from the stronger side. I prefer Dan's proposal. While it makes sense not to require negotiating up, it seems right to recommend it. The argument about symmetry is not all that convincing. Is it better for the sake of symmetry for A to refuse to talk to B (on the grounds that B couldn't talk to A)? I don't think so. I'd rather have connectivity. But of course you're free to make the other choice. paul From owner-ipsec@lists.tislabs.com Thu Jun 3 12:43:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA16139; Thu, 3 Jun 1999 12:43:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08018 Thu, 3 Jun 1999 13:59:13 -0400 (EDT) Date: Thu, 3 Jun 1999 21:08:04 +0300 (EEST) Message-Id: <199906031808.VAA16083@kuvastin.ssh.fi> From: Tatu Ylonen To: ipsec@lists.tislabs.com Subject: SSH IPSEC technology for Lucent Organization: SSH Communications Security, Finland Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lucent Remote Access Business Unit has licensed IPSEC technology from SSH. With its Livingstone and Ascend acquisitions, Lucent is the biggest access router vendor in the world. More information at http://www.ssh.fi/about/press/release03061999.html. Tatu -- SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ipsec.com/ Free Unix SSH http://www.ssh.fi/sshprotocols2/ From owner-ipsec@lists.tislabs.com Thu Jun 3 13:02:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16260; Thu, 3 Jun 1999 13:02:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08054 Thu, 3 Jun 1999 14:10:42 -0400 (EDT) Message-Id: <199906031818.LAA06626@potassium.network-alchemy.com> To: "Jesse Walker" cc: ipsec@lists.tislabs.com Subject: Re: Comments on Section 3.1 of new IKE draft In-reply-to: Your message of "Thu, 03 Jun 1999 08:39:47 EDT." <85256785.0042D6AE.00@zule.shiva.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6623.928433916.1@network-alchemy.com> Date: Thu, 03 Jun 1999 11:18:36 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 03 Jun 1999 08:39:47 EDT you wrote > 1. Section 3.1 says > > In addition, optional attributes may be negotiated. These > include a lifetime and a pseudo-random function ("prf"). > > Something is wrong here, since the section is called "Mandatory > Options." It is not clear here whether the intent is that it is > optional to negotiate these items but that all implementations MUST be > able to negotiate them, or whether the options truely are optional and > an implementation is not conformant if it REQUIREs the peer to > negotiate them. (I know "the answer" from the good ol' boy network, but > the good ol' boy network is not part of the spec.) The good ol' boy network? Is this the same group that said it was OK to send a message ID in a payload field labeled "SPI"? You don't like "Mandatory Option"? Fine. What do you like? Perhaps you can consult with that gaggle of gregarious geriatrics and get back to us? What is "the answer"? > 2. Section 3.1. continues: > > In addition IKE implementations SHOULD support the following > values: > - CAST in CBC mode and Blowfish in CBC mode for encryption > algorithm. > - Tiger ([Tiger]) for hash algorithm. > - Authentication using RSA and DSA signatures, and using RSA > and El-Gamal public key encryption. > - Groups 3 through 5 for Diffie-Hellman group. > > Charles Kunsinger already made the point that most of these have not > been discussed on the list, and it is not self-evident whether any of > these algorithms really rate a SHOULD. Without clear guidelines on when > and why to use each of these algorithms, arbitrarily adding SHOULDs > also arbitrarily decreases the overall managability of IKE > implementations and and increases its overall complexity. Both of these > decreases the overall security IKE affords. Decreasing managability > decreases security because it adds more training and configuration cost, > so increases the the number of places where an IPSec solution won't be > deployed at all. Increasing complexity decreases security, > because it becomes harder to verify our own implementations are bug > free with regard to security issues. All of these need to be MAYs unless > we can provide operational guidance for them. I asked Charles Kunzinger so I'll ask you: do you have a problem with El-Gamal? "most of these"? If you actually read RFC2409 you'd see that Blowfish, Tiger, RSA signatures, DSA signatures, and RSA encryption, and groups 3 and 4 are all there. The only new ones are El-Gamal encryption and group 5. If you bothered to look at the archives of this list or listened at IETF meetings you'd have heard a discussion of group 5. So the only new one is El-Gamal. That's 1 out of 9. Hardly "most". I'm going to add RIPE-MD in the next iteration. Do you have a problem with that? It wasn't discussed on the list? OK, fine. Start a discussion then. Raise some points. You want clear guidelines? Would you like me to include a large paragraph discussing the pros and cons of El-Gamal and RSA? When it's better to use CAST or Blowfish? That kind of hand-holding is wholly unsuitable for a document like IKE. How is the security of IKE decreased by the inclusion of another optional authentication method? Do you know some flaw in El-Gamal? If you don't want to include this authentication method and therefore a knob to allow it then don't; it's not required. What is the problem? The managability of your implementation is not effected unless you implement this. > 3. One issue Section 3.1 raises by omission is the subject of default > values for each of the options. We've talked about and rejected > defaults before. I'm wondering whether we have made an error > in our collective judgement and we need to do something here. > There are three ways in which defaults might help: > > a. improve out-of-the-box interoperability; > > b. experience shows it is usually easier to move from a known working > configuration to another working configuration than to build a > new configuration from scratch; > > c. experience shows it is can be much easier to debug problems by > moving to a known working configuration, trouble-shooting there, and > then applying (b), than to trouble-shoot an arbitrary configuration. > > Even if this reasoning is correct, the IKE specification may not be > the right place to document the defaults. We have rejected defaults > before because it is never clear that good defaults today will be good > ones tomorrow. Maybe we need a separate document a la the "profiles" > or implementers' agreement from the ISO days. The profile document > would have a prescribed finite lifetime, just like DES or IETF drafts, > to account for the fact that security requirements change? When were defaults rejected by this working group? We agreed that DES, SHA & MD5, group 1, and pre-shared keys were the the mandatory-to-implement options. We decided this a long time ago. Deep Crack has made the use of DES very questionable so I changed DES to 3DES and, correspondingly, group 1 to 2. What is wrong with that? > Profiles could help in a lot more areas than just defaults. From the > bake-offs we know that having well-defined profiles speeds > configuration in general. Are you happy with the mandatory-to-implement IPSec transforms but unhappy with the mandatory-to-implement attributes in IKE? You don't like the term "Mandatory Option" yet you fail to suggest any alternative and allude to some nebulous group of people who know "the answer". You seem to have some problem with El-Gamal yet you don't say what it is. What is this unconstructive criticism supposed to accomplish? Dan. From owner-ipsec@lists.tislabs.com Thu Jun 3 15:01:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17572; Thu, 3 Jun 1999 15:01:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08275 Thu, 3 Jun 1999 15:54:59 -0400 (EDT) Message-ID: <00c601beadfc$7b180c50$0101000a@mv.lucent.com> From: "David W. Faucher" To: References: <199906022109.OAA26844@potassium.network-alchemy.com><199906031638.JAA21094@gallium.network-alchemy.com> <199906031642.MAA03525@tonga.xedia.com> Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 3 Jun 1999 15:04:31 -0500 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >> So let me ask the entire working group: should vendors be > >> prohibited from accepting a key length greater than what they have > >> configured? Should they be prohibited from accepting a stronger > >> group? > I may be in the minority here but I see this as an implementation issue. I would argue that a system should be configured to provide a level of security comparable to the value of the information being protected. Overriding that configuration just because it is capable doesn't necessarily mean it should. I'm not arguing for prohibiting such behavior. I'm just not for recommending it. If an implementation chooses to accept such behavior that fine. On the other hand, an implementation could just as easily allow such behavior to be configured. thanks, David W. Faucher From owner-ipsec@lists.tislabs.com Thu Jun 3 15:36:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17938; Thu, 3 Jun 1999 15:36:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08444 Thu, 3 Jun 1999 16:39:36 -0400 (EDT) Message-ID: <3756EA0E.23AEEF14@redcreek.com> Date: Thu, 03 Jun 1999 13:48:14 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <447A3F40A07FD211BA2700A0C99D759B05D074@md-exchange1.nai.com> <199906031547.LAA01181@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Just a quick question on this, with the caveat that I haven't yet taken the time to review the draft (sorry, I'll get to it soon, I promise): regarding the question as to whether negotiating upward should be prefixed with MAY, SHOULD, etc., something has been nagging at me. Isn't this a local policy issue? I mean, if I specify as a matter of policy that I want 56-bit DES *only*, wouldn't it be a violation of my policy to accept 3DES just because you offer it? Scott From owner-ipsec@lists.tislabs.com Thu Jun 3 16:12:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18269; Thu, 3 Jun 1999 16:12:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08658 Thu, 3 Jun 1999 17:22:11 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC81@new-exc1.ctron.com> From: "Waters, Stephen" To: Tim Jenkins Cc: ipsec@lists.tislabs.com, "Waters, Stephen" Subject: RE: New MIB Drafts Submitted Date: Thu, 3 Jun 1999 22:31:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have been thinking of making a suggestion about IPCOMP negotiation for some time, and this new MIB has prompted me to write it down. This MIB has a separate table for IPCOMP Security Associations. It has always seemed odd to me that IPCOMP is being negotiated with IKE at all. It also seems odd that there are other suggestions to extend IKE with IKE-CFG and IKE-XAUTH. IKE is a very good tool to exchange keys in a secure ways that are then used to enact data encryption and authentication. Can't we agree to leave it at that? If there is a need to add other IP Peer negotiation, then perhaps it is time for a generic IP Peer Protocol ('IPPP'). At the moment, there is no way to negotiate IPCOMP between hosts, other than to use IKE. Perhaps we need 'IPPP' to cover these extensions for IP in general. If you think about what these IKE-klingons are adding, it looks very similar to PPP NCPs - CCP, IPCP, CHAP etc. Perhaps running an IP version of these protocols following the end of Phase-2 would allow us to leave IKE pure, and we would not be in the silly position of having IPCOMP SAs. I would even go so far as to say that the policy (subnet,range,address) negotiation could be stripped from phase2 as well. IKE phase2 would then negotiate just the protocols used to protect data and lifetime/lifedata. Any restrictions to be applied to packets could then be negotiated/exchanged by 'IPPP' in a 'policy phase'. In some cases (most, I'd say), no policy needs to be sent - 'send anything'. Maybe I go to far, but there does seem to be a need for a protocol to negotiate peer to peer items for VPNs and non-VPNs that would not be bound to IPSEC/IKE. At the very least, this may allow host peers to negotiate IPCOMP, and allow the Security Gateways to worry about encryption/authentication enforcement. Any votes of support for a draft? Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Wednesday, June 02, 1999 4:40 PM To: ipsec@lists.tislabs.com Cc: John.Shriver@intel.com; John Shriver Subject: New MIB Drafts Submitted Greetings, A new version of IPSec monitoring MIB document is available at , and has been submitted to the internet-drafts registry. Also, a new document, also part of the IPSec MIB series of documents has also been submitted. This document is the DOI-independent portion of the ISAKMP monitoring MIB, at . Due to the embedded page control characters, it should be transferred as BINARY, not text. Comments requested. Tim and John Note: I have received comments that the FTP server on the machine above does not respond to all types of FTP requests. I have tried to get this changed, but have had no luck yet. If you have trouble, email me and I will email copies back. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Thu Jun 3 17:04:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18707; Thu, 3 Jun 1999 17:03:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08901 Thu, 3 Jun 1999 18:24:10 -0400 (EDT) Message-ID: <3756F5AF.9712EFE2@redcreek.com> Date: Thu, 03 Jun 1999 21:37:51 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: ICMP in IPSec References: <199905230130.VAA00586@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Ricky" == Ricky Charlet writes: > Ricky> I have not followed Michael Richardson's draft (icmp-handle) in > Ricky> my 'initial thoughts' post. I find it more clear to ponder these out in > Ricky> terms of 'situational examples'. I hope (naively??) that my list of > > This is, in my opinion, the best way to arrive at functional requirements. > > Ricky> situations is complete. The goal would be to move from my situational > Ricky> format to filling in Michael's draft with the details per message rather > Ricky> than per situation. > > Excellent. If you want be to translate my LinuxDOC SGML RFC source > to Marshall Rose style XML, then I can forward things and you can take > over the document. > I'm not sure, could you forward what you have and I'll take a look? I'm not sure what SGML and XML stuff you are refering to... Ricky From owner-ipsec@lists.tislabs.com Thu Jun 3 17:04:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18715; Thu, 3 Jun 1999 17:04:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08839 Thu, 3 Jun 1999 18:18:37 -0400 (EDT) Message-Id: <199906032227.PAA07366@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 03 Jun 1999 15:25:44 -0700 To: "Waters, Stephen" From: Avram Shacham Subject: RE: New MIB Drafts Submitted Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBC81@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:31 PM 6/3/99 +0100, Waters, Stephen wrote: > >I have been thinking of making a suggestion about IPCOMP negotiation for >some time, and this new MIB has prompted me to write it down. > >This MIB has a separate table for IPCOMP Security Associations. It has >always seemed odd to me that IPCOMP is being negotiated with IKE at all. Not odd at all. RFC2393 details three mechanisms to establish IPComp Association (IPCA): manual configuration, IPSec's IKE, and another dynamic negotiation protocol that is yet to be defined. IPComp usage is very natural in IPSec's environment and IPSec's negotiation infrastructure is available. So, the ippcp wg thought that there is no need to reinvent the wheel for the immediate deployment in the IPSec context. Again, the rfc does support negotiations via another protocol, or protocols, if and when such protocol becomes available. avram >It also seems odd that there are other suggestions to extend IKE with IKE-CFG >and IKE-XAUTH. IKE is a very good tool to exchange keys in a secure ways >that are then used to enact data encryption and authentication. Can't we >agree to leave it at that? > >If there is a need to add other IP Peer negotiation, then perhaps it is time >for a generic IP Peer Protocol ('IPPP'). At the moment, there is no way to >negotiate IPCOMP between hosts, other than to use IKE. Perhaps we need >'IPPP' to cover these extensions for IP in general. > >If you think about what these IKE-klingons are adding, it looks very similar >to PPP NCPs - CCP, IPCP, CHAP etc. Perhaps running an IP version of these >protocols following the end of Phase-2 would allow us to leave IKE pure, and >we would not be in the silly position of having IPCOMP SAs. > >I would even go so far as to say that the policy (subnet,range,address) >negotiation could be stripped from phase2 as well. IKE phase2 would then >negotiate just the protocols used to protect data and lifetime/lifedata. Any >restrictions to be applied to packets could then be negotiated/exchanged by >'IPPP' in a 'policy phase'. >In some cases (most, I'd say), no policy needs to be sent - 'send anything'. > >Maybe I go to far, but there does seem to be a need for a protocol to >negotiate peer to peer items for VPNs and non-VPNs that would not be bound >to IPSEC/IKE. > >At the very least, this may allow host peers to negotiate IPCOMP, and allow >the Security Gateways to worry about encryption/authentication enforcement. > >Any votes of support for a draft? >Steve. > > > > > >-----Original Message----- >From: Tim Jenkins [mailto:tjenkins@TimeStep.com] >Sent: Wednesday, June 02, 1999 4:40 PM >To: ipsec@lists.tislabs.com >Cc: John.Shriver@intel.com; John Shriver >Subject: New MIB Drafts Submitted > > >Greetings, > >A new version of IPSec monitoring MIB document is available at >, >and has been submitted to the internet-drafts registry. > >Also, a new document, also part of the IPSec MIB series of >documents has also been submitted. This document is the >DOI-independent portion of the ISAKMP monitoring MIB, at >. > >Due to the embedded page control characters, it should be >transferred as BINARY, not text. > >Comments requested. > > >Tim and John > >Note: I have received comments that the FTP server on >the machine above does not respond to all types of FTP >requests. I have tried to get this changed, but have >had no luck yet. If you have trouble, email me and >I will email copies back. > >--- >Tim Jenkins TimeStep Corporation >tjenkins@timestep.com http://www.timestep.com >(613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@lists.tislabs.com Thu Jun 3 17:58:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA19013; Thu, 3 Jun 1999 17:58:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08988 Thu, 3 Jun 1999 18:56:24 -0400 (EDT) Message-ID: <3756FD3C.F9718A3D@redcreek.com> Date: Thu, 03 Jun 1999 22:10:04 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Loretta Zhou , ipsec Subject: Re: ICMP in IPSec References: <373C8FED.4927518C@redcreek.com> <374B4455.73AD20FF@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Loretta Zhou wrote: > > Ricky Charlet wrote: > > > > > So Sgw1 has four questions to answer about ICMP messages > > received from R1 intended for return to E1'. > > 1. Is this message intended for me directly or for some endpoint I > > protect? > > 2. Is this an interesting message? > > 3. Do I trust the message? > > 4. Is there enough information in the message to be useful to E1'? > > > > To answer question number 1 above use the following logic: If > > message is an ICMP query, then it is not for E1'... respond to ICMP > > queries to this interface as per local interface policy. If message is > > an ICMP error, then examine the original offending packet data IPSec > > Header field for a valid SPI number. Presence of an SPI implies that > > this message is intended for some endpoint and not for the Sgw itself. > > If the message is in fact intended for this Sgw, then local policy > > should specify whether to handle/respond or ignore the message. > > > > I think another way of identifying whether the message is intended > for sgw or endpoint is to check the protocol field of the IP header > attached to the ICMP message. If the protocol is AH or ESP, it indicates > that the original offending packet was a tunneled packet and the message > is intended for some endpoint protected by Sgw1. If the protocol field > returns a value other than AH/ESP, it indicates that the ICMP message is > for the security gateway. > > In my opinion, this approach is easier than looking for a valid SPI > number. > True! Excellent observation. > > If message is intended for some endpoint behind this gateway, > > and local policy allowed ICMP processing on this interface, then proceed > > to question 2 from above. > > > > > To answer question number 3 above, the only secure course is > > to not trust messages appearing at Sgw1 which did not arrive in an SA. > > But an Operations and Maintenance group might evaluate the security risk > > (DOS attack) of accepting these limited IMCP error messages as worth the > > value of knowing about PMTU, and/or TOS reachability. So they will need > > a configurable option to allow each of these messages. The IMCP > > configuration MUST allow for explicit pass/block filtering on > > Fragmentation Needed messages, and on TOS messages. These filter rules > > are over and above what is achievable with IPSec selectors. > > > > Is it really necessary to have an explicit filter sitting above the > IPSec selectors in SPD? If an administrator wants to let all or certain > ICMP traffic to bypass IPSec, he can always add an entry to the top of > the > SPD table stating that for traffic with "protocol=ICMP, srcAddr=* or > some > subnet address, dstAddr=* or some subnet address", apply bypass action. > > I noticed that sometimes you suggest handling ICMP error messages using > these special configurable filters, and some time you mention that the > ICMP error message needs to be checked against local policy (the SPD). > It seemed to be a little confusing to me when to check against what. > My point here was that you need to specify protocol=ICMP, AND ICMP message type = (FragNeeded OR UndeliverableDueToTOS). The explicit examination of particular ICMP message types/codes is the requirement which exceedes the capabilities of IPSec Selectors. > > > > Recovering the inner IP header in the case of an AH tunneled > > packet requires that we be able to see the entire outer IP header (20 > > bytes +options) the entire AH header (32 or more bytes), 20 or more > > bytes of the inner IP header (full header sans options) and 8 bytes of > > inner IP payload. If there is enough data present, then the inner IP > > packet header may be read. But it is extremely unlikely that the entire > > original IP packet was returned so that the data will not be able to be > > authenticated (but understand that if we have gotten this far, it means > > that an administrator has already made the choice to trust this > > information in spite of its inability to be authenticated). > > > > Recovering the inner IP header in the case of an ESP tunneled > > packet requires that we be ale to see the entire outer IP header (20 > > bytes +options) and enough of the ESP packet so that we may reference > > the SPI and then decrypt enough of the payload data to reveal the inner > > IP header, optinos and first 8 bytes of data. Again, it is very unlikely > > that we will have the entire original IP packet and will not be able to > > authenticate, but a trust decisions has already been made in spite of > > this limitation. > > > > Even though we are only intereseted in the inner IP header and the first > 8 bytes after the header, we still need to have the entire encrypted > packet in order to get the right decryption. Having partial encrypted > packet will not result in the right decryption. Perhaps an encryption expert could jump in at this point. My impression is that you can infact decrypt partial packets if you don't sweat the hash results (which would obviously be different). I don't know if it is a good idea or not, but I did think it possible to decrypt partial packets. > > In fact, it's impossible to get the inner IP header at all if the > original offending packet is a tunneled packet. Keep in mind that > ICMP can only carry an IP header and 8 bytes of the datagram beyond > the header in its message body. When a packet is tunneled, the IP > header is the outer header and the 8 bytes datagram is the first 8 > bytes of the AH/ESP header(the SPI will be included). The original > IP header will never be included in the ICMP message body and can > never be recovered from the ICMP message. Not impossible, just very unlikly. Different vendors IP stacks return different amounts of the original IP datagram in an ICMP message. The RFC only says that you must include at least the header and first 8 bytes. An ICMP message is perfectly capable of carrying more than header + 8 bytes of original packet, it just depends upon how that vendors stack was implemented. I have not done any 'survey of the market' to see what different implementations do. If we want to make the assumption that we will ONLY have header + 8 bytes to look at, thats ok with me, but it is an assumption. > > > > > > If the original inner IP packet header cannot be recovered, > > cease all further processing related to handling this error and drop the > > ICMP packet. An implementation MAY wish to make this an auditable event. > > If the original inner IP packet header and the first 8 bytes of original > > IP packet data can be recovered, then the security gateway MUST > > construct a new IMCP error message. It MUST be addressed to the source > > address named in the original inner IP header. It's ICMP type, ICMP > > code, IP TOS, and IP precedence MUST match the old ICMP packet (now > > being discarded). And the data it contains MUST be the original inner IP > > packet header plus 8 bytes of the original inner IP packet data. > > > > As mentioned above, I believe the inner IP header will never be recoverd > from the ICMP message for tunneled packet. Instead of dropping all the > packets, I suggest we store the packet with its SA (the SPI is included > in the ICMP message body so we can find the SA), and wait until the next > packet arrive from an originating host for the same SA. We will then > assume > the previous packet is also from the same originating host and we can > then > send the ICMP message (or a re-construct of the ICMP message) to that > host. I understand the temptation here but disagree. The particlular messages we are talking about sending back in this circumstance are FragWasNeeded or UndeliverableDueToTOS. If we send the TOS message to an incorrect host, but that host does just happen to have a current flow which the ICMP meesage might match as to its socket parameters, then we could destroy TOS policy distinguising the real host the message needed to go to and the actual host we 'accidently' sent the message to. But on the other hand, perhaps your idea does make sence for the NeededToFragment message. Perhaps some other voices could chime in here. > > My idea of the above suggestion came from RFC 2401(security architecture > for IP) and RFC 2003(IP Encapsulation within IP). In section 6.1.2.1 of > RFC 2401, it indicates that a security gateway MUST support what I just > suggested in the above paragraph for propagation of Path MTU. In section > 5 of RFC 2003, it also explictly stats that when an inner IP header > cannot > be determined due to encapsulation, the encapsulator should maintain > some > "soft state" about the tunnel and the encapsulator can return accurate > ICMP > messages to the original sender based on those "soft state". > We are undertaking the task of rethinking those sentences. As I said above, I think your concept has merrit for PMTU applications, but is dangerous to TOS policies. > > > > When Sgw2 decides to return an ICMP error to E1', similar > > processing occurs. Sgw2 creates the IMCP error message and MUST attach > > the entire offending IP packet and must ensure that the DF bit is > > cleared. Note, that at this point, the offending IP packet is in an > > un-encapsulated state. The ICMP packet which bundles the original > > offending IP packet is sent to E1' via Sgw1 through the complement SA of > > the SA it arrived on. Sgw1 recognizes that an ICMP packet to E1' > > arriving on an SA from the ISAKMP peer far end of the SA is allowable > > and forwards the packet. > > > > Does Sgw1 make decision (allow the ICMP packet to pass to E1) based on > SPD or those special filters? > > Regards, > Loretta Zhou I thank you very much for your input Loretta!!! -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Jun 3 18:37:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19264; Thu, 3 Jun 1999 18:37:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09039 Thu, 3 Jun 1999 19:24:14 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC85@new-exc1.ctron.com> From: "Waters, Stephen" To: Avram Shacham Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: RE: New MIB Drafts Submitted Date: Fri, 4 Jun 1999 00:33:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure I would use the words 'very natural' when describing the negotiation of IPCOMP in IKE, and I would suggest that IKE was not the right wheel to use in the first place, so perhaps invention was required, not reinvention. Cheers, Steve. -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Thursday, June 03, 1999 11:26 PM To: Waters, Stephen Cc: Subject: RE: New MIB Drafts Submitted At 10:31 PM 6/3/99 +0100, Waters, Stephen wrote: > >I have been thinking of making a suggestion about IPCOMP negotiation for >some time, and this new MIB has prompted me to write it down. > >This MIB has a separate table for IPCOMP Security Associations. It has >always seemed odd to me that IPCOMP is being negotiated with IKE at all. Not odd at all. RFC2393 details three mechanisms to establish IPComp Association (IPCA): manual configuration, IPSec's IKE, and another dynamic negotiation protocol that is yet to be defined. IPComp usage is very natural in IPSec's environment and IPSec's negotiation infrastructure is available. So, the ippcp wg thought that there is no need to reinvent the wheel for the immediate deployment in the IPSec context. Again, the rfc does support negotiations via another protocol, or protocols, if and when such protocol becomes available. avram >It also seems odd that there are other suggestions to extend IKE with IKE-CFG >and IKE-XAUTH. IKE is a very good tool to exchange keys in a secure ways >that are then used to enact data encryption and authentication. Can't we >agree to leave it at that? > >If there is a need to add other IP Peer negotiation, then perhaps it is time >for a generic IP Peer Protocol ('IPPP'). At the moment, there is no way to >negotiate IPCOMP between hosts, other than to use IKE. Perhaps we need >'IPPP' to cover these extensions for IP in general. > >If you think about what these IKE-klingons are adding, it looks very similar >to PPP NCPs - CCP, IPCP, CHAP etc. Perhaps running an IP version of these >protocols following the end of Phase-2 would allow us to leave IKE pure, and >we would not be in the silly position of having IPCOMP SAs. > >I would even go so far as to say that the policy (subnet,range,address) >negotiation could be stripped from phase2 as well. IKE phase2 would then >negotiate just the protocols used to protect data and lifetime/lifedata. Any >restrictions to be applied to packets could then be negotiated/exchanged by >'IPPP' in a 'policy phase'. >In some cases (most, I'd say), no policy needs to be sent - 'send anything'. > >Maybe I go to far, but there does seem to be a need for a protocol to >negotiate peer to peer items for VPNs and non-VPNs that would not be bound >to IPSEC/IKE. > >At the very least, this may allow host peers to negotiate IPCOMP, and allow >the Security Gateways to worry about encryption/authentication enforcement. > >Any votes of support for a draft? >Steve. > > > > > >-----Original Message----- >From: Tim Jenkins [mailto:tjenkins@TimeStep.com] >Sent: Wednesday, June 02, 1999 4:40 PM >To: ipsec@lists.tislabs.com >Cc: John.Shriver@intel.com; John Shriver >Subject: New MIB Drafts Submitted > > >Greetings, > >A new version of IPSec monitoring MIB document is available at >, >and has been submitted to the internet-drafts registry. > >Also, a new document, also part of the IPSec MIB series of >documents has also been submitted. This document is the >DOI-independent portion of the ISAKMP monitoring MIB, at >. > >Due to the embedded page control characters, it should be >transferred as BINARY, not text. > >Comments requested. > > >Tim and John > >Note: I have received comments that the FTP server on >the machine above does not respond to all types of FTP >requests. I have tried to get this changed, but have >had no luck yet. If you have trouble, email me and >I will email copies back. > >--- >Tim Jenkins TimeStep Corporation >tjenkins@timestep.com http://www.timestep.com >(613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@lists.tislabs.com Thu Jun 3 19:10:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA21538; Thu, 3 Jun 1999 19:10:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09191 Thu, 3 Jun 1999 20:22:33 -0400 (EDT) Message-Id: <199906040031.RAA07270@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Thu, 03 Jun 1999 13:48:14 PDT." <3756EA0E.23AEEF14@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7267.928456260.1@network-alchemy.com> Date: Thu, 03 Jun 1999 17:31:00 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess it would. But that's not what I'm talking about. The text addresses attributes whose values can be of variable length. So that's Blowfish's key length, Hasty Pudding's block length, or Diffie-Hellman groups of the same type. DES vs. 3DES or SHA vs. MD5 or some distinct invariate algorithm vs. some another distinct invariate algorithm is not what is being discussed. The only reasons presented on why someone would not want to negotiate up are for performance- or memory-constrained implementations. And that's a perfectly legititmate reason why not to. And that seems to be fine with a SHOULD. You should increase security if possible unless you have a good reason why and you fully understand the implications of not doing so. That's a good reason why not to and the understanding seems to be there. Dan. On Thu, 03 Jun 1999 13:48:14 PDT you wrote > Hi Dan, > > Just a quick question on this, with the caveat that I haven't yet taken > the time to review the draft (sorry, I'll get to it soon, I promise): > regarding the question as to whether negotiating upward should be > prefixed with MAY, SHOULD, etc., something has been nagging at me. Isn't > this a local policy issue? I mean, if I specify as a matter of policy > that I want 56-bit DES *only*, wouldn't it be a violation of my policy > to accept 3DES just because you offer it? > > Scott From owner-ipsec@lists.tislabs.com Fri Jun 4 08:19:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23996; Fri, 4 Jun 1999 08:19:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10602 Fri, 4 Jun 1999 09:09:11 -0400 (EDT) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: Dan Harkins cc: ipsec@lists.tislabs.com Message-ID: <85256786.00401D37.00@zule.shiva.com> Date: Fri, 4 Jun 1999 09:11:12 -0400 Subject: Re: Comments on Section 3.1 of new IKE draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan: >> 1. Section 3.1 says >> >> In addition, optional attributes may be negotiated. These >> include a lifetime and a pseudo-random function ("prf"). >> >> Something is wrong here, since the section is called "Mandatory >> Options." It is not clear here whether the intent is that it is >> optional to negotiate these items but that all implementations MUST be >> able to negotiate them, or whether the options truely are optional and >> an implementation is not conformant if it REQUIREs the peer to >> negotiate them. (I know "the answer" from the good ol' boy network, but >> the good ol' boy network is not part of the spec.) > >The good ol' boy network? Is this the same group that said it was OK >to send a message ID in a payload field labeled "SPI"? > >You don't like "Mandatory Option"? Fine. What do you like? Perhaps you >can consult with that gaggle of gregarious geriatrics and get back >to us? What is "the answer"? I was requesting that text be added to the specification describing in what sense the options are optional. The text would go something like "If an implementation does not offer lifetime and pseudo-random function in its proposal, then..." >> 2. Section 3.1. continues: >> >> In addition IKE implementations SHOULD support the following >> values: >> - CAST in CBC mode and Blowfish in CBC mode for encryption >> algorithm. >> - Tiger ([Tiger]) for hash algorithm. >> - Authentication using RSA and DSA signatures, and using RSA >> and El-Gamal public key encryption. >> - Groups 3 through 5 for Diffie-Hellman group. >> >> Charles Kunsinger already made the point that most of these have not >> been discussed on the list, and it is not self-evident whether any of >> these algorithms really rate a SHOULD. Without clear guidelines on when >> and why to use each of these algorithms, arbitrarily adding SHOULDs >> also arbitrarily decreases the overall managability of IKE >> implementations and and increases its overall complexity. Both of these >> decreases the overall security IKE affords. Decreasing managability >> decreases security because it adds more training and configuration cost, >> so increases the the number of places where an IPSec solution won't be >> deployed at all. Increasing complexity decreases security, >> because it becomes harder to verify our own implementations are bug >> free with regard to security issues. All of these need to be MAYs unless >> we can provide operational guidance for them. > >I asked Charles Kunzinger so I'll ask you: do you have a problem with >El-Gamal? Whether or not Charles or I or anyone else has a problem with El-Gamal is not what is at issue here. The issue is what is the criteria by which we decide on MAY, SHOULD, or MUST. >"most of these"? If you actually read RFC2409 you'd see that Blowfish, >Tiger, RSA signatures, DSA signatures, and RSA encryption, and groups >3 and 4 are all there. The only new ones are El-Gamal encryption and >group 5. If you bothered to look at the archives of this list or listened >at IETF meetings you'd have heard a discussion of group 5. So the only >new one is El-Gamal. That's 1 out of 9. Hardly "most". > >I'm going to add RIPE-MD in the next iteration. Do you have a problem >with that? > >It wasn't discussed on the list? OK, fine. Start a discussion then. >Raise some points. > >You want clear guidelines? Would you like me to include a large paragraph >discussing the pros and cons of El-Gamal and RSA? When it's better to use >CAST or Blowfish? That kind of hand-holding is wholly unsuitable for a >document like IKE. > >How is the security of IKE decreased by the inclusion of another optional >authentication method? Do you know some flaw in El-Gamal? If you don't >want to include this authentication method and therefore a knob to >allow it then don't; it's not required. What is the problem? The managability >of your implementation is not effected unless you implement this. Before we had any deployment experience with IKE, I didn't have any problem with loading IKE with a full set of crypto algorithms as MUSTs or SHOULDs. As we gained deployment experience, I have changed my mind. Less seems to be more. People trying to deploy IKE seem overwhelmed and confused by the number of choices presented to them; and every deployment I know of falls back to 3DES and RSA signatures or shared secrets, because the administrators can't make sense of much else. I have seen (many) more than one potential customer throw up their hands and complain they won't deploy anyone's IPSec, because it is just too (many explitives deleted) complicated. This is just my experience for what that's worth--it may not be shared by anyone else--but I do get the same impression from talking with other implementors and from the trade press. Because of this experience, I've migrated to the belief that we should not add any more MUSTs or SHOULDs without first holding a discussion articulating just what problems we think a new algorithm would solve that is not already solved by the mandatory algorithms; otherwise, they become gratuitous implementation overhead at best but more likely a barrier to a successful IKE deployment. For the same reason, I also believe that it is even worth considering to change many of the SHOULDs to MAYs as the document moves forward. ElGamal is a wonderful crypto algorithm and fully worthy of our endorsement via a MAY. The issue is why we should grant it any greater status. >> 3. One issue Section 3.1 raises by omission is the subject of default >> values for each of the options. We've talked about and rejected >> defaults before. I'm wondering whether we have made an error >> in our collective judgement and we need to do something here. >> There are three ways in which defaults might help: >> >> a. improve out-of-the-box interoperability; >> >> b. experience shows it is usually easier to move from a known working >> configuration to another working configuration than to build a >> new configuration from scratch; >> >> c. experience shows it is can be much easier to debug problems by >> moving to a known working configuration, trouble-shooting there, and >> then applying (b), than to trouble-shoot an arbitrary configuration. >> >> Even if this reasoning is correct, the IKE specification may not be >> the right place to document the defaults. We have rejected defaults >> before because it is never clear that good defaults today will be good >> ones tomorrow. Maybe we need a separate document a la the "profiles" >> or implementers' agreement from the ISO days. The profile document >> would have a prescribed finite lifetime, just like DES or IETF drafts, >> to account for the fact that security requirements change? > > When were defaults rejected by this working group? We agreed that DES, > SHA & MD5, group 1, and pre-shared keys were the the mandatory-to-implement > options. We decided this a long time ago. Deep Crack has made the use of > DES very questionable so I changed DES to 3DES and, correspondingly, group > 1 to 2. What is wrong with that? Yeah, this was probably the wrong point to bring up this issue, because the spec does a good job in the options arena. I will raise it again in comments on other sections of the draft. >> Profiles could help in a lot more areas than just defaults. From the >> bake-offs we know that having well-defined profiles speeds >> configuration in general. > >Are you happy with the mandatory-to-implement IPSec transforms but unhappy >with the mandatory-to-implement attributes in IKE? > >You don't like the term "Mandatory Option" yet you fail to suggest any >alternative and allude to some nebulous group of people who know "the >answer". You seem to have some problem with El-Gamal yet you don't say >what it is. What is this unconstructive criticism supposed to accomplish? -- Jesse From owner-ipsec@lists.tislabs.com Fri Jun 4 08:29:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24077; Fri, 4 Jun 1999 08:29:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10682 Fri, 4 Jun 1999 09:30:59 -0400 (EDT) Message-ID: <3757D7B1.C5D707B3@ibm.net> Date: Fri, 04 Jun 1999 09:42:09 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: pau@watson.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: A question on SA establishment in RFC 2408 References: <9906031415.AA22386@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We ran into this at the bakeoff last week..... This would provide value if it was required that the responder retain the Proposal # and Transform #. Since it is only suggested as a SHOULD and since we have found several implementations that have not followed this recommendation, it provide little if no value. Take for example the situation where the initiator proposes 3 proposals, each having 4 transforms and the responder chooses transform #3 in proposal #2. Most implementations followed the recommendation and would send back an SA payload with a single proposal payload with a proposal #2 containing a single transform payload with a transform #3. Others did not follow this recommendation and would return the contents of proposal #2 and transform #3, however numbering them proposal #1 and transform #1. Given this different behavior, the initiator has very little choice other than to go back through all proposed proposals and transforms with the reply looking for a match. Mike Williams IBM AS4/00 TCP/IP Development pau@watson.ibm.com wrote: > My apology if this question has been raised before. > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA establishment, > in its last paragraph before section 4.2.1, it states : > > ".......The responder > SHOULD retain the Proposal # field in the Proposal payload and the > Transform # field in each Transform payload of the selected Proposal. > ..." > > My question is about the word "SHOULD". This word means the responder > does not have to retain the proposal and transform numbers. If it does > not retain the numbers, then what numbers should be used in the > "proposal number" and "transform number" fields in the proposal and > transform payloads sent from the responder to the initiator ? > > A related and more fundamental question is that how the initiator > could determine if the responder retains the numbers or not ? > > Thanks in advance. > > Pau-Chen From owner-ipsec@lists.tislabs.com Fri Jun 4 08:34:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24123; Fri, 4 Jun 1999 08:34:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10706 Fri, 4 Jun 1999 09:40:48 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB9E3@exchange> From: Tim Jenkins To: Mike Williams , pau@watson.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: A question on SA establishment in RFC 2408 Date: Fri, 4 Jun 1999 09:51:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Even if the responder kept the original proposal # and transform #, wouldn't it be prudent to check that they match the contents of those that the initiator sent? If so, what's the point of keeping the numbers the same? (Other than a faster lookup for comparison?) You still have to check the contents of the returned proposal against your policy again anyway... Or is this too paranoid? --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Mike Williams [mailto:mikewill@ibm.net] > Sent: June 4, 1999 9:42 AM > To: pau@watson.ibm.com > Cc: ipsec@lists.tislabs.com > Subject: Re: A question on SA establishment in RFC 2408 > > > We ran into this at the bakeoff last week..... > > This would provide value if it was required that the > responder retain the > Proposal # and Transform #. Since it is only suggested as a > SHOULD and since > we have found several implementations that have not followed this > recommendation, it provide little if no value. > > Take for example the situation where the initiator proposes 3 > proposals, each > having 4 transforms and the responder chooses transform #3 in > proposal #2. > Most implementations followed the recommendation and would > send back an SA > payload with a single proposal payload with a proposal #2 > containing a single > transform payload with a transform #3. Others did not follow this > recommendation and would return the contents of proposal #2 > and transform #3, > however numbering them proposal #1 and transform #1. Given > this different > behavior, the initiator has very little choice other than to > go back through > all proposed proposals and transforms with the reply looking > for a match. > > Mike Williams > > IBM AS4/00 TCP/IP Development > > > > pau@watson.ibm.com wrote: > > > My apology if this question has been raised before. > > > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA > establishment, > > in its last paragraph before section 4.2.1, it states : > > > > ".......The responder > > SHOULD retain the Proposal # field in the Proposal > payload and the > > Transform # field in each Transform payload of the > selected Proposal. > > ..." > > > > My question is about the word "SHOULD". This word means > the responder > > does not have to retain the proposal and transform > numbers. If it does > > not retain the numbers, then what numbers should be used in the > > "proposal number" and "transform number" fields in the > proposal and > > transform payloads sent from the responder to the initiator ? > > > > A related and more fundamental question is that how the initiator > > could determine if the responder retains the numbers or not ? > > > > Thanks in advance. > > > > Pau-Chen > From owner-ipsec@lists.tislabs.com Fri Jun 4 09:08:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24354; Fri, 4 Jun 1999 09:08:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10797 Fri, 4 Jun 1999 10:00:46 -0400 (EDT) From: pau@watson.ibm.com Date: Fri, 4 Jun 1999 10:07:54 -0400 Message-Id: <9906041407.AA23464@secpwr.watson.ibm.com> To: mikewill@ibm.net, pau@watson.ibm.com, tjenkins@TimeStep.com Subject: RE: A question on SA establishment in RFC 2408 Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: xdonyjd2VpWqy32derMP9A== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim, IBM's code does check the responder's repoly against the initiator's list of proposals. I wrote the code that way and I have no arguments there. I like the numbers to be retained precisely for the reason you mentioned, faster lookup for comparison; I remember that was the reason why retaining these numbers was introduced into the draft initially. IMHO, if the numbers are not retained, then RFC 2408 should state clearly what values should be used in their places to avoid ambiguity on the initiator's side. Pau-Chen > From tjenkins@TimeStep.com Fri Jun 4 09:48:11 1999 > Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB9E3@exchange> > From: Tim Jenkins > To: Mike Williams , pau@watson.ibm.com > Cc: ipsec@lists.tislabs.com > Subject: RE: A question on SA establishment in RFC 2408 > Date: Fri, 4 Jun 1999 09:51:25 -0400 > Mime-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2232.9) > Content-Type: text/plain; charset="iso-8859-1" > Content-Length: 2928 > Status: RO > > Even if the responder kept the original proposal # and transform #, wouldn't > it be prudent to check that they match the contents of those that the > initiator sent? > > If so, what's the point of keeping the numbers the same? (Other than a > faster lookup for comparison?) You still have to check the contents of the > returned proposal against your policy again anyway... > > Or is this too paranoid? > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > > -----Original Message----- > > From: Mike Williams [mailto:mikewill@ibm.net] > > Sent: June 4, 1999 9:42 AM > > To: pau@watson.ibm.com > > Cc: ipsec@lists.tislabs.com > > Subject: Re: A question on SA establishment in RFC 2408 > > > > > > We ran into this at the bakeoff last week..... > > > > This would provide value if it was required that the > > responder retain the > > Proposal # and Transform #. Since it is only suggested as a > > SHOULD and since > > we have found several implementations that have not followed this > > recommendation, it provide little if no value. > > > > Take for example the situation where the initiator proposes 3 > > proposals, each > > having 4 transforms and the responder chooses transform #3 in > > proposal #2. > > Most implementations followed the recommendation and would > > send back an SA > > payload with a single proposal payload with a proposal #2 > > containing a single > > transform payload with a transform #3. Others did not follow this > > recommendation and would return the contents of proposal #2 > > and transform #3, > > however numbering them proposal #1 and transform #1. Given > > this different > > behavior, the initiator has very little choice other than to > > go back through > > all proposed proposals and transforms with the reply looking > > for a match. > > > > Mike Williams > > > > IBM AS4/00 TCP/IP Development > > > > > > > > pau@watson.ibm.com wrote: > > > > > My apology if this question has been raised before. > > > > > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA > > establishment, > > > in its last paragraph before section 4.2.1, it states : > > > > > > ".......The responder > > > SHOULD retain the Proposal # field in the Proposal > > payload and the > > > Transform # field in each Transform payload of the > > selected Proposal. > > > ..." > > > > > > My question is about the word "SHOULD". This word means > > the responder > > > does not have to retain the proposal and transform > > numbers. If it does > > > not retain the numbers, then what numbers should be used in the > > > "proposal number" and "transform number" fields in the > > proposal and > > > transform payloads sent from the responder to the initiator ? > > > > > > A related and more fundamental question is that how the initiator > > > could determine if the responder retains the numbers or not ? > > > > > > Thanks in advance. > > > > > > Pau-Chen > > > From owner-ipsec@lists.tislabs.com Fri Jun 4 12:01:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25901; Fri, 4 Jun 1999 12:01:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11238 Fri, 4 Jun 1999 13:13:25 -0400 (EDT) Message-ID: <37580B3C.1CA0325D@redcreek.com> Date: Fri, 04 Jun 1999 10:22:04 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <199906040031.RAA07270@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Dan Harkins wrote: > > I guess it would. But that's not what I'm talking about. The text > addresses attributes whose values can be of variable length. So that's > Blowfish's key length, Hasty Pudding's block length, or Diffie-Hellman > groups of the same type. DES vs. 3DES or SHA vs. MD5 or some distinct > invariate algorithm vs. some another distinct invariate algorithm is not > what is being discussed. > I guess I don't see the difference (for purposes of this discussion) between increasing from DES to 3DES, and doubling Blowfish's keylength, and increasing the DH modulus length. Either way, I think it's a local policy matter, and should not be legislated in any way by this document. I think that if you must say anything at all, then MAY is the appropriate qualifier. > The only reasons presented on why someone would not want to negotiate > up are for performance- or memory-constrained implementations. And that's > a perfectly legititmate reason why not to. And that seems to be fine > with a SHOULD. You should increase security if possible unless you have > a good reason why and you fully understand the implications of not doing > so. That's a good reason why not to and the understanding seems to be > there. > The text says Certain negotiable attributes have ranges or multiple acceptable values. For instance, if the policy specification on a peer mandates group 2 but is offered group 5, as part of an otherwise acceptable protection suite, the peer SHOULD accept that value as it provides more security than demanded. I think that if the policy specification on a peer MANDATES group 2, the peer MUST NOT accept any other value. ...SA lifetimes pose similar issues. If a peer has a local policy which requires SAs live for no more than 2 hours and is offered a protection suite which contains a lifetime value of 1 hour, the peer SHOULD accept that value as it provides less opportunity for key exposure. I agree that lifetimes are a different case, in that either peer may terminate the SA in their own time, so that the one with the lower lifetime is in an equivalent state if he permits the SA with the other side asking for a larger lifetime. That is, the one with the lower lifetime simply terminates when appropriate, according to local policy. More text from the same stretch: It is therefore possible to be in a situation where Alice can successfully initiate an IKE exchange with Bob but not the other way around. A simple way around this situation is to not enforce local policy and accept any lifetime offered or any group offered. This behavior is strongly discouraged; implementations SHOULD NOT ignore local policy. If an implementation accepts a protection suite all values of that protection suite MUST be honored-- in other words, implementations MUST NOT ignore lifetime or Diffie-Hellman group offers and just "do their own thing". SHOULD NOT ignore local policy? I'm really surprised by this text. Maybe I'm misinterpreting, and if so, I'm sure you'll correct me, but when is it *ever* okay to ignore local policy? If we say anything at all about this, shouldn't it be that an IKE implementation MUST NOT ignore local policy under any circumstances? Scott From owner-ipsec@lists.tislabs.com Fri Jun 4 12:49:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26330; Fri, 4 Jun 1999 12:49:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11362 Fri, 4 Jun 1999 14:06:09 -0400 (EDT) Message-Id: <199906041814.LAA10463@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Fri, 04 Jun 1999 10:22:04 PDT." <37580B3C.1CA0325D@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10460.928520073.1@network-alchemy.com> Date: Fri, 04 Jun 1999 11:14:33 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That text is going to be re-written along the lines of what I said in <199906030424.VAA04924@potassium.network-alchemy.com> on the 2nd of June. I'm sorry you don't see a difference between the two. You probably won't get much argument about DES vs. 3DES but when comparing two different encryption algorithms the comparison is not quite as straightforward as increasing the key length of a variable key cipher. Those are quite different. It seems quite obvious to me and also to several people I talked to that negotiating up an attribute whose value can be a range (as opposed to attributes like encryption algorithm which are decidedly NOT ranges) is the wise thing to do. If you want to make a box that accepts 3DES when configured for DES or SHA when configured for MD5 then knock yourself out. It's just that that is not going to be in the draft and I don't see a point in having a discussion along those lines. This is not legislation. It is a statement of what a common sense negotiation technique should be. You think MAY is appropriate? What's wrong with SHOULD? Negotiating up the key length, block size, # of rounds, and Diffie-Hellman group will make you 1) more secure and 2) more interoperable in more situations. Is that not a good thing? I'd say it should be a MUST except that there are some valid situations-- a memory- or performance-challenged box for instance-- where one might not want to do that. You're free to not do this if you fully understand the implications of what you're doing (namely, that you're throwing away a chance to use stronger crypto and possibly refusing to interoperate with people) but in general this is the behavior that SHOULD be done. Mandating that group 2 and group 2 only be negotiated is stupid. We can't bar stupidity but we can say that if you choose to do something stupid you should know the full ramifications of your stupidity. As far as SHOULD NOT ignore local policy, I wrote that because there are lots and lots of implementations that do and I knew I'd get heat if I unilaterally declared them uncompliant. There are lots of people who just ignore what the locally configured lifetime is and do their own thing. That seems very wrong to me but my sense of right and wrong and what is common sense and what is not is obviously not shared by all so I decided SHOULD NOT. But, as I said in the beginning of this email, that text is being rewritten. Dan. On Fri, 04 Jun 1999 10:22:04 PDT you wrote > Hi Dan, > > Dan Harkins wrote: > > > > I guess it would. But that's not what I'm talking about. The text > > addresses attributes whose values can be of variable length. So that's > > Blowfish's key length, Hasty Pudding's block length, or Diffie-Hellman > > groups of the same type. DES vs. 3DES or SHA vs. MD5 or some distinct > > invariate algorithm vs. some another distinct invariate algorithm is not > > what is being discussed. > > > > I guess I don't see the difference (for purposes of this discussion) > between increasing from DES to 3DES, and doubling Blowfish's keylength, > and increasing the DH modulus length. Either way, I think it's a local > policy matter, and should not be legislated in any way by this document. > I think that if you must say anything at all, then MAY is the > appropriate qualifier. > > > The only reasons presented on why someone would not want to negotiate > > up are for performance- or memory-constrained implementations. And that's > > a perfectly legititmate reason why not to. And that seems to be fine > > with a SHOULD. You should increase security if possible unless you have > > a good reason why and you fully understand the implications of not doing > > so. That's a good reason why not to and the understanding seems to be > > there. > > > > The text says > > Certain negotiable attributes have ranges or multiple acceptable > values. For instance, if the policy specification on a peer mandates > group 2 but is offered group 5, as part of an otherwise acceptable > protection suite, the peer SHOULD accept that value as it provides > more security than demanded. > > > > I think that if the policy specification on a peer MANDATES group 2, the > peer MUST NOT accept any other value. > > > ...SA lifetimes pose similar issues. If a > peer has a local policy which requires SAs live for no more than 2 > hours and is offered a protection suite which contains a lifetime > value of 1 hour, the peer SHOULD accept that value as it provides > less opportunity for key exposure. > > > > I agree that lifetimes are a different case, in that either peer may > terminate the SA in their own time, so that the one with the lower > lifetime is in an equivalent state if he permits the SA with the other > side asking for a larger lifetime. That is, the one with the lower > lifetime simply terminates when appropriate, according to local policy. > > More text from the same stretch: > > It is therefore possible to be in a situation where Alice can > successfully initiate an IKE exchange with Bob but not the other way > around. A simple way around this situation is to not enforce local > policy and accept any lifetime offered or any group offered. This > behavior is strongly discouraged; implementations SHOULD NOT ignore > local policy. If an implementation accepts a protection suite all > values of that protection suite MUST be honored-- in other words, > implementations MUST NOT ignore lifetime or Diffie-Hellman group > offers and just "do their own thing". > > SHOULD NOT ignore local policy? I'm really surprised by this text. Maybe > I'm misinterpreting, and if so, I'm sure you'll correct me, but when is > it *ever* okay to ignore local policy? If we say anything at all about > this, shouldn't it be that an IKE implementation MUST NOT ignore local > policy under any circumstances? > > Scott From owner-ipsec@lists.tislabs.com Fri Jun 4 12:50:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26339; Fri, 4 Jun 1999 12:50:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11343 Fri, 4 Jun 1999 13:55:46 -0400 (EDT) Message-ID: <37581529.857CBC33@cyphers.net> Date: Fri, 04 Jun 1999 11:04:49 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Comments on Section 3.1 of new IKE draft References: <85256786.00401D37.00@zule.shiva.com> 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 IKE is not a world unto itself. IKE needs to operate as a member of a grand unified international security infrastructure. The "deployment" of IKE today is miniscule compared to what it will be in the future. Every other security working group (as far as I can recall...) has specified unpatented algorithms like DSA and ElGamal as their MUST algorithms with RSA left in the MAY or SHOULD category. Requiring an algorithm like RSA specifically *prohibits* the creation of any free product based on IPSec/IKE that is in compliance with the old draft. The many other working groups have shown the way out of this mess, and I applaud this working group for moving forward to encourage the use of unpatented algorithms as well, thus enabling classes of products for this technology which were previously impossible. IKE needs to be a part of the overall infrastructure created by the other working groups. I would be in favor of moving RSA to MAY with ElGamal in SHOULD, but I think the current draft reflects a sound melding of requirements and SHOULDs based on IKE's current deployment and the need for unpatented algorithms. In addition, it is *always* a good idea to have a backup algorithm. The encryption modes were previously so tied to RSA that most people just called them the RSA encryption modes. Now IKE has a good balance where encryption can be accomplished with ElGamal or RSA, signing with DSA or RSA, hashing with Tiger or SHA-1, and encryption with CAST or 3DES. I'd really like a 2048 bit MODP group now... ;-) - -Will Jesse Walker wrote: > Before we had any deployment experience with IKE, I didn't have > any problem with loading IKE with a full set of crypto algorithms > as MUSTs or SHOULDs. As we gained deployment experience, I have > changed my mind. Less seems to be more. People trying to deploy > IKE seem overwhelmed and confused by the number of choices > presented to them; and every deployment I know of falls back to > 3DES and RSA signatures or shared secrets, because the > administrators can't make sense of much else. I have seen (many) > more than one potential customer throw up their hands and complain > they won't deploy anyone's IPSec, because it is just too > (many explitives deleted) complicated. This is just my experience > for what that's worth--it may not be shared by anyone else--but I > do get the same impression from talking with other implementors > and from the trade press. > > Because of this experience, I've migrated to the belief that we > should not add any more MUSTs or SHOULDs without first holding a > discussion articulating just what problems we think a new algorithm > would solve that is not already solved by the mandatory algorithms; > otherwise, they become gratuitous implementation overhead at best > but more likely a barrier to a successful IKE deployment. For the > same reason, I also believe that it is even worth considering to > change many of the SHOULDs to MAYs as the document moves forward. > ElGamal is a wonderful crypto algorithm and fully worthy of our > endorsement via a MAY. The issue is why we should grant it any > greater status. > > >> 3. One issue Section 3.1 raises by omission is the subject of > >> default values for each of the options. We've talked about and > >> rejected defaults before. I'm wondering whether we have made an > >> error in our collective judgement and we need to do something > >> here. There are three ways in which defaults might help: > >> > >> a. improve out-of-the-box interoperability; > >> > >> b. experience shows it is usually easier to move from a known > >> working configuration to another working configuration than to > >> build a new configuration from scratch; > >> > >> c. experience shows it is can be much easier to debug problems > >> by moving to a known working configuration, trouble-shooting > >> there, and then applying (b), than to trouble-shoot an arbitrary > >> configuration. > >> > >> Even if this reasoning is correct, the IKE specification may not > >> be the right place to document the defaults. We have rejected > >> defaults before because it is never clear that good defaults > >> today will be good ones tomorrow. Maybe we need a separate > >> document a la the "profiles" or implementers' agreement from the > >> ISO days. The profile document would have a prescribed finite > >> lifetime, just like DES or IETF drafts, to account for the fact > >> that security requirements change? > > > > When were defaults rejected by this working group? We agreed that > > DES, SHA & MD5, group 1, and pre-shared keys were the the > mandatory-to-implement > > options. We decided this a long time ago. Deep Crack has made the > > use of DES very questionable so I changed DES to 3DES and, > > correspondingly, > group > > 1 to 2. What is wrong with that? > > Yeah, this was probably the wrong point to bring up this issue, > because the spec does a good job in the options arena. I will raise > it again in comments on other sections of the draft. > > >> Profiles could help in a lot more areas than just defaults. From > >> the bake-offs we know that having well-defined profiles speeds > >> configuration in general. > > > >Are you happy with the mandatory-to-implement IPSec transforms but > >unhappy with the mandatory-to-implement attributes in IKE? > > > >You don't like the term "Mandatory Option" yet you fail to suggest > >any alternative and allude to some nebulous group of people who > >know "the answer". You seem to have some problem with El-Gamal yet > >you don't say what it is. What is this unconstructive criticism > >supposed to accomplish? > > -- Jesse - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQA/AwUBN1gUs6y7FkvPc+xMEQL/jQCgpizdP/49InJFxMDZV18Z5bd9qwgAoIQg TlndwGgTzYIjnUCQ+tewcyew =+Jho -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 4 13:12:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26496; Fri, 4 Jun 1999 13:12:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11413 Fri, 4 Jun 1999 14:25:11 -0400 (EDT) Date: Fri, 4 Jun 1999 14:34:05 -0400 Message-Id: <199906041834.OAA10478@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: skelly@redcreek.com, ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <3756EA0E.23AEEF14@redcreek.com> <199906040031.RAA07270@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> I guess it would. But that's not what I'm talking about. The Dan> text addresses attributes whose values can be of variable Dan> length. So that's Blowfish's key length, Hasty Pudding's block Dan> length, or Diffie-Hellman groups of the same type. DES vs. 3DES Dan> or SHA vs. MD5 or some distinct invariate algorithm vs. some Dan> another distinct invariate algorithm is not what is being Dan> discussed. Hm, I had thought of DES and 3DES to be key-length variants. That's not literally true of course, but close. So I would think that the same action (i.e., "negotiate up") should be allowed in that case. I assume you didn't mean to exclude it; if you don't want to recommend it as much as you're doing for Blowfish etc., that's fine. paul From owner-ipsec@lists.tislabs.com Fri Jun 4 13:24:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26604; Fri, 4 Jun 1999 13:24:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11407 Fri, 4 Jun 1999 14:24:23 -0400 (EDT) Date: Fri, 4 Jun 1999 14:31:52 -0400 Message-Id: <199906041831.OAA10476@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@cabletron.com Cc: shacham@cisco.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: RE: New MIB Drafts Submitted References: <29752A74B6C5D211A4920090273CA3DC4BBC85@new-exc1.ctron.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> I'm not sure I would use the words 'very natural' when Waters,> describing the negotiation of IPCOMP in IKE, and I would Waters,> suggest that IKE was not the right wheel to use in the first Waters,> place, so perhaps invention was required, not reinvention. Perhaps if you were starting with a clean slate, IKE would not have been the place to put IPCOMP. Then again, a major reason for having IPCOMP is to cope with the loss of link-level compression that result when you start encrypting above there. Meanwhile, we do have IPCOMP negotiation in IKE, and it works fine (modulo a detail or two that people have noticed and the new draft is working to clear up). So what are you proposing? To create another protocol to do what IKE already does? Or to take it out of IKE and put it elsewhere? Or was it just an observation with no protocol change intended? paul From owner-ipsec@lists.tislabs.com Fri Jun 4 15:39:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28308; Fri, 4 Jun 1999 15:39:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11696 Fri, 4 Jun 1999 16:36:19 -0400 (EDT) Message-ID: <37583ACB.A650C7A5@redcreek.com> Date: Fri, 04 Jun 1999 13:44:59 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <3756EA0E.23AEEF14@redcreek.com> <199906040031.RAA07270@potassium.network-alchemy.com> <199906041834.OAA10478@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Dan" == Dan Harkins writes: > > Dan> I guess it would. But that's not what I'm talking about. The > Dan> text addresses attributes whose values can be of variable > Dan> length. So that's Blowfish's key length, Hasty Pudding's block > Dan> length, or Diffie-Hellman groups of the same type. DES vs. 3DES > Dan> or SHA vs. MD5 or some distinct invariate algorithm vs. some > Dan> another distinct invariate algorithm is not what is being > Dan> discussed. > > Hm, I had thought of DES and 3DES to be key-length variants. That's > not literally true of course, but close. > > So I would think that the same action (i.e., "negotiate up") should be > allowed in that case. I assume you didn't mean to exclude it; if you > don't want to recommend it as much as you're doing for Blowfish etc., > that's fine. > I should add at this point that I didn't mean to imply that we shouldn't *allow* such behavior. What I meant to say was that we should not give the impression that an implementation SHOULD violate policy, and that I'm not even sure this discussion should be in the doc. Regarding the case where Dan suggested that Alice could succeed if initiating with Bob but not vice versa, I would suggest that this is only because you permit this negotiating up, when in fact, their policies do not intersect. I whole-heartedly agree that this is a maddening consequence of the complexity of all this security business, but still do not think we should RECOMMEND (the RFC2119 equivalent to SHOULD) that it be circumvented. What we are discussing here is local policy. If it seems too complex, this really is an implementation issue. To resolve this, my default configuration in "expert" mode might permit "DH group x or stronger" with priority ordering implied, and it might support a little checkbox which means ONLY x (or something). In any event, I think we've missed the point entirely, that being that it is not up to IKE to decide. IKE is implemented in an application - a service provider for the ipsec core. As such, IKE should not be making any sort of policy decisions. Rather, the kernel (or whatever component) should be requesting that IKE negotiate the SA within a given set of parameters. If the requester specifies DH-2 alone, and no other DH group, then IKE should provide that and that alone, failing if it cannot. I'm surprised this discussion is even occurring. Am I missing something obvious here? Scott From owner-ipsec@lists.tislabs.com Fri Jun 4 17:08:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29409; Fri, 4 Jun 1999 17:08:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11882 Fri, 4 Jun 1999 18:12:42 -0400 (EDT) Message-Id: <199906042221.PAA11335@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Fri, 04 Jun 1999 13:44:59 PDT." <37583ACB.A650C7A5@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11332.928534867.1@network-alchemy.com> Date: Fri, 04 Jun 1999 15:21:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 04 Jun 1999 13:44:59 PDT Scott G. Kelly wrote > > I should add at this point that I didn't mean to imply that we shouldn't > *allow* such behavior. What I meant to say was that we should not give > the impression that an implementation SHOULD violate policy, and that > I'm not even sure this discussion should be in the doc. Regarding the > case where Dan suggested that Alice could succeed if initiating with Bob > but not vice versa, I would suggest that this is only because you permit > this negotiating up, when in fact, their policies do not intersect. I > whole-heartedly agree that this is a maddening consequence of the > complexity of all this security business, but still do not think we > should RECOMMEND (the RFC2119 equivalent to SHOULD) that it be > circumvented. Your religious approach to policy is clouding your vision. The policies do indeed intersect. Alice's says "blowfish of at least 256 bits", Bob says "blowfish of at least 128". The union of the two ends up being Alice's policy. We're not circumventing some Sacred Policy, we're doing what makes sense and increasing security whereever possible makes sense. > What we are discussing here is local policy. If it seems too complex, > this really is an implementation issue. To resolve this, my default > configuration in "expert" mode might permit "DH group x or stronger" > with priority ordering implied, and it might support a little checkbox > which means ONLY x (or something). In any event, I think we've missed > the point entirely, that being that it is not up to IKE to decide. OK, fine you can have "expert mode" and "idiot mode" but what's being recommended in not "idiot mode". > IKE is implemented in an application - a service provider for the ipsec > core. As such, IKE should not be making any sort of policy decisions. > Rather, the kernel (or whatever component) should be requesting that IKE > negotiate the SA within a given set of parameters. If the requester > specifies DH-2 alone, and no other DH group, then IKE should provide > that and that alone, failing if it cannot. Why on earth would you want to specify group 2 and group 2 alone with no other group accepted? Don't say memory- or performance- challenged box because that's the edge condition that keeps this from being a MUST. Give me a valid reason to configure your security is such a manner. It seems to me that a real-world configuration is "do at least group 2", not "group 2 only group 2 and nothing else including group 5". Also, it seems a real-world configuration is "do blowfish with a key length of at least 256 bits", not "do blowfish with a key length of 256 bits no more no less". > I'm surprised this discussion is even occurring. Am I missing something > obvious here? So am I! I can't think of a reason why you wouldn't want to do stronger crypto if given the option. I want to recommend to people to always do stronger crypto because this is a security protocol. If it's possible to do things in a more secure manner, with longer key lengths, and stronger Diffie-Hellman shared secrets then I strongly recommend people to do that. But like I said before, this isn't legislation. People are free to not take this recommenation. We're trying to engineer a security protocol and recommending people do things that are more secure seems like a no-brainer to me. Dan. From owner-ipsec@lists.tislabs.com Fri Jun 4 18:42:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00672; Fri, 4 Jun 1999 18:42:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12095 Fri, 4 Jun 1999 19:50:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 04 Jun 1999 17:58:42 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA12091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wouldn't it be valid for local policy to preclude disclosing the fact of particular crypto capabilities in some contexts? I tend towards the idea that the policy specifiers should say which offers are valid in which contexts; the advice to "lean towards stronger crypto" should fall on their ears. I also feel queasy about the assumption that there is a monotone relation between a parameter and the crypto strength. Embodying this interpretation in IKE might be the sort of thing that returns to haunt. Hilarie From owner-ipsec@lists.tislabs.com Fri Jun 4 19:17:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA04400; Fri, 4 Jun 1999 19:17:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12213 Fri, 4 Jun 1999 20:30:50 -0400 (EDT) Message-ID: <375871C4.E6D86C63@redcreek.com> Date: Fri, 04 Jun 1999 17:39:32 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <199906042221.PAA11335@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Dan Harkins wrote: > > Your religious approach to policy is clouding your vision. The policies do > indeed intersect. Alice's says "blowfish of at least 256 bits", Bob says > "blowfish of at least 128". The union of the two ends up being Alice's > policy. You've substantially changed the discussion basis here. If the policies intersect, then there is no need for the text to begin with, and you can delete it entirely. We're arguing about the case where they do not. You said in the document Certain negotiable attributes have ranges or multiple acceptable values. For instance, if the policy specification on a peer mandates group 2 but is offered group 5, as part of an otherwise acceptable protection suite, the peer SHOULD accept that value as it provides more security than demanded. That's a far cry from what you're saying above, i.e. "blowfish of at least 256 bits". In fact, that is entirely my point. If this is truly the policy, then there is no need for the language in the document, and it should be deleted, as I said. But if, on the other hand, the policy MANDATES something, you are saying it SHOULD be circumvented - and this is a slippery slope. > We're not circumventing some Sacred Policy, we're doing what makes sense > and increasing security whereever possible makes sense. It does not make sense if, for *whatever* reason, the administrator configured it so that you do not use a "stronger" algorithm. It is not up to the IKE implementation to decide what makes sense, or to decide what is "stronger"; it is up to whoever configures the security. > > IKE is implemented in an application - a service provider for the ipsec > > core. As such, IKE should not be making any sort of policy decisions. > > Rather, the kernel (or whatever component) should be requesting that IKE > > negotiate the SA within a given set of parameters. If the requester > > specifies DH-2 alone, and no other DH group, then IKE should provide > > that and that alone, failing if it cannot. > > Why on earth would you want to specify group 2 and group 2 alone with no > other group accepted? Don't say memory- or performance- challenged box > because that's the edge condition that keeps this from being a MUST. Give > me a valid reason to configure your security is such a manner. I might say group 2 or 1, with a preference for group 2 - whatever. You have argued that if you present me with group 5 in this case, I should accept it, or rather, my IKE implementation should accept it, even though the specified policy does not explicitly permit this. This is just plain wrong. Maybe I know something you don't about group 5. In any event, that's irrelevant. I have argued that it is a policy matter, and that policies are sufficiently expressive as to provide for the functionality you want, as should be the request interface into your IKE implementation. Also, an IKE implementation should only do what it's asked to do, and not presume to know what's "best" under any circumstance. > > I'm surprised this discussion is even occurring. Am I missing something > > obvious here? > > So am I! I can't think of a reason why you wouldn't want to do stronger > crypto if given the option. I want to recommend to people to always do > stronger crypto because this is a security protocol. If it's possible to > do things in a more secure manner, with longer key lengths, and stronger > Diffie-Hellman shared secrets then I strongly recommend people to do that. > But like I said before, this isn't legislation. People are free to not > take this recommenation. > > We're trying to engineer a security protocol and recommending people do > things that are more secure seems like a no-brainer to me. The point is, I may have a valid reason for not wanting to use option x. Maybe you think it's stronger, but I know of an exploitable weakness. Maybe I have overhead concerns. Whatever the reason, I should be able to specify (control) the parameters in whatever manner desired, and know that the implementation won't override my settings because it thinks it knows better than me. Scott From owner-ipsec@lists.tislabs.com Fri Jun 4 20:57:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA17039; Fri, 4 Jun 1999 20:57:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12394 Fri, 4 Jun 1999 22:13:04 -0400 (EDT) Message-Id: <199906050221.TAA12205@potassium.network-alchemy.com> To: Bronislav Kavsan cc: "Scott G. Kelly" , Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Fri, 04 Jun 1999 22:08:21 EDT." <37588694.63FE12CC@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12202.928549288.1@network-alchemy.com> Date: Fri, 04 Jun 1999 19:21:28 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is not substantially different than the comment Shawn Mamros had in <3.0.32.19990602114033.00a39230@bl-mail1.corpeast.baynetworks.com> and my response would not be substantially different than the response I gave him. Dan. On Fri, 04 Jun 1999 22:08:21 EDT you wrote > Dan, > > You said: > "We're trying to engineer a security protocol and recommending people do > things that are more secure seems like a no-brainer to me." > > Sounds good, but what if I value "better performance" more than "more secure >" > and don't want to be surprised by the protocol and paranoid clients forcing m >y > gateway to switch from "secure enough and fast enough" to a "very secure and > very slow"? > > Slava > > > > > From owner-ipsec@lists.tislabs.com Fri Jun 4 20:58:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA17217; Fri, 4 Jun 1999 20:58:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12361 Fri, 4 Jun 1999 22:05:55 -0400 (EDT) Message-ID: <37588694.63FE12CC@ire-ma.com> Date: Fri, 04 Jun 1999 22:08:21 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Dan Harkins CC: "Scott G. Kelly" , Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <199906042221.PAA11335@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, You said: "We're trying to engineer a security protocol and recommending people do things that are more secure seems like a no-brainer to me." Sounds good, but what if I value "better performance" more than "more secure" and don't want to be surprised by the protocol and paranoid clients forcing my gateway to switch from "secure enough and fast enough" to a "very secure and very slow"? Slava From owner-ipsec@lists.tislabs.com Fri Jun 4 21:02:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA17864; Fri, 4 Jun 1999 21:02:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12379 Fri, 4 Jun 1999 22:09:56 -0400 (EDT) Message-Id: <199906050218.TAA12181@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Fri, 04 Jun 1999 17:39:32 PDT." <375871C4.E6D86C63@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12178.928549099.1@network-alchemy.com> Date: Fri, 04 Jun 1999 19:18:19 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I said in a previous post (which you must've ignored) I said the text is changing. Please go back and read it, and the other post it mentions. Since seeing the words "policy" and "mandate" in the same sentence is causing you fits I suggest you stop reading that text and wait for the next rev. This text is necessary because there are enough people running around who say, "if that behavior isn't in the RFC then you can't do it" and enough people who, for whatever reason, want things spelled out in great detail (e.g. what to do with a vendor ID payload that isn't recognized? Drop the connection? Reboot? Panic?). This behavior is the common sense thing to do and that point is underlined by your inability to mention a case why one would not want to do that (when would you want to refuse an offer of a cipher with a key length greater than what you would've offered had you initiated?). There are also some people who think that all things must be symmetric and if Alice can initiate to Bob that Bob must therefore be able to initiate to Alice. Unfortunatly some of these people are the "certifiers" of what is and what is not a compliant IPSec product. I want to expressly point out that that belief is false and there are very good reasons-- in fact, recommended reasons-- why that situation can arise. Dan. On Fri, 04 Jun 1999 17:39:32 PDT you wrote > Hi Dan, > > Dan Harkins wrote: > > > > Your religious approach to policy is clouding your vision. The policies do > > indeed intersect. Alice's says "blowfish of at least 256 bits", Bob says > > "blowfish of at least 128". The union of the two ends up being Alice's > > policy. > > You've substantially changed the discussion basis here. If the policies > intersect, then there is no need for the text to begin with, and you can > delete it entirely. We're arguing about the case where they do not. You > said in the document > > Certain negotiable attributes have ranges or multiple acceptable > values. For instance, if the policy specification on a peer mandates > group 2 but is offered group 5, as part of an otherwise acceptable > protection suite, the peer SHOULD accept that value as it provides > more security than demanded. > > That's a far cry from what you're saying above, i.e. "blowfish of at > least 256 bits". In fact, that is entirely my point. If this is truly > the policy, then there is no need for the language in the document, and > it should be deleted, as I said. But if, on the other hand, the policy > MANDATES something, you are saying it SHOULD be circumvented - and this > is a slippery slope. From owner-ipsec@lists.tislabs.com Fri Jun 4 21:17:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA19541; Fri, 4 Jun 1999 21:17:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12431 Fri, 4 Jun 1999 22:28:45 -0400 (EDT) Message-ID: <37588BEF.3580D93C@ire-ma.com> Date: Fri, 04 Jun 1999 22:31:11 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Dan Harkins CC: "Scott G. Kelly" , Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <199906050221.TAA12205@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Thanks for the clarification. As long as this behaviour is optional (which I missed) - I see no problem with it. Dan Harkins wrote: > This is not substantially different than the comment Shawn Mamros had > in <3.0.32.19990602114033.00a39230@bl-mail1.corpeast.baynetworks.com> and > my response would not be substantially different than the response I > gave him. > > Dan. > > On Fri, 04 Jun 1999 22:08:21 EDT you wrote > > Dan, > > > > You said: > > "We're trying to engineer a security protocol and recommending people do > > things that are more secure seems like a no-brainer to me." > > > > Sounds good, but what if I value "better performance" more than "more secure > >" > > and don't want to be surprised by the protocol and paranoid clients forcing m > >y > > gateway to switch from "secure enough and fast enough" to a "very secure and > > very slow"? > > > > Slava > > > > > > > > > > From owner-ipsec@lists.tislabs.com Fri Jun 4 22:14:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23801; Fri, 4 Jun 1999 22:14:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12515 Fri, 4 Jun 1999 23:19:39 -0400 (EDT) Message-ID: <37589907.222FFDF6@ix.netcom.com> Date: Fri, 04 Jun 1999 20:27:03 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: "Scott G. Kelly" , Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt References: <199906050218.TAA12181@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > As I said in a previous post (which you must've ignored) I said the > text is changing. Please go back and read it, and the other post it > mentions. Since seeing the words "policy" and "mandate" in the same > sentence is causing you fits I suggest you stop reading that text > and wait for the next rev. > Jeeze, Dan. I'll bet your school reports said "does not play well with others". Why don't you call it a night and go get a beer or something? Scott From owner-ipsec@lists.tislabs.com Sat Jun 5 08:24:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06520; Sat, 5 Jun 1999 08:24:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13317 Sat, 5 Jun 1999 09:29:20 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC9E@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com, "Bussiere, Dick" Subject: Proposal for IP Peer protocol Date: Sat, 5 Jun 1999 14:37:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an old existing thread that has a bad subject line.. Paul, What I'm suggesting is that we construct a draft to propose a generic IP Peer Protocol that can be used to negotiate between IP Peers. I'm am suggesting that this protocol is general purpose enough to be easily added to over time and an initial use would be to allow IP peers to negotiate which IPCOMP algorithm will be used. It would be useful for IP peers to be able to negotiate IPCOMP without using IKE. IKE is over the top if you want to just negotiate which compression algorithm you are going to use. As a side effect, such a protocol would allow us to draw a close on the IKE RFCs. Anything that is not concerned with the secure exchange of keys and negotiation of cryptography algorithms could then be moved to a more general purpose protocol. Another side effect could be that hosts can negotiate compression between themselves, and Security Gateways can concern themselves with security. In time, this could remove the need for Security Gateways to worry about high-spec. data compression hardware and all the problems that come with it. Yet another side effect is that compression is not more useful since the is used from source to sink, not just over VPN tunnels: Host1---(IPCOMP)---SG1---(ESP Encryption)---SG2---(IPCOMP)---Host2 Any co-authors out there? Cheers, Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Friday, June 04, 1999 7:32 PM To: Stephen.Waters@cabletron.com Cc: shacham@cisco.com; Subject: RE: New MIB Drafts Submitted >>>>> "Waters," == Waters, Stephen writes: Waters,> I'm not sure I would use the words 'very natural' when Waters,> describing the negotiation of IPCOMP in IKE, and I would Waters,> suggest that IKE was not the right wheel to use in the first Waters,> place, so perhaps invention was required, not reinvention. Perhaps if you were starting with a clean slate, IKE would not have been the place to put IPCOMP. Then again, a major reason for having IPCOMP is to cope with the loss of link-level compression that result when you start encrypting above there. Meanwhile, we do have IPCOMP negotiation in IKE, and it works fine (modulo a detail or two that people have noticed and the new draft is working to clear up). So what are you proposing? To create another protocol to do what IKE already does? Or to take it out of IKE and put it elsewhere? Or was it just an observation with no protocol change intended? paul From owner-ipsec@lists.tislabs.com Sat Jun 5 22:43:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02899; Sat, 5 Jun 1999 22:43:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14286 Sat, 5 Jun 1999 23:47:45 -0400 (EDT) Message-ID: <3759F1A0.64B6A1E@sympatico.ca> Date: Sat, 05 Jun 1999 23:57:20 -0400 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Comments on Section 3.1 of new IKE draft References: <85256785.0042D6AE.00@zule.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse Walker wrote: > 2. Section 3.1. continues: > > In addition IKE implementations SHOULD support the following > values: > - CAST in CBC mode and Blowfish in CBC mode for encryption > algorithm. Should say CAST-128 and reference RFC 2144 to indicate which member of the CAST family of ciphers. [snip] > Charles Kunsinger already made the point that most of these have not > been discussed on the list, and it is not self-evident whether any of > these algorithms really rate a SHOULD. Blowfish and CAST-128 are significantly faster in software than DES let alone 3DES, have adequate keylength, and have withstood considerable analysis. Both specs and implementations are freely avaialble. IPSEC definitely SHOULD support some modern block ciphers, designed after DES and building on the experience gained analysing it. CAST-128 and Blowfish are the obvious candidates. Sure seems self-evident to me. We should add "... MAY support any AES round two candidate cipher ..."? > Without clear guidelines on when > and why to use each of these algorithms, arbitrarily adding SHOULDs ... It's not arbitrary. At least not for block ciphers. Clear guidelines? How about these: Offer both whenever you intiate. Accept either. Prefer either to 3DES. Of the two, prefer CAST-128 because it rekeys faster and has lower memory overhead. From owner-ipsec@lists.tislabs.com Sat Jun 5 22:59:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA03799; Sat, 5 Jun 1999 22:59:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14309 Sun, 6 Jun 1999 00:07:30 -0400 (EDT) Message-ID: <3759F647.5B48EC89@sympatico.ca> Date: Sun, 06 Jun 1999 00:17:11 -0400 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906022109.OAA26844@potassium.network-alchemy.com> <199906031638.JAA21094@gallium.network-alchemy.com> <199906031642.MAA03525@tonga.xedia.com> <00c601beadfc$7b180c50$0101000a@mv.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "David W. Faucher" wrote: > > >> So let me ask the entire working group: should vendors be > > >> prohibited from accepting a key length greater than what they have > > >> configured? Should they be prohibited from accepting a stronger > > >> group? > > > > I may be in the minority here but I see this as an implementation > issue. I would argue that a system should be configured to provide > a level of security comparable to the value of the information > being protected. Overriding that configuration just because it is > capable doesn't necessarily mean it should. > > I'm not arguing for prohibiting such behavior. I'm just not for > recommending it. If an implementation chooses to accept such > behavior that fine. On the other hand, an implementation could > just as easily allow such behavior to be configured. I may be in another minority. One question asked was: > should vendors be prohibited from accepting a key length > greater than what they have configured? My query would have been whether they should be prohibited from REJECTING a key length greater than they've configured. You configure for, say 128-bit Blowfish. I offer 448. The algorithm costs no more to run with the longer key. Clearly you SHOULD accept. I'd like to see the standard say you MUST accept. This applies to things like Blowfish or RC4, where key size does not affect overhead. It clearly does not apply to things like DES vs. 3DES. I don't think it applies to the groups, since those involve a security.overhead trade-off. From owner-ipsec@lists.tislabs.com Sun Jun 6 00:30:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA09914; Sun, 6 Jun 1999 00:30:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14413 Sun, 6 Jun 1999 01:53:09 -0400 (EDT) Message-ID: <375A0EE2.B9B36214@cyphers.net> Date: Sat, 05 Jun 1999 23:02:39 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Comments on Section 3.1 of new IKE draft References: <85256785.0042D6AE.00@zule.shiva.com> <3759F1A0.64B6A1E@sympatico.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 Sandy Harris wrote: > IPSEC definitely SHOULD support some modern block ciphers, designed > after DES and building on the experience gained analysing it. > CAST-128 and Blowfish are the obvious candidates. > > Sure seems self-evident to me. > > We should add "... MAY support any AES round two candidate cipher > ..."? I think we should add such a thing too, but it isn't really possible without actually allocating IDs, so it can't be encouraged without doing so. I'd like to propose that we allocate ID 7 for Twofish. We would like to implement support for that algorithm because it is faster than CAST-5, has passed muster into AES round two, and allows stronger security. - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQA/AwUBN1oOsKy7FkvPc+xMEQKdPQCfT3TzM/Hhk9s2EYzGZv+fQ4OgnC8AoP8W O7osGg5TLX6pT3fA1Yq+Pxoe =QfWB -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jun 7 11:44:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14488; Mon, 7 Jun 1999 11:44:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18589 Mon, 7 Jun 1999 12:21:57 -0400 (EDT) Date: Mon, 7 Jun 1999 12:30:55 -0400 Message-Id: <199906071630.MAA14492@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sandy.harris@sympatico.ca Cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906022109.OAA26844@potassium.network-alchemy.com> <199906031638.JAA21094@gallium.network-alchemy.com> <199906031642.MAA03525@tonga.xedia.com> <00c601beadfc$7b180c50$0101000a@mv.lucent.com> <3759F647.5B48EC89@sympatico.ca> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sandy" == Sandy Harris writes: Sandy> I may be in another minority. One question asked was: >> should vendors be prohibited from accepting a key length greater >> than what they have configured? Sandy> My query would have been whether they should be prohibited Sandy> from REJECTING a key length greater than they've configured. Sandy> You configure for, say 128-bit Blowfish. I offer 448. The Sandy> algorithm costs no more to run with the longer key. Clearly Sandy> you SHOULD accept. I'd like to see the standard say you MUST Sandy> accept. Sandy> This applies to things like Blowfish or RC4, where key size Sandy> does not affect overhead. It clearly does not apply to things Sandy> like DES vs. 3DES. I don't think it applies to the groups, Sandy> since those involve a security.overhead trade-off. Sandy, As you well know, some of us (fortunately not you) have to deal with government restrictions on key length. That means that a particular product may be required to reject (for example) RC4 keys longer than 56 bits even though longer keys require no more processing. The reason is not technical but political. Similarly, in other countries a customer may be prohibited from using keys longer than, say, 128 bits, so again the implementation would have to reject your hypothentical proposal of a 448 bit key. So while I'm comfortable with "should", I cannot accept "must". paul From owner-ipsec@lists.tislabs.com Mon Jun 7 11:46:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14554; Mon, 7 Jun 1999 11:46:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18761 Mon, 7 Jun 1999 12:39:38 -0400 (EDT) To: Paul Koning Cc: sandy.harris@sympatico.ca, ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906022109.OAA26844@potassium.network-alchemy.com> <199906031638.JAA21094@gallium.network-alchemy.com> <199906031642.MAA03525@tonga.xedia.com> <00c601beadfc$7b180c50$0101000a@mv.lucent.com> <3759F647.5B48EC89@sympatico.ca> <199906071630.MAA14492@tonga.xedia.com> From: Derek Atkins Date: 07 Jun 1999 12:48:10 -0400 In-Reply-To: Paul Koning's message of Mon, 7 Jun 1999 12:30:55 -0400 Message-Id: Lines: 34 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Luckily the IETF has a standing policy to ignore local (political) issues (such as key length restrictions) during the standards process. The fact that some of us live in less-free countries does not mean that the standard cannot require us to create something that might be illegal to use in (or export from) our own country. This means we can reasonably ignore political issues when answering these technical questions. So, the question is: TECHNICALLY, is there any reason not to use 'must' in this case? -derek Paul Koning writes: > As you well know, some of us (fortunately not you) have to deal with > government restrictions on key length. That means that a particular > product may be required to reject (for example) RC4 keys longer than > 56 bits even though longer keys require no more processing. The > reason is not technical but political. > > Similarly, in other countries a customer may be prohibited from using > keys longer than, say, 128 bits, so again the implementation would > have to reject your hypothentical proposal of a 448 bit key. > > So while I'm comfortable with "should", I cannot accept "must". > > paul -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 7 11:49:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14618; Mon, 7 Jun 1999 11:49:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18547 Mon, 7 Jun 1999 12:11:57 -0400 (EDT) Date: Mon, 7 Jun 1999 12:19:22 -0400 Message-Id: <199906071619.MAA14488@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Proposal for IP Peer protocol References: <29752A74B6C5D211A4920090273CA3DC4BBC9E@new-exc1.ctron.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> What I'm suggesting is that we construct a draft to propose Waters,> a generic IP Peer Protocol that can be used to negotiate Waters,> between IP Peers. I'm am suggesting that this protocol is Waters,> general purpose enough to be easily added to over time and Waters,> an initial use would be to allow IP peers to negotiate which Waters,> IPCOMP algorithm will be used. I can imagine that an IPPP could someday be useful. Waters,> It would be useful for IP peers to be able to negotiate Waters,> IPCOMP without using IKE. IKE is over the top if you want to Waters,> just negotiate which compression algorithm you are going to Waters,> use. True, but how likely is that? The typical use for compression is dialup lines, but those already DO have compression (X.42mumble, MNP10, whatever). The issue that made IPCOMP important and caused it to appear as part of IKE is that modem based compression doesn't work when you have encryption. So IPCOMP together with IPSEC has an obvious use; IPCOMP alone is not so clear. Can you give an example? Waters,> As a side effect, such a protocol would allow us to draw a Waters,> close on the IKE RFCs. Anything that is not concerned with Waters,> the secure exchange of keys and negotiation of cryptography Waters,> algorithms could then be moved to a more general purpose Waters,> protocol. Sorry, my idiom recognizer doesn't get a match on "draw a close". Does that mean "stop adding new things to..."? When you say "...could then be moved to..." are you proposing to remove the ability to negotiate IPCOMP from IKE? If so, I'm sure you will receive a lot of objection (starting right here), given that it's a capability that is currently defined, implemented, and used, over IKE. If you're proposing to allow IPCOMP to be negotiated using an additional control protocol, that's less harmful, though it seems to add extra complexity for no obvious benefit. For example, would an IPCOMP-supporting IPSEC node then be required to support negotation of IPCOMP both over IKE and over this new protocol? That too is going to meet with objections. Waters,> Another side effect could be that hosts can negotiate Waters,> compression between themselves, and Security Gateways can Waters,> concern themselves with security. In time, this could Waters,> remove the need for Security Gateways to worry about Waters,> high-spec. data compression hardware and all the problems Waters,> that come with it. I don't think so. Again, the best IPCOMP scenario is a road warrior using crypto, and not wanting to suffer the performance hit of no longer having meaningful link level compression. So at that end IPSEC and IPCOMP would both terminate. Similarly, they would at the other end (the security gateway back at the office). The existence of crypto is what forces IPCOMP to be used; innocent third parties don't want to go to the hassle of dealing with compression at all. Also, there are several good implementations of high speed crypto plus compression available, so it's not clear to me that attempting to remove "high spec data compression hardware" from the picture is at all interesting. It's not additional hardware, merely additional gates in existing high speed crypto/compression silicon. Waters,> Yet another side effect is that compression is not more Waters,> useful since the is used from source to sink, not just over Waters,> VPN tunnels: Waters,> Host1---(IPCOMP)---SG1---(ESP Waters,> Encryption)---SG2---(IPCOMP)---Host2 I still don't see when that's interesting. And of course, you can do that today. Still, if enough people want to go to the effort of defining a new protocol that will be used specifically for the IPCOMP-without-IPSEC case, I suppose that's ok. paul From owner-ipsec@lists.tislabs.com Mon Jun 7 15:07:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18047; Mon, 7 Jun 1999 15:07:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19137 Mon, 7 Jun 1999 14:45:03 -0400 (EDT) Message-Id: <199906071854.NAA27727@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Derek Atkins cc: Paul Koning , sandy.harris@sympatico.ca, ipsec@lists.tislabs.com, carney@securecomputing.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "07 Jun 1999 12:48:10 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 7 Jun 1999 13:54:41 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I may be misunderstanding what is being decided here, but as I see it, there is two possible interpretations of the "Must" clause. 1) Implementation must support negotiating up key lengths depending on policy configuration. 2) Implementation must always negotiate up key lengths when possible regardless of policy configuration. If the consensus is that "Must" is option 1, I have no problem with "Must". However, I don't like option 2 at all... > Luckily the IETF has a standing policy to ignore local (political) > issues (such as key length restrictions) during the standards process. > The fact that some of us live in less-free countries does not mean > that the standard cannot require us to create something that might be > illegal to use in (or export from) our own country. This means we > can reasonably ignore political issues when answering these technical > questions. > > So, the question is: TECHNICALLY, is there any reason not to use > 'must' in this case? Depends on what you mean by TECHNICALLY, I don't feel that this is a technical question at all, rather it's a question of policy flexibility. We are making a decision on artificially limiting policy flexability because we feel stronger crypto is always better. Where are we going to draw the line? If an implementation supports a variety of encryption and authentication algorithms, are we going to require that IKE negotiate the best combination of security and resource consumption regardless of local policy? What if (as Scott has suggested) a discovery is made that demonstrates an algorithmic weakness with certain key lengths, are going to preclude the administrator from configuring a secure VPN until such time as we the vendors can come up with a patch? In the end, I will allow the adminstrator to allow or disallow upward negotiation regardless of the standard. Similar to the way we allow administrators to not configure DES depending on policy (even though it's a Must). I prefer that we keep the control of policy in the hands of our customers rather having to explain why they can't. Regards, Michael Carney > > -derek > > Paul Koning writes: > > > As you well know, some of us (fortunately not you) have to deal with > > government restrictions on key length. That means that a particular > > product may be required to reject (for example) RC4 keys longer than > > 56 bits even though longer keys require no more processing. The > > reason is not technical but political. > > > > Similarly, in other countries a customer may be prohibited from using > > keys longer than, say, 128 bits, so again the implementation would > > have to reject your hypothentical proposal of a 448 bit key. > > > > So while I'm comfortable with "should", I cannot accept "must". > > > > paul > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 7 15:51:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18524; Mon, 7 Jun 1999 15:51:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19547 Mon, 7 Jun 1999 16:38:30 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBCC6@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: RE: Proposal for IP Peer protocol Date: Mon, 7 Jun 1999 21:46:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Monday, June 07, 1999 5:19 PM To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com; ippcp@external.cisco.com Subject: Re: Proposal for IP Peer protocol >>>>> "Waters," == Waters, Stephen writes: Waters,> What I'm suggesting is that we construct a draft to propose Waters,> a generic IP Peer Protocol that can be used to negotiate Waters,> between IP Peers. I'm am suggesting that this protocol is Waters,> general purpose enough to be easily added to over time and Waters,> an initial use would be to allow IP peers to negotiate which Waters,> IPCOMP algorithm will be used. Paul>I can imagine that an IPPP could someday be useful. Waters,> It would be useful for IP peers to be able to negotiate Waters,> IPCOMP without using IKE. IKE is over the top if you want to Waters,> just negotiate which compression algorithm you are going to Waters,> use. Paul> True, but how likely is that? The typical use for compression is Paul> dialup lines, but those already DO have compression (X.42mumble, Paul> MNP10, whatever). The issue that made IPCOMP important and caused it Paul> to appear as part of IKE is that modem based compression doesn't work Paul> when you have encryption. Paul> So IPCOMP together with IPSEC has an obvious use; IPCOMP alone is not Paul> so clear. Can you give an example? In the absence of IKE, IPCOMP gives end-to-end compression, not just over each data-link. I guess, as you say, the modem link is the sweet spot, but it does reduce traffic across the entire network without the need to re-compress over each WAN on the way as well as reducing LAN traffic. Waters,> As a side effect, such a protocol would allow us to draw a Waters,> close on the IKE RFCs. Anything that is not concerned with Waters,> the secure exchange of keys and negotiation of cryptography Waters,> algorithms could then be moved to a more general purpose Waters,> protocol. Paul> Sorry, my idiom recognizer doesn't get a match on "draw a close". Paul> Does that mean "stop adding new things to..."? Yes, that's what I should have said. Paul> When you say "...could then be moved to..." are you proposing to Paul> remove the ability to negotiate IPCOMP from IKE? If so, I'm sure you Paul> will receive a lot of objection (starting right here), given that it's Paul> a capability that is currently defined, implemented, and used, over Paul> IKE. Paul> If you're proposing to allow IPCOMP to be negotiated using an Paul> additional control protocol, that's less harmful, though it seems to Paul> add extra complexity for no obvious benefit. For example, would an Paul> IPCOMP-supporting IPSEC node then be required to support negotation of Paul> IPCOMP both over IKE and over this new protocol? That too is going to Paul> meet with objections. As you say, it's too late to pull things from IKE. Any other way to negotiate IPCOMP would need to be an either/or. Waters,> Another side effect could be that hosts can negotiate Waters,> compression between themselves, and Security Gateways can Waters,> concern themselves with security. In time, this could Waters,> remove the need for Security Gateways to worry about Waters,> high-spec. data compression hardware and all the problems Waters,> that come with it. Paul> I don't think so. Paul> Again, the best IPCOMP scenario is a road warrior using crypto, and Paul> not wanting to suffer the performance hit of no longer having Paul> meaningful link level compression. So at that end IPSEC and IPCOMP Paul> would both terminate. Paul> Similarly, they would at the other end (the security gateway back at Paul> the office). The existence of crypto is what forces IPCOMP to be Paul> used; innocent third parties don't want to go to the hassle of dealing Paul> with compression at all. But an alternative is that the client negotiates a tunnel with the security gateway, and then, within that tunnel, negotiates IPCOMP (or any other 'useful' thing) with each node it will communicate with. Paul> Also, there are several good implementations of high speed crypto plus Paul> compression available, so it's not clear to me that attempting to Paul> remove "high spec data compression hardware" from the picture is at Paul> all interesting. It's not additional hardware, merely additional Paul> gates in existing high speed crypto/compression silicon. Good point, although we have been hitting some design issues in scaling hardware compression. Waters,> Yet another side effect is that compression is not more Waters,> useful since the is used from source to sink, not just over Waters,> VPN tunnels: Waters,> Host1---(IPCOMP)---SG1---(ESP Waters,> Encryption)---SG2---(IPCOMP)---Host2 Paul> I still don't see when that's interesting. And of course, you can do Paul> that today. Still, if enough people want to go to the effort of Paul> defining a new protocol that will be used specifically for the Paul> IPCOMP-without-IPSEC case, I suppose that's ok. So far, it's just me, so I'll go to sleep again. Thanks for the well considered comments Paul, very helpful. Steve. Paul> paul From owner-ipsec@lists.tislabs.com Tue Jun 8 06:41:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07629; Tue, 8 Jun 1999 06:41:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21409 Tue, 8 Jun 1999 07:07:53 -0400 (EDT) Message-Id: <199906081116.HAA23093@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-pki-req-02.txt Date: Tue, 08 Jun 1999 07:16:20 -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 : PKI Requirements for IP Security Author(s) : R. Thayer, C. Kunzinger Filename : draft-ietf-ipsec-pki-req-02.txt Pages : 28 Date : 07-Jun-99 The IP Security (IPsec) protocol set now being defined in the IETF uses public key cryptography for authentication in its key management protocol. This document defines the requirements that IPsec has for Public Key Infrastructure (PKI) protocols, formats, and services based on IETF PKIX (a/k/a X.509) certificate schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-02.txt 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-pki-req-02.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-pki-req-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990607101753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990607101753.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 8 17:45:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04075; Tue, 8 Jun 1999 17:45:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23375 Tue, 8 Jun 1999 18:41:53 -0400 (EDT) Date: Tue, 8 Jun 1999 18:50:18 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: IPsec List cc: "John D. Hardin" Subject: can ISAKMP cookies be zero? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think that ISAKMP should allow cookies to be zero, but I cannot find an explicit prohibition. There are hints in RFC 2412 section 2.4.3 and the second last paragraph of section 6, and in RFC 2408 section 2.4. If a responder cookie can be zero, it makes the case of the first row in the table of RFC 2408 section 2.4 hard to distinguish from other rows. Pluto (the IKE daemon that I maintain) forbids 0 cookies. The only interop issue that has come up turned out to be a buggy implementation (I got much thanks from implementor for finding his bug). I think that the protocol can probably survive allowing 0 cookies, but would be less robust. Are 0 cookies prohibited? If so, where? Does anyone think 0 cookies should be allowed? If not, how should this be legislated? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 PS: Thanks to John Hardin for raising this issue. From owner-ipsec@lists.tislabs.com Tue Jun 8 18:56:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA07112; Tue, 8 Jun 1999 18:56:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23565 Tue, 8 Jun 1999 20:07:58 -0400 (EDT) Date: Tue, 8 Jun 1999 17:11:54 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: can ISAKMP cookies be zero? To: hugh@mimosa.com Cc: IPsec List , "John D. Hardin" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Are 0 cookies prohibited? If so, where? rfc's 2522 and 2408. > Does anyone think 0 cookies should be allowed? If not, how should > this be legislated? well, they are only useful as anti-clogging tokens to reduce off-the-path denial-of-service attacks if they are unpredictable. a value of 0 does not satisfy this. photuris (rfc2522.txt) spells out the cookie generation requirements and isakmp (rfc2408.txt) echoes them in section 2.5.3. i'd say a 0 cookie does not satisfy requirement 2: 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie. -gabriel From owner-ipsec@lists.tislabs.com Tue Jun 8 20:53:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA27196; Tue, 8 Jun 1999 20:53:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23727 Tue, 8 Jun 1999 21:50:50 -0400 (EDT) Message-ID: <005701bdb44c$0f765790$2e05010a@HEG> From: "Kalyan Chakravarthy Bade" To: Subject: What's the attribute value for group generator (MODP) ? Date: Mon, 20 Jul 1998 19:05:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01BDB411.62BA4460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0054_01BDB411.62BA4460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In new group mode, what is the attribute value for=20 group generator when the group type is MODP ? =20 I couldn't find it in the draft. Did I miss anything there ? ____________________________________________ Kalyan Chakravarthy B Intoto Inc kalyan@intotoinc.com http://www.intotoinc.com (408) 844-0480 Ext: 302 =20 =20 =20 ------=_NextPart_000_0054_01BDB411.62BA4460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In new group mode,=20 what is the attribute value for
group generator when=20 the group type is MODP ? 
I couldn't find it=20 in the draft. Did I miss = anything there=20 ?
____________________________________________
Kalyan = Chakravarthy=20 B           Intoto = Inc
kalyan@intotoinc.com  =          =20 http://www.intotoinc.com
(408)=20 844-0480 Ext: 302   
     =20
  
------=_NextPart_000_0054_01BDB411.62BA4460-- From owner-ipsec@lists.tislabs.com Wed Jun 9 10:24:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29442; Wed, 9 Jun 1999 10:24:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25422 Wed, 9 Jun 1999 10:40:58 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBCE8@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com, "Waters, Stephen" Subject: RE: Proposal for IP Peer protocol Date: Wed, 9 Jun 1999 15:48:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, to continue this interesting (to me anyway :)) discussion, I was wondering if there has been any thought about using TCP/IP header compression with IPSEC tunnels? Having a quick play with Van Jacobson on my ISDN link, I can reduce the PPP payload for a single byte of telnet from 41bytes to approximately 10bytes. If an IPCP-like negotiation could take place between hosts or between tunnel end-points, then this could deliver the best return on throughput for ACKs and telnet data: IP2 ESP { IP1 TCP Data } ESP-auth-pad For a TCP ACK, the payload inside ESP could be reduced by 75% (4:1). I don't know what the theoretical maximum compression of VJ is, so this could be more I guess with various PPP-like optimisation. I think this would be of particular use to client systems connecting over remote-access VPN tunnels. As I understand it, it is less useful for UDP and Web-page retrieval for different reasons. Would it be possible to add the equivalent of the VJ flags used with PPP in the IPCOMP header (in the reserved 'Flags' octet?). surprisingly, this approach even seems to offer reduction from host to host : IP1 TCP data : 41 bytes IP2 IPCOMP { IP1 TCP data } : with VJ only could be 34 bytes. So, 1) Is VJ worth adding to IPCOMP header for tunnel mode? 2) Is this another option for would-be 'IPP' exchange? 3) Is it worth adding to IKE IPCOMP proposal in some way? Cheers, Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Monday, June 07, 1999 5:19 PM To: Stephen.Waters@cabletron.com Cc: Subject: Re: Proposal for IP Peer protocol >>>>> "Waters," == Waters, Stephen writes: Waters,> What I'm suggesting is that we construct a draft to propose Waters,> a generic IP Peer Protocol that can be used to negotiate Waters,> between IP Peers. I'm am suggesting that this protocol is Waters,> general purpose enough to be easily added to over time and Waters,> an initial use would be to allow IP peers to negotiate which Waters,> IPCOMP algorithm will be used. I can imagine that an IPPP could someday be useful. Waters,> It would be useful for IP peers to be able to negotiate Waters,> IPCOMP without using IKE. IKE is over the top if you want to Waters,> just negotiate which compression algorithm you are going to Waters,> use. True, but how likely is that? The typical use for compression is dialup lines, but those already DO have compression (X.42mumble, MNP10, whatever). The issue that made IPCOMP important and caused it to appear as part of IKE is that modem based compression doesn't work when you have encryption. So IPCOMP together with IPSEC has an obvious use; IPCOMP alone is not so clear. Can you give an example? Waters,> As a side effect, such a protocol would allow us to draw a Waters,> close on the IKE RFCs. Anything that is not concerned with Waters,> the secure exchange of keys and negotiation of cryptography Waters,> algorithms could then be moved to a more general purpose Waters,> protocol. Sorry, my idiom recognizer doesn't get a match on "draw a close". Does that mean "stop adding new things to..."? When you say "...could then be moved to..." are you proposing to remove the ability to negotiate IPCOMP from IKE? If so, I'm sure you will receive a lot of objection (starting right here), given that it's a capability that is currently defined, implemented, and used, over IKE. If you're proposing to allow IPCOMP to be negotiated using an additional control protocol, that's less harmful, though it seems to add extra complexity for no obvious benefit. For example, would an IPCOMP-supporting IPSEC node then be required to support negotation of IPCOMP both over IKE and over this new protocol? That too is going to meet with objections. Waters,> Another side effect could be that hosts can negotiate Waters,> compression between themselves, and Security Gateways can Waters,> concern themselves with security. In time, this could Waters,> remove the need for Security Gateways to worry about Waters,> high-spec. data compression hardware and all the problems Waters,> that come with it. I don't think so. Again, the best IPCOMP scenario is a road warrior using crypto, and not wanting to suffer the performance hit of no longer having meaningful link level compression. So at that end IPSEC and IPCOMP would both terminate. Similarly, they would at the other end (the security gateway back at the office). The existence of crypto is what forces IPCOMP to be used; innocent third parties don't want to go to the hassle of dealing with compression at all. Also, there are several good implementations of high speed crypto plus compression available, so it's not clear to me that attempting to remove "high spec data compression hardware" from the picture is at all interesting. It's not additional hardware, merely additional gates in existing high speed crypto/compression silicon. Waters,> Yet another side effect is that compression is not more Waters,> useful since the is used from source to sink, not just over Waters,> VPN tunnels: Waters,> Host1---(IPCOMP)---SG1---(ESP Waters,> Encryption)---SG2---(IPCOMP)---Host2 I still don't see when that's interesting. And of course, you can do that today. Still, if enough people want to go to the effort of defining a new protocol that will be used specifically for the IPCOMP-without-IPSEC case, I suppose that's ok. paul From owner-ipsec@lists.tislabs.com Wed Jun 9 10:28:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29483; Wed, 9 Jun 1999 10:28:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25450 Wed, 9 Jun 1999 10:55:37 -0400 (EDT) Date: Wed, 9 Jun 1999 11:04:12 -0400 Message-Id: <199906091504.LAA17034@brill.shiva.com> From: John Shriver To: hugh@mimosa.com CC: ipsec@lists.tislabs.com, jhardin@wolfenet.com In-reply-to: (hugh@mimosa.com) Subject: Re: can ISAKMP cookies be zero? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The design of the ISAKMP Phase 1 MIB (draft-ietf-ipsec-isakmp-di-mon-mib-00.txt) assumes that a cookie of 0 is illegal. Without that, we would have to dedicate a "boolean" variable to each cookie to say whether it's valid. (Worse, since the cookies are INDEX's, the booleans would also have to be INDEX's...) It also makes a hell of a lot of sense. From owner-ipsec@lists.tislabs.com Wed Jun 9 11:04:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29794; Wed, 9 Jun 1999 11:04:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25624 Wed, 9 Jun 1999 12:03:34 -0400 (EDT) Date: Wed, 9 Jun 1999 12:12:06 -0400 Message-Id: <199906091612.MAA17182@brill.shiva.com> From: John Shriver To: Stephen.Waters@cabletron.com CC: pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com, Stephen.Waters@cabletron.com In-reply-to: <29752A74B6C5D211A4920090273CA3DC4BBCE8@new-exc1.ctron.com> (Stephen.Waters@cabletron.com) Subject: Re: Proposal for IP Peer protocol Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Van Jacobsen header compression relies on two things that PPP provides and IPsec "tunnels" don't provide: 1. Freedom from reordering of packets. (The anti-replay field is not normally used to prevent reordering.) 2. The receiver gets information about lost (bad CRC) frames. (This is more of a hint, but still important.) Thus, the VJ compression relies very strongly on these characteristics of PPP. By the time you provide the same QoS in IPsec, you will be close to re-inventing TCP. From owner-ipsec@lists.tislabs.com Wed Jun 9 11:32:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00149; Wed, 9 Jun 1999 11:32:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25695 Wed, 9 Jun 1999 12:32:05 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: John Shriver Cc: Stephen.Waters@cabletron.com, pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Proposal for IP Peer protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jun 1999 12:40:56 -0400 From: "Steven M. Bellovin" Message-Id: <19990609164101.CB3D441F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <199906091612.MAA17182@brill.shiva.com>, John Shriver writes: > The Van Jacobsen header compression relies on two things that PPP > provides and IPsec "tunnels" don't provide: > > 2. The receiver gets information about lost (bad CRC) frames. (This > is more of a hint, but still important.) The ESP or AH checksums are much stronger than CRCs, and can be used to discard damaged packets. From owner-ipsec@lists.tislabs.com Wed Jun 9 11:49:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00292; Wed, 9 Jun 1999 11:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25702 Wed, 9 Jun 1999 12:32:09 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBCEA@new-exc1.ctron.com> From: "Waters, Stephen" To: John Shriver Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: RE: Proposal for IP Peer protocol Date: Wed, 9 Jun 1999 17:40:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks John, I was expecting some action on this issue :). I've just been scanning RFC 2507 (IP Header compression. Section 11 seems to suggest that there is a solution to re-ordering) - you drop some efficiency, but it still works, apparently. It does not appear to 'still work' host to host though, since the need to add an extra IP header cancels the advantage of compressing the payload - a TCP/IP one-byte packet would actually get one byte bigger (IP2(20)IPCOMP(4)IP1/TCP(17)Data(1)) Comments from the 'Lulea University' authors of IP Header Compression on the suitability of header compression for the payload of IPSEC tunnels and IP peer-to-peer across the Internet? Thanks, Steve. -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: Wednesday, June 09, 1999 5:12 PM To: Stephen.Waters@cabletron.com Cc: pkoning@xedia.com; ipsec@lists.tislabs.com; ippcp@external.cisco.com; Stephen.Waters@cabletron.com Subject: Re: Proposal for IP Peer protocol The Van Jacobsen header compression relies on two things that PPP provides and IPsec "tunnels" don't provide: 1. Freedom from reordering of packets. (The anti-replay field is not normally used to prevent reordering.) 2. The receiver gets information about lost (bad CRC) frames. (This is more of a hint, but still important.) Thus, the VJ compression relies very strongly on these characteristics of PPP. By the time you provide the same QoS in IPsec, you will be close to re-inventing TCP. From owner-ipsec@lists.tislabs.com Wed Jun 9 11:59:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00377; Wed, 9 Jun 1999 11:59:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25788 Wed, 9 Jun 1999 12:56:25 -0400 (EDT) Date: Wed, 9 Jun 1999 09:59:23 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: Proposal for IP Peer protocol To: John Shriver Cc: Stephen.Waters@cabletron.com, pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: "Your message with ID" <199906091612.MAA17182@brill.shiva.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The Van Jacobsen header compression relies on two things that PPP > provides and IPsec "tunnels" don't provide: > > 1. Freedom from reordering of packets. (The anti-replay field is not > normally used to prevent reordering.) > > 2. The receiver gets information about lost (bad CRC) frames. (This > is more of a hint, but still important.) > > Thus, the VJ compression relies very strongly on these characteristics > of PPP. By the time you provide the same QoS in IPsec, you will be > close to re-inventing TCP. use header compression as per ftp://ftp.isi.edu/in-notes/rfc2507.txt (see section 7.10 - Encapsulating Security Payload Header) From owner-ipsec@lists.tislabs.com Wed Jun 9 12:15:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00520; Wed, 9 Jun 1999 12:15:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25834 Wed, 9 Jun 1999 13:08:11 -0400 (EDT) Date: Wed, 9 Jun 1999 13:16:39 -0400 Message-Id: <199906091716.NAA17224@brill.shiva.com> From: John Shriver To: smb@research.att.com CC: Stephen.Waters@cabletron.com, pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com In-reply-to: <19990609164101.CB3D441F16@SIGABA.research.att.com> (smb@research.att.com) Subject: Re: Proposal for IP Peer protocol Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: John Shriver Subject: Re: Proposal for IP Peer protocol Date: Wed, 09 Jun 1999 12:40:56 -0400 From: "Steven M. Bellovin" In message <199906091612.MAA17182@brill.shiva.com>, John Shriver writes: > The Van Jacobsen header compression relies on two things that PPP > provides and IPsec "tunnels" don't provide: > > 2. The receiver gets information about lost (bad CRC) frames. (This > is more of a hint, but still important.) The ESP or AH checksums are much stronger than CRCs, and can be used to discard damaged packets. Yes, the Digests are much stronger than CRC's. But, on PPP, a CRC error is an almost reliable indication of packet loss. In ESP or AH, packets can be lost without ever seeing a CRC (Digest) error. Moreover, due to multiplexing, even with the detection of a Digest error on an AH or ESP packet cannot reliably pass that information to the correct "connection". But, as noted by someone else, "see RFC 2507" is the right response to the original query. From owner-ipsec@lists.tislabs.com Wed Jun 9 12:26:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00577; Wed, 9 Jun 1999 12:26:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25850 Wed, 9 Jun 1999 13:11:15 -0400 (EDT) Message-ID: <375EA248.E63E3DF7@redcreek.com> Date: Wed, 09 Jun 1999 10:20:08 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalyan Chakravarthy Bade CC: ipsec@lists.tislabs.com Subject: Re: What's the attribute value for group generator (MODP) ? References: <005701bdb44c$0f765790$2e05010a@HEG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kalyan Chakravarthy Bade wrote: > > In new group mode, what is the attribute value for > group generator when the group type is MODP ? > I couldn't find it in the draft. Did I miss anything there ? In new group mode, you select the generator value and include it in the negotiation (it is not fixed). See page 27 of the new IKE draft for details. Scott From owner-ipsec@lists.tislabs.com Wed Jun 9 15:39:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03169; Wed, 9 Jun 1999 15:39:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26424 Wed, 9 Jun 1999 16:39:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 9 Jun 1999 16:50:12 -0400 To: Glen Zorn From: Stephen Kent Subject: Re: New XAUTH draft Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glen, >> >Sorry, apparently I did not make myself clear. I was using the term "user >> >authentication" in the common sense -- that is to say, the sense that is >> >understood in the 95+% of installations where PKI is not existent, let >> >alone ubiquitous. In the day ("just around the corner" for the last 10 >> >years or so) when PKI _is_ ubiquitous, you are absolutely correct. I am >> >obviously somewhat skeptical that that day will come very soon, but I have >> >been wrong before, so suppose I am wrong this time. In that case, the >> >inclusion of XAUTH in IKE does nothing but add useless baggage to an >> >already complex protocol. Conversely, suppose that I am right, and >> >PKI is not ubiquitous for some lengthy period. In this case, the >> >inclusion of XAUTH in IKE will likely slow PKI deployment and reduce the >> >overall security of the system (through the use of comparatively weak >> >user authentication methods). Either way, this is a bad idea. >> >> This has NOTHING to do with whether we have univerals PKIs or not. The >> context we are discussing is a closed community of users who are authorized >> to access resources. This set of users is well known, bounded, etc., >> because the legacy systems you are so fond of can deal only with such >> communities. Thus there is NO need for ubiquitous PKIs to support these >> needs. > >No need to shout, Steve. I felt the need to shout because the mention of a ubiquitous PKI is very much a red herring. >> Organizations need only migrate their Radius databases to local PKI >> databases. In fact, it is especially easy to support online issuance of >> certs to users when you already have a legacy user authentication system. >> > >Great! Sounds like we're in violent agreement that XAUTH is unnecessary, >since the required infrastructure should be easy to install. If I had my druthers, I would not encourage use of legacy systems by making accommodations for them in IPsec. But, the folks selling the technology argue that it is necessary to accomnmodate these systems to facilitate deployment of IPsec. Given the choice between user auth via some legacy means outside of IPsec, and the addition of support for such technoogy in IKE, I vote for the latter, because of the better tie-in to access control, etc. >> >> Also, because IPsec involves access control as a basic security >>service, if >> >> the SPD entries take the form of user names, then it is preferable >>that IKE >> >> be able to verify user identity, in order to support the access control >> >> features of IPsec. >> > >> >Access control means many things to many people. In the scenario under >> >discussion (remote access to some "home" network) it's hard to imagine >> >administrators managing user-level access control via IPsec filters, >> >especially if the home network is at all dynamic. >> >> Access control can be applied at various levels of granularity, true. I >> know your preference here, since we've just concluded an extended debate on >> this in the context of L2TP. You clearly didn't feel that IPsec access >> control was useful, > >On the contrary, IPsec filtering is certainly useful, and not a bad hack >(though rather difficult to configure). > >> and thus argued against pointing out the access control >> differences between L2TP's use of IPsec vs. native IPsec use. Part of your >> argument was that PPP implementations provide appropriate access controls, >> even though such controls are not part of the standards. >> > >Actually, my main point was that IPsec filtering is less a security >feature than an efficiency hack. It should be obvious that equivalent >packet filters applied _at either end_ of a tunnel will have the same >effect on security; it _is_ more efficient (in terms of bandwidth) to >apply the filters before the traffic enters the tunnel, however. Also, >there are standards and standards; even though packet filtering in cisco >routers is not "standard" I'll wager that there are far more people who >can successfully configure a cisco filter than can configure IKE... Filtering at the source is not security-equivalent to filtering at the destination. The reason for filtering at the destination is to ensure that the range of traffic being sent matches what was negotiated when the SA was established. This is a critical security issue, and one of the reasons that we debated how to phrase the differences between direct use of IPsec and use if IPsec under PPTP for a while. Also, your use of terminology here is a bit odd, i.e., "configure IKE." IKE is not where packet filtering occurs; filtering is an integral part of IPsec, while IKE is optional. >> >> If another protocol is employed to veriy user identity, >> >> then one creates a more complex interdependence between IPsec and the >>other >> >> protocol, right? >> > >> >Not sure I understand. Is the "other protocol" RADIUS? If so, there is a >> >much bigger problem then interdependence complexity, due to the severe and >> >well-known security problems with the RADIUS protocol (especially in a >> >proxied environment. >> >> I was not focusing on any specific authentication protocol, just making a >> general observation. >> > >Oh, OK. I'm still not sure that I see a great deal of complexity. It >seems that the hardest thing would be to make sure that the SA goes away >when the user logs off or if user auth fails. Is that required, though? See my comments above re the need to tie user auth to access controls in IPsec. Steve From owner-ipsec@lists.tislabs.com Wed Jun 9 17:27:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA05422; Wed, 9 Jun 1999 17:27:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26595 Wed, 9 Jun 1999 18:30:59 -0400 (EDT) Message-ID: <001e01bdb4dc$71ed16d0$2e05010a@HEG> From: "Kalyan Chakravarthy Bade" To: "Scott G. Kelly" Cc: References: <005701bdb44c$0f765790$2e05010a@HEG> <375EA248.E63E3DF7@redcreek.com> Subject: Re: What's the attribute value for group generator (MODP) ? Date: Tue, 21 Jul 1998 12:19:12 -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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > In new group mode, what is the attribute value for > > group generator when the group type is MODP ? > > I couldn't find it in the draft. Did I miss anything there ? > > In new group mode, you select the generator value and include it in the > negotiation (it is not fixed). See page 27 of the new IKE draft for > details. > > Scott Actually, I am looking for the Group Generator class which is not there in the Appendix A of the draft. How do I negotiate a generator value when there is no class defined for that ? There are two other classes for generators, group generator One and two which are used for elliptic curve groups. Can I reuse one of them ? if not, what should be the class I need to fill when negotiating group generator for MODP ? Kalyan. From owner-ipsec@lists.tislabs.com Wed Jun 9 17:31:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA05471; Wed, 9 Jun 1999 17:31:15 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26615 Wed, 9 Jun 1999 18:33:00 -0400 (EDT) Date: Tue, 8 Jun 1999 20:50:56 -0400 (EDT) Message-Id: <199906090050.UAA23617@lists.tislabs.com> To: owner-ipsec@lists.tislabs.com Subject: BOUNCE ipsec@lists.tislabs.com: Non-member submission from ["John D. Hardin" ] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From majordomo-owner Tue Jun 8 20:50:54 1999 Received: from wolfenet.com (root@smtp1.wolfenet.com [207.178.61.5]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id UAA23613 Tue, 8 Jun 1999 20:50:53 -0400 (EDT) Received: from gypsy.rubyriver.com (IDENT:root@evt-pm3-1-p188.wolfenet.com [206.159.28.188]) by wolfenet.com (8.9.3/8.9.3) with ESMTP id RAA06574; Tue, 8 Jun 1999 17:59:57 -0700 (PDT) Received: from localhost (jhardin@gypsy.wolfenet.com [127.0.0.1]) by gypsy.rubyriver.com (8.8.8/8.8.8) with SMTP id RAA22830; Tue, 8 Jun 1999 17:58:44 -0700 Date: Tue, 8 Jun 1999 17:58:43 -0700 (PDT) From: "John D. Hardin" X-Sender: jhardin@gypsy.rubyriver.com To: "D. Hugh Redelmeier" cc: IPsec List Subject: Re: can ISAKMP cookies be zero? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 8 Jun 1999, D. Hugh Redelmeier wrote: > There are hints in RFC 2412 section 2.4.3 Ouch. That doesn't help any: All messages must have either valid cookies or at least one zero cookie. If both cookies are zero, this indicates a request for a cookie; if only the initiator cookie is zero, it is a response to a cookie request. ...which implies that an initiator cookie of zero is acceptable in a cookie request or a response to a cookie request. Does ISAKMP have the concept of cookie requests? -- John Hardin KA7OHZ jhardin@wolfenet.com pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5 PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76 ----------------------------------------------------------------------- In the Lion the Mighty Lion the Zebra sleeps tonight... Dee de-ee-ee-ee-ee de de de we um umma way! ----------------------------------------------------------------------- Tomorrow: Crusade: the Babylon Project From owner-ipsec@lists.tislabs.com Wed Jun 9 17:56:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA05849; Wed, 9 Jun 1999 17:56:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26880 Wed, 9 Jun 1999 19:05:01 -0400 (EDT) Message-ID: From: "John Hawkins" To: "'ipsec'" Subject: NAT and IPSEC INCOMPATIBLE??? Date: Fri, 4 Jun 1999 13:17:56 -0400 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone please help me out (direct reply to my email account pls.)? I apologize if this is not the appropriate group for this type of question. I have a IPSEC client and am trying to use it with NAT to an ISP, with no luck. However, If I use a static IP it works just fine. Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet discovered a reason for conflict in using the two protocols together. Just trying to understand if it is possible.....or if a IPSEC and NAT are just not made to function together. Specifics of the reason this will or won't work would be VERY much appreciated. thank you, John Hawkins PC Tech Support (Nortel Networks) From owner-ipsec@lists.tislabs.com Wed Jun 9 18:03:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA06021; Wed, 9 Jun 1999 18:03:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26927 Wed, 9 Jun 1999 19:07:06 -0400 (EDT) From: James Dunham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Jun 1999 18:46:59 -0400 (EDT) To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, Jim Dunham Subject: Re: Proposal for IP Peer protocol X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14172.13792.883871.786175@dyad.openroute.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Waters, Stephen writes: > > This is an old existing thread that has a bad subject line.. > > Paul, > > What I'm suggesting is that we construct a draft to propose a generic > IP Peer Protocol that can be used to negotiate between IP Peers. I'm > suggesting that this protocol is general purpose enough to be easily > added to over time and an initial use would be to allow IP peers to > negotiate which IPCOMP algorithm will be used. > > It would be useful for IP peers to be able to negotiate IPCOMP without > using IKE. IKE is over the top if you want to just negotiate which > compression algorithm you are going to use. Yes. We could trade a decrease in the resident size of software on IP-only IPComp nodes for an increase in the resident size and complexity of software (including UI and docs) on IPSec/IKE nodes which wish to communicate with them. I may be overemphasizing the hit, but it's not free. In the event that you're not proposing a pure IP-IP solution, I have the following observations: Supporting two mechanisms to negotiate IPComp between IPSec/IKE hosts is not desireable. Moving IPComp negotiation out of IKE into an IPPP would not make things any easier. The order of convergence between IPPP/IPComp and IKE would be significant and would affect the the encapsulation of traffic flowing into an SPD, which could result in unpredictable variations in traffic propagation. Removing the ambiguity by forcing IPPP to finish before IKE begins would be a non-starter. Jim Dunham OpenROUTE Networks, Inc. From owner-ipsec@lists.tislabs.com Wed Jun 9 18:03:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA06036; Wed, 9 Jun 1999 18:03:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26866 Wed, 9 Jun 1999 19:04:01 -0400 (EDT) Message-ID: From: "Heyman, Michael" Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 3 Jun 1999 14:22:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > Sent: Thursday, June 03, 1999 12:39 PM > > > So let me ask the entire working group: should vendors > > be prohibited from accepting a key length greater than > > what they have configured? Should they be prohibited from > > accepting a stronger group? > > Absolutely not and I'd go so far as to make it a SHOULD > instead of a MAY. > > We're trying to design good security, not workarounds for bad > implementations. > Hmmm, this means if a policy _explicitly_ states 128 bit encryption (note, the policy _did not_ state 128 bit encryption or greater), then IKE has the right to change the policy to be 128 bit or greater? IMHO, IKE must act dumb when it comes to policy and must not assume it knows better then whatever set that policy. Here we seem to be arguing that good security is allowing stronger encryption even when stronger encryption is precluded by the policy. I would argue that good security offers no such surprises. I can imagine applications that may not want to manage, or be capable of managing, the extra 320 bits (above 128) possible in in Blowfish. I can imagine machines not wishing to do the extra work required of a stronger group. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN1bxJrXbkJfuXzRQEQK9ZACeNTT47NLq7FWfpLG5YECiBTany78AoLhe W00MD2vdcnzlKZyiPSez+BnP =gcBZ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jun 9 18:07:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA06155; Wed, 9 Jun 1999 18:07:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26888 Wed, 9 Jun 1999 19:06:01 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Tue, 8 Jun 1999 15:17:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B80ED1A0@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > My query would have been whether they should be prohibited > from REJECTING a key length greater than they've configured. > > You configure for, say 128-bit Blowfish. I offer 448. The > algorithm costs no more to run with the longer key. Clearly > you SHOULD accept. I'd like to see the standard say you MUST > accept. This would mean that if you implement an algorithm with variable length then you must support all key lengths? Making this a MUST would render existing systems non-compliant even though they are not currently required to support (eg) larger groups (it is only a MUST to support group 2). I would rather the issue of negotiating up is left to local security policy. Chris From owner-ipsec@lists.tislabs.com Wed Jun 9 18:13:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA06284; Wed, 9 Jun 1999 18:13:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26940 Wed, 9 Jun 1999 19:08:05 -0400 (EDT) Message-Id: <199906070854.KAA01017@waldorf.appli.se> To: ipsec@lists.tislabs.com Subject: SkipJack numbers? Date: Mon, 07 Jun 1999 10:54:16 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has IANA reserved any IKE or IPsec DOI numbers for SkipJack? Should they be asked to, or is that a question to save for later? Niklas From owner-ipsec@lists.tislabs.com Wed Jun 9 19:27:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11944; Wed, 9 Jun 1999 19:27:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27440 Wed, 9 Jun 1999 20:35:26 -0400 (EDT) Message-ID: <375F0A6A.B18536CF@redcreek.com> Date: Wed, 09 Jun 1999 17:44:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kalyan Chakravarthy Bade CC: ipsec@lists.tislabs.com Subject: Re: What's the attribute value for group generator (MODP) ? References: <005701bdb44c$0f765790$2e05010a@HEG> <375EA248.E63E3DF7@redcreek.com> <001e01bdb4dc$71ed16d0$2e05010a@HEG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kalyan Chakravarthy Bade wrote: > > Actually, I am looking for the Group Generator class which is not > there in the Appendix A of the draft. How do I negotiate a generator > value when there is no class defined for that ? > > There are two other classes for generators, group generator One and two > which are used for elliptic curve groups. Can I reuse one of them ? if not, > what should be the class I need to fill when negotiating group generator for > MODP ? > > Kalyan. I'm not sure I understand what you're looking for, based on what you're saying here, but I'll take a shot, and someone will correct me if I'm wrong. I *think* that if you are using a modp group, you want to use group generator one (value 7) as the attribute class ID, followed by the generator value. I agree that there should probably be some more descriptive text in the appendix. Scott From owner-ipsec@lists.tislabs.com Wed Jun 9 19:27:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11953; Wed, 9 Jun 1999 19:27:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27455 Wed, 9 Jun 1999 20:37:10 -0400 (EDT) Message-Id: <3.0.1.32.19990609174850.00e38b78@gateway.hq.freegate.com> X-Sender: jtardo@gateway.hq.freegate.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 09 Jun 1999 17:48:50 -0700 To: "Derrell D. Piper" , Dan Harkins From: Joe Tardo Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) Cc: Paul Koning , ipsec@lists.tislabs.com In-Reply-To: <199906031638.JAA21094@gallium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suppose my policy is configured for NULL encryption, would this mean I MUST encrypt if the offer proposes, say, 3DES first and NULL second? At 09:38 AM 6/3/99 -0700, Derrell D. Piper wrote: >> So let me ask the entire working group: should vendors be prohibited from >> accepting a key length greater than what they have configured? Should they >> be prohibited from accepting a stronger group? > >Absolutely not and I'd go so far as to make it a SHOULD instead of a MAY. > >We're trying to design good security, not workarounds for bad implementations. > >Derrell > > From owner-ipsec@lists.tislabs.com Wed Jun 9 19:40:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA14037; Wed, 9 Jun 1999 19:40:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27411 Wed, 9 Jun 1999 20:27:51 -0400 (EDT) Message-Id: <199906100036.AAA15949@orchard.arlington.ma.us> To: "John Hawkins" cc: "'ipsec'" Subject: Re: NAT and IPSEC INCOMPATIBLE??? In-Reply-To: Message from "John Hawkins" of "Fri, 04 Jun 1999 13:17:56 EDT." Date: Wed, 09 Jun 1999 20:36:55 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > discovered a reason for conflict in using the two protocols together. Just > trying to understand if it is possible.....or if a IPSEC and NAT are just > not made to function together. Specifics of the reason this will or won't > work would be VERY much appreciated. Yep, NAT breaks IPSEC. NAT breaks any protocol which protects IP addresses from modification. AH's checksum includes these header fields, so that's one thing which breaks. NAT also needs to tweak transport-layer checksums (since the source and destination addresses are included in the UDP and TCP checksums). since those checksums are themselves included in the AH or ESP integrity check, and may also be encrypted by ESP as well. - Bill From owner-ipsec@lists.tislabs.com Wed Jun 9 19:49:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15119; Wed, 9 Jun 1999 19:49:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27503 Wed, 9 Jun 1999 20:52:11 -0400 (EDT) Message-Id: <199906100057.JAA07316@swan.png.flab.fujitsu.co.jp> To: ipsec@lists.tislabs.com Cc: hawkinsj@nortelnetworks.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? In-reply-to: Your message of "Wed, 09 Jun 1999 20:36:55 JST" References: <199906100036.AAA15949@orchard.arlington.ma.us> From: Makoto Kubota Date: Thu, 10 Jun 1999 09:57:15 +0900 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > discovered a reason for conflict in using the two protocols together. Just > > trying to understand if it is possible.....or if a IPSEC and NAT are just > > not made to function together. Specifics of the reason this will or won't > > work would be VERY much appreciated. > > Yep, NAT breaks IPSEC. > > NAT breaks any protocol which protects IP addresses from modification. > AH's checksum includes these header fields, so that's one thing which > breaks. Can I have additional question about this? So, if we do NAT before IPSEC, can I usr NAT & IPSec together? For example, Home Office ---[NAT]---[IPSec]--->Internet... Home Office <--[NAT]<--[IPSec]<---Internet... Thanks in advance. From owner-ipsec@lists.tislabs.com Wed Jun 9 20:24:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA19236; Wed, 9 Jun 1999 20:24:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27599 Wed, 9 Jun 1999 21:30:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 09 Jun 1999 19:38:48 -0600 From: "Umesh Muniyappa" To: , Cc: Subject: Re: NAT and IPSEC INCOMPATIBLE??? Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_35635022.523386C9" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_35635022.523386C9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >>> Makoto Kubota 06/09/99 05:57PM >>> > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > discovered a reason for conflict in using the two protocols together. = Just > > trying to understand if it is possible.....or if a IPSEC and NAT are = just > > not made to function together. Specifics of the reason this will or = won't > > work would be VERY much appreciated. >=20 > Yep, NAT breaks IPSEC. >=20 > NAT breaks any protocol which protects IP addresses from modification. > AH's checksum includes these header fields, so that's one thing which > breaks. >>>Can I have additional question about this? >>>So, if we do NAT before IPSEC, can I usr NAT & IPSec together? >>>For example, >>> Home Office ---[NAT]---[IPSec]--->Internet... >>> Home Office <--[NAT]<--[IPSec]<---Internet... >>> Thanks in advance. Yes NAT breaks IPSec if NAT is between the tunnel (IPSec) points. But, NAT can be behind the IPSec.=20 umesh --=_35635022.523386C9 Content-Type: text/x-vcard Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Umesh Muniyappa.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Umesh Muniyappa TEL;WORK:408-967-7753 ORG:Engineer;Border Services Engineering TEL;PREF;FAX:408-967-5560 EMAIL;WORK;PREF;NGW:UMUNIYAPPA@novell.com N:Muniyappa;Umesh TITLE:Engineer X-GWUSERID:UMUNIYAPPA END:VCARD --=_35635022.523386C9-- From owner-ipsec@lists.tislabs.com Wed Jun 9 20:47:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA21695; Wed, 9 Jun 1999 20:47:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27687 Wed, 9 Jun 1999 22:01:16 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199906100209.TAA08188@kc.livingston.com> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: kubota@flab.fujitsu.co.jp (Makoto Kubota) Date: Wed, 9 Jun 1999 19:09:48 -0700 (PDT) Cc: ipsec@lists.tislabs.com, hawkinsj@nortelnetworks.com In-Reply-To: <199906100057.JAA07316@swan.png.flab.fujitsu.co.jp> from "Makoto Kubota" at Jun 10, 99 09:57:15 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > > discovered a reason for conflict in using the two protocols together. Just > > > trying to understand if it is possible.....or if a IPSEC and NAT are just > > > not made to function together. Specifics of the reason this will or won't > > > work would be VERY much appreciated. > > > > Yep, NAT breaks IPSEC. > > > > NAT breaks any protocol which protects IP addresses from modification. > > AH's checksum includes these header fields, so that's one thing which > > breaks. > > Can I have additional question about this? > > So, if we do NAT before IPSEC, can I usr NAT & IPSec together? > For example, > Home Office ---[NAT]---[IPSec]--->Internet... > Home Office <--[NAT]<--[IPSec]<---Internet... > > Thanks in advance. > Yes. Take a look at cheers, suresh From owner-ipsec@lists.tislabs.com Wed Jun 9 20:49:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA21913; Wed, 9 Jun 1999 20:49:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27667 Wed, 9 Jun 1999 21:57:27 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199906100205.TAA08106@kc.livingston.com> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Wed, 9 Jun 1999 19:05:55 -0700 (PDT) Cc: hawkinsj@nortelnetworks.com, ipsec@lists.tislabs.com In-Reply-To: <199906100036.AAA15949@orchard.arlington.ma.us> from "Bill Sommerfeld" at Jun 9, 99 08:36:55 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > discovered a reason for conflict in using the two protocols together. Just > > trying to understand if it is possible.....or if a IPSEC and NAT are just > > not made to function together. Specifics of the reason this will or won't > > work would be VERY much appreciated. > > Yep, NAT breaks IPSEC. > > NAT breaks any protocol which protects IP addresses from modification. > AH's checksum includes these header fields, so that's one thing which > breaks. > > NAT also needs to tweak transport-layer checksums (since the source > and destination addresses are included in the UDP and TCP checksums). > since those checksums are themselves included in the AH or ESP > integrity check, and may also be encrypted by ESP as well. > > - Bill > It is true that End-to-end IPsec will not work with NAT enroute for most applications in practice. I suggest reading for a discussion on end-to-end IPsec vis-a-vis NAT. However, NAT and IPsec can coexist to provide tunnel mode security. discusses how this combination can work. cheers, suresh From owner-ipsec@lists.tislabs.com Wed Jun 9 21:08:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA23251; Wed, 9 Jun 1999 21:08:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26872 Wed, 9 Jun 1999 19:04:04 -0400 (EDT) Message-ID: <6078A04DA8A8D21189DD00A024B211101B9827@lasis.bank.lv> From: Ivars Suba To: ipsec@lists.tislabs.com Subject: RFC2409 Date: Mon, 7 Jun 1999 19:19:38 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB101.8C1A2F44" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEB101.8C1A2F44 Content-Type: text/plain; charset="windows-1257" IPSec/IKE (RFC2409) Public Key Encryption Aggressive mode"(Phase 1) vulnerability is myself advice. It seems that IPSec/IKE Public Key Encryption Revised Aggressive Mode and IPSec/IKE Pre-Shared Key Aggressive Mode also vulnerable to this type of attack (Chess grandmaster). However, they will be stopped at Phase 2 - Quick Mode (ISAKMP payload is Encrypted). If Initiator and Cheater will share DHPrivKey_i, they will continue this attack against Responder in Phase 2 - Quick Mode still :). For more detailed information look in appendice. Best regards, ============================== Ivars Suba Bank of Latvia mailto:ivarss@bank.lv http://www.bank.lv Ph.: +371 7 022 524, Fax: +371 7 022 112 =============================== ------_=_NextPart_000_01BEB101.8C1A2F44 Content-Type: application/vnd.ms-powerpoint; name="CryptAnalysisVPN_IKE.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CryptAnalysisVPN_IKE.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAA0wEAAAAAAAAA EAAA/v///wAAAAD+////AAAAAM8BAADQAQAA0QEAANIBAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9g IRvw5xEAAO1kjCo2prTBY+QCuUymwIMSNwAAVvcAAIX7AACuCAEAzgYBAJCLawDQ+EUAtREAAAD+ eJy8mwl8FUWTwKu754VwREhArnCTgIKIYFAQ+AiHEG4E5BDEgIAkskQOBUEkIKfIYZaVI4ooCCqL gCCnZgP5AD8OlVNXBCJBgcBnQJCIb6pq670kJN/mkTch2X38Kt0zPVPz76o+qnsGBSUBzLxQgACw FMjPJVJaz3L3y/TkyujOpQcEG8nVgPvkb72AshACLD+AQDnulznL/VngNwGlsstKecu0RxFUyj4X 5j1nQVU57tujV68K0D3m+XFx4+NGTqjVK27iiHG94mLGTCidfXUZ7zUAHh294F/1Gq/eXA7PlZaX Q4EX3id9H8llSi3re6+IjASIfgRg6CKEeMnHczyskn/J0QDJyR5JFmFIliqmpoJIKnBqMnhqzBwp Eg/e6ssvPvtPfHYmPvvAq+OnZFh78Bqw+xqsWrVGTst9nsu8erIynH3g0WfJmQiptKeOzXzaOoLK 83EVp3yXJcDdyoZlJukPAslVQvK2PEFqKn89z2uklPeKv7TLW58cjkZKZ58P8Kby01nnjfgHIMxY sNpO0ssDk3S065ZrWOYt1796Sv0vT+WlyXTFuvYG5NCID+7QWN70mlAVTKGyr8ul8Wgd5vLIroBh mbsCnNJEuzy2yaWRlnGHxmQ/xfJDk0udQ5Njl2ihWR441fiicUq4FmfRd3iWcgilPebxXo4d/Hkt pyYhXsISonUlbcIE+lq0H8BTlIyHaQfuoQ24kZySdYHJHAvvsK+yEWoKnlNpmEOdNSjcq5c9Wipb aaJxCo5QnrZaQRfGhgvUbPxWHbxDI32/CF7OojkoGmfjAj80TgnnwhReB0t92nK+nokuc9WnLQvf ArLor4rGmThfF96WW/Qi/EMf92nLe/XscdG4CLf4oXFKGMPleYgq5XMs9FfW8C5lUaYDfmX63emF MiMUoQVV9vbCUvCq6YNLRfNaSTeZyfiF2STpFfzA1KG5pjONND0oyjA6rfkb0AUzYTA5s751hyMJ BuAquTdB0rkwDd+AbZJex6XwAG2EnnQU+lIGuByPDDGceFdLNsJomuI6qO/MRsn5RwanrVnBaG8N IqAk79UleIUuyX10MAfq81RP76C2eig9p0MoRp/FkXoXPq0TsK4egSdUT0xQ7fAZ9TiGq6Z4S6i+ FHkZGmMEtMBMbo87uSfG8xCM4gmItACP0TpcQ7twL32L5+kWBnFFqs0tqSG/TqF8gDLpMHXjyxQM qTQBwjmdo3mu2KG95G5SY9hBO2Eq9VfRFKyjqbt5m0KtdFph9eMb1g/cztUfYlzfw3jXFRXj2qud WroWJPLX4NvSiVCNVpsfoKBxw2mbNdDUa+lKsBHWkmjmnfAup8AVeXpp+G9oDpfgOQhSC6G++gy6 qyOQrkJguf4OkvV6OK+nA+tuEG5CINq8y3PMFUo0CRRqOtDbuhrtUPUpVPVw3L6CRffv+qyVUzOJ 3/L1RqdjkAV1vDUr6yWepBLhIxWo+qt3VT0Vq4PVTV1PTTDdVbBVQp+y9up0k66DzWHdTifqBNVN E8zROx2PV05r2Fdvx8+sT8HXeFP4XtLNW8MweMl8jzNMsowv23Gr2YlJZj/+w5zHw6YyfW260X4z mo6aHXTWXKNfjMWZph6HWkv5cWsbj7B+5bVWOCSZD6GpcYFbV4d1uhHE6XChDRL5g4frE/yOTuHT eiuXMR9yXTOfO5hYHmD68WjTXOQvGdN20gAzjoaZIMf+ToQr7sWmmuNZZbC3vg/BywrdkaqOHara 2qBetFNhuX0UfrBToBSmQEc8CsvwJFzAZImfP4V4adf7RIBXwWP8KQzjJFjEp2EzExzk9uomL1aB cE5VgAbSP2M18UadyulS31CTyP2kjnGmCb9uQNr3tzJ+f0DTTAy9YiJolDmCcWYFTjNDcY6x7Wnm AzvODLe7myfsW7qs/ba+6b6qrrid2qMrzBTGcz6jhVhVktN0bfbXJrJaVtYzckeFCpKGm0DRUobn i6YkkSsiYTpEvBvCH4qc1lXYKWm6eozb6vbe68ONkeOWousxbqFbOtZxWG3A6TqJanh1BEE7vQFb 69PYSQfQUzqMhuteNEaPplf1Ikk/pmi9mTrpbdRA8lqvpsPqP322NKfP7wBD+XMY59PaHZSF5fVj 6Gs14yr0GBvmbbflROvDGK2q4RRVDpepkrhJBWCKPOmCCsLSugqW1GF4W9WX41q4R1XH9XLtO5Kf IueeVw0dxwtjdCA2Ny3QaeyYw/eIaYIVTA28rcvjWR2EB3Qp/EJ0/YcOxjG6Go7VD2C8biDHdXG7 ro2HdQ1MlfxtORdiGvvkc8q8ERa7vzQL/TDn2vQZL3NDSIHpeAlmYyq0wSDFdrDabEepWSId7Uky Pnykati/qS42qqZ2J93FflTXkH7Z107UTe0MPcoONUPsR80S+ymz0B5lttp9zW17kGmK/2ZewzdE Vpiu+ImpLuPqD/YnZpw9wzxkjzBK7jnhTtefu1fple5H9WL3d2ql+y212t1fbXNXUmfcqVDX/hp6 2hthnUhJ3ChxWFHs09zs5rEBDYyv+CrHky4/LTK35Xb0Wq+2zBxN4ZrM/o9Yl3iItZsPWbWgm2sp 7HJZ6mdXM+V2DVTVA2aq1gG7VY+AX9WQgIo6JiBWDw1YoXsE7NdVAq7qy64As9ZVyYx11TGtXdXN /a4q5opVzqRYqJdZafpVa7/uby3R7a3xupwVqE+Y19Q6c5961iyQWrV3bIFGZi3Xd/VQBa09nc6d LmjgtUB50docnhKZZhrDJlMPjppQCLGYu1lHOMZayzVdg6GaazKUdSXCdWs3nLS+hy3WVZhhWaqr FapKWI3VN6al1KijKop/x3Frdsno7btsNn/Dvsv6y4r/Ovkbi1x37NPcW++q8JHctw13UxIeoCOY Rj/gLbqIsijBClyH6vOTIiOoLi+gCryXbDpA5TiVlkskfI430u9SlslPkM0ZeIl34SFOwLUch9O5 P/bnaHxYoutMmosnHMcCW3EH/p2acnGsxHK9myFaj2EmJmFNqWk72oqjROZLvP8x7ZGY/2v8ic7I OsCiylyT6kmNGvBwqsMTqSovpUBeS3/Ql3SCPqUnizTXLPR61/JZ9vb/QdllHIUj6E/KHS3yz1/O 9xZy9r8q0Si8jLOwLV2jZ2mhY9+2oXcogG+x07E953mD5b42dInO0G9MtMhxZHGGItnmTM7dW8u/ ++d8rMyh8RCcoQw+zv/ONznSMc1lfMauIStNX74o/LiVQ1ORYr2+uIwz7Yr0jF2U1rnC25Ku+YyE BlOs9PKluf2S44sQCeX1bAuOJY8dC+NZT01v0kt59swii8GzFT3tmvriVdF+N1v6pumDT/K7fvZl LB++8zyvD7YWCzxLS4o0sqRwEl/k0z599xPtoSj+6Q6frz0Cj1ey3gN5bFrRiuEojqCf6G7tMGsv 7yJNIk+uvP6M1rBv/Vn+qK/YsXevUyr15L/y8eblm8s9ubfMeAXzWZyYzfcNvVdsfGX4fh7Fj+TT l5fvK7liLpW56zoti68l78jm07y12PgUZ9IALl8g3/s8gF8k5YevJn+ezZdG798Tn1PmNdyN94nN fL6JoJX2AVprF1SfjhK/kLuLn/aw0j6JWfVZaUcUm72jaIu9l3YXyDdIoozydpQfvi32qWy+LfZD xch3yP47HS+Qb7xEXQ398h2yT2TzHbLzt/9750uz99GVAvnm4z5q75cvzT6ezZdmNy02vo7ktlMo AAviW40pNMTu6IdP4dFsvj/v0X5F6WMDeRsv4jT2PWvebdbKma3Gyt1z+HueILPMQJltihYHj+Vr fNJnbycaiQns8vkupvAxa1UvfWmoxSMxmsfjG7JCeZM/wdc5CeP4CD7F5/Fv/E9sxDdRy6qH6Jzj /ZWz2BeflrnAadQzzsvyOFTg59GmAfizxBrLaAj2oxiMoEkYQtPRxpV4A7dLegL/kqjuArroLFal C/gEXcMupKgX3cahdANHy/Fk+g3nSLqC/sR1UraRytIuqkXJVJeOUz2ZRxvSb/SorADakMVdqDRH UxBPkfQDcst65lcqwd9RRf6SGvNqiuBZ1Iwn0IP8AlXiwdSS+1BXbkPdOZzacQl6iG0M5tvYjC9g Sz4hsgcb82aszmuwHr+DdXmSY9shDcalfMDx3tQTXtuFwjR+Acfyc/gcD8aOIi35WawvK82qPALL ciyW4LGoeLI4crZIgsi7aIm/g7ycO7AJfyX3/Rf2FRkp+clybh5vwEX8vkiCyBxcyBNxLo9xvE9T lJ4QBmN4P6z22RMKKgtV7fEhXSN3ZedjF8RpBGwgwmvdytBM9cCRojlR5IrqjCV0DwzTg0WmiLyH oforDNHHsJT+FVn9gRnKolOqDH2hQmixqkjjJR2k7qP2cr6x+h3D1M8Yqr4QWSgy0nHriNKdcICp 7Seizo30c/gbm95IujN+J7JGdEzVXTBa98YoPURkNfbUB3GQsMfq2/iqtmiBvo9W6Qq0TVeib3UV +lPSEBNMD5qS1NLcwE7me+xldokkiLzomD9MD8XeelaetV7+Mcz5ainnPW6YjsUGejg2Fe1/E+mk R2IX/Rq21ZOxhX4FG0sarqc6pvwMnhYPvem4D+bMBNXUcKymZuAuGIkeHU6f19P7Ptzf8/KvEnua 0djTzMD5ZiQuEh1F6W9dYRK/CEt89qlRahyeVz+irz5V+FVl1rcPP4rGcTgq+zsSz6zvlHSxmorH 1J4Cv8Rwvl+QRbNHNE7FxX5onH/VMpk/vssXQgtlxAg0aT5tWfgekPOFUKCZggt14W25Tc/GP3XB XwgV1rMHReNs3OaHprjnCzdd5+pQzucXASN4O8fBapOXPzIy//7DnXhTed64xXvvS+QA2M4RkMSd REZAIo+DNzlGessAmMLt4C1uIOdqwKdcC1L4YTjNreEX7gHpck0GL4fz/Akc4C2wUVrERp4h+XFw ll+Gm/ymxL6bxWYn4Tanyz226L8BO/istIm9kMp74JakIXAWysMtScNUCXhM3eRW6jQ/oQ5zfZFy 6hJr8ZRS4dBK1YbZcs176hdeqU7xVJXKw+W4j5wfqCJgi2oCF1UDULoUBOsMLqfPcobcf0pqu09V hL1yzSHVHq6qKLhfR0FD3QKG6HCYqMvAdH2TJ+rz3F+nczPxbF05X1cPgoH6BZiqo+Fj3RH2yfXH dUM4oUMkRT6kr/MukTWSX6LLwgL9AMzTkbBCd4b1ujfs1v3gpH4a0iWPci7QtIZypglUlGimmkGu Zn7hyuYku8yPnKEvcZp2c6oOgjM6DNJ0Y/in7gBVTDdoZdrAcyYCXjK1YaIpI4L8irnBcSadh5tL 3Feks7nJzU1ZaGIegAh5ThsTBV1MV+hjesILko+Xc2+aBrDE3A+JxsByk8qLfH6/6LvtfQzqLm2v oLJB1Ndc5NuWr33Ye9+FHkRTrUF03TrHy805qb3TWgRRuNDMsnJXQfn3YZ1HTjk0QbTfeIg8JOs5 3DHNTHe42cLfGF/7qoV/35FDM9O933iIPCSvoHOaau6p1vN026dt7t1T1dzXvZ7y2MfzBOc0+83z lNdTkcXgKQ9Bjn08REUZjZvwBviZj/gsa4XLTB/accez8cXi2Va4Scg3ma60zEyTJzgljfeSpvj+ /gZbma48L08bzD9XF97riThd7NvKtOdWZgFNd0y6WEhP3oX0Qepl7ueBpqCdE4+18u7M/Cl3bNYP +tmZ6W2ezN6Z6WmuF9vO0UWMMcdobD7evHzB1jH6h76IBfPFGCubL8ZsKDa+G+L5TTSvQL4LcsXP +oYfvv3mb9l8mfrZYuNrK+2H/PKR8LX149/95q07fOv/33fePOPE+ruMEzXtVqZznnGicLtyNe1N 5jcRj6VeEm8WB1F1O94csnfk+cakOGaB6kK5TjSniDwueaekGWKfV3GcKfh5+VeNGXaMKYmxZix2 FHFumTi5NoqeMr6ilXt/t+jRGoedTUXqbCLJN43j/zNix5o9OM9nzHDvb5LX2tPFTtPN/2wnMMze Am2gdm+GdB8j9n/BADb1+OsCFniehuwuAwDgmSfSYCEb8LBYAADkMWYkHOnPYUnVVep+v+YXqLUA ABr8AADj/AAAoQMBAKgDAQDI4BoA6CwYAH5YAAAA/nic7J0HuJW1sveTLIpUsYIoXQRpivTeVZqF IgIiKIKAgGIBexfEgiAiXUCa9F5EQJr03jcdpQoIiorASvL9Jnu/W4+Hc9me63fv/b7n6vMn70pm Jm1mMnnXSrZW6ZSKbW2mVBqVxij+Sw0ymO/i2ePylNF8k6ZH2sS8L2JRXoXzPdKm5SlutEr8LxUo ygekqQtGJf+XN6lEhzSVzpREkTqUeu+TKYxKlIj8P0iMhTQN/JNJb441Vp1VVdtFlbZPqyKkeW0n dYNtq66yD6n09h6VxlZUqWxhFbNZlbE0yH7vfXyTt/G5Ph4f5i/G3/EX4p1AYz5X8S5e2Bub3ae1 GXxmq/z19jeXB2QFmUE6kNaecGnsDpfaLnSp7GgXsx84Y7uBdk7b1uAhd7Vt4vLahu4Oe7+rZRu5 lraZe9a2cu/Yx11f28kNsc+4kfCMtc+7L+wrbpx9x423vd0EOxRMchORPdFucpPsYTfZngdX+in2 Zj/VlvfT7b1+hn3Mz7Ld/Bz7np9nB/kJdrz/zH7l+9q1vqfd61+3P/gXrPNP20yqk71JtbO3qja2 lHrUVlWt7N2qpb1XPWwbqha2EWiumtlHVSPbXtW1Mp7RyMt8RCOfKqRnkmZA5ufP86QuMU9GFQnz dK2qyNgL7mEeHmZe2qvMzFdW+5zKY7sxd8+FOaxmO6gqzGFpUATkg+5G21pda5tBfw9zWlFdEfBA kHursszPzy6Xte4am86ntzf4mC3EPFYJc/obc/src/wLc32OOf+NuT8f/5551yoez6qYb+XjiW27 Aj1Ji56kQU9SoScxu8lrO9crOwydeQd0Qm5jPldBR4r4NPZGn8Fm8lfbmL/Bxl0+e5a2SHrB5bfn wM/ogLTtltDWq9Rv6IpFfyx6ZNEni15J+88GZAWZQTqQFj3LENJf0DHhu0gqvKWDrBtUS6fQNRtv 5+LxbqQfgNHOxxeSvwMdPIE+Cp/IOeHSk5cOnboCfU2LvqZF99Kir2mQkRqdNCFtRR0t4W3lXFxk R+2ujw7XA/eizw1p64PuKiv1C18rxr05fW5C2QPQNAYPBJ2/G92vY+8hFd6o3d3Q667gWfT9KTfG dnCfUXc/bKY7fM/Z+7CV+klyHuT5YfeMfcy9bZ9wfaAfBO9w+6IbFfBCUvoycl5G3gtJsiPd+NAv wD4WYidfYS9fYjdzsJ/Z2NFM7GkGdjUD+5qBnU1jbKZhd9Owv6nY4VTscTJ2OclKe6WeV9xo8sZQ NgaaMdCOhWcsvOOQMQ5Z45A5AdkTqWMydU2hzmnUPYM2zLY9gq3Oth+S9sJmo7ZFbW2kHrGChuBe 7PRu1RpbfYxxa2sLqfY2h+poM6su1vuu9rR/xe73b9v1/kO7wPe3E/3ndih1ikypp7//wn7hB9kv /Ud2tX/H7vYv21P+OWt9Z5sRWTcityD1lMQHVFUPUVdz6mxG3U1pw+9oQt6D+Icm+Axp202hrRmV 2Kmgk6pv26gmtgVyEtvf1DZVD9iW6n7yawdbFvzRg/zRY2x6u2yyx0id7Nl/DbW8oD5x5dwI18BN dk+4ee4tt8INdFvcRLfXzXdH3Cp3ym1y37mtbp/b5fa4b8k/7naDbe6YW+eOuqXusJvrDsH/nRtN +TB30PVzB1xPt9+9CHUHuJrBW9cluEpupysBCoHcfL4WSVdAF7eH3Bns5xB2nGC922gz+pXY/RJb lLmrxng/6L+2T/tl9iO/zk7xO+10f8TO9L/aOT6t+8pncwt9QbfIl3JLfFW3zN/tvvEN3HL/sFvh O7qV/iW32n/o1vhhbq2f7tb5FW693wN+BGn9Op/Dr/Ul/Gp/t1/hW/hlvr1f6rv5xf5d/7Uf6L/y E/xsP99P9mv8KL/T9/ff+Z7+hH/Zn/Fd/E++rf/RN/On/D3+qK/q9/nb/BafDUkX3Dy/003yM9wI /5Hr7zu7j3xD9x4tfNfncu/739DQLWFleQFtastK0wAtrszKU5AV6Bo022Idx8BWLGQRFjIFDGPl 6gO6Y4myosnK1gm0g+5xNx8LXm+7uMP2JedtD3eTk/n9x7Ul9T+tLX9eTSIvcsqtdd8z99+RJriF bgOzvNQNdrMd66jr5Ia6Rq63q+AGuDLM/X1uumsP1RtujevvdkBxEI067pa7M249erQ9pD+iT2eQ eQoNEtmR99uLHiW4E2jGt2jLTng3Oqlf+A6H3D1o1bfkH0WrToX0IBL287wbCG+0Cg6DQjAarZ0M xVw4l0K9jp5sQ1d3I3FvQCLvNneSshPQHIeWEUf2aLR/GDSCaDxK0F5BJSykLlzNaFsH2vYitfdE Uj/amFj3YZ4PkfcdZQehOQDtPnj2wrsXGXuSsNfdDt9tyLgdeSWQG3mqtXaGX2Wn+kW2N371aT8X G5iHLSxkTVxG7LTWpvfbWQcP2h/dD/aou2APuLTIuoaRz42sQshKbO8enveSt9ddx1iko00OrfrJ nnZHWT/3WOO32szIu8kvt8WwuWrgQb+UOleioZvsZL/eTgjpRjuN5xl+TVLbonGpio0JSmFzBbG/ bNhhWve1/4VY6Qhr+04720t/RM5O5ByB9xyf07o50M6DZz68C5GxKBk13GJfE1k1sGGRHY1LC7/S C+7GGkv49djuRmx4E7a8BZvegm1vwcY3YesbsfkN2P56fMBafMEafAI27lb5xPYu4nkxeUsoWwrN MmiXw7MC3pXIWIWsVchchexV1LGKulZS53LqXkobFiWjFb7iEfxGq+A/VvpID3f7QV6w3o/1C/10 P9HP49PX+BXxL9/gZxLpRUZ78rv5BZR95Qf4OX489PP4d6Uf4bf5TwIiud/6ol5wwlfG99T3v/im /hx+6Gf/tD/tX8UPvR/qFZ79vgefX/Qn/VP4qLaguT/u78WHVfe7fPGASG4vX8UJ+jIqg30nN9r3 ctMYiYV+B6N33u3wWUO9wrPB30AvLrrZPsGN8zPdUN8bvifxa41cd18tILJtWZF7ocF98Xcf4fc+ xP9JPULzFs89yOtJWXc/P6zWknYnkugJ3wdJvNH8v5AUkUik0J0IoQ8YBqYQJSwCW/GJx4AF1xAp FCRSqMyq3QB/2pZI4YWkSEHqeQHLaks9DfC/lckrSMRyDeWWaOUY2EqksghMAcOIVvqA7n+IWCI8 hy9+lrq70iZpW2QX4hsFb7kcrptTeMwj+OgNRGLzibYm2Y5JfREZnUFHNwX/Pd8+6dYh85B9DUt9 390Y/OvvKO8+xYt8DET2v1r1T58+fYlVP2rZfjdE73Cf6Y1uqF7pBurF7hP9lftIz3I99TT3tp7i XtfjXTc92nXQI91Depy7j7x6erarrb92d8Fzl97E8253j/7ONdbfu4f1Wfc0eFufdB9rkf9XV51I C2e4V7VglntTz3Xd9UL3gV7m+ujVrh91DqTdg/ReN0AfdMN5/lxvcCP0cvqx0PWH/mM9HfpJ8E2A XxDFUxNdQy0YG/rTXk92z4V6hGaMe0GPcE/oYZSNcfUDovYcca204IB7UCe4BoxZffpfl3Goq+fw PI2xEbnCM8ndTbtrUVYDmhp6M897XR34G+gfkC2I2iN9EBxn3E+7t8AzoR6hOee6gHfI6xf6KfhX Mz1/9KRLzHRkLzNdWUaltJ7vSupFroT+xt3BSBZn1IrrbWAPnw9RdhK6s66SvkCrPS1O5e/XV/gm Or1/WGfwbXRG/yTpi+S9o2P+I32R0T7NLMtMy4zLzIsGiCaIRohmiIaIpojGiOaIBokmjeN5vKvO DFTU0r5/V1P20C/BNleK/pSmX6XoX2m0uYxegNx5rjz1VkQjSpLegYbfTltug6YYtEXhKQJvUWQU C4jkpvEttSCVb6qVb0hf6zEbd+ozrir9q0j/yurEuovpw8j8Afm/UpelPObvZozuZbwa68y+RUBk dTKL+5nx0+C868s4f0gdb+u0jGtaxjct4yz1Cs+VPF9F3pWUZfTdKeuD/MHwiozhQXMkJeJgrIeQ DgyyI+2KtO3PmnQpjRNEbZzE/KREk1NiEaOT0nGuETITP4vsqI0yN4Jprgq6UIM6a2upf3RAbWir YZ3lwvwJ/poF3BlqyaNEg0WTRaNFs0XDRdNF40XzxQL2uYL6W5dbH3M3MMvX6N9cZmY+PaN+hc7k 0+qsPp3O4zPrwv46XdLn0BX9Lbq6v03f6cuASroyKOmrUl4Tutr6BjTgajQgk28WLOjfjcAP0raU aFlKtHVHkFWaGSuld/KcgCWI7KiuTD6DFlzhM2pNXy+4q/VPLqs+4W5itvMyPrdqaY/I2eUKMGY5 adf1tOtK2pWesU1DO1IhI5aMLHy+ivHLwliK7KiuO305xq8iKMvYFdfl/K26uM+tC/psOpe/Wl/v M+nE9sR0Np9a54O/GPllfHZdxedjzIvqOr40qMxztZDeTVoL1PBVguyorsTxacE8NMGaGiC7HnXU 0rcyXyWgq0xb7gyoxnM1XYo5LMr45vNoKvTX+Qdpv1hyyyTrbMm4P6rTgbS+VZD9Z83842fRxeWh LY+oC/oN43Qno00TUN14fbv5RRcyp/TN5rDObfbpm8xOnc1s0dea9TqLWaUzmkVam3n6rP5KH9Gr 9B69VO/SC/R2PVdv0DP1Cj1dfw3m6Nl6GvmT9Aw9Wk/U/fUE/S7lr+sp+iU9Xj+jx+r2oBXPTaC/ Xy/S9+htpJv03XqNrqiX6SJ6vr4JnoxIcWqs/lmN0j+oYWCgPqX6gB7gFX1SdQFtwIOgGigIrgIX 1Cl1BGxTp9VKdUYtUj/xnF6fUCWQ2E5fSQuy6+91Tn2buUF3Men1JJMFZNMTTV49wRQDFfR4U0eP M830F6aDHmue12PMO3q06atHmeF6pJmkR5gv9XCzTA8zG/RnZpseanaB/XqIOaQHm2N6kDkBftAD zRlwVn9iftUfmd/0u0bG/9Jz9c82GEWv2hQxMXO7Sc18pWbejOnEHL6JzNeR18lY3QRUNxeZS6tL hjSuizK3RaAtGnijlWWtTmcEm3Qms11fRbuvNQeY76PM+2nm/5y+xUh9IuesLkY/Cprv0I09lG2H ZqPOatboa8xyfWVA1MZVeoderQ+gCcf0QnRlmfZa6hGa+TpmZpM3Rx/SK/VOdOhgSNfoBL1O7wb7 Am9kLwv1OGRM01+iCbPRstlInauXoxvr0Jkt+ht0T+oTOYvhnYecmWjRVKROhnYyHDP4dz5y5iNH 0q/RusVo5WK0UWRH7Z6tX4aXeFP3hP9TOD/XC5P4puov+H8AGtMDmpfR2bdDOke/QnteJ30r8Ebt TtD36a26MW1sSP2NaUFTbKAVINbTXeB/Xs9OkjNRv6rH6Of0SMpGQjMG+mm6Pry16V19etMgpAn6 XtCA3jYKsqO6Runv1Rfo+wT9k5qm42quTg9vdkagEFZZHru6U0t7RM46XQcrrUx5Mdqdk35lpoeK en9Vw/UZZP0U0uHY1kjkjkmSHdX1oD4a0AZ0Aa+AHvoY9ngMuzyOfX4f2iNyhoGB+kfKfoLmJ2h/ hOdHeH9Exu9orE+rRtTRGH6RnTz36lf1tfoB2z2J3Z7Alo9j08ew7aPY+FFs/WhSe37k+UfyfqTs R2h+gvZHeM7C+7NajJwlyJF0ofpFzSd/Af5AZEd1pdfTTBrs/jr8wA34g+vxCxmY8QuqPTWU1JtU Rr0wSU6CuoIW36GNflxfw2zlhDYfPDngzawn40fGhTQjMtOBtHpKkB3V1QG/ImhGXh38TQVoi+mp +Jyp+J6p+KBpJn3AOJ7HkfcFZWOgGQPtGHhGwzsKGSOT0YnPnfFPnfBXIjuqa4P+3AiWQfMlNJPg HQ5dX2S+g+znk+hFxvPQvYM/64s/G44/m4Qf+xI/tgw/tgEfFmEzn7fg6zZDK7Kjun4m/ww8P4AT lB8Dh5GzH3m7oN2WRC8ytuELd4H9egA+pT+0n8LzKbz9kNHPnCRP0rPk/Rz85pAgO4rWxOc5/Gdc 98Tv9cZXCd3gwHdaf2x+0r343AO/+EbwjZdbE3NrkdtL/Ve80W3ld/tmoBG4F9Txe/ydoAaoCiqB Cv4YuACuVJX8Laqqz6/uAvf6m1Uz8LjPp7qBd31eNQRMAyvAfnAeXKPyqttAPdAetGOf0g5tb68q gaqqparCrqyKugfczeeaqgb/3qUqq/qqomqsCqmG6kbVSGVRDxLZPqyMaqO876Sc70r6mvoRHPRv qs2+u1rmP1Rf+k/VdD9CTfWT1Ez/lRrnv1ZD/Teqj1+vevgE9bo/pl7z51V3YrlPiVd7E2P1JG56 09+hXyJufY6Y6UlinQ6+rm5LbNyaeKelr6Ob+7t0E/Ib+ur6XmKkxBirUoh1JeaV2FdiYImFJSaW 2FhiZO0vql/cSXXc7WJntkJtdDPUUjdUzXHvqvHuaTXUtVC9XW31tiuturn8qoPLqlq4jOo+l0rV cEpVcN7f4Zwv4Ky/ycV9FnfBx9x5/4v9zR+z5/wee8xvtdv8Brs4fAuQ0nX8v+MtZVN07n/KW8pH Qlv++S1l9tDWDKqV3+4fwiakzVL+GM+t/IGQtvb7eN4P/b5AE41lOZ4r+R3Yzg5saAe2tAOb2olt 7cDGtmNr232rgAM8HyDvAGX7oTkA7UF4DsJ7EBkHfTW/N6TlKS+HHZb3CUF2FCNU9oWo7xZVBrss jX2WwU6lfuGrwnNV8qpQVg2aithhtWC7t2LDhVR5UuGN5qWNyoMtFsBGC2CrBbDZAthuAWy4ALZc AJsugG0XwMYLYOsFsfmC2P6t+IBb8QW3BrnSHqmnqs9DXh7KckGTC9qc8OSENwcyciArBzJzIDsH deSgrhzUmYO6c9CGHKqTyhfSjiqX6oy/6Kjyh7ZF/W6PV2iDh2iD/2iNFrfGn0j7ha8Tz53I60RZ J2ja400k7YhPkee2pMIbzVdFdb8qi48pT+0VVS1VLXieiviiCoxNeXxT+VCf8LYED4B7kFGb9C52 0jV5qk5OVWRUVE1DWgU/Jc/lSEV2VJf3L6mL/nX63JW0I/6rNbbYXGXGt92o7sPP3RPaI7yF4L0R XK0eUunVIyqNelzFGI2Y6gpeRdZbITXqDaS/pSyfRXZU1ww/B/+3QE3EB072w9Vs31ct8T3VJvzk Af8qPvOl0B6R8yP4Ft+5xb+nlvs+ar4fCP3n+M5Jaq7/Us3Cf0o6188n/2t869dBdlRXP59X98WH vumz4D/Pq5f9UfWW36F6+TVqsF+svsAHS3tEzni/VA3zq9QnfpN63+9Wb/vj0J5X77G3Hsj+tb8v FNJB+NKByPyUzyI7qqu9v0c/yv6+ra+tO7InfdpX0M/7kvp1X0z3gK6Xz6+lPSLnY3z6++yh32Y/ /KovD53Q36U74887+Ib49UYhbecb6zbgUfa0IjuqS/z7Xex/68J7P/vhxnxuit9vwRrwCHLasiZI e0ROK38f+fUprwPd3dDfqetDV5u1Qvbesu/+4x68JjJFdlRXlqT3A5fb06fk3UD68E4hY0jTsf6k D7KNrhfqupk1Je4FDVhbWrorVCd3rXrR5VXvupLqE3eXGuGaq8nuKfWV665WuMFqq5umDrhv1Cm3 U51336tU/rfQXpHvnFM/uh/UYbdH7XSr1Fo3S33thqkZ7j01xj2rBrqW6gNXV73uyqpnHX7DZVfN XRZ1D/XWCOtbqmQ9OmF/Zj07y7rzM+vbL6xzv7Le/ca6d571j/jDXfSJbU/FmhhTdzijCjitbqIf WVgfY6yPv9g4Mi76w/ZCcnqINfJwkuzIh8h6tpm1cgtr5k671R+wR7zUL/Q77fd+o93u11C2EhpZ 9yRdbSeyvk6gbGLgvVwc92moq7ZKsIPUXjtcHbSj1RE7nn5OVmfsNPWLnaku2DnK23kqlVugMrrF 6lq3XOV0a1Qht1mVZryruwPEAceIB86oJ9x59YKL6e4uk+7rsuphLq8e74qGN8XyxljeHMsbZHmT LN9NyHcU8l2FfGch313IdxjyXYZ8pyHfbch3HPJdh7ypPuzG6JNupj7rvtEX3Q59Bhx22/Uutw26 LXq526jnu3V6hluFzGX6Y2hfdsN1e/e+buqe03VdS13V1dVlXDl9uyuib3GFdXbal8ldo71V+id7 kr7vVLvtSrXFLlSr7XS1wo5jHkaE8UlpzBK9L7DIEPxmv1Jn7Vz1g52ljiPzOztJ7bNfIPNztc0O YdwHMO6fqUN8Pm7HqlOM/0/QnLNTVdzOUNrNDojWQXmbOs1V0GPd7XqIy697u+z6LZdFd3Np6atF d39Gd08SMx1SJdH5gm47+rdBXe1Wq/TYiGEOpV0iM437UmVmXq93S1Ru4r4ibr0q67aqmvA1gL8l cjq5X9RLzqueLr3+1F2rP3e59CRXSM9xpcIbYEnnMr9zaNPM8Ea4QvI7AnljfKk3wpd6cyxvmydd 4q1ztIeJvhP68/c9l/peSBDZ7G70JyXfN6Xke6vvktID4XkwSJQd9fcienjO7dSn3XJ9zM2m7Ast 9QvfcTcKnZ1O+TLt0duLbndInUvQcZ7PA+GN9GeiW6QFs9D3Bej0CreWtmxA3zeh95uRtVlLfSLn jNtD3i7KEujjDv2N24odbWKM1+kv3MqAaDyKuYK6JPNXwZXRNRn7e10L3cI9ozu6d/VrjE0/Ny3U KzwfuTn6BTdSt3W9dGPs9C73iK7ImJdgjou4YvoOdFDSItjSbci9I0l2VNd2dF+w3y5X39vt6lf7 vYrhj7OgrznQo4KugC4W+G7XN7vbdFb0Ob27Xl+0Rv9gf1Df2l1qh12tNtrFydiA7m5E5hZ8ksiO xl5saRd2tMGOUmuw2/XYj5QLz3L82FLyVlG+034abE7S3bY/zwNBIu/l/OWBUFdndVwNUdvUJ2qx ek9NVq+roaqb+pAo7nUit67s/54kLnqcuKoV+8KmxE5NiKFa8ulxdpVPqafV8+oVIqN3iYz6wjNE vaRGkjuW0nGqBWlD9TlR22Ditt5EiW8Qbz2lShFbFSNKLKA6EEl2UDepJ9QN5GdFWjb1jrqZttym PiamE74xxH7TkbGQiHEV/FvU7SqBKDVBZaflV6n1xGzL6NeX9GgyMdZI9Rvx1BnisKPgAHvTBD9K bfXjiMems29dqPb5Rep79qi/EDM5vwXevcR8R1Vq9RP8VqVTN+hM6kZ9lbpJX6ty6mwqN7abV+dW N+t86hZdQN2qb1e36TKqtK6kKulqqqauoerpWqqhrqma89xa11GP6vvUI7oxaApagEfIawPagy7q Qf2yqq3fVWV0P2QPV5n1BHVBzWBG5qg99Haf+oZ0jdqhNquNaqdaTs6X6pCaEObsr+47n2LunmYe X2D+3iTG/Ygoe5h6Rk1VL6ulqju19FbfqwHqmBrOCA9QX6teaqJ6mxl4Sb2vujDH7aF+hFlrzuw9 FNIn0I2OyHwySXakv43RkAaUP0B83Urdiy7cH+oXvrZoUSu06KGA5nxKTJuha00oaUQqvJHveIFW Cl6mJa+gYy+qnupZ9Roa+px6jBY8xI5E6hM5j6JxHdDbZ2jRy7T7TdUDbepLL4bCOzbg971IR/YP T7EHeYOdRS92JAOQ8xm1j6S9o+jxyFCv8DzDmLdDtx4ivR99vBO6ykE/32DP8RSyng1pOVolcquE XdBTyXVlpc3X0pKr0e/raFt2pOVhJAqA28LbmQ6BT+SUZCSLwluA0coDcoIctOYmeG9Cxg3UKemN 2Fw25F5HKrKj8SqvNgRUUyuwl4XsnmbQ1i+o4zNo0DT6Ku0RObcw73egCRXp+530ua6apurDUxut q4xGCH7fTw1Dp0aCSeoKNDSzWkK9a2jLJmxxG/3YFuoVnuLYU36QDRvNTHma8M3TVyrup6gL2Kf3 Y0Maxz5FrkHnRHZU12a/RK3HTtdhrxuh3QHdfj8Uex6CXQ/Bvj8LfCLnNz+GvFGUjVIH/Wi123+h dvoJahu825Gx2c8L6Tb2RiJ3A6nIjuq66B3tuKC0+hEcJXcfedvVWb9BHWPvtNcvC3wiZz97spPw n/MroN3IOOxRGeBJp87SB4XVxUPqvdZxr/RFfInIjt5xXKFy6NQqu5Y6hTaTyqbTq+u0pBnxN+kp T5tEE7UvP9YsyKMK6ZyqoM6O/7keP3Q1PiMLfimjyqVFrsjJrLKSn43y7NDdBH1OnRea/NDeqvIn o7AqAArrgkmyo7pqqMd1FXxTVXxYNXxZFVUf/1ZLl1NVdElVThdVdwR6kVFCFdHlVQnoKuD3aui7 VF1dG5674b1LPYYPbBnSWsisDqqqNkF2VFdHPrcnvw14RLXFP7bBT7bFX7bFb7bBf7bV0h6RU0c9 TF4Lyh6C5iFoW8DzMLwtkNFCt4VG0o6knakjkh3VNYvV7iv0cQ4ebgrjPkpl0QMZww/o0+u0+1na LDxtA39j/by6S7+tSuk+jN0QlVGjZfAdw5J244F3hnQWuj2X53lqV5Ad1SU+9BT+5hje81tK9qiV WMYWVqldWOQBrOu70B6RsxAZS0lXqq1Yzjr+XQbVHErHq8P4O/HFkh5VA4Pck2pQkP2vfoEwXKlL /AJBzvbcHNNaVo0f8AJnofuNVdlicUaPVmn1GJVBf8GYjAMTwXQwH6xQV4Fr9UrWw1Xo2Wp0bw2y 16qSep0qr9czXqsZ73GqH2M0mM9DwedgPJgBFoDleoNaD7bqjWofnw/Dexx8D47pReqQZserR1I2 lLJP1Unm5ax+TV3QTyllWqnUpr5KZ8qrDCa/+hn92w2W6JvVOPAReA40Y12uAmR9Tgd+wM9tAXPB UPDW/6Nvw5/yD+kXfDv9hn9Ov+vf1L18L/2xH6T7+ZHwT9D9wUA/UQ8Fn/tJ+gs/WU8CM/wUPddP 1fN4XujH66V+jF7hR+lV0Kz3M/Q2P0fv9vP0Af+VPurn69N+gf6NVKu5eJTpOiujm08NwdL76WKq F9beg2jndV1BvaArqy5YfYcQ5Ui0I1GPRD8SBUk0JFGRREcSJUm0JFGTRE8SRUk0JVGVRFcSZV30 1+pT/mracZXeClbyvIC8mf46PcFn1SN8Jj3Ex/QgxmyIP6OGMX6j/LeM61412e9hnA+r2f60WkT5 WjzuLp9GH/Np9S8+tZZITiI6iewkwpNITyI+ifwkApRIUCJCiQwlQpRIUSJGiRwlgpRIUiJKiSwl wpRIUyJOiTwlApVIVCJSiUwlQpVIVSJWiVwlgpVIViJaib0kwpVIVyJeiXwlApZIWCJiiYwlQpZI uUVS5CwRtETSElFLZC0RtkTaEnFL5N0yxFDNQ0QukfnjIQp7METsErlLBC+RvET0EtlLhP/nqPGv /AIoAzZ+pZ6k0uMf0ujxSvM5ThvP0eef8KenaLt4K/FSp/FSP1PXeXyNI4KK6RHqCv05fnQU/mQ0 69S4kF6Lz7gWWVcjU2RH0eOV+JgM+J0M+KAM+KIMlEv91wVMBNPBfCD+aWlIr8EPZcEvZSIV3qjd 5fXmAPketyj+5xb8UC580A34nmugz0JdUp/IuTrIWkbZN9Ash3YFPCvhXYWM1cmoBH1lZFRCpsiO VvfWlLUkP7FOeV6OdSSmjyKrdfCV6wJNxPMo/W5Lv6RMaB/m+VHGRtKW+GV5bkMqNBFPH8atH3sF 4ZXyfvjOgSFvpBrAGMvzAMZVaCKewXqL6k+9wivlw3geTL8k/Yx+DKbNA0iFJhq7rXprwHp4l5Mu IJ0BxoPPwVAwOGAVz6vIW0XZKmhWQbsKntXwrkHG2mTsoP87mYcd8InsaM5Ph/VgM+vCZtaATawF m5PqX8vzavJWUbYSmpVh/ZD0FPnCdwp5whvJOshe6lvW7UPo3DE9lfXk60AnfIf0Ytaa6WoP47RL f8ZaMigpHaz2EhMc4LPwJuu9ya2uZN3JxPqTztyjUplHlGPvdk6/gf30Qv7AUN/uwNeXz+9R1yvq V/2kiuuWSpt6rF/lVVpkZDCFQnqFyctzHpWZVGT/47dCOVircmC7OVi7cuBhcrCW5WBNy4kXzcka l5O1LidrXi7Wvlx46VyshbmoPzdrY+7QXqnnZ12IvEKU3QrNrdDeCs+t8BZERkFkFURmQWQXoI4C 1FWAOgtQd4Hw7U/it0KyP8lPu/KS5gpt+99vhf73WyH5Bubv+lZIvtH5j74V+pQ45mNinD7ELr38 YP2e/whZb+tXfDdipQ66k28ZvhESOc/4puS31e/4Z/QH/nX4PqTtA+nD5/RlAs9jQzqQmEjk9iUV 2VFdXxEXzfUziZ1mEENNJ5aaTkw1jdhqKjxTA08ixuoBYKD/grIvoBkH7Xh4xsM7ARkT9SziLEm/ Ip0PbyQ7sp8l9GclvN/AsxiaBdQjNMI3BxlfIX8x7V7uh+u10Eq6yo/Qa4j71hDLCW8ka5dfqBPA FmK5NX42MqdokS9865C1ifp3IHsvZXuApPv9XDCfz4m80duDW1gRBNnVRHaTs4kE5uvzfhHx4RLi xEXEaV9rqU/kHCCGPIqc0+Ac8PQvvZpMjDcGTzQwIBpb2Qkm7gafYDf4NDvBl4gl3yRW7KnvUL2p f0CoV3huUR/juT7Qt6l3iDtfhaYbO82niC3bhx1khGqqFfFnS32neiTIjuqKdrmX26GmZKcbIR+7 5Xzsvm9Jkh2Nl+y6U7LzTskOXhD1YTIx8AR/DXHwVehGFuY7M/FxRsY8I/FyZh0nT+oVngs+G3nX U3Y9NNdDez082eC9ARk3opvZk9OxxNRfJMmO6hpPHD3ZH1QTwFji6ZH+ezXc/4iPOE9q9CifQUt7 hP8zfyW6nwr7Pq8GEHcP9kfUCL8fvgRk7MAv7QnpND7P4HkaZSI7Gi95OyL41acjTs+I7qXXq5G3 wMeh/wlfeSS0R+TM9IfYT51US/2vaj3lu2nLMfBzeLtyIbxZSX47n/Sm53JvaFLypmd9kPX7m6IN +E6RHdUVvcG63JunlLzBkrde0RuwmOzHiadFdjRe0Vu4y71RS8mbOUHUh+hN4uXeAKbkTeK1YZ8j byJ78Py2ul69GWRHdUVvSC/3ZjMlb0irBlm/v2Gtop4JsqPxit7yXu6NbUre/AqiPkRvqi/3hjkl b6rl7bakDZHVUDUjnmkSZEf+PHrD/uc35Zd6oy5v3SV9hpJnoO+SxBu1W/ZkKXmjn5JvBiKcSnoL dQKqY+HN7V95G9UqtKyYku+9tT+q0/pfdQZvTCafwVzprzZX++wmq89jcvhbzc3+dlPYlzF3+Eqm rK9uKvo7TVVfx9Tw9c2d/n5Txzc29/gmpoFvah4EjXxrPnem7EVou5vivg8yBiLvM5MeGD/YxN0A 84v7xJxxfcxJ96E57nqao+4dc8S9YRJcN7PedTArXFPzjatlVrqiZpO72nzrzuqLblP4rv6v7qAz h/6mVvJ96G9um77gtmjrtobvS6Pvg9PRd0FaHzMxf47yY+H7U6FJ7Y8wPr/oK702V0EjiLS9tK9l SoHbfFVT0Jc3eXwJk90XMdf4fCazv8lk8NcEucJzjb/KXO+zmRt9LpPb32IK+KKmmC8Jf3lTwVcx 5UGkNY38g4xnC8a1hannm5u7+VzDN2Ls7zOVGPtyvraRuoWniq9B2V2MeR1T298DfQNzn28Ib2Nk NDYP+WakjUxz/4BpwRw19w/x+eHkujL4QczNIOZokMnr+9GmXsh/C5nPM78dkfWIkfYkymmD3Keo 52Xq7WlK+k/MLX4ovJ8j43P6mpim9SNMGuY7LfMtspOtwb1iTjDPJ9zb5pTrYU6798xZ18ucc72N Qydivr+R9ogc7YeZC24I5QOg/QQ96W0Ou/fNd667OYiMQ+iMpN+5V9GdVyh/NcguGOq6Wjnm+Ij7 RW9z15q1rphZjT6tcQ+aza6d2eOeNdIWkbHdvUhZR7PUNTOLoFnmiph1LovZ535EX9brSH/k+aJb px2pRxdF/qW/A/xn3TtCPd/R52//0N6onRWZv9LYUmHmJLdvj548w9i9aM671xmft8yRYBuvMAYv MU7PY0NPY6dPoGetTX7mpRj6UNJXM1Fd8lwavSjnK6NXVY3IT2k7VxDVLiPyXUrkuoxodwVRb9TO vCof0VcZoqh6RE+P6jREhb/4nvqQH0DUM0oLr9Bv9EP0Pv8xUelbWqkujN/D+gZVB1srQ+RVIHk8 5Tk7UVgOlYeoM48W+Slt51R/QE0C4/0+sIuoZWfyCnTUHwv4zn9HRHGAaGAfkcAe9Q1YAGb7vYFf eGb6beRtpWwzNFuJErYTJeyEf6865b8NiPq/k3p2EkntJiraz+7uW3ZtR8GxJEidQn+G5x+IzI4S wX0LdvO8jYhuI+1Zj4yoD/K8kUhtC3VuJxX5Ke3/rLADXUg/5hPhfRl2llE7NxI5rfOL1GpoVkCz lPRr8FXYwS4MvEI/188mbxZls6CZBe1stZb8DX6u2kq0FdW1NXx/Nx8soq1LgvyUttP7t4mQ3iTK e430ZT6/SAQlZemJUnqqq1jdMrB+p2b3LrRSnprVMRPr9zWsj9mJEH7XF/ne9S3Qg+imZ+BPaTsc EV2cCPEiO3rrZV0clqwv+dTsgLxquspF9JWdqOV61uksajxtG0d7vgj8wpOaNTWDGkGU9Dn9GEUE NQbecYz9ZFVYzQyI+pcL/rx8vkXNVTcTKUodUl5ELSB/EfXMJWobn9xGec5GBHMjMnOSCn9K+1eR KCZ601KOOKWiui+5HRLp3E9EUpfoogYRitBKeQ1y6xL/NCR6kegnktU06b12c6KjB+EV/pS2owLx VjlimbJEZ+XD+6eOyePcnPkTNGVemzC/DZnn+4h56hFx3q26EQ12DfyVwnuqzuQ9qe4htmpApNSE aKg5UVxLaFvDK4j61xwZLdW7xE3vk74f6pDyx3l+hCiwifqAul5IbqM8N6KuJshrRir8Ke3fH986 lyEtzefk36fr8UmYrKrq2WBJoC8dsATMBpPB+GSU0WORNQaZYwNv1KeaeNpq7J2r6MdA71Am9KV4 LkNeOcoq4jGT55/nynjR6qAm+2ThT2mf+umJ7PfHhzfTH+tRfP48OXqdrcepeXqS+pJ2zyKdBu0E 0tGkw/QENZC0X8DnPH9O3kjKRkEzEtpR8IyGdxQyRst5wpAuoL/yvAA+kR31eQHj+aVeoebqedQ7 OdS9MGCyWkTeYsqW6jXJ7ZbnZYztUvgWMR/C/68i4ZfLXioSXhQkPaxKma2+IqgB6oD7QRPwMGgD ngi4RbUCjUFtUAkUN/lVfpAtvFv+z383Wi/p5JCcIDqfdKJoRdIJIzlpJCeO5OSRnECSk0hyIklO JskJJTmpJCeWEk8uHQsnmaomnWySE05y0unepJNPzcLJjt2+I3gR9PS7/CAwASwEm3yCPwIuAln3 bgXVQFPwNGvk+2A0+Jo1IQGcBZn0dl9Qb/PVwUOgK+gNxhEbLAG7wE8gHWOZC8iY/7vfhbUN85HA 3CQwRwnMVQJzlsDcJTCHCcxlAvIFG3jeQN4GyjZAswHaDfBsgHcDMjYQy24NaWezKTx3NjuC7Oh7 mycMu2DmWup8KuAW8gorSTubW8NzO1KhiTxd4ncAudGL3OhHbvQkN/qSB73Jg/7kQY/yBLnC2wo0 BrVBJVDcFIKnELyFwvcIguiX7O2TToz8T/h+QhB9bxKduPnPnoT5O07kyCkfSSuEEz8FVHlsRNoW eenopNGfTwxd6mSRnD6StAJ2UNnvhH5X4I3mWU5EpeRkU8pOSO3w0S/oSyXpby6QDvykE7CfBOwo AXtKwK52YV+7sLNd2Nsu7G4X9rcbO9yNPe7GLndjn3uw0z3Y6x7sdi/2u5cR2Ys978Wu92Hf+7Dz fdj7fux+P/a/Hz+wH39wAL9wwCf2bQfP28nbTtm2cJPUBLAQbPJbkbEVWVuRuQXZW6hjC3Vtoc7N 1L2ZNmymLXgTcBZk0pto60bavJG2b6QPG+nLRvq0gb5toI8b6OsG+ryBvm8I9huhLPZZHvsri33K 2Pw1T/9tGNknVVmT1pZK8kDiiX5K8kziocRT9U7yXA8leTLxaOLZziZ5OvF4o5M8oHjCpkmeUTyk eMqLSZ5TPOjCJI8qnlU87ItJHlc873/H7YJ/9721L4L3VRU7XFW2c1Ulu0VVtKdVeZtJl7OFdVlb W5e2bXUp+4YuaQfpO+xUXdwuARv17XYn2KHzkl5nd+kMdrdOa4/oNPZnEDNp7DUgDyga5iutlXn7 q6tF5MFFe25nrksgoxIoH1afhH/QpjtIhSaywMSzj/8TtP+/3ws8lHQONDr72QLtFI8Vja+cIY3O i0bnR+WcqaTN0O8/njn93xvx/vFGPLlDNqU34slds//RjXj/L9xpG/W7s6qZ4jttO+NXJO2Ij3mS 5y74G+GN+r0n+JNS+JVS+JfS+JnS+JvS+J2y+J9y+KHy+KOK+KVK+KfK+Kmq+Ktq+K3q+K8a+LFa Vtoj9byoKpBXgbLy0JSDtiw8peEthYySyLoDmcWRfTt1FKOuItRZhLoL04bCdmtoS2H8WVG7l+fd ukRoW9Tv3fi6/foKu09ntHvwfXvwgdJ+4dvM81bytuv0+MY08MZCmqBTQRODJ3XgTb6FNPjFDPjH jPjJjPjLDPjNDPjPDPjRDPhT8asZgpwjWpOnKdPQaGg1PAZeg4xY8IuSVjCpbEWeK5j0Qfa/WmVr qkutsnVCy/KpEczKUNAXdI8VVM+BR0BdcAe4AXhTQB0Ga8FMMBT0JIZ+PsTXgq3+BfA+GAZmgfXg KNCxrf7G2DZfEtQDj4LnQHfQN7bdDwUjAm79y7+3i7QqMc7PS3vy0K48tC8v7cxLe/PS7ry0Py/9 yEd/8tGvfPQvH/3MR3/z0e+b6f/NjEN+UJTnYuQVo6woNEWhLQpPUXiLIqMosoogswiyi1BHEeoq Qp2FqbswbSgU9hbRPuNxntuZfGH/8PseJSF5bxLtVWRPI2k74qYnzMbk/U3UvyFhfHYxVrsZs92M 3S7GcBdjuYsx3cXY7mKMdzHWCYx5AmOfwBwkMBcJzEkCc5MQ9klSzwvgfTAMzALrwVGgYxuQsRFZ G5G5EdkbqWMjdW2kzk3UvYk2bPZjQls2+1GxLX40z6OoU9oW9U/GcUhSm8cE3BrGVdJRsSI8F1Of kQ7503ynXGOjuPBybwFEI3uCwWAyWAp2gh9ADO3LBgqDSqA+aA7a0uJOoEtAPdDKdYm9YbvEctrb Y9lAZdvF3A4y/ifjnIRLxDkbLhnnRD7kiaRZ/Dt20hH+vJOONK5r6P8uxmI3Y7KbsdnFGO1irHYx ZrsYu12M4S7GMoExTWBsExjjBMY6gTH/Z43rCQaDyWAp2Al+ADG0KxsoDCqB+qA5aIu2dQJd0LSO oS2b/bNo3HM8P4vGSdsiP90llt12ZX66Mk9dma+uzJu0v2NAPdDKdaSsIzRdYnlD2jl2oxW+Z0mF N5qXwmGOrw1lQnt77CZbKuTdZItCW4TnorHrAk3Ec3uMNQu9EN5SAZUprx7SErFqPNeAp1qgiXi6 Bh0qYoVXaLuYkrZjyCtpO5sSthPPnU3RQBPxdDFX2K7onfB2DMhIeZaQdjbprJQ/Syo0EU+JpLVC yoRW1olKyWtRelsy2FKqQPOvrHHkXSUuYY1lQw3Z1X/F79Kljn/3/dP/b78N+uNJrL/rt0FyukpS T1uMks82yI60SMbnzyexZLwudRLrr2lR5VBDDlXfDzENfH/TxPcxzf17pqV/07T2z5u2eKb2/lHz hG9k2vgHTKvw3XbKfr+QxY8w2fwok9uPMbf6L8wdoALPNf3nRur7dzWqg7/PPEl7OtGuDv5J8zge rrV/mzZ/QNv7msZ+kLmP9bUObbnXf2Ia+o/o17uUvQ5NN/Oo70RfHoWvkelIfyRth5d+ArmdSUV2 5NsSf1vQiD43hreRecw3MFK/8LX1zcwj/iHKWoTfCCR+5/8w9T/E2DQlfSDwRu2+Inzf//f8diBj +B3CP/92INqDSf8FdzLeFf14xn4iczDR5OI5K/NwpR9trkiScxVyb/DDTR4+38p83QHK81wduTKG gr+mVS604hX0fqiZRQu/pBULqX2pn25W+HlmtV9iVvm1fN5uvvbfmmX+R7Pee7PXZ4r94G+IKZU7 lkXlieVU2YlmbowVVzfFKqscsfqgBXiCvG4qW+w1dW2su8oQ+5Co8GN12vRXe81AtdUMUqtI55p+ argZoAaZIaq3+Vy9Y8apF8xU1cnMUY+ahaqZWaYamXWqntmkWKtVObNKFTXLVWGzRN1qFqgC0OU3 01Q+M1HlNmNVTjNS3Wg+U9chPxPyU5mh6rweqM7qfuq07qNO6t7qBM+H9QC1l3S7/lBt0u+oVfot NZ90kn5fjdC91GDoPgbv8vyKfk89rd9UHXQ39Vg4aS0nruXkdYukk9hyIltOZssJbTnDJGeZ5EyT nG2SM05y1knOPMnZJzkDJWeh5EyUnI36LemslJyZkrNTcoZqt1+ud/pNepPfo1f4I/ir03q6P48/ jZnPfGZwJbjaDPXZzRBfCNwGSoDSZrAvZz4HY8EEYqVJYKJvaaZgVTPQUpnvf/cXR1PhnYY2zkTb 5pDO9UOTtXmR32IE3/g1Zjm6s9R/hd7MNF/5KWa2HwffSCP8wvMlWj+fz4vJX+GnmjX+S3RriVnn 18GbEBBZZE6VM5YHfcqi8se8vzl20ucgrskSW+NNbJE/a+ahm1Kv8CzjeaU/TbwWNwd8+tgZf11M o5dZ4L9RZUVXr09O85DmRXdFdlTXm+QJnofnCZULPc6DPudFr/Oi37nR81wxaY/w54euOPpdGdQH Ldj5PEFeV/T9ZXVVMl5TWZB5Vewt8kV29AutwWqfEXyqzpg+SsXeU5lCufC8qdLFeipneqkfTF+1 JyDydgPVCPR6GHo91wzDhoZiSyJHaPrx3I+8fpT1ga4PdJJ+rD4zn6gh2N7QwBvN2XL1oBEsVi3M V+oxM1M9aSapl8wY1cMMVx9jk4PNwCQ5n6iB2GkvbOstM1p1w96eMDNUK/iaYIv3BUR9W6sKYbOF zRb2Iduw243q3lCP0KxWtSmrYdao8uYbdRv5v98iO0ZlM4JxKruZrG5Cfi4zV+XBD+TDD+Q3K7F3 kS08y+BdhC+YTz2z8QVTKBuvbqZteWl7zoBozEaoc3qEuqiH4g8+UxnxM9eEeoRmkMrKHGRmzFLR 13P4iota0sHqFz0MjFC/Bd5IFj5Mf6yO6k/UcXzIST0ECxqRxPep+pWyn/AZp5NwNKQfqFPge/0R n4U3Gqdeap0WDFBbaJucFpLyRL4+6jvdl7yPVQK82wJ+5xulBT3VZP0ufqunWhHkCM0bao1+lbw3 1ETKPgtIvn0rnG5+WD+vWum3VVt4nkL+y/TlXfAxz0OCXOF5Tw1C3sfgXZ5f1d3Vs/p11Vl3Ve2Q 0Tachha0VW2CP4xOTEd1VQm+8PInrVNyYjvx9Lec+G6rq+Bfq9J+kR3pTXQ24HK/80/JeQFB1Icd +OKUnEtIyfmG/ciSdCd+fof/klh0TpAd1TUQvz7IZzSjvMJX/6rn+ZN6mf9Or/cJxNkb4FmupT37 A5bDu4X8/cSzx/Ui/5Oe5eN6vE+D789iRiJL0uFhjbgauVcG2ZH+9GfNGAAGsn4Monwg5VL/yIAr 4b3ajKBsODQjQKT7g30l05+99wDWmf6sN/1Zd/on0YzgeQR5wykbxpozmD22pEPhGQQG+AqBN5I1 LqxLlVmjKrNWVaLOykbkC9/nviR5pSgrbSaDadAmpmVBBcanUuCNfmkh68oU1rYJrHFfsNaJbOGZ yvMM8uZQJutOtI7J8xyiqZnEPdNIp/5pTbx89LQySHo03BPeJunecLk/vEfSfeJyr7jcLy73jMt9 43LvuNw/LveQy33kci+53E++Lem+crm3XO4vl3vM5T5zuddc7jeXe87lvnO591zuP5d70OU+dLkX Xe5Hl3vS5b50uTdd7k+Xe9TlPnW5V13uV5d71uW+dbl3Xe5fl3vY5T52uZdd7meXe9pTmzvMlSC7 KW7ym6L8X4BPOcHVppAx5F7QJc1xKLfpfOYbXdAs1YXNQl3EzEHCFH2LGYvEYfoGM4CaPqamXvo6 0wO8qq82z9GCJ3Qq86i+oJvrU7qxPqaL6/06td6hD4QT/HKSX070L0g64T8+6cT/0HCidH24CeDR cHp1dbghoJrepu7W+9Q9+ohqzPjKHPy7Ec1/dGd0dIf15e+evvwd1nLvtaRj9QmeRSd+DLKTT5sk 3c19uTu1U3I3t9znLelO3RCtaKy3AJEd1TUzhXeFp+TOcbmnXNK5yJqr39Sz+CyyIyuf/y/uPL/U 3ehyf7qki6llcbhxfWrgjdod3fF+ubvZU3LHu9wLL+la5KzHZtaikSI78pDRPfR/vmP+UnfRC6I2 yv32KbnjPiV35UeImWLgDqNMouyorsImDSXKlDZXgVzmdqy1ANZ6oymFPZfBrksHepGRGsorsewb QD5zK5Q3k5MDXGNuManIcVpSqVmeiwCRHc1jPjxJfrMYaVt0OXxBKXNRS/1CW9Sc17eRV8Ts0Hmg ywedpLnMCrBM5+Wz8Ebtvtp8il/oRW/ZDZkh+JDR1DUZ/zIHOV8jd7nOlyQnv1mkC5gFjOQc2jcV WeN0DvO5vt4M1pmRkxk5kmY0n4A+jGyvIDuq60d09wd8axzfmta0xD+1h/cZfNWroAej3ltfnSQn i/mA2egBXuVzN32F6YQHbaN/0y31SfT/OLIk/R5Zx3UjfQKbEtnRGMnJ8p34sd16P7FbKmiLa6lf +A7xvFunQQMPqo16UziJLukm/NkW+LaHU+y/n6aKTtNf/hT85U/T9w+ytiSfxh8Ar8iO3lxFp/2l zuhEv5z0//33k7/fAhDxRLcKSFl0c0DbkDcJPz3xH24biHii2wukLLqhQG4u+OMtBg+RCk3EUyb8 NjXxxoPoJgS5LeGPv1ctEz6vTv7dZQN8a118by3GurLeGeiEpyY8dfVudb/+Dp994g9rwAnVNKwj shb8FPj/WjSwPkhqo2TvLXvwxL34bWFvLnt02asn7tkzG9nDy15e9vSyt5c9vuz1Zc8ve3+5R0Xu U5F7VeR+FblnRe5bkXtX5P4VuYdF7mORe1nkfha5p0Xua+kfziNPCPe4yH0ucq+L3O8i97zIfS9y 70tKbkO/3F/8udzfzPrzTaR/94ksebMpbzjlTae88Xze32ve9HXNe/4u08fXMv2QMcBXDTGnzMdf jQyiFWD4v4hrLxX/DvhDjBzF33+Ooy8Vb0tMLulgxuUznx7aDIE38gKJ56ovH++nZN8gZ7Il3Rnu 6Zmt95GK7Kjd0bnwP5/vvtQ5cDkrvuQPJ2pWkwpvJCs6r/7nc+eXOp8uZ9ijdBbpTOoW3mgMonP2 lzsfn5Jz9h8HWb+f0++LLJEd7SPlzH9Kzv2n5P4AwR//KtTfdRP1nX/6a1B/vok68W+8/T1/FSpz Uvrnvwr1x9tj/66/+ya3wF7q775FOiWnF1N6e2yEP98e+z/tdGQkV76R+LtOR8q3GVE/5RuQS30L cqlvSwTJ0QdtHIbv/CzsyWvg4+40fWnD+/jZt/G3L1CfyBWebuS9Tnt6QveRrwZdZXxwJfOprwhf ueAvJR0Q3k2XQmbpIPuvrbBjQsvuV/8Vf49jN9hkz/uV1vrFNpWabzOpufYGNdsWVLNsedKa6kt7 n1pgW6iltoNaZZ9XG+w7aqvt819yV/jl/url5f7m37+7V/7z37yT++P/p95JH1mW3Bn/d91JL4jk TkUPBNPRiZk2G/qRUS20Ri1HbzbaX9ChxHqFZzfYjC6ttlots2nUIpsZncqu5sE7DxmCSK7c0yzY aPuqNbaH+sa+qL62HdG3h9G9+6mvZqg3ka8mOnivWmwfUitsO7XOdlVb7Ftqp/0o3OEs+L993/rs pDvN/yfcty53p1/qvvV//JuTf89fVd2R9Pcr91N+gOf9yBLZ0ZnVv+vvTUa2d6m/OfmvPKhSbS/h QVuFv0o1WXV3Ndyrrrrr6qq6zq6Ka+squxaukmvkKrq6rgIl5V1xV87ldmXdla6Mc7a0OwV2g9Vg LhgLPrVl3DvgOVvWtbHl3AO2vLvLVnBlbUVX2FZyOW0Vd7Wt6tLa6s7Ga7qf47Xcyfhd7nC8ttsd f9htiz/rNsXfdxviI93G+Dy3Ob6JvKMuIR53W+JZ/ep4Of91/FE/Pd7bj4wv8Z/Ez/l34sVU13gb 9Xh8sGoW36DujSt9Z7yIrhpvqCvFn9aV4+/pGvEBukH8C/1IfJZ+Kv61fjW+XL8fX6v7xzfpkfFt eko8QX8Z361XxffpA/GDOh4/pG+0R3Vl+71ubU/pnvaMnmLP6q32V33OntfXu7hmtdC1nTJNnTGt Xcx0cqlMN55fJ/9dd073caf0QPetHuG2/l/56wqyssgKIyuNrDiy8sgKJCtR4opUMKxQslLJiiUr l6xgspJd6i9MLbMf+a/t036BfdAvtNX8EluU1e5GPFdGn2C9O2R/dmfsCRe3h9wVbr+71u1GHxJc IbfTlQCVQF0+N3O7XAe3x73o9rqe0PVzB9wwd9CNdt+6ye47N9cdckvdYbfOHXXb3DGkHIfyOBzf un3wfue2ulNukzviVpE/321xE90KN9DNc2/B/4Qb4Rq4T9BF0dl/d9Xqjo73RNffQ0ZPdyey7nKR V6zuSjtBXfS8Efregrraov+dsYOu2MOr2IbwC8+r8HZ1NSmrAU11aKvBw6xSXh06QSR3ri2OndyB vRTHbopjP8Wxo+LYUwnGsST2Vcol1l2Z50rkVaSsAjQVoK0ATwV4KyCjPKjgIm97EPs5hB2diNfA nqphV2JflbGzithbBeyuHPZXFjssgz2Wxi5LYZ8lsdM7sNc7sFtpV/Egcyz4FL53wHOgDTb7ALLu wm7LYreFbTVk1kB2Teq4k7rups7a7lS8rjsSr++OJ6Xfxeu5g/E67tuktkXedht2vC1usfGjbj22 vRYbX42tr8PmN8WfcTviLZz0R+Tsj7fE7p+D/n23FZqt0G6HJwHevfGLIB7SPXHndsWV3wFEdhR9 VI0P1oLy2H85/EBF/EF1/ELduFcPxNer1vFB6un4Y+qNeFHVO/6rHxZf7CfHP/JfxR/xy+Nl/Yb4 9X5bqCNOu7L59fHyfmm8tZ8d7+PHxpf6AfHffM/4berFeFv1RHyIeji+UTWMa12HOmpSVzXqrE7d d8b7BUR6MDm+Vws+x+d8iu/pGd+oX46v1p3jS/XD8bn63viE0G7haRwfrR+LT9dPx7/Sr8eX6A/j K/WA+Do9Cr81FV5B1N/WLq0RNHVpTG18EVGLuR7/dM5a/NYF/Nc5/NjP+LMf8Ws/4N9O4OeO4e8O 4/e+xf/tD+0SmV/Gd5C3i7K90ByA9jt4jsB7HBknkXUamT/hC3/BF/6GL7yAL4zj15xu7XxANOfy lzEmsz8bzT5qqDukP3Fn9PvQv0n7nqetnVw6k9h2rzuBrsh4lfJ33M+6l/te4z/g26zHuCXhL2wk pol/6WOyWxpk///+lzokAkvpX+qQiO1Sf6kj0r95KYwUUxJxCv7xLz1dPrJNSYSc+Jeezoa/3nSS tepE0l9+isZjk52c4r/0tMpOveRfeor8ZwlWHkEhVpvc4DrWrHSsQs4ecz/Z0+6oPef2WMNamdmv tTf55bYYa6Osjw/6payXK20vL+2RehbZ3v4r8uZSNg+ahbYI62p2+NL77TbuDlr2MPaou2APuLSs fNe4HdS5jbq30IatyShNXhnWUyKs0LZo7oaxbgr6sYb2pI0vsq52YH1txspZl7ZXAon92crzFvK2 UbYdmp3QJsCzG949yNgb8HsUjE9l1d0NtrmTrM0nWKOPs1YfY809ytp9xCXWvZfnfeTtp+wANAeh /Q6eQ/AepvQwtZwI6QF4DiLjAPJEdjR3Z9x6Pm2HYicr/h7Kv3VSv/BJzi7+Peg2QrPWfR9igbVO eH4iJjgTPm93UUQ9gFEa7e5z0117t9C94da4/ozoePjnUfPywCcyvkNGAhQbaPlSN9jNdu9A1ckN ZbXuzRobxQXy3Js1vy9r8adA5P+riHrngWOXiKijljW31W1T29A2sq1tPfs0n161pe27toDtbbPa fjaN7W9/ifezh+O97Y74u3Z1/FW7KP60/TLe2s6MN7TT49WtyPirEU6kKWnsx1Zwve1jb7Ef2JL2 bVvFvmTvtk/Z++yjtrFtYB9AfivQglY+aB8j/1lby75hy0Jf0H5is9mByBgSEGnK9Phddg5tmxtv YBfEH7XL4k/ZdfGXbEL8bXsk/oH9Nd7HJtY9xP4cH2gPxT+x28hfEX/Dzo8/a2fFH7NT443sJGRM j1cK6ZR4FZ4rU1YlyI6+55H2Nbd3WalTaJvbSqG9kj5Mb+T5YVosNP/xPSC/z8t85C+Il7BL4vnt qvgNdnM8s90bT22Px138XPx8PI39LX6dPR/PZ138NpvalreZbQ17g61j89t7bQnGqLoVGZeu7z+a DxsXnIvb+Im4sfvj6RiXqxi7G+3yeAG7mDYtRq70/0ueF9KCb+JZ7YZ4Brs7ru3R+AV4f0HG2YBo Pu5jLOrSprq07U60q4q90ZaxV9miNp3NY429Lqle4bkOjctvL8SLWw1XBkYtq73H5kNLS6AP1enb XSFtyJjKc31SkR3Nh7RvPvMgdUr5/CRdkPTLeC10QtpeJdD8K6t5beD0S1jNs6GGsimymq/sNPA1 +NbOs5nC3nN10l5U9qSyN5U9quxVZc8qe9dabjLR6mRbx02y97mJ9kE3wbZy4207N852cV/Y50E3 ot9n3EjbyQ2xj7u+lL9jm7lnbSPX0t7vahFF32Nvc3VtHlfbZiEidozASbDb1rYbaO0Ke79lPbVT GLehjNt72NrzzEl7W9O2RIf+HWtOfn9vB/+N1tw3pDE7CP3oT/pJkB3N8uwwvrNsYp19eZ5kF4W8 SXahnczITyOdGWiSv9thTzKTcZ/NfMxmXmZDJXIWBXwNvoUnk5sf3hXcEdKvGFHhm0UqvJGl3Ml8 pWwPdPm9VGVkRf2q5abb2kEPyof8ajzXQgckrY4+yPPdpEITjfuLbhS6MQkdmYiuTEInJqM7U9Ch qejSNGRNt7UCxvM8nrxxlH0BzVhox8AzGl6RMdJ2RYakL5H3CjQvUZfITrZkV802Rs8eRN8eds/Y x9zb9gnXxz7lBsE73EpbBCLnWep6Cvkd3Ge2tetnH3Ld7QPs2O6Dtz4yGqCjkt7jqqO71dDh6kF2 NBYVXB12hHWs1Cm05V0DdocNktL72SHey4zUCzRR+1ag18vwF+vRut1o1kl02qFvWVwNbKKWvT28 6akT5BSDP4+rT1ldaOpBWxee+nYjWrka/VyBxkbpMtKl2I7IjupK9PyVsZsq2E9V7Kg69lQTu7oL +6qNndW10h7hX4C/mAL/UGzvPep6Hl/dnja2hLY59pe4YtyJTdSyTXh+EJki+z9eMX5/VzA4vlUP ZD/0KfiEvVHf+GYdxY7tbFrfidiwg73WP2ZL+Oa2qb/X9vBV7Xx/O/FsLltcZbKd1YX4RHUsflRt j+fWy+ON9Jz4G3pCfKwewZ5P5IvMgfHFeiT7vSnx1/TCeAO9Pp5T9mbqp/h4lZrYO6u9TRUkJi5r 5/m77Du+oW3iH7LF/aPU3Zo2tLPWSdrGetfOOvcEqbQtWvkSLPtjsNZqv4D8iTbmB9pUvrtN7Z+j H+0CLFpk0SbrBhKvTrQX3QJ7wa215902+5tLANG4yPMe8vdCt4e6RP6lx/T3vwYYnVpqpoaYRqAe qKUGm8pqkCmnBpqSaoC5TfU3hdWnpoDqZ25Wn5g86mOTU/UxuVR3Pr9qiqjnTSn1nKminjG1QQP1 rGnK50fVC6adesN0UB+a9shsi+zW4GEg9aV0xY6+J6tMG6qAWrSnHu1qRNqMtJkazvMI8oZTNsxU Up/R/s+SvyfLS1tz04Z8qpe5RfU2BflchD7crvrSv0/oZz8jsoWnnBpK3hBTjPYWYgxuYQzyUkcu ym+CLju8iWlf0NvkQK7ITv6OkD4LGjAmtUEV1Y12vIC8lxm/N2hDDyPtETk3qncYy5eo51nq7ALt k/B0hvcp+tQlIPLn7ehrG9rThroeU2+alsiTeoSmjepqOqrXzZOUdaLtHRgDSZ8gbQfa0qc2oS+J shLHrD/z0J/56E/5ACPyOwTa4eSNoGwENCPC2ErahLIHkNmE8RDefxlNvPbaJaKJnKHmTJfUssrM SjVG4k40qR69aqBeoZa3qOXDf9KSlKzQUS+rIzul2lIeWkkrUF95elgRWuGNNEj4pPcP0KaGtPU+ ZrIeI16btBYzWp0+SH3lA3oh6y1Tg5mthwY0YpaaQ/cwvImaPzykLahbnqORvVy8vC+0pZOSk1py YktObrVIOsklJ7rkZJec8JKTXnLiS05+yQkwOQkmJ8LkZJicEJOTYnJiTE6OyQkyOUkmJ8rkZJmc MJOTR3ICSU4iyYkkOZkkJ5TGJp1Ykl/rJP5SvGr4FY/8mkd+1SO/7pFf+civfeSco5x3lHOPcv5R zkHKeUg5FynnFeXcopxflHOMcp5RzjXK+UY555g+nMEbbWJ+knFujrnglphzbi3YzvM+Y/xhys6Y NF7H0vussSt9sdj1vmYsl38gVsg/EivjH4tV8E/EqvtnY/X9K7Hmvnusk+8Ve8P3jQ3w/WLTSef5 AbFlfkhsox8W2+OHx46BszzH/eCYUf1i6VV/bHkgYzmINWVwrARpBTUgVo2ymuqj2D3q/VhT9Xbs MfUSM9Il9pxqG3tRNY+9pO5nbmrH3lCVYz3UbSBXOFmXUk8X6Vt0+ulyp5dScgpKTk5JeiNpdnQj kp18uijpJNflTmWl5HSXIOrD3BSeIkvJabQIfz7VFtl6dPrgzycJLnXiQE4kSDrel0G3S0NTJvBG svoHHf/n0w2XOgUxLNCKLVT8h19PRGMg52FT8uuLlPyK48mkM7btfRPzuG9s2iX9IiSqKzpferlz uik57xuhvh+OzGGmNjYrsn//9dLQFJ13Tcm52czQSJoGOSI3HXIz/uHubucOG+WPm1/dAXMWH3AW X/CrW4wvmG28m4AvGBn4RE6G/1PZlQZXVWTh7/SFEJaCQBJkEaEGJRAgYXFhsURElMJgYCDIOICM CkQJMZAACcgSKIaRpYgsYUoREGQfBxiMw6oCsjkMBATZA4KsOiwSQLbu+c4l9+GPmZo3qTp1+naf 8/Xpfu99p/u+23luMbljBTliDblji7lD2zv0sfaYKeW+p92ZEn2aco6+F3zs0P+2cX3JH6lefeqa rodXxbX3yrtEL4I8Y8g3zl4xGo/ilCEHlWNdRbZFu8ZeDdfOq+u6eY1cL2L0IQe94etW5KTW5KRW rr+PHfS1wuWTi2aRkz4gN83y0tw073duoveSy/XauGG0HehpPIrTxr3ltXeDvGSX4/VyY7102uW6 qfTNI8ZUr+BX+nPyW0EJdtCXkMsiyGmWHFfsFpDvFpL3FpL/FnhbyH1ryIUaj/pvcDO8reTHQnLh Mcp5ys+U2079p3se3vc1qEtRIjDDxw76ao/pXgdy5PPky6cxm9w5hxw6j5wzh2zzkVeWfKrxKE55 2saQUx9BPm3yaZvvtSLeM5jmPUuMduRZ1W0xmXiTvBepFTvoKwedyLsvkGO7eKPQ08tBqpeBLK8/ Rnm/x5+8zrTVeBQnCRO8VzDG+wOyvbeR7g3Cm+TRV8nXXbwsJJHD2/s6k/ydRcxhvFbsgBeUb3MR 5U0il04it4/Hs572r34j8bQ3jnXjyLsjydPKy6pHkGdHIJqxRfm+/yvHB6vxLOzm6m0fV3kHTBd8 x7XFAdMM33LlWGhi8A8Tia1ca31p7pJL77gCc485HFhpSmOFKU9dGatNdXzO1fk6+m3k+upLk4yv TE9KP16nYa3JRIHJYftwfG20v//3/lk5bDIqsdjOVe0u9rOHce5lvHsZ916uJnebwfjGDOU40jiG 13CYbUdpc5i2B7ny3W+i6ROBnb4EuJXwd6NSDp9xPJ8ZoYCxOo4TrPewwe9Xfe4xZ/zCnHGTbbf5 uXfkl9JYZirgL8Re4UuAm4H1RqU/fXtyzMmcw7bYwlg2Mf4vTDXOhfarPjXwN/MY568Z56ktfZIp PdlvX16n0kYl2JXoGO+Pc4sZQptM2mg/apOJVWYk1phR7EvnQSXcXW46c8kASirzUKprQr5OCP3v /o9dZeaLaOaLWOaRGmaKq8NcEWfedY1Nlmtm1FftM1w812SPMffUZu6pwdwTQ3s9ZVjef5o5tKP+ 1ZPN811Fo/jhxqnncbbJCdkqx6gP++d1gjjjTGkTa4ol0lyUu3JarslJuUjbk5QD9Nvpy0GWD7Lu INsOyHU5JDBHpYI5JTXNJWlM4g360nKCMaYxceNNhFH8cOOsZzZLnNkq9cwO/9xKHeogznWyTLbL AvlO5slZ6uuyREqbv0oVUyC1zAZRX7Wvbr6WimajiH/aaKX8IMvps4xjWC5f6Smwkr60vFFWyTrq tfKpKH64cd4/mzWOnrlEGCWr5d1QnHqGBmaKFMsEOSdjOeNjpJCyTUazv1z/XJfar5cc1g1j21Da ZMsFGS43aFPKjPfP3QR9aTnG5FFmSGX/fE1+2HHqmZqr0pXSXS5LD//MTXC244B04quZJMepz8jL /vkbbT9N2+OSwrbufKVTQnFoeZ90k72020d79Q83jo6INZ3wED+jNahrmY6oHfqcxOGmxMFKPDzT GJH8PFfgDj+Ke7to7ttiTUdfanOvVot7tprmCVTjTj2GO3X9jcYy3PWDcjMUp5b1/xnXxTWpR634 4cb5JPt8nP01pSRw5hNQKRRnHne2oyjpxHwNt6QrnLyI0oyznB+v+qp9c/+6FOO9J8nsuxeuShp+ ou95ycPZUJxa1t+knIkfqS+J4ocbZx5eMtORZGbiZUoXMw1dQ1w3Es8ZlVHoYMbRbiJF7dVmIlJM LnU2/TJpoxL4TUVzozIOTc1oPE6Mlj6O2gzBU8xDCWxrYN5HQ1+CnLsQ9c0yNDJLkGg+od9sPOnj qM1s1s+jzGdZ9UI0KbluYNRvCbX6RvlYERxXImNt6LepbR5xtO7BuJubKWhmJrNuCv3UNtw5i4Ce TP6Q8mdTBjOZn2aG1pTDsYhzspT5fCVzyGq+R1eb1iw3ZI6qhcXMOVz70l99ovEB329z+V79hO/H JbRdTp/l5i2WB2MB88oiXw+hTzZ1Tgl28LkbgFlmIGMYhNnMNXON9p3hy0LWzyfOPOa/uaExa7lv yd0hvQM04D/c2flvYz5sL9oj9pw9Zs/YE/43y+dtEEexreou2QrujIUrstes2mr7WXvZ/svetTds pLtrq7gAS8t3bay7bau5GxT1DzeOh+lZyzn7sDOuuvNcVffgDutVu8cW2/32pj1k79jjjOaUjXDn GdklG+OuW/VV+4ruDuuL2X7J3mac1+1pe9UW2Z/od8F+G7rDquULttD/Pv4yRfHDjXOS24cpbj/l ECa6I5hACd4jA10uMt14ZLmplA8xzC3GCLcaY9wXGO924D1X6PurTy4xRrpdyHab6VOAd9xSpNHn bfoOIMYg956v09xYtuViMLVih35Px1WR3zhP6rsraEK81m4LOrhPwb0fXncT/VgUI9XloZebg85u Fdq57WjhjtH+Z8TTN95FhbhGyw1ctMS5WHmUovjhzslZNw4/MLbvKUWMs8iNDp0PvOjqUlriR5eC Cy7Dty3yf3U9g5KCk2w7SZsAS8unXB2ccbVxnlr9w40jCvtQGXsQjX+iKnYzhsLQfcRExEgDVCbf lyP332LbGd9ebergNOf1JhIQKU1RSRqigq+boIowj/D6vm/oWxTsQm98g57Yjx44gd/iIpJQzD2T 5do/Qp5CRUn0/RQnUloA0ga/4HlcYZ47i844im7suzsxemOHr1/BdryKbehFrdjB69wXfWQgOkkG Wsg7qCMDUFb64Tr64BTt95fEsgOvEy8VJ5GOa8ikzTDaZtNnCJLp/2boddbyAPSTVEpfvCGKH+78 rsUhrMcRShHWsK8CShDnULL8cCzHWKzGZFrkYzM+xk7WFLLmgO+r9itwHItZ/gh7MY3j/CM2cU+2 lnulVYx96YN1M8vpWOT/ml8WRfHDjVOfDEsMPWUW7z8tFsQ5yIqk2VLSz5aV3jZKUuxDkmQfkeds PWlpG/lPlan9E/ZReYb1L9hqkmwrSw9bTvpYT1KtxUB7K9SXljMomfYuxfn4QZzcXPPv3+Tx/TZg IRvwlvUAAHF660vUWwEQL21Z2JpJ1RdyzQEA+P8AAPj/AADeFQEAiRYBAABRNgBI+DcAZPUAAAD+ eJx0vQecT8f3/z9ztaiJmihJBCGil+hl9bqs7VhswWLtLhaL1Xv03muU6DWI3kWLEkQnPZFKqqi/ 5zn3fd/5/P0fXx4vM3fmnDNnzpyZOee+37usyWxMut3fGZPNnExv+JMBZHUePn/4XGrZnOn5vssr HensS8ZtGekkOy7Vc/5kp1Y848vmZdOgT5eYvsl9ahQObBIZEdjY5PP1FDENkhN7xfTtHtuzS+HU 7n27FQ4Krli+QulWjRoUDmpQRh9kBMc6OoIVuUZa0tvsWmawVsuMlC9RPtLxjfHoylhjMlE+cYzv j9tq/VKOpTOmWLov7GGbzmRx0pkcTnrzNniXegBo6DgmELRxrAmlDKetK4gGnaCLdgqaGKcSeGZj nefAODEoHOM4TqyTiTI7qEG9OWhPPQoMcDqDLs5ApytlvO85jucY0MlJczqAKGewEwnCqJcF7zqD nKwgEzTpwDM7wPkBfGMHOkfAITvI2QM+tmnOTsptYCvtm6HZZPs7G21fynie2zlbbCB4g/7s4Imd CWbYR3aa/ddOoZwMJtrH9n3ax9undiwYZZ/Z4fa5HWKNM9Bap791nBSbzukJutv0TlcQazM4kSDM ZnSCQYjNTVnYaWPLOK1tTcpaPNehvS40AU6ErQ8awtPYCbXNaW8Fwqm3B52pdwN94UsFA5AxyAkE zZlXSVCE+u9mkPOTSXNiQQz1aNDJYEczwOloUp0Oin5OlOlLmUhbF/o6QBcO6sJTDd73KCvxXIH+ ctCVcdrhBZGmpBNmijuhppgTYt4Cb1IvRFsBJ9y86kSYvNDkctqalymz8ZyZ9oz0pwMG+qc22Pxr 25h/bJD50wZSNjcPbWPaAkBt6jVoq2r+tpXpr2B+t2XNb7aU+cWWND/Zt809W9T8YAub72wh85Ut YL60+c0d+6q5ZfOZGzaPuWZzm89tTnPJvmwu2hzmPPvxlM1kPrEZzHGbUXGEtv3gY5vZbAfrqK+C Zhk0C+mfzfM0m8VMsFnNGHbFMOQMAn2pJ4M21BuAytQr2mymPHRlQCl43gFFkfkWz4XpewO8Tr0g 8l8F+Wx6k5PdlVV2MTvvmbHmoXHMA/CTSWe+Y29/wy790mQxdzltbnNi3DQ5zXWTx1zlrPjc5DeX TUHzmXnDXDCFzXlT1HxqipuzpqQ5bUqZU5THzTvmCG0HzdtmrylmPuZs2WHeMtug32ReN2tNIbMC GYtMATOHcipt4+kbCe0QMBi+wcgZYN4FpUyqKWP6m3KgvOlnKpq+pjJ4z6SYqqC66QOSTA3TA3Sl HksZbaqZTtB0gLY9PJGmggmDPxg05jmA9pqmChTVaallSpu6poRpyGyaMrNANAs2r5pwkxvuV5CW HclZTQLnWk/O4kTqPUwO052+blinG3QJJhda5DK9eU6hvT+WGwDSoBsJRiFjHHgfq04GU5GxGCyi bT70c+GbA/8sZM0wec10xp+KtWeAWegzFyzAWoux3jIs9gF6rgJrsNw6rLsRK29B/+1YcAcW/JgV 2Muc9rMaB7HmYax5FGseZ66fYNFTWPQMcz9DeR6LfIZFLmPRq1jvuqnDqtdj9RvhBU3NF6YlHhFk vjYheEeE+RarfG86mh+w9Y9Y5kcs8hMz/5F1+ckMohwGxpifme19Mw3vmmt+N0soV/G8wfyKlj+a PXjbIWQdQe4x8xVafYFWd9HoJhpdx7+uw3XD/GlumX/Q5V/6HkP3FD5r73HX/cytcR8//pM75yF4 bDJZYzPZ9PYl/ma22WwW+4rNanNTy2dz2AI2p32T2lvUStoi9h1bHJShXsGWBuVsZVveVgHVeKpp K9ratpKtS0ttWmrZGrTJv3VtdVuPlga2qm1Mb1PQwr5nA+EPBqFwtQVRyO7IGNGMGmdfs11sLtsN fXqgYaJ9ym7+x/S2D9jZP5l+9lszwN5lp183g+1lM9SeM8PtSTPSHjGj7T4z1u4y4+1WToX1ZrJd aabaJWa6XWRmgTl2oZkL5lNfCpbZxWYt2EnbLjsfzOC0STa7Oe0+tiVAeuqO2QP2cQrspzwADnIy yN3r3uIOHiP3cW7uW8O9a7l/LfewY6qCSty5GQDXDjyC9NTT05bBlAWVqNcEcm8HgjZ6bxtTVmXm NfH0daUtDnBHm456nzvc61bp2mg9nd7xbaHtCGKox+mdn55bw1EZ3Si7+upFVPbLxAHpiQcyaBlD GQc6U4/38XXReCGdynRLty70r6mMLCbW6Qya++KJgtrn0ku9EuisNDmUPgP1O/ocrbijz/m0LzP8 T4lFJCa5o33R1GOIT7xS+j3aWOKVWI1XLDGIAc+0P4Z6tK+9gNJmhTY/z9mhyaTt0h/ji3OindyU +ekTmvx+njjinjiNf2pou9BEE81E8xxDe4zGRe0coftPpyh9lnbpj9a4SUq3Lv3/zTWV5wHaFq0Y oHGUV0q/t07xGnOlEntJzJWqfULTGXQhtupKGa9I1bKHlm79HZWRy0Q5Q4jPBhOnDWYM4g744kDn /+EV2XE6/gBoBjod6e8A2mtcJxjivKHyshNZSGwnMZ7EehLzDdF+oYsEYfCVBe8ip5gizcmjvC8R r6bps7S/DOT5ZWS8TCl1T+dTxEnfgB+sxI0SP0ocKfFkmo9nIPWBtA2gbwA0qdCmwjPAOQVOa4ke vr20gZhsg+1HTJmq8eUWjTcl7kwj/hxMHJpGPJpGXDpI+YT/CDjE2Ns0Ju1PLNrXWe+TI/I8f9lM XLiZ+HQTcepG4tUNGrf2pS2ecdoRrwYCoQnwr+tW4tMtxKpbiGc3E9dusuW0f6viDcbMDp7YrcS0 Um6j3Kr4bx/M0Dj4qbZJ30wwC3jtUnr2HEssPB5MoH0i7ZOhmwqmETcLncv3L88Piaf/tZPABPre p30c/WMVz4gDRd5bJkTj5UzExJmIhTMSR2ckns5AXJ2B+Dq90wtIrN0fDOIAHEL8PZw4fBTxuMgR eSPRZRj1wbQNpK8/NCnQJgOJ0buCWOQEgzY6npQZtC7je/4YRJweTLweQtwu7W0UhZ0g2lrR15oY XspWlFIX+uLKm9NIHB+pMX0Ac6mLHLffpavti/0DiO2lv74TbhuAhtA3Bo00D/BkhRL7h5EDhGku IDlBK+rNlUZoQ2wz5LUC4dTba64QrPmCWwq/51PB+Gkw/ie5RKjtpX3BihT0SkW/VC2FrrDy5DCt 8N8gxSDmP0j5g310QdRb0dYaXxa61vi80ErdO89r019LcxXJWdJ8dAOpD6RtgFNbMchv91gz2PkX GOhKgnL01VYMIM8Z4BSC73PymvPkN7GKwX7/b09u015znP4glfzGzYOiNS8arPQd6esITQeldeml 9OxNBKv5UCfTGIRD2wHaLshLVDrh60i9E23RvvwpxrQCdZEvvNX8c5ccqhO5VLTmVNW0P44cK5bn GFOevrKaZ3n3fTC5VbApQr5UjPyqOLnTO+RS75JXlWLs0ujg0rt88lyK/KwkOdc70L4NhE9kvOU/ 8yI0H8tFPpaH/lfpz4/8QtC8qXShijfpex2aAtC+hry8jJkL2S9TCn82p7LKe41o9C/bGgSRr7Ux j8jrntpQcjw318uIjMxKL3yRWs9Am/Q9h+6JDSHfCybPa0Oe19r8oWUQ+Z7URXZTHaeIedN8b4uQ 871tfuS8+Zlc8FdywvuaG0qOKLliDfLG2ppDPrINzGPOkUdEWv+SXz60rp5/2JbQNUPXxrTV0Tzz b1uNvvfoq2ge2HLkmaV9eWZxxivKuIXNt5prig7NVZ+ixGbHibROkCee1NwyszlLfvcpueAFcsLP bC7yz9zkoXnNTfLS2/Y1c1fz1ILma5XjyvuG5y9ol/5b0F2H5wq8n9lXNG89h7yzyD6puaubt56w MnY63/hS9/ZzBnLaDOaYtmVU3Y7DdwwcBtInOKqlt0fSa667jP5VzGOd5sOZiESFJpMvR85CWxb6 MivNMugXWuHz9kg2zYclLx5EnjsM2jHQToB/GnJmW3eMhTzPpn0adpoI3RjmNxwkW+H3zpcc5j1f Tt2A9jbQRmt/DkUD8vnKoJKWr/jqwlNe+fORFRZGx7cYpxiQPFzyccnLyyOnotK6PBUYoxxtZUAp +t8BRaF9CxSxrhxPVmH/HZeR3D0jOfxLJj/tBeGRvP4NpRG+bJTZec5uCtH2GnT5mHdeLV+ilLrI qKjyXiXf/xaQSZGxWTIzYx4CeR+QgWg+K+ucU+mFL4N5Rd8ZpNO+Z/A9NOngSQdvemSkIxv05EnZ Ssd4m/zhFBnnSTLQU2SkZ8hOz5KtniN7vUAme5FY+xKZ7hUy3qtkwNdZgxv6ziEzmV4mskGRJbKz UM9u7pBN3yJDvmHymGtkx/Iu4grZ8CWy4ItkwOfJfM+R9X5KtnuGLPcUOKllGV9d9PHOuDfNZnTZ Bt8O9NoN7z50PEjGfBT+E0rr8hzn+QjtBzSjlsy6KDxFzFZ4N6mc0iozD+2DeR6JTuPJ1iV7n0O5 iLmuoG2t0gqPZO2va5v0zaGcStv79I3yvQMZqrKKqdxXsGF/dEhFhwGMPwik6XsSl2Yo7WnYOA2a QWAgOg+EZwB6DVBe78yspu9LepPl9zHvgco8VwTlydvLmn7Q91N64SvDeOVAeZ4r0l4ZVIGuKqgO Tw197yKlWxfZ3l6qZmJALP3yPqYH9STtFzp5T1OT9hrQ1IDGo5XSu6/cvmhtE5qa1GuYTlrW8tWF xrNPOdMCyLudMFPBRJpK3MDy7qeq0sYofTVuwcqmHX0RzEfogkEL5Q1WOSVMAl7XA3TB46LxxPZ4 nLwDakMm15LVlHdDDVj5unhCTSxVjRHf428lRqhgApDVWOVVUDSm3X3PVBXLVaelNpYNYKXkPVMz vCGQ1Q9m1hF4dJTJiaY5sEw29MiMHpn9+kjpnTPd2AHd0ak7ZQ92TU94EuFJMlkpPZ7MtMv7KpGV Xd9VdWMu8YwRD283xpMynrKbIpd/XwyFPg0MgKc/SIGvF+Mkwpug77pyKU8C/EmgN88ptPeHZiBI g34ofCKnisrMr++5FmPThWAeus2hnAom0/4+GIeeo8BIeIYqOKGRI+/NxoH3aZsMpkKzGCzyvTtb gozFiqx+X5jByTCT9ZqFjnPQbx76LUC/xchx37dlRY/stOWg72UzF51n0z8NHuH1fFB27zR2r7RJ 3xSep/Is5WTd3e4O9+KEvfjEbnbmTjTZzvpuwU82saPXsyvWsNbyrm4Fu34Zu30x674A/nkq05U7 A8yifa72Cc3rZik87nu+N5HxllmHzI0quxgn19ucQsU5jUow9jtmDxAdvL1+Wt/vleMUK2s+we+O 46/HWOXDnBAHod2vfMWVbx9tB+g7BM1RaI+x+0/AdxL+0/qOsLyvrOCrl/O/2zirNO67xLM+2rP6 XFbHl3qQ0hbntugKuph7ePoP7Mfv2GHf4v3fmBDzlWltvmTfyPvGO+yQW6YeJ31tTvoanPJVOeUr c8JX8Mkuz0lfiVP/PXOZXfg5e0zeWd4w9eFrBH8z5LTk1ghCbqj52vfO8jvOge85T+6pHq4uUnox yU/6/rKf+Rmv/lnfaXbX/nuK7vqe80f67kF3DzqvFD5Pxi946y+c/z+ZMWAYcgZpv9D9SP2e/93o BNon+Oml9O6R71mJ71mpn1id3/CmB6z673jBH3j873iIvFMVeuH/zUzneR40SyhX8byBPnm/upv5 HlRZ3t64wb17A6vJ+9U73JPyrvVrvOMbvOM7Vl5ohecb3zvZu3jAHVb3mvJdYKeInIzUH4Dfte2a 4ndt8+Kye8ax3xtjvzXPkfOUdXiMnIeszd+M/afSCs918xfP8m73EWv/jHGN/cGkt8LfUmUVM/Ku tggobPPZ120uaq/YV212m9tmpZbFZrOZ9W1veivvfuUdsLwLlnfCGex9ZP1s0qm8H7QubRl974sz QfsSPMKbGe4sSMxqX0ZiLuTno5bf5rSFbB77BiMWtgX1vbGXH76r748L2xL0FqX9LdWxIK2v22K0 laClhNIUBUWs0Hu8JW15nivYkvruubh1ZRWBvjiQ9opavkNZUlHeH7dVsnVsZVDJ1qanBlTyrlre WVeyZfU9dnmlF75SoIy2V7bloCkHbXlbEyp5rx1Aa8D/lHX8OU+kvr+uaENBMPVA0AKqpqCxfc82 QFY9WxUOeSteHS1q8FSTntrW1S8ACumtrW/M5d+60NSDtiGtjaFuClpAFQhXMAiFqx1o6ytFB+9O 6mmfmu6sUjzr05k1ibWv2U72TdsBe7VnxkIrPB2YbSfaYliJzqxeV1ayOzwJ8CYhQ+R4edQUu9hM sivJFtaZcXYLWcFOM8ruMyPsETKJk2aI/dSk2UtmoL1uUu1dsoxvTYr90fTCg5Ls3ypLZPay/5g+ vnf4/aEZCG2avQH/ZeScQ94p5B5F/n7G2WXet1vJQtYz/ioykiWqh7dv1uq7e3mHL+/y5Z3+AjMH zKI+HUyjT+in6bv/JWYGdXnX/wH1tYpF/nNZ3v3vhFfapG8n5S7wX7nQeO8td9oZvs8KFpFxzQfy ecFMLaXPy/N2kQHsssnaJn27qe8hM92jnyek9/W7pefr8tnAIf18QT5nsGafNdBb+B2lE749lO5n D+mV3vuWwPPnB/3fEnD83y3or5Krm7ZOHrDcRDoLwWIT4SyhXAaWm1DK1qCFs9TUBFWplwOl6CsA 8lF/BWSh77ldSr6+BA2XoOl8MAMtJlGOpewGWlAvh4Y5KV8GOajnoMxmzoNL5GFXwU3qj8AzcrAq TnZTw8lm6oAA6o1AE+rNQaCT1QSBYOqhlOEggnoENJHOy+AV5pVL5/e/35CQT2S86ETm2E6Rh7qg KvztKYf6+6T06Ns6i+hf5O9ri80iQFu13TxffRFxh9CLLh+obV0+oV2MnkvAcrWx279CaaTu3Vz5 1L4fYOcPsPdy7L4c+8s6yHosNyE+epERiu1bI7MqqES9HChFewGQj7rI8rLf/bo+S81v4E8r6ybr t1xphPYVkAU5z6F7xI44AA5CK3z7oT/gq+dSeZnoGwvmaZvQHWbdD2vbWP9NfpA8/wBrfpC1P6Q+ 0E37he4o9SO0HdY+8Ytc/0P/ij8TOoRfHAQH1GdcmUJ7mPKw+lAOyuyU2f20UnrzroNv1ABVHPEr 8a+s5itwl5z/DPjERy/8f4B/kFfFyQFPdnizm9paZvWvT7D6XhZ8MAu+mBWfzIpvio9mUzqhD4C/ EWhCvTkIpC8IBFMPAf+VWf1Zg/hhO/VZ8d0crG921ll8OwvrnEVphScUOWEgnHo4dBH4e4STE/pc 6scix9v9O9777ztC6fy7v6WVEVeaEcTlwziZBhMnD8LeqUQ5/YhpU9CpD7FnH2JF+bZAKhhEfTBx 4zDaR2CL0cS54ygnEvdO4fSdQSw9B/4FYAn1D2hbzRqspX8TtFuJh3fAvxtZ+4lDDxF3HiMmPUKG c5j6QXCA9n3EpHugEbpdjLmTOPUjsB3ezWAT9Q20r6P/Q+hXwvcBcpYSwy4izp0P5hDLzqAcD8aS 7Y4mBh5JxjmczHEY2ecQ4tvBpglzaka+1YL5BXIitibCDAKtmXMr0JK25vQ1JY9rBBpAWw8EUK9L X11o62OjRuR2TcnjWpDPtSLCbUNOGEpUHE7EGwrkuRX5XnP6mkLTiAi4PjwB8NThuQ65ZV36A6Cr B189E8dYMcTvnaDtgJ7t4YtE13DGCEWvYPQNQs9W/NucFulpRF7e0LRFciQSIpEYgeQwZh+CNdpg iZagKc8NsEZdUJv+WtRqgGrwvAd/Rc2+W7N2waxjGPlSKPUQ1lky/RDWKhTaCBCJzdvC0541iIKv I+vSCd+IhjYG/4ll3TvD2wU58eRbPbnNkjkbe5ObpeBz/cjZUsEgztfB+KH44osntZeHyduVFMZP QX5fZPfXtzjFyJPfYi3fYF0LsL4iIx95b37kFWKd3kR+UeiLs0bvMm5ZUIF6RS17U/bxvbnx4sKx 6tOl8Jd3kVUKWWXU5wdCk6p7oYLS99G3OZVoq4T+FdGhPH5VDh3KwFsaGWV0b3ilyPVipmPY7hh2 PMTs9sO/G96d8G6DbhPjrmPPrEbnD9hDS5jjDDCF+gTax/7PnpvK8wzo5tC3QGmLm+XYZRV9a5Gz EbqtzHkH8nczzj7dc1X840vZUHUqTH5dCfqKjF+BvFj2muw52XsV2IMVlX+PT8Z+3atVVNYRfMCT d5T2w/QfVJqK5MUVdG4f++Yn+1f0cfdwOfZweeZaQcf2TuoZeOocfHI+pezlpaY6dqjGnKqQu1dW WuH5kHIlz8tp5+6DtjrZWw3d8yLDs3UK+6Mfvp+KRw9gzwxi/6SxW2TvD2XHyFkwAs+Xs2E0u2Es e2I840/Q88M9Q6YiewIYR30MbaPoH8ZeHcpOG4wF09gxA/WMkLOipW/MIC1T2DEyvtQ9HxvAeAPg T2XsVHTojy794O2Lbn3RMQVdPRn92eH9kZlK/wDGGAj9QPgGIWMQMqRM89VFrhdjpvqepX0gc5Pz KpX59VfU9Zep+m7N3WOd9byK4BwK5Txqw35tpWdab+yVwhz7qb4BypfC3HujSzK6J6JbAnp3R9+u zNeTI2Ucp4NX9969JSMjGRk9sF03+OPh7wp/F/g7M7bHL2dnPHp00zO1BfRN0akROjVg7HogwF+K TC8/74puXUA86E5/AmMlgWSlD+DcrcNzbdpr0y/nbl14AuAJUF4vZ26E7o3/PydvGBoGMcNW1ALR sAXnX3MomnFGN+Xsa8y51wj9G/p0CGD+9TkPG3A2NuKMbMwJ3cQnTU7tFnqOyykup3kL5toc6Y2R LGd5I6R7Okjp5Tc14KoBbU1oa6FJbaTJWR+gZ7/cAe2UXvgb0F5P74FQ6IKhb6P8nq3k9K9Fb00o 5W6orneES1eTek3aaiOxDnR19G9d/VvHd3N4kW4d9mgdOGvDUYt/a/npa+sIcscEQBPACELrRVLh xIlyx7ThnG7FGdaI86GBvgWurHRCX5893pD93kTvpRLMupjyhcInZQTnfJiv7kWdIZxFofCFICuU 0cKwnscTondbacaUt9dVQFV/KXxeNBZFfxReK998lDfectdFQBcOXZiPVnhC0TECtKNP7sIOehdW 9Jcix9uX0UjvxNgduRc6MB/pE5pOjBPNcwztsZzxQud9j8K71waDQdRTuS/7GbkT8+PLBfDlguyL 19kfb+B7xfC54sh5R2WIrDi9h+W9fGH26pvsgzfYB4XgL8heLsDZIHew3JmvMc5rOpaMOYrSq3tx 41jVqZ5pZgubFvYN4sg3TKB9HRQyQSCY51DLWthiJtKWMG1tSdPOljbtifDb24omwlaGpgr01ZBR wzSyNU09iy/ZuqaqrW8q2YamnG1sStmmpjg5cREbaN6wQSa/DTZ5bZjJA3LbUJOL51y2jXmFMgfP OWjPDrLaCJMZZLKRJgNITz0D7RmgyWhDQLB5Cb7MoCBjvmlrMUY1xnrPlES/MuhZ3pYyle076FMM 3QqY+ragaQAaMr/GoJl9U+fvxSje2raBJhC0wB5im+ZAaJtjj1a0BYHW8Audd+a2t5VMFONGqX1K Y6uS2K04diL2svIdmjeU3uV7k2f2C30R2DbSvot9y8BTDuCjtoJPnitT6t49mA8bFGD+YssitpUp QdZVyjbD1k2YayNTzTZgDQKYb13WpBY610Dn6oxHRoxtRJbID6cM5jmQ9mb0N4QuwNb2rV891q+B KYu8d5Er6/eWbWlet61ZvzasX6jq4e1RWcOcihDWNEz7hCaPQtqCQRv6g7TMRSl14fMyw8yscVYg 6/8ycGUGUXf9IjvIpn4RZrLYcNY+XHm89zvp1D/a0t5W26U/k7ZFsLYR2u+NlYV5ZMF2mdAlI8jA GOmRnx7Z6Xz0GXkW38oCsqKH8HgxVj2b31RnTcWvKrF+JbHn2+wH8b832AcF2QevYsM82C8n/p+d NRJ+kZODfZALe+Zlb+THxkWxfQn20bush/hsBXynJr5RB38Rf62nyM/aCApo3fuem+uTb5qm+GNT n083Uh8XX3dphb8+7Q1AQ+gaKW1h9Xvx52Zaf8tXf/N/3jX9l22m958a3hvR5nh3U3ZXI7Stb8ui WTlTGyvUYBZVsURlZlQRzyrH7ErjWSXxxOJYpRje9RaWeYOZS1mU57fpKwHNu1hP3utWRFZlZFZB fjXGqYmF66NlI1vUNMHiTe3boITq8GKW4X3S/gYn0JucQG9RFmM3lGCcd/Hu0qxOOcaqyFjvoV81 dkAN9K3NuAG2PFYqxzhlkF+anf+ujtGEsiG61Ke9Lv21oKsOfVXmWhn+Csy1LPLcedZknrV1Xm8x rqeHlN5NWR8r1wN1WeVazKcGp4TMszLyKyC/JHqJPd7WE63O/8ylntqvPivlyZDSkyv6tkBOc068 Zsh07UT0A30D7Fdf6YswF7Gj9AtdSeDOU/hb+mRI/cU3DZ7XHeCG/BjsJBLYCjYTKWwCG4gOPgAr qK+ifTU0a7j513GzbuBG3QQ2c9PuArup76F9H/0i78V19CLM5cj6gMhjA9iE7M1gK207gIx/QFEN farxXJ3MpLrqtAGsU96a6FNb5SxT/dy658cuf3WynKpkOVXQS/SrzDiVyaLeI0t5jwxMMpaqzKca mUp15NVQGSJ3JTJlrh+CNfStg2YDtJvAZvh2go+p76F9r47j6ivjHkKGjC31F23tnTSXiCUvcvZf AOeINs+i+RlwihjqE+KK4+AYsdYRcAiuA8Rc+8FeYq3dxIu7wHZith1gF3HYHspD4Ajx2DH6TkB3 EvrT8J5FxjnknUf+RcaSsV9cF+8W2qXy6yOvAWso4zZErqvHMdVL9GuCnk2RLXo3Q3ZzZDdHdgvz GRHpJa03Y27NdMxPoT+jPI3RqRG6iayGyBTZDRijPnOrz9zqMXYAdg1QPbx3utuZ3zadZ33tk2eZ u5SbfX1S9+bg6fAZY19gXJn7WcY6zVinkHGCcY4h56jPZgfUfnWQXxt71vHL36d9AdAEoKvwCG8D 5tAQOY2YU2Od2wUdq4VvzJbmKrmCV/efugf/e8Ofwe8NF/Qd33fMoCEjNiafb4oGzUFLPKwVCGPG YeTrSWiRjBa90KI3q9CbVegD+lFPpW0gsxkEBkMzlHIYbYLh9A9H6xHQCkaiveB9ZjCVGcwCC7HO Qqy0mJkIFrF6C9F+FhhvLkN/BXwO/w3FSHMT3CHS/JKs+xvkfAvt92Y+WEl9LW0bzVdmi/mCGd1l BrdY2xvY8hraXUGjS2h2Ea0uotEFNLnA2pxDi0+x3afmZ+oP0esxeELPUyieovMzJDxjVZ7jJc+x kbHbwWbqW2jfAu1meLaaf7Dnn9jzPjQ/Y8MfoP8GDb6E/w64hS1dbfaa6/TdgOY2tHfR9gv4vkLG N+z079jxPzCbHzkFfuZU+JWT5jcs9JtZQH2euWfmQjcLnhnInIKsiVhpHLMbyYyGgaH4fx+QRFsS lkxk9onQ9AQJzDUBHXqA7vDGU3ahLQbaaCzTEb4obNIeC7TDAm2xVSS2i8R2EdgxnFmIZ4Syd0KZ RQizCEb7NlghCM2DOLdac4YFcTa2NkvxyUV41Xz8dC4eNou9OR3fnYrXTQZD9O1IUzKR5ozanMyn hSIKnvagHfyReGQ48kP4G6yZdgSSpUeoOsIVjdQ4pHZBYmee4+iLhSMGDaPh74Ssjvzbgd6OUHUC 0dRjQJz+25Fcvx32iMBOIXh8EHYLBZE8t8denajH4P0dyY3a4/2ReH8YmgebNHQZgh7D0GEEOoxk h45mX41hx45j545nB09gJ09mV88Cc6gvActoXwXWQLMObIR+M5A9+eIp6cXFuxhzl+5P2aeyX5vg O42wfgN8pyG8jak3pa05aEl/KxCmfF4+vlv3dihtodou/Tux78dAnncrQpVG6t5nmIewwG6frAPU D2Alr5Q+7x3ECaxykuzxJB54Aosd4+w4Cs1hPUs8+l48S18fPEvoUoCcKf2V38ubjuLJxxRp9A3U PqE5SnmEc+cw585hPXeG+k/tU6zAJ3r2DFde6T9O2wltH6Vn0Sn9DqFrj7PsqrN6Fs3C46fQN94n Q+CeV6fNbLBQab2Y/wL1C7Sdx7/PKRZyhrg0Lu1inhfTvgSaJZxpC5XHyy/kfLvIWBcZV9ql/xL1 S7RdQU/p98a6hWfdZD7XwTU87SrlFXCZdvecHMXOHuk7I0dpKTzemnzHafIDZ+QP7MPvzEzOyqmc NhM4ecYqndDfxlu/4CT52neufqe0K/RcFX4vgrqCJeUsvc4K3OQcuM3JKGftl3jS13jht3iy0Avf 19S/5ISUE+4OnuOdx5dZmSsKV9YV/TaUGw2ex3LnsJyUcj5fZAU+YyU+g+aSj1Z4L7HqFykv0HaB /vN43Hloz+p5foZ/z2hd5Hg2P8/5fk7P+ava7v79Csqf4Xmo/d5eO8n5fgqc5oyXu+AMOGceKc2n ek880rviNDhJ3yd6VzxVPu8d2mZ4N3NX7AMHaD+peIoFnmKJZ1jsGfv1udJt0TvlGSfoc+WRuuej mxhjk94zT/20W6HbStsW+uQO8mik9N4nH8DycvfsZWU/5s7YwU35kflJ76it5g/4/lF64d/GnLZz f31E307ssUvvr29Z4bvgjpaHtLyjcr3vHxzUFb2h99t+vOGAn/429LfYfzcob/rppPT29wG8aD+Q Umhc2mvQXKX9Ku1eed1v0206jy/R8S763SKCuuHzqutKuxf+3dR30baDfvG87cx/C94ovJ5t5nOX LtB79T7R9312x2/ct79wFv+E197Dzt8pvfBtwg7rsZ3cyavpXwHdMvgXg4XUF1J68qT03hOOxGvH 4u0T2J2T0Wc6NpmJ7nOQJ/f4fOUXvns8f8Mp497pU5nDRLx8HPwj8TiR4/lCqt7vcs9fZOde1D6h GQ6G4qEDQH/qqYoLfrsl+2KBPrSlKs5Dd46T9xwn8XlOZIkXLnLfXQKXtezpqwuvd5Z0Zx49QAI2 ljiiJ0hifknom+yjFZ6eiivQe7GGyyel/1NtdlAUu6kDY3diHtHwdIY2HtkuvdSvmq7I74ysWI1R LkB7Dp6z8J4Gp1SOl7WGaFxykFvqMDfaEW50iVtOcGOfJJY55RvzFLf4SeonaDsOjtIvtIfgOQDv PrBfZXmfP7UmnmnFjd1a4xuJc7YQYWwnAtgJ3R6lDVPI7Slt0rcZGjcmcuOhD/z+18hMAhIDTeXG nkH0MItbey6xzwJu7sWMtVTpgxRLeV5EVDOfvjnQzIR2OnxT4J9EFDDZL09K77xrrJ9OD9E2oWmC RzXFW5rQ1ow+6ff8qpl+WhFFn0RSPejrrf3NFHEam3k0UnpjSNzWQmO39toudM2Jk1qAllqP8tsw GGsE8W8rLBSIpVv6PilpoXxRSh9IPZCVacWKtNZITyK+MDhDfRFgG/870q5o2IXZxVJGM7MOqoVI lM9gWilnsC9yFAmRPIvkKPo7QRejsWJT5DTBvxqrvHjiKJHZVX+PgbtWHaHqCEUnRomGW2LKWPSJ Q2Zn/XyqudKLjDisEEtbDGNFQ9MJ2o5o1YFaFL1RUHmlyPXilmjqnbTNbZf+DkjtBKIZIZZnofHu yV4aowaxUqHslXD0bgtVe9U0VvWMUx6Jb+OR1J2Z90CXnliiF3oLby9FoL/unRU9kdETCUlokQxP MmN44yVST8S6PX1xcQJ0UvbQMlp5vTkl8pzsa0tQebE8x2qZhGZST9RvBbh7dyi2G6afwbYgumul 8XV/9O2LDn0YrxdyXJmxeGcnzq4o+ttyloUTHYbAF4SMQM7C5irLkzuBuHs8MfdY4u0xxNqjiJcl Th/Beg3Tz3ubKc8IStkdo2gfQ/9YfEFi+PfBRI3j66kszy+2a7zegJNA4neJ4yWel7he4nuJ8+sq vfAtAcugWQXWwLMObET+Zo3bG2n87smT8v/3vRzfZ4+3Wc/brPQtbHADW1zDDpexzWes7wVscQ5b nWF9TmGTE9juGOt1BNscxJYHsM9edtQ+bLQXG+9hznuY7372wEHmfpTn4+Ako52B5hxrcAGeS/jL VWRdR+YNxrjFeLdYC9Hl//oGneh4RxEDrUDqnbX9Lt4ofVL35rUHvfYy1n7GOoi+h9H7GGOeYMyT zOcM8/qUsc8zz4uMf5m1v4IO17DBbb/sWPSM8tmjLbpHMgfhDcceYcRoIjMEewRz0rdRe+xjjvso Zfw9ah+37sWBe/CF3dhot9qqBf2B2r9PdQ2klLZmoCntTf30Unqf093RNRN7tSfKicSG4dxowdg1 iLm0QsdAdGyJji2Yb3PWoRn6NUW+K2eP1pthl+boLmvUApsEcvu1wiatdY0+Q95l5naN+d7ARjex w03GFNvf8a2T+FEv1akK/hdNTBPL7dSF+CYe9KDek/ZE/DOZGCeZmycBn+3GbdSFOCWWGKUTt1QH bp723CZt2RNR7I1O7JEY9ksX9k48e6gHeyqRG6YXWVsv9nEy+zIJJNDWg73Wjf6u7LfO0May12LI lzvB34E92g55kdxWYdxsodx0oYwZxo0Yxu0Xjh4R3ISRxGtt0a8dMVt74rEo4raOxGaddE6eH3q5 02bG3azz68z8YplzNLTR0MZR78IejAc96O/uo+2hpbf+K9QWvbBJL3iS4UlSO21S2gTl2wDPGtpX Ao9eSu/8mYKuk8F0dJ2FrnMZfyl2WA6/0Ll8CTzHY+cYtfNsaGfAM4X5Tgb/le38588QTsGhYDj8 I+EfhUxZh3HMcwIyJiHDHTuS5/bYtyNnmti7s67VcF2PRNamF7KS/fKk9PbxQGQP1HV024UuTdHL 3yeldy+NZG7DsO1Q9BjCGIOxj6x9GuMInfCJPwzBhkPVV7qhR1d8QXSK8/lDjL8UeV78MAX/noRP TMAXxuML4/CDscxLfEfoRqsfRtPWkb4o6MRHI5h/OFGW+FSYyqih8gqqL6yB90NkrAIfYKdl0C+B fpH6nfif+GGI8gm/64/SH4E/RrKObVm3dvC2Zx2jkNNB/XGN+lmM+tp6n1/+73nufbJ0C1vcwZ53 sO1dbrTblDex0XXaruqbO4mkE9jfPdjn3TkrurHn49n7XTkvunKmdeE86MyZEceZGcu50YlzIoqz rS2Qt3URGt0e1zd57TTylQj4HDpe8EXd8hZQou2bjCP6/F9n+h30u8tNfBeaW+h2Cx1vK3r7++7o N5SEvjhjx6JTHON3ZvwunG1dObe6ons80Xs3dOiODj04AxM025C3lFeRfQN5t3yyROZtfU6mPUkz DnmLeRm+z+C/iJzzyPsUuWfUJl2Yp4wXx1kv48dwZsb6dZHSi3MOaMQeDsRWUditk/YfUVqpt6et LZCsIMJH7/JI3bu7xBa31SYJ2FAyl3hfptLRl6m018zjE802IrHHf5nGAa1L9tEWfSUjEdoo5tKB OXVibvJWVt7OxmGfzpoNXWPObjbVk/GS1DZeKbq8eNYn206gq+kL+tsE0Nf0swN4HmBSLLsSJNpB JhgE2jQTAGrZwaYqqGSHmHJ2qCllh5kSdrgpBorwXIT2ovS/DW1x+N5BxrugNDLL2v6mkKKfyQ9e pZ7PpprcIBf1XIz/qu1Df2/k9II3CX9LZKwEU932MHVtd9PIxpvm6Btku5hwSzxsY0ysjTbdmEuS 7aBzevGslzn2AsnwJMPTC55eSi+Qtnie47VMtt189f9+Pq0f9X5K18UnK970VnQ1fShTFGLHeLWl Ry+lp0M/bNAfG6Qyx1Tm0s9n937MrR9tfdXuqT46l1bqHn9P7JkEkrFpCuhLn/QLTwq0SSCR554K TlUgpXfXlLAjWKvhrNkw7DnUVGOdZC3bg04+WuENBM2QHwBq0VYVVIKmHPSl4Cuh6z3Cnx++Rftb uu7DWXfxgxHaL3TFQFH6iqpPDFVa731hWfQuw5qXpiwF3kX/d0Bxxi/G2G/5eIqpLw1GXpopSfu7 oDQ05eAtiw9JWY6yrCLVb6+C6mep2iZ9pUFJ7FwCvE1dfPB1aAoqUpVW6t7P2hXS9n7a9rqin7Z5 7yhy2hTQH98dYPIC8ePXQH6fj7+uvH15Fp/uR7/QCvri5/18/H21DFWZ76j/JtoofJlcDd+Mwq/D bSy+3hmf72Ia4i918c/q7APZE2VsT+aTiO2TGbMX4/RWebl0b6WgQx/6emPXZGyQBE9PeBOQ0YN9 1M20wF+DkBmO/CjGiWVfdGPMJMZPBKJPEvqITlL3bNPLt9dcmmjdR718++5/v8Xh+V53dIxBv/Lo UomyKvrURJ86tNdHp8bo1BydAplXG/QKQ69I9IoCnZh3HOiKjj2AyHrxHvI+i4hBfizogezuyI1h HK9NSu++Kq+69NE2ofGey+uZ08df99YlQceORYc4dCHfV3t1UR1DQRv0DUTvZujfmHnUZz51GL8m ulZVu/83RmXGrEq9Jm116asPTWNom8MTCG8bZIQhKxKZUSAa+XGgK+P1AN0ZO0ERqzpJ3XvnIvPu gbwEtZNrK7GD1y6ltza1lKcQt2JfbpC+3CQp3Eq9NLNvy/0RST2COzaCqCySaCySSCqCKCoMhBJJ tQKBtAXqN477kG3Ip2MJIF7fOkRyF7XlzmvPfdSB9i7Il7Fe/B137biX2gLJ2mNUl37Q9VP6OBCL 7GgguuGNyEuEJ0F1dEuvnuj3twh0i0TPtujXVnUfrG8K2iLDHa8nNMno2QcMpj6MciQYQ320j9+V IXXvnXagznsc8x+HHcZqn9CHgVBoWyvG+umk9HSSbzq3xi6t9Sc+kunroz8t0lJtOFb5WlFvpd88 l1jJtaf8JEgQtnT5XRlS92IVedPSARtH6Zsc/Ebt31VphC8MRNDXFhp5MxMF5G2JvMkRXi+GFptz IwFZp97a11Hf0CT536zEKfoQbaSAvr417Q9Pf+UVGS/Gs963IG6ZAcQiAykHERMNIoZLA4OJVQYT t6QRt6URtw0hLhoDRhPjjARDiZGGEBcOJvYZTDmQ+CeV9r76dvoMup1iLifR8wQ4hs7HmO8nzPU0 9U/pv6BvnnsTG6YQz/ZXPf6v8+MW8m+Dm4xxA7ob1L1S+rw77w463VXIHAb6+tPgFQzWeXk0Unp3 0iXql3W+g9HF7RNa4bkJ7w1wDdtcBpeoX6RdeLxz61N85DyQNun7FFudB9J+Dn+TPql7e+uk2k3s NwRbiS2Hg1HQjPbJEv7R8I4EQ2kbDF0aPGlqc4//pP50jDv3T7HlWUVfaPrTP1D7TyvvINpTkdUP ub2V1rvvj+GXR1mbo6yNrNNx1u0TXb8keJPh66X053VdE2nvidwE1lXWtLuuq/C7crr6617Oe1vX IJU4uA/2663rfg4Z4gefKL87vsgT2Z/SL59uXIL+CnO5xlxu+tb+tvrBAJUndc+Xvd9X8j62Hs/f cWSSY8k8x5EBjiOTHA8mmGnkltNonQ5mkmPOArOpzwXz6JsPFkO/GN5FrIBgIasyl1x3Bis0hdNo PKsxGssP5e8gnvvRlwJNCq39oB8A7yAwBDnDwEg4RqteL37HWHQbr/pNUn0n8O/7cI7j71iextA+ Fr2FzvObSegxSfWeAaajr8xrKnxTlM6ln4bcabRNp09oZoBZYCbPs7Q+SX/ayP18SOY8iblOYv6T scNkX79LN5tyDpgL7zywGCzy8bh8E/U38Lo+OFptJvYTOy6Bdon2C884MBZ7ik2lFFrPB4eyzkOx 3xBsN5jaEHqHMoNhzGk4eo9k7NE+/tHoMhL9RqDpcGY6jJZh8A2Hfxi+4smS0js/RrM+I/Gn4UDa hW4E5UgwWn/nj+urE3ye8z6t4+l111DWcwB69/PJ6ct696cubYPAEPqHA6Efo973vq7gOObuypvg X39r6utYb+Lpg4G8eRsBxlIfxw54H0yiPpk2wRR24VR2xFR2xEx2z1ywkPoS+gSLoV/Mzp3HDprF 7pvKWT+RO2Csvq3ryhjd0LMHSGC/yFsdGffFuz4BrRPQMpEyCd5kZpfELJNUt2H6xilBMQz+kapr D2h7oK+U3X11kePdq71V5ynIkjl485G5TQQurcs/UeecQH8SfpsMZM69FVNUhtQ9H+ttlrKKC4HY Yqb2uTaaCa1rn2Rs0wu7CK13H/fw2SqBvp5qu6XwLYV2mdIJfaJiETSLoFnk55HS85FunD3xoDP2 iMM+cWrridh6Gu2zsMV8pe+pcubxPIv2qfRPYG3GAlmXIbQPRNZAvzwpvTmKvRNZK1mzHr4+oe3u W8ME7XdppPS+PTjs+TDjfXswo9/j8ui3B8eb2mhQR7/XNNUEcDLUx2IN2N0N0bKRWUC52DQFzc1y sNq0MBvAVurb9HOO+ma7qcdzgNkC1iNrLdHqOrAJ2fLtyp2079Fvaso3QZvqu/HTRDsX9F13GGd5 e+7VTuYLopavsNzXWOMbrPEts/uW2X3HbL9jRl/ru6oU3zk/SO/iu/jel/je1+yxb/G/7/GdH/Gb n5nRb8zod2b0F+fCP9j7MTN7TP0JeEr7M2DsZIW1kxSOnaB4zto9wzJPkPeY9XmM/EeM84h1esyY jzkxnrBeT9DhKTDkvxakJwfOCDKRK2Yid8hIHJ+BPCE9uYFDjG/IAZ4z16dEdo+JAB8S7f2NDf40 IeYB0eTP2PYH04y5NGFe8jt6GhBn1CTWqsH9V517sBr3bVXu2irYUX6+uhI2rWQO4YkHwQFTwezn BN1rymFz+VnssuZj/dnskqyN/Oxocf050nnUp9M2QX/Ouywzk59trcCJVYnZVQbvURff+L++g90Q T26EXzRCVkNuhAZYtx4yA9iZdVmBOvDKz1nWZiXqqG/NoH8W/jIH2nlgMXxLtGxA2VCxyB89NaPe ULEEWyzheTHlYm1vym5uQil1L9pvia+1VN9crb4qfS6967fN1We3+Oi2auntLPHh5kDahEZo5bt4 9f/Hx+ubj/QzPal7t2Rt9XPx+XXMeT2QPeDSC189nuvRHsCeqGPWsI5rwTp/KfzeaduCOKeZfnP7 iH5zup5+K3unfkO5tu6ldT5e+cb7dv3GcV39RvdB1uAoc3X3lcjx9IvDhzqxR6LYLyHstSB8qBWx m9AIbUv93Omi7sNQ/czpFj55lyziS/bi18rvnZQJ+GQC+7KHb1/G6x79RmmEtjNtXUBX9mo30J29 mAB6Uhfe/04xed95C3yt7dKfRD2JWE7evybqt1JcGql7b9hl/85m/81kL89gv8jvy5/CHp+kvyPq HvfSV3jsFxrHS86SCn9ffQd/Q+WIbHkv319zgLvs2S/w8q/w+m/YAd9xdvygZ8dE8wsee1/Pjml6 djzUc2MWY7s6uHpI3Vu7Kex9OUOmgxns8Rns8Zns8ZmcD7MUj5AjeMwOeYrcZ8A9e6Zo+dy4dWs9 O72v51A6zqR01pVvqBs7kfoEIKVHI6W3DyYg/30wgTHeR670TVR64X/G/J6Ax/5S6L03p8NpG+E7 78ZRHw+kX+jkHBzPHMaCMeZf7PYv9I/0LBQ+L4IdwpiDFc+oP6P/ifYL3RCQhrw0PS+f+yOxYXpm ytlptV36B1MfTLv0eWfCUPMSz5m0bbAik++8lXa3T+reJ0NBrGNb9JSztiO6xCC3M3LjsVkPzuVE eHvBkwJPKhhkMiu/yOwLekOThF4J0HeDr4ue38/IsJ+QxT9izzxg7/yq4/x3JlxmX15lX95gH99h P3/FefUt++2eCcRXhVZ4WuJvzfG9puyfxvhlQ/3dbJeU3ztjK+rZfoTz+Bjn8QnO/FOc/We4Az7l LrigtMJTiz1ck71dQ9tP038SuuP6M/uV9Wf2j/hlVdT/dcTVtQx3g3tP7OPsl7tD7pDDSlNZcQie g+AAbUKzV3/XQDnl26X8nq7u7wsZbd7BY4rj5W9zxru/s2AVbevZK9t84+3S31sg99E7ZiX30BIw j/p0aCZCM8Yvq7T+ngZ3j1XRO0nupqHoMxRd5PcxDIdmlNIJXznq7j0mGAHdcOgFI/z8UnpvRuWO qqIyR2DDiXpf1fHfef/FSt4bu3r6uwTG6HdQAtgR8j2SGsivpXflCO1/8b70zs96yK+vPIKx1OU7 LCOQMxKMwWfG+r5jInRu2YiTxat7e6Am+sqYHp33LGVVdp1X995i1Fe9RL/h+nsNPPoatNdk7Ho6 /kilq69yh2vdm3s7lVOKE3MyXjqVU3U6p+oMvHsWmIPXzgMLqC+kfSE0i/H6xdAvAUs5ZddRbqBt PX3r4V8H3RqwHJ6l3DpLzOdmBVhNZr8efIRX7yDi2YFXfwQ2UV+Ll6+kfSn9C9hds+GbhoxJyJuI 3InIl29CT1Q9Pdt70fl1ou8bquNceGbDMxOeGfBMg34KOk6mnETbZP3e5k3meIP+68zxOnO8xhyv wX+d+Ul5jfK6Yr5/L32hc10C/wIdS/qE5gZxyE1wC5vcVixh3KVgmZYen5TeefgldvgSO32hdEvR bZ2/TUrvvL6p9hS7in03QLdR+++qzd3yNriF/W6r3V16KT2/vK5rsBQ9l4E12ufyrAErqH9AKX1L oFuM7f8rhdfzsyus0+dmM1hP32qwQvuF7goyrtB2mb7LxESXoZPyiv6WX/feukys8znr/TnnxFVf n0u7nbXfQfmR0lxR7NC6Z68L0FxQX9mp7UL7mWK79nnZ5w384yprfoV1vcwaXUK/z/Cri9jnAuMJ 7WeKTfSthWYltEvRSdZ8NvOZrj53U78HPNFvQ/GfL8EX6ofvY7MJ0ExQmpvqU7J3JtE3Sf1TfO0/ nsn+vfbft6OngRlYaTaazGI15qHNPPMheqxWSH0ObbOw6ExWfTq0gmnK6/m/Z9tN0G4GW5G3DZ7t yN4O3VbFTKw8k/5ZfrpN+n8sCW8m6rN97dI/019Ku7f2q/DzNWAD+2sj2KQyZvI8Cz3no+981V3o VrMXVlNK3fPjTeixAayCV9qF9kPmuI4x3PnNgGa6r5xGOVXppe7FSzKf7bRvBi6N0M5Qu2xVTPPT bPfbyPrvrwPoepAxDygWcNvNh24+fAuQsRB5ixhT5jgfufNom0ffXGjm4Glz8LrZ3G6zuR1ncaPO JgubrTJf/PbFQfgPwXuQvgMKqc/1tXt98/13jtSl/4BiHnIF8/2l9HuyD6DfQfQ9qP2CBbTN97Uv 0j6pe2fWRvbxJrCZvq20b9d5uzTCt48xtus8Zc4LdP6b1BYun5Te2OuhW+/vk1IwH54Fvr75Wnr2 3sPcd7O2uyh3go/UN2czlvia60dCL/yb4HXtLfrMhXYuPHOw9xyVswc5Ikvq/t9Lp7adiQ1m+caS tRH6OUQxc5nbHPrn+NZdMFPpD/rXzOI9IquJ6WI3gS2ms91mYu12sMPE2Z0876R9l+kK4u3Hppti L/W9tO2j7wA0h0yMPWqi7XHTyZ4wHe0p08GeNu1ABPUw+4kJscdMkD1iAqFtAU9Tu980hr8hcuoh sy7yazNmTfuRqc74VdClst1sKqJXebuBeGO9KWXXmZJ2DVhrStjV5m27whSxH5g37XJTyC4zr9ml Jq/8bj+7GCwwue18kwfkp/6mXWiK0V6S/rLQVYK+Grx1kNHArkSfVei22gQjPwL5UYwXw7hiF8+/ vX0Yh45xap+P1F5d0TUeus6KzbRvhXc7cGn8P5Fg96jtutvd4GN4xLZi4x1+ecLTWfs+VhvHw9MV xCvfHr8vxmO7eGwoZTfQ3dfv8XTRcp8/Puhgz7AuZ1ifU6zTJ4xznHGOQHcI+QeUVng6IzPOHmT9 D0N3BPpj8J2A/yQ2OU0pa3uWtrMqT+R682uKnBbwtsYXgpEfCo+sf1sfnfC2A5G0hyGzFbQt1Rf2 mWZA+P3/YwBr8A7rXYp1KMM6lLMbTQXsWwlbv4d9q2J38ZM62CkAe9ZnzuJLjdFf5Ii8Jjw3or0B /fXwr7rYuhY8NeCthowqrFVlZFZEdnnGKct4pRlXfOwd9TPBh1oXfbzzqoTSrPPp6PaV0PoGbZe6 dx+7vrgEv1yKfy4zBfHVN/C7t/C7YvhdceQLvStjlc+nl+Ovy/Bp4Vli8iEjt12ksrz7Lq+dx/M8 kxPfzunrE5rc8ttcacsL3HIe5TwtvW8PiK92Zc4xzDkKfSOYQzB6BDJ+U3RqgA510LEaelRCh7Lo UBL5xZD/JjILsKdcuQvYWwuZzyJTVPeW0C6DZzm8K9jPK1gXkbka2R/69tY6xtyAb23E3zbrnolX bFSd4v37zZLTir6lTX9is37EV32Jt1K4Pftwu/bW77GuN4mcokmcnr1Ab+opoC8naj+QSn0oGEbf CDCSE3YkJ+wwTtdhxFdDOZkHc8KmUQ4A/Tlx+9Leh/5enMLJIIkTOxEkEEG437mV7x9vpL7e9CQ6 SeQWT0KnFNVxqer64ntE+R5uEjy9ue37oHcKPH3h6Ufs1Z95pZIn9IOvL6XMsQ/tvZljL+iSdYx1 jOV+l9crRab/22Do0hek0NYb9FKbbPR//1fsk4zuYqMU0Je+for1/r07ivmNgkbsNFztJvbboDRC m0r7EDAMmuFqxy3QbvbzjdLfRe/GdsOwm9h3BHYcSV1sPspHP4JyuK7BdsYQ7NByCLRSl3bvjBvO 83Bdq+2+vp2UH2n7CC3dunfGJeu6fYT9djDHndhW1vVjMwgM5mYcRjlcx/uI8XbStou132kGglTa +ynvdmRsw47b/fKk9PZdd2wh379O9PmH9Lm0W7HzVuy92fd9642+71xv9Of3/ckT+oEU/QRmJbQf QrMWf1qvdAm+9ZX1TtLvtq9Wn3D9f5mfX0rvLBLfSVW/W+KjcX3Ja5fyxW9BeZ8ad+Is7cg52IEz MYp7pz1nZCTnZTjnZQjnahDnZSDtLbiXmnJmNoa2AXu2Hnu0Dnu4FudHdc6tquzryuzxiuz1cuz5 Mpwd5SkrgaqcJzVor01/AGdAA2gbg2acAy3hb42cEPZ9ODLbgijki14vvmPwvhUShn6RnOvtKNuj ZxQ6d0DHjswhGv06wt+BMorn9rS3Yw5tmUtbaCNBOHWR4Z2FZTirSqNnOfSsgI6V0bEKc6qOfjXR rQ66BSCzATo1wgZNkdsCuYHIDWLsEGSGqc0+pr7LtKGvFfZqCV0z9GgMX0PmVQ85dZlvLeTWYP5V Gec97FKRccurzZYDtyzh00nqnp4yt07oEeWzUzjyQtAvCJmByGyOzCagAXIDmEdtZNdAdlXkVAbl WRNvjPK0V9I+oRFa4VnjW5u16L0e/TewNhs5szcxv03YTsbegg6ujUWfWF0rt/7i+yT538mLpYt1 PmWcS+A64z4AD6k/A+mdVSYryOmsNsXAu9SbgRbUwxQfmXDnMDhP/Sblj+Ah9Uw2zMlrQ52iIJT6 QLCM+ic22PkF/GrbOPdta9DKeWDzgFeoZwKO85t9Yu/bv8F9+8B+Ag5TWwFW21/tWvuz3WB/tFvs 93a7/dbutF/b3fZLu8/esYfsLXvU3rCn7GV71n5mz9nz9qI9g4T1YAMSNoEt1LeBfdRPgAv2N3sT ybcob4OvaPva/qH4yv6luIs+X1DeAbfsn4zxJ3L/sgfBNvpWofd8m96Zwxxm2szONJvNmWxzOBOY 11ibyxnFHIfZfM5g+xq2yO/0swWd3pTJPAt62Vcp89GW1+kLbX94Btjc0OZy0sBgm9MZal92hiNz pM2OvMzO+zaDM8VaZ5Z9aufbh3YJ+n6A/h+i6U5mtAfbncMel9Hyqt2LzjuZ3zZstYm5rbPfYc97 djn2XMTs52GRmUiYwowm2H/sGPuvHW4f2zSkp9pnNgUk2+c2wRonHsQxcgvQhHoDUJe+mtBUBZXg KccqlraP7DvIKYZ2hZFZCEvlx3J5GScn4+VA2yyMnQkd0rGmxv5gHxrsb27Zr8w5e8t8Yq+Yg/aC 2UVUu5lodTWR8GKixtns4kns3lF4+yB2QR92RHd2RlcQx06JYcd0BO3ZPW0pw2kL0QhnDeVadso6 +tdDu5HIfJNJRE4fTo5UMAi5aWAop8RIToyxnBwTGXMaEessxp9H5LyIyHgZ+IAofQWR8gr0W20/ NevsebPRXjRb7WXzkf0cva+bvfamOWDvmMP2C3Pcfm1O2m/NGfsD8/vRXGSuV+0f7Ly/zE3mfts+ Zf6G9UmHb2fExzNjk2zY5mVslMv+YvNhr/zYrRBeWhgbFsGWb2PTEqzbu9i3NHYuCypg8/dANexf G9RlLRqBpqxpBGjP+sSCLtQTQS/6+oJUaAfBNxQZI5A5FvkTGGcqY85k/LnoshCdluE/K9FzDf60 gX2xBY/7yF6zu+wVfO0zfE5874w9bk+yCw+wD/fiibvt53jhdXbuLbsVrk1wr1cp4o0/sMt/RPKv +PLvjPIXoz3DI40z0aZzxuHvo+1LzgibxRnC/hrEXujPvkhhnySzbxJAEnsoSfdSfkWSLQAKOYmg G3sunrZ49ltX9lRXeOPZUz2Q05M9lWyzOn3YV30ZI9VmZO9lYN+lY985jPmMHfHEjsfCU7C2WKYP 9TjQEEvVxGIVsdy7WLAIdPmhz8nueAl+g6x/zEvOb5yl35sczl3zinPV5ObMzOOcMXmdE+ZV54h5 zTlg8ju7TQFnhynobDGFnA3U19G+kf4tJp+zHdqd8OwG+00u5xDn8hFknUTmOZPduYz86yYz8jM5 35oMnMXpnPvGMvYzPOqJfQndcqJnAXQvyqqWwoMqsaqVsHdFPK0i9i/PiVCGNShlf2Ln/myLs+JF 6X8LvIEXvKY79y927T82PfN9ap7Yv5F/3xjnHuN9zbi3GP8KepxHn5PodcS87OxF14/AFnTdaLIx t6wgo7Pe3GUX3mA3HgAfszO3g63U14DV1JeARdQXQDefnT6P3TqX3TqHHTqLGGMG+e9U8tXJ7LoJ 9poZb++aMfY7du6vZji7aoh9wm5ObwfarJZTFR8vwMoVwd9LgrK2N3Puw9xT2DGpYCD12WAudlkE ltjKeGRl/L+yncRzD9CNndXNVuEsrMaZWA3+6nYxWEb9PPiM+i1wm/rX4BtOxXvgJ+q/gF/puw8e UH8A92/41m+M+pNdwD5Ywr5YzWm93u5n73zMTfYRd9Rmds869teH9KxC+gdIX8a9tJgdtJBR5jHK bLhnsorTGG0y0iawguMZUaSPZMRhjDaEMo3nBMXPNon+3mg0EAymPgyMoH00/OPwhAkqS2R+b2cg fzbjzGW8hYy7GB2Wos9S9vEStFuE3nPQajZP05nLVCgnotEEnsYiZTS14dSGURuCRmnUJoLJtC4G S6mvoHWF7c78OlGGcz+F0R5KfyhjhjDPEMYIZReGsh5hSAxjjqFIDUVqCFJDkBLKOodi2RDWNYgy kLVuwVybMucmrF0jzr0GnH/1QTV2cSXbGV/owv6N5zTtzsnagxO2p83D+maHP6PtZ5+ZAfYfbof7 +NQP+NYX3D7XuR0+w+dOc0McNVPwx+nElbPw0zncPPOIoeYTTy0Ei6gvBctoX075EdhJ+3FwkrrE YC/G097/yFbeWUnstZIYTGIxickkNpMYzY3XfiJuvA4uUf9UsYr6KtpW0r+SeG4VtKvgWQ3vamR8 iKwPkbka2atVvvcOPVzjOonxJNZbqX1C0wy0gCcMhFIPV6xSWql7+WA4cWAEe9+NC1crbSh7P4zn MNpDNU68+V+u4LQmNixqw4kXw4kbI4gfIzSOvKm0YdTDaAulLxSaEGhD4Al1WlnhDVf+1tb7nCBM 480wbROaECcISFuo/39ADSEGDSMWDScmDdfYNFRpQqmH0hZCXxtohM7L31s5vxOv/m6DiFXbgBDi VOlvo/iV9t/o/80GakwrcOml9GQ4GuNKrCsx7++2KCjh/GHrgoY+WuHNA15BVibgIFv4vHdVH2gs /IDbVOLi33n6nTvoAef7A6UT+ifs7b+BRNBnwSfUVygeWOFfCo9X977xeQmqC9zX5/h7nHjxCLf0 Qe70fezx3RpRfkXs+A3n0Pfc9/eIw3/iHPrFevqsRv46njdqbP4DN/x38HxDFPoV59hdYvPbxAM3 GeUa8fkVzsiznGinrIzr+c7vnHn3kSJt0uc+r9fyd2IE6ZO656u/o9HvxBEPNKbfRH2Dn+c+9d9o +42++0rn0krpvSO+jz4PmPUD8oDfman03Vfsg+8EuMCpKLnBDSu0np6SL0iucN/X94uWt7X8hbP5 V80jblrvc8EHmlN8CW77co3bQNq+sdLn+eWfmmt8yR37peYeD3w0f4A/OXP/An/TJnSeLn9j2z8V X2mf+/yFr7ylfVL36P+i7x9f25+a03zJs1d+7at/4dfpD9brD813RNYd6/IL7iDjFs83gNBcs967 pb+JDP/CO/7Eln/iRX/gV9L/l+IMfAfBNmSsAqutS+/ySN37SdgCxGMFyIleI196lXwoL/FYbvKo nORAL5NXZScHyupMIl6bSow1g1hrNjHXPGKc5SpHZD/CQ59yJz3nBsngzGVPzSJ+/C8/y0lcmZt8 Ki+51avElfk5AwowXiHGLsTYXim6eDYsQL4mOVsBf5+bxxXQmDPRV+/lt2E+7Zd8r5d1eZM1RhUZ +TR2lfzPrXvvjF7TfNClec0X176msW1PXz3Zf67kJl6VXDEvZT7i11fVZslKl5d6Hs0p+zHXAcS9 qZSpWhc+751ZDmzwCnFuTuybGzvkJu/Mg8zcPtqc2P5lYuEc2Ckb9hf6aspbwBxjt0qUf4tTSU6K b1nbZ+SkDrbOyNpkYZ2EXvgyO+PJkyWmn8k5NY81Wqx5669ENvfYtzc4Ma6QL1zgtDiLVMlhj3Ai yBieX6QhfTjcY1jdCaz2VFZ7Fp42jx28mB22nF24mnNoHWfVZvbOdnx7F/66j713CB8UWSLzANnI Hs45Ny/+grPrK861b/FCyW9+Ip6RfOc+EczvGvW/zzhjGG8Y4w5i/DTFM+v9H2eGGaSDLyN8WdAj O7w54c0L72t4dyFmWxj+YkTOJZBRmryrHN5ZyZc318RL62o+LXm15NcOebZDlmLJbiwrash2nms+ nqZ4Qv2pLzd/RmzznPjlOfGMgdcg4zlRjsgU2U8Z4ylR7BMi3seM/S8RvujyD9H93/Z19MvPSuRF 35zonYMVyco8MjGf9MxLcnOZn/dbSNaQb68nZ96s+fIou5N8fC95+UEi9mNE7qfI18+T/14mf79J Hv+lOU/U9DnR022iqK9Vlsj8l3z3AbnvLXOCfJl1Jyo6YzaRW6+2h8n19xNN7Ub2R4yxlbE2mt5k A5Lrd/ffiavJ6YlCiHTaUkrOL7l/DDl/Z987ge7Ks9b3fmCNiaavIwinHqrvBLxSZHn73P20JVDb pM99bqXlSv3UJFDr3mcI24kQt5tU9BS7JJKpdCMSjMNOHRg/8gUZIjMSnTrSFwddN+aWCF8K/KnW kyWlt0e3E3luN8OwxRAg7ygGaf9WHXOQ3UbbNvq30S+l0Hs2+oTI8xhR6GGi0oNmJnadynpNwLZj WbuRSis8O7DzLjOO9on0T1P7HySKPcJaHCdyPY4ckeXdoaf0HcgH2nZcsYK1W2lPAnk3Iv0n4RMa qXs/2XcfX3gAfiXy+MlctPeIWr8zp+036ivHyOIO4xP77Q2zx17FJy6TGX5mtuAfG+ynZi0+stqe 8r1/OWU+tGfNOnsOv7lA9njJ7LBXyCavmb3wH7S3zRHkHbdf6buXs/Z7fPE3cxVcs6KHp1Nh/L4Q +zY/vp8P389NHvQK/p8dX82Cr2YipknPeWK5J5+ZL+1jstd/8ee/8d8/fLJE5u9ktH+ZW/j5HfvI fOF7p/MNZ8N3nA0/2MzIy4bclxkjF2PlZczXdOwH9k32n+hRR3WS34Yv723k/Y28x3Hf6VTS9zvy nkfe9/xN1vIX58mfZC5/kK27/CKnCG3FtO9vst1/oH0Iz0N4/0XOv2Q+j5D5CNmPGeMx2dETK+N5 v31lBPxD4R0Ebyp8KfD0Aon6HumR0keA9pwrsaAL9UTQC1l9QSo0adAPhXckckSe97vNj9jT3BYX OZcvcz5f5ZyWjPe2vr1cwTm8lHN4Ief3XGw1g3WYgp0mMK8xzEvkiLyxlBN5nqpn9C+c/3Jm3+Ps /p7b/xsixq+IAu8SAd4ih75OLv05d8Al7oDz+m5KdPA+l/pRuT7Q0/82N8FNuK5xK1yxO+D4GOpD RKRHlUd4T/Akt9NpbpPPkCrvtq5yk9xgJHm3dQ8NfuImErnevZWPUzwPyMVJ/gqxg7y/ysodm5n7 NhP3anruSId45DkzfUpW/Ii8+QF59C/caj/qjbQcT1mCNWdj5Rmc6lO5FeTd2Hju2TH6biwrd3R2 ZxB3daq+G8ujcUBPHVfGf83p4q978UkBYpb8CokvJNZItJ6ueTSGSLYFNaZJ9O/7Qk532uSdWk9t l/7XKV+nrRA3lpSvUxZSdLdevpeL9pwgN8hDXz59H9cNGd2UTugLOl3Rpavqmgu8Qv0V2r1SZHh+ 9Bee8Td2eGrHY4+x2GO0vq9LTxyTkZglE7bIjC2yEANlU5snY5tE5PRQOSIvB+NmZx7Z6MtCvCTv ADOxNvIOMD1xkLwDfI7HPcX7/mJd/tG35IJpOrbUPVv+ZUN5jsMz+7AbR2ifSz8C2j7U44DQhPrn kIu8+GXnqsnu3DVZnO8NeZ/J4PxDvmi4xV/Sd4mPOZX+5aZ+yG7/x1ZEVk1kNFQ5/yga0ue+h3wE zWN2/1N4nsPrICM9sjKRR2d27ptsvveQOZ1rJo9zAZxXHbzfhFjI2WgK6vvHLSa/s4NYdLd51dmP /x6G9gTx5mmlF768zhnaT0BzBNoD8OyGdwcytprXkfG6s17LN7Rcr7K9GLcgzwV8bdJX0FnL89r/ Kdf/9x0N5OdyjjL2IX3/mdfZw7g70Ws7Y4ueG33y1vK8gb7N0GyHdic8/4+v846vqnj+/u5VsVCU IhB6JyFASAgtgEjvvdgriIJ+URRReu+IiNJ7kd57lV5CJ9TQQXpLqCpFnvfMOXvDC388f3zYubsz szOzs7tz7iX3rgCr8XeteU31bAh+3vs88UgWuGJeCpwn9qeIzVFic4D12A3/NuV9Td/DlPcydzO+ H754+E8hdw55731W0ePil0iVdZNT+o6ezrn1PdcHrMMjTv7H3AQB1kH4Rc6wzo/oe2BfYn1Ts46Z kJNTPFzfm73Jenr6PJ1Cu+esC/q+rbx/K+/jRvt8UZwXUZyYkZxBkdw2wiNtUSv852kv+rSLwXWb DZkcyOTmjMnLWROKbDgyheCNUF6Rv0zleIUb5Cpj1+C5bvMxd27mzglER7bgXfpaYDFxXEW81hOv bcRrN/E6iN/Hyeuz5jE3/iNuzAfcnn9zQ97jdrzDLetVnxlUl+i85b/nfI9q9G9u3/vwPuJmfWzl ve0r+p5zMnS+FDjEPHuYL5Z5Zc1WsXaL1Q73nJRc33uewzrOhWcuY/N1XPjSkitpyNk05E1qxl5V vlnIzFI5938wFun71PJ+9SyzGxyw8j72bOUR3mSBmdwlM815KruN4A+qvIVgUbCdGfy/EMOp4oZT eY2w86mw5lKdzaJ6lve95f3vWVQys5Rf5BagazqYCj0WjIYewdzDkRuG/FD0OH3SujunNTd/a86D 7zgPvie3eFLkPk9uOxLLzvYhd/xdKr4bVIEXTT+qpAFUTYPsPiq/7VSJG9G7SvWJ/l/tSvMLleAg Kq6BVFr94O2DTE8qt272OtXjXdMRne1Zyx+Z43uqm++YszX58bXaERasZb8lJ+U992/Jr9b6PnyY 8nwdfD8+SttvyTuPjgyesR30ffpI5ijCWBHr6YridRS+FaXmiAJFrPC5HJ9AxTNB38+X9/WjqBei OL0jlUf4O9E/FAxnD40B45Tfk5F25hO0s6OlfiYgnw0k8f4MBqKvBWgZbKODz/Ut4Gthi1tppb+F 8hTluU0+Uyih/e7vQr7k9Vd+n4x9aUtZ6XO5eFA/a5DPHEpQJZSww6Dbge+V1+P/GnxrY6irYvCh FDVLKaqXGOoaQUnr3mNO8D+TSNDPKLzPKy5h5wUgn1+cAMcZO6iIgY6hrxSVcCnGS8JfknOhFLKl OBNiOIdi0BWDztI+XeqJ9/lK0l9S+2Tsls5d0t5SFA/SLmZe1Sf36UeglnXyifTdYEzGk3iH6esb ikHY8wvtUOv1e23wG/uoCefjzWLq0BV2l11DTbfBbqa2W09dJ+8WzLInidxZ6sKLVKQie0M/ZZFP XSbi/1QkFyK5DKm1SG1Caqt+ZrPI7rVzqRxnUBXKPO5b7DpjfRfQHc/F8r5oHICVgzhRB3O6yuc3 w5hthNa/58jDs+SV1MTyqdAJatpjqk/0/g49ST+DOYlFp8mBs+SvfA50nurwIvouUa3IZzjyWc51 25O5uhH1zvpZUKJ1tkgb/Et0xlsy9j/wDTZ+R9sedIT2+BPZKwnsmRvk1w3yU/g9GWndGn/FnC3x Sfq+UlyD/7r1+r0xod9U/mycMWftb2TTEGz/mQgPxP7+2N+HzOqJD93g7YJMR/286rpt5ct/qfQN +hLI/QTGb8B3g/jK517XkJfPwa4Qh8saD4mLxGeEfo6V9N7rONZuHHEdQzxHE0sZE54xtPKJ3AQq +wnKsykoM4JVGc2qjGVnjdPPwDYpzwTo8f7nYSPJE+Fz35wkn3m1t12xszvx7AXVB9/6Qf0ENZh/ h5ELI/RzNJET+aHM8BszDYIaiAf94evHq276WVoP9HRDXxfWpKt+ptbOn0Nod/eNg5bP1/qB3kh0 Ah18mQHgJ3SMBeOhJ+hncV4rcm5NJ8E9Cc3SJ2OTmXWKfl4nrUcLj3tGmMTT4ST9DO8jIJ/pfavj UxRNkGscbIXXxainfp4nn+vJ53tN8LkJ3jYmvxsTBfksUD4TbIwNTVRO5CfSP8E21M8IR9kGxK4B MWyIbEN0NMLvhsS3IXFuQD41CLYyl3s2ac34t/rZYWPuycbEsQmWNsbbxqxWI+UVGfmMsY1+ttgA NLStFY1UVmh3v3+iny9WtM2ozb+wVcj5auyr6pzJteCrDX895f9O9dWjrc3rGv7nlFWIWCWeqSvw xFAeVLBOn7RJ/189M7pz2ObUbc24P5tyl37KffIJ5+MnKisoyVhRdEVwzxSA3/uM80ubxYq8O5uG 2Snc81O452dz/y8yP+k7RBu547ebXtQE3W08d/xp7vhL3PEJ5gdqtzb2X+L2AjanQF861Sd6/wf9 jU2JT8lsW3jaUbN1oGbrjGw3e4Y1PoreOGqIHdQSG83PdrUZonXGHM6C34O2SOtyeKJ+jiqfp06i XpoE32QdH+5/1joajIEeDybYqfDLZ61TVc7Fa5f/mesG5FcC+Qx2omKqmQKmIrMYLEXXZrANepdi qt9ODn6jxdonfg/rxeD/qjuu32hxjepvrtkCttl55gg4SpV2FpyDvgAuQT9HBfoCVedL4JXAQqrT hVSRi2gXg+XQK+lfzVPbH2A9fBt5OtxMlbkNue1U07Ho2EolvIWKeDOV8SYq6o3mNrgFnUhfgt1C hb/VXKNqu8pKXrE7zWW7B+yD3k//QcYPw3cE/njkjpo79hhPssepyk+i+yhPKcfRf9L8y+o/sn+C C+YhK/nAXjX3qfz+sdeo4q+Yv6jq79J/h2ryFjw3QYI9zzzn8fcC/l8D9/D/Pq8fYMMDbHqIDQ/N DSr7RHCLvrvgNk9Ft8ieRCrJGzwBXLPpOcezcIbn5H7Ix9mcn3M8lDYMFODuCAcFoQtxO0fYU+A4 VeABEAe9E2xnd8wDs6Gngd8ZmwwmQo8DYxgbDoaiYyDoj76+YCqYjv6ZYDZzzWHueTaPXYAtC21W bvtMVBHpQVq7xL7K61fpT8V4KvhSIpcS+RTMkYITKjlnb3JOlRc5QwOcuf+ys+6zI+6yy26yK66z Ky6z866CBOib4C70X+zIv800MNP+Q5b+Y5YhtxKsgd4CtkLvBLuIXxw4iNwRqvtjrMcJ1u4U63uW XXeOXXeB/LhANX/eruP1H/SvMWfY8afBSSr9YyDerkB+uTlsl6JrmdkLdvN6J9gOvQ1sZWwz2GiX mLVgDbt4HpgDPQVMhp4EJsAzHrnR7PTRdq0ZZdeDjezkTWALO3gb2M5u3sGu3sXu32N+w9Zf7QGe Og6BI5xKR8FJnkBOgzOcHH+Cc8TmAk8uF2kFl4jXJfrPcKocRW4/ekTnJvSvYe4l3IZzeYqbS+zm 8YQ2T/fqs76n+CzjJ8FxeDYq5uHvfJ785ptDdgHjC5THVaDn4PkTSJ+MnYPvT933Xr+07sZ5Rff+ fPaznAVyJsjZMNfnnQ89n74FjC1gvy+EdyHnwCLkFgVb0eFsTaFnyALte0XPkUWcIQu0P5W2Hu0q mJScMXLOpAwsBYuV3zuDPPnkgSVgmfK5dzeeD+zA3u2cQ/JUvwU7NsG7Hr61YDXyK5Vf5F4JrGDc O79eCqxDZiOym/FlG3q2Q8eqvhcCO1Wn0C42f+lZtomzZjPnzhbOoK0mgNxzvkwyPfu2cD5t5mza BM9G+DcgJ1jvt5uCf/Fwjdy6Rh5c5xxM4Dy8ic7b6L4Dz1+KDbzewPmzkXNoE+fRZs6mbZxd21XW 3ULXyKer4Iqen3ugd+m48F3mbL1E3yUdO8DrA0F+ad27WffsCeY7wXzx2HEEew4z3yFs8/hF7qq+ lv547DmKXXImn0TulLb3aIUWXW79A5zVNhDv6z/ln93x2v9c4IiOCe3W8j5nwwPOm4ecNY/YM/+y j/5lTz1m75iAyB9XftHxmPvgX+Z9xN57CM9DzvQHyNzn3P8HHaLH05cYpJ2/N/QeuIAfci9cxO9L +HAZO69wb1zV+8PZcl9fS/8lxi+yPhfgP0+czqPjnOpy7yKcg+88uIiuK/R785wjduf8O+c8e+gi fJfYT5eV3+3TPzkbz9rb+v+N/2ReGROeM9hyhjtKxpPsl/vJu68ucs6e5ww+5/MI71l9/Q9zyfgD 5n3I/I9Yy0fI/cs6/hvUIa3L8Xt6193Hv/t6790Eicr3UGUSwU29Ex8RB+9evAOvyP1Fe9ennZ0X uZcucydd456U/yucoP/POjlPzcnsHe7Te778LeibVG0J+hmvfMaVHrnM3K05uFPzcb/mtaLL5dU5 +uSulT4ZO6f3b6i2Z+lztNtr57hDz3Fnnue+PM99eYHxC8rnyZ2l7yz365/weXd2YcYLqYzQbq/t 0btb7vBI7vJI7vQiyBVRHpE7Q3sKHOfuPgDioPcoigTf+fkduWm8ng3maQ0gtUAR5RHeXWA7c28G G9C5EiyDngdmMzYN/K61QtK7SX21LpA6QeoFqRukfpA6QuqJSOUVmclgIjzjwBj0DQdD/ZqiL7S0 bu1mEZNZ1DIzaaeB34ndRDD+Cf7+6BkLxkNPBdPpnwlmwzdHaxOvFV3uKWQx67tYa5K0ID11SSbq kqx2Pms9lxpmNusyS2uacHwOpd+raxbZbMhlop5JD9LapeiQ2sa1otf9T6zpWuekQlbqHpnrNR33 +FLRlxKdKeFJgb0psDu5FRm3zp20JpLaSGqklPiWUseFbwQYZl9h/BVqpuS2k757mUL5hXZnmdz7 fdm/vdnLUkf1YG92Y092ZQ91oc7qzB7opHWXV3t1o687Yz3YD73g7Y1MX2T7cw70A14dcVF1Cu1y +yfqsAHs+f5akyVCXwdXfX6RTUBGdN2jBrkP//1gK7IuZuu0jpN67i/tl/HB2DsFTINeABazX1eC NdDrFH8Hz76dWuv9Y2K17vtbx4RnC9iKzE6wQ1uPT1q3n2Vslz/m8Tzk9UO/feTTD4Jz7dN6UurK +77sQ+pAwQNqQsFDsx/E+e2+J86k89ylf3LvnqGWO8lddpx76Sjn9GHidsDeUV6ROUQ847kDjhPz k9wxp7VW3Y/8Ts61zWCT6nK1y1lq1j+pI89x15/XOnaT8lyEvkBNe17HVyuf+0T7MPXqIXCYujZe a1ypdVdRF6/GvtW+TmmlDl7J2Ap4VmDvcviXUwsvRXZJsBV97t2ObVoTS228grisICbLqZmXK4/w HkRmG4jVdnnwE6iZvJ4B5oB5Wj9LHb2UJ9SlZhOyW7TOXq5yWxnbDDZST68Fa3hKnwVmQIset14T kZnE60laf0sdvtSfZzHn4WL6FsGziJp8MTX5UuV3cR1D7MYQA+kbrzX7Mur01WAdWOuPe62L63Bq oBGs00hqoJHUTKOorUaxZqOppUazPmN82ZH6/082gi3IbAOx1OU7qPV3gl3BVvS5fTKEOug36qGh 5M8waqvhyreLvj08G+xj/AD75iA4FGxFxq3LL+TbL9RPQ6izhiiPIJ5ng+PgJPQJn+ektu5/8wzw nyl+oob4iXpiEDXPz/pMcRqZU8orsoOQ+wn6J/oH2rPI/AnkmeS8/zxynjPhgtKi09Ufcl4M8PuT 6Evouxyk3Zr0VZ7LT/Bd0LPJO/Mucn7d0HGh3bkvzzhjwSjWf7j+zdQm4rUDm+OY4yh6zvh6L2H7 GX22GsJ+GwrPcH0mW8O6yfrPQ5dgjuoTvS62f/jPUUsZmwDG6fg8+uZxbs1nXLDAb+cGv81FnqP+ UMzX56mNyG7wn6+857Ck3xd3/4u2o1lgOpiFpi34Hvp7M9+0Bx2gZezp5zdnYxvG2qjMIngXwbtQ +dv6OtrquMcjrbuTOqpe0S/zzDM/gLb6l9nzla+db4+bvxP9HRULgrZ/pbqizVSzFKwyv5t1ZorZ bCaZ7WaC/prvfv0Oo1HmmBlpjpvh+l1W8p1WB82vhvw2G/X7Q4aYteZn8BPyA8wG05f+3maT6am/ RrzZdDNbTBez1f/W7Vjs3W5+BD+YHfi4HcRCb6N/C+Pyq+obkduA/HrTB739mGOgWcMcq5lrlX5P yXCzHJuWmTGG52XDuQGmQosvLsbujB+t3ysl39+030zE7snM+Tt2TUX/NPRNQ+Z3xSr8X8f4Zvhi 4ZdfbN/PHIeZ65h+P5bocvfUCHOC2JzQPhkbAY/ESvpHmpM6JrTbU/K9WsP8ceEbrt+bFf9EeyzI O1THj2n/MP1OrqPaN0zX4ZjSjncI8Rqi63HQlxNe+f6mPWCjjjte9x0uQ3TtNvrfv/OH367RcVf/ yy9J9wR9iEc/1mUA/D8Rs8HEaAj4zf/+mJ/BT9D9GevLuvWGryf83RVbgmdWG11r+bb7nay/fLP6 Dv2W9c7Eugvr301/iXqLynVlzs7QnejrwFg7eCRP2sLfRrFDdQnt9mAb+LxvcPe+xf175ZO+WG3d X0KPZ5+NA6PJmRH6HTnL9LtxfjErzSByYCB5JjnXB/TEz276y9obNDfbYdcP2CX6vtc8lnyW3N6M D+LvRtML3j7I9dc9IfFZQ7xW63fsDGeeUeTuGOYdz/xjgWfPQrVp/BPfXiB5OU1z2+v3eJfwWrBM c3aan+9PnknBvwphvloK+QVE+fW+NaYG9lQH8it7lZCtjJ6qoDp0bVAH20TuWb8nUFt/VXGl/jJg HXyp7f/Kote3KliHVmGOqjqX/JLfWv31QBn3ZOQXBlcD+aU/+UXG1do6GWldDCpjU0Xsq6K61ujr SryWtrx+g6xHu/u4rv5i4TL9Nfjq+qvxS5+QWc7r5fQvIybLsGO5/wuHK4Pvmj8uVy74rvlL//nO sYlYPpGVncAqjycLxrL6Y/Q31ffoN6WNBCMMFQIZMYKsGYnHo8FYlVvxzO8JHmUO6G+ijzF79bfU x6F3AvonMs8k5puE7ATFWubdyLg3t/cb7HuYJ452n6/H0yV00kklth3QPuEbqbxx2j+CPhkT2vk5 koiM0G+AWs/u2Eq7S8dFZqTSnn/eN4Ct9vk9GaFd9ThJ/V6Ovcs1BmPAaMZHKlbzejX9Ep+V+LVS fZzo+zpJsVzlhQ5+U3eXpG/qfjm4Qu7MWkBtvIDaYD618nxqurnUdHPATGqGSWAC9d14xR/Qq6k1 V5qpYDo18VwwD1p0PL1S7hOaWeiYDeagYw61/Dx0zwcLqCEXoHMhc4v8fMUa5t2IzIagnLRJn3qK HZ5dk6lHZ4JZyrOBWpiVBxOhxwOx2/FL6+qHydg8CUxgvnHML2MTFH8gK/6tCvJI6/aJZ6P4vJx5 l6v/kxXch2AGcZgD5infavUnKS5JcXc1/Sbm20QMNmLrOvxYip1Licsy1mANeteC9ejbADahT/if jrGLyzrq7/VgAzo24ctm9GyGf6NiHf0bGN+o86yDx/FL6zJ+ic6/WfvWKb0JWzZp/xK1b7PSLm/W EIPV2LgKrMTP5di4jPVbiv1LmHOJL78MW5bzegW2rMEXT86TFdr5IPZuRn4TujYwtg78wfgaxUri sZK+Vdgt46vxa7X6tzkYl//m9iHmP4g/B+xWnmW38Wy6lee4rTzPbeG5bjPPyoJN0BvBep6D14G1 8KxGZjXyf6iOp+PunpO2q7zo2oLOrWaPzrGNuWKR34bsVp4VxYZNvN6CXuHbDP8mf97NqmM7/aJH aFeD7cXPPdiwi5jswo6d2LYDG3ewltuR3a56PF27sH8X/bvh2Y39e+DfC/Yhvxd50eWePcSew+qX +LhKx4RnPzhA/0HFJuV7Oq5uL5xl7KTdbU6AozxfHAZHeFY8gt/x+HwUu47BcxybTmDTCWw6+3/E 0dVYJ3n2OwWE5zQQvSd5JnT90ro8OaTz7WSenej3xoT3hGIn826HR2zZqbz77F7lF9q9t3QSH0+A 49h2jJgeJX7x2HxE12sb2K78ouMIbTx+HaX/GGt0XO0Tv9ajZ6365ulbozqFdntc/DmL7jPwn2Yu j2+typ7Sfs9fx3f2/4i5qyO2Mv8m7NqELZuxYyu829ArrYw96/Oujdi/GWxFbgv+iY7NQPo3ETMZ E9rdZLGqcz28Gxnfwtg2X4fIiQ5v7ljGt8Ibq/m4VmWEdueszLcN2W3Ku0F5tyKzhThvoV9scTzS Pu130v2xjfM2lnY7kL8L2aV/GzKV597xYKzdx3PtPjOadR7N2BhsHQf/BP9vVWb9H7Fxe2E2vLPg mwnPDG3l9Q7a7To2R+eMVdqdKVN5pp4GZjCnfD/ILMVO5RE50TFD/6ZlN3fEHngFe5HbZ34HUxX7 g/k8irFRar/4Ij7t13HhGw/GMT5GfdujreOX1lUNszQ+7u92tqGHSgdbRmHHKF9+DPRYjc12jY3z 2/Nvq8rP+j/WwZ11JrALxJl/7QFw0Dyyh8x98Df0HXCL/kSQgA83mC8BexOIyy103gZ3mOs+eAD9 CBtE37Puswf2sHkILPNZ+B5bwT7m9eZ/BB4y5wPgtR6/tE7HdWy4QRzFplvw3FZbD5l/fD6Ruw/+ 1nGxPQ5796qc03GHmNzC5pvYnKifM+5A506wR/mEPxE6Eftu45PnZ6zKufwV+21gJ/7uwPbtzCtx 2Mq8W8099pLwisw/4AHjj8kb8dfJ2WCc/rs31mDLWsUu7so9+vd2q4nTIv3OGvnbqd3UV7vATvp2 gO1mMfOsBmugRf5Z54boXIvMH2CN6t+ltPSv1zk92vGvJn5rmXctdqxTWY9f5NbQt1ptiwveIfPp m6827tO/BVut2Au9F3v30L9HfRC+eT6v0E5+GXFcAsSfRWABcy1grvn4PN+XXQS9CFuX4Osyxbak 3/dV23YCiYMXk9WML1Nsp2aJpWbZTp9gp8bAtSL7rJojjjn3Mf8+/NpL/u0ht3bh2y7o7SAWegvY in1b4d2Gzljm2Al2oXcPEB1Pr4vzezf6ROc+dMUxR5zOtYu59oA4xvbrvB7fQeUV2q3TbsZ2+eMe 3z7mjtN2V5BOerLZTN8WtVvsF18O6LjwbQexjG9VHvEnTvk3MS4yQru9FEs8xc+t+Ct+b8HezSrr xWIbr2PxYzv+x2pMPH5p3TknvsYxtldjJTGL9fl2Uhft5PUO+nfis0BisovY7Nb4iOx+6Diffnr9 nJ3HsfsYPh7jrDhqj3D3H6UGOEpNEA+OUBccpk4SHKJOOsDrOPr3qtyz3rM8ao+hTz4rOQQOcv/L HHH0HwCHmMObJx4e4XX7ez/zHNQ5BWKD2HJMeYT3iELGDvn2HFGZ/fQ72vl1GJ8PgYPE/ADz7scO p/8gsofoO4xNR/DlEDyOX1qXO2L3CfV3j/Ic1zjFaf9JbT366di6/wm6Ffu3YdsexXH9TrDd9gTr dooaQ3CS2l7+vvM49FEQTy4dBoc4Uw5xphwG8nfFB9mH8l1iBziLBHHwHgAHyanD4IjO9ax7f6/O fwRbhC9eefeA3dB7FUd0XGjn+x7s2otd0rdbcVxlvH5vTOhUyv+C0jK+i/5dSp8I1nKx9jQ+n0bH Ke2X8R3QsYrTwbzZoDE5rX0yto34bFWcYv+cxM9TxOakH7dTwWeH9cRgHdgINuDHBuxYT86s9/92 dqPKHEf2KIjXmEmMNxC/dRrXQ8FWdDl71hDjNboOR7R/rdIHWQ+vX8ZXKn1QaZd7G1gfWaN15MY6 HXd6DtJ/kPEDPs9+bdexT4VfaLcXZJ0kd7Ywr/xt+WawCdlNT8iu1xw4pH5vwbetimN+G/+fvEz6 zO4U9dop6rQz1F1nqNPOmolgCnGfqv0nGD8GXzw10mFwkJppPzhC31FwnPETqudZNc1E+ye6BGfR dxb+0/Cfpj1JnShznGLeM9RwZ8xkIPyTgLTuOWmi3z/Z5/PGz1DPnVF7hXafF83BvlmKg8xzmHni mfs4c5xE/pTyivzv6vMpbDipfszCH/FrNnGcQzxngTnq617VJ3RS3E7TdwocYzyesSPgkJnLnN78 BzReM+mfgV6J4XSN5Sn128lL+/S3Wb6pc2Qzv5pL5jdzBVwzQ80NkGh+gR5MX29z2vTQX2s7pr8i 297Emx/MEdPGHDatFYf0lz3l10A7g27Q3enrxVgf+Poh098c93+j4xR6/zRDzAWd8+l1dPfhb8w/ TCG2iE1i20XkLiF3BVzj9Q3lG2oS/PaWygjtvnHhG+xorbYeweZ4/QVZ+QXYztjTzZxUv34x19Gb 8IQueX1Vff+ZOQdgb19zBl9OmZ7IdEe2C3o6oa+96j2M/kN+HA7rnF/TL/MK7c7DNvoLqPILufKr qQd17Fv9FVX5xVz5ZVTBAeWrpDI51OdfzXmN2WBsGOT/lks/5pbY9kK2B3LdNPb78W8/9sSpDtHV Tn8F9yBjB01XeLszX0/keiPf118X+d0L+S2LQeYsc5xjrgsaZ5n76b3s1mcSuTaZXPwdTCKfJ5Bv 48ixEYoTZhg5OIxcHA7fCHJ1JLk6Cozltcg+ve7uWX4q+qaobsFh9o+0R+k7qnPJmPBMR5ej3d0x mvweA8SOCcDpGo89Y9kHoxWngzXeUGwciu3D6R+udp/WceEbqTjh+3AsyCtt0jPlAXgOwHOY/ngd G644iq4jjB1Wnz3fhXe/8gvt/BUfx4GxxGgM8PgkThLXeN//w9CHoA8r/aznFPnehuXYvBTbl+DP YrAIeiGYj+1zFUep8+Phiaf+PqLf97ACeqV+5+az7/Jl6FqOnpXol+/mXK3fMRGPrMx5nHGZ94Ty BX+hQuc7wXwneE44pWPCswQ9i8Ei6IVgPvrmAc+240E5aZ2uZfp9FoeRPYKuI8gchlfOwXjlm6c4 Co/Y4/w7DA6pnNAu5p7t4rf4f9jXHa/fO7pCxzzfhG+V37p3+c2gx8a9y/9KcAWSBUSztU3NC7a5 edG2MC/Zr8wr9muT3H5nUti2JqVtBzpCd6TtBDpDd6HtatLa7iYEZLc9TF7bzeShLzfjueDLaTuY HMhmtz+abOjJar8H35kstiX4Aro5Y5/B1wyZpsh/avLbj02Y/ciE2w9MQVvPPDJ1zANTy9w3Nczf prq5Z6qau6ayuWMqmtumvLlpynHyleXkK82JWorTrwSnXzFOv6LmsinCaVCYE6gQJ0M4p1A+kAc6 F8hBfzaQFZ7MnBYhIAMnx+uKK1RiV0waTuo06E3HHOlBCPozgczMkZXxHCAX8+QBeZELA+HQhekv Ak8U8tHIF8e+ksjHcMqXwe438OFNfKlg/uK0/IcT/76php81zENT0/yLv4+BtbVNADxv67JSdViX uuZlYpIcpLD1TWrbwKS3DU0m24j4NiaGTYjfW8TtbVMEREJHgaL0F4WvMDIF0JPP1iTm1Yl/FZPR VjLpbAXzqi3HepZFbwz6S7D+0cwVST5EMHdBbAgHYdChjOWHN595DaS1ebEhHzmQnzUtgB3RJhSE 2WLMVQLEYFMM+VCKXCjFXDHIvYHtbyJbAdmK2FDZZMaWbLaa2pXb1sDGWuiprfYWwu8IfI7Cz+L4 XBI/ytCWAxXoq4zv1UAt6HqgPuON4Bc0QLY+euqjsyFohO+CxuhvwlyNmbcRNjTEngbYVd+WRkdJ Uxf7a9ui6CxiatpCpga+VcfHajYbCOF1RlMFVIAuazOZUqAYdCR9hWw6/E+H36+T0+nxJyN+hZDr IcQoI+uVFr9fIwapiHdKYpqSfE5BnqQit1KSM6nJo7TkYzoj/3voPLfEn+TdWarsM+TsaZOdmzQn N19ubtO83IL5qQrCuBELgSheF2csBr43kCuPfCVysip6a5CDdci/+uReI3LuLfbXe8aw357T/f/0 CereDe+kez85e1nOgxTs4eT2G/LgK3KkJTnSHO6m5MentM3J0xb0fwXP1/B+S660NamQTaXnRwf6 OimSq06h3UndVc+UFJwfXn8HnTcVrwUy5o1L627z7uRKT+Lcg/jKWdSNvOqqZ1RKzqi0vPbOp+7K k8d6/J6M0K6KbEH+fcmeaAW+YZ1a61mV1bbRsyub/QEd7cjhDqxlR/K5M+vaBX3dfD2e7tzMnYv+ nNifA77stj2yP6LnB3R+D74j11uCL6BlTleNv0/kPwAfs38/Ie+bkv/N0PsZepujT3hFpjltM143 Za5PmfsT/8z8EJn3kf0QiK732e8faFvIuifOuvr7v4WUpx5njbx23wcZSc5Fc2aVIE9iOK/Kkivl OF/Lc2ZVJD8rc2ZVIW+qcWbV4MySM1nkPT33TW36ajLmzuhKyFXwz+c3yO3S5HYMuksyR3HOx2jm iyLHI/X3KMWG3OS6nL2XOYcvc9Ze4py9xDl7kXy/QL5f4Kw9z1l7nnNczvNzPM2e1/M9wtcj+iLo L0Teh7Nf8oE80LlADvqz6e/BnmcvXUD/Bea5yHyyzy75rUeLHe6JNi12p8XudNj9Okhvruh4OoXc EVfYr1fBDeV174aHIJMJSJuB/teJaTogPMKbhrikIz6vA7lbMur9kgBuIHcD36/7rUeLHldR5MfO vCA3NuQCOYhXNpAFW+RuEl6RyQqdDcg9lQfkhSe/4mLw+yKqc+9UZ/2qsn6VuWMrsoblWb9yrHlZ 1rA09pXCthLYEY3OKPQVQVdh9BTUO++i6hO9YSCcsULwRGBDJPzR+FQc+ZLoieHsKYPeN1T/X+TH 3+TJffLqAXn1UG1x/3+jHudKPc6TupxLdTif6uhdaIDcjY/0rqzuy9XgzqzJWE3uzFrw1eIsqq13 5osgmXW6pHWVVH3OEe8ufZk5XtIx4a0NXYezrS5jdTlD6sInrfC7vfoO5/w7escW5H7Nz/2am/sn G3dPJu7Z9NxLqZVf5OopLX0ylh0e4RUZkY3Uu9rpk9bl3VsmmrGiIEr7he8t0AS6id7rAo9HWvck 0Vjv+2jtEx7HK/2N6ZMxoZ0vFbiPy3P/V+RursxZWY2zSuqD2pw99ThTGnD3NtY55P4tzOsw/MpL jHNyn2aBX+7vtMiLjlTBVvS6OQqyhlI/FCbGRYhvNPEtTnxjiFFZYlTO5xe5N7VPxl6hfngZ3peo Q5JRh7xAHRLgLn4OBJQWve7ukNokDP0FaMO1ZvH4Q6Hza93itcLn3p0Ix9dQzuL8+J2PNcqPH/mx IxSbwpg/zJfJjx35sCsvY3nhyQNvXtazAOsZBkSPy6uixCaSNS4CIoiRjAlPQe6FwtqXBwhPPuKT 3wq/eyoryZlfgvgWB9GMRcMj4x5fKJC6KhyegtQo4dRTYaCAFTm3/iW1zpJ6K7/2y3hp6NLokTos hnHhcXErzXrFgJKsv/THKNLB/xptauvGpXWfYNTAj+rwVdUaMjM1ZEbW7nXWLo3Wdp5MatYxDbmV nrUNgScLeZINmZzkTB4rOlx90ciUILeKsT+KslciybsIcqwQ+7AAeZiffMyr/J6c1K+h5F84Y8JT RGvD+uR1Q/Q0RI/oa0yt2Ming98DTb3WkFqtkc9Xn1qyHrVkfWrJ+qYiqKCt8Ll92Jh6sDE1ZsPg WBXkq4Fa0HVBvWArvG6u+tSXjagrG1NTNlYeQX2tS+vTL+MNqD+ldblTW2vVBvgkdWtD0EjHhd+r Zevhdz14XFs/uO414ZHaVvpkTOrd6rz2Wo8WHudXTfMWvE3g9fo9XoH0NbbeuMcjtLujs/s1cC6Q R2vi6uyDGuzJmuR1LXK1Njlah1yqRw7UJwcakBcNyY9GrH9j5vH01VK6EfnTkNxoQJ7UJ3fqkTt1 ka3DHpD6uyb7SHTLHNW0/s5jqjJ/VSt2ON8zwpcJeLZVpc6uzmup0WtC19Ixod3dnJa8SgcycJ5J zR5i5LtqyvK6AqhiPX016K8CKkCXtZnhyWzku4CEvxC1fZh1eqR1Z0pG9kMGzoaM5HsI+yMjez8D Of86+ZuOPE5LPgu/yL8OnZ58zkBeh7A3M+m+zAwdYkWP05mCezQ5928KfU6Q54UU9lX2Vhr2Vkaf Px37LzV77lXGUsGTCt6UKiOyTv568B2nlP6zRgptvWePVLyW9lVtrymP+0Qihf/a47mqfK5PWldP hJl4Ewry8SySh+eS3DyP5OQ5JTvPJFl5bsnMc0kIzzEZqM3SU5Olox5LQy32GjXEq9QPKYI2XKVP 6qvL1EhSq8lz0Dlqoj+pc85S15yhrjlN/XOKeU5S25ygBjmuz0HOBmldfSvPJx9xH7xP/fA2NUNj 6p0G1CF1qXFqUqNUY74KzPEGumPQWRx9Udhf2NfnPV8do6Y5YYoxHsP8ZbGlIvZVwV55tqpNzN+i FnmXWuRD/3lI5n3W/5KKtyfNEXvaHLZnwXlz0F4wBxRnTZw9A06Z/fYEr4+DE4yfVJlnffJ70F40 h8ARdB2xf8J7xhxFxxFkDvvzHLLn4Dsf5JXW/ZVGHOP7kduPDQd1TF6f1v6kOY7Td4y+E2Yfuvf5 48K3n3nEzv1qq9h8THmFdmec2BOv4yd8XSd8Oen3bBWeY+rrCaWfjt/HqquwWWmvmBWKq9DXwHWz yt4wqxUJZg1YaxPNFrDN3jKx9o5ZDlbY27S3wE2zDCxlfBm8i2gXMbYYnoX2rpkJZkBPUySY2WAe uheCxcy1lDll/pXEaiUxW0VsVxG/lcRjDfavoV1N32rivUp5LqnNz1q/P9C7BqxUf64gI75dxs4r QPyTsQT6E9CZCG+iyrhP9WKxdzu2xuLbNt/vTRqDBF+38Ceadfi8BWyFbyv+blOZ276803E3eFYs 07jd1b5Yjd1t7Lqr/Utpl/u0O6+WMcdS5luK/mUa59s6LjIraVfSt4L5lysSld9rb2i7gnaZIjH4 ydZiXRuPV8YW6TokBFsZdzm2mHmWMM9iXctEHV/InIvoW8SY139Xbff47gY/HZiqa32Xtb5r5th7 rPc9s0BlPLmFjM8CM6CnK+4EZaQN/qUBdk1lXumbrkigL9Hv98aEdnfSCnJjBTmynPVeyvovZr0X kmPzwGz4pikSoRPpS1CflmiMrmsOrkJecsy1K574C9YVnAMryMWVmpvnoC/ouMd/wc9RGTujuSv8 y7X1aOfTGvbjarDC51vD3lyteX4CHNcxoV0+r1K7LtN/kf4L4Bz5dxac8nWd1LlX+vZIrq8K7o+k /e7y+zdkf8POXxXnzFDkRoBR7K/xiktmLPIjwXB0/cbrIcw9GPzC+BCVEx2nVdez/jeGN8d52nNK D8VfkRP5IfRJ+4tPy7iL8wS14ZwZDcSmoarD4/sVO4dixwgwCno8GMe4k5HWPS959ortl5C/bIb5 Po0mL8bRTqBf+McpxOfLjF/G50s6xxB0Dwa/+L4PZkz0Ce2eNYZqDE7De0Z9GYwub16RP/+E36eV dyhr9ZtPu3zweM5q36+Ksyrj9Z/TMaGf9anPDmyMZb5t2LcVv7bi32Yr36R0zWyAXgfW0v8HWIv9 6+Bfj20b0b1Df1XtwjP/x/BWdGxDbgf6t8O7FfktvN6Czi0617XgebVG55C5ZE6ZW2y4ji3XlU/4 NzO2iXYj7QbadWrTZbXPyUvr4rsRvzeAtdj4B3OvUX6Ru4QPFxnz/NiorfCeVX6hk/5qW3w8p30b fX9j9RvNBed0TGjHL77uhEf6YhUX1Hev3xsT+un1cHm/BN4ljC/GxoX4tgDMx+YZYBp90xibgY6Z ynf+mX/RMY9YzAcLkFsEliK3FFsXI7MYehFYiL4FYD5zzNN5LgflpHVnyFTmm8rYNN+Omf648M8A 09ExHX3SerwXtXW2yLzzwRxiOJt2JpiOHcIjMuLPLDCbvjm0S4DYKXJLgLTP+h+vk7m/JnO2TwDj uAt+ViSwj66DG+yjBPL/Onv+Onv+hhkDxtE3gdcT8WUyc02mnYI/UzjXRd+z/rflJO6XKcwzBZ6J ijvw3/b7vTGhXdwGqS1il9h3V8eEfwIYx134MxgMPUhxV3mFdvMNJu8HYaf0DVZch+eG9v+MvYPU x2tPnJnX8NeNS5vA60TOgOuM3dDxXxXXlXbrM0HPs2vYJPGROEm8rimPyI0Ao9A1Bl3jwAToifBM Qm4Sdoi8s3kK8ZykZ6o35l5P0bw4FaTdeT1F1++W+R29vyv/laDMJF2fqyBRfoNJY+61Hj0luFb/ /cudOGQPILuXuO5C/y54dyK3E9t3YPsOfJNfx9hL/u6FN+7/qAmdTwfRc8DniVP6mv6CgvQf0nmu KO34Zc59QPqEbw/rulch/fd0TOikv1C5Bm5gk9gmNoq9t8Eds9vn3cvrPWA3Y7vxZRd8u5DZiS87 kZfW0+O1SbbIr15e1D7hEX93q9+CCzomtHvG9Hy8rL8OsU9lL9FeVb+TYpT0V5nuu2xn8sw10zwy M8B0nu2mK/2A9j74mzHBPTOL57PZPO/NMTfNXJ755vHcNp/nzQU8Zy6gna99MnYH/AXvfWQeqv5n /e8Cb75/dU5pZ6gtj5F7RCtjD/zxh8H8mKH2/KW2TVf+B/TdB/9A/4Ps337r0cLv3itbiK3zwTye V+di/xxsns2z5yz8mondM3imFf5ZinuMUcea2/DeRCYR2Rvqq9Mj7SKeex3t5vF8+Bf5h8je13jM Q9d85lnAnAuf0CExnEffXD92c+Cdpb480DXxYiH6PJ1CP+tMvUtu3SXXbpN3t8BNcjYRJNi/zA1w HfoquMzYJXAB3gvk7kXy6xJ5coU8SQA3oe+Qo6Lv6bVz936C/RvdfzPPPea7Z+6h6x78dxS36BM7 7jB+B3134b+nNnj2/A3+UXmh3Xl2nv1xXm26i01ip9j7l7mmtv/tzyl67vH6ru/HHXgFN1Xenani y2X9tqur6LvOWIKOX1QkIneD8WvweX67c+2exvAGPlzD/qvY7sXkOvvqmn5z1hWVSQCJ8NxC9x10 i9/3/HjJmsxWfY1MTOCGqQSqBBJMtUCiqRG4aWoGboFH0AFbI5DCVg+kttUC6W2VQGZbOZDFVgxk teUD2eyb4I1AdlsGxARy2JKgVCAXCIOOtCUCJW2xQDnwpo0GRQPlbSQoEqhgIxRVbeFAdVDbFgD5 A3VsbpADOjvIGqhhswUKQBegL8zmpM0N8gTC4Q23ocybFWTCjozY9Dq2pQuEgAfmdXzIgD8h+JUF /7KDXNB5QSj9hUAEPBGBf0xh+AsHXrCFAi+CVNjzGjamtlGBV8AtE6l8iaYIOiJBVOC6iaYtBoqj rwQoRZ/E8unnjVoay0Rim0CMJdbCJ0gwZbQ/kfHbGnPhdetcFV+qE/Ma2FGTNZD1qBX4y9d3i7X5 Czwy1Vmj6oxXg6+qv0Yi6/Z6KV2TnKxPTtYpB+uVg3XLbiuASsStCnETfpGrpGubhbXNCk9WeLMh kw3Z7KxndtYzp7bF0SG06HbnewzrHuP3eXzy2uuT1sWjOHlQkrwoRX7EsKYyVlIRhlwkul3OvGGF 1+3niEBF1qQi+VOBPKpAPpWHp7zyCK/IRIMoXhcBEYxJjhVWVAy2osfVURGBapp/0hYJVAGVddzj r0ouVAPVtS3o08Lr7kDJ24hALe3z+GojV8t6/d6Y0O6zlSzkc5ZATXK6NvksuV6XPK5L7tdBfx3l FfkCID90Tt0HteAXOU9WWjd/NmKWlf2QRfdJDd0n2dkXXr83JrSLYT7dN7J/BLKfwrAjFJkw5RPZ HIzlpM0FcgcKwl+QfRbutx4tepwNoax3fnIin+7HcBsGHUrOSBtGG6rI8cTv24XoPs1Afybdvzl0 XPiyal9W9nIWm558TBfIqPs5DRA5N2c68l/2eFr2bFrd76LzVfDApGcsPftJeNw6F9C9L2fAddbg OmfCDXgSlEd4Q9iDWXidHeSCLqC4YZLyxLCWD9j//4A7vL7J2ns8BfQskde3wD/QD4Dwm+C6R7A3 5TyJwMbCer68CP2C8hRSvMD6vwhSQb9GfxryPI22RQJpfTp18POnKGyO1HPpFe2X8aLQRbGjKGPR jAktfE4mAlsL65l3Ex9u65jHcxM9crYl0iYon3uvolTgmilJvEoo5KyTM0/OvuvIXYP/uvKLXBRt UdpioDi6SoBS0HImllKILk+f0G4tSyuP1yd8Mf7r0no+3gjSjt+dnUly3utSamNCUD74DRWPk/5n ZPL/VCRVWM0qgWTcaqk4+TJw8oVw6mWypcm+CFAQOgJEMRbN6RodeJ2TJi2nTnLwgBnvmLKgHNGs DETfs/4GoBLZXAk9VZhL5qzK6V1V57+D7COQjPFUnMwZsCW9dfzSOh2FsK+g2pYFG7Nga2ZszqQ8 IvMm7RvwlPbtdvzSOh3R2F80kA6kV7+KIBPBeJLuzPSJzyH4mwF/X8fXdFbk3I4oga/FsbsYMShG LKI1Juk4wZODB6zyHXju+ny3lFfopNvtDpCY3SJ2t4jhbR0XmbKgnMZEYnNX41NNcVtlqgZj/N/1 LAB/AXZUGDsqjJ1RAJuysTuysTuyBl62mQMv2RDojIyHBB6z8++bTOjLArKhOwfIBZ0H5FVdd5/5 twAFiEs4+gvoPC9AG3DXhCnY/fSFMhamPGmtx5/el3k9+CsXWRnL5o8XUDo1J3Ea6/q19Z8usqgP L9OXXPuFLzv+ZMOvLJwgmYOto19O+iQVmRCQxY9DRuQyaSySgxQ6JrS7qUOIQUbik5E4ZcAXGRP+ ED92mRjLjK+ZgPC6NQjXuN3htpE4SjwlrreI7y34byuvyGQB2aBzgJzQEu/QwD2NucTQ6QkPrkHS erfXuUrzdPOCXWSet0vAUuhlYDn0SrDGPGe3ge0mIH9RC16we8yLdq952caZ5PaASWEPmldBanvI pAGv28PgoEln9/N6L/27Gd9hUtpY+LeCTeYVu9G8ZDegZx2WLAdL0bcIXQvgnYvMLOSnm/R2qgmx U0wWOxlMNJlARjue/rFgDHxj0Dca+ZHYNpqnqHE8PU3k6WmKMXYafTOxew72z8eXRf/H/+B0ebgM nmXqv8ThObsYLIR/MVyLaZcoPFtXaHwkTp6MtE7PbubbydzbmXsb9Eog48K/EqyBfzvYRf8OeIR/ N/wiI7Q7Gw6Z14ilxDSVxng/MduN/G5fbgc6dmLLfuJ6gJgdUN7Xgnl3mPgc1vV4TccOQh/UtUlv jxBbaU88Qbu8k7XZ5K9TLPPuQn4P8nEmLXqS5A/yej/9+3Q8FbakwC+Re8VuZi2dHmndmblC4ydr /qJdz/pv9Pk8/hfJh2SaD2uDOei1K574H0lTTFb7O5hGLswwGVivV3R8ma7PS6xxctY6FWv+Gmuf VnPod3JI8meKIpvKix73P+nG+Pk0Dn3jFRntBGQmaL5ltpN8fi8PM4NM9IUAycXXkX0dWclHQQY/ N9MH/R7B2o5gzUZh52jN19Q6Pk7nTQ2S8zoZ4wZY6/ilDf79i3loRoERPs8Ycn0Uue71P9AxoV3V sdDf0/PJvTnkzExkpiE7hb0xEblxyHuy/5qx2idjwiO8IvO8nYeOhZr/yZ5o3R5K9p939Xqzhr1Y g56gB2vanbY7/N3Q1w39PZirJ20v5uhNv/A/657vpjpeQdfL8L8M70u0yXj9Iv0C0f2iziO83XQ+ j3bvNPRkvu742Q3/ujJvV7XjBdvNt68H+rrjZ3e17TG8j1WmBzIiJ7Tb1zJ/H+bro3YHsMVYT/9j +IWWvhfAi2qnx+/JCP30X5UMVr1VDLWu/dtE2Hsm0t4xUZaa0yaaaHvdFLdXTQl72ZS0V0wMdBn6 ytobING8Ad8b8JdD7k3k37T3TXn7CBhbwVrwnK0EqkBXp6+m/dfUtg/AP6aOvQkSTF17DVw11Zmj or2E3gvMdR4b/sSmMya/PWVyguz2JHl/gnw/Tr4eY+8fJWfj2WNHyNtDxPEA/h3QsygZ58TzwHI+ PMd4MvhfQj65PQ3/WeTOsycvoucy+q6i9zr6E00u/MmLP/nxp4CVmDydF8FfJdV4lML2EsSiBLLF LLW6vUvc/iKGPFsQC4lpIV4XRl8R9EaiPwqfizJfNPLF8bcEKBlsRa87Y+4R17saY4l1WeQk9mWY s7SuxRWVK4kP8lr6ZV3egLccMuWY703ky1vR455eAraGfZ71eJ51CbA+xsp6ybrJ+pWz3pzlocvT V8E+NrKOFeEV/irwV7eiw+2PBFOPdayLv3XtQ9ZT1tfYWsojvI9NTfTX0jW/CRJ0zaWtF6yZrmoO 1NM+GbsGrsPn+qV1cT9JLpxknU6zRmeJ7TnieZ4YXMT3S+TPFfJI+EX+GvQV+i4zdtHPqXOmIHJe TomuE+g6qcgZjNFh7pAj3GXx5MlR8uwYeXKcPDlBnpzUPMzp56S8DtH76zj5dEz5UyGX3IoO92n4 fvblPoXkZDLN04OcKcIjvEeUlr4XNX8PsH/3w7uf/I1jxUQ+jv0tOoR2vwok+XUff/4iV+/iExU5 a5+THMgmn/fgewgxSa+5/if30Bnu6JPMdZx54pnjUFB3gDmf131ylH10AptO+fvkHP5f4C65xF1z hbvnusnBGuVmLfORK+HkSWHNcWfL/eCe+e/f/w7n7h+BPSOwayS6RmLrKGweje1j0DUWXeNYo/Hs pfGs1wTyejwYR66PY6+NZY+MZg+NgncE+3Q4azEMXUPR+xuxHMJsv4GhxHIYfgzHD5nzWZ88j9L5 Q3yb0iCTBn6hMwEZyxl8520C+2sitkxQu8S+KGwqjE3h2J4fu/Iov8iNVDqUPhmLgEd4i4GSyJVB PsZ6+pzOMsFngjH4OAa+seqv+F1Gx0VmvKIkfcLj8UnrbBzCmkoMfiUWv7HmQ/FtGDGSWI1kbUZh h/B78pFq30jGRsAzXHnTIJMC+WToedGKvl/IiyH6+oWgjSN0HSW2LyPzIjLeuMj8pq9fAq8wllx1 jgiuQdK94/6332/k0lDiN9SEwVsQnREgEploUAL7StGWYqwEKAZfUVCEeSKYrwD25bWDycmfqYcG sXY/kbMD8WEgdgzChsHk/C/0/UJtNAQfh7AvfoVf5n3W2T6SOI9izpGczyOYbwTrPBzbhqmNYmtu dORBR35QgNcyFgEi4fPsHoGOkayP6BrNGnv6YoL1+a/w/6Z+iD/il/hXCvkY5RPZEWA4/cMZHwbf MPiHYovIujUfiOUD8HWA+pwa/9Pjd2bikQPf82qMhN+TK8DrvMRCxoRHeEUmBRAdL1nR15+1FJ0D 9X/je2ei+Pwbcr8SPy+OEtOU6HjFeja8hI7kvE6F7tTgdcZDgPDn0HgNDcY8KQ9eUf3PmQjO2wjs kPZZn7BG6ngKnhFepWYWpNTXkYoXgrTb38ITiT1OLgLa6/P6hQ6++6vzv6Z9wlfYH5f+QuSvjBUO 2pZkv5urOGPF8K8o+78o/kazp4pyjhQlFtHYWfz/41cxYlMc2RKq41X4c+trrz9fkE76y4Xs8Mhf pOUAuZTf6YjWMysHr7MHW+EPvl9EHIpiTxR2RbL+UWpjdp8/E0gNnZI2lfV4PX6h3f8+FTtLMF6M vmiFZ3eJoI9JZ7/L976M9We+AeTDQOz8ib3UH/RlD/XF9j7Y3QefepOXvbhvenLv9MKW3szT9/+I nfPnJ3L6J/QNRO8A9PeDtw9r1Q+6v/bJWBg8oVZ4Byl/mNLu3dQ+2NBf+wso3wDQj7j3o7+PIhQb QpV2Z0RvYtIL9MTGHtjaE5t7YXtv9UF8yaP8/RR5kJe+rCAT4xlAauhUyLxqPV0pVJ/Q7ldm+wXH XkX+Nd+v/+bgcuV/l6fAHDaTzWUz2zw2i81rs9r8NpsNtdltAdqCvI6gP4q2GK9L0R+DRIzNaUsj URqJMjYfyG/LggpIVrJh1HzhtpotRC1XyNZG+zvwv43sW+hpgr7GzNnIZrQNbXrwum1g09r6NrWt Z18FKW1dmxy8YuvYl5BPpqhqX7SVeV0RlId+k743qEnLUi+WpY4sQx1RmrqiNHVNDHVNKVASugS1 TglqzeLwFKXWjKI2jaC2DIM/P/x5qUlyyf+tkc9mqYUyUQtlpGZJT02YjvolDXXMa9SCqaBfo/81 +FJTJ6dGbxr0paFuTWtfAC/ZdNj9uk2FV6nxLi1epsdbifGz/jdVdmKcg1hnJ3LZiGRWIprF5mY9 ciGdw4YwkoE2I69DtF/WKZ+uU1aiLPLuTMhuS/K6FHpkrSJ0THiy6BoWh5b1Kxm8T0KJXaiunayj rKesa4zyZFU9pZm5NH1lmLkMPMLvyUjr3ncprOtcjdmqMVtVvKlMDkgeSD6UV958ivLMVRFUpq8K 48JfHbkaoLp1eqR1Z6TkT2FFdeUpCF2QZwXXL63zP6d9Fzvf1T7hyUne5SbvpD+XfU/HhHbfa/6C 5lUdcqmOfVlzTnJPclBysb5NQ16m83M0I/maibzNTP5mJY+zoTeH5vW7/hxvEbcm9Dcm1sIrMg1Y uwZkRH1yoR4669rXQCrmSwFeYX4vv2thQ237gqKO2iS0W6dkthyvy8EjeV+R8UqgCn3VlO9FRVV0 VcaPiqA8dDl4ylqRdefPLd0XMeS67BPZL2XYE97+seyl50AyX072lWWdH8PzCP77yP0N7rGv7rCv 7tA6fdK69brFXpPXd5SvhO5D6bup/SWVdvYY8tKwio+pUR5RBz1kb95nj/5NPXSP/XoH3PJ13EXW 28cl2LvF4I9GNlL3skWHtAGfFr3ue2ouchZe4Py7xH69TH17hRrjGmfpdeqMBM7eRM7XO2TOXc58 ORMeUt+aoJ6C8ute9OfT8+EO57ScDwn++XDNPx8ucyZc4ny4yDwy33nO5Qs+7eyQfSxnQTp2cWqy 4lWyIjmvXtKzQ84QOUu8c+Um+m4gf8XXcVHp1MyZmvnTwJOGWKSFPy12pkNe9Ii+9ORWBnIsBK2Z 6cmqZ4fM/fT/yKmmduUyc5l3LlxzyNg58M+Gfxa7ZQa7fRo7dSwYxW4dCn6F/oX2J9AfujPoxK7u ANrD3w60Zyd0YL6O+NoRnZ3ZBZ2xqwsWdcXz7lg3DkyAngFm6fz/fd5y72dMY66Z6J3FLpujv3GV 1c5D7zxk5igyYHMmkBWe7PDmstM5yaZhk8hOV+RXOul/M4ov4lMYvoXhY6iOi8wkMAH+oeBXaOF1 +7AbdA/6e4O+GgOJRRgxCbOeznzQ+TU2faF7gx7Y3o1WZN2Z/6PGSmImsfPi2IXxbop8vBbkJX55 Gc8DXx6Nr5OTNvi7JqxuB/zvQLzbc/q0I/4/6jqIbE50ZGeNsoJM1uP1+IV2NUMn1qgTcZQ+4eui rzMG38/vTrZ2A11Yr86sYyfWU8a7KNKzrukYT8Payvp6vNK654B5usay1rLmsvaSAx6PyEguTIZn BpiF/rlA1naeIrXKzrP/fR5Meg5ITa2d0Ur7dB65+jNSeV5VnkjFq/paaHd/RLBLI9Hj8Tqd6a3X 741F6F/jef/jpbD/WniKQBdWhGif0El65ZkgtfYVUTj93rNCYZ9++jMut8YFAplsKMgXyGxzg5zQ 2UGWQIjNFGCeQHqQ1obQZuZ1NvpDgcg9HQ/3uUEGeEPgzQJPNtUpuqksQCh0AYWnJx88uUFO6Owg K3KZAhmQf13nzKDzZ/Ba3+cQ7MmgSK883ut0fptSx4R2OSLzhet8Yr/YlYE5npTLgG8hjHmxcPZJ W5jX4T79dAxbqf5iJp7aLp7z+yg4RqV0jJrvOGf+Cc72k5zxpzj3T3EPneYOOsP9cpZ75k/usXPc jefNm6AiZ3pVzuIaoDbnfX1aQQPGBA2RaYh8HfTVQH8V5qtgDyF/gPsrjvtqL/p3Uy1tB7E8X29X FLY7sHiHKWh38SyxG+ylLt2Lffu4m/aTS/u4r+LImwPQB7h/DqkvWf6ztm4/H0XuCONH8DUeX48q sgafXU7g93H0n+DeO64xyQpyYXMe64258dzB9yP/JB5n8eEM8TmtcSrkxywUf/Mpr8gfV1r6wkFh jekplSmGbEkgcU2qAS4Ru8vE8ZLGVGJblThLrCXmZYl/jPKf0fmFlr7yjFUCwlsD1PbXop5N0tcg eG6f0bVpBH8jeBvC11DXTXhE5gL85xUN4GvAHA2tk5HW2bqHGmUP/uzDl/2s6UHzBjGuQOyq4HNN /Kyr/J58HV7XIB6VGS9vD2P3QfzfTwz3se57gWtFr9sHsZobRTQ3doHd0HsUkcq7l/E9YDfxjwXb fH5pt9DGKgoH7xovp8LQFUaOFUBvOPBkvXmK2J3w7+T1LnJwN9gDj2tF3sUxjtyTPNxLvuwhP/aw 1jIufPvI2X30xTEmObpf8zWT5qzQcfpX097ZsI/zcq/f542lRzajlf7d/pjQLiaSn5LvhxWZkcmg 4/tUNkT3iDdXZvaG8Hr57+V1ZpUV+umz4VPVH2EWsT8WUd8tJYeX8Ty4Ar9WkcOr8W0NWEss1oH1 SK8nVhtZh03EbTP16Rbq463kwFbyaJtpQkw/IM5NiWszXn8KPobnffjfthvIp3Xw/UG+rjbV7Epy Yzm5sZTcWEw+LSSv5rHOc5hnFvNOx46pxHQa+3QaNk5nr87Al9n4Oxffxe5n/Z+A1az3GrAaP1ay NivwazE+LkbHQvU3J3RuxsLwNRy+8GArsu6s2ISvG9TvQr6+MOVZQzz+ABuxdyOxED73PLgD33dq DD4gHk2IgcRGYlSGWBRTXk+mODGUvgqgHuPC+wFyIvupdXqkdWeb0DvMZ9onPLH6ulnQ3q3mE/RI 3Jsx5vHFKm8z1RvLeCxrInzuM5HfifHvxGI6cZpJ3GezxnM5sxZg3yLWZQnrs4x1WsF6rTLV8b02 OVGfmDTGj3fw4QPV5+l9n9dv09+I8Xrw1YK/GnKVkH8TPWXQVxK9xex8YjeXuM4mpjNY62lqh2eL tK4Gnku+zwGzWPOZrP0Mcnoa+TyVdZzKmv6uOULdy5pO5/UM1ngufHPgF9m57JU52mYI1i6SB4uU L4PySU64PmndHnExiiYm0axbCWwuQ1zK4UN5ngsrEZsq+FWNM7sKPlYGlaArKirYCsStPHgTvpL4 XJy4FkVHJLoijPxebjh+htn8xD4vMcjNHZIDX7LiS2ZsyoKf2Wlz8zofcQkjjwuzRpHIik1Pvy/q 7Cym73cXYq7CoIi2UfQJLTwuttWwtzq2VsWHytgYg30lfB7hFXtLcWa/QR6IvxU58yvjj/haFTkn L63be2+qz+J7BWIh8agMb2XlEZnKGhvheVPj86aigsoI7b7RqxxzyWsvhmWtvHbfxJCJmMg3SmQl VtmJSy7ikof45We/hxGfgsSnMP4XUZ8j8aGELc39+Qb5J3o8faVtWdYxhvUUH8XXKPyWdQlHTyj6 8qI3N/pzEP9szJeZ3Mii32Qh33iXw/9Wi+zB5/8snE+ZQSZdO7Evqy/j9Uvr7tNiuk6FeB3OnGHY nB/b87DOuZgzB3M6uWz4KP+DOCf25Fa7xL4iyEb76yy6imN7MZ9++lnB1YG7zHfcWW25Z9pxb3UE XbhvBN24S3pwlwj6QA+gbzD4Ff7B7O0BnFF92Nc9OMO7sKfbs6fbsqe/ZU+3Zk9/w95pBb5iL7Xk 7PiC/f0ZaMoee5c9Xp99WZ19Wp79WspOJrcm4MN44jQJn3/H/+nYP8sUhb8k8nInVES33BN1mK8h 88q58iHni9wtLTjPWlnx5+k7wL3n7/kmPrbDX/H5O87D7zhTf0CuPa87gi6gs7bC756R96lsZ/o6 a7/H15W+rvp6n6Kz8gjtnhUPEJ8DPDHGgX3EdJ+vdw/0XsbiTE/i21Nj7XildXtnD0/n+/SXYAfD N5Cxvjoep+hD/wB0/ay/Fitr4/EPUxmhXW6twM/lrM1KfF1tOnAOd+Ee60ns+rKWA4nBYOX31vdn YjmAs7sPd1IPzu0u3G3tkWuL/LescetgK3qDz7Ws7Txd4y9Yr5as+1es/9fc598qn/AvIy+W0LfY z41FrNtC8zn8nwGRbxr8XG48eT6OfBhPXkxiz04hT6aSL9PJm1nUpXPII+H35N7ldX3ug+qMl4ev pObURPbQBHR4erLZsdRFjnZnh5cHrYhDC3K6KT5/iM9v43NDcro2cauGzRWwsyzzlCR3o8jdQswR yhy5rbNzInk7xc/bmZq3pYjFG/hYkRhUx/86xLARsX8H/R8yTzNi3IJ5WzF/G83F3cH8TarL3DOH /JVJ8UB+WyzAPg9E26hAaRsZKGMjQOFAWVsQhEOHB0pBFwfR0FGgEHQoyA5fdvhz6F+sPOvzoCh0 FAXFAtxPgcK2BHOWgL+YIj9zc4+gO5L5owIx1vFL6+rsAtAFfJsKBd5Q+yJBlPLFqGwEKMzrgmpz aW2dnLRu7xVQH8SX4vSX0rGCilLoLg6KMhbJ6ygrvG7vFQxkoz87CKW/kI4VVBRCJhRkh85hPT6P V2gnX0LjJPGSuGXTMeEvDCICORnLqTEpocimvCWCcU36y81JVvTtMW04x9uSLz+QJ+24Rzpwbnck PzuTR13Jm27cUz04+3tx3/RGQ1/yqB9n9wDwE7n8M3tgMHn1C3fXEHJrCHfXr6YcqAxdDZ7a8NZA phqyVdBRyfYk97qTu124WzuRix3I4R+Ra8td1wYdrcnnr7nv/kct0pK8/py2Bfq/pP9/3I9fw9ca /m+Ra4N8W/T8yP5qj86O6O7CPN147uzJvN0UdZmvPn40wI8m2PCu7UOu96Ue7EM92IfasLd5T/t7 scd6mbeQbQIaIdMQ+YbEohHtW+h5B7xP/4eMfwJvM+SagxbQn9P3GWNN4fkYfIjM+8i+i01v4+vb 2PcO7XvE9wPwIf0fM/4paAZvc/CFtl143Zn+joqmxKgp7efItqT/f+Ab8DWvW4GvGGsJTwvWsCWx +Iq2FfH4GrS2zUBz6Ob0fY7s54x/Yb4knl8Sz69sK/q+Yaw1PN+B73ndhrHv0NUand9gUyvwFfO3 xLYvwIfwfcS58In5Hv1t6W+Lru/h/x7Zttj/Az59TwzaEOdWtj86B6BzAK/7M97P/Ejc2xOzDvB0 grczfnTB9i6sZ1fm7oK+LtjYmfk6Y3sn25S78BP4P0Lufe7L99D/Luf4O+h/h/i8RSwbE9fGxLsJ a/UWa/Y26/4OZ9y7PPu/Sw6+Q16+TZ68Rc40IX+akE/vU1d9QJ59RC43Jcebk+vN2QOfsxe+YF+0 YH+0YJ98SW3zDWgNLfvm6bPK1eGD0fMze+Mn9shA9kt/0BfOPujtxV7qwZ7qzt7qyh7rzDydmKcD e68dc/3IXG1Vf06Qm7XIw97MS38+1jK/7s1OyHVBvjv6eoI+zNOP+QbonJF2EL4M0n0pKKK2DH7i /YtficNvxOE33adl/H1bnD1cVPkGqf3R0CXoKwWEpxyoDF2Ntqr99YlvfxvIHpd9/qs/NpDnqZ+A 119Hx4R2v6vQEt1fMV8r9LdG/3eswffM8SPr0Z793JG16cJ+7sY69eC86MW8/bir+rOGnk7RXUPP kz56nlQgFuWJZzliU5ZYliGWpYljDDEsyTlRgnWT+aJZwygr87v66wvoLxhrQdsS/1v6PF/ouVMU FAfR5EMxpYXf+dETe3phR2fOnI7Y0B4bfsT2H7Dje/z4DlvknPoaO/6HnyL7uc5VgnlKEYPS2FQG 28pi4xvYWg7ZCtheER8q4UtlfKqGb9WJQ038rG5lzj7+vEK7mr67nnM1tU/4uoGu2ue1Mu7url6c gz147u3O2kh/V0VdeOvredddz8kG6Kmvrav7+nAW9ePM68u51YdzrDdnpIx3V16hvXO1Dzz99GwV /mZB2uVLb87EXnreyrn7sU3S+xH4gNfvWuFxz3/d9extZLvredwYyPn8js4nfB6/2POWnu+94Ovp +9EVdPNbkXfx6qY6G2ufjHWBvwu0a2Xc1XxytvdRyDnfDP2foP9D7JB7QO6DJsrfRXW9Be3dEd3x p4fyikxzIDq+0LuiP+en6BTa1VJyR3QGXfCnK/LdmKM78t0523pwr/Tk/O0d1NFc756exK4HMeyh vO/r3GKD6HK1Uye9c9610nZWvK3jwtcJdPTvpQ7weK1HC797v6grc3ZXfMYcclfJnfUxeuQOex+d 7ym/p+N96A/AR/R/wnhTvc+6YrPTI617n6MT40+Oddd7sJnKypjL2456BzbT+1D6ZbyD4lP2XlPQ LNgKj8vbztx/Xbgvu+i92QLZ5joufB2IqdydnRjrpDxfW4//W5UR2sWxPXztuMM66F37JXJy7zp+ aVsB6W/BOSB3sdeKXJKO75BtDeRu/p+OCc8P6PoR+Xb0t2O8PXN7vB6/0C4OTfVO/5Yz5lvkvtMx 4W8GPqNPxj+hr5lPu3O/BXN9AT5j3s+YqxlziYzwiFxzv0743K8TvgAtsKslSGpbBuPaRuuErzi7 WoGvtX5oDd1Ka4uWyisyXo3RinPuG/i/4VwWuf8F6/IWrMEXWltIjSG1htQcLZRHeL9HXxtef8vY N/C1Yv2+Ai3JxS+AyLt9/RE2fMgcns7PuNdbga+DrYy7/dZG65U22NcGXVLHfE/c2tiPicVHKiO6 vuN1W2L0Azw/wNsWmbac7T9g0w/BVnQ5Gzpr/dNW+2SsC7VOV+BaGXf7aiC+9SdO/YhRD+btxnxS NwmP8Haj7c7rntjVm/E++NYPu6Se8mS/1HYg/ooeod2zQm/qpV6gLzVTf+qlAdgyED1Orj90P/T3 1VqsHbztrci4OuY9+t6n70PkP6a/KTVYc63HpC6T+kzqtK6sUTdytyt52lVruK6gB3ze/O2xvyN9 nRjrDE9nrfGkvvsGuhX4krEWqrsja9CBNWhP/GXuH1mDH+17Wuu1V1uEdvdCI631PqSG+5iarimQ OvBb6rzvlc+TFbo1fa2A8HwE//vgA+vkpU36ZvEq8FRGj9SKNaHrUCvWh78RvG9pbSn8TRTvMvYW PI3grY/+OsxVE1SDrgwqBVvR69alMXd/Y60930S+oo55PBXQJX1lQQwobT3eGG2d359R831GHSm1 6if6KwNRzFlUeUTmHWqe96gx3qdm+ZD+jxlvBl9z+D/X2tZrRY/by1LfNqfObK6/eBAKwpAJVx5P JhyEQYeC/KxXXpCHPeHVxkm/UyX1sdTJORjLoWPC8yXtN6A1dBtFzv+8p+A+P3gnUNC+w7Pwu4Ew UAA63Erfs/6f7Ts8/78N/9vwvKsIhT/Mev3emNCO3/G9h+73fL53oN9mHjf2dnC+JPvce749bUHb Dvxgw+33toCV189636KtDYMnHF6RKQRvIeXvTl877S9gHY+03z5Bu/8X4WQcn3st7dM2plCZ5827 gaL4VAhfoqzQz/o/F+/C8zZ4B573gHstrVuP91SH44uiJd+A0+Fk3/PH3vZfvxOcN8k+J7PXRtt1 4A9b1M4DO8FuXkv/07a63Jpno+CNtivBalsMXkFRuwVs0jFvXNqk35H0eHbrHEk8O8HuJ3RI+7St 7v+uTGd8DpD2WXGcg7456J6uENp7La3jeXrMvZb26fdn3P0wgTNhIufDROrS8YoGdpyivh2jqGtH 8zw0ihp+JOfOCM6bEZwpwzlHRnCOjOS5YiwYz+vxPJ+Ivqd9cOfSRM6xScwxmXNsEvom6bwVkKuA XBXQkNcNrMfn8Qrt5Edjz1jGx9M3UdEAGbG1Hv31rDdeX9vRjAuv0O7sFXuHg2HYOlx9EF+q4UMN /KsNb92gjrHQY/B7tI5VhcfzewSy4vMIhadP2uBvPGo8yyPv9QvfSJ67RoMxyI4F4xgfr6hgHf/E YNxeDK5RRn0PrT/Vf1nb2JazDW15W99WsPVAXVvR1rGVQRVb01a11UAl/q1ga8BZ05axtW0pRqOR ikQ6wr7Fjn6H0+B9G2o/tPnsJzaPbWpz2U9tDuis9iObmf4Q+4FND086kNq+Z1+179qXwYvIPg8s 9EPupfvU439zz93jfrvDnXeTOzKBOvk6d+BV6t6L1FLnqanOUQf8SS1x5v/1dR7wVRXN3z97RFR6 71WS0EEFLCg2UJFOICEJEBJSIAHSCAQC0rGBSu8dRBHs0rv0JqgoSO8d6V3k/c6cuzf+eT68j5/f s3t2Z2ZnZ2dnZw8393I+HiG3OMz5eYS84DC5wmHO0EOcxwc5mw9wXu/nnN/nDKYcQvmh+csZbvY4 I82fzlj9pbrd+uvoM8yvzhz9NfVdzmzqM/QX0n9zpvh+wW48GAXfx/CLrL7ITmecbowbb46h60nu I6c4V89g2bPc0c7jKxfB3/jbVXANv7kD7uEHDhY3Jpi5B5vHqWcHT1B/CuTEtrlBXtMaW7U2BbBz IROK/dqYoiYMW8rngztg4yhTAQRQD8DGgYp2rEFbEEHUbUPUbU20DWadmrNbm5oXWMuXWNNXWOPX WOs3+a8B699QV/dVVvZVqOsx+qtwctbL53Uf2nc2L2+GnOb4SXNkBSOnFWiNLPGpUPhD4G3Jc3Pa mzJKU2g93xI+j1fq9hcCAkws+seaivhOZeZUFZ8hoqN7GLqHqs+9gMS6cIofvmaaILkxEt9F/4bU Gqo8GaMxshuCBjzL7F7Ff1+G/kV6n8fTa6FxoNovhpI7F+MGmDgdX+r2d4Xv44//gDzYND+2Lah+ HGmKgZLoWBoZZdG3vE9GoPp+NOsTZcpAUwr64vAVgb+QyohgXcNZ53DWO4z1D8MPwhkj3MhY9rOz R/Hno+TUR/HtE/jYSfz9DL5/jnz5AveDv9kLl9kXV7lHXmeP3MT/brNn7rF3PJ3D2UsR5hb1G+R8 1+i7As0l6C/Cdw7+M8g5jTzZT8fJwY+Ry8t+OuzbT6KD/Uzffnz+APvoIPvpEPvqMPvrCPvsCPvt KPtAaA8retLfC7pM6PuyT/qz5wbqntnH/pPyL92HQ4zItLnNAWco9F6b1zdUS2k/qKVXt/r86nzO 3vycvTlT9++f+suTY81e9vU+5xP4P1J6b8wPaR8OzQj2+1jfr1JO1T2+iz1vZUnp/01mjQNztU1o dmr/XLNT8aX2Sd2ed7sZd7czBrnjkTUR2snQTAMzoJuttL8qZtM/E0yHdor+MuYf8PxBbBEZv2vp 1e197wQx5Sjrd5g4cxBf2I+992HbvdjqT+KR0Ar/XmeYxjmx+0GNhRIf41nbDsSlMI1PIutFlVtC /nIXf2lBTGqJf7TEl4Lxq2D8qxX+0YoY1hr/CIE3VPmE/zQ4Q/0cbefpuwguQXcZSIy7A+4hw2F/ PdA418J/zj7B3n1S41wL/L6FeUxjoEfj0baivRXxMJh4GAxdKyM8zZQ/kCzci3nl2Vdl2Eul2Esl 2TsSD4sR64oQIwoTdQpq3JT4KXFU4mmwyaHjtlSZXnxtTX8IdCHE11D2Zht4wzS+FkNmCZXdjv3d XvexxNvy7GvZ27YUffzffgZPELyBlIHoFgBvALwV4K2gendQngogSM/J9sS5tiCCczPCX4oc+7eo EocbA4leDczrxLE3qL1JHGtAHHubONaQONaIs7cVvKHKKzKq6JkcYmow7+eId3WIey8QI+tq3H+b uNkAKfWJkm8i4XXGeB2q16B+FQt58d++Z5Y4LmdAsMZy6XsNywkkvnsxXmja+M4KqT/q/hHkNjBB 7pumkkLqDR75+YLKSvMGNG+YQOqB7lumIvQVffxSVla8oXRSz/rWuLd5bqBtFRUNoKlvvHavT+qW XmQH8VxJUZ96feWR9kDapE/qj8qz5zrvmrncn6V8eD72XeEXStNQ6T7Xz2oIGmqb1K0uc8kXv4BG 2j5XiNxGxmv3+qRu5c7xPQuN9M1RNNW2OfrrNVZuQ57f1TYr39NZ2r0+qT+cKyYqfy0iSDN2XgsQ jCe3xoNDQBu8PAxE4MlSa8/6d8Abo/GVGE7peLgSOKm74oHJ+NkA/G0AXjgQ3xuAtwzAl/vjm/3x 0X74cj9yyvc47/ty7vfh/M/El3vj0730Bim3zCrIqYLcqsivjjY1GfMFdKnLqDbbaMCoDRm1MaM2 4/9DQDj1drTJPB71ufV2yGpv5P/DdW4dmE0Uc41mztE692a0N6O9BQim3krt0JaZt8UGEfC2VUu0 9/3XTus2h2+K7s2wRXNs0oI5iHQZSWjaqpR2atVm5CFNoWkCbWN4hM+uYyNs1wS7NVV7JrP7B/Dc 33jtg7RP6vbu9g5tDXn2+vtT74/9ZQ0G+eNMRexbETtXxt5VsXs17F+TdXiG9XjOtz4vwlMXvKJr N1D5Rc5b9MkavgTtC6AOfLXAsyqjD2uUqW8QqjBGJZPBGL2NHU9Ka5tq2KIKa1oZu1RmXpVY60qs eUVde+GXNxZp6JcM4pEZi+xoI3w2f4xSH22KNZtgV1n3RrQ0oiY3mSaagUqkq4f167J+L7C2NaAW GSLrGWz/HOtQh5V4kdV5WaNcMD7VAt7mml02RkYzZIWAMOrt1B+a66rZ8aP8Ppb1d8d2nuPYc+M5 cydwbk4gR5vIuT6a3TUa7xvF8ygi7kjO0hGchyO4K47Ca8bCI3yP+jzuRPgnIWcS/J7cFozR2Mcn dWmLAJGM19549B6P1K1vjVJdorRN6EbzPIa6tI+iXfqkbs+8sXjjSPT7DD0/U31b89zGNw+Pdwzz Gu2b1yhyg5HQjdR5NUO/JkDml/Wto+NV50baJn3jfPMfr2ikfeP9tsj6DJ79vHVdxniF+b4KXkeX N0B9cpYGoCE2eId5vYVe9cmB3yAHfo3891Xy35fJfeuS+z5PzlSbXPg5cu2a9FeHrgo5c0VQgedi 5OHFmUMJUBLblgKlmU8ZRTNTFn3LgaeZWwBlZVCF9mqgOjQ1oX8GPAd/bU74OuAFdBa9H/UuroHO oQ37NZQ5ccJi53rgZXjrahnim3Mb+sOgC4M+3Aifteu7zP1dX5v0NeRe8A6ltDfS0qvbta3rJCOz K/I6Iy8OvhjzNuvfEPu9q3YM57kd7R3oj4ZObBmPXgno1MW8hB3rKrL+3SIAORXVnh1pi8EWceZZ 5NeC/nlsL7TC8wLj1mENarE2zyC3BvKrMHYQeJrnCvpvZHH+uRXVNemqbdJXDN7itBVVdNM+qfv/ fgj7F8P+Hp+3nsWxpdfegvaWWre2KMdalgWlWcNSoCTrWELRQumEtwQoCV8pIL5QFpT3+YLll9LG 3Jd13YOZt/hBS+baAluIfzRnvuIvnu9UVD9qwrwbK7/IC9T2ZvQ3Q8fmpiqoDn9N5Dyj76WCkdlK /eol/KOu31eCtXz4nZ199zqcPTtUP/cUYaT+qHeG76PHEKWLNJ/ov4V7z1LavGS4ygj3932sz16b lHYtPBmR2iY0VqZXxmnfML8uWbmXfQeRzDmQbFJNkkkByaYb6Eqtm+lCmQA6UYszidAlcE9PIN6n ENdTiN6pRO9UorXIeNQ7+mTOnBSoUqBJUqRCL/9Ju9cndUvfRUdO0jahSlKIPknG9klpc44EdBCd OnOKdFb9YtE1HprOQPTvovTdVIrUEkAn2uN4ioE2GrQHkcbKktLqk8pck4G0CU0qJ5c8S3sa+ZKt 2/fOMs80ZKapbcKM5U+mnkJbMvYSO6T4bfa/+XCEG2oi3DAj5aPy4bZKEwLamHDqbRUh2iZ1q3+E G85zmLaFK8KUx2v3+qRu5Yb5noVG+sIU4dom9Sy5ITyHapuV78mVdq9P6g+fM0GPCf9I8ucuINl8 iYW/5K49z8kwXzmZZgF376+d/uYbZ6D51hlivnc+ND9yL//J+dQs4p6+2BlrljoTzDJnslnhTDMr nVlmtfO5WeN8adY5881651uzyfnBbHEWUi4yG53FZoOzFCynbyVYC906sJ62jdBtAJvMZmcL2ArP drCD+i9mO9hBfSdtv9L3OzS7wR/OZrNHf+PoAPf5g9ztD5ojziFzyDli9jvHzF7nuPnTOQXtGXCB +t/QXwZX6Ltq/nKum33ODXPAuWkOO7fMUXDcuW0ugSvUr4Eb9N2C5i6095xr5j78D5Djmr+53182 T5qr3MOvmTzmBnfwG9y/b3H3vs29+w537nvcsf/h/nyf/O9f8j3HrWGM+6xx3TrmMfdF8IrJ5r4G 3jSPczsT5HTfMQVAWb2xvWWqc4OT73J/CbzCja4ez6/R/jr9r0P3ptvQ1HcbgcamAXiL+jvuu6YR 7U1AKPVw0IV6Grxp3DJT3WdANernnTT3tNPdjQOdnEQ3wenodnHCQUu3q9MQvEb9BTfRqUFfNWiq ulFOACjrRjtl3I5OKTfGKe7GOkVBcTfeKQlKu53p7wq6OeXcFEVpN42yB+hJe094M0Av6r0pMxWl 3T4gExm9nRL0lYCmOLQl4BOUdNNBd+rdaU9zioGibqpTBPlF3GSek+lLoi+JejfaujkF0aMAcyiA /gVBYeZSBBSjrQTPxdG1KCjC3Aqhe0GQn7nkY255mWNO5prd7eC4bnvnvmnr3DER+EI4fhDmnDdt QIhzFpwxoc5pnk/SfgKa49AeM+1ApHPUROGb0c4+E+P8aeKc30wnZ6dJcLaZLvh8N/ZAsrPGpDor THf2SDp7pqfzvenlfGMyna9MX2eu6cf+GuhMNYPZc0Od0eYD9uHHzkecN0PIWfubT8EnTj+e+5mP aHvf+RjaEWYA+/Q99mimM9NkOF+YHshMc35ivGWmK2MmsPfi2Vcd0amDswd9DzK3Q8zjiGmN3sHM ozlzasrcGjHPhsz3LfZSfeciudLfnMN/mxep16G9FjZ4FroazL8afJWRUZm9WQm5lZBfkT0cxHwD QQD7NoC2ANoqUH+aWFDOWUXOsZYcYz31TWAXucdv4A/af6ddsIP6VrCJPGYDecrPxPw15C6rwFLq P4JvyGHm0TcHmunQToJvDGOMZLxPyDPeR8dB6Nqf/KIP+vciv+hFXpHBfDLIF3tQ704emsIcuzLX BOYcz9w7YgNuzZz9Lcg7m3G+t+BMb04u15xcrQX0LZ2e2KyvaYX81sTM1qxTiPMZGIF/jAKjse84 fGMcth5vYkE8a9oFdKOeAXrT1xe6/vANIuYOQc4HrOnHzgDW9z3Wuzd3lB6gG3eQBO4lXbifdONO kcydIpX7UTp3op5mMnOaSiyfDmbAM4Pn6fRNh3YafNPBDPSeBWZTn80cZzGXmeSe05nrNPLUacxv KnOdSi4+SxEBXQczB5rPyWvl/HjUvxd/hS3nMZ53tnQxcxXJ8KQBac8AvYzQ2Xerct58gw9/jQ3n o/NXPpp5zGE+bQtYs6+h+Rr72lJ47PfVbOGs2YJ/b2L/bMAP5Cxay5m0hrNpFXtgJWfVcvbDUuy8 BJ9YjE8sZI1+ZL/84HxgvsPO3/jlDuX5Q9qH0f8pdKM4+8bCNwH+yciZztk3C7lzOfvmmZ+dBXru beTc28we3oweos9W6lt8dZvvrcff1+Pn6/HfDfjvBs7Ejez/jezLTc4SpRX+jfBu4Oxcj2/LubnO WQ3WMpbwr/N/Jm0De8GTt0775Fxdp20bwSZkbPKXQms/K+Wdu+u1Tfq2QL/Zfx6v19LeH7bqeSzY Tvs2sIW5bQYe/Wbl3YT+m8FWdN8OhH4nNIJdvnKH/7Nnf0C/G/rfkLULnl/g2QG2QbNVsZPzfyft v9C/HbptnP9b4dnK+S85wCZ/LrRX84FN2iZ9e8CfQNr30iZ9Urf054h155z92iZ0Z33P0n7hP3W7 Zn9oHnFWc4tDxMajxLcTxMrTSuvRnyLeHdc85KA56BwmvziK/GPocxK9zxiRYee+j3ziL/KQvZwl e51L6HCR/vNK87vinOYtu7X9ErgMzRXmcQ16yV2u+e9hd6nfQ9Ydylv03dDfkLpJHnOTfEbyGslv JM+5iV43mIPH78m5SQ50izndhuY2tHeY/x3Ng66Bm/TdhuYufP9A/w98tpRxrX/kN9fJg66TD10l L7pCfnSJPOki+dJFaC8prfD8yzwc7btkskH3BPlTTuW9SQ4luO7fz+9oTiT5keRJki9J3iT5k+s+ Ry5Vg5yqqnmg+VUAuVZ5cq4y5q4pSQ5WlFyskE+eyC2kbXfIze6SmwntfXj+hfeBqaKyXHKzx3y5 WTbGepwxH2fs7OiQnZzrcfcdRTbVSep2LeubuvTXpr067UHkWmWB5HE5le4tRU76C4Cy+qa+AbT1 9feeXnKF3/plQ83p3qDtFW2X/jfMy+hRD7yKvPqu0Ng428S87TYl72uieeCb2ufRNOBZ2m3/2659 19ZIc0LJDZtA04i8saH2C/275I8NzbuaP75jmoPWmkc2hKcxEF4bPySnbERuKW0NFV2gT6NMBd01 57QxKj/PlUE17fdoGoA3TAr5aArtqW4hkJ8+obX2yMHzUyAHbfkVaW4+6HKAnL5SaCz9SCfdvQZu kdNmhz6H8qa695xU2tLckYp0P30sz3E8j1RIPY0csLsr7bG0SZ/Usz7HW5O8sYbmxZInJ5IvdyZv jid/jvXxdna60O7l0l2h6UYu3Y1cuqvySC5d07V3Z8mlO4BIpzyl5NZByKmCnKrIqa60wpOo+be0 VyLnDiI/DSQ/rQB9ecqylOVcK0tK+95NcvMY0JFcN5r8OYocW2g7knPHkL9L3h5HPhwDvDy+sNJL 3fpLF2gTkNkJ3k7weHm+l/fHKK/US4BSyCpNn9CWQ29BGb+vJuudQO4GZbRd+ruCbswhGaRST6Vf 6Px3f+QlK8pqn/dcxlcW1z6pZ9GX5X5Q7j905Xkur2Wa87SvXta1/0bXE7oe0PXwyZf+HiCDeoav XWjk7iF0Urf+35v59ua5l95nSruerLLcYcq6falLv/X/DL3TyN2mpLb31ftOSWjljlNc7zoZ2NKr l/DPpwe0PaHLUJTQ/h4gXe9EXp+UNg6nICOF/lS9G8kdSe5KcmcqpXTCl05bd/q7c+9JZb2TKZN4 lnuTLUWO//0RfKnwpWi/oKSO4bWX1j6p288RJHKPSuQ+1UXvX4WA3MXkTubRebzF9c6WpGMLXX7o 8+NnBfD7gr7Sq4s868+JyOiikHtcYe3rrCgMT1FQzPVoivvKUkovdbvnornbxTBWHPK9O18h/FXu gMX0Tmj5PXmFkS39BfRuGKe8eYDcDwVyV8yndfs3K2Gc23I3DOOsC+fcjOA8bef8y13QZX8+wf7L 6Xo65IVX6tlpc4kB96G7zf3gOjzCKzLOaRlOGaa44P/3ptbkCa31/nkOnOd+cUH7ha6N4ixtZ3z3 07PG0ktp41l7cpT25DJyXw0Hcn8NJV8JcU6B00ob6pPTlntdexAJXQe923qlyLD/ftWHfLg399YM 52vum99zp13InXOJSSG/TSLX7Up+mkgu1plcLp68LpY7XkfuxVHOX8g6qLJEZhS5VUfuzLHcH+O5 +3UmD0wkB+xKvpZEbppCHpxGTpxObtyDfDmDvLs3OX8fcv6+3HVFD7sn5H48zBnM3VjuUp9wpxrF 3Wo89+Mp3I9nKq3w9CefH8Q9ewg5/vvcwT4k7x/GPfsT7gUjfPdsuyc+oT4ceO3v6d1smN7BpfTq QmP/prwd84ly9poY5it37kTy5W7YI4Wcvzu5fk9078VdpQ869EOvgdwDh3Bv/IC7yceM/4nOoR86 DTZD0WkQ98P+3Ef6chfp7bvfp2PzVO7ASdikC3eFzuTlcdg52vmVtdrD+h0EB4zoYv+O7jnWtQ4+ I/f4uuRpr4P63Ovf4rkh7Y3xo6bQtMAfgvGNENamDWsUQX4rckReOHJDeZZ3Bi3pbw5dE+gbwfcO /G/hm28i63Vkvgxeov487bXxr+f+kxNX0vcFh0xl5FRBTlXkVMcXayLrGeiE1uOR55P0CY3QHgHC e8B/lwzCT+RdQxD3iIr6/mGP9gtdZeqVtX0T2Ogvhcf++0Agd4JAnqVN+gJBBZW5xe8DFZAbqNii ffbZK/f46/YcLc+alAPl2QNPK/0OP4+8CwnQtnX0r4JupZblKb36av99rzz3n6dBeX1Pss6UZS94 slfqO5Qy7I+y9JVVmq3+z8GUZ5897fwBdmh7WcUu+H4D0rfbCE0Ae1HopO7/JUVo5D1MeR9dWX3e baS9lK9P6ln0v/toPLqyoJy2SenVhcb+u1ox5lqMOZRA/5J6t91gSmMP733P70pfDr09nTfpHEtz fy4JT3HmLe+AivpkiCy798twzy/tTETedGjnIH8etN+AH6FbqrTCW4J6SdpK0lcKmtLQloGnrDOJ cccakWN1fdHJ0HdHz7AfqzuDGGsoPvIRdhuOfUYorfDIO6dAYkgl9nBN9u1z7OEXnd5G+F9Q9NK6 XdeXnZ7sjx7sjwxtF9qXgLyXqkdfPfpsKbT+X/xz0vSd1cv+PqmnG2l/iXpdRZr/c34tnDD2aBh7 tC17NJI92pE9GsceTTCvOV2Rkaz0IkPegzVwEokX8eZdJ4Z4EOV79xVhrBwp7b9dtNT3Y2Ha35x6 S4VHI3V7dsm7sxbIaa6y2uk7NelvrohgjLbEHenvACKNpW/xn3+7DyGWh+g7NnnXNtC0cvoSo3og JwW6RN/7uUhkxYJE6tLek36hGwT9h0D4P/Gfh21ZtwgQzhqGgTacA21Yx1B9h/eZ0gpPa55DaA+h PxT6NsTrcM6UCCAy/N9lSntvnjP0nd8448kfT30C58EEzriJJhmkUs8AvenL1PeAXin8WeeY/B1Z X86xAZxPg81g5wPOiWGcF59yboxSWuF5D70HoN8g/HEoc/wQ//wY+8g74hFOphE5Nk6OcjrTlmA+ c7qBHtonNCOpj6RtFH3SL3QjnU7+uv27ganQy3vGKfjoJHgm4msTnFQzHh8aiy+Nxu52jFFOF56T aE824/Cv8fjXRNZjEvtgCvtpKrClyLV59nTq0/X9ZW/jjdeHeh8zk3Fn+trtfOTd5lTGnKbvOdO1 T2hmUJ9Bm7z3nKb9QtfZR5vg5/fehXY2s5TOo50OZqD7bDCH+hz659D3uZad9f1p1vjy/jSGMeOQ 0Un7PPp46rG0daQ/GnnyjtWjldLui6lOG2wQ5nvvGqV9M5QnCrTnuS2Q/nDj0Vr6Nv49OFvf04ah QxttF9qZCmmP8Mcb771sJ+YRg34dtE9oZmk9RvWeyxrKu9sv/e96s74j2Z5rU024mWYizFSTaSab PmYY+JB6Buhueph0kwyiqIWbXiDThJn3wUfUhffhd8j+dUfmdJUdZqYoLTbRNq9dSks7jTGnIXm6 6hEBfSZlbyPt06lLae+hn5q+ZhQYY94zE8Ak6lOA0AjPZOg/VfT1772e9GWATP4bAAZTH6rz7Kt0 Qi9zHgr/APAeM82kzABSs/xS2ridhkW60yJtQpOutupppD2Nsruvbn2rB3ZIZ95iy+6mE0jWfuHp Qb0H7T3p78n8La2Udg5ixyFgkGmDfm10HaRf6HuBTOjfBx9RHw3GYu8Jfnt66zAVSPnwZywL6N/j yC9OdDZPgwCTCLqYQNMVdDNBJokyGXSnPR2a7qYU7SXoLwpdYegLgPw854U2j0kxuZldLmhzYbmc 2DEnds6t35Q91BRB02JYvKT52JTG44qBItQLgvzMIC99uc0H8LxvnoQ+OzPPxqoZZv+AWHifGHqX 8/g2uEn9BufBdfLs68775hox8xpn9lVi/RVi/lXi/FVi6hXi62Vi9GVygkvk6H/joX+Te192ZtM3 FxlfIWsBMr81d7iP3CWvv+8sNv+SW/zrLGfcFcYxq4xrVqPTapPDrGFua5nrWpPP/Mz815lCoIDZ jP6b6NsAzXrzBH3ZoDHQ/0t+c4985Ta4Qd5zAZylfor24+ROR6kfZpyDjLmfe9Ff6LCXe9if6LQb 3f4gt9njfE7bTPqmmn2cFweY30HOkcOcE0exx3Fi5kni+Gli9QXi1yVixFXi2Q3i121i0T3i133i 0X3ihGMi0T8Sm3fA9h1YxyjWM9oUNx1Zm1jWJs6UxVfFLx7e5zafqsh6B6mPdPX5SyL+ITyCBOqC RFMBP6lAfwC0AX5/6maEv6Lye3W7Xyrg3QEgCF8Lgrai8ghvMkhDVrr6okfXU2mlbs/uguqXXZhP V+bTjfkkoY+lFx9O4zmF+SX5fLkLfpgITwJrmGCE3+YVudjjufDfXPhxbvw5N/x50Csv/PnQJz/8 Qi98eajnpi0X8nNCJ76fQ3n7+HO40ma4KYOvl8TXi+PnRfDxQvh4HtNP6Tx6+UbyIbpfCkNTDNoS 8JSCt7Tum+GmnE+O1O3f7cieuMue+Id98oB9Ydg3jyHnceQ8wX7Kgaxc7K+8yMuve072nuzB4SpH ZMteLKT9QvcB83mfeQzF74ewFwfjz4PYBwPxnwH4UX98qp+5BW77y/7+HOMKEVv24TX243X89Dq5 9g326Q326030u4WeQi98Nyiv83yNvmvQXGUvX2UvXyEXuoycy8ixpci174QuOTPw85lgOn1TwWT6 J8A7DjljwEil9/ikPob6WDAenknEgSnmIrwXub9fRI6UItOu1z3uFvfYi3fZi3fYi7fYizeJF9e5 t0v8EFrhkThy1fmS9vnM5WvovmNuP8CzEN6F/lLkWd/KpjFlFbZcwXotAxJvFrF+Hp1HL89LsPVS sJz+lRqLJKZkU6zy26IwMaiwxqOfWb+1rJ/EqTWsu8StVUorPE9q21pfDPsZP5bYtZ51X49PiIx1 +MHPKkvq9tzLb7bQv0XbhC4/8U5inrQXMFu1T+r23YnEtRPglLOGWLeamCSxT2KgxMLVzGUN81iL Tj/jW+vMU8TNXGYjeluZm9FtIz64Hn3X4cNrVX9jhHcVMlYiayUyVyB7BWOsZKxVxME1jLtG4+px 7pontFz7n7+XWkBM/ZqY+i0x9Qfi6ULi6WLi6TKNwUd8MVlkHEPmIWx/gHXY54vJe7hr/oGM331y RJ7NUfbig3vwoz+J1bvxBy92L6BtHryfM9ZM5EwzQmfP91PktyeI28f0b9rkb9zk79GGcQ6M1Di/ V+P9NJ7HE+9H0j8MuqHQ94evN3NON2eI+af088Peu0wb5+9S3tK/04vBR2Px13hs1RlbJSq98J0j V7zI82Xar9LvnRcx2Lcjdo4GHbR8gCypi2zrE/9wT/tHx7J9kVr/R/8esIP2Sd36RHnfmVLOxBO/ YolpMcS2jsSgKPxKziI5k+Rsao8/tGfN2xG/2rNP2jN+pMoS+Q60T4CnoM1FmQfkQ0YBlRNN7O9I fI3Rs6yUjiVjJui5ZEvR5eHPo5ZwdR2RFock+WRkAiN0YfQk0JN6Ju39kD4QyUOR/CFUw6Eazgny CeUInsfQPh4Jk6GZQTmb5y/o+wpJX4K50H7O82wwg/o02qZzesxglJmcILNNqpnDKTKXk+YLsID6 d7T9SN8isAy65WAVPKuRsZqZrGGsNcx8LdnfWjK9n00IeyaYvdMCNGdvNQVN2E+NyFEagDfZX6+B etRfBi/R9wJ4Hrra+u0A68wzyKkBqiEzCAQyVgCowNjlQFmzknNjJTZeQbkMey9lLRcTPxaxlgtZ k59Yn+84Q77BB6eCycTPKfjXVNZyJj4zi7WczZ7+nLNqLmv9BbHgS2LUPNb2K/jms//ns74LiAvz wVfU59H+BTSfQz8H35iJb8zAzycQZychdzJypyBzGvFiBn4yC1lz0GMusuYiYw6YjRzBLOqzfL/U MUt/tSM3WXMO1u4JMxH5E5A/DnmjkDsSnx7BnhrBOJ8xh08Yczj1T2n/DL8cgR4jGXc0cxkD71jm Mg49xyNvIuNPYrzJ2GQKY00l3k7DTjPAFHx2Em0TGX8i/RPQaQK049FlPHMdB8YiZwzyRjEnGeMz xvqUsT9k7I/Q7SN0/BhbDqPvE8b/lPE/g34EfCPhH4Osscgdh/zxjDWB8Scy7gQwjvoY9BjHvhnH vpnAnpzAWo4HY6mPYU1H0z8K2pGs60j0HIGczyg/43kEOdUI/GKk/lJMJeiqwlcN/uqMUZM5P6OY Yp5l3s8y7+dALeq1aKtDXx3mX5sxa8NTBf0rsp8CyUUqkIuUIw8pw14rRQ5SnPyjKHsvP7lSfvK5 AuyMQuyIIuRjxdkhpeXeRZ4WxE2pEvu0KrlUdXKVmvA8C29tcpjnwYvIehnUQ25j0IQ8pyloxljN KVsoMkxL5Aez01qxy0LZxeHs/PYgktjSQRH3yO+GiIQvkhw0Sj8p3Zkyluc4/bR1pH5augt7tRtI 8pfCY/OnTqylxJVOxJg4dI1hHtHMqwMxKFJjUZKPVz4x7cWmDsw5mrnGMKc4bNcJ/s7Ys5PK+cRX H+Y/r7pozBqmbZ21LvhUyy4KiWvDtW71SmD/JYJO7KV49k0cPhzPOnZi/RLwlUR8oYtPVmfqnfCd ONY1lnWOgTZWeSQezod2/n/Kef4zMRHfSACdoe/Mvkxgzyaw3xM1dn5pPB3mY915YC7jzeF5FphO 33Rj+aW0eqdDmw6vxNQ0ZEmMTYEnmTG6wdMVn/T4hH8GzzNpn6XxOEXp58L3JZinpZUnZdZn2BfT 9xNjfEf7Au3zeBbA/x1yvBgudPbdUQJxuwuQWJ5MLJX4nmKWKI3QJlFPoq0bMb8b/V2JuwmKNf53 28HE7FYghLgdRtxuS8yOBHIedAJCKzydGCMWRPPcFoTRFwJdsJ4Vngwprc3e4nxoAN4hH2tI2Qg0 4axoyjnRHLTw0Qt/C9Cc8ZuCxrQ1or8heMd33ryl5UZffbP/37LkXKmkZ4ycNXLmrCM+rCc2bCAu yJkkZ5OcUXJWyZm1hbNri/F02+Q7vzZCs4F9vYH9vZ59LjJ+Zs+vZe+vRfYaYsEaxllNbFhDfFmj 51kQNFJaO5bUc2wV8UbOt9XENTnv1hCLPHqPT9pWEZtWQrOSM3AF9MK3HKwwIqMU7VLaPKkUfaX0 fFyhNGV4LsNZKWVZ2qUuNDaXz2G+5cz4hrj9PXH7R2LtQmLdIuLvYmLxEmLyMqUXvpI8F6OvCDQF 8b380OeBL6fyf+0vRaZ973aN8/caOaW0SZ+czTd4tu1SWt1vcKZe40y95qO5Qf0656u0X3cmap/U bY6XR89p79zOyXmdgz3wJHsgO/vucfbQY+ylB5z99zmz73H3uo2smz4ZntypnKvTONumc9bO0Dzh PnetB84czre5nMdzOQNF3jzO6K8422WcBZyvC5j314z99X/K+f4554E2Nzx5NIeYr/35KPPRlhd5 0m7z59vk2jeZ2x30uocu/6KHSyyQfONJxs/poxc+ySskv8hOnHiMmOEQP+4zj7vMR+TcQo6U17h3 3vTV7TrnhDeX5j3TkT+VOU5mvpPgneDn9XSYgg5TOdun6xgy1lPYUfKgXCCn4ktffa7/XXEeaPKg W27KXEo/V2nygHw856PPlkJr/80xD2Pk1vzIa/foZmuulJc+L3eaiaxZPrqZft78tOVTGo9Oci3h LwAK0leQdikL+epCb/ffA2zkclZk4yx5gpwgB+dKLuySh3l7v67n8RTQ56mMPZk5TWJNJmDD8dhm LPYfg53GmAf/+fec29yZbpKv3SFHu0eOJn1C43A2SW4n+dsdzac+we7DsbuUw/DFj5VP6va7IIow dlFQmPELol9+dMiLDrnJdXKix1Po8QR6PI78x5BvyIcc8iLJD0XOLdXjU80nZWzRwYU+G7lXdnhl LjmQlwu5eZAv8yzA2VSIMSVfLKo5o5QzffXp/r1aAL5C8BWGr4jml9OVpqi2TUTfCUZo7L8B5GDM XLTl1pxTck/JQScpjdDmB5Iv5gV5oM2t9GM1HxVe68e3yUNvaw76GfMdwbxHMZfRzMWjE/qneM6O HbLR75JjOOQH97HHPWx8F/678IucWz5ZUrfzuut8wPMH2iZ0Qn9Hyw8o39c+qdvvYSyo+a3MdTxz GIf+Y9F9DLqPRp9RmhM/jg6PoYNLfiN5s+TP9zWf/tAnV+R/zDp9rHo+wC+M0n+mc5C5PIEsmVcu xpB8PZ/aTOws6zDJV0721Sf433EWhqcgOhXS3HuC8fSdxHpNBGNZqzE8SzmaOYxSWqnbd0clNDcf T847ntg/DoxljT0aj2+c5vNFtH8i58VEzosJYLy/FBl2/fJhi7zMKb/m95Lnj4J3NLxjoBuntB7v WMYcxVgjoRmhub/cASy/lDmxp63bdy7VGbMGOlRHVkX6KoDy8JUAxaCz/CKvCLKfBgGME6R3ifGc 35PgneQvRZ61xXN6j5jqu1tM5ryfqP3VqdfQ5ylA+qaTE0wnN5hGXjHVV3p1kWHPidrwyHMdlSv1 KVqKXKlLv/VLaa/ta/PoRO5U391mmq8+2b/utdCrFvOphazaeueZbDwZU8lbpoBJjDsBjAPjtRSe BspfjnXqg636ssYDsNNA1mIwfjCUnOJ9cpEPsdtH2G2Y3p9qsnbPsl61fPKexZY1sG8V+ipCEwRt BXjKw+vdrwazHoOQK7+G2Zd1zdR7lh1TShvj5c5VUN9/p9HeQ/uEtoDpBXrQ1x0dU4ylk9LmuxX1 F0Az0bUXY6YxhxT8yaMRniJkysVoL8Wdpiw0FaAP0l8T7evPGZv47m3v6h1O7nJyp5O7ndzxBrEW A5n/AHygP/7Tz1Tm3lTRJ6cSbVXoq6Y0g7DLYGw0BN4hyBhq6oJ62ORN0ID74LugMfUmek8c4rsv DvXHUO++OJTcdyj3R7lHev3C0xjepqAZdm5O2VLxvr8UXuvH4WTlIdyMgvU7OpJAGv0ZSiO0wegb zBxa0hZMXytoWnNTkXtpBDercEW0385y34zW91ix3AvlziqIVhqhFZ629LUD7alH+u6nUf/fv6/t aCLcOCPlo/++VmiiAfpQb6uI1japZ/0dbDzPcdoWrhC5scZr9/qknvX3td6z0EhfmCJe26SeJTea 547aZuWLLl671yf1h+do/36hndPPRDr9TbQzwMQ6g0wnZ7BJdIaYbs5Q0wtkUu8L+tE+gP6BYADt /Tkz+nFm9OWs6MMZ38MZbbqDNM74FJBEvQNoT70dZ38E+UAYtG3gDWGsEKePae30AImmlRNHmUBb V5ABTaYJd/oa0e1R34mXjpxU1XMI+g5G70EmzhnIPPozbj943zNtqUcyVjTtsUojtEPhed+kK4b6 736DdG4DmddA8x71vtBngl7w9ABCKzw9mHcGZW/Qh7a+oB/9A6Ad5LORyBqMHJEndXvu9HDGmJ6g FzbpjT36khe9xznbnzN3gH5OZqjSi4z+avP36f8IPYbD8xm8I9BhFDoIPFlS2nMnnP629LVX248x HUEsuV886OyjFd7uII01SQFJ1DuASOrt4A9XyHqN1LrVvbUTa4JZp1a6XrJufXQdQ9GxDevqjS28 H7POQ2mXPqHpARKhj1N+kdPSifTXbc4q6xUOvax9KD4Q6qT4/KGzyRo7gXpXkK5+EgptmG+dhf/h vyG3utdxUk1NJ8lUd5JNZae7qQh/BVCG5zK0l0ZmGf1ebPke9gT6Ekwg41Z0OkEfb6owdnX9npIE 7NGFe1OyEZmP+kxITfprKE2aeZ551HS68dztP2WyPw4GOPJvuT1Up8qgCvpVg8+T0U11rgaqIKcy 7ZVARWgCQQD0gUBk2DtFKfQrBV9pnZfML9WU981X6AK1nkZbKvNNAcmmrM8OZbBDaXitDCmtb1XF BlVYh0qUQdgkAFTAJuX1c0WJaj+hF/6yyClP/Wn9LnixZQI6d0b/TsbKkTJrfTw71UGP2vA/B/+z 8Iq9a8BTjbE8Pik78yzt8t0xSaYWfLWZi8fvfZbQ1h/2B/veqpz+PWcvdO1jShJniuE/RYkZxRi/ tPoFZzEQuofX2L6zE57ioAR8JUEZZJXDH8s7vUEG/AIZIxO7ZEL7no5RXMeRz2gPUH6p2+9RLuLr 82jeA/2M1+bFetGvKPDaRJZ8X1WK8dqTtK+Y+oqno+hRXufSA/0E6eiShr4pPl6Pvzj2K057GZ9d yipfBuvXU/nL++2QZcsoHaOGUxu5teh/jnnXxJY19POm5CHMrwpxrCKxIJAYEcA9owKxrDzxoSzx rDQoRfwrScwoQfwpTmwqSpwq4ow3hR3uFM5kU8DhTkNbQeJZIeJRYeiLwFcUGUWJl8WQXYKYW5I4 W5oxyzJ2eXSowFoEgiD9LnjZG+no1R1/S0PP7kZ0fnhdbRyqirxqyHsG+z+LjFrIqM386ug80+Hv SXsv+jOZ53vQkl8x18r6GduBxuP39mIZzsVyoAL6BjL3IHSuTFwXGqGtRBnEs9inAn1PQ1NO7TOM +QzDPsP9pciycgtgm0KgKPYp5oxj/qOhGQntZ0on9CWxVQlsWxzbFqNfbFvAmaR8wl/Qmeqv2zOw CHoUYfzC8BeCvyD8BeDND29+XQtv3ILUC9JWiDUrzLhFGLcoPMXgLYYMWRuRVVjlefWseJfJfDOZ byZz7YOusodkLwyCb4jSCn95bFuBtQwEQbqeUnp1kZEVO3qwNumsjXyHairrnIZ9u2ssrci6iQ8I vfBVZt2qsH6eP6RD3525p5vavrW1sur4/SPL3+1n7lPJTVNAV3LpruTVXcivu5BnS/vDPmXt2pV8 PBGaRKUVHuEdbLqRNyepvA/gFwylPpSbwRDaB9E/EAyAtr+xMqTsxF3B1rO+f+YDsuShfjorT8p0 X5/UH56X9alf8I1fWNsd+MUOZ4bZTH0je3E9a/wzfrCG9V2Ff65kzy3V384caFZT/5l9vZ6+Tfr7 mqPNNnhE1qO+Y2s7sn9RTDU7nSlgEuMJJpvtPG93piFjOs/TjdDucGYqvdRtXFuBj6xEl9X4+lr8 bx06bsAnNyFjC/we33TkTOV5Eu3j6R8N3Qjoh8P3IXMZakSOtd8yYscS5iVt0ifPMk8pF+E7S3x1 ay/Rezt7bytyN+H/G9in65C7Bh9eiT9b/hX4tchbi75ip43osBl9t6LTDrX3JLXBw+vST8eRT9IP 41b4CTfIEazqGDxhHCs5Ba+ZZj42s7jdfk7vXPOZmWdGm6/BEqjWgR3U95qR5i/69kGzH0kHuAUf xAsOIeMwHngYDzuCzKN4zVFutMdMb5BhjnOrPc6t9gSedoRx9+KNvzPmTm52Wxl3A3JWg0U8/0D7 N8j7CnlzoZuFx06DRz6tKp9SnYS8ifjgBHxwAr49Hh8dxx6YAMbyPBJ8it9/ynjDjMz3Yd+x76nH ML8xZgFzngPVLLXDEOQPQmZf5PRhpr2ZaQYa9oCqjxnFvMYyv/HoNBE9pzP3mVB8wWjz6BV5nkwp 7R13NDYbw5zHYsOxassl2j9KsQS7rgM7qO8Fe4xH7/FI3d6t0tSGJ9HlBDqdQLfj6HQc2xxDn2Po fRT9j6DXEex4GK0PMa+D6HeA1d7PjPapPBljBLI/pT6ctmH0fQTNB9AOhWcwGAh/f+S8B/ogtzfI YIweoDtjpjO+6JOCPqKT1G1M/lDXcgPytiJvJ7J+R8c9rN1++A8rbbrOQXzkAOPtRudd8Hi+8DH8 IsP/W1DYuT8+MJA1GoRPDME3huIjH+ArH6rPrFaej6l/RNsH9L0PzRBoB7M+A5V3qr8UedYHuqn/ jMdnxJ/Er8S/JuknovvgD/189MLXn7a+9GVClwF9OnxpyjuOuDpW/dArbX28Px4kqn9ONN18/pqo 5QSTqJisfVK3PpPMqiWxQkmsWiLypK+rYhzjjVY/T2EVxdeT8VOh7+bjkbqVI77bHaSy0ilA+oQ+ BaRCm6b75BMwnL0yXP1ceHoCKR/+jI+9k+Rj/Hzo8QS8TyEjB8iFPrlBHu0b+cjvZsuLZ+eHV96X 5lWMhn6U8drHap/ULf0T6PSEvuMco3RPMqY8S3s2X5/Urf/l1/E9XXKofp8YK+NJ5v0UyEFfTqUZ 5Rt7pOrjvY/13uU+PHd75uQyM5Ax3WTXz8jIZ2Umm7tEk1vkRlL+Qxx/QDx29TMw8lkY+UzMNCN8 D9vE+vhtzp2bRIo75EH34P2XnNWB9zH8LjtjPQVvLv13pRkq6wnas9Hv4o8POKv+gU/GtnKktD5u +XIq3xR0mgTfBOSPN/eVb7T57/ie/hOY1yQdIztjyXytnFz6706z/fWHzxprp8LOj+Rf34F55G5z wXRysSnkZpPI0aZSzgCzWee5tM8DC5Re+B71uekS8BbHNkWQUwh5hVSuyP+Ouoz3I3K+U3lF6CvC GEUZq4Qj751lXMEElSF1a6P/8hZzvgZfQTMXmtlgBvnvVKUvpuN7uhejr6iOIWMt+D86FFIs9dcf tpH97fFBnAGDzffEqoXEtGVgI89biTe/EHt/Iwb9wV7cR6w5yH49xN49yj4/Qjw4bBJAPG2x9HUk jkYRXztAG0Vc7whiifFdQRKxNw2kmz/Z33+wr3eTA/xOjPsV7GSMbWATsW098W4NWEqsWwR+IPZ9 A+ZT/wJ95sA7Vf+ypC/+8B5r3w8/6E+c7W++ROf5RubzqLvQIOY0hLGGMtb75mewyjfnhbR/z7wX IONrZEhd2paBjTxvRYcdRvhtDpzMOSS2SMMGYpsM5t6bufZljv2Y2wDmJvTC1585ii0zdd57sMFf xLsDxMBD2OYIcgSePCmtT0RCF4ncKGg7MkYs9PGM11ntfwTbHvXxHWFNDhPDD7Emh8inhfaAiYE3 mvXogJwO1EVee54jfXU7l17o1wt901mbNPRPAbJmsaAjc4oCkT4ZIq8jiOW5K0iiLw2kQ9sTvt7M PRNZmSpzJ3ci799O3mNd+5BnZGL7TNZA+oSmL/W+tL3H2vc3a8Eafyk89hzpS17YjzXur77wA/WF 9C9VGo9nKbZeBH5gDb9RXxiAz4h/CK+N5RnEn57qP59rn/hTBs/Snu7rk7rd7+ITgzjLBzD2APWz 2fDN0L9cylTeKcrfG3/so+0z1U/7Ke089V1Pn6/Vv+z+s7l/tDPLxIPO7OUExRfU54EFJpb93A5E ON+aMBDifGNaERta0hdMfAh2viQ3+8KEwy9yHv4u/ERiQ6IzB1kyxkzTEUQzRiyIoz2espP2C4R2 rv/9ZazzPf3f0f4NOi0A8+j/Qmk6K76Adx6YD93X4BtkfmtiQKzie//9pgX8onMraELoa6Nzkrl9 r3RC3w5E0B8GQpHXWuc4Hywwll9Ke09uy1wiQBhza8M8QphDS+zREru0UF4Z7yswD1lf0j8XurnQ z8Fes01b+CKAJ2eGypK6fafm2WqmiaIvytfn0c9WG9p+KR/+twjr8/GMF8fYsegRw1yi0SmUsg06 hdEegQ3bQRMJopzPofvcCM+jvt8tGrvEIiNObT4PfEF9Lm1fIv8rdJExBF/7/z00hOdQeKQtWutf Mf58Y9ultHmL+EQUiESPdiBC7fUFdPOUTvjCqbdlvHa0R+rYcxl7rvpTLJDS7jXRL97X59F4+sar 78zVPqk/bD/72wE9ibs9iA89iKPpxIp0cvTuxNE0kEqcSabsBrpQ7wTiiK8xxLCOIIpYFApaUw+m PZj+ZshoSjxuiszmyG5ptphWZjN0m0wYiCDWR4Jo7gBxoBMxqStIIm6lgjTiTHezEj2WotMi9v2P xLFv2fvzwZfs/wXgJ+LCUp5X0rcWmo1G5vGo72BPRbfu6NaDmNmD+fVkrj3Ndvhk7lsZa5vOvbvO /Vd0+JX4LPMX7PbvsWDm2VrnvIe5S9z+kxj9J/P4g3nsVlrh6QTiGC+G52gQRX8bEEK9Fe0ix8aA JozfBF2aolNTdGjG2NLv0f2G/XbRtgNsV5s2pRSexsq3Tev233yTOW9TQBLoii07gThsGw0isXUE CMNWIaAVa9GSdWkmf4+CDJHbHHnB1FvTFkpfGIiALhJEwxMHOiGjK0hCZipI03XzShnfnquZrFUv xXzs/C32/gEbL8K+S6FdAc9qpRe+7qx5OmvZg1ygJzS9WPPe5jvWeIHx5MzTsjfniciUurWfrGEv 9OqNrExk9EF+X/yj7//hlfpP0CzleSX6rGWcjbr2GX6/yboDvK6yyzjyOcdS6FkCFKNeEOSHPx/I wxxygZxmOXnzcnLuZeTQS8m55e+QviW3/o7c+3ty+x9oX8idZBG0i8mnl3APWYqcZchbbgqDosgp rp+HXKWfrXzYj60+RuUvI7dfxnjLkenpkBvevKqb6Ci6is5r0H0N8lbr3x8UBPmhzQfywJsL5ETO UyprKTouQfYS9F1iZBxDu4wldRtr7nNu/MPcpE3o/vU9S/td4pat23cZdmz5rGcJxi3KmEV03svQ ZSk6L0H3xeixCD0WosdPzO1HtZnBdo7x5Incfx15/gGdyLOhzQ7Pk/DmQEYuZOVRmcuRvQKbylgr sekqbLrabwMpy/+n/qj3mgWdVeTza8j1fyb3X8/8N3IX2My5tZU7wnZTytkBdhL/t0CzyRR0NpgC zjqTH/rCzkKwWO8FhZwVRmQ96p5TWuVsQ+YWZG9ijA2Mtw65a5GxGv6VyGVN0aUQsougS1GfLsXR pQS6lHR+ATuMyPJ/ltbZxfNObSupkPovxmv/Vfuk7v9sE+PlQ35+5BdCj8LoUxS9isFbwkdb2jeO jCljF0WHIuhSCJ0LonMBZBRAhpWVT5+9999FsEkhkM9HY5+ltPdImWsh5loYmxXWO9ViP10hZxFj LAXL4fdsYkvhs+tXV2WV5AxfzDm8lHN2GVhpOkAXiQ3bM34ECEOHUNAavYNBC+rNQFNomjJ+M/ha wB/sLIFmMefyIs7lhZzLi+BfiKyFyF1kZJyH7z/tkBPJGFGsXzRjR6NzR2R1RFYU9KJTB8boQF+k 6rUavdZw3q/hvBf87H8n1oTnJsgS3VqoruvRZz26r2MO69DlZ6UXPplXKGjNc7DSrzXNlVdkeHKk tGdZmPMTc/qJuS0kf1tETrcY+iXQLFe6ZooVyFmGvKXIXYL8xYwrtlhkLL+UNheWOXbUOYqNfvLR LGKui3xz92xg6aR8OC+xPrwNPbYz/nbstA07bcNOWxTLzFb4dlAKzcN7y+qyjfluh34H/DtUznLo V4CVKseTKTQendTt2Jt1nLXaJnRbwFbaNivWap/Us8ZaTNsS1W0zY0jfVoXouJT2pUZotur3+C7R uh1rB3rt8PUL3Xad91Ij7b/Av8NXt/TbfXbZ4aPb5p/XcuR79e1+u2TZ1eZCkfC0R2576Nphi3AQ xvxCQQj1EMrW6N5SsZK6YBntS43wPmxv+znqCPjaqU+vAOLjMs4S2paB5fj3Cnx0ha9c5b+zeuMK VqOLYJX2C10YaOPTIVR1W+6rr/rP9/KsoW2Ntnm6rkLvVfislGv8OXoL9eXV2has/Su19NpXamlt 3Er1WaFtwSrXs01rtdMarQuN3fMd1DaL0Xsx+i+hf4narBX8rfx2XQ7vMrWN2EV4OlAKXwe/XbPW y87vd/b7r+AX4vIuZP3K+L/hf7+xx6XvUf9mtgP6X4jRvxKff1esg1+w3uxUbDBCsxNIuV2/p3iz 1q0dZLydwNL9iv12Aq99hfZJ3Y4p4+xG9u+qm+hpaVfDuxaso2296uLRWvoN/3MWf6MyQ5w85KV5 yY3zkRsXAcXIhYuTp5YgbytJflqK3LQMuVw5ctLy5KEBlBV5rkL7M6AWNM+Tz74IT13wMvJeAfWQ 8xpyX0fmG+Tcr5Obv272Ut9v3jSHwUnTwJwHl019c5O+G/Bch/86sq4h8xqyrzLGVVPdXDFVoatk LpkgUMH8jS4X0esCOp5H33PkI2fJS86Qn5whTznNfE6Rs5widzlJ/nOC/Oc4+c8x8pqj5DdHyHMO k+8cIo88SA50gPzqL3PL2WP+5hy+wNl8lvU4he3OYssL4BI2vwvuU39Au8EOj2GH7NjgSeafA3vl Yv5iz0f5TBHsURS7SJkf5IU2N8ij9V2076Jf1mAn5S7KXVoXev/nR8jny4GyjF+a8WWNijN+McYu iiyhFZ7ijFOC55LoVRqasuhZXtfQ45fS/71k0LwEXoCutm9dq+sab2StN7Dm65W+vNalbZOuf3Xo nwG1GP95+F9kPJFldX2TdX+TOdRTvxD/2Kr9QvcSeBkdXwH10PlV8Bp6vwb96+ovu4zll9K+P/B8 Zz9+JL60W/uE9jXqr9H2ujlA+2H1MWv3+uYWfnbTvIUPvYW/1McfpP8Nnx/W17bL1G9QCjx6Ke33 UxaDpiT+Vhq/K4f/VcAPA9UnL+ObV7CF+Kr47DVTR31YfFl8+gY6ebLqa/06c71G3zVormK3q/Bc gfeKqaGyLpnKyA/SMS5i8wv4+Xn24TnW9IwRPez3bdzHd/91DuHHh/HnI/jjUfL7Y/j5cXzyBD55 Ep+UfSD74TQ+J/tD9slZ/OScyhKZRUAh+gtAmw+ePCA3/DmR8xTynkRuduRn0zEO4fsHGVPG3m/u /+e7zk+xN04Ra84Q52QfXXZ+M9ec3eaOs894uu4399hnF4iF59hfp9lHp6EXvpPUT/nq9ty/r3tu LXtvLTw/sxd/1n7hOQv9BXCJ57vgH+pCb98H59W4to15bGUeW5jDZt2r2fBhF3928GehF74HyDP4 9WP0Pw7dE/DkgDeX7s0duketvLz+/Z3jf96VNcUHG5vfTSPzm2kI3sYvG+DT9cGb+Hd9eN8BDZH5 Lm1NoBGeR31G5Q3o3lBekbML3/0Vfk/2u4zTGN4m5g9k/K6yvHF3Me5OaGW8X+DdoWOLrNe13Kl1 u/c9/t3gN2TsQv42+LYpjfA1oHwbNKQuOjdCh8Y6nh33D9OCfdfUp4u1ic1bqhNTq7PmNYixNfHV Gs5Rno8w/iFwUL9Xsyr+UVXp9vzP+98azjH4joL98IqcPfD9Cf6C/oDKquEcNpZOSpuLVYGnCmNU VRyGx+sX+uoKT4eq0FVVXfb7vuvTq9t1raG6/QHNn7Tv1T6hr4be1Xiu7tNJ6GpSCm0N31z+6yf2 t8YqwBOg3/O530j9Uf/GK98FGqDfm7kHur+g30u5x/cdoX9on9QtfQDygkCg0guvPO/zlYe0T+qW XuQ+jdwsOm8caS/PWE/76g/Pw9o3ntgQS2yIAVHEhkjQjlgUTowIJUaHgQjicTtiRSRtUfR1hEZ4 hPfhedv7cqjZZ0LgDYe+rcoV+UfhPaZ88dTjaI8B0dBEgnbIj2CcMMZrA38opchp7ZMldfvuzMqI VRmHkXHIdIC3PTxtVe99Si8yRJ7IzZrDEfQQ3ixdpEwiXsb/n3nl/J/3Xfecc8S/88TDi+Bv8o1L 5rpz1VwBfzvXzHFwlPoh54o5QN8B6PZBv885Y/Y7p81B55Q57JyA5rg5gR+fwp/PgvPsgYvgMvUr tF+j/ya0t+GRMR91h7vOeDcY7xbj3dPfWzgPzhFPz4ILqudtcMO5jMwrRuhtTn5Q9bxqjqje14nD 1xn7mtII7RXwN/3HwVHqh5BxmNLySWn9SOYmc/yLsb35XtT5H/TRH1Z+zx4H0Gs/NPvR8YDPLvY+ /zd7+jw4gy1O6e9syO9tHFObHXROKq3wHKI8zPMx2k9gq1PQnAXnob8IRM5FIKX1yX907c5glzPY 6yQ2OWGuQnuZcTz6o9jgGM/HaT+BHYTmNLRnsONZXXexq8j5R5/PaP1hX7Fz6cjZ3JEcIYacIY7c IQZEmdv44C188ha+edO0BC3IG1pwnjfH/1pybrfiHA/lPA8DEbS3Bx0460Xeoz43HY/ceGTFMlYs +UmMjnuZ+t+UF8A59sh5cA05N1SXOHji4BHeBJ7jfXUbM1uofqKn6Htb+4Q+DIQioyUIVv0Ft5RW 6ln8x00z5tRc53ZF+4JV5hVwlucT9J80Ht0xpZW6PTtjdM7nmLvYQGwhNhHbnCYmnELWCR/vSeSd wm5niBNCcxbac/AIr6zBBZ27lSelZ0f3fz53TXR1j4LjJtA9Cy5QvwJuUb9vgtyWbpDb2g10QynD QYRbHTSg3gS0pR5DGUsZB9Lcp0EZN9U14F+TgpwU95pJdReBxSYRxLhLTDt3qQmlfJWyHqhL/UVQ hnp+d5nJ5q43edyN1H8xxd1dppT7G327TVmX08QVnR91X7lA/3lwFhpOVfcw9YOAkwK+QJ4DmW+Q ew5c0Pl69FJaGW8xX9eV+Xu2uKD9gdSDmE8Q7RXd3G5Ft6BbiblWcitQf0sR6P8NhAjq4W6A2xQ0 ov6WoiJtFd0wtWMgCFAaqdsY1RZbtsWmEWrbJvx/A1BdacJ0DaqDBtSbgLbUhbaja/mktO832rqd eJZ1idV2oQujDKctXPs6uVl//9Wd5zRtC1ek6Xp67V6f1O1eP2nS0CbNrUJbffCOm+4Gg1DqEYo0 6qm0pdGXBk0qvpGKvVLcp8DjbjI2TXbP4B8nFVm/a7JI/SVN26RvEVjs86GFtC1SpPrpl+BLi/Gp RfiW52ep+FIiiMGf2uFP4muhfrsswecW43vSJn1L1Q9fc7Pa6/l/x2MxfrnYvERbXW0XumWUy2hb qn1ev5Q2Diwzj9GXDfr8tJfRvqWKMvDld5fTJ/0eneuvv6L8pRzPVwPcPaac+vxvprT7qynp7jBF 3W2mkLvO5HLXmqfc1eYJd4V53LXjLed5Je1rTE76c7OH8uoe2gQPmRV7IFD3wD5FkK/u7SWJCfa7 KFzaHzOV3Gymivu4qQ6ecbODbKaWa0wd91/nBfee85J726nrXndedq84r7jnwVnqp8FJ2g87td2D zjOgunvIqcJzRfeoE+QedwLorwDd0+45p7z7N7jslHOvUt4Cd2i/B+5D46Cb6PLwv90+bmqqPtlV tyroVRF9A9AtCPpK1KWtOniG/me1zEb5uKKmm/X5QpFRU9ukL7uipivtT+oYXt3eFS869ZhrPfcG c73NPO8xzwfOi4z5PPy1XCvPmNrY6Hn6X4TuJWxUF76X3YuKev7fLzmEjQ5DdxR7HodO7HZK7Sj2 rKe0wnMenKXvNDgJ3QmlF7467hGnlitybOw6jI0PYeuD2PwAtj/gPKv9Ht0zoDpjVuG5IqjkWnop 7W9sPaZ2D8D+FZiHrIesi6yPrFM51qss61aO9SuHTuXR6Wld16NOoMoRuccoT/B8ivYzrOU5aG6B O9TvgfuOyA/UNbPjPeaP61m5hf137H+dytBXxd7V0akm/M8hpxb2re3exA7XsccVcAnbXABnqZ+m 7yQ0x7HBMXiOOTWoV0OvKuhVmf5K0FXEvkHMJ4h5BTK/QGQR58Ed+u6B+9DJ+I86c+4zxr/o8wD7 OqaGT0/hqUJZlbI6Mmq6/0DzD7pYeiltrnZGdRbdX2QOLzKXF9DjBeb2PHrUQY/aSi/8d+G9Tf0m bdfpuwQuQHeW8hywsqS0e+YYehxl/kfR8RgyjsN/En6hER7hFXud0nbprwlqYKtqrvC+qHJKODKv +2qXIPQIQo9A9BCbBWBDzkrq58BZ+k5DdxJ6sbfIEFmnqJ/BlmdpP0//LXCH+j3wD+2ezdjDjvzv /wHPCC6bYCEb8HQIAAAWh4gjy5XvodCxsyt55fRdch4AAMv5AACr+wAA3gUBAG0HAQAw30oAwOdI AEIIAAAA/nicrVkNbBTHFZ6Z3bXDj0jzVwKJoiKhllBwYlzj0PJTRRBbtQN2gQI1VhJjfGdscDGm BEojIlWiKUSGEKWRIgKSUZoflVDAbVMacI+oaqFqUmQI/oltTF3XWBgDxcS382b6Zn/OmNu117k7 692+9+btm++bnX3zbFMyhhBtzr2EpJBMoj4Gyjj2gXl2QGnjWWTcA+M11B4jE/D7myn3kvuJxA8h 96B9duADs9VYnzrWGRtrjTEr00THN9Xy6WQy2ssW5+c/SJ4tW1NVuamytPob+ZVb1lblV5ZtqB7n RI+3YghROfLJ0LyalXcQh4rULRwUf/zQK163keXDJBQKkY0LCdm7dy/5bZl1A9nhfO1wlB2OUV9f T+pb6sk7Z/qINPvIwYOH0L2DSBWGX9JRpGOoJdHR8x0ErnBmeq5X40Cvudl4jXqNNUg1pnmOXdDe N0P6CT0VdY4zIHr8VvPNpNSKiDLD4uPimEmZ40+xrsib2X6NqCyPYLaQ/r55QVP3PWg9sqGrTe9a 7UE0wMJcaungzmOjsuNdVLp17cPZ7Csl9i5SsV/X00FqYQ7MRfg1YnNyGdmYfmNqFqsH2BW4rruz Dc1Preu3qJRB0afpYZ5uDKJ38w3Fl26EeZo+Er6pKS6+DC1Z+CbSaTKNLpBeY9kGmL8wFnB3H+BO jtsH9vNWI+7zHo/XqYhvOd6dbWTx7SjrUQ+KaI5xw9xlLOQuw4etfGPJYvTPQb8a24K6souMMTyE UmnM4MtQlO01T9C5o2SavM9nNU7qYJr6Au7N24jtQJf/PzD+pJ7Fb6J06sH5H9FvmMyD/1/Rf0Rf yNXYNdSV3aCP4W0oXfoMfhZF2Ynwf4c8Lj8m3/fkP12jPKwt9OHvvnlGjP8cjJ+uzeXPoxSgHhTD o1q/uUHLieM/C/2Pol+NFaKu7Ke1CTwXZamWzp9CUXYi/Hcj/1of/ocZ5VeYH//45/9njD/M5vIO lPMsOP8DrN+8zuL516H/APrVWCvqyj7NJvB/olxg6fxPKMpOhH8py+Qtxhvcq/IP1la/OuXuALvi v4GZMnkps6uXqllBUbRor/MX9LoYCnWauCiMIZXePQ8e0X/Pi/XXecso5sjgJfr3+HB1VHG5s043 4x37zBbN+6Rz63QGX63ZdTqDtyTtHCnSe/hafcmw58gSMIwe/vEI+Gp4kW7jq4WipOFrkJQ3sZ/D nXNjBxSbW3VcE+8xrJhG+RI0s1ejFwK/Ez8g3CzQtoKdhWA9eREWk61QoP0qmgtBs2xggD3PNicL 5ZuNrVDFtsFmY1e0MjDTS7TX7NLDTpYblt5Jw9Clb492ikTevos8B15kuZ49WTPRoZw+lOL/Zvr3 YEbsqdrvykMp5VSHZmc/qF0QFCEjEdDobuG9awbfzTt35W6h0Qgw36rhdIQwRtq78hn5P5qsXTkL Z85k8XiH4stkEZhFR8I3TXPxZZFk4dtCfiJryE7P8yaPrYJX2Fvw1bqvH+PdeWwfvIyyCfWgiOax PKhhb8fqjHv6LEX/PPSrsZ+hruwXWAlUoFSznbASRdmJ7P9CXI0qn9WI0FUg6VvgzTv+9P0Xxkfo PriN0k2D8z9O8yDFg/8Z9B+nb1tjN1FXdhMtgcsoPXQnfIqi7ET4p5KN8jHyS0/+T5DVsJ4c9OEf 333Nx/gnyJuwFuVHqAfFMIUUQBWpjeM/G/1T0K/GnkNd2c+QMCxBWUF2wVwUZSfC/6rciL+5e/M/ KlfDNenHP/75/wXjj8o3oQulUQbnXysL4JaM5/8R+mvRr8Y6UFf232UYzqE0yV1wEkXZifBfJ/dA O+uDZHRffZhpD6yTdvVSNSsoinbSC2vpfWI03df9opT2Qvso5qiBMvrruG5muO4rS5TRa7zd54yL dTe4O+06XQMdSTtHimm2WEffG/YceU+MZdkiMgK+q1BMbXymKE4avou8ENrk52L47us5aMWYL/hF 0Sa7zaaBoNkXw0pYThqEnWW1pf8QGsRy8m9zSTRoliq5Crub806WIkv/qTwvtrJOszpwJ9gpcrDe fuJkyUP9tOgWn4ge+rnZ7fk7dtDMjQMHBCHefy1rgUJRISpSk9F9VaRWiELRAvZ+ULsgKEIKk6Qu LsvRdF8YLSZJCn5Vw0axQqRwe1fuJ7d9urvR78oMnHm2jMc7FN9sOUlmiJHwPU5cfE8NWzVG9dbI P8hr8lPP8yZXfihekdfFV+y+8O5c2S1eRqlCPSii+bJW7JG3Yk8g1n2hfz761dh21JVdLE+ICpRq 2SpWoSg7kf1/AlfjnM9qRMSHguBqBO6+MD6C7+WXKN0iOP86UStSPfifQX+duGWN3URd2Y3ihLiM 0iNaxWcoyk6Ef0j+Ub4kP/Pk/yQcExXQ78Pfo/vC+CehV5SgrEA9cPcF74pNEI3jn4X+KehXY8+j ruxsOCXyUVZCh5iHouxE+D+L/Et8+B/jx0Qf9+Pv0X1h/DHeK/6L0siD8z/E3xX9PJ7/R+g/hH41 1oG6sv/GT4lzKE28Q5xCUXYi/Mt5l2iXOTIZ3VeObJddopzb1UvVrMB/XYBFslSE5Gi6r7AMiUXy 0ijm6BRhcXXYOn939/WqDItF4hJ4n3Fune4UxWDX6U7RlrRzZI3YL8sFIXfnuxMfIePkfnl6BHxP yzXCxrcUsyYLX+PA70Q7TxtyKsR3X3Wijc8kXwykkXa+AJr7A3df0cNiGUx3shy19KXRb5Pl8F3I vx00yyZ+RGyTM5wsxy19C59Btsm5UB24E/yPeQDr7WQnS62lXzEnkx6RBt1fBn37hp9t8P+s7scr fqRnZ//39v/bwsMNYCEb8OkEAACGJd0P3Qll6R8dQkT+GpXoYBIAANP6AABy+wAAFQUBAPMEAQD4 mj8AQO46ALcEAAAA/nictZhrTBxVFMfPfczKLg+JiwuSWqs1mkgJELSIJbHWJsYEFEgxNTEp0KiL JBIW6vaDpDRqWmvkixo/GANtqrUfGh8hkZiq2w8kYowkFmpaJbRgIWkoAWlEdu7DOzt3La3DzKaM s9m5j3P2f3/3nLk3cxdBEICUq5sBFWBdhvpm45h5NmnVcvDB4I4QUbWNkKfuDwRuhztAqgsgS7XP JmPmncYSDWlbKGXDKaVC3Xd/qo9CsWrveqa+vgDq2vbGOro6XureVN8RfzFW39H2ane29s5J+QBY GvVwoy5J6V7nsDxpigOpz1r01ryW1SwjkEgkwCK3rl5969WVXt2wfBK/J+DTHxdAmgswMHBcdfdC 6mfqJnVF6oYVCqp6HlbAFt8jjnFqYofMoHGRONkWxah8ReYgJ9uf4jFY2/Y47FjD1mOWI2Y+iqx6 EhupGadJSxGC21TJsB0z0L0Y7Dxbtgjdj5m5IHtMWyEA+apUscG2L0lFugCXo4Bp1cKq1s7S6mk9 q1xQvlb5IJLyxmyim7K5KlpmNRImxTfrreajWCivJg++7/Fg0uZ7DT70ja/BRLiSnSRufCdJJUO4 wYOvBeKa7wnD4H7xzSf71egz1I1vhlayfjKfdOe7O/Dlis3XjKO+8W0wj5FGdtmV7zJtZMfIBo/4 vYznNV9RYL9vfBET4zA77prf4yTMMI548G017tX5jQL4xtdjlqEClue6PvJwAStDXut3t3pWbL4J /NEtrY9MmetYKznHrrjm/AqNiFaS68HcGvhJ7zlT6Fn/cs6CeJxFXXMeJePKK8Lc+b6CPZrva/qm b3x3sUJUx0KuOQ/hd3khOu+xpq/iq5pvC3T6ticCK0C1rAa58b2Aa9k1CR7x24VOa75rcNg3PsQq UZxNu/JNK49KhDz43oH3NN8beMI3vmrF1u255wzyabTikd8mI8Bsvoeg3ze+KnaUhPk+1/W7j4b5 UVLlEb9xvFfHr9qYvKX1kSnzojgv22S24xvSXHKn/MEcc53PGD0sd8oty+n5lDs/r6EivYeeXnnf t3gPm+3yOXbJle8SjUC7NP525+MrNTreT4V+9Y2vlkVpNp9y5ZtSHlFay9z5ao0PNN9f5Bvf9stJ s0Xm8ZgrX4z+DC3yHo/47U4O6fx2BUuFX3xzyXPU6x3ok6xGFkFzSXe+Udqn34H+oJ/9r+vpiBmW 97GEtE8PqeMPTp8eSIq5iJ6Rm1lYHjHXM47baWkE1ra1Ydu2ev+xGG1C+m9MrLNmYdYhcxFfJBtJ Fg0aneYvGWfuFMpnS2Q7sVXy2Wa8nTyNW8gS4WZHxioj8DmbxQlsq3zBtqIEfh5N4Fk8wAbFeqLX LIr5MjqBnWzfSdtmj1rMy+AEboIEXkY5vI9nOsIm2cVz0Tat0s0Pym14QDbgXBTlNRmrNItJXgKz yFaZ5N+KGfSbSKISGOcfs/VE4AyvFs1ySCtXi4gYQmViBDXLclHiqOykUsg7xQER1yqdooXHUZy/ hQ6INjHk+Hw7qfSxC2KYV2mVC2KUVaFp9iQa5mNiT8YqTaxChjnXT26FfJ1xeJsFUJiXyoGM15r7 aNf/TUlfTv7O+wv9zz5j/1fzDyZ906dgIRvwWQwAAJQGTasESXXmpW8kqug0O/wWGQAA/fsAAMP7 AAANBAEARgQBAOD8MQBAxzQAJwwAAAD+eJy1WAl0VUUSrer+WcgCCmpkDQNR1IiSkQgyMOBBcAkg ixjBFQkIiLKOiEHIgREDKhE0EgWECKiAQJQhR2QYWRRBWcYRJEQR3A7CBAdxZPtdVVP//f8TGF8g c47z/qlf/ar79at7q7u6+yHUArDPJAEkwS4IXTEqiWZTkIKhUpKZEn9BvNVSE6it/5fH1oG6IHoB xOs9BTcFkwNdAwmRugSvzng9pURsaZ4tAA30/o4ePXteBN2HDhw9YsyIwWOb9hwxbtDoniOGPjo2 MdI6yWsDEOqjJ5zdr/X6rfIj1DLg+YH6q877jlo6oSgbey2g6QKA5/OgU55AyUiA9Xmd4MCCPDh6 VMCDpVde5C8vUsiL3Kxfvx7Wf7keXv/4KEjwKCxYsEjNeeA9pX8SKUjkJtRfQC2tFUzI98xqOUwM dAmEyqdNjOdB9MmWiBCn2pkwPohYDYRjEqq7RJ9NDIQwn82h8TgMRFqGnrsGwwwlmChXtSpLaELv DL8LIkyE32Uh7BlUXmF7wBdNMPgDxQWGxP5/RkSP/3lE+Pt4iOIDQ2OjjGOYcRPGFXMm4yaKNvYs xrsGkgIfVMM4np9xU8m4OYPxynfFVTIeiXrEs3i4OPK+1AiDofvuo7vk1DmDwZtGDxgH0D/ScolX b2C+3s/T/h7V3wRThB1sGJ6tHG9RjeHXhl+NkOOpJOgzfszYQY9ALBCSOaZyCI39BuPsl3iBLccG F1R2EJom0WmRB+Fp4U2lagyh6eJNsapYhXwOj7tu6CS7Vm58FadWeajir4rTUF2cjtaQDmCyp2N1 /oS0qZwxfuMh+o5oLDQvmBC7Ic5rRWIR60W+KhYJUBX7kLcI4TE+WCXNZkBQkqkXDKJseJXug5P0 mEoB7KM5sFTlfiqG6fQGLKIVsI42q+zX8n54in6CbDoBj5PFImqG06kljlJ5ivqozsEu1E9tfXAR DcOlNAo/pkL8gJar7T2tW47xNA13u3txueuKO9wVuNpdjG+4WqoPw3L3HexwZbDWrYHVbg685gq0 /KTac+AN10t1N9itutx1VEEt+3H1oglxFYj3q5sbs9iG6qI8ao6t5DHRi8NR5dOftwc83q6BbHhM 1sEnslN7vBGn4jD8AadhffMXzDLf42RDuM+kmIb2AXO5XWiy7XYz2Z40m60NbLbb7CL9TbHTbI4d Ydva22yyvcyeNmxOmc9MnP3AfGFWmeVmrplhxprR5mZzr2lpMk0zk2zqmHL8BVfhPn3nTrwZV2Nd LMQKGIwboTUugsPQCVJxMLyHs2AG5sAATIMr8LAchI1SAK9IFLOuL2eMnTDmxGowX+JhrgVrYKWU wQb5Cf4uFv+lfR6Xr6EF7NeM+Q84JlvgkJyd96rPbaH4mLiFgag/urbVOAa9PX9awAGazUJBbs1d 5HmeJD9ykfybS9WnHNiqbXTcSj6MkclwvcyCXbwMZvM2GMwWb+YMrM/34m56DF/VsXkrFeFRN0rH YwaO0rHXyk2GGNcUDgW3y57gWNkWbCg7glv4q2AeHw925gbO0S1uLU1xE+kzN5wa0WgaSTNpFZXS ftpBzdkP8+9sPTBxQ6x/3eZz1E0xTweGWP95f+7YdfO4SoMKmsm3cX+eynfwbn6Ek2U2Z8hqle18 qezlH3ktl/BcPsgb+N+8V6WCd6qsUynhXbyYV3Ou1j/HH3ERH1Cp0DKrjflBLXfg7SoHuDOfVGHO UN1E7U04RupzYzlFV0oFNVeJUTnAUSy6r6lx3KNYyhVLG8UyVrFsUiyneDanKpZUxRKrWL5ULPPV 192K5WvF8nUEx1sq8xXLC4rlIa3PVSxT1eepag/heEjldi2nK5Z0tYcwZKitieoktScplljFclCx lCuWcsVSrlj8xvy5s+4hQeoE/agrzKLuGpvBKpPgU5quWXg69KGZMJFmQxHNg7epVGWnlnfCePoG suggDKdf4Fm6CCdSKg5SGU9dVd+FN1CW2rpqRr5PR/WD+DfNsu9SsdqWa10xOpeLW10vLHZtcaOr j0tcHM5xQVjivoBitxs2uq2w0i3V++nwkpuk5eFq7w1zXCfV7WCr6h3uGpUfZaur6UxfrKN+X8zS s9anUNTPHr/VrVOXqlxmE+B+luB8Dga/5kRXVxq7ftLevSRZbrt0dvGQ5TKhh8uGe51/Lw28XhJh C38bPMyngs0k0d0qKW6c9rRQ6roK1Y2hhbsVrnZPQGeXD8N88dU8u2Vh68B+U11df1u/ckelO/rK GZBQOZv9V/PzzZC63viK09HUkZ6iaZqT3qTHaTNNp720nHbSKcojv91LhdmDjWxspU968vhVhknw fLk08Cn9nebSK+Q3gxPO418zz786IHQlHadUOkIN6VvNnnupOfWhXLqdplB3KqBe2n8/WkgP0us0 QrWjm8lyRwrw9VTTGKwyPbwY+K0w5xt1TTw/k6EuD6MttILy6SQNp0z+Ew3lmfQMr9WVx/IC7s2P a+Z4XHPJUF7BPTRTXu2b+YfYkC8Z54x5dZw18HxJhNsVfwmPo01cSNt4FW3hvVTKFfQCH6OH+Xu6 jTdTBhdTOk/2jfGb9jDusSk1ivE39CyvpGzfLF3TGLfgdGrFzekGbkKduSl158upjB+jL/hJ+orz qZxn0af8iuKYR+t4Dl3FXSlNMTbjNr4x/q1t/jvsnWZcfK7vrrEbvmnHxV/iu2s833jK8ThpBfN1 l7IMjkg77IkD8AmcgG/ja/gjvo+NzAndOaaYfJNu1ptrjTMDdSdYqDvIbaad/dnk2ERbaJvbMvsW l9nneIXN43w7jrvZh7i2bcN7TBIfNgeoti2llvY5GmqH0xqbRotsa7fGNnKzbJzrYmPcLybFFZs/ uL5mvKtnPnQ/4F/dHN2D34OH3AV4IX0G7eltyKVCWEJTdaXtALtoowg9I214vJyVlXQH+d9Zyx99 bS/7xsBMN8x0d6vMLe5fqi+3/V1b67cfrcpy/lnwfGy38ti+BGrxKpPG75vWvM004V2mHe8zffmY uZ3fM7k82RTxI6aEB5q5KqO03Junmn5aHsu/Ny9xsupUcxvfos9NUFmqstGk83Lj/9YkD2UAPnT/ xHLl9Yjbq+ecz/HcnFU3i+70MFwJ6XxK2nFjXf86whTOglLOhv08EJrJSHhUJsE78iJ8Ja/DhbAF MuG4nkva4wjIxwmwG/OhGAvhT/gqZOICOApvQomes++DMiiCI7DT+/iQhNfqCaIb9sc/Yyp21nJd /ElblUAWFEA9GKB7+/Yq8SrbpTa8rDJagtJaKmQ/H5KH+Zica0acbyWrLoZR/Gm8UlrzZ9KPj8tE RijR/FrGDaChtIAhkgnLJAs+l4F6ap4BV0Mp9IKf4RHlYBIUYAH0xSJohi/Dd7AIXoViGAgrlKFN MFItL+o56QbM0dPTLCzT2TgBb8T7lY8teoZ6AJYpOfnwsdytqDNVUOUj+VBeUHlY3pZr5DUp4/ky iJf4nnn8Vp3zxXyXh3kIbKBjxvIM04izTAf+EnvzWBzEsfggr4N7+AmYyI/CHO4PK7k9rOeL4SM+ Ibqzkc/5qHyv5dPMUk9OS5Bj4QQ3BJR0SJFrIUOaQSeNVhvZL5fJRo1fkbSTd2SIHJQJckSek28U 31Z5WkrU9oxkyHA5zNlylfSV+2SE1hXJYpXV2uIdrSuU7jJGrtffpRIrF6kPzfUMliApEiedJUHu lFR5Uq6TuSqLpbkslGQpkJN8t+ziy2QDl/EH/Lzux+/R00e6PpekO/cKWsYf0gJdExbzdFrLS2iv rrYneQOlyCfUQzbQGCmlQllIJfIKfaoiWm4FK6kvzKNF8BSd1v3xH7Ev5WF7WoZNaC/+7MC86642 T7uRpr/bqvknzv7BZaoMsG1dgerNNsudsoNc/cBElx6Y59oGdrgOgePu94EGlBy4jr6w7anYDqTB diZdZ2u6mqTFrsFDsS9Xky+ip+qD0JHrYH++CXtwLtbjF/VU+rTu3+/CadQS51AyriL/L4A1Pbfv gfaMeCe3xSwejXX5WdxDE/E16o4zqCnOJ4HSGq+4ft8cq+ZySLfA8Hg/U1f1FPr+GP6WF/2KGf1u +eu2fuxWfTmNXn7tq+s77GdcxN/4yvkY5bF6P7Hyi/Zv7+ev+w77YyN+BSI6JqJjI19D/wNKiRFT AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A6APFJAAAAQDpAygAAACAFgAA 4BAAAOAQAACAFgAABQAAAAoAAAAiAQAALQEAAAEAAAAAAAABDwAJBBQEAAAAAAoEBAAAAGkAAAAP AMwPpAAAAAAAzQ8IAAAAAAAAAAEAADABAMMPGAAAAAEAAAAAAAAADQAAAAEAAABDAQAAALMSABAA ug8IAAAAQwBsAGkAcAAgALoPKAAAAE0AUwBfAEMAbABpAHAAQQByAHQAXwBHAGEAbABsAGUAcgB5 AC4AMgAwALoPLAAAAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBsAGkAcAAgAEcAYQBsAGwAZQByAHkA DwDMD6QAAAAAAM0PCAAAAAAAAAABEgAwAQDDDxgAAAABAAAAAAAAAA8AAAABAAAARgEAAACzEgAQ ALoPCAAAAEMAbABpAHAAIAC6DygAAABNAFMAXwBDAGwAaQBwAEEAcgB0AF8ARwBhAGwAbABlAHIA eQAuADIAMAC6DywAAABNAGkAYwByAG8AcwBvAGYAdAAgAEMAbABpAHAAIABHAGEAbABsAGUAcgB5 AA8AzA+kAAAAAADNDwgAAAAAAAAAAf8AMAEAww8YAAAAAQAAAAAAAAAWAAAAAQAAAEgBAAAAsxIA EAC6DwgAAABDAGwAaQBwACAAug8oAAAATQBTAF8AQwBsAGkAcABBAHIAdABfAEcAYQBsAGwAZQBy AHkALgAyADAAug8sAAAATQBpAGMAcgBvAHMAbwBmAHQAIABDAGwAaQBwACAARwBhAGwAbABlAHIA eQAPAMwPpAAAAAAAzQ8IAAAAAAAAAAEAADABAMMPGAAAAAEAAAAAAAAAFwAAAAEAAABJAQAAALMS ABAAug8IAAAAQwBsAGkAcAAgALoPKAAAAE0AUwBfAEMAbABpAHAAQQByAHQAXwBHAGEAbABsAGUA cgB5AC4AMgAwALoPLAAAAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBsAGkAcAAgAEcAYQBsAGwAZQBy AHkADwDMD6QAAAAAAM0PCAAAAAAAAAABAAAwAQDDDxgAAAABAAAAAAAAABgAAAABAAAASgEAAACz EgAQALoPCAAAAEMAbABpAHAAIAC6DygAAABNAFMAXwBDAGwAaQBwAEEAcgB0AF8ARwBhAGwAbABl AHIAeQAuADIAMAC6DywAAABNAGkAYwByAG8AcwBvAGYAdAAgAEMAbABpAHAAIABHAGEAbABsAGUA cgB5AA8AzA+kAAAAAADNDwgAAAAAAAAAAQAAMAEAww8YAAAAAQAAAAAAAAAZAAAAAQAAAE0BAAAA sxIAEAC6DwgAAABDAGwAaQBwACAAug8oAAAATQBTAF8AQwBsAGkAcABBAHIAdABfAEcAYQBsAGwA ZQByAHkALgAyADAAug8sAAAATQBpAGMAcgBvAHMAbwBmAHQAIABDAGwAaQBwACAARwBhAGwAbABl AHIAeQAPAPIDXgEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcPRAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAwLcSAMC3EgDMsxIA+NMDMPCzEgAIAAAA8LMSAH7UAzAA AAQAEAC3D0QAAABUAGEAaABvAG0AYQAAAGUAdwAgAFIAbwBtAGEAbgAAAMC3EgDAtxIAzLMSAPjT AzDwsxIACAAAAPCzEgB+1AMwAAAGIgAApA8IAAAAAAADAAEAHgAAAKUPCgAAAAAAASAAAAEAFAAA AKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEAC AAAAAAIAAAD//+8AgAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUA AGADYAMAAAAAAAUAAIAEgAQAAAAADwALBJoRAAAPAADwkhEAAAAABvCwDAAAAlgGAJUBAAA6AAAA CQAAAAAAAAAHAAAAAAAAAA8AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAwAAAAAAAAABwAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAKAAAAAAAAAAoAAAAFAAAADgAAAAAAAAAGAAAAAAAAAAoA AAAAAAAACgAAAAAAAAAKAAAAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAAAAAAoAAAAAAAAACgAA AAAAAAAKAAAAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAABAAAAAYAAAAAAAAAEQAAAAEAAAANAAAA AwAAAA0AAAADAAAABAAAAAAAAAAFAAAAAAAAAAYAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAYAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAA AAIAAAARAAAADgAAAAAAAAAEAAAAEwAAAAUAAAAAAAAAAwAAABQAAAAEAAAAAAAAAAQAAAAVAAAA BQAAABEAAAAEAAAAAAAAAAQAAAATAAAABAAAAAAAAAADAAAAAAAAAAUAAAC/AAHw5AEAAAIAB/Ak AAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAI4AAgAH8CQAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAjgACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAA AAAAAAAAAAAAAACOAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAI4A AgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAjgAyAAfwJAAAAAME7WSM KjamtMFj5AK5TKbAg/8A7xEAAAEAAAAAAAAAAACOADIAB/AkAAAAAwTkMWYkHOnPYUnVVep+v+YX /wC4WAAAAQAAAO8RAAAAAI4AMgAH8CQAAAADBHF660vUWwEQL21Z2JpJ1Rf/AJ71AAABAAAAp2oA AAAAjgAyAAfwJAAAAAMEFoeII8uV76HQsbMreeX0Xf8AfAgAAAEAAABFYAEAAACOADIAB/AkAAAA AwSGJd0P3Qll6R8dQkT+GpXo/wDxBAAAAQAAAMFoAQAAAI4AMgAH8CQAAAADBJQGTasESXXmpW8k qug0O/z/AGEMAAABAAAAsm0BAAAAjgBTBwvwvgIAAAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEB BAAACIIBAAABAIMB////AIQBAAABAIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAA AIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQB AAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BGAAe AMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkB AAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANYBAQAAANcBAgAAAP8BDAAO AAACAAAAAAECgICAAAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkC AAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAAD AIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8C AQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAA AMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANIC IE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAf AAQDAQAAAEADAwAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DEAA/ACAAGvEIAAAA ////AMyZAABAAB7xEAAAAP////8BAAAI//////cAABAfAPAPOAAAAAAA8wMUAAAALgEAAAQAAAAA AAAAEAAAgAAAAAAAAPMDFAAAAC8BAAAEAAAAAAAAABEAAIAAAAAADwDQB4sAAAAfAP8DFAAAAAIA AAQMAAAAAAAAAAAAAAAAAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAUQAAAGQAAABRAAAA ZAAAAPyzEgB+1AMw9LMSAAgAAACmFwAAWA4AAE79//+s////AQAAAHAA+wMIAAAAAAAAAHAIAABw APsDCAAAAAEAAABACwAAPwDZDwwAAAAAANoPBAAAAAAAJQBPANkPDAAAAAAA2g8EAAAAAAA9AA8A 8A8ODAAAAADzAxQAAABAAQAABAAAAAEAAAANAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8/AAAACUlQ U2VjL0lLRSBQdWJsaWMgS2V5IEVuY3J5cHRpb24gCUFnZ3Jlc3NpdmUgTW9kZSB2dWxuZXJhYmls aXR5AAChDxQAAABAAAAAAAAAAAAAQAAAAAAAAgAfAAAAqg8SAAAABgAAAAEAAAADADoAAAAAAAAA AADzAxQAAABFAQAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA9BAAAACUlQU2VjL0lL RSBQdWJsaWMgS2V5IEVuY3J5cHRpb24gCSBBZ2dyZXNzaXZlIAlNb2RlIHZ1bG5lcmFiaWxpdHkA AKEPKAAAAEIAAAAAAAAAAAAjAAAAAAACAB8ACwAAAAAAAgAgABQAAAAAAAIAHwAAAKoPEgAAAAYA AAABAAAAAwA8AAAAAAAAABAAnw8EAAAABwAAAAAAoA80AAAAHCBDAGgAZQBzAHMAIABHAHIAYQBu AGQAbQBhAHMAdABlAHIAHSAgAGEAdAB0AGEAYwBrAAAAoQ8cAAAAGwAAAAAAAAAAABoAAAAAAAIA FAABAAAAAAAAAAAA8wMUAAAASwEAAAQAAAABAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPQQAA AAlJUFNlYy9JS0UgUHVibGljIEtleSBFbmNyeXB0aW9uIAkJCUFnZ3Jlc3NpdmUgTW9kZSB2dWxu ZXJhYmlsaXR5AAChDygAAABCAAAAAAAAAAAAAQAAAAAAAgAfAEAAAAAAAAIAGAABAAAAAAACAB8A AACqDxoAAAABAAAAAAAAAAUAAAABAAAAAwA8AAAAAAAAAAAA8wMUAAAATAEAAAAAAAACAAAAEAEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPQQAAAAlJUFNlYy9JS0UgUHVibGljIEtleSBFbmNyeXB0aW9u IAkJCUFnZ3Jlc3NpdmUgTW9kZSB2dWxuZXJhYmlsaXR5AAChDxQAAABCAAAAAAAAAAAAQgAAAAAA AgAYAAAAqg8SAAAABgAAAAEAAAADADwAAAAAAAAAEACfDwQAAAABAAAAAACgD+wEAABIAEEAUwBI AF8AeAA9AHAAcgBmACgAUwBLAEUASQBEAHgAYwAsAEsARQB4AHwASwBFAGMAfABDAEsAWQAtAFgA fABDAEsAWQAtAFkAfABJAEQAeABjACkAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgAEgAQQBTAEgAXwBDAD0AcAByAGYAKABTAEsARQBJAEQAaQByACwAIABLAGUA aQB8AEsAZQByAHwAQwBLAFkALQBJAHwAQwBLAFkALQBSAHwASQBEAGkAcgApACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAcAByAGYAPQBIAE0AQQBDACAA bwByACAASwBlAHkAZQBkACAATQBBAEMAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIABLAEUAeAA9AGcAXgBEAEgAUAByAGkAdgBLAGUAeQBf AHgAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgAHgAPQBpACwAIAAgAHIAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAFMASwBFAEkARABpAHIAPQBwAHIAZgAoAEgAQQBTAEgAKABO AGkAfABOAHIAKQAsACAAQwBLAFkALQBJAHwAQwBLAFkALQBSACkADQBJAGYAIABDAGgAZQBhAHQA ZQByACAAaQBzAG4AGSB0ACAAYQBnAHIAZQBlAGQAIAB3AGkAdABoACAAYQBuAHkAIABzAGkAZABl ACwAIABhAHQAdABhAGMAawAgAHcAaQBsAGwAIABiAGUAIABzAHQAbwBwAHAAZQBkACAAaQBuACAA UABoAGEAcwBlACAAMgANAEkAZgAgAEMAaABlAGEAdABlAHIAIABpAHMAIABhAGcAcgBlAGUAZAAg AHcAaQB0AGgAIABJAG4AaQB0AGkAYQB0AG8AcgAoAGMAaABlAGEAdABlAHIAIABrAG4AbwB3AHMA IABEAEgAUAByAGkAdgBLAGUAeQBfAGkAKQAsACAAdABoAGUAeQAgAGMAYQBuACAAZgBhAGsAZQAg AFIAZQBzAHAAbwBuAGQAZQByAA0AQQB0AHQAYQBjAGsAIABpAHMAIABwAG8AcwBzAGkAYgBsAGUA IABpAG4AIABNAGEAaQBuACAAYQBuAGQAIABBAGcAZwByAGUAcwBzAGkAdgBlACAATQBvAGQAZQAA AKEPHAAAAHcCAAAAAAAAAAB2AgAAAAACABQAAQAAAAAAAAAAAKoPOgEAAAcAAAAAAAAAAwAAAAEA AAADAAEAAAAAAAAABwAAAAEAAAADAAEAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAAAwAAAAEAAAAD AA0AAAAAAAAABAAAAAEAAAADAB8AAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABwAAAAEAAAADAAYA AAAAAAAAAwAAAAEAAAADAA0AAAAAAAAABAAAAAEAAAADABoAAAAAAAAAAwAAAAEAAAADAEwAAAAA AAAAAwAAAAEAAAADAAMAAAAAAAAACQAAAAEAAAADAJoAAAAAAAAABwAAAAEAAAADAAEAAAAAAAAA AwAAAAEAAAADAAYAAAAAAAAAAgAAAAEAAAADAAEAAAAAAAAAAgAAAAEAAAADAIsAAAAAAAAACQAA AAEAAAADAEwAAAAAAAAAAADzAxQAAABOAQAABAAAAAIAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA9DAAAACUlQU2VjL0lLRSBQdWJsaWMgS2V5IEVuY3J5cHRpb24gCQkJIEFnZ3Jlc3NpdmUgCU1v ZGUgdnVsbmVyYWJpbGl0eQAAoQ8UAAAARAAAAAAAAAAAAEQAAAAAAAIAGAAAAKoPEgAAAAYAAAAB AAAAAwA+AAAAAAAAABAAnw8EAAAABwAAAAAAqA8dAQAASG93IHRvIHJlc29sdmUgcHJvYmxlbT8g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAJCQkJ ICAgIEluIHByb3RvY29sIGZpcnN0IGFuZCBzZWNvbmQgbWVzc2FnZSBhcHBseSBzaWduYXR1cmU6 CQkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxLiBTSUdOaShLRWkpIDIu IFNJR05yKEtFcikgICAgICAgICAgICAgICAgICAgICAgAAChDxQAAAAeAQAAAAAAAAAAHgEAAAAA AgAUAAAAqg90AAAAGAAAAAAAAAASAAAAAQAAAAAAmgAAAAAAAAABAAAAAQAAAAAAKgAAAAAAAAAF AAAAAQAAAAMAAQAAAAAAAAADAAAAAQAAAAMABQAAAAAAAAAFAAAAAQAAAAMAAQAAAAAAAAADAAAA AQAAAAMAGAAAAAAAAAABAAEEUAAAAAAAAAH///9/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABABIAAADqAwAAAAAPAPgD IQsAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAAZmYA////AE1NTQDM mQAAzJkAAIAAAADAwMAAlpaWAGAA8AcgAAAAmcz/AE1NTQAAAAAATU1NAJkAmQD/zAAA////AOrq 6gBgAPAHIAAAAMDAwAABAAAAwMDAAAEAAACWlpYAAAAAAP///wDq6uoAYADwByAAAAAAAGYA//8A AAAAAACZzAAAmcwAAP//AACZmf8AmTP/AGAA8AcgAAAA/2YAAP/MAACWlpYAAJkAAP/MAAAAmQAA ////AP+ZZgBgAPAHIAAAAP/MAAAAAAAAlpaWADNmAAAzZgAAzMwAAP///wD//68AYADwByAAAACZ zP8AAQAAAJaWlgBmZjMAZmYzAP/MAAD///8AzOz/AGAA8AcgAAAA/8wAAJkAzACWlpYA/zMAAP8z AAD/zAAA////AP//zAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAAAVQAAAAAAAAAAAEACAAAA AAIAAAD//+8AkAABAP///////yoAAAAAAwAAEACjD44AAAAFAP/9PwAFACIgAABkAAAAAAEAAGQA PAAAANgAAABAAgAAAAACAAAA///vAJAAAQD///////8eAAAAAAEAAIAlAAATICgA1AEgAQAAAgAa AKQ1AAABACIgAAAAAF8AIwDQAkACAAACABgAgDUAABMgSwAeAPADYAMAAAIAFACABQAAuwAQBYAE AAACABIAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///v AIAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAF AACABIAEAAAAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAA AP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAA AAAABQAAgASABAAAAABQAKMPUAAAAAUAAAABAQAABAAAAAAAAAABAAEJAAAEAAEAIAEAAAAAAgAB CQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDw4AAAABAAAA AAAAAAAAAgAwAHAAow8+AAAABQAAAAAAAAAAAAIAGgABAAAAAAAAAAIAFgACAAAAAAAAAAIAFAAD AAAAAAAAAAIAEgAEAAAAAAAAAAIAEACAAKMPPgAAAAUAAAAAAAAAAAACABUAAQAAAAAAAAACABQA AgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACAA8ADwAMBFsGAAAPAALwUwYAABAACPAI AAAACQAAAAzIBQAPAAPw5QUAAA8ABPAoAAAAAQAJ8BAAAAD/AQAAAAABAAEDAACoLvYAAgAK8AgA AAAAyAUABQAAAA8ABPBeAAAAQgAK8AgAAAACyAUAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAAgAEH AAAAgQEAAAAIgwEHAAAIjAFkAAAAvwEUABQAwAEBAAAI/wEAAAgAAAAQ8AgAAACQ+vADcBrgEA8A BPDGAAAAEgAK8AgAAAADyAUAAAoAAHMAC/AqAAAAfwABAAEAgAAE1IoAhwABAAAAgQEEAAAIvwEB ABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACAAUACQBRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQD+AA8A DfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciBUaXRsZSBTdHls ZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8DABAAASAArwCAAAAAXIBQAACgAA swAL8EIAAAB/AAEAAQCAAGTUigCBAQQAAAi/AQEAEQDAAQUAAAj/AQEACQAFAgz4AAAGAnDGAAAH AqgpAQAIAnDGAAA/AgAAAgAAABDwCAAAAKAFQALQFKAODwAR8BAAAAAAAMMLCAAAAAEAAAACAP4A DwAN8KYAAAAAAJ8PBAAAAAEAAAAAAKgPVAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5 bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbCANRm91cnRoIGxldmVsDUZpZnRoIGxldmVsDQAA og8kAAAAIQAAAAAADQAAAAEADQAAAAIADQAAAAMADAAAAAQAAQAAAAMAAACqDwoAAABVAAAAAQAA AAAADwAE8FIAAAASAArwCAAAAAjIBQAACgAAcwAL8CoAAACFAAIAAACHAAEAAACBAQUAAAi/ARAA EADAAQEAAAj/AQAACAC/AxAAEAAAABDwCAAAAAAAAADwAOAQDwAE8FIAAAASAArwCAAAAAnIBQAA CgAAcwAL8CoAAACFAAIAAACHAAEAAACBAQQAAAi/ARAAEADAAQEAAAj/AQAACAC/AxAAEAAAABDw CAAAAAAAAADwAKAFDwAE8NMAAAASAArwCAAAAArIBQAACgAAwwAL8EgAAAB/AAEAAQCAAMTUigCF AAIAAAC/AAAADwCBAQQAAAi/AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAA PwAAABDwCAAAAKAOEALABmAPDwAR8BAAAAAAAMMLCAAAAAIAAAAHAf4ADwAN8EMAAAAAAJ8PBAAA AAQAAAAAAKgPAQAAACoAAKEPGgAAAAIAAAAAAAAgAAAUAAIAAACAAAMAAAABAA4AAAD4DwQAAAAA AAAADwAE8NUAAAASAArwCAAAAAvIBQAACgAAwwAL8EgAAAB/AAEAAQCAACTVigCFAAIAAAC/AAAA DwCBAQQAAAi/AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAA AGAPEAIwCYAQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAv4ADwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgP AQAAACoAAKEPHAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEADgAAAPoPBAAAAAAAAAAPAATw 1QAAABIACvAIAAAADMgFAAAKAADDAAvwSAAAAH8AAQABAIAAhNWKAIUAAgAAAL8AAAAPAIEBBAAA CL8BCQAfAMABAQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAYA8wCeAN gBAPABHwEAAAAAAAwwsIAAAABAAAAAgC/gAPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAA oQ8cAAAAAgAAAAAAACgAAAIAFAACAAAAgAADAAAAAQAOAAAA2A8EAAAAAAAAAA8ABPBOAAAAEgAK 8AgAAAAByAUAAAwAAJMAC/A2AAAAgAEHAAAAgQEAAAAIgwEGAAAIkwGOn4sAlAHevWgAvwEeAB8A /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAACZzP8ATU1NAAAAAABNTU0AmQCZAP/MAAD///8A6urq ACAAug9sAAAASQBuAHQAcgBvAGQAdQBjAGkAbgBnACAAQQAgAFMAcABlAGEAawBlAHIAIAAtACAA RABhAGwAZQAgAEMAYQByAG4AZQBnAGkAZQAgAFQAcgBhAGkAbgBpAG4AZwAgACgAUgApAC4AcABv AHQADwDuA1wGAAACAO8DGAAAAAIAAAADBAcJCAAAABAAAIAAAAAAAAAAAA8ADAQMBgAADwAC8AQG AAAwAAjwCAAAAAkAAAAMzAUADwAD8JYFAAAPAATwKAAAAAEACfAQAAAABgAAAAQAAAAAAAAABgAA AAIACvAIAAAAAMwFAAUAAAAPAATwXgAAAEIACvAIAAAAAswFAAAKAACTAAvwNgAAAIUAAgAAAIcA AQAAAIABBwAAAIEBAAAACIMBBwAACIwBZAAAAL8BFAAUAMABAQAACP8BAAAIAAAAEPAIAAAAkPrw A3Aa4BAPAATwxgAAABIACvAIAAAAA8wFAAAKAABzAAvwKgAAAH8AAQABAIAAZOT+AIcAAQAAAIEB BAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAwANAAmAVkAYPABHwEAAAAAAAwwsIAAAAAAAA AAMA/gAPAA3wVAAAAAAAnw8EAAAABgAAAAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgVGl0 bGUgU3R5bGUAAKIPBgAAACEAAAAAAAAAqg8KAAAAIQAAAAEAAAAAAA8ABPDhAAAAEgAK8AgAAAAE zAUAAAoAALMAC/BCAAAAfwABAAEAgAAk5f4AgQEEAAAIvwEBABEAwAEFAAAI/wEBAAkABQIM+AAA BgJwxgAABwKoKQEACAJwxgAAPwICAAIAAAAQ8AgAAAAQCEACABJgDA8AEfAQAAAAAADDCwgAAAAB AAAABAD+AA8ADfBXAAAAAACfDwQAAAAFAAAAAACoDyMAAABDbGljayB0byBlZGl0IE1hc3RlciBz dWJ0aXRsZSBzdHlsZQAAog8GAAAAJAAAAAAAAACqDwoAAAAkAAAAAQAAAAAADwAE8FIAAAASAArw CAAAAAXMBQAACgAAcwAL8CoAAACFAAIAAACHAAEAAACBAQUAAAi/ARAAEADAAQEAAAj/AQAACAC/ AxAAEAAAABDwCAAAAAAAAADwAOAQDwAE8FIAAAASAArwCAAAAAbMBQAACgAAcwAL8CoAAACFAAIA AACHAAEAAACBAQQAAAi/ARAAEADAAQEAAAj/AQAACAC/AxAAEAAAABDwCAAAAAAAAADwAKAFDwAE 8NMAAAASAArwCAAAAArMBQAACgAAwwAL8EgAAAB/AAEAAQCAAITl/gCFAAIAAAC/AAAADwCBAQQA AAi/AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAKAOEALA BmAPDwAR8BAAAAAAAMMLCAAAAAIAAAAHAf4ADwAN8EMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoA AKEPGgAAAAIAAAAAAAAgAAAUAAIAAACAAAMAAAABAA4AAAD4DwQAAAAAAAAADwAE8NUAAAASAArw CAAAAAvMBQAACgAAwwAL8EgAAAB/AAEAAQCAAOTl/gCFAAIAAAC/AAAADwCBAQQAAAi/AQkAHwDA AQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAGAPEAIwCYAQDwAR8BAA AAAAAMMLCAAAAAMAAAAJAv4ADwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHAAAAAIA AAAAAAAoAAABABQAAgAAAIAAAwAAAAEADgAAAPoPBAAAAAAAAAAPAATw1QAAABIACvAIAAAADMwF AAAKAADDAAvwSAAAAH8AAQABAIAAROb+AIUAAgAAAL8AAAAPAIEBBAAACL8BCQAfAMABAQAACP8B BQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAYA8wCeANgBAPABHwEAAAAAAAwwsI AAAABAAAAAgC/gAPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACgA AAIAFAACAAAAgAADAAAAAQAOAAAA2A8EAAAAAAAAAA8ABPBOAAAAEgAK8AgAAAABzAUAAAwAAJMA C/A2AAAAgAEHAAAAgQEAAAAIgwEGAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAACZzP8ATU1NAAAAAABNTU0AmQCZAP/MAAD///8A6urqAA8A8AO+BQAAAQDxAwgA AAAQAACAAAAMMA8ADAR+BQAADwAC8HYFAABQAAjwCAAAAAcAAAANiAUADwAD8BQFAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAIgFAAUAAAAPAATwyQAAABIACvAIAAAA CIgFAAAKAACjAAvwPAAAAH8AAQABAIAApOn+AIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAAD AL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsIAAAAAAAAAAoC AAEPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAASAAAAEAFAACAAAA gAADAAAAAQAMAAAA+Q8EAAAAAAAAAA8ABPBeAAAAEgAK8AgAAAAJiAUAAAoAAFMAC/AeAAAAhwAB AAAAfwEAAAEAvwEBAAEA/wEIAAkAfwMQAD8AAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgA AAACAAAABQAAAQ8ABPAiAQAAEgAK8AgAAAAKiAUAAAoAAKMAC/A8AAAAfwABAAEAgAAE6v4AgQEE AAAIvwEJAB8AwAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAACwCkAC oA7QFA8AEfAQAAAAAADDCwgAAAADAAAABgIAAQ8ADfCeAAAAAACfDwQAAAACAAAAAACoD1IAAABD bGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwN Rm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAM AAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwywAAABIACvAIAAAAC4gFAAAKAACjAAvwPAAAAH8A AQABAIAAZOr+AIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/ AAAAEPAIAAAAAACQCeAQIAEPABHwEAAAAAAAwwsIAAAAAQAAAAcAAAEPAA3wRwAAAAAAnw8EAAAA BAAAAAAAqA8BAAAAKgAAoQ8eAAAAAgAAAAAAASgAAAEAAgAUAAIAAACAAAMAAAABAAwAAAD4DwQA AAAAAAAADwAE8M8AAAASAArwCAAAAAyIBQAACgAAswAL8EIAAAB/AAEAAQCAAMTq/gCHAAIAAACB AQQAAAi/AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAGAV AABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAgABDwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPAQAA ACoAAKEPHAAAAAIAAAAAAAEgAAABABQAAgAAAIAAAwAAAAEADAAAAPoPBAAAAAAAAAAPAATw0QAA ABIACvAIAAAADYgFAAAKAACzAAvwQgAAAH8AAQABAIAAJOv+AIcAAgAAAIEBBAAACL8BCQAfAMAB AQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAYBWQCeAQgBYPABHwEAAA AAAAwwsIAAAABQAAAAgCAAEPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8eAAAAAgAA AAAAASgAAAEAAgAUAAIAAACAAAMAAAABAAwAAADYDwQAAAAAAAAADwAE8EIAAAASAArwCAAAAAGI BQAADAAAcwAL8CoAAACBAQAAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwDJDxYEAAAPAAwE5gMAAA8A AvDeAwAAQAAI8AgAAAAFAAAABcAFAA8AA/B8AwAADwAE8CgAAAABAAnwEAAAAPX19fX19fX19fX1 9fX19fUCAArwCAAAAADABQAFAAAADwAE8McAAAASAArwCAAAAALABQAACgAAowAL8DwAAAB/AAEA AQCAACTo/gCBAQQAAAi/AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAA ABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAooADwAN8EMAAAAAAJ8PBAAAAAQA AAAAAKgPAQAAACoAAKEPGgAAAAIAAAAAAAAgAAAUAAIAAACAAAMAAAABAAwAAAD5DwQAAAAAAAAA DwAE8MkAAAASAArwCAAAAAPABQAACgAAowAL8DwAAAB/AAEAAQCAAITo/gCBAQQAAAi/AQkAHwDA AQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAAAAkAngECABDwAR8BAA AAAAAMMLCAAAAAEAAAAHAgABDwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHAAAAAIA AAAAAAAoAAACABQAAgAAAIAAAwAAAAEADAAAAPgPBAAAAAAAAAAPAATwzQAAABIACvAIAAAABMAF AAAKAACzAAvwQgAAAH8AAQABAIAA5Oj+AIcAAgAAAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8C AAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAAAgAA AAkCAAEPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8aAAAAAgAAAAAAACAAABQAAgAA AIAAAwAAAAEADAAAAPoPBAAAAAAAAAAPAATwzwAAABIACvAIAAAABcAFAAAKAACzAAvwQgAAAH8A AQABAIAAROn+AIcAAgAAAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAf AH8DEAA/AAAAEPAIAAAAYBWQCeAQgBYPABHwEAAAAAAAwwsIAAAAAwAAAAgCAAEPAA3wRQAAAAAA nw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACgAAAIAFAACAAAAgAADAAAAAQAMAAAA 2A8EAAAAAAAAAA8ABPBCAAAAEgAK8AgAAAABwAUAAAwAAHMAC/AqAAAAgQEAAAAIkwHevWgAlAGO n4sAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZADMz zADMzP8AsrKyAA8A7gP/AwAAAgDvAxgAAAAHAAAADQAAAAAAAAAQAACAAAAAAAcAAAAPAAwErwMA AA8AAvCnAwAAEAEI8AgAAAADAAAAAxAGAA8AA/A/AwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA /////wAAAAACAArwCAAAAAAQBgAFAAAADwAE8GwAAAASAArwCAAAAAIQBgAgAgAAQwAL8BgAAACA ALSBAAG/AQAAAQD/AQAAAQABAwPIBQAAABDwCAAAAIABQAJAFJADDwAR8BAAAAAAAMMLCAAAAAAA AAANAAABDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwkwIAABIACvAIAAAAAxAGAAAKAACjAAvwPAAA AIAAFIIAAb8AAgACAIEBBAAACL8BCAAeAMABAQAACP8BBAAOAD8CAAADAL8CAQAPAP8CFgAfAH8D EAA/AAAAEPAIAAAAXwXgATAV4QwPAA3wJwIAAAAAnw8EAAAABAAAAAAAqA8vAQAACUluaXRpYXRv ciAJCQkJICAgICBSZXNwb25kZXIgDSAgICAgICAgICAgCS0tLS0tLS0tLS0tICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSANSERSLCBT QSwgWyBIQVNIKDEpLF0gS0VpLCANPElEaT5QdWJrZXlfciwgPE5pPlB1YmtleV9yICAgICAtLS0t LT4gDQkJCSAgICAgICAgICAgIDwtLS0tLSAgIEhEUiwgU0EsIEtFciwgPElEcj5QdWJLZXlfaSwg DQkJCQkgICAgICAgICA8TnI+UHViS2V5X2ksIEhBU0hfUiANSERSLEhBU0hfSQkJICAgICAgICAg ICAtLS0tLT4gAAChDxgAAAAwAQAAAAAAYAAA2P/Y/zABAAAAAAIAFAAAAKoPvAAAAIoAAAAAAAAA AwAAAAEAAAADAAQAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADAAUAAAAAAAAAAgAA AAEAAAADAAEAAAAAAAAABgAAAAEAAAADADAAAAAAAAAAAwAAAAEAAAADAAMAAAAAAAAAAwAAAAEA AAADAAEAAAAAAAAABgAAAAEAAAADABMAAAAAAAAAAgAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAAD ACsAAAAAAAAADwAE8EgAAAASAArwCAAAAAEQBgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAJnM/wBNTU0AAAAAAE1NTQCZ AJkA/8wAAP///wDq6uoADwDuA1wEAAACAO8DGAAAAAgAAAANDhYAAAAAABAAAIAAAAAABwAAAA8A DAQMBAAADwAC8AQEAAAgAQjwCAAAAAgAAAANJAYADwAD8JwDAAAPAATwKAAAAAEACfAQAAAA+EeO AJzotAAAAAAATNiOAAIACvAIAAAAACQGAAUAAAAPAATwbAAAABIACvAIAAAAAiQGACACAABDAAvw GAAAAIAA1IIAAb8BAAABAP8BAAABAAEDA8gFAAAAEPAIAAAAgAFAAkAUYAMPABHwEAAAAAAAwwsI AAAAAAAAAA0AAAEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADJAYAIAIAAEMA C/AYAAAAgAA0gwABvwEAAAEA/wEAAAEAAQMFyAUAAAAQ8AgAAACwBOAB0AhACA8AEfAQAAAAAADD CwgAAAABAAAADgEAAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8HwAAACyBArwCAAAAAQkBgAwCgAA gwAL8DAAAAAEAAAAAACAAAAAAAAEQQcAAAALAQ0AAAA/AQAAAQC/AQEAAQD/AQEAAQABAwXIBQAA ABDwCAAAALAKEALwBvgODwAR8BwAAAAAAMELBAAAAA0AAAAAAMMLCAAAAAIAAAAWAQABDwAE8HgA AACyBArwCAAAAAYkBgAQCgAAowAL8DwAAAB/AAAAAQAEQQYAAAALAQ8AAAA/AQAAAQCBAQQAAAiD AQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgAABDwCAAAAOAKYA9wFD0PDwAR8AwAAAAAAMEL BAAAAA8AAAAPAATweAAAALIECvAIAAAACyQGABAKAACjAAvwPAAAAH8AAAABAARBCQAAAAsBFgAA AD8BAAABAIEBBAAACIMBAAAACL8BAAARAMABAQAACP8BAAAJAAECAgAACAAAEPAIAAAAcAigBXAI 4AoPABHwDAAAAAAAwQsEAAAAFgAAAA8ABPB4AAAAsgQK8AgAAAAMJAYAEAoAAKMAC/A8AAAAfwAA AAEABEEKAAAACwEXAAAAPwEAAAEAgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAI AAAQ8AgAAACABwAPgBPgCg8AEfAMAAAAAADBCwQAAAAXAAAADwAE8HgAAACyBArwCAAAAA0kBgAQ CgAAowAL8DwAAAB/AAAAAQAEQQgAAAALARgAAAA/AQAAAQCBAQQAAAiDAQAAAAi/AQAAEQDAAQEA AAj/AQAACQABAgIAAAgAABDwCAAAAIAEYAkQDtAIDwAR8AwAAAAAAMELBAAAABgAAAAPAATwSAAA ABIACvAIAAAAASQGAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8B AAAIAAQDCQAAAD8DAQABABAA8AcgAAAAmcz/AE1NTQAAAAAATU1NAJkAmQD/zAAA////AOrq6gAP AO4DsQUAAAIA7wMYAAAABwAAAA0AAAAAAAAAEAAAgAAAAAAHAAAADwAMBGEFAAAPAALwWQUAADAB CPAIAAAAAwAAAAQsBgAPAAPw8QQAAA8ABPAoAAAAAQAJ8BAAAAD/////AAAAAAAAAAAAAAAAAgAK 8AgAAAAALAYABQAAAA8ABPBsAAAAEgAK8AgAAAACLAYAIAIAAEMAC/AYAAAAgAB0ggABvwEAAAEA /wEAAAEAAQMDyAUAAAAQ8AgAAABgAEACQBTgAQ8AEfAQAAAAAADDCwgAAAAAAAAADQAAAQ8ADfAM AAAAAACeDwQAAAAAAAAADwAE8EUEAAASAArwCAAAAAQsBgAACgAAowAL8DwAAACAAJSDAAG/AAIA AgCBAQQAAAi/AQgAHgDAAQEAAAj/AQQADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAA ABACIAEgFvgPDwAN8NkDAAAAAJ8PBAAAAAQAAAAAAKgP9wEAAAlJbml0aWF0b3IgCQkJQ2hlYXRl cgkJCVJlc3BvbmRlciANICAgCS0tLS0tLS0tLS0tIAkJCS0tLS0tLS0tLS0tIAkJCS0tLS0tLS0t LS0tIA1IRFIsIFNBLCAgS0VpLCANPElEaT5QdWJrZXlfYywgDTxOaT5QdWJrZXlfYwkgLS0tLS0+ IAkgICAgICAgICAgIEhEUiwgU0EsICBLRWksDQkJCSAgICAgICAgICA8SURjPlB1YmtleV9yLCAN CQkJICAgICAgICAgICA8Tmk+UHVia2V5X3IgICAgIC0tLS0tPg0JCQkJIAkgICAgICAgIAkgICAg IEhEUiwgU0EsIEtFciwgDQkJCQkJCSAgICA8SURyPlB1YktleV9jLCANCQkJCSAgICAgICAgICAg ICAgICAgICAgICAgPC0tLS0tCSAgICA8TnI+UHViS2V5X2MsIEhBU0hfUg0JCQkgICAgICAgICBI RFIsIFNBLCAgS0VyLA0JCQkgICAgICAgIDxJRGM+UHVia2V5X2ksIA0JCSAgICAgICAgPC0tLS0t ICAgICAgIDxOcj5QdWJrZXlfaSwgSEFTSF9DIA1IRFIsSEFTSF9JCSAgICAgIC0tLS0tPiAgICAg ICAgICBIRFIsIEhBU0hfQyAgICAgLS0tLS0+AAChDxgAAAD4AQAAAAAAYAAA2P/Y//gBAAAAAAIA EgAAAKoPpgEAAFwAAAAAAAAAAwAAAAEAAAADAAQAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAA AAEAAAADAAYAAAAAAAAAAgAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADAB8AAAAAAAAABQAAAAEA AAADABAAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADABQAAAAAAAAAAgAAAAEAAAAD AAEAAAAAAAAABgAAAAEAAAADACsAAAAAAAAAAwAAAAEAAAADAAoAAAAAAAAAAgAAAAEAAAAAAAIA AAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADACwAAAAAAAAAAgAAAAEAAAADAAEAAAAA AAAABgAAAAEAAAADACEAAAAAAAAAAwAAAAEAAAADAAQAAAAAAAAABQAAAAEAAAAAAAEAAAAAAAAA AgAAAAEAAAAAAAIAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADAB0AAAAAAAAAAgAA AAEAAAADAAEAAAAAAAAABgAAAAEAAAADAEQAAAAAAAAADwAE8EgAAAASAArwCAAAAAEsBgAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAJnM/wBNTU0AAAAAAE1NTQCZAJkA/8wAAP///wDq6uoADwDuA9gBAAACAO8DGAAAAAEA AAANDgAAAAAAABAAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABAAQjwCAAAAAMAAAADNAYADwAD 8BgBAAAPAATwKAAAAAEACfAQAAAABAAAAA4AAAAAAAAAAAAAAAIACvAIAAAAADQGAAUAAAAPAATw bAAAABIACvAIAAAAAjQGACACAABDAAvwGAAAAIAAtIQAAb8BAAABAP8BAAABAAEDA8gFAAAAEPAI AAAAgAFAAkAUkAMPABHwEAAAAAAAwwsIAAAAAAAAAA0AAAEPAA3wDAAAAAAAng8EAAAAAAAAAA8A BPBsAAAAEgAK8AgAAAADNAYAIAIAAEMAC/AYAAAAgAAUhQABvwEAAAEA/wEAAAEAAQMFyAUAAAAQ 8AgAAAAQBUACYBVgDw8AEfAQAAAAAADDCwgAAAABAAAADgAAAQ8ADfAMAAAAAACeDwQAAAABAAAA DwAE8EgAAAASAArwCAAAAAE0BgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAJnM/wBNTU0AAAAAAE1NTQCZAJkA/8wAAP// /wDq6uoADwDuA1wCAAACAO8DGAAAAAgAAAANDhYAAAAAABAAAIAAAAAABwAAAA8ADAQMAgAADwAC 8AQCAABQAQjwCAAAAAQAAAAEPAYADwAD8JwBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAADwGAAUAAAAPAATwbAAAABIACvAIAAAAAjwGACACAABDAAvwGAAAAIAAVIQA Ab8BAAABAP8BAAABAAEDA8gFAAAAEPAIAAAAgAFAAkAUIAQPABHwEAAAAAAAwwsIAAAAAAAAAA0A AAEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADPAYAIAIAAEMAC/AYAAAAgAD0 gwABvwEAAAEA/wEAAAEAAQMFyAUAAAAQ8AgAAACgBUAC8AygDg8AEfAQAAAAAADDCwgAAAABAAAA DgEAAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8HwAAACyBArwCAAAAAQ8BgAwCgAAgwAL8DAAAAAE AAAAAACAAAAAAAAEQQsAAAALARkAAAA/AQAAAQC/AQEAAQD/AQEAAQABAwXIBQAAABDwCAAAAKAF Vw8ZFOAKDwAR8BwAAAAAAMELBAAAABkAAAAAAMMLCAAAAAIAAAAWAQABDwAE8EgAAAASAArwCAAA AAE8BgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAJnM/wBNTU0AAAAAAE1NTQCZAJkA/8wAAP///wDq6uoAEAARELFaAAAA wgAAeJzsnQe4lrWy75MsilQRC4jSRTpK711EmoWi0gRFUBBQEMG+bahYEESkC0jvvYiAIEjvfdFB qoAg2IAvyf1N1nqXbg/7sPR4z9n3Pgefv3m/ZGbSZiaT91vJt2njdQdHzsh2SP3hXxUVp5xPo1L9 Lk8nIvzLpJRJ/Oy891G2/99//0/9s8AlohXzlxLInKcG14A0IC1IB9KDDCAjuDZBBdR1IDO4HtwA bgQ3gSwgK7gZZAO3gFtBdpAD5AS5QG6QB+QFt4F84HaQHxQABUEhUBgUAUVBMXAHuBMUByVASVAK lAZlQFlQDpQHFUBFUAlUDrqtVFVQDVQHNUBNcBeoBe4GtcE9oA6oC+qB+qABuBfcB+4HD4CGoBFo DJqAB8FD4GHQFDQDzUEL0BI8kmgz7n926sO/hupp/uvGXNRSnUm7qhfUn/l3ExoTyTJh7uJC/pKE 4rt/Tzt90YqDasZiHShSJORpRv5p1Uk9w4g+pjr8qbrlX2a80O/7k1y+5xNTQ70dVVvmsiv/fxad ujPoVXL/ZVVGiw+UPiW3fun64TkJzzqx/uLUeq96lBlor7rzObn/sv2F/ss8vRYX1Z+gi3GJ7foz 9v/voL//+++/9k8zi3FpE3T3j7YrfrtB+zZdn3726XbdctXs2P6Z6l275ar9aMeObbu+EDx+g0at ErNbXSX7x/Izu/xeB+vYgfpcrIvujTL6gz+l1LpA9Y4dc9V8tFvbJ57u2r7tswVVixb1axRv0aRR w+It6tzbqHH1+vUbtWjQ6L7yZe9veF8Lkf9o124t7mvXrn2bti0aPNr58bbPPlWsR6d2YVni39S4 It2/25o52Zb0V/4V+HCk+TP0mf7YybJ/tZN/1z+Z98j2deLnxAFU2ZnL4izw4+dIGZ4gblsz8Q6p Qp/FU6Qz38ayxeQpvfkm1TupE/LGx0V5FS++k1o8ScxEcaPUU1Qn+JVLvxu7PIklOqQpdIZEipRR K5MojEqQmOCPIolxIU0F/1TS2+KasJpVs11UGdtVFSHNYzupm207dZ1todLae1UqW0mlsIVVnM2i jKVB9jvvY5u9jc33sdhwfznW01+KdQJN+FzVu1hhb2w2n9qm8xmt8jfZX11ukAVkBGlAanvKpbI7 XUq72KWwY1yc/cAZ2wM86bRtA1q4zPYhl8c2ciXsA66Wbexa2Waum23tetonXD/byQ21z7pR8Iyz z7vx9hU3wfZ0E20fN8kOA1PcZGRPtpvdFHvUTbUXwbV+mr3NT7cV/Ex7n59lH/dzbA8/z77nF9jB fpKd6D+zX/p+dp3vZff51+z3/gXrfFebQXWyt6onbUHV1pZWj9lqqrW9R7Wy96lHbCPV0jYGzVUz +5hqbNurelbGMxp5HxaahJFPEdJziTMg8/PHeVJXmCcTornb4m6QqMwK7mUeHmFe2quMzFcW+5zK bXswd8+FOaxuO6iqzGEZUATkhe4W20bdYJtBfy9zWkldE/BgkFtQWebnR5fTWne9TePT2pt9nC3E PFYNc/orc/szc/wTc/0Lc/4rc38x9h3zrlUslkUx38rHEtp2DXqSGj1JhZ6kQE/i7Gav7Xyv7HB0 pifohNwmfK6KjhTxqewtPp3N4DPbOH+zjbm89gJtkfSSy2d/AT+iA9K220Nbr1O/oisW/bHokUWf LHol7b8QkAVkBGlAavQsXUh/QseE7zKp8JYJsm5WrZxC12zsSReL9SD9AIxxPraY/J3o4Cn0UfhE zimXlrw06NQ16Gtq9DU1upcafU2FjJTopAlpa+poBW9r52IiO2p3A3S4PrgPfW5EWx9211mpX/ha M+7N6fNDlD0ITRPwYND5e9D9uvZeUuGN2t0Dve4OuqHvz7ixtoP7jLr7YzNvw/ecvR9baZAo52Ge H3HP2sfdW/Yp1xf6wfCOsC+60QEvJKYvI+dl5L2QKDvSjQ/9IuxjMXbyJfbyBXYzD/uZix3Nxp5m YVezsK9Z2NkMxmYGdjcD+5uOHU7HHqdil1OstFfqecWNIW8sZWOhGQvtOHjGwTsBGROQNQGZk5A9 mTqmUtc06pxB3bNow1z7TrDVufZD0t7YbNS2qK2N1aNW0AgQI2OjbbDVxxm3draQam+zq442o+rC Rq67PetfsQf8W3aD/9Au8gPsZP+5HUadIlPqGeDH2/F+sP3Cf2TX+J52j3/ZnvHPWes72/TIugW5 BainFD6gmmpBXc2psxl1N6UNv+Eh8h7GPzyEz5C23Rraml6JnQo6qQa2rXrItkROQvub2qbqQdtK PUB+nWDLgt97kN97jM1vlUvyGCmTPPvPoZYX1CeuvBvpGrqp7im3wL3pVrpBbqub7Pa5he6YW+3O uM3uW7fN7Xe73V53mPyTbg/Y7k649e64W+aOuvnuCPzfujGUD3eHXH930PVyB9yLUHeAqxm89Vy8 q+x2uZKgEMjF5xuQdA10MXvEncN+jmDH8da7TTa9X4Xdf22LMnfVGe+H/Ve2q19uP/Lr7TS/y870 x+xs/7Od51O7L31Wt9gXcEt8afe1r+aW+3vcN76hW+EfcSt9R7fKv+TW+A/dWj/crfMz3Xq/0m3w e8EPILVf77P7db6kX+Pv8St9S7/ct/fLfA+/1L/rv/KD/Jd+kp/rF/qpfq0f7Xf5Af5b38uf8i/7 c76LP+/b+R98M3/G3+uP+2p+v7/Db/VZkXTJLfC73BQ/y430H7kBvrP7yDdy79HCd31O977/FQ3d GlaWF9Cmdqw0DdHiKqw8BViBrkezLdZxAmzDQpZgIdPAcFauvuBtLFFWNFnZOoEnoXvCLcSCN9gu 7qh9yXn7jrvVyfz+89qS8j+sLX9cTSIvcsatc98x99+SxrvFbiOzvMwNcXMd66jr5Ia5xq6Pq+gG urLM/f1upmsP1eturRvgdkJxCI066Va4c24DerQjpD+gT+eQeQYNEtmR99uHHsW7U2jGYbRlF7yb nNQvfEdD7l606jD5x9GqMyE9hIQDPO8BwhutgsOhEIxBa6dCMR/OZVCvpyfb0dU9SNwXkMC73Z2m 7BQ0J6FlxJE9Bu0fDo0gGo+StFdQGQupB1cz2taBtr1I7b2Q1J82JtR9lOcj5H1L2SFoDkK7H559 8O5Dxt5E7HN3wncHMu5EXknkRp5qnZ3lV9vpfontg1/t6udjAwuwhcWsicuJndbZtH4H6+Ah+4P7 3h53l+xBlxpZ1zPyuZBVCFkJ7d3L8z7y9rkbGYs0tMmhVeftWXec9XOvNX6bzYi8W/0KWwybqw4e 9suocxUautlO9RvspJBusjN4nuXXJrYtGpdq2JigNDZXAPvLih2mdl/5n4iVjrG277JzvfRH5OxC zjF4f+FzajcP2gXwLIR3MTKWJKGmW+rvQlZNbFhkR+PS0q/ygnuwxpJ+A7a7CRvejC1vxaa3Yttb sfHN2PombH4jtr8BH7AOX7AWn4CNu9U+ob1LeF5K3teULYNmObQr4FkJ7ypkrEbWamSuRvZq6lhN XauocwV1L6MNS5LQGl/xKH6jdfAfq3ykh3v8YC/Y4Mf5xX6mn+wX8Okr/Ir4l2/wMwn0IqM9+T38 Isq+9AP9PD8R+gX8f5Uf6bf7TwIiuYd9US845avgexr4n3xT/wt+6Eff1Z/1r+KH3g/1Cs8B/w6f X/Sn/TP4qHaguT/p78OH1fC7ffGASG5vX9UJ+jEqQ3wnN8b3djMYicV+J6N30e30WUK9wrPR30wv Lru5Pt5N8LPdMN8Hvqfxa43d2756QGTbsiL3RoP74e8+wu99iP+TeoTmTZ7fIa8XZW/7hWG1lvRt Iole8H2QyBvN/wuJEYlECm8TIfQFw8E0ooQlYBs+8QSw4HoihQJEClVYtRviT9sRKbyQGClIPS9g We2opyH+twp5BYhYrqfcEq2cANuIVJaAaWA40Upf8PbvIpYIz+GLu1F3d9okbYvsQnyj4E2X3fVw Co95DB+9kUhsIdHWFNsxsS8iozPo6Kbhvxfap916ZB6x/8BS33e3BP/6Gyq4T/EiHwOR/a9W/bNn z15h1Y9adsAN1TvdZ3qTG6ZXuUF6qftEf+k+0nNcLz3DvaWnudf0RNdDj3Ed9CjXQk9w95NXX891 dfRXrjY8tfVmnve4e/W3ron+zj2iL7iu4C192n2sRf6fXXUiLZzlXtWCOe4NPd+9rRe7D/Ry11ev cf2pcxDtHqz3uYH6kBvB8+d6oxupV9CPxW4A9B/rmdBPgW8S/IIonprsGmnBuNCf9nqqey7UIzRj 3Qt6pHtKD6dsrGsQELXnmGutBQfdwzreNWTMGtD/eoxDPT2P5xmMjcgVninuHtpdi7Ka0NTUW3je 5+rC31B/j2xB1B7pg+Ak437WvQmeDfUIzS+uC+hJXv/QT8G/mumFY6ZcYaYje5ntyjEqZfRCV0ov cSX1N64EI1mcUSuut4O9fD5C2WnoLrjK+hKt9rQ4hX9AX+Mf0mn9Izqdb6vT+6dJXySvp47zH+nL jPZZZllmWmZcZl40QDRBNEI0QzRENEU0RjRHNEg0aQLPE10NZqCSlvb9VU3ZS78E211p+lOGfpWm f2XQ5rJ6EXIXuArUWwmNKEVaAg2/k7bcAU0xaIvCUwTeosgoFhDJTeVbaUEK31Qr34i+1mc27tbn XDX6V4n+ldMJdRfTR5H5PfJ/pi5LeZy/hzG6j/FqojP6lgGR1cksHmDGz4KLrh/j/CF1vKVTM66p Gd/UjLPUKzzX8nwdeddSlt6/TVlf5A+BV2SMCJojKREHYz2UdFCQHWlXpG1/1KQraZwgauMU5ic5 mpwcixiTmE5wjZGZ8FlkR22UuRHMcFXRhZrUWUdL/WMC6kBbHessH+ZP8Ocs4O5QS24lGiyaLBot mi0aLpouGi+aLxaw3xXQh10ufcLdzCxfr391GZn5tIz6NTqDT62z+DQ6t8+oC/sbdSmfXVfyt+sa /g59ty8LKusqoJSvRvld0NXRN6MBmdGADL5ZsKC/GoEfom3J0bLkaOvOIKsMM1Za7+I5HksQ2VFd GXw6LbjGp9eavl5ymfV5l0Wfcrcy23kYn4Ja2iNydrv8jFkO2nUT7bqWdqVlbFPRjhTIiEtCJj5f x/hlYixFdlTX3b4841cJlGPsiuvyvqAu7nPpAj6rzukz65t8Bp3Qnjid1afUeeEvRn5Zn01X9XkZ 86K6ri8DqvBcPaT3kNYCNX3VIDuqK2F8WjIPD2FNDZFdnzpq6YLMV0noqtCWuwOq81xdl2YOizK+ eT2aCv2N/mHaL5bcKtE6WzHuj+k0ILVvHWT/UTN//1l0cUVoy6Pqkn7dON3JaPMQqGG8vtP8pAuZ M/o2c1TnMvv1rWaXzmq26hvMBp3JrNbpzRKtzQJ9QX+pj+nVeq9epnfrRXqHnq836tl6pZ6pvwLz 9Fw9g/wpepYeoyfrAXqSfpfy1/Q0/ZKeqJ/V43R70Jrnh6B/QC/R9+rtpJv1PXqtrqSX6yJ6ob4V nvRIcWqc/lGN1t+r4WCQPqP6gnfAK/q06gLagodBdVAAXAcuqTPqGNiuzqpV6pxaos7znFafUiWR +KS+lhZk09/pHPoOc7PuYtLqKSYTyKonmzx6kikGKuqJpq6eYJrp8aaDHmee12NNTz3G9NOjzQg9 ykzRI80XeoRZroebjfozs10PM7vBAT3UHNFDzAk92JwC3+tB5hy4oD8xP+uPzK/6XSPjf+W5+o82 GEWv2hQxceZOk5L5Ssm8GdOJOXwDma8hr5Ox+iFQw1xmLq0uFdKYLsrcFoG2aOCNVpZ1Oo0RbNYZ zA59He2+wRxkvo8z72eZ/1/07UbqEzkXdDH6UcB8i27spWwHNJt0FrNWX29W6GsDojau1jv1Gn0Q TTihF6Mry7XXUo/QLNRxZi558/QRvUrvQocOhXStjtfr9R6wP/BG9rJYT0DGDP0FmjAXLZuL1Pl6 BbqxHp3Zqr9B96Q+kbMU3gXImY0WTUfqVGinwjGL/y9EzkLkSPoVWrcUrVyKNorsqN1z9cvwEm/q XvB/CufnenEi33Q9nv8GojHvQPMyOvtWSOfpV2jPa6RvBt6o3fH6fr1NN6GNjai/CS1oig20BsR6 ugv8z+u5iXIm61f1WP2cHkXZKGjGQj9DN4C3Dr1rQG8ahjRe3wca0tvGQXZU12j9nRqPvk/S59UM HVPzdVp4szEChbDKCtjV3VraI3LW67pYaRXKi9HuHPQrIz1U1PuzGqHPIet8SEdgW6OQOzZRdlTX w/p4QFvQBbwC3tEnsMcT2OVJ7PO70B6RMxwM0j9Qdh6a89D+AM8P8P6AjN/QRJ9VjamjCfwiO2nu 1c/qK/U9tnsauz2FLZ/Epk9g28ex8ePY+vHE9vzA8w/k/UDZD9Cch/YHeC7A+6NaipyvkSPpYvWT Wkj+IvyByI7qSqtnmFTY/Y34gZvxBzfhF9Ix45dUe2oopTer9Hpxopx4dQ0tLqGNfkJfz2zlgDYv PNnhzain4kcmhDQ9MtOA1HpakB3V1QG/ImhGXl38TUVoi+np+Jzp+J7p+KAZJm3ABJ4nkDeesrHQ jIV2LDxj4B2NjFFJ6MTnzvinTvgrkR3VtVF/bgTLofkCminwjoCuHzJ7Ivv5RHqR8Tx0PfFn/fBn I/BnU/BjX+DHluPHNuLDImzh81Z83RZoRXZU14/kn4Pne3CK8hPgKHIOIG83tNsT6UXGdnzhbnBA D8SnDID2U3g+hbc/Mvqb0+RJeoG8H4PfHBpkR9Ga+DyH/4zpXvi9PvgqoRsS+M7qj8153ZvP7+AX Xw++8WprYi4tcnur/443uq39Ht8MNAb3gbp+r78b1ATVQGVQ0Z8Al8C1qrK/XVXz+VRtcJ+/TTUD T/i8qgd41+dRQ8EMsBIcABfB9SqPugPUB+3Bk+xTnkTb26vKoJpqpaqyK6uq7gX38PkuVZP/11ZV VANVSTVRhVQjdYtqrDKph4lsH1FGtVXed1LOdyf9h/oBHPJvqC3+bbXcf6i+8J+qmX6kmu6nqNn+ SzXBf6WG+W9UX79BvePj1Wv+hPqHv6jeJpb7lHi1DzFWL+KmN3wJ/RJx63PETE8T63Tw9XQ7YuM2 xDutfF3d3NfWD5HfyNfQ9xEjJcRYlUOsKzGvxL4SA0ssLDGxxMYSI2t/Wf3kTquTbjc7s5Vqk5ul lrlhap57V010XdUw11L1cXXUW66M6uHyqQ4ui2rp0qv7XQpV0ylV0Xlfwjmf31l/q4v5TO6Sj3MX /U/2V3/C/uL32hN+m93uN9ql4VuA5K7j/xNvKZuic/8ubykfDW35j28ps4W2plOt/Q7fApuQNkv5 4zy39gdD2sbv5/kA9PsDTTSW5Xmu7HdiOzuxoZ3Y0k5sahe2tRMb24Gt7fCtAw7yfJC8g5QdgOYg tIfgOQTvIWQc8tX9vpBWoLw8dljBxwfZUYxQxReivttVWeyyDPZZFjuV+oWvKs/VyKtKWXVoKmGH 1YPtFsSGC6kKpMIbzUtblRtbzI+N5sdW82Oz+bHd/Nhwfmw5PzadH9vOj43nx9YLYPMFsP2C+ICC +IKCQa60R+qp5nOTl5uynNDkhDYHPDngzY6M7MjKjszsyM5OHdmpKzt1Zqfu7LQhu+qk8oa0o8qp OuMvOqp8oW1Rv9vjFdriIdriP9qgxW3wJ9J+4evEcyfyOlHWCZr2eBNJO+JT5LkdqfBG81VJPaDK 4WMqUHslVUtVD56nEr6oImNTAd9UIdQnvK3Ag+BeZNQhrc1O+i6eapBTDRmVVNOQVsVPyXN5UpEd 1eX9S+qyf40+dyftiP9qgy02Vxnxbbeo+/Fz94b2CG8heG8BmVULlVY9qlKpJ1QcoxGnuoNXkfVm SI16HelvKstnkR3VNcvPw/8tUpPxgVP9CDXX91Nf+15qM37yoH8Vn/lSaI/I+QEcxndu9e+pFb6v WugHQf85vnOKmu+/UHPwn5LO9wvJ/wrf+lWQHdXV3+fR/fChb/hM+M+L6mV/XL3pd6refq0a4peq 8fhgaY/ImeiXqeF+tfrEb1bv+z3qLX8S2ovqPfbWg9i/DvCFQjoYXzoImZ/yWWRHdbX39+rH2N+3 83V0R/akXX1F/bwvpV/zxfQ70PX2+bS0R+R8jE9/nz30W+yHX/UVoBP62roz/ryDb4RfbxzSJ30T 3RY8xp5WZEd1iX+vzf63HrwPsB9uwuem+P2WrAGPIqcda4K0R+S09veT34DyutDdA/3dugF0dVgr ZO8t++7f78HvQqbIjurKlPh+4Gp7+uS8G0gb3imkD2ka1p+0QbbR9UNdt7GmxLygIWtLK3eN6uRu UC+6POpdV0p94mqrka65muqeUV+6t9VKN0RtczPUQfeNOuN2qYvuO5XC/xraK/Kdc+oH97066vaq XW61WufmqK/ccDXLvafGum5qkGulPnD11GuunOrm8Bsum2ruMql7qbdmWN9SJOnRKfsj69kF1p0f Wd9+Yp37mfXuV9a9i6x/xB/usk9oewrWxDhVwhmV32l1K/3IxPoYx/r4k40h47I/ai8lpUdYI48m yo58iKxnW1grt7Jm7rLb/EF7zEv9Qr/Lfuc32R1+LWWroJF1T9I1djLr6yTKJgfeq8Vxn4a66qh4 O1jtsyPUITtGHbMT6edUdc7OUD/Z2eqSnae8XaBSuEUqvVuqbnArVA63VhVyW1QZxruGO0gccIJ4 4Jx6yl1UL7g4/bbLoPu5LHq4y6MnuqLhTbG8MZY3x/IGWd4ky3cT8h2FfFch31nIdxfyHYZ8lyHf ach3G/Idh3zXIW+qj7qx+rSbrS+4b/Rlt1OfA0fdDr3bbYduq17hNumFbr2e5VYjc7n+GNqX3Qjd 3r2vm7rndD3XSldz9XRZV17f6Yro211hnY32ZXDXa2+VPm9P0/ddao9dpbbaxWqNnalW2gnMw8gw PsmNWaL3BRYZgl/tl+qCna++t3PUSWR+a6eo/XY8Mj9X2+1Qxn0g4/6ZOsLnk3acOsP4n4fmFztd xewspd3cgGgdlLepM1xFPc7dqYe6fLqPy6bfdJl0D5eavlp090d09zQx0xFVCp0v4HagfxtVZrdG pcVGDHMo7RKZqdwXKiPzepP7WuUi7iviNqhybpu6C76G8LdCTif3k3rJedXLpdWfuhv05y6nnuIK 6XmudHgDLOl85ncebZod3ghXTHpHIG+Mr/RG+EpvjuVt85QrvHWO9jDRd0J//L7nSt8LCSKb3YP+ JOf7puR8b/VtYnowPA8BCbKj/l5GD39xu/RZt0KfcHMpG6+lfuE76UajszMpX649envZ7Qmpc/E6 xvNFILyR/kx2S7RgDvq+CJ1e6dbRlo3o+2b0fguytmipT+Scc3vJ201ZPH3cqb9x27CjzYzxej3e rQqIxqOYK6BLMX8VXVl9F2N/n2upW7pndUf3rv4HY9PfzQj1Cs9Hbp5+wY3S7Vxv3QQ7re0e1ZUY 85LMcRFXTJdAByUtgi3dgdwSibKjunag+4IDdoX6zu5QP9vvVBz+OBP6mh09KuDy62KB7059m7tD Z0Gf07qb9GVr9Pf2e3XY7lY77Rq1yS5NwkZ0dxMyt+KTRHY09mJLu7GjjXa0WovdbsB+pFx4VuDH lpG3mvJd9tNgc5LusQN4HgQSeK/mLw+Gujqrk2qo2q4+UUvVe2qqek0NUz3Uh0RxrxG5dWf/9zRx 0RPEVa3ZFzYldnqIGKoVn55gV/mM6qqeV68QGb1LZNQPnqHqJTWK3HGUTlAtSRupz4nahhC39SFK fJ146xlVmtiqGFFiftWBSLKDulU9pW4mPwvSsqqe6jbacof6mJhO+MYS+81ExmIixtXwb1V3qnii 1HiVjZZfpzYQsy2nX1/Qo6nEWKPUr8RT54jDjoOD7E3j/Wi1zU8gHpvJvnWx2u+XqO/Yo/5EzOT8 Vnj3EfMdVynVefitSqNu1hnULfo6dau+QeXQWVUubDePzqVu03nV7Tq/KqjvVHfosqqMrqwq6+rq Ll1T1de1VCN9l2rOcxtdVz2m71eP6iagKWgJHiWvLWgPuqiH9cuqjn5XldX9kT1CZdST1CU1ixmZ p/bS2/3qG9K1aqfaojapXWoFOV+oI2pSmLM/u+98hrnryjy+wPy9QYz7EVH2cPWsmq5eVsvU29TS R32nBqoTagQjPFB9pXqryeotZuAl9b7qwhy3h/pRZq05s9cipE+hGx2R+XSi7Eh/m6AhDSl/kPi6 tboPXXgg1C987dCi1mhRi4DmfEpIm6FrD1HSmFR4I9/xAq0UvExLXkHHXlS9VDf1DzT0OfU4LWjB jkTqEzmPoXEdwpmfp6F/iX6+gzb1oxfD4B0X8NtepCP7h2fYg7zOzqI3O5KByPmM2kfR3tH0eFSo V3ieZcyfRLdakD6APt4NXZWgn6+z53gGWd1CWp5WidyqYRf0TFJdWWjzDbQkM/p9I23LhrTcjER+ cEd4O9Mh8ImcUoxkUXjzM1q5QQ6QndbcCu+tyLiZOiW9BZvLitwbSUV2NF4V1MaA6mol9rKY3dMs 2jqeOj6DBk2jr9IekXM7814CTahE3++mz/XUDNUAnjpoXRU0QvDbfmo4OjUKTFHXoKEZ1dfUu5a2 bMYWt9OP7aFe4SmOPeUDWbHRjJSnCt88falifpq6hH16Py6kMexT5Bp0TmRHdW3xX6sN2Ol67HUT tDuhO+CHYc9Dseuh2PdngU/k/OrHkjeastHqkB+j9vjxapefpLbDuwMZW/yCkG5nbyRyN5KK7Kiu y97RjktKqx/AcXL3k7dDXfAb1Qn2Tvv88sAncg6wJzsN/y9+JbSbGIe9Kh08adQFOYGF1cVC6r3W Ma/0ZXyJyI7ecVyjsuuUKpuWOoU2g8qq06obtaTp8TdpKU+dSBO1Lx/WLMitCukcqoDOhv+5CT+U GZ+RCb+UXuXUIlfkZFRZyM9KeTboboU+h84DTT5oC6p8SSis8oPCukCi7KiumuoJXRXfVA0fVh1f VlU1wL/V0uVVVV1KlddFVYlALzJKqiK6gioJXUX8Xk1dW9XTdeC5B97a6nF8YKuQ1kJmDVBNtQ2y o7o68rk9+W3Bo6od/rEtfrId/rIdfrMt/rOdlvaInLrqEfJaUtYCmhbQtoTnEXhbIqOlbgeNpB1J O1NHJDuqaw6r3Zfo4zw83DTGfbTKpAcxhh/Qp9dodzfaLDztAn8T/byqrd9SpXVfxm6oSq/RMvhO YEl78MC7QjoH3Z7P8wK1O8iO6hIfegZ/cwLveZiSvWoVlrGVVWo3FnkQ6/o2tEfkLEbGMtJVahuW s57/L4dqHqUT1VH8nfhiSY+rQUHuaTU4yP5Xf4EwQqkr/AWCnO25LU5rWTW+xwtcgO5XVmWLxRk9 RqXWY1U6PZ4xmQAmg5lgIViprgM36FWsh6vRszXo3lpkr1Ol9HpVQW9gvNYw3hNUf8ZoCJ+Hgc/B RDALLAIr9Ea1AWzTm9R+Ph+F9yT4DpzQS9QRzY5Xj6JsGGWfqtPMywX9D3VJP6OUaa1SmgYqjamg 0pl86kf0bw/4Wt+mJoCPwHOgGetyVSDrcxrwPX5uK5gPhoE3/x99G/6Mb6Ff8E/q1/1z+l3/hu7t e+uP/WDd34+Cf5IeAAb5yXoY+NxP0eP9VD0FzPLT9Hw/XS/gebGfqJf5sXqlH61XQ7PBz9Lb/Ty9 xy/QB/2X+rhfqM/6RfpXUq3m41Fm6iyMbl41FEvvr4up3lj7O0Q7r+mK6gVdRXXB6juEKEeiHYl6 JPqRKEiiIYmKJDqSKEmiJYmaJHqSKEqiKYmqJLqSKOuyv0Gf8Zlpx3V6G1jF8yLyZvsb9SSfRY/0 GfRQH6cHM2ZD/Tk1nPEb7Q8zrvvUVL+XcT6q5vqzagnl6/C4u30qfcKn1j/5lFoiOYnoJLKTCE8i PYn4JPKTCFAiQYkIJTKUCFEiRYkYJXKUCFIiSYkoJbKUCFMiTYk4JfKUCFQiUYlIJTKVCFUiVYlY JXKVCFYiWYloJfaSCFciXYl4JfKVCFgiYYmIJTKWCFki5ZaJkbNE0BJJS0QtkbVE2BJpS8QtkXer EEM1DxG5ROZPhCjs4RCxS+QuEbxE8hLRS2QvEf4fo8Y/8xdA6bDxa/UUlRb/kEpPVJrPMdr4C30+ jz89Q9vFW4mXOouX+pG6LuJrHBFUnB6prtGf40dH40/GsE5NCOkN+IwbkJUZmSI7ih6vxcekw++k wwelwxelo1zqvzFgMpgJFgLxT8tCej1+KBN+KQOp8EbtrqC3BMj3uEXxP7fjh3Lig27G91wPfSbq kvpETuYgazll30CzAtqV8KyCdzUy1iShMvRVkFEZmSI7Wt3bUNaK/IQ65XkF1pGQPoasNsFXrg80 Ec9j9Lsd/ZIyoX2E58cYG0lb4ZfluS2p0EQ8fRm3/uwVhFfK++M7B4W8UWogYyzPAxlXoYl4huit agD1Cq+UD+d5CP2S9DP6MYQ2DyQVmmjstultARvgXUG6iHQWmAg+B8PAkIDVPK8mbzVlq6FZDe1q eNbAuxYZ65Kwk/7vYh52wieyozk/G9aDLawLW1gDNrMWbEmsfx3Pa8hbTdkqaFaF9UPSM+QL3xnk CW8k6xB7qcOs20fQuRN6OuvJV4FO+I7opaw1M9Vexmm3/oy1ZHBiOkTtIyY4yGfhTdJ7k0tdy7qT gfUnjblXpTCPKsfe7Rf9OvbTG/mDQn17Al8/Pr9HXa+on/XTKqZbKW3qs35VUKmRkc4UCuk1Jg/P uVVGUpH9z98KZWetyo7tZmftyo6Hyc5alp01LQdeNAdrXA7WuhyseTlZ+3LipXOyFuak/lysjblC e6WeH3Uh8gpRVhCagtAWhKcgvAWQUQBZBZBZANn5qSM/deWnzvzUnT98+5PwrZDsT/LRrjykOUPb /vdbof/9Vki+gfm7vhWSb3T+s2+FPiWO+ZgYpy+xS28/RL/nP0LWW/oV34NYqYPu5FuFb4REzrO+ KfntdE//rP7Avwbfh7R9EH34nL5M4nlcSAcRE4ncfqQiO6rrS+Ki+X42sdMsYqiZxFIzialmEFtN h2d64EnAOD0QDPLjKRsPzQRoJ8IzEd5JyJis5xBnSfol6UJ4I9mR/XxNf1bB+w08S6FZRD1CI3zz kPEl8pfS7hV+hF4HraSr/Ui9lrhvLbGc8EaydvvFOh5sJZZb6+cic5oW+cK3HlmbqX8nsvdRthdI esDPBwv5nMAbvT24nRVBkE1NZjc5l0hgob7olxAffk2cuIQ47Sst9Ymcg8SQx5FzFvwCPP1Lq6YS 443FEw0KiMZWdoIJu8Gn2A12ZSf4ErHkG8SKvXQJ1Yf6B4Z6hed29TGe6wN9h+pJ3PkqND3YaT5D bNk+7CAjVFetiT9b6bvVo0F2VFe0y73aDjU5O90Iedkt52X3fXui7Gi8ZNednJ13cnbwgqgPU4mB J/nriYOvQzcyMd8ZiY/TM+bpiZcz6hh5Uq/wXPJZybuJspuguQnam+DJCu/NyLgF3cyWlI4jph6f KDuqayJx9FR/SE0C44inR/nv1Aj/Az7iIqnRo306Le0R/s/8teh+Cuz7ohpI3D3EH1Mj/QH44pGx E7+0N6Qz+DyL5xmUiexovOTtiOBnn4Y4PT26l1avQd4iH4P+PL7yWGiPyJntj7CfOq2W+Z/VBsr3 0JYT4MfwduVSeLOS9HY+8U3P1d7QJOdNz4Yg67c3RRvxnSI7qit6g3W1N0/JeYMlb72iN2Bxsh8n nhbZ0XhFb+Gu9kYtOW/mBFEfojeJV3sDmJw3iTeEfY68iXyH57fUTeqNIDuqK3pDerU3m8l5Q1ot yPrtDWtV9WyQHY1X9Jb3am9sk/PmVxD1IXpTfbU3zMl5Uy1vtyVthKxGqhnxzENBduTPozfsf3xT fqU36vLWXdJnKXkW+i6JvFG7ZU+WnDf6yflmIMKZxLdQp6A6Ed7c/pm3Ua1Dy4op+d5b++M6tf9Z p/PGZPDpzLU+s8nss5ksPrfJ7gua2/ydprAva0r4yqacr2Eq+btNNV/X1PQNzN3+AVPXNzH3+odM Q9/UPAwa+zZ87kzZi9C+bYr7vsgYhLzPTFpg/BATcwPNT+4Tc871Nafdh+ak62WOu57mmHvdxLse ZoPrYFa6puYbV8usckXNZpfZHHYX9GW3OXxX/2d30BlDf1Mq+T70V7ddX3JbtXXbwvel0ffBaei7 ILWPM3H+F8pPhO9PhSalP8b4/KSv9dpcB40g0vYyvpYpDe7w1UwBX8Hk9iVNNl/EXO/zmoz+VpPO Xx/kCs/1/jpzk89qbvE5TS5/u8nvi5pivhT8FUxFX9VUAJHWNPYPM54tGdeWpr5vbu7hc03fmLG/ 31Rm7Mv7OkbqFp6qviZltRnzuqaOvxf6huZ+3wjeJshoYlr4ZqSNTXP/oGnJHDX3Lfj8SFJd6fxg 5mYwczTY5PH9aVNv5L+JzOeZ347IetRIexLktEXuM9TzMvX2MqX8J+Z2Pwzez5HxOX1NSFP7kSYV 852a+RbZSdbgXjGnmOdT7i1zxr1jzrr3zAXX2/zi+hiHTsT5AUbaI3K0H24uuaGUD4T2E/Skjznq 3jffurfNIWQcQWck/da9iu68QvmrQXaBUFdm5ZjjY+4nvd3dYNa5YmYN+rTWPWy2uCfNXtfNSFtE xg73ImUdzTLXzCyBZrkrYta7TGa/+wF92aAj/ZHny269dqQeXRT5V/4O8D/q3jHq+ZY+H/5de6N2 VmL+ymBLhZmTXL49evIsY/eiueheY3zeNMeCbbzCGLzEOD2PDXXFTp9Cz9qYfMxLMfShlK9uorrk uQx6Ud5XQa+qGZGf3HauJKpdTuS7jMh1OdHuSqLeqJ15VF6ir7JEUfWJnh7TqYgKf/K99BE/kKhn tBZeod/kh+r9/mOi0je1Ul0Yv0f0zaoutlaWyCt/0njKczaisOwqN1Fnbi3yk9vO6f6gmgIm+v1g N1HLrqQV6Lg/EfCt/5aI4iDRwH4igb3qG7AIzPX7Ar/wzPbbydtG2RZothEl7CBK2AX/PnXGHw6I +r+LenYRSe0hKjrA7u4wu7bj4EQipE6hP8fz90Rmx4ngDoM9PG8nottEezYgI+qDPG8iUttKnTtI RX5y+z8n7EAX04+FRHhfhJ1l1M5NRE7r/RK1BpqV0Cwj/Qp8GXawiwOv0M/3c8mbQ9kcaOZAO1et I3+jn6+2EW1FdW0L398tBEto69dBfnLb6f1bREhvEOX9g/RlPr8YbjC9LS4tUUovdR2rWzrW75Ts 3oVWylOyOmZg/b6e9TEbEcJv+iLfu74J3iG66RX4k9sOR0QXI0K8zI7eelkXhyfpS141NyCPmqly En1lI2q5iXU6k5pI2ybQnvGBX3hSsqamUyOJkj6nH6OJoMbCO4Gxn6oKq9kBUf9ywp+Hz7er+eo2 IkWpQ8qLqEXkL6Ge+URtE5PaKM9ZiWBuQWYOUuFPbv8qEcVEb1rKE6dUUvcntUMinQeISOoRXdQk QhFaKa9Jbj3in0ZELxL9RLKaJr7Xbk509DC8wp/cdlQk3ipPLFOO6KxCeP/UMWmcmzN/gqbM60PM byPm+X5invpEnPeoHkSD3QN/5fCeqjN5T6t7ia0aEik9RDTUnCiuFbRt4BVE/WuOjFbqXeKm90nf D3VI+RM8P0oU+JD6gLpeSGqjPDemroeQ14xU+JPbv9+/dS5LWobPSX+fricmYqqqpueCrwN9mYCv wVwwFUxMQlk9DlljkTku8EZ9ugtPW529c1X9OOgTyoS+NM9lyStPWSU8ZtL881wFL1oD3MU+WfiT 26f+ejL7/YnhzfTHejSfP0+KXufqCWqBnqK+oN1zSGdAO4l0DOlwPUkNIu0f8DnPn5M3irLR0IyC djQ8Y+AdjYwxcp4wpIvorzwvgk9kR31exHh+oVeq+XoB9U4NdS8OmKqWkLeUsmV6bVK75Xk5Y7sM viXMh/D/q0j45XJXioSXBEmPqNJmm68EaoK64AHwEHgEtAVPBdyuWoMmoA6oDIqbfCofyBreLf/X vxutn3hySE4QXUw8UbQy8YSRnDSSE0dy8khOIMlJJDmRJCeT5ISSnFSSE0sJJ5dOhJNM1RJPNskJ JznpdF/iyadm4WTHHt8RvAh6+d1+MJgEFoPNPt4fA5eBrHsFQXXQFHRljXwfjAFfsSbEgwsgg97h C+jtvgZoAbqDPmACscHXYDc4D9IwljmBjPlf/S6sXZiPeOYmnjmKZ67imbN45i6eOYxnLuORL9jI 80byNlK2EZqN0G6EZyO8G5GxkVh2W0g7m83hubPZGWRH39s8ZdgFM9dS5zMBt5NXWEna2RQMz0+S Ck3k6RK+A8iFXuRCP3KhJ7nQl9zoTW70Jzd6lDvIFd7WoAmoAyqD4qYQPIXgLRS+RxBEf8nePvHE yL/D9xOC6HuT6MTNf/UkzN9xIkdO+UhaMZz4ya8qYCPStshLRyeN/nhi6Eoni+T0kaQVsYMqfhf0 uwNvNM9yIio5J5uSd0Jqp4/+gr50ov7mBGnAeR2P/cRjR/HYUzx2tRv72o2d7cbedmN3u7G/Pdjh HuxxD3a5B/vci53uxV73Yrf7sN99jMg+7Hkfdr0f+96Pne/H3g9g9wew/wP4gQP4g4P4hYM+oW87 ed5B3g7KtoebpCaBxWCz34aMbcjahsytyN5KHVupayt1bqHuLbRhC23Bm4ALIIPeTFs30eZNtH0T fdhEXzbRp430bSN93EhfN9LnjfR9Y7DfCOWwzwrYXznsU8bmz3n6w2Fkn1blTGpbOtEDiSc6n+iZ xEOJp+qT6LlaJHoy8Wji2S4kejrxeGMSPaB4wqaJnlE8pHjKy4meUzzo4kSPKp5VPOyLiR5XPO// xO2Cf/e9tS+C91VVO0JVsfNVZbtVVbJnVQWbQZe3hXU5W0eXse10afu6LmUH6xJ2ui5uvwab9J12 F9ip85DeaHfrdHaPTm2P6VT2RxBnUtnrQW5QNMxXaivz9mdXi8iDi/bcyVyXREZlUCGsPvH/pE0l SIUmssCEs4//Dtr/P+8FWiSeA43OfrZEO8VjReMrZ0ij86LR+VE5ZyppM/T792dO//dGvH++EU/u kE3ujXhy1+x/diPe/wt32kb97qzuSvadtp3xK5J2xMc8zXMX/I3wRv3eG/xJafxKafxLGfxMGfxN GfxOOfxPefxQBfxRJfxSZfxTFfxUNfxVdfxWDfxXTfxYLSvtkXpeVBXJq0hZBWjKQ1sOnjLwlkZG KWSVQGZxZN9JHcWoqwh1FqHuwrShsN0W2lIYf1bU7uN5jy4Z2hb1ew++7oC+xu7X6e1efN9efKC0 X/i28LyNvB06Lb4xFbxxIY3XKaCJgydl4E26hTT4xXT4x/T4yfT4y3T4zXT4z3T40XT4U/Gr6YKc Y1qTpynT0GhoNTwGXoOMuOAXJa1oUthKPFc0aYPsf7XK3qWutMrWDS3Lq0YyK8NAP/B2XAH1HHgU 1AMlwM3Am/zqKFgHZoNhoBcx9PMhvhZs8y+A98FwMAdsAMeBjtvmb4nb7kuB+uAx8Bx4G/SL2+GH gZEBBf/039tFWpUQ5+ehPblpV27al4d25qG9eWh3Htqfh37kpT956Vde+peXfualv3np9230/zbG IR8oynMx8opRVhSaotAWhacovEWRURRZRZBZBNlFqKMIdRWhzsLUXZg2FAp7i2if8QTPT5q8Yf/w 2x4lPmlvEu1VZE8j6ZPETU+ZTUn7m6h/Q8P47Gas9jBmexi73YzhbsZyN2O6m7HdzRjvZqzjGfN4 xj6eOYhnLuKZk3jmJj7sk6SeF8D7YDiYAzaA40DHbUTGJmRtQuYmZG+ijk3UtYk6N1P3ZtqwxY8N bdniR8dt9WN4Hk2d0raofzKOQxPbPDagYBhXSUfHFeG5mPqMdOgf5jv5GhvFhVd7CyAa2QsMAVPB MrALfA/i0L6soDCoDBqA5qAdLe4EugTUB61dl7jXbZe4HPbOuKygiu1i7gTp/4txTvwV4pyNV4xz Ih/yVOIs/h076Qh/3ElHGtc99H83Y7GHMdnD2OxmjHYzVrsZs92M3W7GcDdjGc+YxjO28YxxPGMd z5j/R43rBYaAqWAZ2AW+B3FoV1ZQGFQGDUBz0A5t6wS6oGkdQ1u2+G5o3HM8d0PjpG2Rn+4Sl812 Z366M0/dma/uzJu0v2NAfdDadaSsIzRd4vKEtHPcLVb4upEKbzQvhcMc3xDKhPbOuFtt6ZB3qy0K bRGei8bdGGginjvjWLPQC+EtHVCF8hohLRlXneea8FQPNBFP96BDRazwCm0XU8p2DHmlbGdT0nbi ubMpGmgini7mGtsdvRPejgHpKc8U0s4mjZXybqRCE/GUTFwrpExoZZ2onLQWpbWlgi2lCDT/yhpH 1S55BWssF2rIpv47/i5d6vir75/+f/vboN+fxPq7/jZITldJ6mmLUfLZBtmRFsn4/PEklozXlU5i /TktqhJqyK4a+KGmoR9gHvJ9TXP/nmnl3zBt/POmHZ6pvX/MPOUbm7b+QdM6fLedvL9fyORHmqx+ tMnlx5qCfrwpASryfJf/3Eh9f1WjOvj7zdO0pxPt6uCfNk/g4dr4t2jzB7S9n2niB5v7WV/r0pb7 /Cemkf+Ifr1L2WvQ9DCP+U705TH4GpuO9EfSJ/HSTyG3M6nIjnxbwt8WNKbPTeBtbB73DY3UL3zt fDPzqG9BWcvwNwIJ3/k/Qv0tGJumpA8G3qjd14Tv+/+evx1IH/4O4T/+7UC0B5P+C+5mvCv5iYz9 ZOZgssnJcxbm4Vo/xlyTKOc65N7sR5jcfC7IfJUAFXiugVwZQ8Gf0yoXWvEKej/MzKGFX9CKxdS+ zM80K/0Cs8Z/bVb7dXzeYb7yh81y/4PZ4L3Z5zPEfe9vjlMqV1wmlTsuh8pGNHNLXHF1a1wVlT2u AWgJniKvh8oa9w91Q9zbKl3ch0SFH6uzZoDaZwapbWawWk063/RXI8xANdgMVX3M56qnmaBeMNNV JzNPPWYWq2ZmuWps1qv6ZrNirVblzWpV1KxQhc3XqqBZpPJDl8/MUHnNZJXLjFM5zCh1i/lM3Yj8 DMhPYYapi3qQuqD7q7O6rzqt+6hTPB/VA9U+0h36Q7VZ91Sr9ZtqIekU/b4aqXurIdB9DN7l+RX9 nuqq31AddA/1eDhpLSeu5eR1y8ST2HIiW05mywltOcMkZ5nkTJOcbZIzTnLWSc48ydknOQMlZ6Hk TJScjfo18ayUnJmSs1NyhmqPX6F3+c16s9+rV/pj+Kuzeqa/iD+NM5/5jOBakNkM89nMUF8I3AFK gjJmiC9vPgfjwCRipSlgsm9lpmFVs9BSme+/+hdH0+GdgTbORtvmkc73w5K0eYnfagTf+LVmBbqz zH+J3sw2X/ppZq6fAN8oI/zC8wVav5DPS8lf6aebtf4LdOtrs96vhzc+ILLIHCpHXG70KZPKF+f9 bXGnfXbimkxxa72JW+IvmAXoptQrPMt5XuXPEq/FzEGfNu6cvzFOo5eZ4L9FZUFXb0pKc5PmQXdF dlTXG+QJnofnKZUTPc6NPudBr/Og37nQ85xx0h7hzwddcfS7CmgAWrLzeYq87uj7y+q6JPxDZULm dXFvki+yo7/QGqL2G8Gn6pzpq1TceypDKBeeN1SauF7Kmd7qe9NP7Q2IvN0gNRK9Ho5ezzfDsaFh 2JLIEZr+PPcnrz9lfaHrC52kH6vPzCdqKLY3LPBGc7ZCPWwES1VL86V63MxWT5sp6iUzVr1jRqiP sckhZlCinE/UIOy0N7b1phmjemBvT5lZqjV8D2GL9wdEfVunCmGzhc1W9iHbsdtN6r5Qj9CsUXUo q2nWqgrmG3UH+b/dIjtWZTWCCSqbmapuRX5OM1/lxg/kxQ/kM6uwd5EtPMvhXYIvWEg9c/EF0yib qG6jbXloe46AaMxGql/0SHVZD8MffKbS42euD/UIzWCVhTnIyJiloK+/4Csua0mHqJ/0cDBS/Rp4 I1n4MP2xOq4/USfxIaf1UCxoZCLfp+pnys7jM84m4nhIP1BnwHf6Iz4LbzROvdV6LRiottI2OS0k 5Ql8fdW3uh95H6t4eLcH/MY3Wgt6qan6XfxWL7UyyBGa19Va/Sp5r6vJlH0WkHT7Vjjd/Ih+XrXW b6l28DyD/Jfpy7vgY56HBrnC854ajLyPwbs8v6rfVt30a6qz7q6eREa7cBpa0E61Df4wOjEd1VU1 +MKrn7ROzonthNPfcuK7na6Kf61G+0V2pDfR2YCr/Z1/cs4LCKI+7MQXJ+dcQnLONxxAlqS78PM7 /RfEovOC7KiuQfj1wT69Ge0VvvpnvcCf1sv9t3qDjyfO3gjPCi3tORCwAt6t5B8gnj2pl/jzeo6P 6Yk+Fb4/kxmFLElHhDUiM3KvDbIj/RnAmjEQDGL9GEz5IMql/lEB18Kb2YykbAQ0I0Gk+0N8ZTOA vfdA1pkBrDcDWHcGJNKM5HkkeSMoG86aM4Q9tqTD4BkMBvqKgTeSNSGsS1VYo6qwVlWmzipG5Avf 574UeaUpK2OmghnQJqTlQEXGp3Lgjf7SQtaVaaxtk1jjxrPWiWzhmc7zLPLmUSbrTrSOyfM8oqnZ xD0zSKf/YU28evS0Kkh6LNwT3jbx3nC5P/ydxPvE5V5xuV9c7hmX+8bl3nG5f1zuIZf7yOVecrmf fHvifeVyb7ncXy73mMt95nKvudxvLvecy33ncu+53H8u96DLfehyL7rcjy73pMt96XJvutyfLveo y33qcq+63K8u96zLfety77rcvy73sMt97HIvu9zPLve0pzQlzLUgmylu8pmi/JefTzlAZlPIGHIv 6VLmJJTbdV7zjS5glunCZrEuYuYhYZq+3YxD4nB9sxlITR9TU299o3kHvKozm+dowVM6hXlMX9LN 9RndRJ/QxfUBnVLv1AfDCX45yS8n+hclnvCfmHjif1g4Uboh3ATwWDi9uibcEFBdb1f36P3qXn1M NWF8ZQ7+akTzn90ZHd1hffW7p69+h7Xcey3pOH2KZ9GJH4LspNMmiXdzX+1O7eTczS33eUu6SzdC K5rorUBkR3XNTuZd4cm5c1zuKZd0PrLm6zf0HD6L7MjKF/6LO8+vdDe63J8u6VJqWRpuXJ8eeKN2 R3e8X+1u9uTc8S73wku6DjkbsJl1aKTIjjxkdA/9H++Yv9Jd9IKojXK/fXLuuE/OXfkR4kwxUMIo kyA7qquwSUWJMmXMdSCnuRNrzY+13mJKY89lsesygV5kpITyWiz7ZpDXFITyNnKyg+vN7SYFOU5L KjXLcxEgsqN5zIsnyWeWIm2rLo8vKG0ua6lfaIuai/oO8oqYnTo3dHmhkzSnWQmW6zx8Ft6o3ZnN p/iF3vSW3ZAZig8ZQ11T8S/zkPMVclfovIly8pklOr9ZxEjOo33TkTVBZzef65vMEJ0RORmRI2l6 8wnoy8j2DrKjun5Ad7/Ht8bwralNK/xTe3ifxVe9Ct5h1PvozIlyMpkPmI13wKt87qGvMZ3woG31 r7qVPo3+n0SWpN8h66RurE9hUyI7GiM5Wb4LP7ZHHyB2SwFtcS31C98RnvfoVGjgIbVJbw4n0SXd jD/bCt+OcIr9t9NU0Wn6q5+Cv/pp+gFB1tak0/gD4RXZ0Zur6LS/1Bmd6JeT/r/9/eRvtwBEPNGt AlIW3RzQLuRNwU9P/qfbBiKe6PYCKYtuKJCbC35/i0ELUqGJeMqGv01NuPEguglBbkv4/d+rlg2f 1yT93WVDfGs9fG8txrqK3hXohOcueOrpPeoB/S0++9Tv1oBTqmlYR2QtOB/4/1w0sCFIaqtk7y17 8IS9+B1hby57dNmrJ+zZMxrZw8teXvb0sreXPb7s9WXPL3t/uUdF7lORe1XkfhW5Z0XuW5F7V+T+ FbmHRe5jkXtZ5H4WuadF7msZEM4jTwr3uMh9LnKvi9zvIve8yH0vcu9Lcm5Dv9ov/lztN7P+eBPp 330iS95syhtOedMpbzyf9/eZN3w9856vbfr6WqY/Mgb6aiHmlPn4s5FBtAKM+Bdx7ZXi34G/i5Gj +PuPcfSV4m2JySUdwrh85tNCmy7wRl4g4Vz11eP95Owb5Ey2pLvCPT1z9X5SkR21OzoX/sfz3Vc6 By5nxb/+3YmaNaTCG8mKzqv/8dz5lc6nyxn2KJ1DOpu6hTcag+ic/dXOxyfnnP3HQdZv5/T7IUtk R/tIOfOfnHP/ybk/QPD7X4X6u26ivvsPvwb1x5uoE37j7e/5VaiMiekffxXq97fH/l2/+ya3wF7p d98inZLTi8m9PTbCH2+P/Xc7HRnJlW8k/q7TkfJtRtRP+QbkSt+CXOnbEkFS9EEbh+M7Pwt78pr4 uLtNP9rwPn72LfztC9QncoWnB3mv0Z5e0H3kq0NXBR9c2XzqK8FXPvhLSQeGd9OlkVkmyP5zK+zY 0LIH1H/H73HsAZvtRb/KWr/UplALbQY1396s5toCao6tQHqX+sLerxbZlmqZ7aBW2+fVRttTbbN9 /1vuCr/ar15e7Tf//upe+Y+/eSf3x/+73kkfWZbcGf933UkviORORw8EM9GJ2TYr+pFeLbZGrUBv Ntmf0KGEeoVnD9iCLq2xWi23qdQSmxGdyqYWwLsAGYJIrtzTLNhk+6m19h31jX1RfWU7om+PoHsP UN9dod4EvrvQwfvUUttCrbRPqvW2u9pq31S77EfhDmfB/+371ucm3mn+73DfutydfqX71v/5Nyf/ nl9V3Zn4+5UHKD/I8wFkiezozOrf9XuTke1d6Tcn/5UHVardFTxo6/CrVFPV266me9XVcN1dNdfZ VXXtXBXX0lV2jV0lV89VpKSCK+7Ku1yunLvWlXXOlnFnwB6wBswH48CntqzrCZ6z5VxbW949aCu4 2raiK2crucK2ssthq7rMtppLbWs4G7vL/Rir5U7HarujsTpuT+wRtz3WzW2Ove82xka5TbEFbkts M3nHXXws5rbGsvg1sfL+q9hjfmasjx8V+9p/EvvF94wVU91jbdUTsSGqWWyjui+m9N2xIrparJGu HOuqq8Te0zVjA3XD2Hj9aGyOfib2lX41tkK/H1unB8Q261Gx7XpaLF5/EdujV8f264OxQzoWO6Jv scd1FfudbmPP6F72nJ5mL+ht9mf9i72ob3IxzWqh6zhlmjpj2rg408mlMD14fo38d90vuq87owe5 w3qk2/Z/5dcVZGWRFUZWGllxZOWRFUhWooQVqUBYoWSlkhVLVi5ZwWQlu9IvTC23H/mvbFe/yD7s F9vq/mtblNXuFjxXeh9vvTtif3Tn7CkXs0fcNe6Au8HtQR/iXSG3y5UElUE9Pjdzu10Ht9e96Pa5 XtD1dwfdcHfIjXGH3VT3rZvvjrhl7qhb74677e4EUk5CeRKOw24/vN+6be6M2+yOudXkL3Rb3WS3 0g1yC9yb8D/lRrqG7hN0UXT2r65ab6PjvdD195DRy92NrNou8oo1XBknqIeeN0bfW1JXO/S/M3bQ HXt4FdsQfuF5Fd7u7i7KakJTA9rq8DCrlNeAThDJnW+LYyclsJfi2E1x7Kc4dlQceyrJOJbCvkq7 hLqr8FyZvEqUVYSmIrQV4akIb0VkVAAVXeRtD2E/R7CjU7Ga2FN17Ersqwp2Vgl7q4jdlcf+ymGH ZbHHMthlaeyzFHZaAnstgd1Ku4oHmePAp/D1BM+Bttjsg8iqjd2Ww24L2+rIrInsu6jjbuq6hzrr uDOxeu5YrIE7mZh+G6vvDsXqusOJbYu87XbseHvMYuPH3QZsex02vgZbX4/Nb44963bGWjrpj8g5 EGuF3T8H/ftuGzTboN0BTzy8+2KXQSyke2PO7Y4pvxOI7Cj6qBYbogUVsP/y+IFK+IMa+IV6Ma8e jG1QbWKDVdfY4+r1WFHVJ/azHx5b6qfGPvJfxh71K2Ll/MbYTX57qCNGu7L6DbEKflmsjZ8b6+vH xZb5gbFffa/YHerFWDv1VGyoeiS2STWKaV2XOu6irurUWYO67471D4j0YGpsnxZ8js/5FN/TK7ZJ vxxbozvHlulHYvP1fbFJod3C0yQ2Rj8em6m7xr7Ur8W+1h/GVumBsfV6NH5rOryCqL9tXGojaOpS mTr4IqIWcxP+6Rdr8VuX8F+/4Md+xJ/9gF/7Hv92Cj93An93FL93GP93ILRLZH4R20nebsr2QXMQ 2m/hOQbvSWScRtZZZJ7HF/6EL/wVX3gJXxjDrzndxvmAaM7llzGmsj8bwz5qmDuiP3Hn9PvQv0H7 nqetnVwak9B2rzuB7sh4lfKe7kfd232n8R/wbdFj3dfhFzYS0oRf+pjqlgXZ/7//UodEYMn9pQ6J 2K70Sx2R/i1IZqSYnIhT8M+/9HT1yDY5EXLCLz1dCL/edJq16lTiLz9F47HZTk32Lz2tttOv+EtP kf8sycojKMRqkwvcyJqVhlXI2RPuvD3rjttf3F5rWCsz+nX2Vr/CFmNtlPXxYb+M9XKV7e2lPVLP EtvHf0nefMoWQLPYFmFdzQZfWr/Dxtwhyx7GHneX7EGXmpXvereTOrdT91basC0JZcgry3pKhBXa Fs3dcNZNQX/W0F608UXW1Q6sr81YOevR9sogoT/beN5K3nbKdkCzC9p4ePbAuxcZ+wJ+i4Lxqay6 e8B2d5q1+RRr9EnW6hOsucdZu4+5hLr38byfvAOUHYTmELTfwnME3qOUHqWWUyE9CM8hZBxEnsiO 5u6c28CnHVDsYsXfS/lhJ/ULn+Ts5v+H3CZo1rnvQiywzgnPeWKCc+HzDhdF1AMZpTHufjfTtXeL 3eturRvAiE6EfwE1rwh8IuNbZMRDsZGWL3ND3FzXE6pObhirdR/W2CgukOc+rPn9WIs/BSL/X0XU uw6euEJEHbWsua1hm9pGtrFtY+vbrnx61Zax79r8to/NYvvbVHaA/SnW3x6N9bE7Y+/aNbFX7ZJY V/tFrI2dHWtkZ8ZqWJHxZyOcSFNS2Y+t4Cbb195uP7Cl7Fu2qn3J3mOfsffbx2wT29A+iPzWoCWt fNg+Tn43W8u+bstBX8B+YrPaQcgYGhBpysxYbTuPts2PNbSLYo/Z5bFn7PrYSzY+9pY9FvvA/hzr axPqHmp/jA2yR2Kf2O3kr4y9bhfGutk5scft9FhjOwUZM2OVQzotVpXnKpRVDbKj73mkfc1tbSt1 Cm1zWzm0V9JH6I08P0KLheY/vwfkt3lZiPxFsZL261g+uzp2s90Sy2j3xVLakzEX+yV2MZbK/hq7 0V6M5bUudodNaSvYjLamvdnWtfnsfbYkY1TDiowr1/efzYeNCX6J2dipmLEHYmkYl+sYu1vsilh+ u5Q2LUWu9P8LnhfTgm9iWezGWDq7J6bt8dgleH9CxoWAaD7uZyzq0aZ6tO1utKuqvcWWtdfZojaN zW2NvTGxXuG5EY3LZy/FilsNVzpGLYu91+ZFS0uiDzXoW+2QNmJM5bkBqciO5kPat5B5kDqlfGGi Lkj6RawWOiFtrxpo/pXV/GPQzCtYTbdQQ7lkWc2Xdgb4Chy2C2yGsPdck7gXlT2p7E1ljyp7Vdmz yt61lptKtDrV1nVT7P1usn3YTbKt3UT7pJtgu7jx9nnQg+j3WTfKdnJD7ROuH+U9bTPXzTZ2rewD rhZR9L32DlfP5nZ1bCYiYscInAZ7bB27kdautA9Y1lM7jXEbxri9h609z5y0t3fZVujQX7HmpPf3 dsjfaM39QhpnB6MfA0g/CbKjWZ4bxneOTaizH89T7JKQN8UutlMZ+RmkswNN0nc77ElmM+5zmY+5 zMtcqETOkoCvwGF4MriF4V1BiZB+yYgK3xxS4Y0s5W7mK3l7oKvvpaogK+pXLTfT1gl6UCHkV+e5 FjogaQ30QZ7vIRWaaNxfdKPRjSnoyGR0ZQo6MRXdmYYOTUeXZiBrpq0VMJHnieRNoGw8NOOgHQvP GHhFxijbHRmSvkTeK9C8RF0iO8mSXXXbBD17GH17xD1rH3dv2adcX/uMGwzvCCttEYicbtT1DPI7 uM9sG9fftnBv2wfZsd0PbwNkNERHJb3X1UB3q6PDNYLsaCwqurrsCOtaqVNoK7iG7A4bJqYPsEO8 jxmpH2ii9q1Er5fjLzagdXvQrNPotEPfMrma2EQte2d401M3yCkGf27XgLJ60NSHth48DewmtHIN +rkSjY3S5aTLsB2RHdWV4PmrYDdVsZ9q2FEN7Oku7Ko29lUHO6tnpT3Cvwh/MQ3+Ydjee9T1PL66 PW1sBW1z7C9hxbgbm6hlH+L5YWSK7P98xfjtXcGQ2DY9iP3Qp+AT9kb9Ylt0FDs+aVP7TsSGHewN /nFb0je3Tf199h1fzS70dxLP5rTFVQbbWV2KTVYnYsfVjlguvSLWWM+Lva4nxcbpkez5RL7IHBRb qkex35sW+4deHGuoN8RyyN5MnY9NVCmJvbPYO1QBYuJydoGvbXv6RvYh38IW949Rdxva8KS1TtK2 1rsnrXNPkUrbopUv3rI/Buus9ovIn2zj/CCbwr9tU/rn6MeTARYtsmiTdYOIVyfby26RveTW2Ytu u/3VxYNoXOR5L/n7oNtLXSL/ymP6268BRqeWmqmhpjGoD2qpIaaKGmzKq0GmlBpo7lADTGH1qcmv +pvb1Ccmt/rY5FB9TU71Np9fNUXU86a0es5UVc+aOqCh6maa8vkx9YJ5Ur1uOqgPTXtktkN2G/AI kPqSu2JH35NVoQ1VQS3aU592NSZtRtpMjeB5JHkjKBtuKqvPaP9nSd+T5aGtuWhDXtXb3K76mAJ8 LkIf7lT96N8n9LO/EdnCU14NI2+oKUZ7CzEGtzMGeagjJ+W3QpcN3oS0H+hjsiNXZCd9R0ifBQ0Z kzqgqupBO15A3suM3+u04R0j7RE5t6iejOVL1NONOrtA+zQ8neF9hj51CYj8+ZP0tS3taUtdj6s3 TCvkST1C01Z1Nx3Va+ZpyjrR9g6MgaRPkT4J2tGntqEvCbISxmzA/2nv2sN0rLb4b+/NxHDcBonE cypCLlEpPMqt62jItVxSuUy5NJqRW2jMkROJiHGijCTidCQpdEWijlNDhGISjVBH5FZor/Nb27wf p/T4+r95nvWs/b173fZ+97v23u/s3/fxPmTzfmSzfrpV+w8G2Rxem8262ZSZHfpWeSfWdaTNTuwP 1f3d1cSoUedYTVwSPP/lnKOsKe9KM/bETRxJyWzVnRhBL1n0MuE3oySeGTpqZXPajne0NKKs8sb0 14gtbEJZ1Y1GkOpp6zsypnaMtQ3vZDJ7/FbyVryjzdkG9dco0FO0lWVb8M4mcwS0513qQrnu1D09 8nMC70bfWo569nzr5bwQS38oUksRW4rc6laA5FJElyK7FOGlSC9FfCnySxFgigRTRJgiwxQhpkgx RYwpckwRZIokU0SZIssUYabII0UgKRJJEUmKTFKE0rwCxJKe1jl9UvzGcIpHT/PoqR493aOnfPS0 j+IcFe+ouEfFPyoOUvGQiotUvKLiFhW/qDhGxTMqrlHxjYpzTAwYvLnWySvW+zftCb/KHvfrSZ+z nGet5LPuoE0Q4xLlQldS6rjy0tJVkY6uptzrGkpP11j6uuaS4VrLCNdFHnf95SmXKVPcdJnqXiNf IdPdBzLT5cost11y3F7SYZZPyQxnMdUlIpvP8j/Yl89yTpnhGpA3xnTXjHUtMdHdgfHuLvzN9cRw 3pGBbhB6u2Ho4oajLe/NrS4TTd1Y1CVVCci6eDNdNN4i9NP50EvxoKAUOaW8EnlFjo3IdgxdVIDk Oh8qKx50l1LUhmVxosjiQaNF9GtUW/SsR+iDXyMJzoU4UESC8gXSkGP7Wso0DLqRrewwxn+LbjgX CmJWkNVnocn/nZ6I+kDxsPGcvojnFMdDBRjbB6ST7SMdbGrBiZDIV4QvPR9ONx68b0StJYc2Z9lb +cyq7TOnl56LC+8aD262BGWUJ9CO2i1Ku8XP+u5u7/MtZJ895nfaw8wBh5kLjvmVzAVvWPELmQvm BD21U0zmMXcsYo5Yxtyx2p6k7EnqeL/dFpKvKZdfwHeTvqXuvmA79t020ov5I9VdQV5JOrsy0soV k7ougXnGMt+IP2g1HrVzAXNQIq+VYF2S1HYVpYW7VNq7K6UbbfRgDro/8EbMSY2ZkxpJn2A78rVI pjEXZTMnPcvclO36yWR3l4xzt0umu0EGU7a/03jUzg3ygGslA12KDHXdZLQbQLlMmUjdSbQx0S09 i7/B/La0wHbkyzCXJTCneea4IzKH+W4u895c5r85bjVz3zLmQo1H9d+WZ9wa5sdc5sLtpL2kH0kn RPWnOIenAwd5IVICngm2I1+tMMXdwhzZkvmyCWYydz7PHJrDnPM8s81zrijzqcajdopRtixz6iWY RplplJ3mGtFeU0x2N9JGC+ZZ5c3wJO2NdzeTq+3I11C0Zt69iTm2rRuJrm4oUl0aMlwfjHRd8HfX hrIaj9pJxljXCY+5ezHEPYgBbiB6Mo/ezXzd1mUgmTm8VeDpzN8ZtDmYn9V2lBc032ailBvPXDqe uX0MbnTqX/VGoInL4rUs5t0RzNOal5UPZ54djiTGVironm+Oj1bjGfiEq7eNXOVttm3xOdcWm219 fMaVY64ti3/bIljDtdZ79hRz6UlZan/hHA68agtjkS1GXhpL7EV4g6vzFdR7h+ur92wK3rddSb35 uR+W23QstUNZPwwfWPX3R9+fJWKlVSqHtVzVrqefTxnnBsa7gXFv4GryE/swPraPsB392IZ7sI11 X1JmG2W3cOW7ySZRJwEfBYrslsSbVikRr7M9r1tDAmMVthO87vB28Ks6v3DO+IlzxnHWneBzL8wv hbHAFsc/aXtRoMhuGt6ySn2o25VtTmEfNsNqxrKS8b9rK7Av1K/qVMRr9nL2X332UzPqpJC60m8v fk6ljFK0K9E2nm7najuIMumUUT8qk47FdgSW2ZH0pf2gFO8udwDnkr6kVM5DqVKP+bpO7Lv7Z0tp zhdJnC/KcR6paCdIVc4V1e2jUttmSH2ruiqfJjW5Jrucc08Vzj0VOfeUpbyiDIuF08yxHfVZJ5tf kBJW7ccbp+JxPjRfmTVmO/m2gNeJ4qxuC9ty9ogpYvebU2a3OWx2mv2U3UnaTL2PAm1heQuvbWHd ZnPUbDWwX5ridpepZA+Y2ky8kS8t17HW1qbdmjbBqv1446xmV5nqdo2pZtcF3EpV8ijOFWaBWWvm mM9NjtlDftTMN4Xtv0wZu9RUtm8b1VX5i+wHpoR9x5iANnrVfGMWUmcB27DQvK8osAJfWn7HLDYr yJebV4zajzfO09isLGpm0sJIs8Q8GotTMTSwE8wRM9Z8a0azxx8zuaQPzSj6ywy4LpV/ywzltcGs e4QyQ8w+M8wco0whOybgbiJfWi5rJ5GeMaUDvmZa3HEqpuaQaUfqaH4wnQPmJsJ2bDateTeTzQ7y fHNHwN9o/W7K7jAdWNeRd7pDLA4tbzTtzQbKbaS86scbx20oZ1vjQj6jFckr29tQJfacVMdxUx3e 1ISztVGEz3Nx7vBLcW+XxH1bOXtboCrcq1Xmnq2SvQYVuFMvy526/kbjBdz1g3Q8FqeW9fuML8Vh U41c7ccb57X0eTX9XUWqw56vg5KxOCdxZzuSNIA278HPph3E3IzCjDMxxKu6Kt8gfC7EeH8xKfTd DYdMP3xP3b1mEvbE4tSy/iblVHxHfsCo/XjjnITb7RQk26m4g9TWTka7WK4bgeZWaSRusVmUG0dS eZUZhw42k3wI9dIpoxTpTUQDq5SFq+woXE0b1wc7KjMIDTkP1WFdDfs0agWK5ty5uMIuwJV2Pura F6k3E9cGOyozk9dzSC+wrHwu6hV8rmFVbz656pYKthLYrrqMtVaoU9lJtKPXzrS7gZ2A+vZJXptA PZWNt88SoMjkGaTp9gJM5fw0NbamHIaX2Ccvcz5/lXPIEo7RJbYxy7U4R1XGPM45XPtSX3WS8CzH 2yyO1Rc5HudTdiF1FtoHWH4YczivvBT4IOoMIR9aYDt67voi2/ZnDAMxk3PNLKu+0wLN5fUXaCeH 89+sWJu13Kvg7ZC+Aep7jjc7v9fmbX6//8J/67f7fP9V+M/yXh/FccSXlwO+uOR7SJ4/7FVW6/f4 H/x//Sl/zBeRU76MRLa0fMqXkxO+ghwjqX68cVxMzcoi/mKxcpE4KS9n3rAe8p/6I36TP+63+pN+ B6PZ5RNkLyM74MvKUa+6Kl9CTvL6EdYf8CcY51G/2x/yef576u3zn8XesGp5n88N/4//gaT2441z vGzEBNlE2opx8gXGkqIx0l8ykS5jkCETSTMwWOZhuCzBY/Iuxsg6PCG5QV91MmljhKzHEFlFnaV4 SF5GP+o8SN2+tDFQngi8n4xmXSYeJlfbsd/TkTLmr+LMFXIQ9WivsazGLfIKuPfDfTIuxKI2UmUS usnzaCOL0ULW4jrZTvkfUZO6NaVULNdouYYkmepSzlxGUvvx9skeycI3jO1rUh7jzJNRMXzgfrmU dD2+kw7YJ2lBNi/86noaqQN2sm4nZSJbWt4lVZEvVbCXXPXjjaMUNqI0PkUS/oPy+IQx5MbeI9ZF WVMDpZnvE5n7f2ZdfpBXmarYzX49jjooYq5CSVMLxQOvhzKG8wg/n9aN/RcF69EdH6MrNqEzvsKd 2I9kHOGeyXPtn2AaooSpG/TUThFzHWBuwE9oiYOc5/agDb5Ee/ruSBvdsS7wTliLu/EhupGr7eg+ 90IP0x+tTRquMw+hqumLoqY3jqIHdlF+U0Es63Af7aViJwbgMNIpM5iyQ6gzCCnU7xm7z1rui94m ldQL9xu1H2//LsdWvIUvSHlYRl9LSVGcjzDLD8NCjMYSPEmJaViF2fiIV3J5ZXPQVflF2IF5LD+H DZjMdj6OldyTLedeaTFjf/nMupnlAXgp/JpfBkntxxunngyrGztlVjOcFoviHOiN6ecLmd6+qOnu S5kO/kKT7C8xzX01c72/MpwqU/lr/GWmKa/f5CuYFF/adPaJpod3JtV79Pc/x3xpOY2U7k+RJNiP 4uTm+s+/P//+4N//APMXxVMQABEQnRMAAABEAAB4nOxaC3hN17Yec861Ix6pJDQeQT3iUbRKo151 PKIEISqKVkqoqKSpEGkpVaH1aB2Pum6VtEopfdxSpZ5tbnBUL9pSj/ZWkUofhFOUSjVrjHHH3tkb p7ZkRdzvfue7Z+X7M9eac64x/znGmGM+9tr3ZUjOsrXVv4c/XX8BA8RlIeCaPOWF5woG0N5nYmZf Nv/r+qe6UEBe1Bb7uQRum5cRBArKCsoJygsqCIIEtwkqFroAhAhCBZUElQW3C8IEVQRVBdUE1QXh ghqCmoJagju8fkP/t93/f3/1hVT5S4fa8ACMkjQNnvlzKCjyChOP8clyx4MGEjfcV3Zhcddr63bk vTmwNkt5ali+mBIl7T8JoyEWhkFyidp2X6ESha7tj9P3xntTLe2mQCL0kZ4nwli4x/Pn/KoKWrlj oLtPTtt3dz2mVeG98rbfXFrtDUPFAknwtDw7varfRP/ddsowvvYLx6Hx8irJ+P/X2P3nv5RY0ZQr 9N0/j1133O6V9Fha6tjUEem1o1KSRndKS6/dbWhKSmLaM56I3ytuiDd7SDHZF9t8OMafL84RZ+Sc 31xKNeqUklI7amh64uOpaUmJY++E+PiYzs3jH4rr2zy+e++4fp1iYuLie8XFtmnVp29svFv+0LT0 +D6p4xLTRo9Kjx+WMnSkG3ePe3KER/Jq0/TpvAOhjkfSzVyNZi/TJakf/OdOti1lJ0t9ue3uG/vK +xzsLZsQA7C9ucTYVu4yiQTmxXB3dLA8i0B3pCivpxX0z3ffVdDdyw8McUuq5YkPDQIqSmx2SyuM I/3zpxWsDvwioJy3rJynrFB5Vbx5EZ48y7Ne6Ne7T5/K13ifRwV9UpNGpZf31q7gqVMYzfrAP8ot 9OOrPNw1LQ8P5V3B+mMfJ3f50suGnhodOwIkyFQwdC5ChtxncAYslb/sBBkh2W5kCxiypYs5OSDI EU/OBnePmTsKMoC9ATnD+y/De5PhffDI+C4bVu4+B1xwDpYuXSHZ8p7HNADsvWHvg1ue21KRunDG aelX15FUiQ+oVOW/bD7cqGxYfpZeFkgud+y3pQXpqS70jLtkjnPX+EO7fF7jzdfe/ABPKpcuzDee 2SLCWLDcztKLArN0guuSa1j+Jdc/Wkr9yVLXssl3Jbu2B/jYiA2usLE86TlhVTQL5a13lY1b6jCX G1sChuVvCXDKJsHl1s1VNuIZV9gYbytWMWyusvax8eklQdgsCpxk/LFxynAlTqN9eIx8DMUfr7Ge Tw/FWc3Xk1APwzIidQl9gPPpM5G+Cw9TNu6lTbiN3sc15JRZD5jAyfAK+ytLVBPxuMpFH+vCoHCz VnZLqWrlisSJmKjcvlpZl0SHs9V0/FLtvsJGxn4prFzIZrdInI6zi2HjlOFMmMirYKFfXc7SL6DL nPGry5J7QCH7MyLxBZylS67LdXou/qYP+NXlzVr2gEici+uKYeOUYRJX4sGqnN9YWFxZkxuURZsu +Inpf2UUyoxQCg+q6hmF5eAZE4cLRfJKST8wE/Aj84Gkp3GZqUszTXcaYXpTtGF02vPnoQfmQzw5 0751hUcWDMSl8u58SWfCZHweNkh6HhdCI1oDsbQf+tFZcDmODEmceUNN3oUJNNG1W1+ZjbKvjwxO vVnJHsvdg0goy9t1GV6sy3KcDuFAfYIa6E3USQ+lITqUkvQxHKG34EN6PtbTiXhQxeJ81RkfUa2w vmqBl4TVx4KnoBlGQhvM5yjczLGYwYMxmtMRaTZ+RatwBW3B7fQlnqBLGMRhVIfbURN+jsJ5F+XT XorhUxQCOZQO9TmPE3im6CFK7i5SM9hEm2ESDVAJFKITqJd5mcKtPFps9ecL1jfc2TUAklxfw1jX aZXk2q6daro2ZPJn4F/TmVCDlptvoKi44dRnDbTwaLoKrIGVJJJ5M7zGO+C0tF4e/htaw0kYAkFq DjRUq6GX+hzyVCgs0vsgW78HJ/QUYB0D9U0oJJjXeIY5TZlmPoWbLvSyrkGbVEMKV70d+1eIyP5V H7N8PZP123Wj0WkMsqCup2cVPYzHq0x4SwWqAeo11UAl6xB1UTdQ6aaXCrHK6MPWdp1n8nSI2as7 60w9X8Voghl6s+N45bSH/fRGXG29C/7iTclHSYynhxEw2nyNU022xJeNuN5sxizzKf6XOYF7TVX6 zMTQpyaF9ptNdMycox+NxfmmAYdbC7mVtYETrZ94pVUfssyb0MK4oEDXhFX6LkjV9YVtkOA3Hq4P 8it6Bx/R67mCeZPrmVncxSTzQNOfU0xrwR8S0zbTQJNGw0yQY3tnwumCeaaG41kl3tPfpvCUwoKO qq4drjrZoJ6wc2CRvR++sXdAOdwBXXE/vIqH4AfMlvXzu5Ahfr1TALwU7uN3YRhnwVw+AmuZYDdH qYs8TwXCcVUZGsv4TNbEa3QO50l/w00m95c+pprm/JwB8e8vJX4vo8kmiZ42kTTSfI6pZjFONkNx hrHtyWaZnWqG271MW/uSrmi/rC8WnFGnC5zqoye8IByP+10tJKuynKvrcHE+UehZvnN/nwbdZ731 TaBIqcCzRFKW4LQgQoeKdUP5TcERXY2dMs1T93EnHeWpX98YeW4nsu7jNrqdYxl71fs4RWdRLY+M IOis38f2+gh20wH0oI6g4boPjdIp9IyeK+nblKDXUje9gRrLvdbLaa/6D7+e5rT9LjCUP4Q0v9ru oiyspO9Df7sZV4ljbITHb4NF6t2YoGrgRBWMr6qy+IEKwB3S0g8qCMvralhWR+Bl1VCea+M2VRPf k7qvyP1EyXtMNXG8XhilA7G1aYNO144+fveY5ljZ1MLLuhIe00G4S5fDj0TWv+sQHKVr4BjdCDN0 Y3muhxt1Hdyra2GO3F+WvFDTzC8/p5zXwLyCj82cYjhf1ekjHs5NYAdMwZMwHXOgAwYptkPUWjta TRN0tcdLfHhL1bJ/UT1sVC3sbrqHfa+uJeOyn52pW9hn9Ug73Ay27zUL7AfNHHukWW/3M5ftQaYF PmmexecFi01PfMfUlLj6jf2OSbOnmqZ2olHyzsGCPP1hwVK9pOBePa9gn1pS8Fe1vGCA2lBQRR0t yIF69mcQa6+BVYKyuEbWYaXRT2uzlccENDb+1lc+S7qK8cirntvVo706MnO0gHMy+99jneTB1lbe Y9WGGNdC2OKy1PeulqrA9bCqGfCCah+wVfUO+EkNDgjTSQHJemjAYt074FNdLeCMPuUKMCtdVcwY V13T3lXT3O6qZk5bwWaHhfpVK1c/Y32qB1gLdJQ1VgdbgfqgeVatMrepR81s6VWUYw3cZVZyQ1dv VdTe0+nc6YLGHg1UEqmt4UHBZNMMPjANYL8Jh1CLOcb6nJOslXyHKx5quCZARVcmnLe2wiHra1hn nYGplqV6WuGqjNVMfWHaSY+6qtLYN43bs0uit/+y6fwF+y8bIDv+81RcLHJd0U9rT7+rw1vy3gbc Slm4iz7HXPoGL9HPKJsSrMx1qSE/IEikejybKvN2smkXBXMOLZKV8HFeQ79KWT63JZvP4knegnt4 Pq7kVJzCA3AAJ+DdsrrOp5l40PFaYD1uwr9RC74VO7Gr1j0rUr/CfMzCO6SnnWk9jhTMkvX+27RN 1vyf4Xd0VPYBFlXlO6iB9KgxD6e6PI6q80IK5JX0G31MB+ldeqBUc80cj3Utv2Uv/y+UncKRmEi/ 09Vocf385fxswXf+VYVG4imchp3oHD1KcxzbtgO9QgF8iZ3Gdl978fJeBzpJR+kXJprreGVxlDqy zfl89Wzt+tM/57HSx8bN4Cid5QP8b3yROzpmcwofsWvJTtOfLUoet3xswijZY4tT+IIdRo/YpfHO xR5POud3JRRPyTLKF14dl5xRipXQtZZtw8nk1mNJLOvu6UUafc2ZWcdbYNkwt19TPzwj0m+kS/9s 4vABfq2YcxnLj+3c7cVhe9HAo7SgVJFlB2fxz3zEr+2+o20Uzd9d4efvjMBtlcLfgdw6DbOSOJoj 6Tu6kR8WnuX9TOPJfVdJr6YV7F9+oT0aKnZs3fOUQ7H8x3V8r+U3k2O5r8x4RfOzONPL7wt6/Zbx q8C380i+5zp51/L7RGrMpAo33KcV8mvHm7z8NK+/ZfwU59NArlQkvzd4ID9Bqhh+d/CHXn659MZN 8XPKeQXH8E7Rmd9fImiJvYtW2kX1p6usX6igRzH+sMQ+hIX9WWJH3jJ9R9M6ezttLZLfIFllVLKj i+G3zj7s5bfObnoL+e2x/0YHiuQ3VlZdTYrlt8c+6OW3x77e/2+eX669k04XyW8W7qSoYvnl2ge8 /HLtFreMX1cqsHdQABbFbznuoMF212L4Kdzv5ff7TeqvNGPsYd7AczmX/c+aN5q1fLPVGHl7Bn/N 6TLLPCyzTenWwWP4HB/yO9qJRuB8dvn9Labka9bqHvbloTaPwAQei8/LDuUlfgef4yxM5c/xQT6B f+G/4118EbXseoiOOz5fOYb98CGZC5yuetI8XFpBZX4MbRqI38ta41UajP0pCSNpPIbSFLRxCV7A jZIexD9kVfcDuugYVqcfsC2dwx6kqA9dxqF0AVPkeQL9gjMkXUy/4yopW0MVaQvVpmyqRweogcyj TegXuld2AB3I4h5UnhMoiCdKuowKZD/zE5XhfRTGH1MzXk6RPI1acjrdyY9TFY6ndhxHPbkD9eL6 1JnLUFO2MYQvY0v+AdvxQcE2bMZrsSavwAb8Ctbj8Y51hxSPC3mX47Opth7dhcNkfhzH8BAcwvHY VdCOH8WGstOszolYkZOxDI9BxRPEkNMF8wWvoSX2DvLw3ITN+RN57z+xn2CE3E+QvBf5fZzLbwjm C2bgHB6HM3mU43Oa0oyECBjFn8JyvyOhqLJwFYVNda2rOzs/pyBOV8AGIj3arQotVW8cIZIzBadV dyyje2OEjhdMFLyO4foTDNVfYTn9E7L6Dc8qiw6rCvSRCqV5KozGSjpI3UZRkt9M/YoR6nsMVx8J 5ghGOPaOaN0NB5o6xayor670ffybmb5IujvuE6wQGZN0D0zQfTFaDxYsx1i9GwcJ92R9GZ/RFs3W t9FSXZk26Cr0pa5Gv0saakLoTlOW2pkL2M18jX3MFsF8wROO+UfoodhXT7tmr3d9DHO+W/L9jhuh k7GxHo4tRPpfBN30COyhn8VOegK20U9jM0nr60mOWa6Gh8RCLzkeg76ZoIYajjXUVNwCI9Atw2l7 sZ7fw4tr7/pdYqxJwVgzFWeZEThXZJRmvPWE8fwELPA7pkaqNDyhvkV/Y6rku8rCbx++FYlpONL7 HYl71nfKdJ6ahF+pbUV+ieH8vKCQzTaROAnnFcPG+VctE/jtG3whNEciRqDJ9avLko8A3xdCgWYi ztEl1+UGPR1/10V/IVRSy+4WidNxQzFsbvV8UUDnuSYE+/0iIJE3ciosN9fy79jx+vOHK+tN5f7F LcPzXiYHwEaOhCzuJkiETE6DlzhJRstAmMid4a/cWPJqwbtcG3bw3XCE28OP3BvypM5ZXgQn+B3Y xetgjXjEGp4q92lwjJ+Ci/ySrH3Xis4OwWXOk3dskX8BNvEx8YntkMPb4JKkoXAMKsElSSNUGbhP XeT71RFuq/ZyQ0GwOslaLKVUfbhf1YHpUud19SMvUYd5ksrh4fIcJ/kPq0hYp5rDz6oxKF0OQvRZ DtbH+Ky8f1h6u1OFwXaps0dFwRkVDbfraGii28BgXR/G6QowRV/kcfoED9B53FIsW0/y6+lB8LB+ HCbpBHhbd4WdUv+AbgIHdaikyHv0ed4iWCH3C3RFmK0bwYu6IyzW3eE93Re26v5wSD8EeXKPkhdo 2kOwaQ5hspqpYZBrmB+5qjnELvMtn9UnOVcXcI4OgqM6AnJ1M/i77gLVTAzcbzrAEBMJo00dGGcq CJCfNhc41eTxcHOS+wm6m4vc2lSE5qYRREo7HUw09DA9Ic7EwuNynyF5L5nGsMDcDpnGwCKTw3P9 fr/o3/feBnUD3yuqbBD1Mz/zZcvfOezNn0IPoknWIDpvHedF5rj03mkv/qd9s3dpGAjDeMmbxaGD g04tnTp0dHIJ0iKKpYNfk4NTp3SpdRAcxAbqUFBwLLjrUAoVlzpKISCiQ8E/oCB00lI6qCR38b3S tIGkyaUGB+nBQSCX3C/Pk9zHe5cwjSPNmTieBdnjsPwjJ5MmTFVgRIykasS5aUpaHO6MF3CKq/pf 7zBpSpoKjIiRHBF+moh2Imbpt6M20zsV0XoDp5g+rAZ+GhWy1OpUMgCnGIGpDyP6TWu8ZNRCbePZ 8ZxEKrBLGyNni4E4K5E6ktchQytwijXwkhYHpE3n/TdEgoxRtryD9r7av+tXREF9JVg1JLigCjfp JZK+TiBN0C1YMPbALXLC1LJGZr7wilsh4RGZ2YG1YWRmE3qBRY46RIYWLdh4rXzzYos+Ch3izieD OOSToRYYXx+dr9OyK98blmgLfQ8+FVaGfJ/CfmB8KXx/qCcfRb6Uh78qnI/4qn8eeWPtRHVCOxHT JUhb2gl/UbmYXocPzEypA3QzCKKoXoQnvWHZYxJELxBFyhu8cxPzMh7zknZRn2NyCO712WeNXV2G OZKDAlnHzK9MHstu0G1wGq1Mv7bI7ponaVikaUhSZxruf0b0HDyQsuOYYfqV5GtdQZ0UuEfN3rGG oGcz/p94/P+XmZzKu/cF4uibhtAszdL/SD+bndjcEAAREF8KAAAALAAAeJztWQtQlccV3v9xQdFo fSQqyZjYcayxhogUCdZH4wtbEVC0asVRkMdFeegVRazN6Ew7JlWj1kySmYzRDI5NTGt8tklMkKDT SbUTrUUjinrFUoqMiBolcPfs9uz/4HX/C//13plMpq5zuOex9+z5ds+ePeC5s33c7x0Kv0E6jAlE IYx3JyFtdJJB2vgBIbIhM865qeaPx/dqABIzqD+enwNJnHkoUjek7khhSD2QeiI9gdQLqbeeAqQP Ul+kfkYesO8WzuPh55hN8vFfAXmOTCV5+OkiRR1LQafjKcwY05eoB8OwbohRqpuntZ3r/t1XbnKo RNJmqGZNmYzr55IVJJGkkWV+rU203JPb1Ry731trfMq4bg7JIEmIPIOsIqO0f/bHQCJLogYKTHbX F9D/NFjnJWP9SFw1gaTiCWSTNSjbHeGPgF+c0wbFXF+/t4oRlz/3//Fd//4PCU9RCdNzt+PdDccf M7OXuvJX5WcWPDc5J3vFy66C5+JSc3IyXEVaxZ+ZvNhQL+5C/U3s4ZVWufg6JiN3P3BI0uT83NzV edlLUwuy8/NISkr8pMiUucmzI1N+npA85+X4+OSUmcmJsTFJsxNThPNUV0FKUn5hhmtFXkHKCmd+ Xk52XkZEYW6m9izhOKCMXHPrX31t36RHGcO3vif7M/+JdiDHBgAyWEOcu3n3JUM2NpBMiCbkUhQh rsHChpVAie0tqkO0ZhWVoof8oedMk+B6ymU9+vUUngZr9WFYSG+szcKbXkfONH3ouebIDQ0zbGGa Td+8AYZuqKZTici7OQlJSf3bZJ+2C0n52XkFPYzZPbU5ejVLIu396nncGoeYqWpxSEYHaxW9wNWI KAeSrKwssnIKITt27CB/ztZ3Y4PxY4PBbDCE0tJSUlpZSvadbiDc00D27NmL6g1EK8Vc7KjOcEMQ WyJ2+yey/mpEW+5XRVO9Z7XjD5KVrZwLm2Jpu6js92Spx1VRvymugNHL+um+gO+UmNEsO8yTN/Sy oQ/RPhG3rOsV7RV4Gr1lqfs9FxXxvf7akbXfbanDbrdGA7KTciUSzHX0qMzfIXStqn024Gr6p0T0 LBJzn1IjgStOCrIZochNgclEpMf0R4+ioeon34K7qrlae/+S9vkjiXO70UeoThrpaI3e9Nc+vkiH k0aoXcU3NMSML0oJVnwDpOE8QprIrWxxDvD81jGRmnmAmeyVB/p5C4t53uKFH4rxzcVvxzli6Hqk XOTtRhTruOfZ7JhCTYQDNX9hJAH1sagXtkLkhbzI0Z1mIeU7RtI5SEK2Wsfu2s1kOO/jYzdKVPB4 1InUGrejJQNN/P/A+SVqDL2PVK3ax39QveeRLfD/DfUH1SlU2O4gL+RytTu9jlSjjqRnkIQcCP59 5Hn+OfmZJf4RikSdyhQf+M2b52jBH4vzRyjj6BKkWcjbjeEZ5aEnT5nuhX806p9BvbAtRF7Ik5Re dAZSshJJX0ISciD4tyD+Yh/4D8gSvSX7wu99/p/h/APyOFqFdEG2j3+3/NBzV/bGfwz1u1EvbNeQ F/JJuRf9CumiHEk/RRJyIPgz5Wha6XiTWlX+1trqq06ZGaBX/DfRUzTNlPXqJWqW3SgqlTdoqnqs JQrxmphRONpVevM9eFr9C01T36CVfqwRRdPVn9LO6qjA0rZOX8Fv7PRUKtYvnVmno2iKotfpKFoZ tHdkkVpHM9TETt+RRHA46ujnXcS3jS5S9fiKYVHQ4ivnEr0s/wbaro0dUMvaouMa0M2hzangr8AV eWvzRdt34heEemYpRaB7IVhP1kICKYJZyu+bZ4BdL3kyYM+zzvAi0dWOInDJ62C1Y3Nzvm2kN6R6 T43qNLzc0/hqyQk16vrmahbI7btEp8NaeYZlT3aFqLBcejLE98303YM5Wk5VvytPhiyXVLhi5IPI ArsRyqQMFGkLs86a1rvZNiu3MEUqA9ln1TA6QujO9aycxr+RgpWVo3HlaNk73vbxRctlMFrqKr7h ihlfDAlWfIVkBd9GNlm+N/HyAnhNfgcerfv6FX47Xt4JG5FWIW83ovFyPGyT322pM+brk4z68agX tl8jL+RUOR1ykArkTTAfSciB5P9C3A2Xj90okxYAl94Ba9zer+8/cX6ZtBMakWol+/iPSvEQYoH/ NOqPSu9qtvvIC/mylA43keqkTXAWSciB4A8lK/lg8qol/hdJCuSSPT7we3dfE3D+i+RtyED6JfJ2 YxhCZoGLFHvhH4P6IagXtsXIC3kacUIi0jyyGcYhCTkQ/Lf5SvzN3Rr/YZ4Cd7gv/N7n/wXOP8zf hhqkCm4ffzGfBQ+4N/5PUF+MemGrQl7If+dOOI90mW+GEiQhB4J/Gd8ObrkBgtF9NaCn7bCM69VL 1Cy7UbhJPWRIfZg/3VdflinVg9uPNbZBtvSWVzfTWfcVw7KlO9Tt441r6W4wO/U6vQ2qgvaOpElx bJn0QafvyAcsTI5jZV3EdxvSJD0+D0sLWnyX6EK4zr9mnXdfi+EazrlKL7HrvNZzucmu9wSYD3NJ OdO9pGj8bChnc8m/PYnNdr24+ALsbi4YXhZp/Bp+gRXJ1Z4C251gNZuO9faU4SUe+ZOslp1iddLX nlrL37Hteq5o2s0Isf5rWSUsZDksJzQY3VdOaA5byCpBzweRBXYjlGAQV9lN7k/3hbPZIC6Br6qh RzGPhVA9K3eRRh/dnf9ZGYUrj+He8baPbwwfxKNYV/E9T8z4Xuq0avh1a/hf+R1+1vK9mcE/Yq/x u+wRuy/89gxeyzYiuZC3G9EEXsy28wctJ9DSfaF+AuqFbT3yQk7jx1kOUgG/xhYgCTmQ/D+Ou3He x26UsY8Ywd2w3X3h/DK8l98i1TL7+I+xYhZqgf806o+xB5rtPvJCrmDH2U2kOnaNnUMSciD4s/jH /BV+zhL/KDjCcuChD/wW3RfOHwX1LB1pHvK2uy94n62CZi/8MagfgnphW4K8kOPgBEtCmg9VbDyS kAPBPxPxp/vAf4QeYQ3UF36L7gvnH6H17L9IFdQ+/r30ffaQeuP/BPV7US9sVcgL+Ut6gp1Hukyr 2AkkIQeCfzmtYW4+nQej+5rO3byGLad69RI1y/ZfF2Aqz2RZ3J/uy8mz2FR+w481qpmT3e60znfs vrZyJ5vKboD1G2fW6WqWBnqdrmbXg/aOLGW7+HJGSEd/beMjpAffxU92Ed8kvpTp8SWj12DFV9F0 iLlpRLtXwbv7Osau0xfI1aYI4qYT4cpD291X8wE2B0YYXg5rfHLzj8lcGAtJjXa9rKIH2To+0vBy VOML6Uiyjo+DAtud4H88u7HehhteijX+liec1LEIqP3W7u3rfLXW/2c1h9X8rs5OIdZjH8+HjXwe zONLIIIXQCN7FTtZ238dgI/hFBvdcju5u9SrRqiW/SAOuWO/NoKI6taP3EGv56ERSuBZVgKT2FFw Im1mn2KV/wLK2JdQya4CMJUN5M+yYXwsG8HT2Q95IQvnb7FufB++jJ+xcrYfb2ggFfB1Pp6LGmNl 29GJ7fH4/x7/A9RNIBkQABEQuQYAAAAgAAB4nO1Ye2wURRj/ZnbvbK8PsFev2CCiGHxApU2VWiEK FCUkhZaWGoyXtFcC7UFp6fWgkEgoUQNi7D9qTDSGQlDkDx8QEolBPExIxBgh8kax5a0ECAiKvZ2H M7tzcK3XvQPWGCLfZW5n5/v2+37zvW729uy+u2ftpvxj0I+eAQ0YTwd33BpSw6TBAFjdM855bJnf oduKqBhMjWwRP5cYMuZ3iZEmRroYHjEyxMgUI0vFm/23sO+QQ1QFLeIThuHwHDSLawiW9m8FtuQT GRPTJfvBSNE3JEUs9vPxsh2Ze3pg03ZkSuixnlIm7C+AhVAB9TDvhmxLyhFdKH4/qT63RF2xsNsE c6BS7HwOtEGh+UmdhgBGsgfKPaVqX279vRxrjpT9ImF1OgREBIKwWNynSvk3sX8Zpw4tZt+qZ03h SqX+ZZ8YpJ67Q7c3IRFFzWPlbv/azRdf04KzQy1tLXPDw8uaggsnhsLDpwSamuaEloJXcqtr1XJt kuUrpZtbE+Vip0hG3vOHC6GylgULFjUHZwfCwZZm8PvLJxX5a6qrivxTp1fPnFheXu2fVl1RWlJZ VeGXygOhsL+ypX1OaGFz2N8WbGgONBU93r5grnkykfSpNnrx2b05KVfSzdAjb67FNyKf1WeTpbew SadIxj1W+0jdKwfCuAKAXx8FqMuRPNEJtMJ02SGKTK7sFBk4ZOyNylkmXpE+ySM1DTP7w0j3INGb pTarj+yNhox7XJd1j+J5TJ7lvDy19pC5poPMu5nTKytz47LP9EJlS7A5nKGkM00Zq5tVQl+9Vh5f xyEldRMHUifYROjlvq6KXfogEolArJd2qK8ONelQN1Im8nMEPvruInDjInR1rRfLHWA+xkE9z82P vJGukF5+Alu/Fk8m9FMNWWmku3q0RLxLbDefxzNRIt7v7GkYmPcsTBqAt8woRMR4Csl5FLtiOWEi LRC/bPJ3gODYqd9axWDFWfJ8+hJMjIt8mWFpcJvlJ3yDLVnN9HQuLkRuQ868YjafxLTH9MnrRSEr rw8jzvtGE/WLZpy3jFLEDB331xePT8dMSNUkwfc13hK18C2Gdx3DN8NAuJhs1OzwbdSKCcIzkuAL QLvCN9Hlok7huxBdI6yf1u3wndaLyRrtQtQe333uTb0Wvjrc6Bi+ocY6rYqcssV3Sq8i67ShSfzX gC8ofEPcSxzD5zMw9pL1tvFdr3kJxr4k+Ma6HlDxbQRwDN8yYwzKJdm29ZGNc8kYlKx+Z4lcsfAd xe/fVH2kinkaqdcOkLO2MT+r+1i9lpUEc737e9VzjqMK52JO0vF+0mgb80Ztv5DyEXt8m6FW4ftC f9UxfPeSPDSNeGxj7sFv0jx0OElNn8fnFb7R0OpYTwSSi8rJeGSHz4/LyRUOSfw3E21T+K7AKsfw IVKM2skJW3wnhEQxQknwvQFvKXyv4KOO4SsV2MJJe84WegL1JolvjctNLHyPwRrH8JWQtZqXLrKt 30W6l67VSpL4bz+erfxX6uq+qfpIFfMldpgHeUbCE9K56GT+rbHPdj/79FV8Mh99NbafwsT56hmi eui23rcd8/dOYz5/gRyzxXdM98F87vrLHh/tHa/8PcVz0DF85aRRz6DHbfEdFxKNejmxx1fuekfh +1P70rF+2W0EeDYN2eIL6T9AgN+fxH+zoltVfNvSC5hT+M5FD+jJzkAfplURHzoXtce3W+9UZ6CT +sf/aj2tNrz8QRLh1tuD+fqDY28Pmol5iL6DjyBevtq4FTt2b0u7YGBeEFu8+P4jMVoI9Ws+ke+a eWkrjUu4Rxumpenprlbjx5Qj9wkaTC5rEzRLy2AyAk/QpuKAdlmjRkvKWnbBZ+QMjmBLy+dkLIrg F9FRfAZ3kS3sVrxXx/LpVbQBJ+Jt5xbPsppPx8AGXAMRfBVl0k6aqoXhvI1moXFKS5iu4ONwF5+B s1AjHZ+yljrWTUfBGWRp6aZfsdPoJxZFo2A//YDcigd20FJWx7cqzaXMx7aiMWwXquOFbFRCzYm0 5NFWtpy1Ky2tLEDbUTt9DS1nQbY1YX4n0tJJjrCdtERpOcJ2kxJ0gpShnXQfq01ZSw0p4l5KVeYW 8ZcJhdeJG3lpAe9KudbsrV3/NyVGieQT9xf9H31Gg8QU/1zBtefQDffPejSFzUMbWX99fd7BmQdP Yd9ArB/Ia+tkuHaGVudhWo+s/mmweuQUvkPkJdrND7J42w0NDddsW5Gspb8ImaPkEOvmvxlHelPV Pp3OojWwj1la/Oa8SmRUDZw0KqKeAXx/h/4v9DdwPx/cEAAREMj4AAAA3AEAeJzsvXecjtf397v3 rQUhQQgieojoJXoZRmcY0zFMw2BMYWYMZvQaPXovUZLoJYheghA9iF7SpCekNzzvta77upPHOb/X +T7POb8/zuv18PrY+9p7rbXXXnvtvde67nvG+XMF7q7cWvxj88SfpiabefQ4t8n5rzYPsO7Ds/88 P3r8+LHbnB08/j9//n/z5yF45MW3rJ08y5rnAk+B3CAPyAueBvlAfvCM4wKmACgICoHnQGFQBDwP ioJioDh4AZQAL4KSoBQoDcqAsqAcKA9eAhVARfAyqAReAZVBFVAVVAPVQQ1QE9QCtUEd8CqoC+qB +qABaAgagcagifq2Mc2AH2gOWgB/0BK0Aq1BG9AWtAPtQQfQEQSATqAzCARdQBAIBiEgFISBcBAB uoJuoDuIBD1ATxAFokEMiAVxoBfoDfqAeNAX9AP9QQIYABJBEkgGKWAgGARSQRpIB4NBBhgChoJh IBNkgeFgBBgJRqnuyfxNYy1aITcNWcLxn/8pYnL49rucBxU4N+TPIae79b9pS8++cNdsPWCVIrvT ZrF8MrNKwaKxOtP/tT8FOYX+7c//Kd8Qb+lh3AFYPZCZ98aKNfTvf/6nqPFYOQNlTv/p+DnAhjPO SWq949dk1E54QxorPli94D/7U/x/Y/6yTqOcZfKd3/KY3avbf7r/H/23n07/589/9x/LKmbL4/ju k3tXzu2AfnGDklOT+6SV9h/QL6X5oLTSbWIGDOg9aKie+AHBUd7mqP+H5p8bbBv4f+eL03HGx3d/ yWGtf3JiYnpSv7iYtH7JSSYysmOLmpGhwUE1I9t1Cg5p3rFjcGRAcOcG9QKDOkeK8JhBaZGByRm9 B6UkpUWm9E1Oiusbk1YtI7GPXkv82ZStyuCvLxb8j3fS/86fl6et9Pyv0Of7nybZ8P/FJP+/+jMa jAFjwTgwHkwAE8Ek8BqYDKaAqWAamA5mgJngdTALzAZzwFwwD8wHC8BCsAgsBkvAUrAMLAcrwErw BlgFVoM1YC14E7wF3gbrwHqwAWwEm8BmsAVsBdvAdvAO2AF2gl3gXbAb7AF7wT6wHxwAB43j54fB EfAeOAqOgePgfXACnAQfgFPgNDgDzoJz4Dy4AD4EF8ElcBl8BK6Aq+AauA5ugJvgFrgN7oC7QALv T8Cn4DPwObgHvgBfgq/A1+Ab45y3/x1nrnv2y10gz94NZFYQiJ0hEBvEXWXlJrC778ktcELvbrkp 8np+f/z7Y6k97Xm9yL3C0pHNPmWcljGeZI9DJVLl5qiQ8xluDv9BvWPSkgc1LB3QJiI8oLXGi9JT 1rA9UtgasQN6l87ol9a3dGBQrRo1q3Rq5V860L+qPsgIHuvREazIVc2z23zO7cVdLGVOSrm9/tTx dVbaXtU6N9vfvl3rtFqflKMYo3y2u/YwUUoeTzaT35PdvAReoe4HWno8JgB08VgTQhlGWx8QDaKg i/a8YGI8tcEjG+t5DIwnBoVjPB5PrCcXZT7QkHp70J16JBji6QV6e4Z6+lDGe5/jeI4BUZ5MTw8Q 6cnyRIBQ6tXAK55hnrwgFzTZwCM7xPMl+MwO9RwBh+wwzx7wrs307KTcBrbSvhmaTXawZ6NNo4zn uZtniw0AJenPB/62s8Es+6edaf+w0ymngSn2L/sa7ZPsQzsBjLWP7Cj72A63xjPUWs9g6/Gk2mye AaCfze7pA2JtDk8ECLU5PUEg2BaiLO3pYqt6OttGlI15bkp7M2j8POG2BWgJT2tPiG1PeycQRr07 6EW9L0iDLwMMQcYwTwBoz7wqgbLUfzTDPN+YTE8siKEeDaIMdjRDPD1NhqeHIt0TadIoE2nrTV8P 6MJAM3jqw/sqZW2ea9JfHbqqnm54QYSp5Ak1FTwhprwn2JQBpaiXoK24J8w87wk3haEp6OlqnqF8 mufctOekPxsw0D+0QeYP28X8ZgPNzzaAsr353bamzQ80od6QtnrmV1uH/prmR1vN/GArm+9sJfON fcl8ZcuZL21pc8+WMJ/Y4uZjW8zcts+bm7aIuW6fM1dtIfORLWAu2mfMBZvfnGM/nrS5zPs2hzlm cyqO0LYfvGtzm+1gHfU10KyAZjH9c3meafOYyTavGc+uGImcYSCNejLoQt0f1KFeyz5takBXFVSG 52VQDplleC5NX0nwIvUXkP88KGKzmwLsrryyi9l5jzhbficmfQC+IQK5x97+jF36MXHnHU6bW5wY N8gzr5FfXuGs+Iic8hL55IfkkefJW86RO54h7zhNrvgBeeJJymPkjkdoO0g+uZe88l3Olh3kmtug 30QO+ja56CpkLCF+nkc5g7ZJ9I2BdjjIgi8LOUPIPYcgM4O8czA552Ci9HTyzTRyzTRyzVTyzFRy zEEgiTyzP+hDPZYymvwzCpoe0HaHJ4IYPxT+INCaZz/aG5Grvgp9DXLTKuSkFclBy5F3liTPLA7l 8+SSheB+Fmn5kJyXPPAp8oXcZEx5GS0/2cKz5IkFQCH6CqJFQXLCAmj1LNo+g/bPkPvlZ2b5uePz ca/n405/mnv8aWadl/s4L1bIxz39LHd2AaxRkHu8EHd6Ye7256EpRr0YbcXpL85d/gI8Jbi7X+Te Lsl9XZJ7ujR3dBnu5rLcyeW4i8tj7ZewegWsX5E792VWohJ37Svcs5VZnSrcr1VZqercqzVAdVax Fitah5Wtxyo3ZLWbsurNWf1WeEFb7sqOeEQg92Qw3hHOPdmdO7Ind2Qs92MfkIj3DKRMoxxGORKM N98y2/tEKg/Q/kcijwdofJ9I4nu0/JrI4B5RwOf4yqfc/p+g1V20uoNGN9DoGv51Da7r5mfu7t/Q 5Q/6/oLuIXzWfsVd9y23xn38+GfunN/BXyYXl2Uum90+xd/c9mmbxz5r89pC1IrY/La4LWBLUStD rZIta1+2FUBV6jVtFVDd1rE1bF1Qn6dGtpZtYmvbZrQ0oaWxbUib/NvMNrDNafG39WxretuCDvZV GwB/EAiBqyuIRHZPxohm1Dhb1Pa2BW1f9OmPhon2Ibv5NzPQPmBnf2PS7edmiL3DTr9msuwlM8Ke NaPsCTPGHjHj7D4zwe4yk+xWToX1ZppdbWbYZeZ1u8TMAfPsYjMfLKS+HKywS83bYCdtu+xCMIvT Jtns5rR711YE2al7zB6wj1NgP+UBcJCTQe5e5xb36Luf8tkKcd+SVnDntgR+3Lv1QG3u3ByAawce QXbq2WnLYaqB2tQbAbm3A0AXvbed90flsxU28fT1oS0OcEebnnqfe7jXrdJ10Xo2veO7QtsTxFCP 0zs/O7eGR2X0pezjrZdV2c8QB2QnHsihZQxlHOhFPd7L11vjhWwq0ymdutAXVRl5TKynF2jvjSde 0D6HXuq1QS+lya/0Oajf1udoxW19LqJ9ueF/SCwiMclt7YumHkN84pbS79LGEq/EarxiiUEMeKT9 MdSjve3FlTYvtMV4zgdNLm2X/hhvnBPtKURZjD6hKebjiSPuidP4p6G2C0000Uw0zzG0x2hc1M0j dP/oFKnP0i790Ro3SenUpf+fuWbwPETbohVDNI5yS+l31yleY64MYi+JuTK0T2h6gd7EVn0o4xUZ WvbX0qm/rDIKmkjPcOKzLOK0LMYg7oAvDvT6F6/IjtPxh0Az1NOT/h6gu8Z1guGekiovH5GFxHYS 40msJzHfcO0XuggQCl818ApyyisyPc8p71PEq5n6LO3PAHl+BhnPUErd1fkkcdJn4EsrcaPEjxJH SjyZ6eUZSn0obUPoGwJNBrQZ8AzxnAQfaIke3r20gZhsg00npszQ+HKLxpsSd2YSf2YRh2YSj2YS lw5TPuE/Ag4x9jaNSQcTi6Z51nvliDzXXzYTF24mPt1EnLqReHWDxq1ptMUzTjfi1QAgNH6+dd1K fLqFWHUL8exm4tpNtrr2b1WUZMx84G+7lZhWym2UWxX/7INZGgc/1Dbpmw3mALddSteeE4iFJ4HJ tE+hfRp0M8BM4mahc/j+4Pl34uk/7FQwmb7XaJ9I/wTFI9ta5ZUxwRov5yImzkUsnJM4OifxdA7i 6hzE19k9KUBi7cFgGAfgcOLvUcThY4nHRY7IG4MuI6ln0TaUvsHQpEKbDCRG7wNikRMEuuh4UubQ uozv+mMgcXoQ8Xowcbu0d1GU9gTS1om+zsTwUnailLrQV1DeAkbi+AiN6f2YSzPkOP0OXRNv7O9H bC/9LTxh1h+0hL41aKV5gCsrhNg/lBwgVHMByQk6UW+vNEIbbNshrxMIo95dc4UgzRecUvhdnwrC T4PwP8klQmyK9gUpUtErA/0ytBS60sqT33TCfwMVw5j/MOUP8tIFUu9EW2d8Weg64/NCK3X3PG9C f2PNVSRnyfTSDaU+lLYhniaKYT67x5oszx/AQFcJVKeviWIIec4QTwn4PiKvOUd+E6vI8vl/d3Kb 7prjDAYZ5DdOHhSteVGW0vekryc0PZTWoZfStTcRrOZDUaY1CIO2B7S9kZeodMLXk3oUbdHe/CnG dALNkC+89X1zlxwqilwqWnOq+tofR44Vy3OMqUFfNc2z3Ps+iNwqyJQlXypPflWB3OllcqlXyKsq M3YVdHDoHT55rkx+Vomc62VoXwLCJzLK+M68cM3HCpKPPUf/8/QXQ34JaEopXYiiFH0vQlMc2qLI K8yYBZH9DKXwP+2po/KKEo3+YjuDQPK1LuZP8rqHNoQcz8n1ciIjt9ILX4TWc9AmfY+h+9sGk+8F ked1Ic/rbH7SMpB8T+oiu62OU9aUMl/YsuR8L5mvOW++JRf8npzwvuaGkiNKrtiQvLGJ5pB/Wn/z F+fIn0Raf5Bf/m4dPX+yHaFrh66taWuqeeavtj59r9JXyzyw1ckzq3jzzAqMV45xS5vPNdcUHdqr PuWIzY4RaR0nTzyhuWVuc5r87gy54Hlywg9tQfLPQuShhc0N8tJbtqi5o3nqC+ZTlePI+4znu7RL /03orsFzGd4P7bOat55F3mlkn9Dc1clbj1sZO5t3fKm7+zkHOW0Oc1Tbcqpux+A7Cg4D6RO8p6W7 R7JrrruC/jXMY53mw7mIRIUmlzdHzkNbHvpyK80K6Bdb4XP3yNOaD0tePIw8dyS046GdDP9M5My1 zhiLeZ5L+0zsNAW68cxvFEi2wu+eL/nNq96c2p/2LtBGa39+hT/5fB1QW8tnvXXhqaH8RcgKS6Nj GcYpDyQPl3xc8vIayKmltA5PTcaoTltVUJn+l0E5aMuAstaR48oq7bvjcpK75ySHf8oUo/0FeCSv L6k0wvc0ZT6e85kStBWFrgjzLqzlU5RSFxm1VN7z5PufAzIpMjZLZmbM7/KWk3oOovm8rHMBpRe+ HOZZfWeQTfsewfe7yQZPNnizIyMb2aArT8pOOsZL5A8nyThPkIGeJCM9RXZ6mmz1LNnreTLZC8Ta F8l0L5PxXiEDvsYaXNd3DrnJ9HKRDYoskZ2Hej5zm2z6JhnydfOcuUp2LO8iLpMNXyQLvkAGfI7M 9yxZ7xmy3VNkuSfBCS2reuuij3vGlTKb0WUbfDvQaze8+9DxIBnze/AfV1qH5xjPR2g/oBm1ZNbl 4ClrtsK7SeVUUZnP0Z7F8xh0mkS2Ltn7PMolzHUVbW8rrfBI1v6itknfPMoZtL1G31jvO5ARKqu8 yn0WGw5Ghwx0GML4w0CmvidxaEbQnomNM6EZBoai81B4hqDXEOV1z8z6+r5kIFn+IPMqqMNzLf3c NY28LB36dKUXvqqMVx3U4LkW7XVAXejqgQbwNNT3LlI6dZHt7qX6JgbE0i/vY/pTT9J+oZP3NI1o bwhNQ2hcWind+8rpi9Y2oWlEvaGJ0rKxty40rn2qmw5A3u2EmpomwtTmBpZ3P/WUNkbp63ML1jHd 6AtnPkIXBDoob5DKqWgS8Lr+oDceF40ndsfj5B1QFzK5jqymvBvyZ+Wb4QmNsFR9RnyVv7UZoabx Q1ZrlVdT0Zp25z1TPSzXgJYmWNaPlZL3TO3whgBWP4hZh+PRkaYAmubHMk+jR270yO3TR0r3nOnL DuiHTv0o+7NrBsCTCE+SyUvp8uSmXd5Xiax8+q6qL3OJZ4x4ePsynpTxlH0VBX37YgT0mWAIPINB KnwpjJMIb4K+6yqoPAnwJ4GBPKfSPhiaoSAT+hHwiZy6KrOYvudaik0XgwXoNo9yBphG+2tgInqO BWPgGaHghEaOvDebCF6jbRqYAc1SsMT77mwZMpYq8vp8YRYnw2zWaw46zkO/Bei3CP2WIsd535YX PfLRlp++Z8x8dJ5L/0x4hNf1Qdm9M9m90iZ903mewbOU03R3OzvcjRP24hO72Zk70WQ767sFP9nE jl7PrniLtZZ3davY9SvY7UtZ90XwL1CZjtxZYA7t87VPaF40y+Fx3vOVQkYZsw6ZG1V2eU6ulziF KnAaVWTsl80eIDq4e/0Dfb9XnVOsmnkfvzuGvx5llQ9zQhyEdr/yVVC+fbQdoO8QNO9Be5Tdfxy+ E/B/oO8Ia3jLmt56dd+7jdNK47xLPO2lPa3P1XR8qQcqbQVuiz6gt/kKT/+S/XiPHfY53v+ZCTaf mM7mY/aNvG+8zQ65aZpz0jfhpG/IKV+PU74OJ3xNr+wanPS1OfVfNZfYhR+xx+Sd5XXTAr5W8LdD TkdujUDkhphPve8s73EOfMF58pXq4egipRuTfKPvL9PNt3j1t/pOs5/2f6Xop+85v6bvK+i+gs4t hc+V8R3e+h3n/zdmPBiJnGHaL3RfU//K9250Mu2TffRSuvfIF6zEF6zUN6zOD3jTA1b9R7zgJzz+ RzxE3qkKvfD/YF7neQE0yyjX8LyBPnm/upv5HlRZ7t64zr17HavJ+9Xb3JPyrvVTvOMzvOMeKy+0 wvOZ953sHTzgNqt7VfnO64f75bPlpP4A/KhtVxU/apsbl31lPPYLY+zn5jFyHrIOfyHnd9bmV8b+ WWmF55r5hWd5t/sna/9IPoO1X5rsVvg7qqzyRt7VlgWlbRH7oi1I7Vn7vM1nC9m81PLYp21ufdub 3cq7X3kHLO+C5Z1wDnsfWd+abCrvS61LW07v++Jc0D4Fj/DmhjsPEvPaZ5BYEPlFqBWzBWwJ+5wt yYil7Qv63tjND1/R98elbUV6y9FeRnV8gdYXbXnaKtJSUWnKgbJW6F3eSrYGzzVtJX33XME6sspC XwFIey0tX6aspKjhi9tq26a2Dqhtm9DTECp5Vy3vrGvbavoeu4bSC19lUFXb69jq0FSHtoZtBJW8 1/aj1e9fZVNfzhOh769r2RAQRD0AdICqLWhtX7X+yGpu68Ehb8UboEVDnhrR08Q6+vlBIb1N9I25 /NsMmubQtqS1NdRtQQeoAuAKAiFwdQNdvaXo4N5JA+xD049Vimd9erEmsbaojbKlbA/s1Z0ZC63w 9GC2UbTFsBK9WL0+rGQ/eBLgTUKGyHHzqOl2qZlqV5MtrDMT7Raygp1mrN1nRtsjZBInzHB7xmTa i2aovWYy7B2yjM9Nqv3apOBBSfZXlSUyU+xvZpD3Hf5gaIZCm2mvw38JOWeRdxK57yF/P+PsMq/Z rWQh6xl/DRnJMtXD3Tdv67t7eYcv7/Llnf4iMw/Mof46mEmf0M/Ud//LzCzq8q7/DepvK5b4zmV5 978TXmmTvp2Uu8A/5WLjvrfcaWd5PytYQsa1EMjnBbO1lD43z9tFBrDLJmub9O2mvofMdI9+npDd 2++Urq/LZwOH9PMF+ZzBmn3WQG/h9yid8O2hdD57yK707rcEHj8+6PuWgMf33YLBKrmB6ep5Dqw0 EZ7FYKkJ9yyjXAFWmhDKzqCDZ7lpBOpRrw4q01ccFKH+LMhD32O7nHx9GRouQ9OFYBZaTKWcQNkX dKBeHQ0LUD4D8lPPT/m0OQcukoddATeo/wkekYPV9eQzDT1Pm6bAj3or0IZ6exDgyWsCQRD1EMow EE49HJoIzzPgWeZVUOf3729IyCcybnQic+ymeI66oB783SlH+PqkdOm7epbQv8TX1xWbhYOuarsF 3voS/ZZw+WyiyxtqW4dPaJei5zKwUm3s9K9SGqm7N1cRte8b2PkN7L0Su6/E/rIOsh4rTbCXXmSE YPvOyKwHalOvDirTXhwUoS6y3Ox3v67PcvMD+NnKusn6rVQaoX0W5EHOY+j+ZEccAAehFb790B/w 1guqvFz0TQALtE3oDrPuh7Vtgu8mP0ief4A1P8jaH1If6Kv9Qvce9SO0HdY+8YuC/6J/1pcJHcIv DoID6jOOTKE9THlYfSg/ZT7KfD5aKd15N8U3GoK6HvEr8a+85hNwh5z/FHjfSy/8P4HfkFfXkx+e fPDmM020zOtbnyD1vTz4YB58MS8+mRffFB99WumE3g/+VqAN9fYggL5AEEQ9GPxT5vVlDeKH3dRn xXfzs775WGfx7Tyscx6lFZ4Q5ISCMOph0IXj7+GeAtAXVD8WOe7u3/HqP98Ryubb/R2tjLjajCYu H8nJlEWcPAx7ZxDlpBPTpqLTIGLPQcSK8m2BDDCMehZx40jaR2OLccS5EymnEPdO5/SdRSw9D/5F YBn1N2hbyxq8Tf8maLcSD++Afzey9hOHHiLuPEpMeoQM5zD1g+AA7fuISfdAI3S7GHMnceo7YDu8 m8Em6htoX0f/m9Cvhu8N5Cwnhl1CnLsQzCOWnUU5CUwg2x1HDDyGjHMUmeNIss/hxLdZpg1zake+ 1YH5BXAidibCDASdmXMn0JG29vS1JY9rBfyhbQ78qDejrxm0LbBRK3K7tuRxHcjnOhHhdiEnDCEq DiPiDQHy3Il8rz19baFpRQTcAh4/eJry3JTcshn9ftA1h6+5iWOsGOL3KGh7oGd3+CLQNYwxQtAr CH0D0bMT/7anRXpakZe3NF2RHIGECCSGIzmU2QdjjS5YoiNoy7M/1mgGmtDfmFpDUB+eV+Gvpdl3 Z9YuiHUMJV8KoR7MOkumH8xahUAbDiKweVd4urMGkfD1ZF2i8I1oaGPwn1jWvRe8vZETT741gNss mbNxILlZKj6XTs6WAYZxvmbhh+KLT57Ubh4mb1dSGT8V+WnIHqxvccqTJ5dhLUuyrsVZX5FRhLy3 GPJKsE6lkF8O+gqs0SuMWw3UpF5Ly4GUg7xvbty4cIL6dGX85RVkVUZWVfX5odBk6F6oqfSD9G1O bdpqo38tdKiBX1VHh6rwVkFGVd0bbily3ZjpKLY7ih0PMbv98O+Gdye826DbxLjr2DNr0fkN9tAy 5jgLTKc+mfYJ/9pzM3ieBd08+hYpbQWzErusoe9t5GyEbitz3oH83YyzT/dcXd/4UrZUnUqTX9eG vhbj1yQvlr0me072Xk32YC3l3+OVsV/3al2VdQQfcOW9R/th+g8qTS3y4po6t3e985P9K/o4e7g6 e7gGc62pY7sn9Sw8dR4+uZBS9vJy0wA71GdOdcnd6yit8LxJuZrnlbRz90HbgOytoe55keHaOpX9 kY7vZ+DRQ9gzw9g/mewW2fsj2DFyFozG8+VsGMdumMCemMT4k/X8cM6QGcieDCZSH0/bWPpHsldH sNOysGAmO2aonhFyVnT0jhmoZSo7RsaXuutjQxhvCPwZjJ2BDoPRJR3eNHRLQ8dUdHVlDGaHD0Zm Bv1DGGMo9EPhG4aMYciQMtNbF7lujJnhfZb2ocxNzqsM5jdY0cxXZui7NWeP9dLzKpxzKITzqAv7 tZOeaQOxVypzTFd9/ZQvlbkPRJdkdE9EtwT07oe+fZivK0fKOE4Ht+6+e0tGRjIy+mO7vvDHw98H fvkJll6M7fLL2RmPHn31TO0AfVt0kp/x8Wfs5sDPV4pMNz/vg269QTzoR38CYyWBZKX349xtynMT 2pvQL+duM3j84PFTXjdnboXurf+nkzcUDQOZYSdqAWjYgfOvPRTtOKPbcva15txrhf4tvTr4Mf8W nIf+nI2tOCNbc0K38UqTU7uDnuNyistp3oG5tkd6ayTLWd4K6a4OUrr5TUO4GkLbCNrGaNIEaXLW ++nZL3dAN6UXfn/am+s9EAJdEPRdlN+1lZz+jeltBKXcDQ30jnDoGlFvRFsTJDaFrqn+baZ/m3pv DjfSbcoebQpnEzga829jH30THUHuGD9o/BhBaN1IKow4Ue6YLpzTnTjDWnE++Otb4DpKJ/Qt2OMt 2e9t9F6qyKzLK18IfFKGc86Heutu1BnMWRQCXzCyQhgtFOu5PMF6t1VhTHl7XRfU85XC50ZjkfRH 4rXyzUd54y13XTh0YdCFemmFJwQdw0E3+uQu7KF3YS1fKXLcfRmN9CjG7sm90IP5SJ/QRDFONM8x tMdyxgud+z0K917LAsOoZ3Bfphu5E4vhy8Xx5RfYFy+yP0rie+XxuQrIeVlliKw4vYflvXxp9mop 9kFJ9kEJ+F9gLxfnbJA7WO7MooxTVMeSMcdSunU3bpygOjU37Wxp08GWJI4saQLsi6CECQRBPIdY 1sKWNxG2oulqK5lutorpToTf3dYy4bYONHWhr4+MhqaVbWSaW3zJNjP1bAtT27Y01W1rU9m2NRXI icvaAFPSBppiNsgUtqHmOVDIhpiCPBe0XcyzlPl5zk97PpDXhpvcIJeNMDlAduo5aM8BTU4bDILM U/DlBi8wZinbmDHqM9arphL6VUXPGrayqWNfRp/y6FbctLAvGH/Qkvm1Bu1sKZ2/G6O4a9sFmgDQ AXuIbdoDoW2PPTrRFgg6wy907pnb3dY2kYwbqfapgq0qYbcK2InYy8p3aEoqvcNXimf2C33h2DbC voJ9q8JTHeCjtqZXniNT6u49WAQbFGf+YsuytpOpSNZV2bbD1m2YaytT3/qzBn7Mtxlr0hidG6Jz A8YjI8Y2Ikvkh1EG8RxAezv6W0LnZ5t416856+dvqiHvFeTK+pWxHc2LtjPr14X1C1E93D0qa1hA Ecyahmqf0DynkLYg0IX+QC0LUkpd+NzMMDdrnBfI+j8DHJmB1B2/yAeeVr8INXlsGGsfpjzu+51s 6h9dae+q7dKfS9vCWdtw7XfHysM88mC7XOiSE+RgjOzIz47sbF76nDyLb+UBedFDeNwYq7ktZhqw puJXtVm/StjzJfaD+F9J9sEL7IPnseFz2K8A/p+PNRJ+kZOffVAQexZmbxTDxuWwfUX20Sush/hs TXynEb7RFH8Rf22uKMbaCIpr3f2em+OTpUxb/LGt16dbqY+Lrzu0wt+Cdn/QErpWSlta/V78uZ3W y3jrpf71rumfbDO779Rw34i2x7vbsrtaoW0LWw3NqpsmWKEhs6iHJeowo1p4VnVmVwXPqoQnVsAq 5fGuMlimJDOXshzPL9FXEZpXsJ68162FrDrIrIv8+ozTCAu3QMtWtpxpg8Xb2pdARdXhySzD/aS9 JCdQKU6gMpTl2Q0VGecVvLsKq1OdsWox1qvoV58d0BB9mzCun62BlaozTlXkV2Hnv6JjtKFsiS4t aG9Gf2PoGkBfj7nWgb8mc62GPGeejZhnE51XGcZ19ZDSvSlbYOXmoBmr3Jj5NOSUkHnWQX5N5FdC L7HHS3qiNf3XXJqr/VqwUq4MKV25om8H5LTnxGuHTMdORD/Q+2O/FkpflrmIHaVf6CoBZ57C39Er Q+pPvmlwve4AN+S7YCeRwFawmUhhE9hAdPAGWEV9De1roXmLm38dN+sGbtRNYDM37S6wm/oe2vfR L/KeXEc3wlyJrDeIPDaATcjeDLbStgPI+AcU9dGnPs8NyEwaqE4bwDrlbYQ+TVTOCtXPqbt+7PA3 IMupR5ZTF71EvzqMU4cs6lWylFfJwCRjqcd86pOpNEBeQ5UhclcjU+b6JniLvnXQbIB2E9gM307w LvU9tO/VcRx9ZdxDyJCxpf6krd2T5iKx5AXO/vPgLNHmaTQ/BU4SQ71PXHEMHCXWOgIOwXWAmGs/ 2EustZt4cRfYTsy2A+wiDttDeQgcIR47St9x6E5A/wG8p5FxFnnnkH+BsWTsJ9fFvYV2qfwWyPNn DWXclsh19Diqeol+bdCzLbJF73bIbo/s9sjuYD4kIr2o9XbMrZ2OeQb6U8rTGp1aoZvIaolMke3P GC2YWwvm1pyx/bCrn+rhvtPdzvy26TxbaJ88y9yl3Oztk7o7B1eHDxn7POPK3E8z1geMdRIZxxnn KHLe89rsgNqvKfKbYM+mPvn7tM8PGj90FR7h9WcOLZHTijm11rmd17E6eMfsaK6QK7h136l78J83 /Dl83nBe3/HdYwYtGbE1+XxbNGgPOuJhnUAoMw4lX09Ci2S0SEGLgazCQFZhEEinnkHbUGYzDGRB M4JyJG2CUfSPQuvR0ArGoL3gNWYwgxnMAYuxzmKstJSZCJaweovRfg6YZC5Bfxl8BP91xRhzA9wm 0vyYrPsz5HwO7RdmIVhN/W3aNppPzBZzlxndYQY3Wdvr2PIq2l1Go4todgGtLqDReTQ5z9qcRYsz 2O6M+Zb67+j1F/ibnodQPETnR0h4xKo8xksey8/g2u1gM/UttG+BdjM8W81v2PNn7Hkfmm+x4ZfQ f4YGH8N/G9zElo42e801+q5DcwvaO2h7F75PkPEZO/0eO/5LZvM1p8C3nArfc9L8gIV+MIuoLzBf mfnQzYFnFjKnI2sKVprI7MYwo5FgBP4/CCTRloQlE5l9IjQDQAJzTUCH/qAfvPGUvWmLgTYay/SE LxKbdMcC3bBAV2wVge0isF04dgxjFuIZIeydEGYRzCyC0L4LVghE80DOrc6cYYGcjZ3NcnxyCV61 ED+dj4fNYW++ju/OwOumgeH6dqQtmUh7Rm1P5tNBEQlPd9AN/gg8Mgz5wfwN0kw7HMnSI1Q94YpG ahxSeyOxF89x9MXCEYOG0fBHIasn//agtydUUSCaegyI0397kut3wx7h2CkYjw/EbiEggufu2CuK egze35PcqDveH4H3h6J5kMlEl+HoMRIdRqPDGHboOPbVeHbsRHbuJHbwZHbyNHb1HDCP+jKwgvY1 4C1o1oGN0G8GsiefPCXduHgXY+7S/Sn7VPZrG3ynFdb3x3dawtuaelva2oOO9HcCocrn5uO7dW+H 0Bai7dK/E/u+C+R5tyJEaaTufoZ5CAvs9so6QP0AVnJL6XPfQRzHKifIHk/ggcex2FHOjvegOaxn iUufwrP0DcKzhC4VyJkyWPndvOk9PPmoIpO+odonNO9RHuHcOcy5c1jPnRG+U/skK/C+nj2jlFf6 j9F2XNvH6ll0Ur9D6NjjNLvqtJ5Fc/D46fRN8soQOOfVB2YuWKy0bsx/nvp52s7h32cVizlDHBqH dinPS2lfBs0yzrTFyuPmF3K+XWCsC4wr7dJ/kfpF2i6jp/S7Y93Es24wn2vgKp52hfIyuES7c06O ZWeP8Z6RY7UUHndN7nGafMkZ+SX78J6ZzVk5g9NmMifPBKUT+lt4611Okk+95+o9pV2l56rwuxHU ZSwpZ+k1VuAG58AtTkY5az/Gkz7FCz/Hk4Ve+D6l/jEnpJxwt/Ec9zy+xMpcVjiyLuu3oZxo8ByW O4vlpJTz+QIr8CEr8SE0F720wnuRVb9AeZ628/Sfw+POQXtaz/NT/HtK6yLHtfk5zvezes5f0Xbn 7ydQfgvP79rv7rUTnO8nwQec8XIXnAJnzZ9Kc0bviT/1rvgAnKDvfb0rHiqf+w5tM7ybuSv2gQO0 n1A8xAIPscQjLPaI/fpY6bbonfKIE/Sx8kjd9dFNjLFJ75mHPtqt0G2lbQt9cge5NFK675MPYHm5 e/aysu9yZ+zgpnzHfKN31FbzE3y/Kb3wb2NO27m/3qFvJ/bYpffX56zwHXBby0Na3la57vcPDuqK Xtf7bT/ecMBHfwv6m+y/65Q3fHRSuvv7AF60H0gpNA7tVWiu0H6Fdre85rPpNp3Hx+h4B/1uEkFd 93rVNaXdC/9u6rto20G/eN525r8FbxRe1zYLuUsX6b16n+j7PrvjB+7b7ziLv8Frv8LO95Re+DZh h/XYTu7ktfSvgm4F/EvBYuqLKV15UrrvCcfgtRPw9snszmno8zo2mY3u85An9/hC5Re+r3j+jFPG udNnMIcpePlE+MfgcSLH9YUMvd/lnr/Azr2gfUIzCozAQ4eAwdQzFOd9dkv2xgKDaMtQnIPuLCfv WU7ic5zIEi9c4L67CC5pOcBbF173LOnHPPqDBGwsccQAkMT8ktA32UsrPAMUl6F3Yw2HT0rfp9rs oEh2Uw/GjmIe0fD0gjYe2Q691K+YPsjvhaxYjVHOQ3sWntPwfgBOqhw3aw3WuOQgt9RhbrQj3OgS txznxj5BLHPSO+ZJbvET1I/Tdgy8R7/QHoLnALz7wH6V5X7+1Jl4phM3dmeNbyTO2UKEsZ0IYCd0 e5Q2VCG3p7RJ32ZonJjIiYfe8PlfKzMVSAw0gxt7FtHDHG7t+cQ+i7i5lzLWcqUPVCzneQlRzUL6 5kEzG9rX4ZsO/1SigGk+eVK6511r/XR6uLYJTRs8qi3e0oa2dvRJv+tX7fTTikj6JJLqT99A7W+n iNPYzKWR0h1D4rYOGrt113aha0+c1AF01Hqkz4ZBWCOQfzthoQAs3dH7SUkH5YtU+gDqAaxMJ1ak s0Z6EvGFwhnijQC7+N6R9kHD3swuljKamfVQLUSifAbTSTmDvJGjSIjgWSRH0h8FXYzGim2R0wb/ aq3y4omjRGYf/T0Gzlr1hKonFFGMEg23xJSx6BOHzF76+VR7pRcZcVghlrYYxoqGJgranmjVg1ok vZFQuaXIdeOWaOpR2ua0S38PpEaBaEaI5Vlo3HsyRWPUQFYqhL0Sht5doequmsaqnnHKI/FtPJL6 MfP+6DIAS6Sgt/CmKAJ8dfesGICMAUhIQotkeJIZwx0vkXoi1h3gjYsToJOyv5bRyuvOKZHnZG9b gsqL5TlWyyQ0k3qifivA2bsjsN1I/Qy2A9FdJ42vB6NvGjoMYrwU5DgyY/HOKM6uSPq7cpaFER0G wxeIjADOwvYqy5U7mbh7EjH3BOLt8cTaY4mXJU4fzXqN1M972ynPaErZHWNpH0//BHxBYvjXwBSN 45urLNcvtmu87s9JIPG7xPESz0tcL/G9xPnNlF74loEV0KwBb8GzDmxE/maN21tp/O7Kk/L/8r0c 72ePt1jPW6z0TWxwHVtcxQ6XsM2HrO95bHEWW51ifU5ik+PY7ijrdQTbHMSWB7DPXnbUPmy0Fxvv Yc57mO9+9sBB5v4ez8fACUY7Bc1Z1uA8PBfxlyvIuobM64xxk/Fushaiy3/1DTrR8bYiBlqB1Htp +x28Ufqk7s5rD3rtZaz9jHUQfQ+j91HGPM6YJ5jPKeZ1hrHPMc8LjH+Jtb+MDlexwS2f7Fj0jPTa oyu6RzAH4Q3DHqHEaCIzGHsEcdJ3UXvsY477KGX8PWofp+7GgXvwhd3YaLfaqgP9Adq/T3UNoJS2 dqAt7W199FK6n9Pd1jUTe3UnyonAhmHcaEHYNZC5dELHAHTsiI4dmG971qEd+rVFviNnj9bbYZf2 6C5r1AGbBHD7dcImnXWNPkTeJeZ2lflex0Y3sMMNxhTb3/auk/hRiupUF/+LJqaJ5XbqTXwTD/pT H0B7Iv6ZTIyTzM2TgM/25TbqTZwSS4wSxS3Vg5unO7dJV/ZEJHsjij0Sw37pzd6JZw/1Z08lcsOk kLWlsI+T2ZdJIIG2/uy1vvT3Yb/1gjaWvRZDvhwFfw/2aDfkRXBbhXKzhXDThTBmKDdiKLdfGHqE cxNGEK91Rb9uxGzdicciidt6EptF6ZxcP3Rzp82Mu1nn14v5xTLnaGijoY2j3ps9GA/609/PS9tf S3f9V6ktUrBJCjzJ8CSpnTYpbYLybYDnLdpXA5deSvf8mY6u08Dr6DoHXecz/nLssBJ+oXP4EniO x84xaue50M6CZzrznQb+Kbv5zp/hnIIjwCj4x8A/FpmyDhOZ52RkTEWGM3YEz92xb0/ONLF3L12r UboeiaxNCrKSffKkdPfxUGQP1XV02oUuU5Hi65PSvZfGMLeR2HYEegxnjCzsI2ufyThCJ3ziD8Ox 4Qj1lb7o0QdfEJ3ivP4Q4ytFnhs/TMe/p+ITk/GFSfjCRPxgAvMS3xG6ceqH0bT1pC8SOvHRcOYf RpQlPhWqMhqqvBfUF96C901krAFvYKcV0C+Dfon6nfif+GGw8gm/44/SH44/RrCOXVm3bvB2Zx0j kdND/fEt9bMY9bX1Xr/893nufrJ0E1vcxp63se0dbrRblDew0TXaruibO4mkE9jf/dnn/Tgr+rLn 49n7fTgv+nCm9eY86MWZEceZGcu5EcU5EcnZ1hXI27pwjW6P6Zu8bhr5SgR8Fh3Pe6NueQso0fYN xhF9/qsz/Tb63eEmvgPNTXS7iY63FAN9fbf1G0pCX4GxY9EpjvF7MX5vzrY+nFt90D2e6L0vOvRD h/6cgQmabchbyivIvo68m15ZIvOWPifTnqQZh7zFvATfh/BfQM455J1B7im1SW/mKePFcdbL+DGc mbE+XaR045wDGrGHAbFVJHaL0v4jSiv17rR1BZIVhHvpHR6pu3eX2OKW2iQBG0rmEu/NVHp6M5Xu mnm8r9lGBPb4J9M4oHXJPrqir2QkQhvJXHowpyjmJm9l5e1sHPbppdnQVebsZFMDGC9JbeOWosuT Z32yjQJ9TBoYbBNAmkm3Q3geYlItuxIk2mEmCATYTOMHGtssUw/UtsNNdTvCVLYjTUU7ypQHZXku S3s5+l+CtgJ8LyPjFVAFmdXsYFNCkW6KgeepF7EZphAoSL0g4z9vB9E/EDkp8Cbhb4mMlWAa2P6m me1nWtl40x59A21vE2aJh22MibXRpi9zSbI9dE5PnvUyxxSQDE8yPCnwpCi9QNrieY7XMtn29db/ +fm0dOrpStfbKyveDFT0MYMoUxVix3i1pUsvpatDOjYYjA0ymGMGc0n32j2duaXTlqZ2z/DSObRS d/kHYM8kkIxNU0EafdIvPKnQJoFEngcoOFWBlO5dU9GOZq1GsWYjsecIU591krXsDqK8tMIbANoh 3w80pq0eqA1Ndegrw1dR13u0Lz8sQ3sZXfdRrLv4wWjtF7ryoBx95dQnRiit+76wGnpXZc2rUFYG r6D/y6AC45dn7DJenvLqS1nIyzSVaH8FVIGmOrzV8CEpq1NWU2T47PWC+lmGtklfFVAJO1cEL1EX H3wRmhcUGUordfdn7Upoe7q2vahI1zb3HUUBmwoG47tDTGEgflwUFPP6+IvKm8az+HQ6/UIrSMPP 0738aVqGqMyX1X8TbSS+TK6Gb0bi12E2Fl/vhc/3Ni3xl2b4ZwP2geyJqnYA80nE9smMmcI4A1Ve Qd1bqegwiL6B2DUZGyTBMwDeBGT0Zx/1NR3w10BkhiE/knFi2Rd9GTOJ8ROB6JOEPqKT1F3bpHj3 mkMTrfsoxbvv/v0tDtf3+qFjDPrVQJfalPXQpxH6NKW9BTq1Rqf26BTAvLqgVyh6RaBXJIhi3nGg Dzr2ByLryXvI/SwiBvmxoD+y+yE3hnHcNind+6qG6jJI24TGfa6hZ84gX91dlwQdOxYd4tCFfF/t 1Vt1DAFd0DcAvduhf2vm0YL5NGX8RuhaT+3+zxh1GLMe9Ua0NaOvBTStoW0PTwC8XZARiqwIZEaC aOTHgT6M1x/0Y+wERazqJHX3nYvMuz/yEtROjq3EDm67lO7aNFaeEtyKadwgadwkqdxKKZrZd+X+ iKAezh0bTlQWQTQWQSQVThQVCkKIpDqBANoC9BvHg8g25NOxBBCvbx0iuIu6cud15z7qQbv8nnkZ 68nfcdeNe6krkKw9RnVJhy5d6eNALLKjgeiGNyIvEZ4E1dEp3Xqiz9/C0S0CPbuiX1fVPUvfFHRF hjPeAGiS0XMQyKI+knIMGE99nJffkSF19512gM57IvOfiB0maJ/Qh4IQaDsrJvjopHR1km86d8Yu nfUnPpLpG6Q/LdJRbThB+TpR76TfPJdYybGn/CRIILZ0+B0ZUndjFXnT0gMbR+qbHPxG7d9HaYQv FITT1xUaeTMTCeRtibzJEV43hhabcyMBWaeB2tdT39Ak+d6sxCkGEW2kgjTvmg6GZ7Dyiown41n3 WxA3zRBikaGUw4iJhhHDZYIsYpUs4pZM4rZM4rbhxEXjwThinDFgBDHScOLCLGKfLMqhxD8ZtKfp 2+lT6HaSuZxAz+PgKDofZb7vM9cPqJ+h/7y+eR5IbJhKPDtY9fivzo+byL8FbjDGdeiuU3dL6XPv vNvodEchcxjq7c+EV5Cl83JppHTvpIvUL+l8s9DF6RNa4bkB73VwFdtcAhepX6BdeNxz6ww+cg5I m/SdwVbngLSfxd+kT+ru3jqhdhP7DcdWYstRYCw047yyhH8cvGPACNqyoMuEJ1Nt7vKf0J+OceZ+ BlueVqRBM5j+odr/gfIOoz0DWenIHai07n1/FL98j7V5j7WRdTrGur2v65cEbzJ8KUp/Ttc1kfYB yE1gXWVN++m6Cr8jp4+v7ua8t3QNMoiDB2G/gbruZ5EhfvC+8jvjizyRfYZ++XTjIvSXmctV5nLD u/a31A+GqDypu77s/r6S17D1JP5OJJOcQOY5kQxwIpnkJDDZzCS3nEnr62A2OeYcMJf6fLCAvoVg KfRL4V3CCggWsyrzyXVnsULTOY0msRrjsPwI/g7jOZ2+VGhSaU2Hfgi8w8Bw5IwEY+AYp3o9+R1j 0W2S6jdV9Z3Mv6/BOZG/E3gaT/sE9BY612+mosdU1XsWeB19ZV4z4JuudA79TOTOpO11+oRmFpgD ZvM8R+tT9aeNnM+HZM5TmetU5j8NO0zz9jt0cynngfnwLgBLwRIvj8M3RX8Dr+OD49RmYj+x4zJo l2m/8EwEE7Cn2FRKoXV9cATrPAL7Dcd2WdSG0zuCGYxkTqPQewxjj/Pyj0OXMeg3Gk1HMdORtIyE bxT8I/EVV5aU7vkxjvUZgz+NAtIudKMpx4Bx+jt/HF+d7PWc12idRK+zhrKeQ9A73SsnjfUeTF3a hoHh9I8CQj9eve81XcGJzN2RN9m3/lb/f5/y2Urh6VlA3ryNBhOoT2QHvAamUp9Gm2A6u3AGO2IG O2I2u2c+WEx9GX2CpdAvZecuYAfNYffN4Kyfwh0wQd/W9WGMvujZHySwX+Stjoz75F2fgNYJaJlI mQRvMrNLYpZJqttIfeOUoBgJ/xjVtT+0/dFXyn7eushx79WBqvN0ZMkc3PnI3KYAh9bhn6JzTqA/ Cb9NBjLngYrpKkPqro8NNMtZxcVAbDFb+xwbzYbWsU8ytknBLkLr3sf9vbZKoG+A2m45fMuhXaF0 Qp+oWALNEmiW+HikdH2kL2dPPOiFPeKwT5zaegq2nkn7HGyxUOkHqJwFPM+hfQb9k1mbCUDWZTjt Q5E11CdPSneOYu9E1krWrL+3T2j7edcwQfsdGindbw+OfCz/k5Jzi+b0edxz+u3BSaYJGjTV7zXN MH6cDC2wmD+7uyVatjKLKJeatqC9WQnWmg5mA9hKfZt+ztHCbDfNefYzW8B6ZL1NtLoObEK2fLty J+179Jua8k3Qtvpu/AOinfP6rjuUs7w792qUuUvU8gmW+xRrfIY1Pmd2nzO7e8z2HjP6VN9VpXrP +WF6F9/B9z7G9z5lj32O/32B73yN33zLjH5gRj8yo184F37D3n8xs7+o/w0e0v5I/mcQO01h7VSF x05WPGbtHmGZv5H3F+vzF/L/ZJw/Wae/GPMvToy/Wa+/0eGh/K9V5L8WZCcHzglykSvmInfISRyf gzwhO7mBhxjfkAM8Zq4Piez+IgL8nWjvV2zwswk2D4gmv8W2X5p2zKUN85Lf0eNPnNGIWKsh918D 7sH63Lf1uGvrYkf5+era2LS2OYQnHgQHTE2znxN0r6mOzeVnsauZd/VnsyuxNvKzoxX050gXUH+d tsn6c97VmJn8bGtNTqzazK4OeJW6+MZ/9R3slnhyK/yiFbJaciP4Y93myPRjZzZjBZrCKz9n2YSV aKq+NYv+OfjLPGgXgKXwLdPSn7KlYokvempHvaViGbZYxvNSyqXa3pbd3IZS6m603xFf66i+uVZ9 Vfocesdv26vPbvHSbdXS3Vniw+2BtAmN0Mp38Vr8y8dbmHf0Mz2pu7dkE/Vz8fl1zHk9kD3g0Atf c56b0+7Hnmhq3mId3wbrfKXwu6dtB+KcdvrN7SP6zenm+q3snfoN5Sa6l9Z5eeUb79v1G8fN9Bvd B1mD95irs69EjqtfHD4UxR6JZL8Es9cC8aFOxG5CI7Qd9XOnC7oPQ/Qzp5v45B2yiI/Zi58qv3tS JuCTCezL/t59Ga979DOlEdpetPUGfdirfUE/9mICGEBdeP85xeR9503wqbZLfxL1JGI5ef+aqN9K cWik7r5hl/07l/03m708i/0ivy9/Ont8qv6OqK+4lz7BY+9qHC85Swb8afoO/rrKEdnyXn6w5gB3 2LN38fJP8PrP2AH3ODu+1LNjivkOj72vZ8dMPTt+13NjDmM7Ojh6SN1du+nsfTlDXgez2OOz2OOz 2eOzOR/mKP5EjuAvdshD5D6S/5lIz57pWj42Tt1a106v6TmUjTMpm3XkG+rGTqE+GUjp0kjp7oPJ yH8NTGaM15ArfVOUXvgfMb+/wV++UujdN6ejaBvtPe8mUp8EpF/o5BycxBwmgPHmD+z2B/R/6lko fG4EO5wxsxSPqD+i/2/tF7rhIBN5mXpePvZFYiP1zJSz02q79GdRz6Jd+twzYYR5iudc2palyOU9 b6Xd6ZO6+8lQIOvYFT3lrO2JLjHI7YXceGzWn3M5Ed4UeFLhyQDDTG7lF5lpYCA0SeiVAH1f+Hrr +f2IDPtvsvg/2TMP2Dvf6zj/nAmX2JdX2JfX2ce32c+fcF59zn77ygTgq0IrPB3xt/b4Xlv2T2v8 sqX+braLyu+esbX0bD/CeXyU8/g4Z/5Jzv5T3AFnuAvOK63wNGYPN2JvN9T2D+g/Ad0x/Zn9Ovoz +0d8smrp/zri6FqVu8G5J/Zx9svdIXfIYaWpozgEz0FwgDah2au/a6C68u1SfldX5/eFjDMv4zEV 8PKXOOOd31mwhrb17JVt3vF26e8tkPvoZbOae2gZWED9dWimQDPeJ6uK/p4GZ4/V1TtJ7qYR6DMC XeT3MYyCZqzSCV916s49JhgN3SjoBaN9/FK6b0bljqqrMkdjwyl6XzX13Xn/xEruG7vm+rsExut3 UPzYEfI9kobIb6x35Wjtf/K+dM/P5shvoTyCCdTlOyyjkTMGjMdnJni/YyJ0TtmKk8Wtu3ugEfrK mC6d+yxlPXadW3ffYrRQvUS/Ufp7DVz6hrQ3YuzmOv4YpWuhckdp3Z17N5VTmRNzGl46g1P1dU7V WXj3HDAPr10AFlFfTPtiaJbi9UuhXwaWc8quo9xA23r61sO/Drq3wEp4lnPrLDMfmVVgLZn9evAO Xr2DiGcHXv0O2ET9bbx8Ne3L6V/E7poL30xkTEXeFOROQb58E3qK6una3o3OrxF9X1cd58MzF57Z 8MyCZyb009FxGuVU2qbp9zZvMMfr9F9jjteY41XmeBX+a8xPyquU1xQLfXvprs51GfyLdCzpE5rr xCE3wE1sckuxjHGXgxVaunxSuufhx9jhY+x0V+mWo9s6X5uU7nl9Q+0pdhX7boBuo/bfUZs75S1w E/vdUrs79FK6fnlN12A5eq4Ab2mfw/MWWEX9DUrpWwbdUmz/Tym8rp9dZp0+MpvBevrWglXaL3SX kXGZtkv0XSImugSdlJf1t/w699YlYp2PWO+POCeuePsc2u2s/Q7Kd5TmsmKH1l17nYfmvPrKTm0X 2g8V27XPzT6v4x9XWPPLrOsl1ugi+n2IX13APucZT2g/VGyi721oVkO7HJ1kzecyn9fV527o94Cn +Gwo/vMxuKt++Bo2mwzNZKW5oT4le2cqfVPVP8XX/uGZ5ttr/3w7eiaYhZXmoskcVmMB2iwwb6LH WoXU59E2B4vOZtVfh1YwU3ld/3dtuwnazWAr8rbBsx3Z26HbqpiNlWfTP8dHt0n/jyXhzUV9rrdd +mf7Sml3134Nfv4W2MD+2gg2qYzZPM9Bz4Xou1B1F7q17IW1lFJ3/XgTemwAa+CVdqF9kzmuYwxn frOged1bzqScofRSd+Mlmc922jcDh0ZoZ6ldtipm+mi2+2xkfffXAXQ9yJgHFIu47RZCtxC+RchY jLwljClzXIjcBbQtoG8+NPPwtHl43Vxut7ncjnO4UeeShc1VmU9+++Ig/IfgPUjfAYXU53vb3b6F vjtH6tJ/QLEAuYKFvlL6XdkH0O8g+h7UfsEi2hZ625don9TdM2sj+3gT2EzfVtq367wdGuHbxxjb dZ4y50U6/01qC4dPSnfs9dCt9/VJKVgIzyJv30ItXXvvYe67WdtdlDvBO+qbcxlLfM3xI6EX/k3w OvYWfeZDOx+eedh7nsrZgxyRJXXf76VT287GBnO8Y8naCP08opj5zG0e/fO86y6YrfQHfWtm9X8N LZ+tjeltN4EtppfdZmLtdrDDxNmdPO+kfZfpA+Ltu6avYi/1vbTto+8ANIdMjH3PRNtjJsoeNz3t SdPDfmC6gXDqofZ9E2yPmkB7xARA2wGetna/aQ1/S+Q0R2Yz5DdhzEb2HdOA8euiSx272dRCrxp2 A/HGelPZrjOV7FvgbVPRrjUv2VWmrH3DlLIrTQm7whS1y01h+d1+dilYZArZheY5UIx6KbvYlKe9 Ev3VoKsNfX14myLD365GnzXottYEIT8c+ZGMF8O4YhfXv919GIeOcWqfd9RefdA1Hrpeis20b4V3 O3BofD+RYPeo7frZ3eBdeMS2YuMdPnnC00v73lUbx8PTB8Qr3x6fL8Zju3hsKGVf0M/b7/L01nKf Lz7oYU+xLqdYn5Os0/uMc4xxjkB3CPkHlFZ4eiEzzh5k/Q9DdwT6o/Adh/8ENvmAUtb2NG2nVZ7I defXFjkd4O2MLwQhPwQeWf+uXjrh7QYiaA9FZidoO6ov7DPtgPD7/scA1uBl1rsy61CVdahuN5qa 2Lc2tn4V+9bD7uInTbGTH/ZswZzFl1qjv8gReW14bkW7P/3N8a9m2LoxPA3hrY+MuqxVHWTWQnYN xqnGeFUYV3zsZfUzwZtaF33c86qi0qzz6uj0VdT6Bm2XunsfO764DL9cjn+uMC/gqyXxuzL4XXn8 rgLyhd6Rscbr0yvx1xX4tPAsM0WQUcguUVnufVfYLuB5gSmAbxfw9glNIfltrrQVBk65gHKBlu63 B8RX+zDnGOYcib7hzCEIPQIYvy06+aNDU3Ssjx610aEaOlRCfnnkl0JmcfaUI3cRe2sx81liyune EtoV8KyEdxX7eRXrIjLXIvtN795ax5gb8K2N+Ntm3TPxio2qU7xvv1lyWtG3ihlMbJZOfJVGvJXK 7TmI23Wgfo91vUnkFE3i9EwBA6mngjRO1HSQQX0EGEnfaDCGE3YMJ+xITteRxFcjOJmzOGEzKYeA wZy4abQPoj+FUzgZJHFiJ4IEIgjnO7fy/eON1NebAUQnidziSeiUqjouV12ffI8o38NNgmcgt/0g 9E6FJw2edGKvwcwrgzwhHb40SpnjINoHMscU6JJ1jHWM5XyX1y1Fpu/bYOiSBlJpGwhS1CYbfd// Ffsko7vYKBWk0ZeuWO/bu2OZ31hoxE6j1G5ivw1KI7QZtA8HI6EZpXbcAu1mH99Y/V30Tmw3EruJ fUdjxzHUxeZjvfSjKUfpGmxnDMEOLYdDK3Vpd8+4UTyP0rXa7u3bSfmOto/W0qm7Z1yyrts72G8H c9yJbWVd3zXDQBY340jKUTreO4y3k7ZdrP1OMxRk0J6uvNuRsQ07bvfJk9Ldd/2whXz/OtHrH9Ln 0G7Fzlux92bv9603er9zvdGX3w8mT0gHqfoJzGpo34TmbfxpvdIleNdX1jtJv9u+Vn3C8f8VPn4p 3bNIfCdD/W6Zl8bxJbddyie/BeV+ahzFWdqTc7AHZ2Ik9053zsgIzsswzstgztVAzssA2jtwL7Xl zGwNrT97tjl7tCl7uDHnRwPOrXrs6zrs8Vrs9ers+aqcHTUoa4N6nCcNaW9Cvx9ngD+0rUE7zoGO 8HdGTjD7PgyZXUEk8kWvJ98xuN8KCUW/CM71bpTd0TMSnXugY0/mEI1+PeHvQRnJc3fauzGHrsyl K7QRIIy6yHDPwqqcVVXQszp61kTHOuhYlzk1QL9G6NYU3fyQ6Y9OrbBBW+R2QG4AcgMZOxiZoWqz d6nvMl3o64S9OkLXDj1aw9eSeTVHTjPm2xi5DZl/PcZ5FbvUYtwaarOVwCkrenWSuqunzC0KPSK9 dgpDXjD6BSIzAJntkdkG+CPXj3k0QXZDZNdDTh1QgzVxx6hBe23tExqhFZ63vGvzNnqvR/8NrM1G zuxNzG8TtpOxt6CDY2PRJ1bXyqk/+T5J/nfy8tliPWcY5yK4xrgPwO/UH4HsnjUmLyjgWWvKg1eo twMdqIcq3jFhnsPgHPUblF+D36nnsqGewjbEUw6EUB8KVlB/3wZ5vgPf2y6e+7Yz6OR5YJ8Dz1LP BTyeH+zf9r79Fdy3D+z74DC1VWCt/d6+bb+1G+zXdov9wm63n9ud9lO7235s99nb9pC9ad+z1+1J e8meth/as/acvWBPIWE92ICETWAL9W1gH/Xj4Lz9wd5A8k3KW+AT2j61Pyk+sb8o7qDPXcrb4Kb9 mTF+Ru4v9iDYRt8a9F5os3vmMYfZNrdnpn3aM83m90xmXhNsQc9Y5jjSFvFk2aLYopgn3b7gGUiZ zLMgxT5PWYS2wp40aAfDM8QWgragJxNk2QKeEfYZzyhkjrH5kJfb85rN4ZlurWeOfWgX2t/tMvR9 A/3fRNOdzGgPtjuLPS6h5RW7F513Mr9t2GoTc1tn72HPr+xK7LmE2S/AIrORMJ0ZTba/2fH2DzvK /mUzkZ5hH9lUkGwf2wRrPPEgjpE7gDbU/UEz+hpBUw/Uhqc6q1jF/mlfRk55tCuNzBJYqhiWK8w4 BRgvP9rmYexc6JCNNTX2S/u7wf7mpv3EnLU3zfv2sjloz5tdRLWbiVbXEgkvJWqcyy6eyu4di7cP YxcMYkf0Y2f0AXHslBh2TE/Qnd3TlTKMtmCNcN6ifJudso7+9dBuJDLfZBKRM4iTIwMMQ24mGMEp MYYTYwInxxTGnEnEOofxFxA5LyEyXgHeIEpfRaS8Cv3W2jNmnT1nNtoLZqu9ZN6xH6H3NbPX3jAH 7G1z2N41x+yn5oT93JyyXzK/r80F5nrF/sTO+8XcYO637EPmb1ifbPh2Tnw8NzZ5Gts8g40K2u9s EexVDLuVwEtLY8Oy2PIlbFqRdXsF+1bBztVATWz+KqiP/ZuAZqxFK9CWNQ0H3VmfWNCbeiJIoS8N ZEA7DL4RyBiNzAnIn8w4MxhzNuPPR5fF6LQC/1mNnm/hTxvYF1vwuHfsVbvLXsbXPsTnxPdO2WP2 BLvwAPtwL564236EF15j5960W+HaBPd6lSLe+CW7/Gskf48v/8govzDaIzzSeKbYbJ6J+Ps4+5Rn tM3jGc7+GsZeGMy+SGWfJLNvEkASeyhJ91IxRZItDkp4EkFf9lw8bfHstz7sqT7wxrOn+iNnAHsq 2eb1DGJfpTFGhs3J3svBvsvGvvMw5iN2xN92EhaejrXFMoOox4GWWKoRFquF5V7BgmWhKwZ9AXbH U/AbZP1mnvL8wFn6hcnvuWOe9VwxhTgzn/OcMoU9x83zniOmqOeAKebZbYp7dpgXPFtMCc8G6uto 30j/FlPEsx3anfDsBvtNQc8hzuUjyDqBzLMmn+cS8q+Z3MjP5fnc5OAszua5byxjP8Kj/rZPoVsB 9CyO7uVY1cp4UG1WtTb2roWn1cL+NTgRqrIGle037NxvbQVWvBz9ZUBJvKCo7txf2LW/2ezM96H5 2/6K/PvGeL5ivE8Z9ybjX0aPc+hzAr2OmGc8e9H1HbAFXTeap5lbXpDTs97cYRdeZzceAO+yM7eD rdTfAmupLwNLqC+CbiE7fQG7dT67dR47dA4xxizy3xnkq9PYdZPtVTPJ3jHj7T127vdmFLtquP2b 3ZzdDrV5LacqPl6clSuLv1cC1exA5jyIuaeyYzLAUOpzwXzssgQss3XwyDr4fx07lef+oC87q6+t y1lYnzOxPvwN7FKwgvo58CH1m+AW9U/BZ5yKX4FvqH8HvqfvPnhA/QHcP+BbPzDqN3YR+2AZ+2It p/V6u5+98y432TvcUZvZPevYX2/SswbpbyB9BffSUnbQYkZZwChz4Z7NKs5ktGlIm8wKTmJEkT6G EUcy2nDKTJ4TFN/aJPoHotFQkEV9JBhN+zj4J+IJk1WWyPzCzkL+XMaZz3iLGXcpOixHn+Xs42Vo twS956HVXJ5eZy4zoJyCRpN5moCUcdRGURtJbTgaZVKbAqbRuhQsp76K1lW2H/OLogzjfgqlPYT+ EMYMZp7BjBHCLgxhPUKRGMocQ5AagtRgpAYjJYR1DsGywaxrIGUAa92BubZlzm1Yu1ace/6cfy1A fXZxbdsLX+jN/o3nNO3HydqfE3aAfY71zQd/TptuH5kh9jduh/v41Jf41l1un2vcDh/icx9wQ7xn puOPrxNXzsFP53HzLCCGWkg8tRgsob4crKB9JeU7YCftx8AJ6hKDPRlPu/8jWw3PamKv1cRgEotJ TCaxmcRoTrz2DXHjNXCR+hnFGupraFtN/2riuTXQroFnLbxrkfEmst5E5lpkr1X57jv0MI3rJMaT WG+19glNO9ABnlAQQj1MsUZppe7mg2HEgeHsfScuXKu0Iez9UJ5DaQ/ROPHGP7mCpzOxYTkbRrwY RtwYTvwYrnHkDaUNpR5KWwh9IdAEQxsMT4inkxXeMOXvbN3PCUI13gzVNqEJ9gQCaQvx/Q+owcSg ocSiYcSkYRqbhihNCPUQ2oLp6wKN0Ln5eyfPj8SrP9pAYtUuIJg4Vfq7KL6n/Qf6f7ABGtMKHHop XRkejXEl1pWY90dbDlT0/GSbgZZeWuF9DjyLrFzAg2zhc99VvaGx8ANuU4mLf+TpR+6gB5zvD5RO 6P9mb/8KJII+Dd6nvkrxwAr/cnjcuvuNz4tQnee+PsvfY8SLR7ilD3Kn72OP79aI8hNix884h77g vv+KOPwbzqHvrKvPWuSv43mjxuZfcsPfg+czotBPOMfuEJvfIh64wShXic8vc0ae5kQ7aWVc13d+ 5My7jxRpkz7neb2WPxIjSJ/UXV/9EY1+JI54oDH9JuobfDz3qf9A2w/03Vc6h1ZK9x3xffR5wKwf kAf8yEyl775iH3zHwXlORckNrluhdfWUfEFyhfvevu+0vKXld5zN32seccO6nws+0JziY3DLm2vc AtL2mZU+1y9/1lzjY+7YjzX3eOCl+Qn8zJn7C/iVNqFzdfkV2/6s+ET7nOe73vKm9kndpf+Fvt+8 bT9rTvMxz275qbd+16fTT6zXT5rviKzb1uEX3EbGTZ6vA6G5at13S78SGf6Cd/yMLX/Gi37Cr6T/ F8Up+A6CbchYA9Zah97hkbr7k7DFiceKkxMVJV96nnyoMPFYIfKoAuRAz5BX5SMHyuuZSrw2gxhr FrHWXGKuBcQ4K1WOyP4TD33InfSYGySHZz57ag7x4z/5WQHiykLkU4XJrZ4nrizGGVCc8UowdgnG dkvRxbVhcfI1ydmK+/qcPK64xpyJ3nqKz4ZFtF/yvRTr8CZrjCoyimjsKvmfU3ffGRXVfNChKeqN a4tqbDvAW0/2nSuFiFclVyxMWYT49Xm1WbLSFab+nOaU6cx1CHFvBmWG1oXPfWeWHxs8S5xbAPsW wg6FyDufQ2YhL20BbP8MsXB+7PQ09hf6+spb3Bxlt0qUf5NTSU6Kz1nbR+SkHmydk7XJwzoJvfDl 9kwiT5aYfjbn1ALWaKnmrd8T2XzFvr3OiXGZfOE8p8VppEoOe4QTQcZw/SIT6aPgHs/qTma1Z7Da c/C0BezgpeywlezCtZxD6zirNrN3tuPbu/DXfey9Q/igyBKZB8hG9nDOOXnxXc6uTzjXPscLJb/5 hnhG8p37RDA/atT/GuOMZ7yRjDuM8TMVj6z7f5wZZpANvpzw5UGPfPAWgLcwvEXx7hLMtjT85Ymc KyKjCnlXdbyztjdvboSXNtN8WvJqya895NkeshRLdmNZUUO281jz8UzF39QfenPzR8Q2j4lfHhPP GHgNMh4T5YhMkf2QMR4Sxf5NxPsXY/9BhC+6/EZ0/6t9Ef2KsRKF0bcAeudnRfIyj1zMJzvzktxc 5uf+FpK3yLfXkzNv1nx5rN1JPr6XvPwgEftRIveT5OvnyH8vkb/fII//2JwjavqI6OkWUdSnKktk /kG++4Dc96Y5Tr7MuhMVnTKbyK3X2sPk+vuJpnYj+x3G2MpYG81AsgHJ9fv57sS15PREIUQ6XSkl 55fcP4acv5f3nUA/5Xnb+37gLRNNX08QRj1E3wm4pchy97nzaUuAtkmf89xJy9X6qUmA1t3PELYT IW43GegpdkkkU+lLJBiHnXowfsQTMkRmBDr1pC8Our7MLRG+VPgzrCtLSnePbify3G5GYovhQN5R DNP+rTrmMLuNtm30b6NfSqF3bfQ+kedRotDDRKUHzWzsOoP1moxtJ7B2Y5RWeHZg511mIu1T6J+p 9j9IFHuEtThG5HoMOSLLvUNP6juQN7TtmGIVa7fangDybkT6T8AnNFJ3f7LvPr7wAHxP5PGNuWC/ Imq9Zz6wn6mvHCWLO4xP7LfXzR57BZ+4RGb4odmCf2ywZ8zb+Mhae9L7/uWkedOeNuvsWfzmPNnj RbPDXiabvGr2wn/Q3jJHkHfMfqLvXk7bL/DFH8wVcNWKHq5OpfH7EuzbYvh+EXy/EHnQs/h/Pnw1 D76ai5gmO+eJ5Z58ZP4HX+cdn1XR/O3dWwWkSYfQO4QeOgFEeu9ge6wP6COoKIqo9NCbiCi9F+m9 VymhhRYINUBo0ltCV4q818w5e4cP/nj/+LJ7dmdmZ2Znd+ecQ8591j7i7vVv4vk+8XvHlyUyb3NH e8+cJM5P2YfmjP9M5zx7w0X2hsv2VeSlRO5rjJGOsTIyZhYd+5bNxfoTPV5XneRr+PLcRp7fyHMc 75lOGX2+I8955HnPfe5a7rGf3OXO5Q536x6/yMlLW37tu8/d7gNo/4LnL3j/Rs7f3Pk8ROZDZD9i jEfcHT22Mp77+koE/D3g7QLv9/B9C8/X4Et9jvRQ6d8C/2Ff+S/4hPqX4GtkdQLfQ9MV+h7w9kaO yHPfNt9id3FaHGBfPsT+fJR9Wu544/Tp5XT24cnsw+PZv0fjqxHMwzD8NBi7+mGXyBF5/SmHcP2z 7tE32P9lz77C3n2J0/88GeM5ssDTZIAnuYeO5V76CGfAQc6AaH02JTq491JXlWua7v5xnAQn4DrG qXDYroBjNdSbyEgjlUd4t3Mlp9MuTpMYpMqzraOcJMcZSZ5tXUGDa5xEItedW5nYxTOAdOzkacgd 5PlVCs7YVzlvk3KuvswZGSAfeYqlT7grfsh98y3uo29wql3VE2kqkTIJb47EyyPY1X/mVJBnYwM5 Z/vps7EUnNGpAl04q7/XZ2MZNA/4QseV8bMEPgnWXX6SlZwlRCH5heQaX1qnawbNIb6y2TSn+TK4 7rMH2tEmz9S+0Hbpz0GZg7bsnFhS5qDMrmhn3f1eOtrTgvQgA32Z9HncZ8j4TOmEPlvgU3T5VHVN B9JQT0O7K0WGi6N7RMZ9/PDEDsQf/fFHX31e9zJ5TBJylqT44lV8kZwcKKX6/Ct88yVy2qsckZea cVNhR0r6kpMvyTPApMyNPAN8mTxIngE+JeKeEH33mJcH+pRcMFzHlrrz5T3bius2ROY3rMYI7fPo I6D9hnobIDStgjak4774tcBRkypw2iQPXDLc95lXAg+4XzSc4sn0WeIjdqW/Oan/YrU/sKWRVRkZ tVTOA0Ut+rznkA+hecTqfwLPU3gDyHgZWUm5j341kGBS+s8h0waOmQyB/SBadXBfQsweWGCy6fPH xSYksIJcdI3JHNhA/G6Gdjv55i6lF76Mgd20b4dmC7R/wLMG3hXIWGJyICNHYJ6WObWcp7JdjpuN 66x+m/RlC8zhes4z5bzE/6OB/HSBSMbepM8/MwbWMu5K9FrG2KLnAl/eHK7n07cImmXQroRnDViP vRtNGpWzJfi+92X8kSRw1SQLXMD3p/HNcXxziPnYB/1OpU2jzzDlWeY++g9CFwv9afjOw+89ZxU5 zn8JZFm32KXv6u6cT5+5PmIenrDzP+UkCDAPQi98hnl+Qtsjm4z5Tcs8ZoVPdvGi+mz2FvPpyfNk St3dZ13U57by/Fae45b16UqzX5RmxwxjDwrjtBEaKctYob9AecmvOx/csDnhyQ1PPvaYAuw1heEt Ck9xaEsqrfBfIXO8yglyjb7r0NywBRk7H2PnASIjZ/AsTRNYjh/X4a/N+Gsn/tqHvw5j90ni+px5 yon/hBPzEafnX5yQ9zkd73LKetlnZpUlMm/7z5zvk43+xen7ENonnKxPrTzbvqrPnJMgM1ngCONE M14U48qcrWPulqse7j4phT57XsA8LoRmIX2LtV/o0hMr6YjZdMRNWvpeU7p58MxTPvd/MJbpc2p5 Xj3P7AOHrDzHnq80QpskMJezZK65QGYXCf4gy1sKlgXLucH/CzGaLG40mdcYu5gMayHZ2TyyZ3nu Lc+/55HJzFN64VuCrNlgJvWJYDz1MYw9Gr5R8I9EjpMnpTtzOnLyd2Q/+Jb94DtiiztFzvMUthu+ 7GEfc8bfI+O7SRZ4yQwiSxpC1jTMHiDz20WWGIncdSpP5P9q15pfyASHkXENJdMaBO0AePqSuUXY G2SP90w3ZHZhLn9gjO/Ibr5lzI7Ex1eqR2gwl/2GmJRn7t8QXx31OXyo0nwVfB5fWstviDuvHhbc Y7vqc/owxihFXynrySrNdWlsK0POURqUskLnYnwKGc8UfZ4vz/VLky+UZvcOUxqh7077SDCaNTQB TFJ6j0fKuc/UnR7t9Z2AvBtIpP0ZDEVeO9A+WJYN3te3g66dLW+llPZ2SlOG+zZ5p1BB293fhXzO 9Rd+m/R9bitZaXOxeFjfNcg7hwpkCRXsKOo/gu+U1qP/Cnxjw8mrwrGhEjlLJbKXcPIaQUXrnjHH ++8k4vUdhfe+4jJ6XgTy/iIOnKTvsCKcejhtlciEK9FfEfqK7AuV4K3EnhDOPhSOrHBkVvbrlZ55 zleR9oraJn23deyK9raifLDufOZlfXKefggaWcefQNtN+qQ/kXaUXt9UDEOfXyhHWq/dK4Nf7CMn XIw1y8lD19i9dgM53Ra7jdxuM3mdPC2YZ0/huXPkhZfISIX3pr5lkbcuU7F/JpxL4VwF10a4tsK1 Q9/ZLLP77UIyxzlkhTKO+4pdD7TvCXpjuWg+EIlD0HIYO+pwdld5fzOK0cZo/nueODxHXElOLG+F 4shpT6g8kfs79Wn6DuYUGp0hBs4Rv/Ie6ALZ4SXkXSZbkXc48i7nhu3LWBF4vYe+C0qwThcpg3+J Tn97+r4EX6Pjt5RdQDfqHn0CayWeNXOT+LpJfAq9xyOlm+MvGLM9NknbF4rr0N+wXrvXJ/U3lD4n e8w5+xvRNALdf8bDQ9F/MPoPILL6YkMEtD3h6abvq27YDj7/51q/SVs8sR9P/03obuJfee91HX55 D3YVP1xRf4hfxD9j9D1W4rPXSczdJPw6AX+Ox5fSJzQTKOWN3BQy+ylKszXIM4ZZGc+sTGRlTdJ3 YFuVZgr1yf77sLHEidC5LyfJO68uthd69saf/agNwLZB1H6iNpx/RxELY/Q9mvAJ/0hG+I2RhlEb igWDoRvEVYS+S+uDnAjk9WROeuk7tR/9MaTuzr5J1OX92iDQH47uoKvPMwT8hIyJYDL1KfouziuF z83pNKinIVnapG86o87Q93VSenWhcfcI07g7nKbv8D4E8k7vG+2foXgTvtbBUmidj/rq+zx5ryfv 997E5jextjXx3RovyLtAeSfYGh3eVD7hn0r7FNtS3xGOsy3wXQt82BLelshohd0t8W9L/NyCeGoR LGUsd2/Skf5v9N1ha87J1vjxTTRtjbWtma1WSis88o6xk75bbAFa2o6KVsordXe+f6zvF2vatuTm n9k6xHw91lV99uRG0DWGvpnSf6vymlE25rqB/56yDh6rxT11De4YqoMa1smTMvH/q2dDdm77KXlb W87PNpyl/+U8+Zj98WPlFVSkrwyySnLOFIHee8f5uc1uhd/tTaPsDM75GZzz8zn/l5mf9AlRJGf8 LtOPnKC3jeWMP8MZf5kzPt58T+7Wyf6D315B55TIy6DyRO6X1L+2qbApie0MzY/kbF3J2XrAG2HP MsfHkRtDDrGbXCLS/GzXmxGaZyxgL/g9qIuULoan6ntUeZ86jXxpGnTTtX+0/651PJhAfTKYYmdC L+9aZyqf89de/53rFvjXAnkHO1Ux08wAM+FZDlYiaxvYSX2vYqZfTg9+0WLjM7+HlTT4v+pO6hct rpP9LTTbwU67yBwDx8nSzoHz1C+Cy9RfIgN9hawzGUgeWEp2upQschnlcrCa+lra13PX9gfYDF0k d4fbyDJ3wreLbDoKGTvIhLeTEW8jM95KRh1p7oDb1BNoi7fbyfB3mOtkbdeYyat2j7lio8EB6gdp P0z/UeiOQR8L33Fz157gTvYkWfkpZB/nLuUk8k+Zf5j9J/ZPcNE8ZiYf2WvmIZnf3/Y6WfxV84Cs /h7td8kmb0NzC8TbC4xzAXsvYv91cB/7H3L9CB0eodNjdHhsbpLZJ4DbtN0Dd7gruk30JJBJ3uQO 4LrNxD6enT08D+dDQfbmQuzjhSlDQRHOjqKgGPXinM4l7WlwkizwEIihvgfsYnUsAvOpzwK/0zcd TKU+CUygbzQYiYyhYDDyBoKZYDby54L5jLWAsRfZ/HYJuiy1OTjts5JFZALp7Qr7Gtev0Z6a/tTQ pYIvFfwpGSMlO1QK9t4U7CpJ2UMD7Ln/sLIesiLuscpusSpusCqusPKugXjqt8A96g9YkX+ZWWCu /Zso/dusgm8t2EB9O9hBfQ/Yi/9iwGH4jpHdn2A+4pi708zvOVbdeVbdReLjItn8BbuJ6z9o32DO suLPgFNk+idArF0D/2pz1K5E1iqzH+zjeg/YRX0n2EHfNhBpV5iNYAOreBFYQH0GmE59GpgCzWT4 xrPSx9uNZpzdDCJZyVvBdlbwTrCL1bybVb2X1R9tfkPXX+0h7jqOgGPsSsfBKe5AzoCz7Bx/gvP4 5iJ3LpcoBZfx12Xaz7KrHIfvIHJE5lbkb2DsFZyGC7mLW4jvFnGHtkjX6ou+U3yO/lPgJDSRikXY u5g7v8XmiF1C/xKlcRnoeWj+BNImfeeh+1PXvdcupTtxkuvaX8x6lr1A9gTZGxb6tIupL6ZtCX1L WO9LoV3KPrAMvmXBUmQ4XVPqHrJE25LrPrKMPWSJtqfW0qu7DCYVe4zsM6kCK8Fypff2II8/RWAF WKV07unGy4Hd6LuLfUju6rejx1ZoN0O3EayHf63SC1/ywBr6vf0rWWATPJHwbsOWncjZRT1K5b0S 2KMype5880D3sq3sNdvYd7azB+0wAfhe8nmS6N63nf1pG3vTVmgiod8Cn2CzX24N/sXDdWLrOnFw g30wnv3wFjLvIPsuNA8UW7jewv4TyT60lf1oG3vTTvauXcrrTqHrxNM1cFX3z2jqe7Vf6K6wt16m 7bL2HeL6UJBeSvc0676NY7w4xotFj2Poc5TxjqCbRy981/Ra2mPR5zh6yZ58Cr7TWt6nlLrIcvMf YK+2gVhf/ml/747V9pcCx7RP6m4uH7I3PGK/ecxe84Q18w/r6B/W1FPWjgkI/0mlFxlPOQ/+Ydwn rL3H0DxmT38Ez0P2/b+RIXI8eQnBurP3pp4DF7FDzoVL2H0ZG66g51XOjWt6fjhdHuq1tF+m/xLz cxH6C/jpAjLOqyz3FOE8dBfAJWRdpd0b5zy+O++fORdYQ5egu8x6uqL0bp3+yd54zt7R/2/8J+NK n9CcRZeznFHSn6i/nE/eeXWJffYCe/B5n0Zoz+n134wl/Y8Y9zHjP2Eun8D3D/P4T1CGlC7G7+tZ 9xD7Huq5dwskKN1j5UkAt/RMfIIfvHPxLrTC94Dynl93el7iXLrCmXSdc1L+r3C8/j/rFNw1J7F3 OU/v+/y3qd8ia4vXd7zyjisTfNk4W3NzphbkfC1gRZaLq/O0yVkrbdJ3Xs/fwlqeo83V3Vo7zxl6 njPzAuflBc7Li/RfVDqP7xxt5zhf/4TOO7NL0F9ceaTu1lq0nt1yhodxlodxppeCr5TSCN9ZytPg JGf3IRBDPVpRKvjk53f4ZnE9HyzSHEBygVJKI7R7wS7G3ga2IHMtWEV9EZhP3yzwu+YKiU+TBmpe IHmC5AuSN0j+IHmE5BNhSis808FUaCaBCcgbDUb6OcVA6lK6uZuHT+aRy8ylnAV+x3dTweRn6Acj ZyKYTH0mmE37XDAfugWam3ilyHJ3IcuZ3+Wak6QHmchLspKX5LCLmeuF5DDzmZd5mtMUxebCtHt5 zTKbE76s5DOZQHq7EhmS27hS5Lr/iTVb85zU8EreI2Ol0X6PLjVtqZCZCpqU6JsSvVNY4XHz3F1z IsmNJEdKhW2ptF/oxoBRNjn9ycmZUtju+vQypdJL3e1lcu4PZP32Zy1LHtWHtRnBmuzFGupJntWD NdBd8y4v94qgrTd9fVgP/aDtD89AeAezDwwCXh5xSWVK3cX2T+RhQ1jzgzUnS6B+A1zz6YU3Hh6R dZ8c5CH0D4Ol8DqfbdI8TvK5B9ou/cPRdwaYRX0JWM56XQs2UN+k+Cu49+3RXO9vE6V531/aJzTb wQ549oDdWnp0Urr1LH17/T6P5jHXj/3yiV9/FBzrgOaTklc+9HkfkwcKHpETCh6bgyDGLw88sydd 4Cz9k3P3LLncKc6yk5xLx9mnj+K3Q/au0grPEfwZyxlwEp+f4ow5o7nqQfj3sK9tA1tVlstdzpGz /kkeeZ6z/oLmsVuV5hL1i+S0F7R/vdK5N9pHyVePgKPktbGa40quu468eD36rfdlSil58Fr61kCz Bn1XQ7+aXHglvCuCpchzTzt2ak4sufEa/LIGn6wmZ16tNEJ7GJ6dIErL1cE3UHO5ngMWgEWaP0se vZI71JVmK7zbNc9erXw76NsGIsmnN4IN3KXPA3Ooixw3X1Phmcb1NM2/JQ9f6Y+znP1wOW3LoFlG Tr6cnHyl0ju/TsB3E/CBtE3WnH0Vefp6sAls9Pu90vl1NDnQGOZpLDnQWHKmceRW45iz8eRS45mf CT7vWP3/J5FgOzw7QRR5+W5y/T1gb7AUeW6djCAP+o18aCTxM4rcarTS7aUtmnuDA/QfYt0cBkeC pfC4efmFePuF/GkEedYIpRHEcm9wEpyiHufTnNLS/W+eIf49xU/kED+RTwwj5/lZ7ynOwHNaaYV3 GHw/Uf+J9qH2HDx/ArknueDfj1xgT7iodZHp8g/ZL4b47Yn1y8i7Eqy7ORmoNFeeobuoe5O3511i /7qp/VJ3+77c40wE45j/0fo3U1vx1250jmGM48g568u9jO5n9d5qBOttJDSj9Z5sA/Mm878IWYIF Kk/kOt/+4d9HraRvCpik/YtoW8S+tZh+wRK/XBj8movcR/2hWKz3U5HwbvHvr7z7sMTfF3f/i7ab WWK6mqWmM/iO+ndmsekCulKXvufv35yOnejrpDzLoF0G7VKl7+zL6Kz9Ho2U7kzqpnJFvoyzyHwP OutfZi9Wuh99fdz43WnvplgS1P0LlVXWzDQrwTrzu9lkZphtZprZZabor/ke1G8YjTMnzFhz0ozW b1nJN60Om18N8W0i9fshI8xG8zP4Cf4hZosZSHt/s9X01V8j3mYizHbT0+zwv7odhb67zA/ge7Mb G3eBKOo7ad9Ov/yqeiR8W+DfbAYgdxBjDDUbGGM9Y63T75SMNqvRaZWZYLhfNuwbYCZ1scX52O3x 4/W7UvL9poNmKnpPZ8zf0Wsm8mchbxY8vyvWYf8m+rdBFwW9/GL7QcY4ylgn9PtYIsudU2NMHL6J 0zbpGwON+Erax5pT2id1t6bku1qj/H6hG63fzYp9pjwRpB2p/Se0fZR+k+u4to3SeTihdUc7An+N 0Pk47PMJrXy/KRpEar+jdd9wGaFzF+l/f+cPv9yg/S7/l1+S7gsG4I9BzMsQ6H/CZ8Px0Qjwm//9 mJ/BT9QH0zeQeesPXV/oeyu2B/esTjrX8rX7Pcy/fFl9t35lvQe+7sn8R+gvUW9Xvl6M2YN6d9q6 0vcjNBInnaHvpNitsqTu1mAn6LwvuHtfcf9O6aQtSkv3l9CTWWeTwHhiZox+I2eVfhvnF7PWDCMG hhJnEnMDQF/sjNBf1t6isfkjen2PXiLvO41jiWeJ7W3YIPZGmn7QDoBvsK4J8c8G/LVev7EzmnHG EbsTGHcy408Enj5LVafJz3y9QOJylsa21+7RruBasEpjdpYf78/uScG/CmG8Rgr5BUT59b4NpgH6 1AfyK3u14K2NnLqgPvXGoAm6Cd+Lfk+gsf6q4lr9ZcAm2NLY/5VFr21dMA+twxh1dSz5Jb+N+uuB 0u/xyC8MrgfyS3/yi4zrtXQ8Ujof1EanmuhXR2Vt0OtaXEtZXb8g69XdedxUf7Fwlf4afH391fiV z/Cs5no17avwySr0WO3/wuHa4FPzp9WqBZ+aJ/vXN8emovlUZnYKszyZKJjI7E/Q31SP1i+ljQVj DBkCETGGqBmLxePBROVb88LvBI8zh/Q30SeY/fpb6pOQOwX5UxlnGuNNg3eKYiPjRtLvje39Bns0 48RQHvDleLKknrhTiW6HtE3oxiptjLaPoU36pO7sHItHxugXoDazOnZQ7tV+4Rmrdc8+7wtg6316 j0fqLnucpnavRt/V6oMJYDz9YxXruV5Pu/hnLXatVRun+rZOU6xWfqkHv9TdM/FL3a8GZ8jtWUvI jZeQGywmV15MTreQnG4BmEvOMA1MIb+brPiD+npyzbVmJphNTrwQLKIuMp6fKfeGZh4y5oMFyFhA Lr8I2YvBEnLIJchcytjCv1ixgXEj4dkS5JMy8a2n6OHpNZ18dC6YpzRbyIWZeTCV+mQgejt6KV3+ MB2dp4EpjDeJ8aVviuIPeMW+dUEaKd068XQUm1cz7mq1f7qC8xDMwQ8LwCKlW6/2JPol0e8up9/K eFvxQSS6bsKOlei5Er+sYg42IHcj2Iy8LWAr8oT+eR87v2wi/94MtiBjK7ZsQ8426CMVm2jfQn+k jrMJGkcvpYv4FTr+Nm3bpPWt6LJV21eoftu07uJmAz5Yj47rwFrsXI2Oq5i/lei/gjFX+Pyr0GU1 12vQZQO2eHwer9SdDaLvNvi3ImsLfZvAH/RvUKzFH2tpW4fe0r8eu9arfduCfvl3bB9h/MPYc8ju 4F52J/emO7iP28H93Hbu67ZxryzYSj0SbOY+eBPYCM16eNbD/4fKeN7v7j5pl/KLrO3I3GGidYyd jBUF/054d3CvKDps5Xo7coVuG/Rb/XG3qYxdtIscqbscbD92RqPDXnyyFz32oNtudNzNXO6Cd5fK 8WTtRf+9tO+DZh/6R0O/HxyAfz/8Isvde4g+R9UusXGd9gnNQXCI9sOKrUr3vF/dWjhH3ym7z8SB 49xfHAXHuFc8ht2x2HwcvU5AcxKd4tApDp3O/R9+dDnWKe79TgOhOQNE7inuCV27lC5Ojuh4exhn D/K9PqGNU+xh3F3QiC57lPaA3a/0UnfPlk5hYxw4iW4n8Olx/BeLzsd0vnaCXUovMo5RxmLXcdpP MEcnVT+xazNyNqptnrwNKlPqbo2LPeeQfRb6M4zl0W1U3tPa7tnr6M79Hz53ecQOxt+KXlvRZRt6 7IB2J3KllL4Xve+KRP9tYAd827FPZGwD0r4Vn0mf1N1JFqUyN0MbSf92+nb6MoRPZHhjR9G/A9oo jceNyiN1t8/KeDvh3am0W5R2Bzzb8fN22kUXRyPl83Ynnh872W+jKHcB+buQvfq3ITO5750MJtoD 3NceMOOZ5/H0TUDXSdBP8f9WZd7/4Ru3FuZDOw+6udDM0VKud1Pu0r4FOmaU1t2eMpN76llgDmPK 90HmKfYojfCJjDn6Ny37OCOioRXsh++A+R3MVBwMxvM4+sap/mKL2HRQ+4VuMphE/wS1LVpLRy+l yxrmqX/c3+3sRA6ZDrqMQ49xPv8E6hPVN7vUN85uz74dyj/v/5gHt9eZwF4QY/6xh8Bh88QeMQ/B X9Tvgtu0J4B4bLjJePHoG49fbiPzDrjLWA/BI+pP0EHkveg8e2SPmsfAMp6F7qkVHGBcb/wn4DFj PgJe6dFL6WTcQIeb+FF0ug3NHdX1iPnbpxO+h+Av7RfdY9B3v/I5GXfxyW10voXOCfqecTcy94Bo pRP6BOoJ6HcHmzw7o5TPxa/obwN7sHc3uu9iXPHDDsbdYe6zloRWeP4Gj+h/StyIvY7PBv3077Wx AV02KvZyVkbr39utx0/L9Js18rdT+8iv9oI9tO0Gu8xyxlkPNlAX/hftGyJzIzx/gA0qf6/WpX2z junVHf16/LeRcTeixybl9eiFbwNt61W3mOAZspi2xarjAf1bsPWK/dT3o2807dFqg9At8mml7vhX 4ccVQOxZBpYw1hLGWozNi33eZdSXoesKbF2l2Jn4+76q2x4gfvB8sp7+VYpd5CxR5Cy7aBPsUR+4 UnhflHPEMOYBxj+AXfuJv2hiay+27aW+C0RR3w52oN8OaHciM4ox9oC9yI0GIuP5eXF270OeyDyA rBjGiNGx9jJWNIih76CO69EdVlqpu3naR99ev9+jO8DYMVruDdYT72y20bZd9Rb9xZZD2i90u0AU /TuURuyJUfqt9AuP1N1aisKfYucO7BW7t6PvNuX1fLGT6yjs2IX9UeoTj15Kt8+JrTH07Vdfic+i fLo95EV7uN5N+x5sFohP9uKbfeof4T1IPcavPz9/Ts+T6H0CG0+wVxy3xzj7j5MDHCcniAXHyAuO kicJjpAnHeI6hvb9yveiZ5bH7QnkybuSI+Aw57+MEUP7IXCEMbxxYqERWre+DzLOYR1TIDqILieU RmiPKaTviK/PMeU5SLurO7uOYvMRcBifH2Lcg+jh5B+G9whtR9HpGLYcgcbRS+liR/SOU3ujleak +ilG209p6dWf9637n6A70H8nukUrTuo3wfbZOObtNDmG4BS5vfx950nqx0EssXQUHGFPOcKechTI 3xUfZh3Kt8QOsRcJYqA9BA4TU0fBMR3rRef+fh3/GLoIXazSRoN91Pcrjmm/1J3t0ei1H72kbZ/i pPJ47V6f1FMr/Stal/69tO/Velwwl4uyZ7D5DDJOa7v076YepTgTjJst6pMz2iZ9O/HPDsVp1s8p 7DyNb075fjsdvHfYjA82gUiwBTu2oMdmYmaz/7ezkcpzEt7jIFZ9Jj7egv82qV+PBEuR5fTZgI83 6Dwc0/aNWj/MfHjt0r9W64e17mJvC/Mjc7SJ2Nik/U7OYdoP03/Ipzmo5SbWqdBL3a0FmSeJne2M K39bvg1shXfrM7ybNQaOqN3bsW2H4oRfxv4rLhPf2Z0mXztNnnaWvOssedo5MxXMwO8ztT2O/hPQ xZIjHQWHyZkOgmO0HQcn6Y9TOS/KaabaP5ElOIe8c9Cfgf4M5SnyRBnjNOOeJYc7a6YDoZ8GpHT3 SVP99uk+ndd/lnzurOordfe+aAH6zVMcZpyjjBPL2CcZ4xT8p5VW+H9Xm0+jwym1Yx72iF3z8eMC /DkPLFBb96s8qSf67Qxtp8EJ+mPpOwaOmIWM6Y1/SP01l/Y5yBUfzlZfnla7Hb+Uz3/N8g0dI6f5 1Vw2v5mr4LoZaW6CBPML9eG09TdnTB/9tbYT+iuyXUys+d4cM53MUdNRcUR/2VN+DbQHiKDem7Z+ 9A2AbhA8g81J/zc6TiP3TzPCXNQxn59Hdx7+xvijFKKL6CS6XYLvMnxXwXWubyrdSBPvl7eVR+ru iwtfo0dH1fUYOsfqL8jKL8D2QJ8Ic0rt+sXcQG78M7Lk+pra/jNjDkHfgeYstpw2feHpDW9P5HRH XheVexT5R3w/HNUxv6JdxpW62w876S+gyi/kyq+mHta+b/RXVOUXc+WXUQWHlK6W8uRWm381F9Rn w9FhmP9bLoMYW3zbD94+8EWo7w9i30H0iVEZIutH/RXcw/QdNr2g7c14feHrD/9Af17kdy/ktyyG mXOMcZ6xLqqfZezn17Kbn2nE2nRi8XcwjXieQrxNIsbGKOLMKGJwFLE4GroxxOpYYnUcmMi18D4/ 7+5efibyZqhswVHWj5THaTuuY0mf0MxGlqu7s2M88T0BiB5TgJM1GX0msg7GK84Ec7yR6DgS3UfT Plr1PqP9QjdWEefbcCJIK2XiPeUhaA5Bc5T2WO0brTiOrGP0HVWbPduF9qDSS93ZKzZOAhPx0QTg 0YmfxK+xvv1HqR+hflTrL7pPke82rEbnlei+AnuWg2XUl4LF6L5QcZw8PxaaWPLvY/q9hzXU1+o3 N198lq9C1mrkrEW+fJtzvX5jIhZeGfMk/TJunNIFf6FCx4tjvDjuE05rn9CsQM5ysIz6UrAYeYuA p9vJIJ+UTtYq/Z7FUXiPIesYPEehlX0wVukWKY5DI/o4+46CI8ondedzT3exW+w/6suO1e+OrtE+ zzahW+eX7im/GfbUuKf8yYMzkCQgkq1tY16xn5qktp1JZr8wye1XJoX91qS0nU0q+yPoRr0bZXfQ g3pPyl4mve1tQkAu28cUsBEmP2356M8LXR7b1eSGN5f9weRETg77HfjWZLftwWfUP6XvE+jawtMG /v+aQvYjE2o/NEXt+6aYbWaemCbmkWlkHpoG5i9T39w3dc09U9vcNTXNHVPd3DLV2PmqsvNVZket xO5Xgd2vHLtfGXPFlGI3KMEOVJydoSi7UEGQn3pekJv2nCAHNNnYLUJAZnaOjIqrZGJXTTp26nTI zcAYmUAI8rOCbIyRg/7cIC/j5AcF4AsFRamXoL0UNKXhLwt/efSrCH84u3wV9H4dG97AlhrmAbvl 3+z4D0097GxgHpuG5h/sfQqsbWwC4GXblJlqwrw0Na/ikxQgpW1u0toWJpNtabLaVvi3NT58E/+9 hd/eNqVAGPXSoAztZaArAU8R5BS0DfF5ffxfx2SxtUwGW8O8Zqsxn1WRG478Csx/WcYKIx5KMnYx dCgKQqkXpq8QtAVNGpDeFkCHgsRAIea0CHqUNYVBqC3HWBVAODqFEw+ViIVKjBUO3+vo/ga8NeCt iQ61TTZ0yWnrqV75bAN0bIScxqpvcewuic2lsbM8NlfEjiqU1UAN2mpjez3QiHoz0Jz+VtALWsDb HDnNkdkStMJ2QWvkv8lYrRm3FTq0RJ8W6NXcVkZGRdMU/RvbMsgsZRra4qYBttXHxno2JwjhOoup A2pQr2qzmkqgHPUw2orbDNifAbszEtOZsCcLdoUQ6yH4KAvzlR670+CD1Pg7FT5NRTynJE5SE1up iJm0xFF64jGDkf89dIFT4k/i7hxZ9lli9ozJxUmah5MvH6dpAU7BQmQFoZyIxUFprsvTFw7d6/BV h78WMVkXuQ2IwSbEX3NirxUx9xbr6z/GsN5e0vX//A7qnoZ317WfgrUs+0FK1nAK+zVx8AUx0p4Y +RTqNsTHfyk/JU7b0f4FNF9B+w2x0tmkhje17h9daeuuSKEype526l66p6Rk//Dau+q4qbkWSJ/X L6U7zXsTK33xcx/8K3tRBHHVS/eoVOxR6bn29qfeSpPfevQej9RdFtmO+PucNdEBfM08ddS9Koft pHtXTvs9Mn4khrsyl92I5x7Ma0/kRfhyPNn5GDsv7XnQPzd0uWwXeH9AzvfI/A58S6y3B59RlzFd Nv4enn8ffMT6/Zi4b0P8t0XuJ8j9FHlCKzyfUrblug1j/ZexP/b3zA/geQ/eD4DIeo/1/r6Wxa27 42yqv/9bXGmasdfItfseZBgxV5Y9qwJxEs5+VZVYqcb+Wp09qybxWZs9qw5xU489qwF7luzJwu/J eWga09aQPrdH14Kvhr8/v05sVya2w5FdkTHKsz+WZbzSxHiY/h6l6JCPWJe99wr78BX22svss5fZ Zy8R7xeJ94vstRfYay+wj8t+fp672Qu6v5f05Yi8krQXJ+6Lsl4KgvzU84LctOfU34O9wFq6iPyL jHOJ8WSdXfZLry56uDva9OidHr0zoHdGkMlc1f4MCjkjrrJer4GbSuuehofAkxVImZn2jPg0AxAa oU2HXzLgn4xAzpYser7Eg5vw3cT2G37p1UWOyygKoWcBkA8d8oLc+CsnyI4ucjYJrfDkoJ4TyDmV HxSAppDiUvB7EfU5d+ozf3WZv9qcsTWZw+rMXzXmvCpzWBn9KqFbBfQoi8zSyCuFrBLIKaZn3iWV J3JDQVH6ikNTEh3CoC+LTeXhr4iccPaeKsh9XeU/ID7+Ik4eElePiKvHqov7/xvN2FeasZ80ZV9q wv7URM9CA+RsfKJnZX2frwFnZkP6GnJmNoKuEXtRYz0zk4Ik1smS0mVSzdlHvLP0VcZIpn1C25h6 E/a2pvQ1ZQ9pCp2UQu/W6jvs8+/oGVuM87UQ52s+zp+cnD1ZOWczcS6lVXrha6Z1aZO+XNAIrfAI b5ie1U6elC7u3jJl6SsDSmu70L0F3qT+pp7rAo9GSncn0VrP+7LaJjSOVtpb0yZ9Une21OA8rs75 X5OzuTZ7ZT32KskPGrP3NGNPacHZ21rHkPO3BNeh2FUAH+fhPM0OvZzf6eEXGamDpch1YxRjDiV/ KIGPS+Hfsvi3PP4Nx0dV8VE1n1743tA26UtO/vAqtMnIQ5KQh7xCHhLgLH4JBLQuct3ZIblJKPKL UBbVnMWjL0y9kOYtXil07ulEUWwtzF5cCLsLMkeFsKMQehRGp1DGD/V5CqFHQfQqQF8BaPJDW4D5 LMJ8hgKR4+KqDL4JY45LgZL4SPqEphjnQgltyw+EpiD+KWSF3t2VVWTPr4B/y4Oy9JWFRvo9usJA 8qqi0BQjRylKPhUKiljhc/NfUfMsybcKabv0V6ZeGTmSh4XTLzTOb5WZr3BQkfmX9nBFBujTUKa1 rl9K9wajAXbUh66u5pDZyCGzMHcZmbt0mtt5PGmZx3TEVibmNgSa7MRJTnjyEDP5rchw+UUrU4HY Ksf6KMNaCSPuShJjxVmHRYjDQsRjAaX3+CR/LUz8FaVPaEppbticuG6JnJbIEXmtyRVb+fXgd6DJ 11qSq7Xy6ZqTSzYjl2xOLtnc1AQ1tBQ6tw5bkw+2JsdsGeyrA3890Ih6U9AsWAqtG6s5+WUr8srW 5JStlUbQXPPS5rRLfwvyTyld7DTWXLUFNkne2hK00n6h93LZZtjdDBpXNg/Oe0NoJLeVNumTfLc+ 117p1YXG2dXQvAXtm9B67R6tQNpaW6/fo5G6O6Nz+TlwXpBfc+L6rIMGrMmGxHUjYrUxMdqEWGpG DDQnBloQFy2Jj1bMf2vG8eQ10nor4qclsdGCOGlO7DQjdprC24Q1IPl3Q9aRyJYx6mn+nd/UZfy6 VvRwtmeBLivwdKtLnl2fa8nRG1JvpH1Sd2dzeuIqA8jMfiY5e4iRb9VU5boGqGM9eQ1orwNqUK9q s0GTzci3gIS+OLl9qHVypHR7ShbWQ2b2hizEewjrIwtrPzMxn5H4zUAcpyeehV74M1LPRDxnJq5D WJtZdV1mox5iRY6TmZJzNAXnb0q9T5D7hZT2NdZWOtZWFp8+A+svLWvuNfpSQ5Ma2lTKI7yO/0bw iVMq/14jpZbevUdqrqV8TcvrSuPeSKT0rz2aa0rn2qR0+USoiTWFQUHuRfJzX5KP+5E83Kfk4p4k B/ct2bgvCeE+JjO5WSZysgzkY+nIxdKQQ7xG/pAyqMM12iS/ukKOJLma3AedJyf6kzznHHnNWfKa M+Q/pxnnFLlNHDnISb0PcjpI6fJbuT/5kPPgPfKHt8kZWpPvtCAPaUqO05AcpR7j1WCM15Edjszy yCuN/iV8ed791QlymjhTjv5wxq+KLjXRrw76yr1VY3z+FrnIu+QiH/j3QzLui/6XVKw9ZY7ZM+ao PQcumMP2ojmkOGdi7Flw2hy0cVyfBHH0n1KeF735PWwvmSPgGLKO2T+hPWuOI+MYPEf9cY7Y89Bd CNJK6f5KI4b+g/AdRIfD2ifXZ7Q9cYyTtJ2gLc4cQPYBv1/oDjKO6HlQdRWdTyit1N0eJ/rEan+c LyvO55N2T1ehOaG2xmn9ef99pLJKmLX2qlmjuEb9Orhh1tmbZr0i3mwAG22C2Q522tsmyt41q8Ea e4fyNrhlVoGV9K+CdhnlMvqWQ7PU3jNzwRzqsxTxZj5YhOylYDljrWRMGX8tvlqLz9bh23X4by3+ 2ID+GyjX07Yef69Tmsuq84vm7w/kbgBr1Z6r8IhtV9DzKhD7pC+e9nhkJkCboDzurV4U+u5C1yhs 2+nbvVV9EO/LFvoEswmbt4Md0O3A3p3Kc8fndzLuBfeKVeq3e9oWpb67g173tH0l5Wq/7varVYyx kvFWIn+V+vmO9gvPWsq1tK1h/NWKBKX3yptarqFcpUgIvtlarnPj0UrfMp2H+GAp/S7GljPOCsZZ rnOZoP1LGXMZbcvo89rvqe4e3b3g24GZOtf3mOt7ZoG9z3zfN0uUx+NbSv88MIf6bMXdII+Uwb80 QK+ZjCttsxXxtCX47V6f1N2ZtIbYWEOMrGa+VzL/y5nvpcTYIjAfulmKBOoJtMWrTSvURzc0BtfB LzHmyjXP/AXrGvaBNcTiWo3N89Qvar9Hf9GPUek7q7Er9Ku19OrOpg2sx/VgjU+3gbW5XuM8DpzU Pqm7eF6nel2h/RLtF8F54u8cOO3LOqVjr/X1kVhfF1wfievdxfdv8P6Gnr8qzpuR8I0B41hfkxWX zUT4x4LRyPqN6xGMPRz8Qv8I5RMZZ1TWi/43hjfGBcrzWh+JvcIn/CNok/IXvy79zs9TVIfzZjwQ nUaqDI/uV/QciR5jwDjqk8Ek+h2PlO5+ydNXdL8M/xUzyrdpPHExiXIK7UI/SSE2X6H/CjZf1jFG IHs4+MW3fTh9Ik/q7l5jpPrgDLRn1ZbhyPLGFf4Lz9h9RmlHMle/+XUXDx7NOW37VXFOebz289on 9Re99dmNjlGMtxP9dmDXDuzbZuVLStfNFuqbwEba/wAb0X8T9JvRLRLZu/VX1S6+8H8M70DGTvh2 I38XtDvg3871dmRu17GuB/erDTqGjCVjytiiww10uaF0Qr+Nvq2UkZRbKDepTldUP8cvpfNvJHZv ARvR8Q/G3qD0wncZGy7R59kRqaXQnlN6qSf+1bbYeF7bIn17o/SL5oLz2id1Ry+27oFG2qIUF9V2 r93rk/rz8+HifgW0K+hfjo5LsW0JWIzOc8As2mbRNwcZc5Xuwgv/omMRvlgMlsC3DKyEbyW6Lodn OfVlYCnyloDFjLFIx7kS5JPS7SEzGW8mfbN8Peb6/UI/B8xGxmzkSenRXtLS6SLjLgYL8OF8yrlg NnoIjfCIPfPAfNoWUK4AoqfwrQBSvuh/vE7n/JrO3j4FTOIs+FkRzzq6AW6yjuKJ/xus+Rus+Ztm AphE2xSup2LLdMaaTjkDe2awr4u8F/1vy2mcLzMYZwY0UxV3ob/jt3t9Und+G6a6iF6i3z3tE/op YBJn4c9gOPVhintKK3U33nDifhh6SttwxQ1obmr7z+g7TG28/syeeR17Xb+U8VwnsAfcoO+m9v+q uKF1Nz9TdD+7jk7iH/GT+Ou60gjfGDAOWROQNQlMoT4VmmnwTUMP4Xc6z8Cf03RP9frc9QyNi9PB utuvZ+j83Ta/I/d3pb8a5Jmm83MNJMhvMKnPvdKrzwjO1b//cicG3kPw7seve5G/F9o98O1B993o vhvb5Ncx9hO/+6GN+T9yQmfTYeQc8mlitH5df0FB2o/oOFe17uhlzANA2oQumnndr5D2+9on9cS/ ULkObqKT6CY6ir53wF2zz6fdz3U02EffPmzZC91eePZgyx74pfTkeGWiLvKrl5e0TWjE3n1qt+Ci 9knd3WN6Nl7RX4c4oLyXKa+p3Yk+SvyrTPct27ncc801T8wcMJt7u9laf0T5EPxFn+C+mcf92Xzu 9xaYW2Yh93yLuG9bzP3mEu4zl1Au1jbpuwseQPsQnscq/0X/u8Ab7x8dU8o5qstT+J5QSt8jv/9x MD7mqD4PVLfZSv+Itofgb+p/w/uXX3p1oXfPypai62KwiPvVhei/AJ3nc+85D7vmovcc7mmFfp7i Pn3kseYOtLfgSYD3ptrq5Ei5jPteV3fjeDb8A/9jeB+qPxYhazHjLGHMpc/IEB8uom2h77sF0M5T Wx7pnHi+EHmeTKm/aE+9R2zdI9buEHe3wS1iNgHE2wfmJrhB/Rq4Qt9lcBHai8TuJeLrMnFylTiJ B7eo3yVGRd7zc+fO/Xj7F7L/Ypz7jHff3EfWfejvKm7TJnrcpf8u8u5Bf1918PT5C/yt/FJ3+9kF 1scF1ekeOomeou8Dc111/8sfU+Tc5/qeb8ddaAW3lN/tqWLLFf3a1TXk3aAvXvsvKRLgu0n/deg8 u92+dl99eBMbrqP/NXT3fHKDdXVdv5x1VXniQQI0t5F9F9li933fXzIn81VeKxMeuGlqgTqBeFMv kGAaBG6ZhoHb4An1gG0QSGnrB9LaeoFMtk4gm60dyG5rBnLY6oGc9g3weiCXrQLCA7ltRVApkBeE Ug+zFQIVbblANfCGLQvKBKrbMFAqUMOWVNS1JQL1QWNbBBQKNLH5QG7quUCOQAObM1CEehHaQm0e ynwgf6AotEVtYcbNAbKiRxZ0yohuGQIh4JHJiA2ZsScEu7JjXy6Ql3oBUJj24qAkNCUDf5sS0JcI vGKLB5KC1OiTBh3T2tKB5OC2CVO6BFMKGWGgdOCGKUtZDpRHXgVQiTbx5fP3G43Ulwn4Nh4fi6+F ThBvqmh7Av131OdC6+a5LrbUx+cN0KMhcyDz0SjwwJd3m7l5AJ6Y+sxRffrrQVfXnyPhdWu9ks5J HuYnD/OUm/nKzbzlsjVALfxWB78JvfDV0rnNztzmgCYHtDnhyQlvLuYzF/OZR8vyyJC6yHb7ezjz Hu63eXRy7bVJ6fxRnjioSFxUIj7CmVPpq6gIhS8M2S5mXrdC69ZzyUBN5qQm8VODOKpBPFWHprrS CK3wlAWluS4FStInMVZCUTNYihyXR5UM1NP4k7JUoA6orf0efV1ioR6or2Uxvy607gyUuC0ZaKRt Hl1j+BpZr93rk7p7t5KdeM4eaEhMNyaeJdabEsdNif0myG+itMJfBBSinkfXQSPohc/jldKNnxOf 5WA9ZNd10kDXSS7Whdfu9Und+bCgrhtZPwJZT6HoURieUKUT3tz05aHMC/IFikFfjHVW1C+9ushx OhRmvgsREwV1PRa1odQLEzNShlIWVuR+5vftQnSdZqY9q67f3NovdDm0LQdrObvNRDxmCGTR9ZwO CJ8bMwPxL2s8PWs2va53kfkaeGQy0ZeJ9SQ0bp6L6NqXPeAGc3CDPeEmNPFKI7QhrMHsXOcCeakX Udw0iXFimMtHrP+/wV2ubzH3Hk0R3Uvk+jb4m/ojIPQmOO8lWZuyn5RExxK6vySl/orSFFe8wvwn Bampp6E9HXGeTstSgfR+PW3w/VNpdA7TfSm5tkt/Gepl0KMMfWXpk7rQOZ6S6FpC97xb2HBH+zya W8iRvS2BMl7p3LOKSoHrpiL+qqCQvU72PNn7bsB3HfobSi98pSnLUJYD5ZFVAVSiLntiJYXI8uRJ 3c1lZaXx2oQu3L+urPvjzWDd0bu9M5HPu66kOsYH+YNfqHia+D8jU/wrI6nDbNYJJOFUS83Ol5md L4RdL6utTPSVBMWolwSl6SvL7lo2kJGdJj27TgrwiBHvmqqgGt6sDUTei/4GoBbRXAs5dRhLxqzL 7l1Xx78L7xOQhP7U7MyZ0SWTdfRSOhnF0a+Y6pYdHbOjazZ0zqo0wvMG5evQVPb1dvRSOhll0b9M IAPIpHaVgqck/Ymys9EmNodgb2bszYitGazwuRVRAVvLo3c5fFAOX5RVn2RgB08BHjHLd6G559Pd VlqpJ55ud4H47Da+u40P72i/8FQF1dQn4pt76p96ijvKUzfo43/PZxHoi7CiQllRoayMIuiUk9WR k9WRI/CqzRZIZkOoZ6E/JPCUlf/QZEVedpAT2blBXur5QQGVde+FfwtQBL8URX4RHecV6gbcM6EK Vj9thekLVZr01qPP5PNkDP7KRQ76cvr9RbSelp04nXXtWvp3F9nVhldpS6HtQpcLe3JiV3Z2kGzB 0tVfTXyTCk8IyO77IQt8WdUXKUBK7ZO6O6lD8EEW/JMFP2XGFukT+hDfd1npy4atWYHQujkoqn67 y2kjfhR/il9v49/b0N9RWuHJDnJSzw3yUBd/Fw7cV5+LD52cosE5SJzvLjpWZe5uXrHLzMt2BVhJ fRVYTX0t2GBesjvBLhOQv6gFr9hok9TuN6/aGJPCHjIp7WHzGkhrj5h0IKM9Cg6bDPYg1/tp30f/ bpPKRkG/A2w1yW2kSWa3IGcTmqwGK5G3DFlLoF0Izzz4Z5tMdqYJsTNMdjsdTDVZQRY7mfaJYAJ0 E5A3Hv6x6Daeu6hJ3D1N5e5phjF2Fm1z0XsB+i/GlmX/x//gdHG4CppVar/44SW7HCyFfjlUyylX KDxd16h/xE8ej5ROzj7G28PYuxh7J/W1QPqFfi3YAP0usJf23dAI/T7ohUfqbm84YtLgS/FpavXx QXy2D/59Pt9uZOxBl4P49RA+O6S0aYJxdxT/HNX5SKN9h6kf1rnJZI/hWynjnqm7uJO52erPUxTj 7oU/Gv4Ykx45ifyHuT5I+wHtT40uKbFL+JLbbcylkyOl2zPXqP9kzpPazcx/pE/n0SclHpJoPGwM xqBXrnnmfyTNMDns72AWsTDHZGa+kmv/Kp2fZMxxCuY6NXOehrlPrzH0OzEk8TNDkVP5RY77n3QT /HiahLzJiix2CjxTNN6y2Wk+vReH2UBW2kKAxGJGeDPCK/EoyOzHZqag3WOY2zHM2Tj0HK/xmlb7 J+m4aUEKrpPQb4C1jl7K4N+/mMdmHBjj00wg1scR6177I+2Tuss6lvprejGxt4CYmQvPLHhnsDam wjcJfo/3HzNR26RPaIRWeF62i5CxVOM/yTOlW0NJ/vVUrz9z2I856Av6MKe9KXtDH4G8COT3Yay+ lP0Yoz/tQv+icz5CZSRH1qvQvwptMsokXCelXSCyk+o4Qhuh43l196ShL+P1xs4I7OvFuL1Uj1ds hK9fH+T1xs7eqttTaJ8qTx94hE/qbl3L+AMYb4DqHUAXYz35T6GXurS9ApKqnh69xyP15/+qZLjK rWPIde1fpqS9b8LsXVPaknPaBFPW3jDl7TVTwV4xFe1VE069Cm1V7U2QYF6H7nXoq8H3Bvxv2Iem un0CjK1hLXjJ1gJ1qNenraH9xzS2j8Dfpom9BeJNU3sdXDP1GaOmvYzci4x1AR3+RKezppA9bfKA XPYUcR9HvJ8kXk+w9o8Ts7GssWPE7RH8eAj7DulelIR94mVg2R9eoj8J9MngT2HPQH8OvgusyUvI uYK8a8i9gfwEkxd7CmBPIewpYsUnz8dF8FdJ1R+V0L0CvqgAbzlLrm7v4bcH+JB7C3whPi3OdQnk lUJuGPJLY3MZxisLf3nsrQAqBkuR6/aY+/j1nvpYfF0VPvF9FcasrHNxVfkqYoNcS7vMy+vQVoOn GuO9AX91K3Lc3UvANrAvMx8vMy8B5sdYmS+ZN5m/atYbszr16rTVsE+NzGNNaIW+DvT1rchw6yPe NGMem2JvU/uY+ZT5NbaR0gjtU9MQ+Y10zm+BeJ1zKZsFc6ZrGgPNtE36roMb0Ll2KZ3fTxELp5in M8zROXx7Hn9ewAeXsP0y8XOVOBJ64b9O/SptV+i75MfUeVMMPi+mRFYcsk4p8gR9dJQz5BhnWSxx cpw4O0GcnCRO4oiTUxqHefyYlOsQPb9OEk8nlD41fCmsyHBvww+yLg8oJCaTaJweZk8RGqE9pnVp S6rxe4j1exDag8RvDDMm/DGsb5EhdferQBJfD7HnAbF6D5vIyJn7PMRATnnfg+0h+CSTxvqfnENn OaNPMdZJxolljCNB2QHGfFnXyXHWURw6nfbXyXnsv8hZcpmz5ipnzw2TmznKx1wWJFaKEiclNMad Lg+Da+bff/87mrN/DPqMQa+xyBqLruPQeTy6T0DWRGRNYo4ms5YmM19TiOvJYBKxPom1NpE1Mp41 NA7aMazT0czFKGSNRO5v+HIEo/0GRuLLUdgxGjtkzBe9eR6n44f4OqWDJx30Us8KpC9P8MnbFNbX VHSZonqJfqXRqQQ6FUX3QuiVX+mFb6zWC9MmfSWhEdpyoCJ8VeAPt548J7NK8J5gAjZOgG6i2it2 V9F+4ZmsqEib0Hh0UjodRzCn4oNf8cVvzPlIbBuFj8RXY5mbcegh9B5/mOo3lr4x0IxW2nTwpIQ/ CXKSWpH3C3ExQq9fCeo4RudRfPsqPEnh8fqF5ze9TgaS05dCZY4JzkHiueP+t99vxNJI/DfShEJb DJklQRg8ZUEF9KtEWYm+CqAcdGVAKcYpyXhF0K+AHU5M/kw+NIy5+4mYHYoNQ9FjGDoMJ+Z/oe0X cqMR2DiCdfEr9DLui/b2sfh5HGOOZX8ew3hjmOfR6DZKdRRd8yEjPzIKgSJcS19JEAadp/cYZIxl fkTWeObYkxcezM9/hf43tUPsEbvEvkrwhyud8I4Bo2kfTf8o6EZBPxJdhNfN+VA0H4KtQ9TmtNif Cbuz4Y/c2F5AfST0Hl8RrgvgC+kTGqEVnpRAZCSzIm8wcykyh+r/xvf2RLH5N/h+xX+eH8WnqZCR 3Ho6JENGCq5TIzstyEh/CBD63OqvkUGfJ8ZBcpX/kinJflsSPaR80RvWMO1PyT3Ca+TMglR6HaZ4 JVh361towtDH8ZWk7rV57VIPPv3V8dNom9CV8PulvTjxK30lgrol6u/GKk9fOewrw/ovg71lWVNl 2EfK4Iuy6Fn+/2NXOXxTHt4KKuM16PPptddeMFhP/MuFXNDIX6TlBnmV3skoq3tWbq5zBUuhDz4v wg9l0Kc0eoUx/6VVx1w+fVaQlnoqytTWo/Xope7+96noWYH+crSVVXh6VwjamLj3u3gfSN9gxhtC PAxFz59YS4PBQNbQQHQfgN4DsKk/cdmP86Yv504/dOnPOAP/D985e34ipn9C3lDkDkH+IGgHMFeD qA/WNukLhaawFdphSh+qdfc0dQA6DNb2Iko3BAzC74NoH6AojA6Fte72iP74pB/oi4590LUvOvdD 9/5qg9iSX+kHKfLDL205QFb6M4O01FPD85r1ZKVUeVJ3vzI7KNj3GvxpfLv+HYOrlf5d7gJz26w2 r81m89vstoDNYQvZnLawzWWLUBbjuiTtpSnLcV2J9nA4wm0eWxmOynBUsQVBIVsV1ICzlg0l5ytq 69ni5HLFbWOkvwP92/C+hZw3kdeaMVvZLLalzQQy2hY2vW1u09pm9jWQyja1KUBy28Qmgz+Joq5N amtzXRNUp/4Gba+Tk1YlX6xKHlmFPKIyeUVl8ppw8ppKoCL1CuQ6Fcg1y0NThlyzNLlpSXLLUOgL QV+AnCSv/N8aeTdLLpSVXCgLOUsmcsIM5C/pyGPSkAumpp6G9jTQpSVPTovcdMhLR96a3r4CktkM 6J3RpsaqtFiXHiszYa34+EX/myoXPs6Nr3PhuZx4MgcezW7zMR954c5tQ+jJTJmF6xBtl3kqqPOU Ay8Lv9sTctmKXFdCjsxVSe0Tmuw6h+Wpy/xVDJ4nhfFdYZ07mUeZT5nXcKXJoXIqM3Jl2qowchVo hN7jkdI9dymh81yP0eoxWl2sqU0MSBxIPFRX2oKK6oxVE9SmrQ79Ql8fvgagvnVypHR7pMRPCUV9 pSlGvRj3Cq5dSmd/Hvsuer6rbUKTh7jLR9xJe177H+2Tuvuu+SsaV02IpSb2VY05iT2JQYnF5jYd cZnBj9EsxGtW4jYb8ZuDOM6J3Nwa1+/6Y7yF396kvTW+FlrhacHctSAimhMLzZDZ1KYBqRkvJUjO +F58N0KHxvYVRRPVSepunpLYalxXg0bivib9tUAd2uopXVJFXWTVxo6aoDr1atBUtcLr9p/bui7C iXVZJ7JeqrAmvPVjWUsvgSQ+n6wryzw/heYJ9A/h+wvcZ13dZV3dpXTypHTzdZu1Jtd3la6CrkNp u6XtFbXu9DHEpWEWn5KjPCEPeszafMga/Yt86D7r9S647cu4B6+3jiuwdstBXxbeMF3LFhlSBvy6 yHXfqbnEXniR/e8y6/UK+e1Vcozr7KU3yDPi2XsT2F/vEjn32PNlT3hMfmuCcorJr3vRXlD3h7vs 07I/xPv7w3V/f7jCnnCZ/eES48h4F9iXL/p1p4esY9kLMrCK0xIVrxEVKbhKpnuH7CGyl3j7yi3k 3YT/qi/jktbTMmZaxk8HTTp8kR769OiZAX6RI/IyEVuZibEQpGajJYfuHTL28/8jp57qldcsZNyF UC0gYhdAPx/6eayWOaz2WazUiWAcq3Uk+JX6L5Q/gcHUe4DurOquoAv0P4IurISujNcNW7shswer oAd69USjXljeG+0mgSnU54B5Ov6/77fc84xZjDUXufNYZQv0N65y2EXIXQTPAkVmdM4KckCTC9q8 djY72Sx0Et7ZikJaT/zfjGKL2BSKbaHYWFj7hWcamAL9SPArdaF16zCCeh/a+4OB6gPxRSg+CbWe zILUC6lvBlLvD/qgewSl8Lo9/wf1lfhMfOf5sSf9EYqCXAsK4L8C9OeHLr/61/FJGfxdE2a3K/Z3 xd9d2H1+xP8/6DwIbx5k5GKOcoCs1qP16KXucobuzFF3/ChtQtdTr7MEn+f3JlojQE/mqwfz2J35 lP6eikzMawb60zG3Mr8erZTuPmCRzrHMtcy5zL3EgEcjPBIL06GZA+YhfyGQuV2kSKu8i+y/7wcT 7wPSkmtnsVI+H0cu/wxTmteUJkzxml5L3Z0fJVmlYcjxaJ3MTNZr9/pK6l/jef/jpYR/LTSlqJdQ hGib1BPlyj1BWm0rpXDyvXuFEn79+Xdcbo6LBLLawqBgIJvNB/JQzwWyB0Js1gDjBDKB9DaEMhvX OWkvDITveX+49waZoQ2BNjs0OVWmyCazAIWpF1F4cgpCkw/koZ4L5IAvayAz/Bl1zMw6fmav9G0O QZ/MikxK411n8MtU2id1FyMyXlEdT/QXvTIzxrN8mbEthD7PF04/KUtwXdSvP+/DDiq/nIklt4tl /z4OTpApnSDnO8meH8fefoo9/jT7/mnOoTOcQWc5X85xzvzJOXaes/GCeQPUZE+vy17cADRmv29O KWhBn6AlPC3hb4K8Bsivw3g17BH4D3F+xXBe7Uf+PrKlXSCK++tdihJ2NxrvNsXsXu4l9oH95KX7 0e8AZ9NBYukA51UMcXOI+iHOnyNqS/Z/za1bz8fhO0b/MWyNxdbjihzBe5c47D6J/DjOvZPqkxwg Lzrnt16f688XfB75J/44hw1n8c8Z9VNx32eFsbeg0gr/Sa1LW1FQQn16WnnKwVsRiF8Tc4DL+O4K frysPhXf1sXP4mvxeVX8H670Z3V8qUtbdfpqAaFtABr7c9HMJsprEdy3z+rctIK+FbQtoWup8yY0 wnMR+guKFtC1YIyW1vFI6XSNJkeJxp4D2HKQOT1sXsfHNfBdHWxuiJ1Nld7jb8J1A/xRm/7q9ih6 H8b+g/jwAPO+H7hS5Lp1EKWxUUpjYy/YRz1aEaa0++mPBvvwfxTY6dNLuZ0ySlEieNZ4MRWKrFBi rAhyiwKP1xunlN0D/R6u9xKD+0A0NK4UfufHGGJP4nA/8RJNfEQz19IvdAeI2QO0xdAnMXpQ4zWr xqzUY/Svpr294QD75X6/zevLBG8WK+37/D6pO59IfEq8H1Vkgyez9h9Q3hBdI95Y2VgbQuvFvxfX 2ZRX6s/vDf9V+SXNMtbHMvK7lcTwKu4H12DXOmJ4PbZtABvxxSawGe7N+CqSediK37aRn24nP95B DOwgjnaaN/Hp+/i5DX5ty/V/wUfQvAf923YL8bQJuj+I1/Wmnl1LbKwmNlYSG8uJp6XE1SLmeQHj zGPc2egxE5/OYp3OQsfZrNU52DIfexdiu+j9ov8TsJ753gDWY8da5mYNdi3HxuXIWKr25qGej75Q bC0KXdFgKbxur9iKrVvU7uK+vFCl2YA//gCR6BuJL4TO3Q/uxvY96oP38ceb+EB8Iz6qgi/KKa3H Ux4fSlsN0Ix+oX0fPuH9r3VypHR7m9R3m0+0TWii9LptUN8d5mPkiN/b0ufRRSltW5UbRX8UcyJ0 7p3I7/j4d3wxGz/Nxe/zmeOF7FlL0G8Z87KC+VnFPK1hvtaZ+tjemJhojk9aY8c72PC+yvPkvsf1 27S3or8ZdI2grwdfLfjfQE4V5FVEbjm7GN8txK/z8ekc5nqW6uHpIqXLgRcS7wvAPOZ8LnM/h5ie RTzPZB5nMqe/a4yQ9zKns7mewxwvhG4B9MK7kLWyQMvMwdxF4mCZ0mVWOokJ1yalWyPOR2XxSVnm rQI6V8Ev1bChOveFtfBNHeyqx55dBxtrg1rUaypq2Br4rTp4A7qK2Fwev5ZBRhiyShr5vdyi2Blq C+H7AvggH2dIbmzJgS3Z0Ck7duaizMd1QfwSShyXYI7C4BWdnn8u6vQsp8+7izNWCVBKy9K0SV1o nG/roW99dK2LDbXRMRz9Kvg0Qiv6VmLPfp04EHtrsufXxh6xtS58jl9Kt/beUJvF9hr4QvxRG9ra SiM8tdU3QvOG+ucNRQ3lkbr7olc1xpJrz4dVrVy7LzFkxSfyRYkc+CoXfsmLX/Ljv0Ks91D8Uwz/ lMD+UmpzGDZUsJU5P18n/kSOJ6+yrco8hjOfYqPYWhq7ZV6KIqcw8gogNx/yc+P/nIyXjdjIrl+y kC/e5fa/apEreP+fnf0pG8iqcyf65fB5vHYp3XlaTuepONdFGTMUnQuhe37mOS9j5mZMx5cTG+V/ EOdBn3yql+hXCt6y/jyLrPLoXs6vP3+v4PLAveZbzqzOnDM/cm51Az05bwQRnCV9OEsEA6gPoW04 +BX64aztIexRA1jXfdjDe7Kmu7CmO7Omv2FNd2RNf83a6QC+YC21Z+/4jPX9CWjDGnuXNd6cdVmf dVqd9VrJTie2pmDDZPw0DZt/x/7Z6D/PlIG+IvxyJtREtpwTTRivJePKvvIB+4ucLe3YzzpYsef5 M8A98/dsExt/xF6x+Vv2w2/ZU7+HrwvX3UBP0ENLoXf3yAeUtwdtPbTdo+tFWy+9PqDooTRSd/eK h/DPIe4YY8ABfHrAlxtNfT99MaYv/u2rvna0Urq1E83d+QH9Jdjh0A2lb6D2xygG0D4EWT/rr8XK 3Hj0o5RH6i621mDnauZmLbauN13Zh3tyjvXFdwOZy6H4YLjSe/P7M74cwt49gDOpD/t2T862LvB1 hv8b5rhjsBS5wfta5naRzvFnzFd75v0L5v8rzvNvlE7oVxEXK2hb7sfGMuZtqfkf9J8A4W8TfC83 mTifRDxMJi6msWZnECcziZfZxM088tIFxJHQe3zvct2c86A+/dWhq6gxNZU1NAUZnpycdiJ5kau7 vcOLgw74oR0x3QabP8Dmt7G5JTHdGL/VQ+ca6FmVcSoSu6WJ3eKMUZgx8lmn51TidoYft3M1bivh i9exsSY+qI/9TfBhK3z/DvI/YJy2+Lgd43Zg/E4ai/uC8ZuYl7l7Dvkrk/KBQrZcgHUeKGtLByrb sEAVWxKUCFS1xUBR6kUDlaiXB2WplwbFqRcGuaDLBX1u/YuVF70PKo2MMqBcgPMpUMJWYMwK0JdT FGJszhFkhzF+6UC4dfRSujy7CPUivk7FA6+rfmGgtNKFK29JUILrYqpzZS0dn5Ru7RVRG8SW8rRX 0r5iikrILg/K0BfGdWkrtG7tFQvkpD0XKEx7ce0rpigOT2GQi3pu69F5tFJ3/BXUT+Iv8VtO7RP6 EqBkIA99edQnFRQ5lbZC0K+Jf7k5zYq8aNOJfbwz8fI9cfIj50hX9u1uxGcP4qgXcRPBOdWHvb8f 501/JAwkjgaxdw8BPxHLP7MGhhNXv3B2jSC2RnB2/WqqgdrU60HTGNoG8NSDtw4yatm+xF5vYrcn Z2t3YrErMfwDfJ056zohoyPx/BXn3ZfkIu2J6/9RtkP+57R/yfn4FXQdof8Gvk7wd0bOD6yvLsjs huyejBPBfWdfxo1QNGW85tjRAjveRId37QBifSD54ADywQHkhv3Nf7S9H2usn3kL3jdBK3hawt8S X7SifAs574D3aP+A/o+hbQvfp6Ad9f/R9gl9baD5CHwAz3vwvotOb2Pr2+j3DuV/8O/74APaP6L/ v6AttJ+Cz7TsyXUP2rsp2uCjNpT/g7c97V+Cr8FXXHcAX9DXHpp2zGF7fPEFZQf88RXoaNuCT6l/ Stv/4P0f/Z+Zz/Hn5/jzC9uBtq/p6wjNt+A7rjvR9y2yOiLza3TqAL5g/Pbo9hn4ALoP2Rc+Nt8h vzPtnZH1HfTfwdsZ/b/Hpu/wQSf83MEORuYQZA7hejD9g8wP+L0LPusKTXdoe2BHT3TvyXz2Yuye yOuJjj0Yrwe6d7dtOAs/hv5D+N7jvPwP8t9lH38H+e/gn7fwZWv82hp/v8lcvcWcvc28v8Me9y73 /u8Sg+8Ql28TJ28RM28SP28ST++RV71PnH1ILLchxj8l1j9lDfyPtfAZ66Id66Md6+RzcpuvQUfq sm6e36tcHj4cOT+zNn5ijQxlvQwGA6EcgNx+rKU+rKnerK1erLEejNOdcbqy9n5krB8Yq7PKzwPy MRf5WZsFaC/IXBbStdkdvp7w90ZeXzCAcQYx3hAdM8wOw5Zhui4FpVSX4c88v/gVP/yGH37TdVrF X7flWcNllG6Y6l+WegXaKgGhqQZqU69HWdf++szX34ayxmWd/+r3DeV+6ifgtTfRPqm731Voj+wv GK8D8jsi/1vm4DvG+IH56MJ67sbc9GQ9RzBPfdgv+jHuIM6qwcyhJ1NkN9D9ZIDuJzXwRXX8WQ3f VMWXVfBlZfwYjg8rsk9UYN5kvLLMYWkr47v86zPqn9HXjrI99rf3aT7TfacMKA/KEg/ltC70zo6+ 6NMPPXqw53RDhy7o8AO6f48e32HHt+gi+9RX6PEldgrv/3SsCoxTCR9URqcq6FYVHV9H12rw1kD3 mthQC1tqY1M9bKuPHxpiZ30rYw7wx5W6y+l76z7XUNuELgL00javlH53dvVjH+zDfW9v5kbaeyma Qttc97veuk+2QE5zLV3eN4C9aBB73kD2rQHsY/3ZI6W/t9JK3dtXB0AzSPdWoW8brLt46c+e2E/3 W9l3P7KJcj8E73P9rhUad//XW/feVra37setgezP7+h4QufRiz5v6f7eD7q+vh29QIRfCr/zV4TK bK1t0tcT+p7UXSn9LueTvX2AQvb5tsj/GPkfoIecA3IevKn0PVXWW9S9M6I39vRRWuH5FIiMz/Ss GMz+KTKl7nIpOSN6gJ7Y0wv+CMboDX9v9rY+nCt92X/7B2V8qmdPX3zXBx/2Udr3dGzRQWS53Km7 njnvWil7KN7WfqHrDrr551JXaLzSqwu9e17UizF7Kz5hDDmr5Mz6CDlyhr2HzP8ovSfjPervgw9p /5j+Nnqe9UJnJ0dK95yjO/3P9vXWc7Ct8kqfi9tuega21fNQ2qW/q+K/rL02oG2wFBoXtz04/3py XvbUc7MdvJ9qv9B1xadydnanr7vSfGU9+m+UR+rOj12g+5EzrKuetZ/DJ+euo5eyA5D2duwDchZ7 pfAlyvgW3o5AzuYvtU9ovkfWD/D/SPuP9HdhbI/Wo5e680MbPdO/YY/5Br5vtU/o24JPaJP+j2lr 69fdvt+OsT4DnzDuJ4zVlrGER2iE71M/T/ifnyd8BtqhV3uQWLYP+rWT5glfsHd1AF9p/tCRegfN LdorrfB4OUYH9rmvof+afVn4vgzm5e2Yg880t5AcQ3INyTnaKY3Qfoe8Tlx/Q9/X0HVg/r4A7YnF z4Dwu3X9ITp8wBiezE841zuAr4Kl9Lv11knzlU7o1wlZksd8h9862Y/wxYfKI7K+5bozPvoemu+h 7QxPZ/b279Hp+2ApspwOPTT/6axt0teTXKcXcKX0u3U1FNsG46dB+KgP40YwnuRNQiO0EZS9ue6L Xv3pH4Btg9BL8imP93Mth2KvyJG6u1foT77UDwwkZxpMvjQEXYYix/ENpj4I+QM1F/sR2i5WeFwe 8x/a3qPtA/g/or0NOdinmo9JXib5meRpvZijCGK3F3HaS3O4XqAPdN74XdC/G23d6esBTQ/N8SS/ +5p6B/A5fe1UdjfmoCtz0AX/y9g/MAc/2P9ortdFdZG6Oxdaaa73ATncR+R0bYDkgd+Q532ndB6v 1DvS1gEIzYfQvwfet45fysQvi9eBpjZyJFdsSP3/tffe8VUVTfz/2SOC0nuvkoQOKmBBsQAq0gkk pEAgpAChpBAIBKQJNlDphF5FEbDTu3QEQUVReu9I7yLf98y5e+M3z4vfn7+/vs/z+rhzdmdmZ3dn Z2cPN/e2IFdsDX9beNtpbin8oYoI2trB0xbe1uhvQV9NQWPoN0Ajfyl67bqEcPaHaO75GvINtc3j aYAuqasP6oGXjMdbT0s77jhyvjjySMlVo/VXBp6lz9rKIzLh5DyR5BjtyVmiqO9Eeyx88fB30dzW K0WP3cuS38aTZ8brLx5UBlWQqaY8nkw1UAW6MqjEegWCAPaElxtn/k6V5MeSJ5enrby2CU93yiSQ DJ2qqPA/7xTsvx+Eu9VNOHfhCLcKqApdzUjdoz5nG879Pwz+MHgiFJXhr2K8eq9NaMtv+SLRHenj C4cOox/bFubvL9M++853uKlu+oM0U830MVWNPD/qvUVfUwWeavCKTA14ayj/MOr6a31VY3mkTPkP bT8XYWUsn32WMquNuVUmmxPh1mZMNRjLs0boR33mIgKeMBAOTySwz1La9YhUHZbvWUr8DVgdVjbS 1xbmew7395tpn5XZY+qY9WCtqW2+BjvBzzxLfVZbrW99bZ6Ft45ZCVabuvAKapstYJO2ee1SZv6O pMfzs/aRybMT/PwfHVJmtdV+duUL2hcDKR81j4vRtxjdXyiE9p6ltDxZ2+yzlFnfz9jzYRYxYTbx YTZ56UxFsJmhaG2mKVqaqdyHppDDTybuZBBvMogpk4gjGcSRydwrpoOZPM/kfiL6so7BxqXZxLE5 9DGXODYHfXO03wbINUDuTdCG52Dj8Xm8Qlv5qdgznfaZ1M1WBCMjtraivpXx2ltrOZV24RXaxl6x dxKYiK2TdAwylsaMoQnjaw5vS7+O6dDTGPdUbXsLHm/cGcjKmDMUnj4p/b/xqPP5OvJevfBN5t41 FUxDdjqYQftMRQNj+Wf75y2Hf42K6zu0j8j+65sQ86ppY143rU0D0wq0NA1NC/MGeNM0NW+ZxqAR /21gmsDZ1LxsmpsXaa2D1DNI1zLt2NHhRIP2prKJMkEm2gSYGPOU6WzKQ5cxHU0p6kuYDqYoPIVB ARNp8pkI8yTIgWw2YKD/4Vy6Rz5+h3PuFufbDc68q5yRl8mTL3EGXiDvPUMudYqc6iR5wAlyiWOc j0fJLY5wfh4lLzhCrnCEM/Qw5/EhzuaDnNcHOOf3O+9SDqf8wPzljDL7nDHmD2eC/lLdXv119Fnm F2ee/pr6Hmcu9Cz9hfRfnWm+X7CbBMYi9xHyomsgulPppyf9xpvj2HqK+8hpztWzzOw57mgX8JVL 4G/87Rq4jt/cBffxA4cZNyaYsQebx6GzgxzQT4JczG0ekM+0Za7amoLMc2ETyvy1M8VMGHMpnw/u yBx3MhVBAHQAcxyoaM8aRIIIom47om5bom0w69SS3drcPM9avsiavswav8paN+D/jVj/xrq6r7Cy r8Bdn95fQZKzXj6vm2Xf2by8BXpa4ict0RWMnjagLbrEp0KRD0G2Nc8tqW9OL83h9XxL5DxZoe0v BASYWOyPNZXwnSqMqRo+Q0TH9jBsD1Wfex6N9ZAUP3zVNENzUzS+jf2NoRqrPumjKbobg0Y8y+he wX9fgv8FWp/D02tjcaDOXwwldy76DTBx2r/Q9neFH+CP/4C8zGkB5raQ+nGUKQ5KYWMZdJTD3go+ HYHq+9GsTydTFp7S8JdArijyhVVHBOsazjqHs95hrH8YfhBOH+FG+rKfnT2GPx8jpz6Gb5/Ex07h 72fx/fPkyxe5H/zNXrjCvrjGPfIGe+QW/neHPXOfvePZHM5eijC3oW+S812n7So8l+G/hNx55M+i 5wz6ZD+dIAc/Ti4v++mIbz+JDfYzfQfw+YPso0Psp8PsqyPsr6Pss6Pst2PsA+E9ouhLez/40uEf yD4ZzJ4bqntmP/tPyr90Hw43otPmNgedEfB7dV7bCC2l/pCWHm3t+cX5jL35GXtztu7fP/SXJyeY P9nX+52Pkf9Q+b0+P6B+FDyj2e8TfL9KOV33+B72vNUlpf83mTUOzNc64dmt7fPNbsUX2ia0Pe/2 0u9eZzx6J6FrMrxT4ZkBZsE3V3l/UcylfTaYCe80/WXM35H5ndgiOn7T0qPtfe8kMeUY63eEOHMI XzjAfO9nbv9krv4gHgmvyP/pjNQ4J/N+SGOhxMd41rYjcSlM45PoekH1lpS/3MVfWhGTWuMfrfGl YPwqGP9qg3+0IYa1xT9CkA1VOZE/A85Cn6fuAm2XwGX4rgCJcXfBfXQ47K+HGuda+c/ZHOzdJzTO tcLvW5nHNAZ6PB5vG+rbEA+DiYfB8LUxItNC5QPJwr2YV4F9VZa9VJq9VIq9I/GwOLGuKDGiCFGn kMZNiZ8SRyWeBpuc2m9r1enF17a0h8AXQnwNZW+2QzZM42txdJZU3e3Z3x10H0u8rcC+lr1tS7HH /+1nyAQhG0gZiG0ByAYgWxHZimp3R5WpCIL0nOxAnIsEEZybEf5S9Ni/RZU43BRI9GpkXiOOvQ7V gDjWiDj2JnGsMXGsCWdvG2RDVVZ0VNUzOcTUZNzPEu/qEveeJ0bW07j/JnGzEVoaEiUboOE1+ngN rlfhfoUZ8uK/fc8scVzOgGCN5dL2KjMnkPjuxXjhaec7K4R+1P0jyG1kgtwGprJC6EaP/HxBFeV5 HZ7XTSB0oPuGqQR/JZ+8lFUUryuf0JnfGvcmz420rpKiETwNjVfvtQlt+UV3EM+VFQ2hG6qM1AdS J21CPyrPnu+8beZzf5Yy63jsu8LPlaex8n2mn9UQNNY6oa0t88kXP4dH6j5TiN4mxqv32oS2euf5 noVH2uYpmmvdPP31Gqu3Mc9va53V79ks9V6b0FlzxQSVr00EacHOawWC8eS2eHAIaIeXh4EIPFmo Dqx/R7wxGl+J4ZSOR6obJ3UPPDARPxuCvw3BC4fie0PwliH48mB8czA+OghfHkRO+Q7n/UDO/QGc /+n4cn98up/eIOWWWRU9VdFbDf01sKYWfT6PLfXo1WYbjei1Mb02pdcW/DcEhEO3p07G8ajPrbdH Vwcj/w3XsXVkNJ0YazRjjtaxt6C+BfWtQDB0G52HSEYeyRxEIBupM9HB9//2Stscvjm2t2AuWjIn rRiDaJeehCdStbTXWW1BHtIcnmbwNkVG5Ow6NmHumjFvzXU+E9n9Q3gebLz6YdomtL27vUVdY569 9sHQg5l/WYNh/jhTifmtxDxXYb6rMe/Vmf9arMPTrMezvvV5AZl64GVdu6EqL3reoE3W8EV4nwd1 kasNnlEdA1ijdH2DUJU+Kps0+uhvbH9S2rmpzlxUZU2rMC9VGFdl1roya15J117k5Y1FCvYlgnh0 xqI72oiczR87qY82ZzabMa+y7k2oaQIlN5lmmoFKpKvP7Ndj/Z5nbWvCLTpE19PM/bOsQ11W4gVW 5yWNcsH4VCtkW2p22RQdLdAVAsKg26s/tNRVs/138vtY5t8d23FOZM9N4szN4NzMIEebzLk+jt01 Du8by/NYIu4YztLRnIejuSuOxWsmICNyj/o87mTkp6BnCvKe3lb00dQnJ7TURYAo+utgPH5PRmjr W2PVlk5aJ3zjeB4PLfVjqZc2oe2ZNwFvHIN9n2Lnp2pvW57b+cbhyY5nXON84xpLbjAGvjE6rhbY 1wzI+DK/dXSS2txE66Rtom/8kxRNtG2Sfy4yP4NnP29djz5eZryvgNew5XXQkJylEWjMHLzFuN7A robkwK+TA79K/vsK+e9L5L71yH2fI2eqQy78LLl2LdprwFeVnLkSqMhzcfLwEoyhJCjF3JYGZRhP WUULUw57y4OnGFsAZRVQlfrqoAY8teB/GjyLfB1O+LrgeWwWux/1Lq6RjqEd+zWUMXHCMs/1wUvI 1tMyxDfmdrSHwRcGf7gROTuvbzP2t3110taYe8FblFLfREuPtmtbz0lEZw/0dUVfHHIx5k3WvzHz 97bOYzjP7anvSHs0fDKX8djVDZu6mxeZx3qKzH+3CEBPJZ3PztTFMBdx5hn014b/OeZeeEXmefqt yxrUZm2eRm9N9Fel7yDwFM8V9d/I4vxjK6Zr0kPrpK04siWoK6boqW1C+/9+iPkvzvx7ct56lmAu vfpW1LdW2s5FedayHCjDGpYGpVjHkopWyieyJUEp5EoD8YVyoILPF6y8lDbmvqTrHsy4xQ9aM9ZW zIX4R0vGK/7i+U4l9aNmjLupyou+QK1vQXsLbGxpqoEayNdCz9P6XioYnW3Ur17EP+r5fSVYy6zv 7Oy711Hs2RH6uacII/Sj3hm+hx3DlS/KfKz/Fu49S2nzklGqI9zf9pE+e3VS2rXwdERpnfBYnV4Z p20j/bZk5l72HUQi50CiSTa9TBJIND1BD6iepjtlN9AFKs4kwNeNe3o34n0ScT2J6J1M9E4mWouO R72jT+TMSYIrCZ5eimT45f9S77UJbfm7a8+9tE64einEnl7Gtklpc45u2CA2deUU6ar2xWJrPDxd gdjfXfl7qhahuoEu1MfxFANvNOgAoozVJaW1J5mxJgKpE55kTi55lvoU8iVL2/fOMs4UdKbo3IQZ K58InURdIvMl85Dkn7P/zYcj3FAT4YYZKR+VD0cqTwhoZ8KhIxUhWie0tT/CDec5TOvCFWEq49V7 bUJbvWG+Z+GRtjBFuNYJnak3hOdQrbP6Pb1S77UJnfWcCXpM5MeQP3cHieYLZvgL7toLnDTzpZNu FnH3XuwMNl85Q83XznDzrfOB+Z57+Q/OJ2Yp9/RlzgSzwskwK52pZrUzw6xx5ph1zmdmvfOF2egs NJucr81W5zuz3VlCudRscZaZzc4KsIq2NWADfBvBJuq2wLcZbDXbnO1gBzI7wS7on81OsAt6N3W/ 0PYbPHvB7842s09/4+gg9/lD3O0PmaPOYXPYOWoOOMfNn84J84dzGt6z4CL03/BfAVdpu2b+cm6Y /c5Nc9C5ZY44t80xcMK5Yy6Dq9DXwU3absNzD977znXzAPmH6HHN39zvr5gnzDXu4ddNXnOTO/hN 7t+3uXvf4d59lzv3fe7Y/3B/fkD+9y/5nuPWNMZ9xrhuXfOY+wJ42WRzXwUNzOPczgS53LdMQVBO b2xvmBrc4OS73F8EL3Ojq8/zq9S/Rvtr8DVwG5uGbhPQ1DQCb0C/5b5tmlDfDIRCh4Pu0CnIpnDL THafBtWhLzgp7hmntxsHujgJbjens9vdCQet3R5OY/Aq9PNuglOTturwVHM7OQGgnBvtlHU7O6Xd GKeEG+sUAyXceKcUKON2pb0H6OmUd5MUZdwUyj6gL/V9kU0D/aD7U6YryrgDQDo6+jslaSsJTwl4 SyInKOWmgt7QvalPcYqDYm6yUxT9Rd1EnhNp60VbL+ie1PV0CmFHQcZQEPsLgSKMpSgoTl1Jnktg azFQlLEVxvZCoABjyc/Y8jHGXIw1u9vRcd0OzgMT6dw1EfhCOH4Q5lww7UCIcw6cNaHOGZ5PUX8S nhPwHjftQZRzzHTCN6Od/SbG+cPEOb+aLs5u0835yXTH53uyBxKd9SbZWW16s0dS2TN9nW9NP+cr k+58aQY6880g9tdQZ7p5lz03whln3mcffuR8yHkznJx1sPkEfOwM4nmQ+ZC695yP4B1thrBP32GP pjuzTZrzuemDzhTnB/pbaXrQZzf2Xjz7qjM2dXT2Ye8hxnaYcRw1bbE7mHG0ZEzNGVsTxtmY8b7B XmroXCJX+ptz+G/zAnRd6mszB8/AV5PxV0euCjqqsDcro7cy+iuxh4MYbyAIYN8GUBdAXUXop4gF 5Z215BwbyDE2QW8Fe8g9fgW/U/8b9YJd0DvAVvKYzeQpPxLz15O7rAUroL8HX5HDLKBtHjwz4Z2C 3Hj6GEN/H5NnvIeNw7B1MPnFAOzvR37Rj7wijfGkkS/2ge5NHprEGHsw1m6MOZ6xd2YOuDVz9rci 72zB+d6KM70luVxLcrVW8Ld2+jJnA00b9LclZrZlnUKcT8Fo/GMsGMf8TsQ3JjLXk0wsiGdNu4Oe 0GmgP20D4RuM3DBi7nD0vM+afuQMYX3fYb37c0fpA3pyB+nGvaQ795Oe3CkSuVMkcz9K5U7U10xl TNOJ5TPBLGRm8TyTtpnwzkBuJpiF3XPAXOi5jHEOY5lN7jmTsc4gT53B+KYz1unk4nMUEfB1NPPg +Yy8Vs6PR/178ZfM5QL6886W7ma+IhGZFCD1aaCfET77blXOm6/w4cXM4UJs/tLHs4AxLKRuEWu2 GJ7FzK8tRcZ+X812zprt+PdW9s9m/EDOog2cSes5m9ayB9ZwVq1iP6xgnpfjE8vwiSWs0ffsl++c 9803zPNXfr0jeP6A+pG0fwLfWM6+CchlID8VPTM5++agdz5n3wLzo7NIz70tnHvb2MPbsEPs2QG9 3UfbfG8T/r4JP9+E/27GfzdzJm5h/29hX251liuvyG9BdjNn5yZ8W87Njc46sIG+RH6j/zNpm9kL nr6N2ibn6kat2wK2omOrvxRe+1kp79zdpHXSth3+bf7zeJOW9v6wQ89jwU7qfwLbGds24PFvU9mt 2L8N7MD2nUD4d8Mj2OMrd/k/e/Y7/Hvh/xVde5D5GZld4Cd4dih2c/7vpv5n2nfC9xPn/w5kdnD+ Sw6w1Z8L/an5wFatk7Z94A8g9X9SJ21CW/7zxLrzzgGtE75zvmepv/gf2q7Z75pHnNPc4jCx8Rjx 7SSx8ozyevyniXcnNA85ZA45R8gvjqH/OPacwu6zRnTYse8nn/iLPORPzpI/ncvYcIn2C8rzm+K8 5i17tf4yuALPVcZxHX7JXa7772H3oO+j6y7lbdpu6m9I3SKPuUU+I3mN5DeS59zCrpuMwZP39Nwi B7rNmO7Acwfeu4z/ruZB18Et2u7Acw+5f+D/BzlbSr/WPwqYG+RBN8iHrpEXXSU/ukyedIl86RK8 l5VXZP5lHI62XTbZ4MtB/pRLZW+RQwlu+PfzW5oTSX4keZLkS5I3Sf7kus+SS9Ukp6pmHmp+FUCu VYGcq6y5Z0qRgxUjFyvs0yd6C2vdXXKze+RmwvsAmX+RfWiqqi6X3OwxX26Wjb4ep8/H6Ts7NmQn 53rcfUuRTW0S2q5lQ1OP9jrU16A+iFyrHJA8LpfyvaHIRXtBUE7f1DeCt6H+3tOLrshbv2ysOd3r 1L2s9dL+unkJO+qDV9DX0BUeG2ebmTfd5uR9zTQPbKBtHk8jnqXetr/p2ndtTTQnlNywGTxNyBsb a7vwv03+2Ni8rfnjW6YlaKt5ZGNkmgKRtfFDcsom5JZS11jRHf4UymTQW3NOG6MK8FwFVNd2j6cR eN0kkY8mUZ/sFgYFaBNeOx85eX4S5KSugCLFzQ9fTpDLVwqP5R/jpLrXwW1y2uzw51TZZPe+k0xd ijtGkernj+U5jucxCqFTyAF7u1IfS520CZ35Od5a5I01NS+WPDmBfLkreXM8+XOsT7ar0516L5fu AU9Pcume5NI9VEZy6VquvTtLLt0RRDkVKCW3DkJPVfRUQ08N5RWZBM2/pb4yOXcQ+Wkg+WlF+CtQ lqMs71pdUtr3bpKbx4DO5LrR5M+dyLGFtzM5dwz5u+TtceTDMcDL44sov9DWX7rD2w2dXZDtgoyX 53t5f4zKCl0SlEZXGdqEtzx2C8r6fTVR7wRyNyir9dLeA/RkDIkgGTqZduHz3/3Rl6gop23ec1lf WULbhM7kL8f9oPx/+CrwXEHLFOcpH13Otf9G1xe+PvD18emX9j4gDTrNVy88cvcQPqGt//dnvP15 7qf3mTKup6scd5hy7kBoabf+n6Z3GrnblNL6gXrfKQWv3HFK6F0njbn06JL+8fSBty98aYqS2t4H pOqdyGuT0sbhJHQk0Z6sdyO5I8ldSe5MpZVP5FKp6017b+49yax3ImUvnuXeZEvR439/hFwyckna LiilfXj1ZbRNaPs5ggTuUQncp7rr/aswkLuY3Mk8Pk+2hN7ZemnfwlcA/gL4WUH8vpCv9GjRZ/05 AR3dFXKPK6JtXRVFkCkGirseTwlfWVr5hbZ7Lpq7XQx9xaHfu/MVxl/lDlhc74RW3tNXBN3SXlDv hnEqmxfI/VAgd8X8Stu/WQnj3Ja7YRhnXTjnZgTnaXvnX+6CLvszB/svl+vZkA9ZobNT5xIDHsB3 h/vBDWREVnSc1zKcMkxx0f/vTW3JE9rq/fM8uMD94qK2C187xTnqzvrup+eM5ZfSxrMO5CgdyGXk vhoO5P4aSr4S4pwGZ5Q31KcnkntdBxAFX0e923ql6LD/fjWAfLg/99Y0ZzH3zW+50y7hzrncJJHf 9iLX7UF+mkAu1pVcLp68LpY7XmfuxZ2cv9B1SHWJzk7kVp25M8dyf4zn7teVPDCBHLAH+VovctMk 8uAUcuJUcuM+5Mtp5N39yfkHkPMP5K4rdtg9Iffjkc673I3lLvUxd6qx3K0mcT+exv14tvKKzGDy +WHcs4eT47/HHewD8v6R3LM/5l4w2nfPtnviY+hRwKt/R+9mI/UOLqVHC4/9m/L2jKeT86eJYbxy 504gX+7JfCSR8/cm1++L7f24qwzAhkHYNZR74HDuje9zN/mI/j/WMQzCpnfNCGwaxv1wMPeRgdxF +vvu96nMeTJ34F7MSXfuCl3Jy+OY52jnF9ZqH+t3CBw0Yov9O7pnWde6+Izc4+uRp70GGnKvf4Pn xtQ3xY+aw9MKfwjGN0JYm3asUQT5regRfeHoDeVZ3hm0pr0lfM3gb4LcW8i/gW82QNdr6HwJvAj9 HPV18K9n/5MTV9b3BYdNFfRURU819NTAF2uh62n4hNeTkedTtAmP8B4FInvQf5cMwk/kXUMQ94hK +v5hn7YLXxXoKlq/FWzxlyJj/30gkDtBIM9SJ22BoKLq3O73gYroDVRs1zb77JX7/LQ9RyuwJuVB BfbAU8q/yy8j70ICtG4j7WvhW6NlBUqPXue/71Xg/vMUqKDvSTaacuwFT/cafYdSlv1RjrZyyrPD /zmYCuyzp5zfwS6tL6fYg9yvQNr2GuEJYC8Kn9D+X1KER97DVPDxldPnvUbqS/vahM7k/83H4/GV A+W1TkqPFh7772rFGWtxxlAS+0vp3XazKcN8eO97flP+8tjt2bxVx1iG+3MpZEowbnkHVMynQ3TZ vV+We34ZZzL6ZsI7D/0L4P0KfA/fCuUV2ZLQpagrRVtpeMrAWxaZcs4U+p1gRI+19QUnTd8dPc1+ rOEMo68R+MiHzNso5me08oqMvHMKJIZUZg/XYt8+yx5+welvRP55RT+l7bq+5PRlf/Rhf6RpvfC+ COS9VH3a6tNmS+H1/+Kfk6LvrF7ytwmdaqT+Reh6ihT/5/xaOWHs0TD2aCR7NIo92pk9Gsce7WZe dXqgI1H5RYe8B2vkJBAv4s3bTgzxoJPv3VeEsXqktP920Vrfj4Vpe0vo1gqPR2h7dsm7s1boaam6 2us7NWlvqYigj0jijrR3BFHG8rf6z7/dhxDLQ/Qdm7xrG2raOAOJUX3QkwRfgu/9XBS6YkECtNT3 pV34hsH/ARD5j/3nYSTrFgHCWcMw0I5zoB3rGKrv8D5VXpFpy3MI9SG0h8LfjngdzpkSAUSH/7tM qe/Pc5q+85toPP2ToDM4DzI44yabRJAMnQb605au7wG9UuQzzzH5O7KBnGNDOJ/eNe8673NOjOS8 +IRzY6zyisw72D0E+4bhjyMY4wf450fMj7wjHu2kG9Fj4+RYpyt13cynTk/QR9uEZwz0GOrG0ibt wjfG6eKn7d8NTIdf3jNOw0enIDMZX8twks0kfGgCvjSOebd9jHW689yL+kQzEf+ahH9NZj2msA+m sZ+mA1uKXptnz4Seqe8v+xuvvwHQA8xs+p3tq7fjkXeb0+lzhr7nTNU24ZkFPYs6ee85Q9uFr6uP t5tf3nsX2tXMUT6PdyaYhe1zwTzoebTPo+0zLbvq+9PM/uX9aQx9xqGji7Z5/PHQsdR1pj0affKO 1eOV0u6L6U475iDM9961k7bNUplOoAPPkUDaw43Ha/nb+ffgXH1PG4YN7bReeGcrpD7CH2+897Jd GEcM9nXUNuGZo3SM2j2fNZR3t1/43/VmfkeyPdemm3Azw0SY6SbdTDUDzEjwAXQa6G36mFSTCDpB hZt+IN2EmffAh9Aim/Udsn/d0TlTdYeZacrLnGidVy+l5Z1BnzPQPFPtiIA/nbK/kfqZ0FLae+gn ZqAZC8abd0wGmAI9DQiPyEyF/xPFQP/e60tbGkjn/0PAu9AjdJwDlU/4ZcwjkB8C3mGk6ZRpQCgr L6WN2ynMSG9qpE54UnWu+hqpT6Hs7aOtb/VhHlIZt8xlb9MFJGq7yPSB7kN9X9r7Mn7LK6Udg8zj cDDMtMO+droO0i78/UA6/O+BD6HHgQnMd4Z/Pr11mA6kzPoZy4L69zjyixNdzVMgwCSA7ibQ9AA9 TZDpRZkIelOfCk9vU5r6krQXg68I/AVBAZ7zwZvXJJk8jC43vLmZuVzMYy7mOY9+U/YIUxRLizPj pcxHpgweVxwUhS4ECjCCfLTlMe8j8555Av7sjDwbq2YY/UNi4QNi6D3O4zvgFvRNzoMb5Nk3nPfM dWLmdc7sa8T6q8T8a8T5a8TUq8TXK8ToK+QEl8nR/8ZD/yb3vuLMpW0+Or5E1yJ0fm3uch+5R17/ wFlm/iW3+NdZRb+rjWPWGtesw6Z1JqdZz9g2MNYNJr/5kfFvNIVBQbMN+7fSthmeTSYHbdngMfD/ S35zn3zlDrhJ3nMRnIM+Tf0Jcqdj0Efo5xB9HuBe9Bc2/Mk97A9s2ottv5Pb7HM+o242bdPNfs6L g4zvEOfIEc6JY8zHCWLmKeL4GWL1ReLXZWLENeLZTeLXHWLRfeLXA+LRA+KEY6KwP4o578jcd2Qd O7Ge0aaE6czaxLI2caYcvip+kXWf23yqEusdpD7Sw+cvCfiHyAi6QQsSTEX8pCLtAfAG+P2ppxH5 Sirv0Xa/VMS7A0AQvhYEbyWVEdlEkIKuVPVFj6+v8gptz+5C6pfdGU8PxtOT8fTCHssvPpzCcxLj 6+Xz5e74YQIy3VjDbkbkbV6Rmz2eG//NjR/nwZ/zIJ8Xu/Ihnx97CiAv/CKXFzoPdbnRnws+8f2c KjvAn8OVMaNMWXy9FL5eAj8vio8XxsfzmkHK5/HLN5IP1/1SBJ7i8JZEpjSyZXTfjDLlfXqEtn+3 I3viHnviH/bJQ/aFYd88hp7H0ZOD/ZQTXbnZX/nQV0D3nOw92YOjVI/olr1YWNuF733G8x7jGIHf D2cvvos/D2MfDMV/huBHg/GpQeY2uOMvB/tzjKtEbNmH19mPN/DTG+TaN9mnN9mvt7DvNnYKv8jd pLzB83XarsNzjb18jb18lVzoCnquoMeWote+E7rszMLPZ4OZtE0HU2nPQHYiesaDMcrvyQk9HnoC mITMFOLANHMJ2Uvc3y+hR0rRadfrPneL++zFe+zFu+zF2+zFW8SLG9zbJX4Ir8hIHLnmfEH9Qsay GL5vGNt3yCxBdom/FH3Wt7JpTFnLXK5mvVYCiTdLWT+Pz+OX5+XM9QqwivY1GoskpmRTrPXPRRFi UBGNRz+yfhtYP4lT61l3iVtrlVdkntC6Db4Y9iN+LLFrE+u+CZ8QHRvxgx9Vl9D23CtgttO+XeuE rwDxTmKe1Bc0O7RNaPvuROLaSXDaWU+sW0dMktgnMVBi4TrGsp5xbMCmH/GtjeZJ4mZuswW7rc5t 2LYFH9yEvRvx4Q1qvzEiuxYda9C1Bp2r0b2aPtbQ11ri4Hr6Xa9x9QR3zZNabvjP30stIqYuJqZ+ TUz9jni6hHi6jHi6UmPwUV9MFh3H0XmYuT/IOuz3xeR93DV/R8dvPj2iz+Yof+KD+/CjP4jVe/EH L3Yvom4Bsp/R12z0zDDCZ8/30+S3J4nbx/Vv2uRv3OTv0UZyDozROP+nxvsZPE8i3o+hfSR8I+Af jFx/xpxqzhLzT+vnh713mTbO36O8rX+nF4OPxuKv8cxVV+YqQflF7jy54iWer1B/jXbvvIhhfjsz z9Ggo5YP0SW06LY+8Q/3tH+0L9sWpfQ/+veAHbVNaOsTFXxnSnkTT/yKJabFENs6E4M64VdyFsmZ JGdTB/yhA2venvjVgX3Sgf6jVJfod+DNAZ6ENzdlXpAfHQVVTzSxvzPxNUbPstLal/TZTc8lW4ot WT+PWtLVdURbHJrkk5Hd6KE7vfcCfaHTqR+E9qFoHoHmD+AaBdcoTpCPKUfzPJ76SWiYCs8syrk8 f07bl2j6AsyH9zOe54JZ0DOom8npMYteZnOCzDXJZh6nyHxOms/BIuhvqPuetqVgJXyrwFpk1qFj HSNZT1/rGfkGsr8NZHo/mhD2TDB7pxVoyd5qDpqxn5qQozQCDdhfr4L60C+BF2l7HjwHXx39doCN 5mn01ATV0RkEAukrAFSk7/KgnFnDubGGOV5NuZL5XsFaLiN+LGUtl7AmP7A+33CGfIUPTgdTiZ/T 8K/prOVsfGYOazmXPf0ZZ9V81vpzYsEXxKgFrO2XyC1k/y9kfRcRFxaCL6EXUP85PJ/BPw/fmI1v zMLPM4izU9A7Fb3T0DmDeDELP5mDrnnYMR9d89ExD8xFj2AO9BzfL3XM0V/tyEPWnJO1y2Emoz8D /RPRNxa9Y/Dp0eyp0fTzKWP4mD5HQX9C/af45WjsGEO/4xjLeGQnMJaJ2DkJfZPpfwr9TWVOptHX dOLtDOZpFpiGz06hbjL9T6Y9A5sy4J2ELZMY60QwAT3j0TeWMUkfn9LXJ/T9AX1/iG0fYuNHzOVI 2j6m/0/o/1P4RyM3Bvnx6JqA3onon0RfGfQ/mX4zwETo8dgxkX0zkX2TwZ7MYC0ngQnQ41nTcbSP hXcM6zoGO0ej51PKT3keTU41Gr8Yo78UUxm+ashVR74GfdRizE8rpplnGPczjPtZUBu6NnV1aavL +OvQZx1kqmJ/JfZTILlIRXKR8uQhZdlrpclBSpB/FGPvFSBXKkA+V5CdUZgdUZR8rAQ7pIzcu8jT grgpVWafViOXqkGuUguZZ5CtQw7zHHgBXS+B+uhtCpqR5zQHLeirJWUrRZppjf5gdlobdlkouzic nd8BRBFbOiriHvndEFHIRZGDdtJPSneljOU5Tj9tHaWflu7OXu0JevlLkbH5UxfWUuJKF2JMHLbG MI5oxtWRGBSlsaiXT1Y+Me3Fpo6MOZqxxjCmOOauC/Jdmc8uqudjHz3Sf15115g1Uuu6Ki34RMvu Colro5S2dnVj/yWALuylePZNHD4czzp2Yf264SsJ+EJ3n66u0F3wnTjWNZZ1joE3VmUkHi6Ed+F/ ygX+MzEB3+gGusLflX3ZjT3bjf2eoLHzC+PZsJDZXQDm0988nueAmbTNNFZeSmt3KrypyEpMTUGX xNgkZBLpoycyPfBJT07kZ/E8m/o5Go+TlH8+cl+ABVpafVJmfoZ9GW0/0Mc31C/SNk9mEfLfoMeL 4cJn3x11I253BxLLE4mlEt+TzHLlEd5e0L2o60nM70l7D+JuN8V6/7vtYGJ2GxBC3A4jbkcSs6OA nAddgPCKTBf6iAXRPEeCMNpC4AvWs8LTIaWdszc4HxqBt8jHGlM2Ac04K5pzTrQErXz8It8KtKT/ 5qApdU1obwze8p03b2i5xUdv8/9blpwrlfWMkbNGzpyNxIdNxIbNxAU5k+RskjNKzio5s7Zzdm03 nm1bfefXFng2s683s783sc9Fx4/s+Q3s/Q3oXk8sWE8/64gN64kv6/U8C4JHSjuPpfQcW0u8kfNt HXFNzrv1xCKP35OTurXEpjXwrOEMXA2/yK0Cq43oKE29lDZPKk1baT0fVytPWZ7LclZKWY56oYXH 5vI5zdecGV8Rt78lbn9PrF1CrFtK/F1GLF5OTF6p/CJXiufitBWFpxC+VwD+vMjlUvnF/lJ02vdu 1zl/r5NTSp20ydl8k2dbL6W1/SZn6nXO1Os+npvQNzhfpf6GM1nbhLY5Xl49p71zOxfndU72wBPs gezsu8fZQ4+xlx5y9j/gzL7P3esOum75dHh6p3OuzuBsm8lZO0vzhAfctR468zjf5nMez+cMFH0L OKO/5GyXfhZxvi5i3Ivpe/F/yoX+MeeFNw8yeTWHWKjt+SnzU5cPfVJv8+c75Nq3GNtd7LqPLf9i h0sskHzjCfrP5eMXOckrJL/ITpx4jJjhED8eMI57jEf03EaPlNe5d97y0XadcyGbW/Oemeifzhin Mt4pyGb4ZT0bpmHDdM72mdqH9PUk8yh5UG6QS/GFj57vf1ecF5682JaHMrfyz1eevCA/z/lps6Xw 2n9zzEsfeTQ/8uo9vrmaK+WjzcudZqNrjo9vtl+2AHX5lcfjk1xL5AuCQrQVol7Kwj5a+O3+e8gc uZwV2ThLcpAT5ORcyc285GXc3q/reTIF9Xk6fU9lTFNYkwzmcBJzM4H5H888jTcP//PvOXe4M90i X7tLjnafHE3ahMfhbJLcTvK3u5pPfcy8j2LepRyJL36kckLb74IoSt/FQBH6L4R9BbAhHzbkIdfJ hR1PYkcO7Hgc/Y+h35APOeRFkh+KnttqxyeaT0rfYoMLfzZyr+zIylhyoi83evOiX8ZZkLOpMH1K vlhMc0YpZ/vomf69WhC5wsgVQa6o5pczlaeY1k3G3gwjPPbfAHLSZ27q8mjOKbmn5KBTlEd4CwDJ F/OBvPDmUf4Jmo+KrPXjO+ShdzQH/ZTxjmbcYxnLOMbi8Qn/kzxnZx6y0e6SYzjkBw+Yj/vM8T3k 7yEvem77dAltx3XPeZ/n97VO+IT/rpbvU76nbULb72EspPmtjHUSY5iI/ROwfTy2j8OesZoTP44N j2GDS34jebPkzw80n/7Ap1f0f8Q6faR2PsQvjPJ/qmOQseRAl4wrN31Ivp5f50zmWdZhiq+c6qMz /O84iyBTCJsKa+6dYTx7p7Bek8EE1mo8z1KOYwxjlVdo++6opObmk8h5JxH7J4IJrLHH48lN1Hy+ qLZP5ryYzHmRASb5S9Fh1y8/c5GPMRXQ/F7y/LHIjkN2PHwTldeTnUCfY+lrDDyjNfeXO4CVlzIX 82lp+86lBn3WxIYa6KpEW0VQAbmSoDh8Vl70FUX3UyCAfoL0LjGJ83sKslP8peizc/Gs3iOm++4W UznvJ2t7Deia+jwNSNtMcoKZ5AYzyCum+0qPFh32nKiDjDzXVb1CT9NS9Aot7dYvpb6Or87jE73T fXebGT56qn/da2NXbcZTG1119M4z1Xg6ppO3TANT6DcDTASTtBSZRipfnnUawFwNZI2HME9DWYt3 8YMR5BTvkYt8wLx9yLyN1PtTLdbuGdartk/fM8xlTea3Km2V4AmCtyIyFZD17lfvsh7D0Cu/hjmQ dU3Xe5btU0ob4+XOVUjff6dQ30fbhLeg6Qf60NYbG5OM5ZPS5ruV9BdA07G1H32mMIYk/MnjEZmi ZMrFqS/NnaYcPBXhD9JfEx3ozxmb+e5tb+sdTu5ycqeTu53c8YaxFkMZ/xB8YDD+M8hU4d5Uyaen MnVVaauuPMOYl3eZo+HIDkfHCFMP1GdOGoBG3AffBk2hm+k9cbjvvjjCH0O9++IIct8R3B/lHum1 i0xTZJuDFsxzS8rWivf8pchaPw4nKw/hZhSs39HRC6TQnqY8whuMvcGMoTV1wbS1gactNxW5l0Zw swpXRPvnWe6b0foeK5Z7odxZBdHKI7wiE0lbe9ABOsp3P+30//n3tZ1NhBtnpHz039cKTzTAHuhI RbTWCZ35d7DxPMdpXbhC9MYar95rEzrz72u9Z+GRtjBFvNYJnak3mufOWmf1iy1evdcmdNYx2r9f aO8MMlHOYBPtDDGxzjDTxXnXJDjDTU9nhOkH0qEHgkHUD6F9KBhC/WDOjEGcGQM5KwZwxvdxxpne IIUzPgn0gu4IOkC35+yPIB8Ig7cdsiH0FeIMMG2dPiDBtHHiKLtR1wOkwZNuwp2BRmx71HfipaIn We0cjr3vYvcwE+cMZRyD6XcQsu+YSOgo+oqmPlZ5hHcEMu+ZVMUI/91vmI5tKOMaat6BHgh/OuiH TB8gvCLTh3GnUfYHA6gbCAbRPgTeYb45El3vokf0CW3PnT7OeNMX9GNO+jMfA8mL3uGcHcyZO0Q/ JzNC+UXHYJ3z92j/EDtGIfMpsqOxYSw2CDxdUtpzJ5z2SNo66NyPN51BLLlfPOjq4xXZ3iCFNUkC vaA7gijo9siHK2S9xihtbW/rxJpg1qmNrpes2wBdx1BsbMe6en2L7Ees8wjqpU14+oAE+ONUXvS0 dqL8tM1ZZb3C4Ze1D8UHQp0knz90NZl9d4PuAVLVT0LhDfOts8hn/Rtya3tdJ9nUcnqZGk6iqeL0 NpWQrwjK8lyW+jLoLKvfiy3fw96Ntm4mkH4rOV3gjzdV6buGfk9JN+ajO/emRCM6H/WZkFq011Se FPMc46jl9OS553/KRH8cDHDk33L7qE1VQFXsq46cp6On2lwdVEVPFeorg0rwBIIA+AOB6LB3itLY Vxq5MjouGV+yqeAbr/AFKp1CXTLjTQKJppxvHsoyD2WQtTqktL5VjTmoyjpUpgxiTgJAReakgn6u KEHnT/hFvhx6KkA/pd8FL3PZDZu7Yn8XY/VImbk+3jzVxY46yD+L/DPIynzXRKY6fXlyUnblWerl u2N6mdrI1WEsnrz3WUJLZ/UH+96qvP49Zz9sHWBKEWeK4z/FiBnF6b+M+gVnMRC+rGts39mJTAlQ ErlSoCy6yuOPFZz+IA15gfSRzrykw/uO9lFC+5HPaA9ReaHt9ygX9bV5PO+AQcar82K92FcMeHWi S76vKsl49b20rbj6imej2FFBx9IH+wSp2JKCvUk+WU++BPNXgvqyvnkpp3JprF9fla/gn4fMueyk fdR06qC3Nu3PMu5azGVN/bwpeQjjq0ocq0QsCCRGBHDPqEgsq0B8KEc8KwNKE/9KETNKEn9KEJuK EaeKOpNMEYc7hTPVFHS401BXiHhWmHhUBP6iyBVDRzHiZXF0lyTmliLOlqHPcvRdARsqshaBIEi/ C172Rip29cbfUrCztxGbs66rjUPV0FcdfU8z/8+gozY66jC+ujrOVOT7Ut+P9nTG+Q685FeMtYp+ xnao8eS9vViWc7E8qIi9gYw9CJurENeFR3grUwbxLPNTkban4Cmv8zOS8Yxkfkb5S9Fl9RZkbgqD YsxPcWci4x8Hzxh4P1U+4S/FXJVkbkswt8Vpl7kt6ExROZEv5Ez30/YMLIodRem/CPKFkS+EfEFk CyBbQNfC67cQdCHqCrNmRei3KP0WQ6Y4ssXRIWsjuoqoPo/OjHfpjDed8aYz1gHYKntI9sIw5IYr r8hXYG4rspaBIEjXU0qPFh2ZsaMPa5PK2sh3qCazzinMb2+NpZVYN/EB4Re5KqxbVdbP84dU+Hsz 9lRTx7e2Vlddv39k+rv9zH0yuWkS6EEu3YO8ujv5dXfybKnP6lN2XnuQjyfAk6C8IiOy75qe5M29 VN/7yAtGQI/gZjCc+mG0DwVD4B1srA4pu3BXsHTm98+8T5Y8ws9n9UmZ6msTOuu4rE/9jG/8zNru wi92ObPMNugt7MVNrPGP+MF61nct/rmGPbdCfztzqFkH/SP7ehNtW/X3NceZn5ARXY/6jq2d6P5Z Md3sdqaBKfQnmGp28rzTmYGOmTzPNMK7y5mt/ELbuLYaH1mDLevw9Q3430Zs3IxPbkXHduQ9uZno mc7zFOon0T4OvtHwj0LuA8YywogeO38riR3LGZfUSZs8yzilXIrvLPfRdr7E7p3svR3o3Yr/b2af bkTvenx4Df5s5Vfj16JvA/bKPG3Bhm3YuwObdul8T9E5yLoug7Qf+ST9SG6FH3ODHM2qjscTJrKS 0/CaGeYjM4fb7We0zjefmgVmnFkMlsO1EeyC/tOMMX/Rth+eA2g6yC34EF5wGB1H8MAjeNhRdB7D a45xoz1u+oM0c4Jb7QlutSfxtKP0+yfe+Bt97uZmt4N+N6NnHVjK83fUf4W+L9E3H745eOwMZOTT qvIp1Snom4wPZuCDGfj2JHx0InsgA0zgeQz4BL//hP5GGhlvVt+x76nHM77xZhFjngfXHJ2H4egf hs6B6BnASPsz0jQs7APXADOWcU1gfJOwaTJ2zmTss+H4nN4W0Cr6PJ1S2jvuOOZsPGOewBxO0Llc ru1jFcuZ141gF/SfYJ/x+D0Zoe3dKkXn8BS2nMSmk9h2AptOMDfHsec4dh/D/qPYdZR5PILVhxnX Iew7yGofYET7VZ/0MRrdn0CPom4kbR/C8z68I5B5FwxFfjB63gED0NsfpNFHH9CbPlPpX+xJwh6x SWgbkz/QtdyMvh3o242u37BxH2t3APkjypuqYxAfOUh/e7F5DzKeL3yEvOjw/xYU8zwYHxjKGg3D J4bjGyPwkffxlQ/UZ9apzEfQH1L3Pm3vwTMc3ndZn6EqO91fij7rAz3VfybhM+JP4lfiX1P0E9ED 8IdBPn6RG0zdQNrS4UuDPxW5FJWdSFydoH7olZae5I8HCeqfk01Pn78maJlhEhRTtU1o6zOJrFov VqgXq5aAPmnroZhIf+PUz5NYRfH1RPxU+Hv6ZIS2esR3e4NkVjoJSJvwJ4FkeFN0n3wMRrFXRqmf i0xfIGXWz/jYO0l++s+PHTmQfRIdOUFu7MkD8mrbmEd+N1s+PLsAsvK+NJ9iHPxjjVc/QduEtvw5 sCmHvuMcr3xP0Kc8S302X5vQ1v8KaP+eLTnVvo+N1fEE434S5KQtl/KM9fU9Ru3x3sd673Kzjt2e ObnNLHTMNNn1MzLyWZmp5h7R5Da5kZT/EMcfEo9d/QyMfBZGPhMzw4hc1jmxPn6Hc+cWkeIuedB9 ZP8lZ3WQfQy/y05fTyKbW/9daZbqykF9Ntpd/PEhZ9U/yEnfVo+U1setXC6Vm4ZNU5DLQP8k80Dl xpn/9u/Zn8G4pmgf2elLxmv15NZ/d5rrp7OeNXaeijjfk399AxaQu80HM8nFppGbTSFHm045C8xl nedTvwAsUn6Re9TnpksiW4K5KYqewugrrHpF/zfQ0t/36PlG9RWlrSh9FKOvko68d5Z+BRmqQ2g7 R/+VLe4sBl/CMx+euWAW+e905S+u/Xu2F6etmPYhfS36v2worFjhp7POkf3t8WGcAe+ab4lVS4hp K8EWnncQb34m9v5KDPqdvbifWHOI/XqYvXuMfX6UeHDEdAPx1MXS1pk42on42hHeTsT1ziCWGN8D 9CL2poBU8wf7+3f29V5ygN+Icb+A3fTxE9hKbNtEvFsPVhDrloLviH1fgYXQn2PPPGSn61+WDMQf 3mHtB+EHg4mzg80X2LzQyHgedRcaxpiG09cI+nrP/AjW+sa8hPpvGfcidCxGh9BStxJs4XkHNuwy Im9z4ETOIZmLFOZA5iaNsfdnrAMZ4yDGNoSxCb/IDWaMMpfpOu59zMFfxLuDxMDDzM1R9Ag8fVJa n4iCLwq9neDtTB+x8MfTX1ed/6PM7TGf3FHW5Agx/DBrcph8WngPmhhko1mPjujpCC36OvAc5aPt WPphXz/sTWVtUrA/CciaxYLOjKkTiPLpEH2dQSzPPUAv2lJAKrx9kevP2NPRla46d3Mn8v7t5B3W dQB5Rjpzn84aSJvwDIQeSN07rP1gswGs95ciY8+RgeSFg1jjweoL30EvoX2F8ngyK5jrpeA71vAr 9YUh+Iz4h8jaWJ5G/Omr/vOZtok/pfEs9am+NqHtfhefGMZZPoS+h6ifzUVulv7lUrrKTlP5/vjj AK2frX46SHkXqO969ixW/7L7z+b+0c4cEw+6spe7KT6HXgAWmVj2c3sQ4XxtwkCI85VpQ2xoTVsw 8SHY+YLc7HMTjrzoyfpd+AnEhgRnHrqkj9mmM4imj1gQR308ZRdtFwjvfP/7y1jnW9q/of4rbFoE FtD+ufJ0VXyO7AKwEL7F4Ct0fm1iQKziW//9phXyYnMbeEJoa6djkrF9q3zC3x5E0B4GQtHXVse4 ECwyVl5Ke0+OZCwRIIyxtWMcIYyhNfPRmnlppbLS35dgAbq+oH0+fPPhn8d8zTWRyEUAT88s1SW0 fafmzdVs04m2Tr42j3+uzqFtlzLrv0VYn4+nvzj6jsWOGMYSjU2hlO2wKYz6COawPTxRoJPzGXyf GZF51Pe7RTMvseiI0zlfAD6Hnk/dF+j/ElukD8Fi/7+HhvAciozURSv9Jf0vNLZeSpu3iE90AlHY 0R5E6Hx9Dt8C5RO5cOhI+mtPfZT2PZ++56s/xQIp7V4T++J9bR6PZ2+8+s58bRM66/zZ3w7oS9zt Q3zoQxxNJVakkqP3Jo6mgGTiTCJlT9AduguII77GEMM6g07EolDQFjqY+mDaW6CjOfG4OTpboru1 2W7amG3wbTVhIIJYHwWiuQPEgS7EpB6gF3ErGaQQZ3qbNdixApuWsu+/J459zd5fCL5g/y8CPxAX VvC8hrYN8GwxMo5HfQd7Mrb1xrY+xMw+jK8vY+1rdiInY99BXz/p2Hvr2H/Bhl+IzzJ+wV7/Hgtm nG11zPsYu8TtP4jRfzCO3xnHXuUVmS4gjv5ieI4GnWhvB0Kg21AvemwMaEb/zbClOTY1x4YW9C3t Ht+vzN8e6naBnTqnzSlFpqnK/aS0/TffRM7bJNAL9GAuu4A45jYaRDHXESCMuQoBbViL1qxLC/l7 FHSI3pboC4ZuS10obWEgAr4oEI1MHOiCjh6gFzqTQYqum1dK//ZcTWet+ikWMs9fM9/fMcdLmd8V 8K5GZp3yi1xv1jyVtexDLtAXnn6seX/zDWu8yHh6FmjZn/NEdApt50/WsB929UdXOjoGoH8g/jHw /5IV+gd4VvC8Bns20M8WXfs0v99k3gFeU91lHfmcY2nsLAmKQxcCBZDPD/Iyhtwgl1lF3ryKnHsl OfQKcm75O6Svya2/Iff+ltz+O+qXcCdZCu8y8unl3ENWoGcl+laZIqAYekro5yHX6mcrs/qxtceo /pXk9ivpbxU6PRvyIJtPbRMbxVaxeT22r0ffOv37g0KgALz5QV5kc4Nc6HlSda3AxuXoXo69y430 Y6iXvoS2seYB58Y/jE3qhO9f37PU3yNuWdq+y7B9y2c9S9JvMfosquNeiS0rsHk5ti/DjqXYsQQ7 fmBs3+ucGebOMZ4+0fuvI8/fYRN5NrzZkXkC2ZzoyI2uvKpzFbpXM6fS1xrmdC1zus4/B1JW+A/9 qPeahZy15PPryfV/JPffxPi3cBfYxrm1gzvCTlPa2QV2E/+3w7PVFHI2m4LORlMA/iLOErBM7wWF ndVGdD3qnlNG9fyEzu3o3kofm+lvI3o3oGMd8mvQy5piS2F0F8WWYj5bSmBLSWwp5fwMdhnR5f8s rbOH591aV0oh9M/Gq/9F24T2f7aJ/vKjvwD6C2NHEewphl3FkS3p4y3j60f6lL6LYUNRbCmMzYWw uSA6CqLD6sqvz97776LMSWGQ38djn6W090gZa2HGWoQ5K6J3qmV+vsLOUvpYAVYh782JLUXOrl89 1VWKM3wZ5/AKztmVYI3pCF8Uc9iB/iNAGDaEgrbYHQxaQbcAzeFpTv8tkGuFfLCzHJ5lnMtLOZeX cC4vRX4Jupagd6mRfrLef9qjJ4o+OrF+0fQdjc2d0dUZXZ3gF5s60kdH2qLUrnXYtZ7zfj3nveBH /zuxZjw3Q5fY1kpt3YQ9m7B9I2PYiC0/Kr/IybhCQVueg5V/g2mpsqLD0yOlPcvCnB8Y0w+MbQn5 21JyumXwL4dnlfK1UKxGz0r0rUDvcvQvo1+Zi6XGyktpc2EZY2cdo8zRDz6epYx1qW/s3hxYPimz 5iXWh3/Cjp30v5N5+ol5+ol52q5YaXYgt4tSeLLuLWvLT4x3J/y7kN+lelbBvxqsUT2eTuHx+IS2 fW/TfjZonfBtBzuo26bYoG1CZ/a1jLrlats2+pC2HQqxcQX1K4zw7NDv8V2utO1rF3bt8rUL304d 9woj9T8jv8tHW/6dvnnZ5eP7yT+uVej36J3+ecmcV5sLRSHTAb0d4GvPXISDMMYXCkKgQyjbYntr xRpowUrqVxiRzTrf9nPUEci1V59eDcTHpZ/l1K0Eq/Dv1fjoal+51n9n9foVrMMWwVptF74w0M5n Q6jatspHr/3P9/Ksp2691nm2rsXutfislOv9OXor9eV1Whes7Wu09OrXaGnnuI3as1rrglWvNzdt dZ7WKy08ds931LlZht3LsH857ct1ztog38Y/r6uQXalzI/MiMh0pRa6jf14z18uO7zf2+y/gZ+Ly HnT9Qv+/4n+/ssel7VH/ZrYL/p+J0b8Qn39TbEResMnsVmw2wrMbSLlTv6d4m9J2HqS/3cDy/cL8 7QZe/WptE9r2Kf3sRfdvapvYaXnXIbsBbKRuk9ri8Vr+zf9zFn+lOkOcvOSl+ciN85MbFwXFyYVL kKeWJG8rRX5amty0LLlceXLSCuShAZSVeK5K/dOgNjzPkc++gEw98BL6Xgb10fMqel9D5+vk3K+R m79m/oQ+YBqYI+CUaWQugCumoblF201kbiB/A13X0Xkd3dfo45qpYa6aavBVNpdNEKho/saWS9h1 ERsvYO958pFz5CVnyU/OkqecYTynyVlOk7ucIv85Sf5zgvznOHnNMfKbo+Q5R8h3DpNHHiIHOkh+ 9Ze57ewzf3MOX+RsPsd6nGbuzjGXF8Fl5vweeAD9kHrDPDzGPGRnDp5g/DmZr9yMX+bzUT5TlPko xrxIWQDkgzcPyKv0Hur30C5rsJtyD+UepYXf//kR8vnyoBz9l6F/WaMS9F+cvouhS3hFpgT9lOS5 FHaVgaccdlbQNfTkpfR/Lxk8L4Ln4avjW9causZbWOvNrPkm5a+gtNRt1fWvAf/ToDb9P4f8C/Qn uqytDVj3BoyhvvqF+McObRe+F8FL2PgyqI/Nr4BXsftV+F9Tf9ljrLyU9v2B5zsH8CPxpb3aJryv Qr9K3WvmIPVH1MfsvDc0t/GzW+YNfOgN/KUh/iDtr/v8sKHWXYG+SSnw+KW0309ZHJ5S+FsZ/K48 /lcRPwxUn7yCb15lLsRXxWevm7rqw+LL4tM3scnT1VDpG4z1Om3X4bnGvF1D5iqyV01N1XXZVEF/ kPZxiTm/iJ9fYB+eZ03PGrHDft/GA3z3X+cwfnwEfz6KPx4jvz+On5/AJ0/ik6fwSdkHsh/O4HOy P2SfnMNPzqsu0VkUFKa9ILz5kckL8iCfCz1Pou8J9GZHfzbt4zC+f4g+pe8D5sF/vuv8NHvjNLHm LHFO9tEV51dz3dlr7jr7jWfrAXOffXaRWHie/XWGfXQGfpE7BX3aR9tz/4HuuQ3svQ3I/Mhe/FHb ReYc/BfBZZ7vgX+ghd++D86nce0nxrGDcWxnDNt0r2bDh1382cGfhV/kHqLP4NeP0f44fDmQyYls bt2bu3SPWn35/Ps75/+8K2uODzY1v5km5lfTGLyJXzbCpxuCBvh3Q2TfAo3R+TZ1zeARmUd9RuV1 +F5XWdGzB9/9BXlP99v00xTZZuZ3dPymurx+99Dvbnilv5+R3aV9i67XtNyttN37nvxe8Cs69qD/ J+R+Uh6Ra0T5JmgMLTY3wYam2p/t93fTin3X3GeLnRObt9QgptZgzWsSY2vhqzWdYzwfpf/D4JB+ r2Y1/KOa8u37n/e/NZ3jyB0DB5AVPfuQ+wP8Bf9B1VXTOWIsn5Q2F6uKTFX6qKY4gozXLvw1FJ4N 1eCrprYc8H3Xp0fbda2ptv0Ozx/U/6ltwl8du6vzXMNnk/DVohTemr6x/NdP7G+NVUQmQL/n84AR +lH/xivfBRqg35u5D76/4P+Tcp/vO0J/1zahLX8A+oJAoPKLrDzv95WHtU1oyy96n0JvJp/Xj9RX oK+nfHTWcdj5jSc2xBIbYkAnYkMUaE8sCidGhBKjw0AE8bg9sSKKuk60dYZHZEQ267jtfTnU7Dch yIbDH6l6Rf8xZI+rXDx0HPUxIBqeKNAe/RH0E0Z/7ZAPpRQ9bX26hLbvzqyOWNVxBB2HTUdkOyAT qXbvV37RIfpEb+YYjmKHyGbaImUv4mX8/zWuXP/zvuu+c574d4F4eAn8Tb5x2dxwrpmr4G/nujkB jkEfdq6ag7QdhG8//Puds+aAc8Ycck6bI85JeE6Yk/jxafz5HLjAHrgErkBfpf467bfgvYOM9Pmo O9wN+rtJf7fp777+3sIFcJ54eg5cVDvvgJvOFXReNcJvc/JDauc1c1TtvkEcvkHf15VHeK+Cv2k/ AY5BH0bHEUorJ6X1IxmbjPEv+vbGe0nHf8jHf0Tlvfk4iF0H4DmAjQd982Lv83+zpy+As8zFaf2d Dfm9jeM6Z4ecU8orMocpj/B8nPqTzNVpeM6BC/BfAqLnEpDS+uQ/unZnmZezzNcp5uSkuQbvFfrx +I8xB8d5PkH9SeZBeM7Ae5Z5PKfrLvMqev7R57NKZ/UVO5bOnM2dyRFiyBniyB1iQCdzBx+8jU/e xjdvmdagFXlDK87zlvhfa87tNpzjoZznYSCC+g6gI2e96HvU56bj0RuPrlj6iiU/idF+r0D/TXkR nGePXADX0XNTbYlDJg4Zke3Gc7yPtjGzldondoq9d7RN+MNAKDpag2C1X3BbeYXOlD9hWjCmljq2 q9oWrDqvgnM8n6T9lPH4jiuv0PbsjNExn2fsMgcyFzInMjdniAmn0XXSJ3sKfaeZt7PECeE5B+95 ZERW1uCijt3qk9KbR/d/PndNdHWPgRMm0D0HLkJfBbehH5ggt7Ub5LZ1A91QynAQ4dYAjaCbgUjo GMpYyjiQ4j4FyrrJrgH/miT0JLnXTbK7FCwzCSDGXW7auytMKOUrlPVBPegXQFnoAu5Kk83dZPK6 W6B/NiXcPaa0+ytte005l9PEFZsfdV+5SPsFcA4eTlX3CPQhwEmBXCDPgYw3yD0PLup4PX4prY43 GK/ryvi9ubio7YHQQYwniPpKbh63klvIrcxYK7sVod9QBPp/AyECOtwNcJuDJtBvKCpRV8kN03kM BAHKI7SNUZHMZSRzGqFz24z/NgI1lCdM16AGaATdDERCC29n18pJad9vRLpdeJZ1idV64QujDKcu XNu6uJl//9Wb5xStC1ek6Hp69V6b0HavnzIpWJPiVqWuIXjLTXWDQSh0hCIFOpm6FNpS4EnGN5KZ ryT3SfC4m8icJrpn8Y9TiszfNVmq/pKiddK2FCzz+dAS6pYqkv38y/GlZfjUUnzL87NkfCkBxOBP 7fEn8bVQ/7wsx+eW4XtSJ20r1A9fdTPr6/t/x2MZfrnMvEhdPa0XvpWUK6lboW1eu5Q2Dqw0j9GW Df4C1JfVthWKssgVcFfRJu0en+unX1b50o7nqwHuPlNeff5XU8b9xZRyd5li7k+msLvR5HY3mCfd dSaHu9o87tr+VvG8hvr1JhftedhD+XQPbUWGzIo9EKh7YL8iyEd7e0ligv0uCpf6x0xlN5up6j5u aoCn3ewgm6ntGlPX/dd53r3vvOjeceq5N5yX3KvOy+4FcA76DDhF/RGnjnvIeRrUcA87VXmu5B5z gtwTTgDtFeF7yj3vVHD/Blec8u41ytvgLvX3wQN4HGwTW7L+2+3jppbak11tq4pdlbA3ANuC4K8M LXU1wNO0P6NlNsrHFbXczM8Xio5aWidt2RW1XKl/QvvwaHtXvOTUZ6z13ZuM9Q7jvM84Hzov0Odz yNd2rT5j6jBHz9H+AnwvMkf1kHvJvaSo7//9ksPM0RH4jjGfJ+CTeTut8yjzWV95ReYCOEfbGXAK vpPKL3J13aNObVf02Nh1hDk+zFwfYs4PMvcHnWe03eN7GtSgz6o8VwKVXcsvpf2Nrcd03gOY/4qM Q9ZD1kXWR9apPOtVjnUrz/qVx6YK2PSUrusxJ1D1iN7jlCd5Pk39WdbyPDy3wV3o++CBI/oDdc1s f4/543pmbmH/Hftfpwr81ZjvGthUC/ln0VOb+a3j3mIebjAfV8Fl5uYiOAd9hrZT8JxgDo4jc9yp CV0du6piVxXaK8NXifkNYjxBjCuQ8QWiizgP7tJ2HzyAT/p/1JnzgD7+xZ6HzK9javrsFJmqlNUo a6CjlvsPPP9gi+WX0uZqZ9Vmsf0FxvACY3keO55nbM9hR13sqKP8In8P2TvQt6i7QdtlcBG+c5Tn gdUlpd0zx7HjGOM/ho3H0XEC+VPIC4/IiKzM12mtl/ZaoCZzVd0V2RdUT0lHxvVA5yUIO4KwIxA7 ZM4CmEPOSujz4BxtZ+A7Bb/Mt+gQXaehzzKX56i/QPttcBf6PviHem/O2MPO//vf//vf/z//+z/D Px1PEAARENENAAAAJgAAeJztWHt4jVfWX3vvk4tc0GiFuMRH0E5QmUpdhsGXQdtchFQzTFoNiYqG EBmhUfIw1dCS0qbSoqRoi0HUJ8+oMePSKh2XdlCRVoVOH+WLjmrrdvZa+1vve85JQk8knZnvjz6P fZ519n7X3u/e67due+/34yN3VZZsCTsDt5RfgwIyjcC3Fk+4yS5NAaT7mYwxHra5U35WBZnITXex /XyYLJv7MfkzNWIKYApkCmIKZmrM1MTlAuB59075eZbhkMW/HGgHg2AS19kw49ZUcNvSnD3GM5eV Dzpx3rDKLlf34NpjV539shK2/EXYIxyenBLD60+EyTAUxsCEn7S2VUI4C9XG09D3prtryetmQjok MvJ0mArd7V/DSwuQwsqBFqaGrm9BT2zpagv3+lG8agKksgUyYBo/N7SE/Qv4LTvlK8/6rhhWbrl+ SvzfifuffxFsRRXg8t1bYzeM/+IzxmZnTc0al9MuJjNj8sDsnHZDUjMz07NnQDOrN2m0mz26Hvb3 vd+d4s0XF7EzmsoffIS4d2BmZruY1Jz0p7KyM9Kn3gcpKXH/HZUyIml4VMrDCUmPDoyLS0qJTxra u2fi8KEp1vyp2TkpiVm56dmTJ+Wk5GZl82tp3XInjnPNvEl1mXbhaEiDI+lfKfcuLJE/ZXzTW0H2 /jdB/tvFsrsn9oX7uam778UOAAUdOce3tPo4E6gXgqwscMzutTJFoNzrRKfVCpJz/Zv6WzO1tfND J98mnJut2Vx5BJ17ncGOwY4Ad1+A3edSXqibF2HzHGD53aMJiYl31/I+WwWJWRmTcgLdo4PsMa5s lgg3z+vy4xo5rJEOWw7hPsF6k74/t64yyjYu+O1WAbyUDwPyDZRO5qjIHwCVq/Lh0iUDxp1o891/ +e5Gvvth165dsOvzXfDWR5fAOC/BqlVrmJ0P9lvG0rKrYdwP1nyWBXpI104SXacOAx2DHFb7hvTx 2M9+syvvQlbO1tJzQndxJbhsYvU153cDHRbmm3UobR063COt97oJl4YCpEdXjapbQlprutYCtyZc aylwSVbjXS6+wysap/Nr9HOM9/3/8YiEn+wR3mU8j/6ODF+Pxt0RIl24fGprXHrQ+t6k8cGOIMf7 dWhc1K9xWa1xWUvj1Wv5VWvcbXW3ZP5wj3u9cLcGref47EFpTWpp8DfZqbkAo9wj19n9Elby8wqe bxL/Zspi0U+54Klqf/PUovaVUECaXQVB0oypOekT+RSBAuVlpvNCqrPCT30umqoKEda0egIrTDxh kQ+usLBDqQ6GFS52iNXYypLZ5XdxQpvkRnn+NTpVrIca/dXo1OrzY2+1aocItmtfjh+rltUR480f PGt4bMF5QVratXTeyG0LX9vyNbYIgBrbW9IKcPm4lcEjVBQ4TTAOg3RMhjfwCbiG05gK4RQug/VM o7EEFuDbsAY3wU7cx3Sa26fhOfwWkvEqTEclirG9WIBdxRSm5zCJ6zQxCEcyL0mswQliPU4RH2GR eB83Mu897tso/HG+OK4fFxv1YHFY3yu26XvE27oR1xdgo/4HHNblsENvh216GbypC7n9LPPT4G09 jOs4OM51he7PJLjtTVevSEtXDn9vfct91iqrz6NHzrHVegy07XCJ9eldb0/aeusGyTDN7IS/mSM8 40AxT0wQX4v5oqX8HxErvxJzJIpTMlS2Uk/KTmq1TFaH5Bx1Te5TyrFPHVRr+DdXzVdpKkv1Uo+o YNVR3ZAkr8uj0k+9Lz+TW+VGuVwukjkyWw6Rj8uuMlq2l8GyiawQP4it4hSveUQMEdtEiCgSVTBO 7IEeYg1cgAEQLsbBe2IJLBJpkCoi4F5xwZyDPaYQXjcezLy/1PIdF+bAOjA3tzE3gu2w2ZTDbvMt fGyU+CfPecWcgc5wmjPm3+Gy2Q/nzc15r+7cZtlH+q12eOThva3BNhhuy9MZKnEpGXRSDxpkXqLZ 5hsqNt9TGcuUBgd4DPutKYCpZg48aJbAMdoAS+kgjCMlhlCUaEmPi+M4TbzBvvkwFotLegr7Y5SY wr7XXc8BH90OzjsPmRPOHHPQ2cocdu6nL5z5dMUZQ2Fa40N6B87Vs/CozsTWmI2TcTFuxTI8jYex A3nD/F+qGUi/8cp7377b9M2VzzvGK+9xf3vbxdm6ioAqXEyP0CiaR4/ScZpIwWYpRZltTIeohTlJ 39AOKqXldI520/d0kqmKjjDtZCqlY7SWtlEe9y+kD6mYKpmquE3MIxrD7X50iKmSYugaE1EU122Z 35Z8TEtqY67jfaYKOzD5MFWSBwufaxpsdw+WCsbSk7HkMJa9jOU6LaVwxhLOWHwZy+eMZSXLepyx nGEsZ9w4/si0krG8zFie4v48xjKPZZ7HfAvHU0xDuR3JWCKZb2GIYl5broOYH8RYfBnLOcZSwVgq GEsFY/Hm87fPuueNwAEwEgfDEoxn24xjmg2f4ALOwgsgCRfDLFwKxbgCtmAZ0xFuH4EZeBZi8Rxk 4g/wIt4tZmG4SGeagYO5/q3ojbHMG8wZ+Qn26jHiL5xl/4QlzNvIfSVC6zxxQA8TJbqX2KNbinXa TyzTTlinP4MSfRz26AOwWa/n5wXwqp7N7UzmD4dlegDXfeAA14d1N6ZvzAHd0Ehfy15/ymf9TfuT ZfWb/beufaoFU0e+Io4m41xJTucZCtQhpo0eafrqV02sPmRitD/E6mhI0MnwuPY+S5g9SyDspy+d F+i6s70J1A+bUJ3LM602IbqK6zbQWT8MXfQzEKMLYIJXfA3PbrGih+O0rKtvlGpZfaLiE311BARU R7P33by+CAmx/cuPvak/PofzOSe9g9NxHy7Ak7gRj+B1zEdvp5cqeUK0Vr7VMvHN40cZJsCWpYXj E/wYl+Pr6C2CA+qRr70tXxMweB9ewXC8iK3wS86eJ7EDJmEeDsW5GI+FOIznH4mrcQy+hVlcaxyC ivqjgx7Ehtpgq0ywbeBth6nP69racgZDCE3A/bgJC/AaZmI0/R4zaDG+QDt451G0iobTdM4c0zmX ZNAmSuBM2cVr5h+vLFmibmvzunQWZssSCEMZfynl4l4qwoO0FffTSSyjKnyZLuPT9BU+Qvswikow kuZ4tfE76oI4oUIbZOOz+CJtxmSvWbqhNu5MkdidOmBvaosx1A7jqROW0zT8jJ7FL6gAK2gJfkKv M44VuJOW4S9oMEYwxvbU06uN/9M87yfsIzLXP8/rqTFOvKNy/Zt7PTXW509ptk66w0o+pWyAi6aP SBSp4hkxU2wRb4pvxF9Fa3mVT46hskBGyl3yfqnlWD4JFvEJ8qDso76TaSpQFakOqlz9kcrVQtqk 8qlA5VKceooaq550QgbRBVmJjVUZdlULMUNl4nYVgWtUD71dtdZLlJ8epHz0DzJUl8hf6RFyhm4m P9Bfiz/rZXwGTxHndVNxFx6FvrgF8rAI1uE83mn7wTHcYwy+YHrSDHNTVuIT5K1Zyzv6xnb29YHF eoKM11vlQ/qfXHdSo3Qv5e08WpPlvGfB+rTd3dZ2c2hEW2UE/VX2oIOyLR2TfeiUHEGX5VB6T+bR HFlME2UpjZXLmaZwezjNkyO5nUO/lK9SMNfh8hF6iN+bybSeaY+MpI3S+6pBNkoHfKD/V1SwXi/q k3zP+VTcXmd1RdFjNob7IJKumz7Uhve//jCXYqGMkuE0jYX2ZjJMMrPhXfMKfGHegrtgP0TDFb6X 9BVZUCBmwnFRACWiCH4v3oBosQouwTtQyvfsJ6AciuEiHLE/PgSJ+/kGESdGiT+IcBHD7RDxLY8q hVgohGaQymf7vkz+TIdMY3iNKds4TQ9TZU7TefM0XTa3i4j6drK6bOjBH0GbTQ86akbSFTOLBJRy fi2nMGhlOsN4Ew0bTCx8asbyrXkRdIEyGAbfwUTWwWwoFIUwQhRDe/Ea/APWwBtQAmNhE2toL0xm zit8T+ot0vj2tESUczTOFAPFaNbHfr5DPQkbWDkF8JH5HaOOZhJMH5oPzMtMT5stppt505TTSpNO 67zeebztOvXZ/JiNeTzsxstS0SLZmmJlP/pcDKcckU6+YgzthBR6BmbRJFhGo2Az9YVddA98SFcN n2zMp3TJfMXtG0SmmblhnOQLV6kVCBMJoeZ+iDLtYQBbq6c5bTqaPWy/YtPHvGvGm3NmprloFpqz jO+Aed6UMu8FE2UyzQVKNr8wI8wTJov7is1apm084l3uKzLxZqp5kH8tjK+5m2XowHewABNq/EyM CTCPmXDzrHnALGdaazqY1SbYFJpr9DtzjDqa3VRO79NLfB5P4dtHJL8XxCf3KtxAH+Aq3hPW0gLc QevwJO+212g3hpq/YYLZjVNNGRaZ1VhqXsdPmAy3u8NmHAErcA08hzf4fPxrMQLzRV/cINriSfGd Bvkn3UU+ryfLUfoA5x8/9SsdzZSqeulCrvepWH1dpeuWjlk60rFC93Ic1v0cV/QvHWEY7HgAP1N9 sUSNxXFqMT6gGrqbRPhuF+d9X6sjX3hu1eegPzURo+g3IoHyRDN6hW+lz/P5/bdiPnYVyzBYbEXv XwAbem8/AX1JiMeol4ilbBFCL4oTOEu8ifFiEbYTK9FAWYN3XG/fHGti2ao7C5e/165rZrK+P7q+ 5Xm+Ynq+W/54rDft1nw59RRv4+ua2yWnn1te/+p49OixbjlF9Rft/7ycP57bJY9yy+Vw1z7u2tf9 NfROuVN+3uX/AC4T/A4AAHIXXAAAAAEAEAAAAAAAIgEQAFo2AAAtATAAIDwAAM0kAAD2LwAAQAEQ AD5AAABDARAAplIAAEUBIABFRAAAX60AAEgBcAAEwQAAa8sAACzSAACpSAAAYk4AAPzKAQBCUAAA AAD1DxwAAAANAQAAgxUAAwAAAADV2AEAAQAAAFMBAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADg hZ/y+U9oEKuRCAArJ7PZMAAAAPAlAAANAAAAAQAAAHAAAAACAAAAeAAAAAQAAACYAAAABwAAAKQA AAAIAAAAIAEAAAkAAAAsAQAAEgAAADgBAAAKAAAAWAEAAAsAAABkAQAADAAAAHABAAANAAAAfAEA AA8AAACIAQAAEQAAAJABAAACAAAA6QQAAB4AAAAXAAAASW50cm9kdWNpbmcgIGEgU3BlYWtlcgAA HgAAAAMAAABMQgByHgAAAHEAAABDOlxQcm9ncmFtIEZpbGVzXE1pY3Jvc29mdCBPZmZpY2VcVGVt cGxhdGVzXFByZXNlbnRhdGlvbnNcSW50cm9kdWNpbmcgQSBTcGVha2VyIC0gRGFsZSBDYXJuZWdp ZSBUcmFpbmluZyAoUikucG90AAByAB4AAAADAAAATEIAUB4AAAADAAAAMzAAUB4AAAAVAAAATWlj cm9zb2Z0IFBvd2VyUG9pbnQAb3NvQAAAAKA+JQlmAAAAQAAAACCeqZgUnr4BQAAAAOBYRJkAl74B QAAAACD96eAAsb4BAwAAANgAAABHAAAAViQAAP////8DAAAACABvEE0MAAABAAkAAAMjEgAACABz AAAAAAARAAAAJgYPABgA/////wAAEAAAAAAAAAAAALoDAADKAgAACQAAACYGDwAIAP////8CAAAA FwAAACYGDwAjAP////8EABsAVE5QUBQAyPAAMAAAAAAUAAAARA2KAAAAAAAAAAoAAAAmBg8ACgBU TlBQAAACAPQDCQAAACYGDwAIAP////8DAAAADwAAACYGDwAUAFROUFAEAAwAAQAAAAEAAAAAAAAA BQAAAAsCAAAAAAUAAAAMAsoCugMFAAAABAENAAAAEAAAACYGDwAWAP////8AAAAAAAAAAAAAwAMA ANACAAAIAAAAJgYPAAYA/////wAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQAABwAAAPwCAQAAAAAA AAAEAAAALQEBAAUAAAAHAQQAAAAGAAAAJgYmAAIAAQAFAAAABAEHAAAABwAAAPwCAAD+/v8AAAAE AAAALQECAAwAAAAkAwQAAAAAAMADAADAAy0AAAAtAAcAAAD8AgAA/P3/AAAABAAAAC0BAwAEAAAA 8AECAAwAAAAkAwQAAAAtAMADLQDAA1oAAABaAAcAAAD8AgAA+fz/AAAABAAAAC0BAgAEAAAA8AED AAwAAAAkAwQAAABaAMADWgDAA4cAAACHAAcAAAD8AgAA9fn/AAAABAAAAC0BAwAEAAAA8AECAAwA AAAkAwQAAACHAMADhwDAA7QAAAC0AAcAAAD8AgAA8Pb/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAk AwQAAAC0AMADtADAA+EAAADhAAcAAAD8AgAA6fP/AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQA AADhAMAD4QDAAw4BAAAOAQcAAAD8AgAA4e7/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAkAwQAAAAO AcADDgHAAzsBAAA7AQcAAAD8AgAA1+n/AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQAAAA7AcAD OwHAA2gBAABoAQcAAAD8AgAAzeT/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAkAwQAAABoAcADaAHA A5UBAACVAQcAAAD8AgAAwt//AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQAAACVAcADlQHAA8IB AADCAQcAAAD8AgAAuNr/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAkAwQAAADCAcADwgHAA+8BAADv AQcAAAD8AgAAr9X/AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQAAADvAcAD7wHAAxwCAAAcAgcA AAD8AgAAp9L/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAkAwQAAAAcAsADHALAA0kCAABJAgcAAAD8 AgAAoc//AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQAAABJAsADSQLAA3YCAAB2AgcAAAD8AgAA nc3/AAAABAAAAC0BAgAEAAAA8AEDAAwAAAAkAwQAAAB2AsADdgLAA6MCAACjAgcAAAD8AgAAmsz/ AAAABAAAAC0BAwAEAAAA8AECAAwAAAAkAwQAAACjAsADowLAA9ACAADQAgYAAAAmBiYAAgAAAAYA AAAmBgEQAgAAAAgAAAD6AgAAAAAAAP///wAEAAAALQECAAUAAAAEAQsAAAAFAAAAJgYAEAAADAAA ACQDBAAAAAAAAADQAsAD0ALAAwAAEgAAACYGAhAaAAAAAQEFAAAAAAAAAAAAAQAAAAAAAAAAAAAA BgAAACYGARACAAIABAAAAC0BAAAGAAAAJgYmAAIAAQAFAAAABAENAAAABgAAACYGJgACAAAABwAA APwCAAAAAAAAAAAEAAAALQEEAAQAAADwAQMABgAAACYGJgACAAEABwAAABsE0QLBAwAAAAAGAAAA JgYmAAIAAAAFAAAABAEHAAAABwAAAPwCAAD+/v8AAAAEAAAALQEDAAwAAAAkAwQAAAAAAMADAADA Ay0AAAAtAAcAAAD8AgAA/P3/AAAABAAAAC0BBQAEAAAA8AEDAAwAAAAkAwQAAAAtAMADLQDAA1oA AABaAAcAAAD8AgAA+fz/AAAABAAAAC0BAwAEAAAA8AEFAAwAAAAkAwQAAABaAMADWgDAA4cAAACH AAcAAAD8AgAA9fn/AAAABAAAAC0BBQAEAAAA8AEDAAwAAAAkAwQAAACHAMADhwDAA7QAAAC0AAcA AAD8AgAA8Pb/AAAABAAAAC0BAwAEAAAA8AEFAAwAAAAkAwQAAAC0AMADtADAA+EAAADhAAcAAAD8 AgAA6fP/AAAABAAAAC0BBQAEAAAA8AEDAAwAAAAkAwQAAADhAMAD4QDAAw4BAAAOAQcAAAD8AgAA 4e7/AAAABAAAAC0BAwAEAAAA8AEFAAwAAAAkAwQAAAAOAcADDgHAAzsBAAA7AQcAAAD8AgAA1+n/ AAAABAAAAC0BBQAEAAAA8AEDAAwAAAAkAwQAAAA7AcADOwHAA2gBAABoAQcAAAD8AgAAzeT/AAAA BAAAAC0BAwAEAAAA8AEFAAwAAAAkAwQAAABoAcADaAHAA5UBAACVAQcAAAD8AgAAwt//AAAABAAA AC0BBQAEAAAA8AEDAAwAAAAkAwQAAACVAcADlQHAA8IBAADCAQcAAAD8AgAAuNr/AAAABAAAAC0B AwAEAAAA8AEFAAwAAAAkAwQAAADCAcADwgHAA+8BAADvAQcAAAD8AgAAr9X/AAAABAAAAC0BBQAE AAAA8AEDAAwAAAAkAwQAAADvAcAD7wHAAxwCAAAcAgcAAAD8AgAAp9L/AAAABAAAAC0BAwAEAAAA 8AEFAAwAAAAkAwQAAAAcAsADHALAA0kCAABJAgcAAAD8AgAAoc//AAAABAAAAC0BBQAEAAAA8AED AAwAAAAkAwQAAABJAsADSQLAA3YCAAB2AgcAAAD8AgAAnc3/AAAABAAAAC0BAwAEAAAA8AEFAAwA AAAkAwQAAAB2AsADdgLAA6MCAACjAgcAAAD8AgAAmsz/AAAABAAAAC0BBQAEAAAA8AEDAAwAAAAk AwQAAACjAsADowLAA9ACAADQAgYAAAAmBgEQAgABAAQAAAAtAQEABAAAAPABBQAFAAAABAENAAAA CAAAAPoCAAAAAAAAAAAAAAQAAAAtAQMABwAAAPwCAAD///8AAAAEAAAALQEFAAUAAAAHAQEAAAAI AAAAJgYPAAYA/////wEACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AACoAAAAGP///2kE AADRAgAACAAAACYGDwAGAP////8AAAQAAAAtAQAABAAAAC0BAQAFAAAABwEEAAAABgAAACYGJgAC AAEABQAAAAQBBwAAAAcAAAD8AgAAmcz+AAAABAAAAC0BBgAMAAAAJAMEAKgAGP9pBBj/aQRU/6gA VP8HAAAA/AIAAJzM/gAAAAQAAAAtAQcABAAAAPABBgAMAAAAJAMEAKgAVP9pBFT/aQSP/6gAj/8H AAAA/AIAAJ/O/QAAAAQAAAAtAQYABAAAAPABBwAMAAAAJAMEAKgAj/9pBI//aQTL/6gAy/8HAAAA /AIAAKTP/AAAAAQAAAAtAQcABAAAAPABBgAMAAAAJAMEAKgAy/9pBMv/aQQGAKgABgAHAAAA/AIA AKnR+wAAAAQAAAAtAQYABAAAAPABBwAMAAAAJAMEAKgABgBpBAYAaQRCAKgAQgAHAAAA/AIAALDT +QAAAAQAAAAtAQcABAAAAPABBgAMAAAAJAMEAKgAQgBpBEIAaQR9AKgAfQAHAAAA/AIAALjW9wAA AAQAAAAtAQYABAAAAPABBwAMAAAAJAMEAKgAfQBpBH0AaQS5AKgAuQAHAAAA/AIAAMHZ9QAAAAQA AAAtAQcABAAAAPABBgAMAAAAJAMEAKgAuQBpBLkAaQT0AKgA9AAHAAAA/AIAAMnc8wAAAAQAAAAt AQYABAAAAPABBwAMAAAAJAMEAKgA9ABpBPQAaQQwAagAMAEHAAAA/AIAANHg8QAAAAQAAAAtAQcA BAAAAPABBgAMAAAAJAMEAKgAMAFpBDABaQRsAagAbAEHAAAA/AIAANji7wAAAAQAAAAtAQYABAAA APABBwAMAAAAJAMEAKgAbAFpBGwBaQSnAagApwEHAAAA/AIAAN7l7QAAAAQAAAAtAQcABAAAAPAB BgAMAAAAJAMEAKgApwFpBKcBaQTjAagA4wEHAAAA/AIAAOLm7AAAAAQAAAAtAQYABAAAAPABBwAM AAAAJAMEAKgA4wFpBOMBaQQeAqgAHgIHAAAA/AIAAOXo6wAAAAQAAAAtAQcABAAAAPABBgAMAAAA JAMEAKgAHgJpBB4CaQRaAqgAWgIHAAAA/AIAAOfp6gAAAAQAAAAtAQYABAAAAPABBwAMAAAAJAME AKgAWgJpBFoCaQSVAqgAlQIHAAAA/AIAAOnp6gAAAAQAAAAtAQcABAAAAPABBgAMAAAAJAMEAKgA lQJpBJUCaQTRAqgA0QIGAAAAJgYmAAIAAAAGAAAAJgYBEAIAAAAEAAAALQECAAUAAAAEAQsAAAAF AAAAJgYAEAAADAAAACQDBACIAhj/qAD0AIgC0AJoBPQAEgAAACYGAhAaAAAAAQEFAAAAAAAAAAAA AQAAAAAAAAAAAAAABgAAACYGARACAAIABAAAAC0BAAAGAAAAJgYmAAIAAQAFAAAABAENAAAABgAA ACYGJgACAAAABAAAAC0BBAAEAAAA8AEHAAYAAAAmBiYAAgABAAwAAAAkAwQAiAIY/6gA9ACIAtAC aAT0AAYAAAAmBiYAAgAAAAUAAAAEAQcAAAAHAAAA/AIAAJnM/gAAAAQAAAAtAQYADAAAACQDBACo ABj/aQQY/2kEVP+oAFT/BwAAAPwCAACczP4AAAAEAAAALQEHAAQAAADwAQYADAAAACQDBACoAFT/ aQRU/2kEj/+oAI//BwAAAPwCAACfzv0AAAAEAAAALQEGAAQAAADwAQcADAAAACQDBACoAI//aQSP /2kEy/+oAMv/BwAAAPwCAACkz/wAAAAEAAAALQEHAAQAAADwAQYADAAAACQDBACoAMv/aQTL/2kE BgCoAAYABwAAAPwCAACp0fsAAAAEAAAALQEGAAQAAADwAQcADAAAACQDBACoAAYAaQQGAGkEQgCo AEIABwAAAPwCAACw0/kAAAAEAAAALQEHAAQAAADwAQYADAAAACQDBACoAEIAaQRCAGkEfQCoAH0A BwAAAPwCAAC41vcAAAAEAAAALQEGAAQAAADwAQcADAAAACQDBACoAH0AaQR9AGkEuQCoALkABwAA APwCAADB2fUAAAAEAAAALQEHAAQAAADwAQYADAAAACQDBACoALkAaQS5AGkE9ACoAPQABwAAAPwC AADJ3PMAAAAEAAAALQEGAAQAAADwAQcADAAAACQDBACoAPQAaQT0AGkEMAGoADABBwAAAPwCAADR 4PEAAAAEAAAALQEHAAQAAADwAQYADAAAACQDBACoADABaQQwAWkEbAGoAGwBBwAAAPwCAADY4u8A AAAEAAAALQEGAAQAAADwAQcADAAAACQDBACoAGwBaQRsAWkEpwGoAKcBBwAAAPwCAADe5e0AAAAE AAAALQEHAAQAAADwAQYADAAAACQDBACoAKcBaQSnAWkE4wGoAOMBBwAAAPwCAADi5uwAAAAEAAAA LQEGAAQAAADwAQcADAAAACQDBACoAOMBaQTjAWkEHgKoAB4CBwAAAPwCAADl6OsAAAAEAAAALQEH AAQAAADwAQYADAAAACQDBACoAB4CaQQeAmkEWgKoAFoCBwAAAPwCAADn6eoAAAAEAAAALQEGAAQA AADwAQcADAAAACQDBACoAFoCaQRaAmkElQKoAJUCBwAAAPwCAADp6eoAAAAEAAAALQEHAAQAAADw AQYADAAAACQDBACoAJUCaQSVAmkE0QKoANECBgAAACYGARACAAEABAAAAC0BAQAEAAAA8AEHAAUA AAAEAQ0AAAAEAAAALQEDAAQAAAAtAQUABQAAAAcBAQAAAAgAAAAmBg8ABgD/////AQAIAAAAJgYP AAYA/////wEABwAAAPwCAAD/zAAAAAAEAAAALQEGAAQAAAAtAQAABAAAAC0BBgAJAAAAHQYhAPAA 0AIoAAAAAAAEAAAALQEGAAQAAAAtAQUABAAAAPABBgAEAAAALQEDAAcAAAD8AgAAmQCZAAAABAAA AC0BBgAEAAAALQEAAAQAAAAtAQYACQAAAB0GIQDwAPAAKAAAAAAABAAAAC0BBgAEAAAALQEFAAQA AADwAQYABAAAAC0BAwAQAAAAJgYPABYA/////wAAVwAAAG8CAAAhAQAAkQIAAAgAAAAmBg8ABgD/ ////AQAcAAAA+wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAKIKCkrSfO1323ztd9Bn73eiCgpK AAAKAAQAAAAtAQYABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgECAAAAEAAAACYGDwAWAP////8A AFcAAACPAgAAiQEAAMECAAAIAAAAJgYPAAYA/////wEABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA AgECAAAABAAAAC0BAQAEAAAALQEAAAcAAAAbBJkAYQNAAGAABAAAAC0BBQAEAAAALQEDAAUAAAAJ AgAAAAIFAAAAFAIAAAAAHAAAAPsC1/8AAAAAAACQAQAAAO4AAAAiVGFob21hAACtCgpl0nztd9t8 7XfQZ+93rQoKZQAACgAEAAAALQEHAAQAAADwAQYABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEY AAAABQAAAAIBAQAAAA8AAAAyCmYAywAFAAAASVBTZWMAEAAWABcAFgATAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAyCmUAygAF AAAASVBTZWMAEAAWABcAFgATAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAAC4AAAAyCmYAMQEaAAAAL0lLRSBQdWJsaWMgS2V5IEVuY3J5 cHRpb24QABAAGAAXAA0AFwAXABcACQAKABMADQAYABYAFQANABcAFwATAA8AFAAXAA4ACQAXABcA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEB AAAALgAAADIKZQAwARoAAAAvSUtFIFB1YmxpYyBLZXkgRW5jcnlwdGlvbhAAEAAYABcADQAXABcA FwAJAAoAEwANABgAFgAVAA0AFwAXABMADwAUABcADgAJABcAFwAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAzAAAAMgqQAMsAHQAAAEFn Z3Jlc3NpdmUgTW9kZSB2dWxuZXJhYmlsaXR5ABkAFwAXAA4AFgATABIACgAUABYADQAgABcAFgAW AA0AFQAXAAkAFwAWAA8AFgAXAAkACgAJAA4AFQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1N TQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAzAAAAMgqPAMoAHQAAAEFnZ3Jlc3NpdmUg TW9kZSB2dWxuZXJhYmlsaXR5ABkAFwAXAA4AFgATABIACgAUABYADQAgABcAFgAWAA0AFQAXAAkA FwAWAA8AFgAXAAkACgAJAA4AFQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAEAAAALQEB AAQAAAAtAQAABwAAABsEJwKJA+UAUAAEAAAALQEFAAQAAAAtAQMABQAAAAkCTU1NAgUAAAAUAgAA AAAcAAAA+wLl/wAAAAAAAJABAAAA7gAAAABUaW1lcyBOZXcgUm9tYW4A23ztd9Bn73eiCgpLAAAK AAQAAAAtAQYABAAAAPABBwAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA FgAAADIKBAG6AAoAAABJbml0aWF0b3IgCQANAAgABwAHAAwABwAOAAkABgAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgoEAToC DgAAACAgICAgUmVzcG9uZGVyBwAGAAcABwAGABIADAAKAA4ADQANAA4ADAAIAAUAAAAuAQEAAAAF AAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABgAAAAyCjEB WgALAAAAICAgICAgICAgICCdBwAGAAcABwAGAAcABwAGAAcABwAGAAUAAAAuAQEAAAAFAAAAAgEC AAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAHMAAAAyCjEBugBIAAAA LS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0tCQAJAAkACAAJAAkACQAJAAkACAAJAAcABwAGAAcABwAGAAcABwAGAAcA BwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAGAAcABwAG AAcABwAGAAcABwAGAAcABwAGAAcABwAIAAkACQAJAAkACQAIAAkACQAJAAkABQAAAC4BAQAAAAUA AAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAJwAAADIKXgFa ABUAAABIRFIsIFNBLCBbIEhBU0goMSksXSAAEwAUABIABgAHAA8AEwAHAAYACQAHABMAFAAOABQA CQANAAkABgAJAAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAu ARgAAAAFAAAAAgEBAAAADAAAADIKXgFdAQMAAABLRWllEwARAAcABQAAAC4BAQAAAAUAAAACAQIA AAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKXgGIAQEAAAAs AAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAA AgEBAAAACQAAADIKjAFaAAEAAAA8AA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAA ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADAAAADIKjAFpAAMAAABJRGllCQATAAgABQAAAC4B AQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAA ADIKjAGNAAEAAAA+AA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAAEAAAADIKjAGcAAYAAABQdWJrZXkOAA4ADQANAAwADgAFAAAALgEB AAAABQAAAAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAPAAAA MgqMAewABQAAAF9yLCA8AA0ACQAGAAcADwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1NTQIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAKAAAAMgqMAR4BAgAAAE5pEwAIAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAy CowBOQEBAAAAPmkPAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAA LgEYAAAABQAAAAIBAQAAABAAAAAyCowBSAEGAAAAUHVia2V5DwANAA0ADgALAA4ABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAGwAAADIK jAGYAQ0AAABfciAgICAgLS0tLS0+AA0ACQAHAAYABwAHAAYACQAJAAkACQAIAA8ABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAANAAAADIK uQF6AR4AAAAgICAgICAgICAgICA8LS0tLS0gICBIRFIsIFNBLCAHAAYABwAHAAYABwAHAAYABwAH AAYABwAPAAkACQAJAAgACQAHAAcABgAUABMAEgAGAAcADwATAAcABwAFAAAALgEBAAAABQAAAAIB AgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAMAAAAMgq5AY8CAwAA AEtFciATABAACQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAMAAAAMgq5AbsCAwAAACwgPCAHAAYADwAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAMAAAAMgq5AdcCAwAAAElE ciAJABQACAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAAJAAAAMgq5AfwCAQAAAD5pEAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1N TQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgq5AQwDBgAAAFB1YktleQ4ADgAN ABMADAAOAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAA BQAAAAIBAQAAAAwAAAAyCrkBYgMDAAAAX2ksIA0ABwAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAA AAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABYAAAAyCuYB2gEKAAAAICAgICAg ICAgPAcABgAHAAcABgAHAAcABgAHAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJNTU0CBQAA ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACgAAADIK5gElAgIAAABOchMACQAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgrm AUECAQAAAD5yDwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1NTQIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAQAAAAMgrmAVACBgAAAFB1YktleQ8ADQAOABMADAANAAUAAAAuAQEAAAAF AAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABYAAAAyCuYB pgIKAAAAX2ksIEhBU0hfUg4ABwAHAAYAFAATAA8AEwAOABEABQAAAC4BAQAAAAUAAAACAQIAAAAF AAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAFgAAADIKFAJaAAoAAABIRFIs SEFTSF9JEwAUABIABgAUABMADwATAA0ACQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAk1NTQIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAhAAAAMgoUAnoBEQAAACAgICAgICAgICAgLS0t LS0+AAcABgAHAAcABgAHAAcABgAHAAcABgAJAAkACQAJAAkADwAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAACAQIAAAAEAAAALQEAAAQAAAAtAQEAHAAAAPsCEAAHAAAAAAC8AgAAALoBAgIiU3lzdGVt AHflCmZUBwCKAQAACgAGAAAABwCKAQAACgAEAAAALQEHAAQAAADwAQYADwAAACYGDwAUAFROUFAE AAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF 1c3VnC4bEJOXCAArLPmuvAMAAHgDAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAAMAA AAAGAAAAyAAAAAcAAADQAAAACAAAANgAAAAJAAAA4AAAAAoAAADoAAAAFwAAAPAAAAALAAAA+AAA ABAAAAAAAQAAEwAAAAgBAAAWAAAAEAEAAA0AAAAYAQAADAAAAPMCAAACAAAA6QQAAB4AAAAPAAAA T24tc2NyZWVuIFNob3cAAB4AAAAPAAAATGF0dmlqYXMgQmFua2EAAAMAAABwUwMAAwAAACAAAAAD AAAABQAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAAeEAAACQAAABAAAABUaW1lcyBOZXcgUm9tYW4ABwAAAFRhaG9tYQA3AAAA SW50cm9kdWNpbmcgQSBTcGVha2VyIC0gRGFsZSBDYXJuZWdpZSBUcmFpbmluZyAoUikucG90ABcA AABNaWNyb3NvZnQgQ2xpcCBHYWxsZXJ5AEAAAAAgSVBTZWMvSUtFIFB1YmxpYyBLZXkgRW5jcnlw dGlvbiAgQWdncmVzc2l2ZSBNb2RlIHZ1bG5lcmFiaWxpdHkAQgAAACBJUFNlYy9JS0UgUHVibGlj IEtleSBFbmNyeXB0aW9uICAgQWdncmVzc2l2ZSAgTW9kZSB2dWxuZXJhYmlsaXR5AEIAAAAgSVBT ZWMvSUtFIFB1YmxpYyBLZXkgRW5jcnlwdGlvbiAgICBBZ2dyZXNzaXZlIE1vZGUgdnVsbmVyYWJp bGl0eQBCAAAAIElQU2VjL0lLRSBQdWJsaWMgS2V5IEVuY3J5cHRpb24gICAgQWdncmVzc2l2ZSBN b2RlIHZ1bG5lcmFiaWxpdHkARAAAACBJUFNlYy9JS0UgUHVibGljIEtleSBFbmNyeXB0aW9uICAg ICBBZ2dyZXNzaXZlICBNb2RlIHZ1bG5lcmFiaWxpdHkADBAAAAgAAAAeAAAACwAAAEZvbnRzIFVz ZWQAAwAAAAIAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAAVAAAARW1iZWRk ZWQgT0xFIFNlcnZlcnMAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABQAAAJgAAAAD AAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADpBAAA QQAAAE4AAAB7ADEARQA1ADQAMAA0AEUAMAAtADEAQwBGADQALQAxADEARAAzAC0AQgA0ADIARQAt ADAAMAAxADAANQBBADMAMABBADgANQAxAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD2DxoAAAAUAAAAX8CR4znZAQACAPQDAwASAExCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAAR AAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAA AC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAA PAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABK AAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgA AABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAA AGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA dQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACD AAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEA AACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAA AKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAA rgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8 AAAAvQAAAP7///+/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoA AADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAA ANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA 5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1 AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMB AAAEAQAABQEAAAYBAAAHAQAACAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEA ABIBAAATAQAAFAEAABUBAAAWAQAAFwEAABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAA IAEAACEBAAAiAQAAIwEAACQBAAAlAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAu AQAALwEAADABAAAxAQAAMgEAADMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAADwB AAA9AQAAPgEAAD8BAABAAQAAQQEAAEIBAABDAQAARAEAAEUBAABGAQAARwEAAEgBAABJAQAASgEA AEsBAABMAQAATQEAAE4BAABPAQAAUAEAAFEBAABSAQAAUwEAAFQBAABVAQAAVgEAAFcBAABYAQAA WQEAAFoBAABbAQAAXAEAAF0BAABeAQAAXwEAAGABAABhAQAAYgEAAGMBAABkAQAAZQEAAGYBAABn AQAAaAEAAGkBAABqAQAAawEAAGwBAABtAQAAbgEAAG8BAABwAQAAcQEAAHIBAABzAQAAdAEAAHUB AAB2AQAAdwEAAHgBAAB5AQAAegEAAHsBAAB8AQAAfQEAAH4BAAB/AQAAgAEAAIEBAACCAQAAgwEA AIQBAACFAQAAhgEAAIcBAACIAQAAiQEAAIoBAACLAQAAjAEAAI0BAACOAQAAjwEAAJABAACRAQAA kgEAAJMBAACUAQAAlQEAAJYBAACXAQAAmAEAAJkBAACaAQAAmwEAAJwBAACdAQAAngEAAJ8BAACg AQAAoQEAAKIBAACjAQAApAEAAKUBAACmAQAApwEAAKgBAACpAQAAqgEAAP7///+sAQAArQEAAK4B AACvAQAAsAEAALEBAACyAQAAswEAALQBAAC1AQAAtgEAALcBAAC4AQAAuQEAALoBAAC7AQAAvAEA AL0BAAC+AQAA/v///8ABAADBAQAAwgEAAMMBAADEAQAAxQEAAMYBAAD+////yAEAAMkBAADKAQAA ywEAAMwBAADNAQAAzgEAAP7////9/////f////3////9////1AEAAP7///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////UgBvAG8AdAAgAEUA bgB0AHIAeQAAAAMADAAAACQDBAAAAO8BwAPvAcADHAIAABwCBwAAAPwCAACn0v8AAAAEABYABQH/ /////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAEkCBwAAAPwCAAChz/8AAAD+////AAAAAAQA AABQAGkAYwB0AHUAcgBlAHMAAABJAsADdgIAAHYCBwAAAPwCAACdzf8AAAAEAAAALQEDAAQAAADw AQUADAAAACQDEgACAf///////////////6MCBwAAAPwCAACazP8AAAAEAAAALQEFAAQAAADwAQMA DAAAAAAAAAATegEAwAOjAkMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAQAEAAAA8AEFAAUAAAAE AQ0AAAAIAAAA+gIAAAAAAAAAAAAABAAaAAIBAQAAAP///////////wAAAAQAAAAtAQUABQAAAAcB AQAAAAgAAAAmBg8ABgD/////xwEAAAAQAAAPAAYABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAJgYPAAYA/////wAABAAAAC0BAAAEACgAAgECAAAABQAAAP////8GAAAA JgYmAAIAAQAFAAAABAEHAAAABwAAAPwCAACZzP4AAACrAQAAICYAAAwAAABQAG8AdwBlAHIAUABv AGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAABwAEAAAA8AEGAAwAAAAkAwQAqABU/2kEKAACAf// /////////////wAAn879AAAABAAAAC0BBgAEAAAA8AEHAAwAAAAkAwQAqACP/74AAABd2QEAqADL /wUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA AAD8AgAAqdE4AAIBBAAAAP//////////8AEHAAwAAAAkAwQAqAAGAGkEBgBpBEIAqABCAAcAAAD8 AgAAvwEAAAAQAAAAAC0BBwAEAAAA8AEGAAwAAAAkAwQAqABCAGkEQgBpBH0AqAB9AAcAAAD8AgAA uNb3AAAABAAAAC0BBgAEAAAA8AEHAAAAAAD///////////////9pBLkAqAC5AAcAAAD8AgAAwdn1 AAAABAAAAC0BBwAEAAAA8AEGAAwAAAAkAwQAqAC5AGkEuQBpBPQAqAD0AAcAAAD8AgAAydzzAAAA BAAAAC0BBgAEAAAA8AEHAAwAAAAkAwQAqAD0AGkE9ABpBDABAAAAAP///////////////wAABAAA AC0BBwAEAAAA8AEGAAwAAAAkAwQAqAAwAWkEMAFpBGwBqABsAQcAAAD8Ag== ------_=_NextPart_000_01BEB101.8C1A2F44-- From owner-ipsec@lists.tislabs.com Wed Jun 9 22:04:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA25417; Wed, 9 Jun 1999 22:04:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA27811 Wed, 9 Jun 1999 23:11:25 -0400 (EDT) X-Authentication-Warning: taz.nama.digitalvoodoo.org: tlyons owned process doing -bs Date: Thu, 10 Jun 1999 00:19:43 -0400 (EDT) From: Tim Lyons X-Sender: tlyons@taz.nama.digitalvoodoo.org To: Makoto Kubota cc: ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? In-Reply-To: <199906100057.JAA07316@swan.png.flab.fujitsu.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Makoto, Your Scenario will work. --Tim On Thu, 10 Jun 1999, Makoto Kubota wrote: > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > > discovered a reason for conflict in using the two protocols together. Just > > > trying to understand if it is possible.....or if a IPSEC and NAT are just > > > not made to function together. Specifics of the reason this will or won't > > > work would be VERY much appreciated. > > > > Yep, NAT breaks IPSEC. > > > > NAT breaks any protocol which protects IP addresses from modification. > > AH's checksum includes these header fields, so that's one thing which > > breaks. > > Can I have additional question about this? > > So, if we do NAT before IPSEC, can I usr NAT & IPSec together? > For example, > Home Office ---[NAT]---[IPSec]--->Internet... > Home Office <--[NAT]<--[IPSec]<---Internet... > > Thanks in advance. > From owner-ipsec@lists.tislabs.com Thu Jun 10 07:54:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA07820; Thu, 10 Jun 1999 07:54:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28797 Thu, 10 Jun 1999 08:36:21 -0400 (EDT) Message-ID: From: "Michael Lee" To: Glen Zorn , "'Stephen Kent'" Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 10 Jun 1999 08:45:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With regard to the need for a PKI, I too am grappling with this question. My application deals with enterprise systems almost exclusively, so I question the need to have 3rd party certificates and a full PKI. The 3rd party certificates are going to represent an up front as well as an ongoing maintenance cost for each server and client within the system. Why not do it within our own IT department? By the way, I am relatively new in this field. Does anyone know of a good summary of the IKE and other key distribution/management documents which I can refer to? Regards, Michael Lee > ---------- > From: Stephen Kent[SMTP:kent@bbn.com] > Sent: Wednesday, June 09, 1999 4:50 PM > To: Glen Zorn > Cc: ipsec@lists.tislabs.com > Subject: Re: New XAUTH draft > > Glen, > > >> >Sorry, apparently I did not make myself clear. I was using the term > "user > >> >authentication" in the common sense -- that is to say, the sense that > is > >> >understood in the 95+% of installations where PKI is not existent, let > >> >alone ubiquitous. In the day ("just around the corner" for the last > 10 > >> >years or so) when PKI _is_ ubiquitous, you are absolutely correct. I > am > >> >obviously somewhat skeptical that that day will come very soon, but I > have > >> >been wrong before, so suppose I am wrong this time. In that case, the > >> >inclusion of XAUTH in IKE does nothing but add useless baggage to an > >> >already complex protocol. Conversely, suppose that I am right, and > >> >PKI is not ubiquitous for some lengthy period. In this case, the > >> >inclusion of XAUTH in IKE will likely slow PKI deployment and reduce > the > >> >overall security of the system (through the use of comparatively weak > >> >user authentication methods). Either way, this is a bad idea. > >> > >> This has NOTHING to do with whether we have univerals PKIs or not. The > >> context we are discussing is a closed community of users who are > authorized > >> to access resources. This set of users is well known, bounded, etc., > >> because the legacy systems you are so fond of can deal only with such > >> communities. Thus there is NO need for ubiquitous PKIs to support > these > >> needs. > > > >No need to shout, Steve. > > I felt the need to shout because the mention of a ubiquitous PKI is very > much a red herring. > > >> Organizations need only migrate their Radius databases to local PKI > >> databases. In fact, it is especially easy to support online issuance > of > >> certs to users when you already have a legacy user authentication > system. > >> > > > >Great! Sounds like we're in violent agreement that XAUTH is unnecessary, > >since the required infrastructure should be easy to install. > > If I had my druthers, I would not encourage use of legacy systems by > making > accommodations for them in IPsec. But, the folks selling the technology > argue that it is necessary to accomnmodate these systems to facilitate > deployment of IPsec. Given the choice between user auth via some legacy > means outside of IPsec, and the addition of support for such technoogy in > IKE, I vote for the latter, because of the better tie-in to access > control, > etc. > > >> >> Also, because IPsec involves access control as a basic security > >>service, if > >> >> the SPD entries take the form of user names, then it is preferable > >>that IKE > >> >> be able to verify user identity, in order to support the access > control > >> >> features of IPsec. > >> > > >> >Access control means many things to many people. In the scenario > under > >> >discussion (remote access to some "home" network) it's hard to imagine > >> >administrators managing user-level access control via IPsec filters, > >> >especially if the home network is at all dynamic. > >> > >> Access control can be applied at various levels of granularity, true. > I > >> know your preference here, since we've just concluded an extended > debate on > >> this in the context of L2TP. You clearly didn't feel that IPsec access > >> control was useful, > > > >On the contrary, IPsec filtering is certainly useful, and not a bad hack > >(though rather difficult to configure). > > > >> and thus argued against pointing out the access control > >> differences between L2TP's use of IPsec vs. native IPsec use. Part of > your > >> argument was that PPP implementations provide appropriate access > controls, > >> even though such controls are not part of the standards. > >> > > > >Actually, my main point was that IPsec filtering is less a security > >feature than an efficiency hack. It should be obvious that equivalent > >packet filters applied _at either end_ of a tunnel will have the same > >effect on security; it _is_ more efficient (in terms of bandwidth) to > >apply the filters before the traffic enters the tunnel, however. Also, > >there are standards and standards; even though packet filtering in cisco > >routers is not "standard" I'll wager that there are far more people who > >can successfully configure a cisco filter than can configure IKE... > > Filtering at the source is not security-equivalent to filtering at the > destination. The reason for filtering at the destination is to ensure that > the range of traffic being sent matches what was negotiated when the SA > was > established. This is a critical security issue, and one of the reasons > that we debated how to phrase the differences between direct use of IPsec > and use if IPsec under PPTP for a while. Also, your use of terminology > here is a bit odd, i.e., "configure IKE." IKE is not where packet > filtering occurs; filtering is an integral part of IPsec, while IKE is > optional. > > >> >> If another protocol is employed to veriy user identity, > >> >> then one creates a more complex interdependence between IPsec and > the > >>other > >> >> protocol, right? > >> > > >> >Not sure I understand. Is the "other protocol" RADIUS? If so, there > is a > >> >much bigger problem then interdependence complexity, due to the severe > and > >> >well-known security problems with the RADIUS protocol (especially in a > >> >proxied environment. > >> > >> I was not focusing on any specific authentication protocol, just making > a > >> general observation. > >> > > > >Oh, OK. I'm still not sure that I see a great deal of complexity. It > >seems that the hardest thing would be to make sure that the SA goes away > >when the user logs off or if user auth fails. Is that required, though? > > See my comments above re the need to tie user auth to access controls in > IPsec. > > Steve > From owner-ipsec@lists.tislabs.com Thu Jun 10 09:16:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09094; Thu, 10 Jun 1999 09:16:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29120 Thu, 10 Jun 1999 10:05:53 -0400 (EDT) Message-ID: <9DBF3C44F94BD2119C4400105A16BC7F500BAE@MAILMAN> From: "Brothers, John" To: ipsec@lists.tislabs.com Subject: RE: NAT and IPSEC INCOMPATIBLE??? Date: Thu, 10 Jun 1999 10:08:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Linux has a patch available that allows NAT to work with IPSec, as long as AH is turned off. It isn't perfect, but it works quite well. ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html By the way, there are certain markets where NAT is a requirement (such as running IP to the guest rooms in hotels) and IPSec is also extremely high profile. It would help everyone out if there was a built-in method to scale arbitarily large for address translated IPSec connections - just with ESP, I don't think that AH is as important to these users. jb > -----Original Message----- > From: Tim Lyons [SMTP:tlyons@digitalvoodoo.org] > Sent: Thursday, June 10, 1999 12:20 AM > To: Makoto Kubota > Cc: ipsec@lists.tislabs.com > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > Makoto, > > Your Scenario will work. > > --Tim > > > On Thu, 10 Jun 1999, Makoto Kubota wrote: > > > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > > > discovered a reason for conflict in using the two protocols > together. Just > > > > trying to understand if it is possible.....or if a IPSEC and NAT are > just > > > > not made to function together. Specifics of the reason this will or > won't > > > > work would be VERY much appreciated. > > > > > > Yep, NAT breaks IPSEC. > > > > > > NAT breaks any protocol which protects IP addresses from modification. > > > AH's checksum includes these header fields, so that's one thing which > > > breaks. > > > > Can I have additional question about this? > > > > So, if we do NAT before IPSEC, can I usr NAT & IPSec together? > > For example, > > Home Office ---[NAT]---[IPSec]--->Internet... > > Home Office <--[NAT]<--[IPSec]<---Internet... > > > > Thanks in advance. > > From owner-ipsec@lists.tislabs.com Thu Jun 10 09:21:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09135; Thu, 10 Jun 1999 09:21:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29240 Thu, 10 Jun 1999 10:24:58 -0400 (EDT) Date: Thu, 10 Jun 1999 07:33:50 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: NAT and IPSEC INCOMPATIBLE??? To: "Brothers, John" Cc: ipsec@lists.tislabs.com In-Reply-To: "Your message with ID" <9DBF3C44F94BD2119C4400105A16BC7F500BAE@MAILMAN> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Linux has a patch available that allows NAT to work with IPSec, as long as > AH is turned off. It isn't perfect, > but it works quite well. > > ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html > > By the way, there are certain markets where NAT is a requirement (such as > running IP to the guest rooms in hotels) > and IPSec is also extremely high profile. It would help everyone out if > there was a built-in method to scale arbitarily > large for address translated IPSec connections - just with ESP, I don't > think that AH is as important to these users. hmm... so I HAVE to trust my hotel? What kind of customers are they looking for? If they are looking for the commuter, then NAT is a bad thing since I will want to encrypt my data back to my corporate network. PatC > > jb > > > -----Original Message----- > > From: Tim Lyons [SMTP:tlyons@digitalvoodoo.org] > > Sent: Thursday, June 10, 1999 12:20 AM > > To: Makoto Kubota > > Cc: ipsec@lists.tislabs.com > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > Makoto, > > > > Your Scenario will work. > > > > --Tim > > > > > > On Thu, 10 Jun 1999, Makoto Kubota wrote: > > > > > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not yet > > > > > discovered a reason for conflict in using the two protocols > > together. Just > > > > > trying to understand if it is possible.....or if a IPSEC and NAT are > > just > > > > > not made to function together. Specifics of the reason this will or > > won't > > > > > work would be VERY much appreciated. > > > > > > > > Yep, NAT breaks IPSEC. > > > > > > > > NAT breaks any protocol which protects IP addresses from modification. > > > > AH's checksum includes these header fields, so that's one thing which > > > > breaks. > > > > > > Can I have additional question about this? > > > > > > So, if we do NAT before IPSEC, can I usr NAT & IPSec together? > > > For example, > > > Home Office ---[NAT]---[IPSec]--->Internet... > > > Home Office <--[NAT]<--[IPSec]<---Internet... > > > > > > Thanks in advance. > > > From owner-ipsec@lists.tislabs.com Thu Jun 10 09:25:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09168; Thu, 10 Jun 1999 09:25:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29160 Thu, 10 Jun 1999 10:14:39 -0400 (EDT) Date: Thu, 10 Jun 1999 10:23:44 -0400 Message-Id: <199906101423.KAA03778@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Heyman," == Heyman, Michael writes: Heyman,> Hmmm, this means if a policy _explicitly_ states 128 bit Heyman,> encryption (note, the policy _did not_ state 128 bit Heyman,> encryption or greater), then IKE has the right to change the Heyman,> policy to be 128 bit or greater? Heyman,> IMHO, IKE must act dumb when it comes to policy and must not Heyman,> assume it knows better then whatever set that policy.... I think this is the right approach. Rather than add ways for IKE to do things not stated in the policy, let's have recommendations about what the policies should be able to express. That's a better solution because it satiesfies the "principle of least astonishment". In other words, a. IKE should negotiate exactly according to the policy it has been given. b. Implementation should be encouraged to implement policies of the form "accept exactly X" as well as "accept X or stronger". The spec should give some examples of what "X or stronger" means. I believe this should satisfy both sides, because it allows and encourages negotiating up, without allowing negotiating up when it goes against the expressed policies. paul From owner-ipsec@lists.tislabs.com Thu Jun 10 11:11:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10356; Thu, 10 Jun 1999 11:11:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29567 Thu, 10 Jun 1999 11:51:23 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB114A7@exchange> From: Stephane Beaulieu To: John Hawkins , "'ipsec'" Subject: RE: NAT and IPSEC INCOMPATIBLE??? Date: Thu, 10 Jun 1999 11:30:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are alternatives to doing NAT with IPSec. For example, using the Isakmp-Cfg method http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-04.txt, the edge device (which in your network does NAT) could allocate a private address to the remote user. The remote user then uses this private address in the inner IP header of the tunneled ESP and/or AH packet. Ex. Tunneled Packet from remote user to private network... Outer header Src IP = ISP allocated IP Outer header Dest IP = Edge Device IP AH ESP Inner header Src IP = Edge Device allocated IP (may be private/illegal address) Inner header Dest IP = IP on private network. data There are approximately 5 or so vendors who support this today, and many more who are planning to support it. From owner-ipsec@lists.tislabs.com Thu Jun 10 11:19:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10488; Thu, 10 Jun 1999 11:19:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29638 Thu, 10 Jun 1999 12:10:32 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D099@md-exchange1.nai.com> From: "Mason, David" To: "'Paul Koning'" , ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 10 Jun 1999 08:51:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to see the following: For any symmetric ciphers where there is negligible differences in memory consumption and performance overhead between key lengths, the ID/RFC that explains how the cipher is negotiated via IKE (transform ID, etc) MUST state that only the maximum key length is used (no key length attribute). If this was the case, "negotiating up" for these ciphers would no longer be an issue. For security attributes that have performance/security tradeoffs, security gateway administrators will most likely want the policy that they configure to be enforced (hypothetically - they wouldn't want a policy that says PFS off being "negotiated up" to 2048-bit DH for 1000 simultaneous SA negotiations). If an administrator wants to allow "negotiation up" he would configure it that way and all combinations for a security attribute of value X and greater would be offered and allowed (but then that wouldn't be "negotiate up"). -dave > -----Original Message----- > From: Paul Koning [SMTP:pkoning@xedia.com] > Sent: Thursday, June 10, 1999 10:24 AM > To: ipsec@lists.tislabs.com > Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) > > >>>>> "Heyman," == Heyman, Michael writes: > > Heyman,> Hmmm, this means if a policy _explicitly_ states 128 bit > Heyman,> encryption (note, the policy _did not_ state 128 bit > Heyman,> encryption or greater), then IKE has the right to change the > Heyman,> policy to be 128 bit or greater? > > Heyman,> IMHO, IKE must act dumb when it comes to policy and must not > Heyman,> assume it knows better then whatever set that policy.... > > I think this is the right approach. Rather than add ways for IKE to > do things not stated in the policy, let's have recommendations about > what the policies should be able to express. That's a better solution > because it satiesfies the "principle of least astonishment". > > In other words, > a. IKE should negotiate exactly according to the policy it has been > given. > b. Implementation should be encouraged to implement policies of the > form "accept exactly X" as well as "accept X or stronger". The spec > should give some examples of what "X or stronger" means. > > I believe this should satisfy both sides, because it allows and > encourages negotiating up, without allowing negotiating up when it > goes against the expressed policies. > > paul From owner-ipsec@lists.tislabs.com Thu Jun 10 12:18:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11106; Thu, 10 Jun 1999 12:18:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29817 Thu, 10 Jun 1999 13:05:52 -0400 (EDT) Date: Thu, 10 Jun 1999 13:14:44 -0400 Message-Id: <199906101714.NAA03902@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David_Mason@nai.com Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <447A3F40A07FD211BA2700A0C99D759B05D099@md-exchange1.nai.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mason," == Mason, David writes: Mason,> I would like to see the following: For any symmetric ciphers Mason,> where there is negligible differences in memory consumption Mason,> and performance overhead between key lengths, the ID/RFC that Mason,> explains how the cipher is negotiated via IKE (transform ID, Mason,> etc) MUST state that only the maximum key length is used (no Mason,> key length attribute). Mason,> If this was the case, "negotiating up" for these ciphers Mason,> would no longer be an issue. That seems reasonable. One issue I can see is backwards compatibility. Currently such ciphers must have the keylength attribute present; the change you're proposing means that it must be absent. A less disruptive way would be to require it to be present but set to the max value. Even then you may run into trouble if the other end is an older implementation that supports several lengths but not the max length. (Don't know if this is common but it is currently legal.) Mason,> For security attributes that have performance/security Mason,> tradeoffs, security gateway administrators will most likely Mason,> want the policy that they configure to be enforced Mason,> (hypothetically - they wouldn't want a policy that says PFS Mason,> off being "negotiated up" to 2048-bit DH for 1000 Mason,> simultaneous SA negotiations). If an administrator wants to Mason,> allow "negotiation up" he would configure it that way and all Mason,> combinations for a security attribute of value X and greater Mason,> would be offered and allowed (but then that wouldn't be Mason,> "negotiate up"). Are you saying that you would simply generate N proposals with the N possible values of the parameter? That sounds problematic. For example, RC4 has a keysize 40 to 256 or so, which means N is 217... Also, if you have a (hypothetical) variable length authentication transform, you'd end up with N*M proposals. I'd rather have an explicit "negotiate up" policy. paul From owner-ipsec@lists.tislabs.com Thu Jun 10 12:36:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11255; Thu, 10 Jun 1999 12:36:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29988 Thu, 10 Jun 1999 13:44:54 -0400 (EDT) Date: Thu, 10 Jun 1999 10:49:09 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: RE: NAT and IPSEC INCOMPATIBLE??? To: "'ipsec'" In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDFB114A7@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk there's also the rsip extension for e2e ipsec from the nat wg: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-00.txt other rsip drafts: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-framework-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-protocol-01.txt -gabriel From owner-ipsec@lists.tislabs.com Thu Jun 10 12:36:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11266; Thu, 10 Jun 1999 12:36:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29954 Thu, 10 Jun 1999 13:34:36 -0400 (EDT) Date: Thu, 10 Jun 1999 10:43:49 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: Dan McDonald Cc: Pat.Calhoun@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: "Your message with ID" <199906101740.KAA11513@kebe.Eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And just to make matters worse, I could not have anyone connect directly to me thanks to NAT (i.e. ftp, SIP, etc). PatC > > > By the way, there are certain markets where NAT is a requirement (such as > > > running IP to the guest rooms in hotels) > > Until the hotels get more customers like Pat, who say that... > > > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > > for? If they are looking for the commuter, then NAT is a bad thing since I > > will want to encrypt my data back to my corporate network. > > And by then they'll be looking for another alternative. > > > > and IPSec is also extremely high profile. It would help everyone out if > > > there was a built-in method to scale arbitarily > > > large for address translated IPSec connections - just with ESP, I don't > > > think that AH is as important to these users. > > And that alternative is IPv6. ESP works just fine over that. > > Dan From owner-ipsec@lists.tislabs.com Thu Jun 10 12:39:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11303; Thu, 10 Jun 1999 12:39:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29930 Thu, 10 Jun 1999 13:31:14 -0400 (EDT) From: Dan McDonald Message-Id: <199906101740.KAA11513@kebe.Eng.Sun.COM> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: Pat.Calhoun@Eng.Sun.Com Date: Thu, 10 Jun 1999 10:40:11 -0700 (PDT) Cc: johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: from "pcalhoun@eng.sun.com" at Jun 10, 99 07:33:50 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > By the way, there are certain markets where NAT is a requirement (such as > > running IP to the guest rooms in hotels) Until the hotels get more customers like Pat, who say that... > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > for? If they are looking for the commuter, then NAT is a bad thing since I > will want to encrypt my data back to my corporate network. And by then they'll be looking for another alternative. > > and IPSec is also extremely high profile. It would help everyone out if > > there was a built-in method to scale arbitarily > > large for address translated IPSec connections - just with ESP, I don't > > think that AH is as important to these users. And that alternative is IPv6. ESP works just fine over that. Dan From owner-ipsec@lists.tislabs.com Thu Jun 10 13:14:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11850; Thu, 10 Jun 1999 13:14:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00053 Thu, 10 Jun 1999 14:08:28 -0400 (EDT) From: tcosenza@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com, "pcalhoun@eng.sun.com" Message-ID: <8525678C.006478BA.00@d54mta07.raleigh.ibm.com> Date: Thu, 10 Jun 1999 14:17:23 -0400 Subject: Re: NAT and IPSEC INCOMPATIBLE??? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mr. Thomas Cosenza Software Eng. IBM T/L 441-8782 "I always said that you can get more with a kind word and a two by four then you can get with a kind word", Marcus B5 "pcalhoun@eng.sun.com" To: Dan McDonald cc: Pat.Calhoun@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com (bcc: Thomas Cosenza/Raleigh/IBM) Subject: Re: NAT and IPSEC INCOMPATIBLE??? And just to make matters worse, I could not have anyone connect directly to me thanks to NAT (i.e. ftp, SIP, etc). PatC > > > By the way, there are certain markets where NAT is a requirement (such as > > > running IP to the guest rooms in hotels) > > Until the hotels get more customers like Pat, who say that... > > > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > > for? If they are looking for the commuter, then NAT is a bad thing since I > > will want to encrypt my data back to my corporate network. > > And by then they'll be looking for another alternative. > > > > and IPSec is also extremely high profile. It would help everyone out if > > > there was a built-in method to scale arbitarily > > > large for address translated IPSec connections - just with ESP, I don't > > > think that AH is as important to these users. > > And that alternative is IPv6. ESP works just fine over that. > Could you not use ESP with an authentication alg if you wanted to make sure where the packet came from. Thomas From owner-ipsec@lists.tislabs.com Thu Jun 10 13:53:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA12283; Thu, 10 Jun 1999 13:53:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00278 Thu, 10 Jun 1999 14:54:43 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199906101903.MAA07348@kc.livingston.com> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: Pat.Calhoun@Eng.Sun.Com Date: Thu, 10 Jun 1999 12:03:10 -0700 (PDT) Cc: danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: from "pcalhoun@eng.sun.com" at Jun 10, 99 10:43:49 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pat, The accessability provided by NAPT (Network Address Port Translator) is not any less than the accessibility provided by a host with a single address. Further, Bidirectional-NAT does not preclude inbound connections. It simply does address multiplexing - optimal use of limited addresses available. I suggest you take a look at prior to spreading misinformation. cheers, suresh > > And just to make matters worse, I could not have anyone connect directly to me > thanks to NAT (i.e. ftp, SIP, etc). > > PatC > > > > > By the way, there are certain markets where NAT is a requirement (such as > > > > running IP to the guest rooms in hotels) > > > > Until the hotels get more customers like Pat, who say that... > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > > > for? If they are looking for the commuter, then NAT is a bad thing since I > > > will want to encrypt my data back to my corporate network. > > > > And by then they'll be looking for another alternative. > > > > > > and IPSec is also extremely high profile. It would help everyone out if > > > > there was a built-in method to scale arbitarily > > > > large for address translated IPSec connections - just with ESP, I don't > > > > think that AH is as important to these users. > > > > And that alternative is IPv6. ESP works just fine over that. > > > > Dan > > > From owner-ipsec@lists.tislabs.com Thu Jun 10 14:03:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12396; Thu, 10 Jun 1999 14:03:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00327 Thu, 10 Jun 1999 15:02:40 -0400 (EDT) Date: Thu, 10 Jun 1999 12:11:43 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: Pyda Srisuresh Cc: Pat.Calhoun@Eng.Sun.Com, danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: "Your message with ID" <199906101903.MAA07348@kc.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk agreed, but my comment was directed to the use of NAT in hotels. It was not inteded to be IPSec specific. I had *assumed* that they were doing port translation (to conserve addresses). PatC > > Pat, > > The accessability provided by NAPT (Network Address Port Translator) > is not any less than the accessibility provided by a host with a > single address. > > Further, Bidirectional-NAT does not preclude inbound connections. > It simply does address multiplexing - optimal use of limited > addresses available. > > I suggest you take a look at > prior to spreading misinformation. > > cheers, > suresh > > > > > And just to make matters worse, I could not have anyone connect directly to me > > thanks to NAT (i.e. ftp, SIP, etc). > > > > PatC > > > > > > > By the way, there are certain markets where NAT is a requirement (such as > > > > > running IP to the guest rooms in hotels) > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > > > > for? If they are looking for the commuter, then NAT is a bad thing since I > > > > will want to encrypt my data back to my corporate network. > > > > > > And by then they'll be looking for another alternative. > > > > > > > > and IPSec is also extremely high profile. It would help everyone out if > > > > > there was a built-in method to scale arbitarily > > > > > large for address translated IPSec connections - just with ESP, I don't > > > > > think that AH is as important to these users. > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > Dan > > > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 10 14:42:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13064; Thu, 10 Jun 1999 14:42:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00470 Thu, 10 Jun 1999 15:25:07 -0400 (EDT) Date: Thu, 10 Jun 1999 22:34:03 +0300 (EET DST) Message-Id: <199906101934.WAA21577@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Ivars Suba Cc: ipsec@lists.tislabs.com Subject: RFC2409 In-Reply-To: <6078A04DA8A8D21189DD00A024B211101B9827@lasis.bank.lv> References: <6078A04DA8A8D21189DD00A024B211101B9827@lasis.bank.lv> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ivars Suba writes: > IPSec/IKE (RFC2409) Public Key Encryption Aggressive mode"(Phase 1) > vulnerability is myself advice. It seems that IPSec/IKE Public Key > Encryption Revised Aggressive Mode and IPSec/IKE Pre-Shared Key Aggressive > Mode also vulnerable to this type of attack (Chess grandmaster). However, > they will be stopped at Phase 2 - Quick Mode (ISAKMP payload is Encrypted). > If Initiator and Cheater will share DHPrivKey_i, they will continue this > attack against Responder in Phase 2 - Quick Mode still :). For more detailed > information look in appendice. How can the cheater convince the Initiator to use his public key instead of the responder? If the Initiator uses Responders public key the C cannot know the value of Ni, thus it cannot calcute the Hash payload, because the Ni is needed there. I don't think this "attack" would work. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jun 10 14:44:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13100; Thu, 10 Jun 1999 14:44:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00585 Thu, 10 Jun 1999 15:49:58 -0400 (EDT) To: "pcalhoun@eng.sun.com" Cc: Pyda Srisuresh , danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? References: From: Derek Atkins Date: 10 Jun 1999 15:45:25 -0400 In-Reply-To: "pcalhoun@eng.sun.com"'s message of Thu, 10 Jun 1999 12:11:43 -0700 (PDT) Message-Id: Lines: 76 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How can you do port address translation on known incoming ports? For example, what do I do if I need to get to port X on your host, which is sitting behind a NAT firewall? Obviously I don't know you're sitting behind a NAT gateway; how is the NAT gateway supposed to know that a packet coming to port X is destined for host Y or host Z, both of whom may be using these NAT-unfriendly protocols? And no, an answer of "don't use NAT-unfriendly protocols" is not a valid answer, as many of these protocols were developed years (or decades) before NAT. -derek "pcalhoun@eng.sun.com" writes: > > agreed, but my comment was directed to the use of NAT in hotels. It was not > inteded to be IPSec specific. I had *assumed* that they were doing port > translation (to conserve addresses). > > > PatC > > > > Pat, > > > > The accessability provided by NAPT (Network Address Port Translator) > > is not any less than the accessibility provided by a host with a > > single address. > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > It simply does address multiplexing - optimal use of limited > > addresses available. > > > > I suggest you take a look at > > prior to spreading misinformation. > > > > cheers, > > suresh > > > > > > > > And just to make matters worse, I could not have anyone connect directly to me > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > PatC > > > > > > > > > By the way, there are certain markets where NAT is a requirement (such as > > > > > > running IP to the guest rooms in hotels) > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are they looking > > > > > for? If they are looking for the commuter, then NAT is a bad thing since I > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > and IPSec is also extremely high profile. It would help everyone out if > > > > > > there was a built-in method to scale arbitarily > > > > > > large for address translated IPSec connections - just with ESP, I don't > > > > > > think that AH is as important to these users. > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > Dan > > > > > > > > > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 10 15:17:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13763; Thu, 10 Jun 1999 15:17:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00656 Thu, 10 Jun 1999 16:07:58 -0400 (EDT) Message-ID: <37601DD8.E0ACE6F4@seas.gwu.edu> Date: Thu, 10 Jun 1999 16:19:36 -0400 From: Cyberspace Policy Institute X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ietf-openpgp@imc.org, ietf-ssh@clinet.fi Subject: Growing Development of Foreign Encryption Products in the Face of U. S. Export Regulations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You may be interested in a report released June 10, 1999, entitled "Growing Development of Foreign Encryption Products in the Face of U. S. Export Regulations" by the Cyberspace Policy Institute of The George Washington University. The full report is at http://www.seas.gwu.edu/seas/institutes/cpi/library/docs/cpi-1999-02.pdf The executive summary follows: GROWING DEVELOPMENT OF FOREIGN ENCRYPTION PRODUCTS IN THE FACE OF U.S. EXPORT REGULATIONS Lance J. Hoffman* David M. Balenson** Karen A. Metivier-Carreiro* Anya Kim* Matthew G. Mundy** June 10, 1999 Report No. GWU-CPI-1999-02 http://www.seas.gwu.edu/seas/institutes/cpi/library/docs/cpi-1999-02.pdf *Cyberspace Policy Institute, School of Engineering and Applied Science, The George Washington University, Washington, DC **NAI Labs, The Security Research Division of Network Associates, Inc., Glenwood, MD EXECUTIVE SUMMARY Development of cryptographic products outside the United States is not only continuing but is expanding to additional countries; with rapid growth of the Internet, communications-related cryptography especially is experiencing high growth, especially in electronic mail, virtual private network, and IPsec products. This report surveys encryption products developed outside the United States and provides some information on the effect of the United States export control regime on American and foreign manufacturers. We have identified 805 hardware and/or software products incorporating cryptography manufactured in 35 countries outside the United States. The most foreign cryptographic products are manufactured in the United Kingdom, followed by Germany, Canada, Australia, Switzerland, Sweden, the Netherlands, and Israel in that order. Other countries accounted for slightly more than a quarter of the world's total of encryption products. A full summary listing of the foreign cryptographic products can be found in an appendix to the report. The 805 foreign cryptographic products represent a 149-product increase (22%) over the most recent previous survey in December 1997. A majority of the new foreign cryptographic products are software rather than hardware. Also, a majority of these new products are communications-oriented rather than data storage oriented; they heavily tend towards secure electronic mail, IP security (IPsec), and Virtual Private Network applications. We identified at least 167 foreign cryptographic products that use strong encryption in the form of these algorithms: Triple DES, IDEA, BLOWFISH, RC5, or CAST-128. Despite the increasing use of these stronger alternatives to DES, there also continues to be a large number of foreign products offering the use of DES, though we expect to see a decrease in coming years. New cryptography product manufacturers have appeared in six new countries since December 1997, and there has been a large increase in the number of products produced by certain countries. The new countries are Estonia, Iceland, Isle of Man, Romania, South Korea, and Turkey. The United Kingdom jumped by 20 products from 119 to 139, and Germany jumped from 76 products to 104. Also notable was Japan's increase, from six products to 18, and Mexico's, from a single product to six at the present time. We identified a total of 512 foreign companies that either manufacture or distribute foreign cryptographic products in at least 67 countries outside the United States. A full summary listing of these is given in an appendix to the report. On average, the quality of foreign and U. S. products is comparable. There are a number of very good foreign encryption products that are quite competitive in strength, standards compliance, and functionality. We present sketches of some representative competitors to U.S. manufacturers of software and hardware with encryption capabilities; all are developing products with strong encryption and have as customers a number of large foreign or multinational corporations. The specific companies highlighted are Baltimore Technologies, Brokat, Check Point, Data Fellows, Entrust, Radguard, Seguridata Privada, Sophos, and Utimaco. We found some examples of advertising used by non-U. S. companies that generally attempted to create a perception that purchasing American products may involve significant red tape and the encryption may not be strong due to export controls. This almost always appeared on Web sites. We observed that companies vie to have encryption products that meet certain accepted worldwide standards. Encryption experts from all over the world have contributed to two important international standards efforts, IPsec and the Advanced Encryption Standard.. Finally, we suggested that our empirical product data could be combined with economic measures and economic theories to better explain why we are seeing the observed growth and to examine the effects of Internet growth, e-commerce development, and regulatory actions on the international cryptographic market over time, thus getting better insights into the implications of various policy options. From owner-ipsec@lists.tislabs.com Thu Jun 10 15:29:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13846; Thu, 10 Jun 1999 15:29:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00772 Thu, 10 Jun 1999 16:40:23 -0400 (EDT) Message-Id: <199906102048.NAA26516@potassium.network-alchemy.com> To: Joe Tardo cc: "Derrell D. Piper" , Paul Koning , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Wed, 09 Jun 1999 17:48:50 PDT." <3.0.1.32.19990609174850.00e38b78@gateway.hq.freegate.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26513.929047734.1@network-alchemy.com> Date: Thu, 10 Jun 1999 13:48:54 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For the umpteenth time, no. Dan. On Wed, 09 Jun 1999 17:48:50 PDT you wrote > Suppose my policy is configured for NULL encryption, would this mean I MUST > encrypt if the offer proposes, say, 3DES first and NULL second? > > At 09:38 AM 6/3/99 -0700, Derrell D. Piper wrote: > >> So let me ask the entire working group: should vendors be prohibited fro >m > >> accepting a key length greater than what they have configured? Should they > >> be prohibited from accepting a stronger group? > > > >Absolutely not and I'd go so far as to make it a SHOULD instead of a MAY. > > > >We're trying to design good security, not workarounds for bad > implementations. > > > >Derrell > > > > From owner-ipsec@lists.tislabs.com Thu Jun 10 15:31:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13869; Thu, 10 Jun 1999 15:31:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00750 Thu, 10 Jun 1999 16:37:25 -0400 (EDT) Message-Id: <199906102045.NAA26501@potassium.network-alchemy.com> To: "Heyman, Michael" cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Thu, 03 Jun 1999 14:22:45 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26498.929047526.1@network-alchemy.com> Date: Thu, 10 Jun 1999 13:45:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I really miss Ran Atkinson. During a discussion on mandating support for secure DNS he said the following: "Hmm. Perhaps permit me to narrow those statements a bit to try to clarify something (mandating implementation support vs. mandating use) that periodically causes confusion within the IPsec WG. "The IETF requires that _implementations_ of IP also _implement_ support for DNS. The IETF does NOT require that users actually _USE_ DNS. Now most users DO use DNS because it is widely implemented and it is often easier to use than typing an IP number. However, on occasion users (e.g. me) don't use DNS and instead just type an IP number on the command line (e.g. "telnet 1.2.3.4") and this isn't violating any IETF requirement." So we can mandate the support for negotiating up things like key lengths but not require that it be done every single time. If someone wants to have a policy that says, "128 bits no more no less" then they are free to do that without violating any IETF requirements just as Ran (and you, and me) is free to type telnet 1.2.3.4 and not violate any IETF requirements. As I stated before, the text that is causing so many people problems is being rewritten and the word "policy" will not show up anywhere. No one is advocating overriding any policy. But the text said SHOULD. Some want MUST. So, keeping in mind the difference between mandating implementation support versus mandating use, what should it be? SHOULD or MUST? Is there a reason not to support this capability (again, keeping in mind the difference between mandating implementation support versus mandating use)? Dan. On Thu, 03 Jun 1999 14:22:45 PDT you wrote > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > > Sent: Thursday, June 03, 1999 12:39 PM > > > > > So let me ask the entire working group: should vendors > > > be prohibited from accepting a key length greater than > > > what they have configured? Should they be prohibited from > > > accepting a stronger group? > > > > Absolutely not and I'd go so far as to make it a SHOULD > > instead of a MAY. > > > > We're trying to design good security, not workarounds for bad > > implementations. > > > Hmmm, this means if a policy _explicitly_ states 128 bit encryption > (note, the policy _did not_ state 128 bit encryption or greater), > then IKE has the right to change the policy to be 128 bit or greater? > > IMHO, IKE must act dumb when it comes to policy and must not assume > it knows better then whatever set that policy. Here we seem to be > arguing that good security is allowing stronger encryption even when > stronger encryption is precluded by the policy. I would argue that > good security offers no such surprises. > > I can imagine applications that may not want to manage, or be capable > of managing, the extra 320 bits (above 128) possible in in Blowfish. > I can imagine machines not wishing to do the extra work required of a > stronger group. > > > > - -Michael Heyman From owner-ipsec@lists.tislabs.com Thu Jun 10 16:26:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14303; Thu, 10 Jun 1999 16:26:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01071 Thu, 10 Jun 1999 17:42:44 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 10 Jun 1999 15:51:10 -0600 From: "Hilarie Orman" To: , Subject: Re: RFC2409 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA01068 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't understand what the attack is, I'm sorry. It appears that both the Initiator and Responder believe that they are talking to the cheater, so what is failure? If the Initiator and Cheater are collaborators, then can share signing keys as easily as decryption keys, so the "fix" doesn't make sense to me, either. It's possible that there is a flaw, given that the two sides don't ever prove that they can compute the shared key, but I don't exactly see what's wrong. Please explain. Hilarie From owner-ipsec@lists.tislabs.com Thu Jun 10 16:26:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14311; Thu, 10 Jun 1999 16:26:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01032 Thu, 10 Jun 1999 17:30:18 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D09C@md-exchange1.nai.com> From: "Mason, David" To: "'Dan Harkins'" , "Heyman, Michael" Cc: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Thu, 10 Jun 1999 14:35:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I vote for MAY :) -dave > -----Original Message----- > From: Dan Harkins [SMTP:dharkins@network-alchemy.com] > Sent: Thursday, June 10, 1999 4:45 PM > To: Heyman, Michael > Cc: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > I really miss Ran Atkinson. During a discussion on mandating support > for secure DNS he said the following: > > "Hmm. Perhaps permit me to narrow those statements a bit to try to > clarify > something (mandating implementation support vs. mandating use) that > periodically causes confusion within the IPsec WG. > > "The IETF requires that _implementations_ of IP also _implement_ > support for > DNS. The IETF does NOT require that users actually _USE_ DNS. Now > most > users DO use DNS because it is widely implemented and it is often > easier to > use than typing an IP number. However, on occasion users (e.g. me) > don't > use DNS and instead just type an IP number on the command line (e.g. > "telnet 1.2.3.4") and this isn't violating any IETF requirement." > > So we can mandate the support for negotiating up things like key lengths > but > not require that it be done every single time. If someone wants to have a > policy that says, "128 bits no more no less" then they are free to do that > without violating any IETF requirements just as Ran (and you, and me) is > free > to type telnet 1.2.3.4 and not violate any IETF requirements. > > As I stated before, the text that is causing so many people problems is > being > rewritten and the word "policy" will not show up anywhere. No one is > advocating > overriding any policy. But the text said SHOULD. Some want MUST. So, > keeping > in mind the difference between mandating implementation support versus > mandating use, what should it be? SHOULD or MUST? Is there a reason not to > support this capability (again, keeping in mind the difference between > mandating implementation support versus mandating use)? > > Dan. > > On Thu, 03 Jun 1999 14:22:45 PDT you wrote > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > > > Sent: Thursday, June 03, 1999 12:39 PM > > > > > > > So let me ask the entire working group: should vendors > > > > be prohibited from accepting a key length greater than > > > > what they have configured? Should they be prohibited from > > > > accepting a stronger group? > > > > > > Absolutely not and I'd go so far as to make it a SHOULD > > > instead of a MAY. > > > > > > We're trying to design good security, not workarounds for bad > > > implementations. > > > > > Hmmm, this means if a policy _explicitly_ states 128 bit encryption > > (note, the policy _did not_ state 128 bit encryption or greater), > > then IKE has the right to change the policy to be 128 bit or greater? > > > > IMHO, IKE must act dumb when it comes to policy and must not assume > > it knows better then whatever set that policy. Here we seem to be > > arguing that good security is allowing stronger encryption even when > > stronger encryption is precluded by the policy. I would argue that > > good security offers no such surprises. > > > > I can imagine applications that may not want to manage, or be capable > > of managing, the extra 320 bits (above 128) possible in in Blowfish. > > I can imagine machines not wishing to do the extra work required of a > > stronger group. > > > > > > > > - -Michael Heyman From owner-ipsec@lists.tislabs.com Thu Jun 10 16:50:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14504; Thu, 10 Jun 1999 16:50:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01223 Thu, 10 Jun 1999 18:06:33 -0400 (EDT) Date: Thu, 10 Jun 1999 18:15:35 -0400 Message-Id: <199906102215.SAA07218@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906102045.NAA26501@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> ... Dan> So we can mandate the support for negotiating up things like key Dan> lengths but not require that it be done every single time. If Dan> someone wants to have a policy that says, "128 bits no more no Dan> less" then they are free to do that without violating any IETF Dan> requirements just as Ran (and you, and me) is free to type Dan> telnet 1.2.3.4 and not violate any IETF requirements. Sounds good. What wasn't clear before was whether you were proposing to require a capability to ask that X be done, or requiring that X be done (always). The DNS analogy helps. Dan> As I stated before, the text that is causing so many people Dan> problems is being rewritten and the word "policy" will not show Dan> up anywhere. No one is advocating overriding any policy. But the Dan> text said SHOULD. Some want MUST. So, keeping in mind the Dan> difference between mandating implementation support versus Dan> mandating use, what should it be? SHOULD or MUST? Is there a Dan> reason not to support this capability (again, keeping in mind Dan> the difference between mandating implementation support versus Dan> mandating use)? The rewrite should be useful, because clearly the previous version was causing confusion. I'm not entirely sure how you can state what you're proposing without using the word "policy", or equivalent circumlocutions. So the intent is: a. implementations should (must?) provide a way for the user to specify a policy of the form "128 bits or better". b. implementations may (should? must??) also provide a way for the user to specify a policy of the form "exactly 128 bits". If that's right, then fine -- and I'd prefer "should" and "may" respectively. And by the way, stating both (a) and (b) -- rather than only (a) -- would help make the intent clearer. paul From owner-ipsec@lists.tislabs.com Thu Jun 10 16:50:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14512; Thu, 10 Jun 1999 16:50:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01242 Thu, 10 Jun 1999 18:09:16 -0400 (EDT) Date: Thu, 10 Jun 1999 15:18:17 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: NAT and IPSEC INCOMPATIBLE??? To: Pakulski Krzysztof-LKP014 Cc: "pcalhoun@eng.sun.com" , "'Derek Atkins'" , Pyda Srisuresh , danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: "Your message with ID" <61CD66E671E4D211A19A00A0C978B0DC1213BA@ont15exch1.ont.isg.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I believe that one of the possibilities to make static binding. > > If something comes to port X on NAT gateway, it is forwarded to port Y on > host Z, if policy allowes that. So is this a service that the hotel registration handles as well as wake up calls? :) PatC > > Krzysztof > > ---------- > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > Sent: Thursday, June 10, 1999 3:45 PM > > To: pcalhoun@eng.sun.com > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > ipsec@lists.tislabs.com > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > How can you do port address translation on known incoming ports? For > > example, what do I do if I need to get to port X on your host, which > > is sitting behind a NAT firewall? Obviously I don't know you're > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > that a packet coming to port X is destined for host Y or host Z, both > > of whom may be using these NAT-unfriendly protocols? > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > valid answer, as many of these protocols were developed years (or > > decades) before NAT. > > > > -derek > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > not > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > translation (to conserve addresses). > > > > > > > > > PatC > > > > > > > > Pat, > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > is not any less than the accessibility provided by a host with a > > > > single address. > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > It simply does address multiplexing - optimal use of limited > > > > addresses available. > > > > > > > > I suggest you take a look at > > > > prior to spreading misinformation. > > > > > > > > cheers, > > > > suresh > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > directly to me > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > PatC > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > requirement (such as > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > they looking > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > thing since I > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > everyone out if > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > large for address translated IPSec connections - just with > > ESP, I don't > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > From owner-ipsec@lists.tislabs.com Thu Jun 10 17:06:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14752; Thu, 10 Jun 1999 17:06:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01287 Thu, 10 Jun 1999 18:20:28 -0400 (EDT) To: Pakulski Krzysztof-LKP014 Cc: "pcalhoun@eng.sun.com" , Pyda Srisuresh , danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? References: <61CD66E671E4D211A19A00A0C978B0DC1213BA@ont15exch1.ont.isg.mot.com> From: Derek Atkins Date: 10 Jun 1999 18:20:42 -0400 In-Reply-To: Pakulski Krzysztof-LKP014's message of Thu, 10 Jun 1999 16:25:43 -0400 Message-Id: Lines: 115 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me repeat my question: If a packet comes in on port X on the NAT gateway, how do you know whether the packet really goes to port X on host Y or port X on host Z? Remember, this is a protocol with a known port (port X)... It ALWAYS sits on port X. So, how do you address "port X on host Y" when "host Y" is behind a NAT gateway? -derek Pakulski Krzysztof-LKP014 writes: > > I believe that one of the possibilities to make static binding. > > If something comes to port X on NAT gateway, it is forwarded to port Y on > host Z, if policy allowes that. > > Krzysztof > > ---------- > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > Sent: Thursday, June 10, 1999 3:45 PM > > To: pcalhoun@eng.sun.com > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > ipsec@lists.tislabs.com > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > How can you do port address translation on known incoming ports? For > > example, what do I do if I need to get to port X on your host, which > > is sitting behind a NAT firewall? Obviously I don't know you're > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > that a packet coming to port X is destined for host Y or host Z, both > > of whom may be using these NAT-unfriendly protocols? > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > valid answer, as many of these protocols were developed years (or > > decades) before NAT. > > > > -derek > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > not > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > translation (to conserve addresses). > > > > > > > > > PatC > > > > > > > > Pat, > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > is not any less than the accessibility provided by a host with a > > > > single address. > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > It simply does address multiplexing - optimal use of limited > > > > addresses available. > > > > > > > > I suggest you take a look at > > > > prior to spreading misinformation. > > > > > > > > cheers, > > > > suresh > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > directly to me > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > PatC > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > requirement (such as > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > they looking > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > thing since I > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > everyone out if > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > large for address translated IPSec connections - just with > > ESP, I don't > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 10 17:12:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14808; Thu, 10 Jun 1999 17:12:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01351 Thu, 10 Jun 1999 18:32:57 -0400 (EDT) Date: Thu, 10 Jun 1999 15:42:03 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: Derek Atkins Cc: Pakulski Krzysztof-LKP014 , "pcalhoun@eng.sun.com" , Pyda Srisuresh , danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Let me repeat my question: If a packet comes in on port X on the NAT > gateway, how do you know whether the packet really goes to port X on > host Y or port X on host Z? Remember, this is a protocol with a known > port (port X)... It ALWAYS sits on port X. So, how do you address > "port X on host Y" when "host Y" is behind a NAT gateway? Derek, That *is* the problem. Huge amounts of pre-configuration is necessary. I really doubt that the Hotel chains really understand the amount of administration required to deploy such a screwy scheme. PatC > > -derek > > Pakulski Krzysztof-LKP014 writes: > > > > > I believe that one of the possibilities to make static binding. > > > > If something comes to port X on NAT gateway, it is forwarded to port Y on > > host Z, if policy allowes that. > > > > Krzysztof > > > ---------- > > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > > Sent: Thursday, June 10, 1999 3:45 PM > > > To: pcalhoun@eng.sun.com > > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > > ipsec@lists.tislabs.com > > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > > > How can you do port address translation on known incoming ports? For > > > example, what do I do if I need to get to port X on your host, which > > > is sitting behind a NAT firewall? Obviously I don't know you're > > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > > that a packet coming to port X is destined for host Y or host Z, both > > > of whom may be using these NAT-unfriendly protocols? > > > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > > valid answer, as many of these protocols were developed years (or > > > decades) before NAT. > > > > > > -derek > > > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > > not > > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > > translation (to conserve addresses). > > > > > > > > > > > > PatC > > > > > > > > > > Pat, > > > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > > is not any less than the accessibility provided by a host with a > > > > > single address. > > > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > > It simply does address multiplexing - optimal use of limited > > > > > addresses available. > > > > > > > > > > I suggest you take a look at > > > > > prior to spreading misinformation. > > > > > > > > > > cheers, > > > > > suresh > > > > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > > directly to me > > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > > requirement (such as > > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > > they looking > > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > > thing since I > > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > > everyone out if > > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > > large for address translated IPSec connections - just with > > > ESP, I don't > > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 10 17:30:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14937; Thu, 10 Jun 1999 17:30:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01375 Thu, 10 Jun 1999 18:46:30 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199906102255.PAA02566@kc.livingston.com> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: warlord@MIT.EDU (Derek Atkins) Date: Thu, 10 Jun 1999 15:55:02 -0700 (PDT) Cc: Krzysztof_Pakulski-LKP014@email.mot.com, Pat.Calhoun@Eng.Sun.Com, suresh@livingston.com, danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: from "Derek Atkins" at Jun 10, 99 06:20:42 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me try to respond. I will assume, you are refering to a specific flavor of NAT, called Network Address Port Translator (NAPT). NAT is session-based and does not operate on a per-packet basis. I.e., once a session is permitted by NAT in a certain direction, packets flowing in either direction will undergo translation. So, I will further assume, you are refering to a new inbound session directed to a well-known TCP/UDP port on the NAPT device. Now, when a new session is initiated to port X on the NAPT device, the session will be directed, by default, to the NAPT. However, as Mr. Krzysztof pointed, it is possible to set up a static policy to redirect the session to a different host within the address realm supported by NAT. For example, if the NAT device does not have FAX service available on the box, it may be redirected to a host that does have it. cheers, suresh > > Let me repeat my question: If a packet comes in on port X on the NAT > gateway, how do you know whether the packet really goes to port X on > host Y or port X on host Z? Remember, this is a protocol with a known > port (port X)... It ALWAYS sits on port X. So, how do you address > "port X on host Y" when "host Y" is behind a NAT gateway? > > -derek > > Pakulski Krzysztof-LKP014 writes: > > > > > I believe that one of the possibilities to make static binding. > > > > If something comes to port X on NAT gateway, it is forwarded to port Y on > > host Z, if policy allowes that. > > > > Krzysztof > > > ---------- > > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > > Sent: Thursday, June 10, 1999 3:45 PM > > > To: pcalhoun@eng.sun.com > > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > > ipsec@lists.tislabs.com > > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > > > How can you do port address translation on known incoming ports? For > > > example, what do I do if I need to get to port X on your host, which > > > is sitting behind a NAT firewall? Obviously I don't know you're > > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > > that a packet coming to port X is destined for host Y or host Z, both > > > of whom may be using these NAT-unfriendly protocols? > > > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > > valid answer, as many of these protocols were developed years (or > > > decades) before NAT. > > > > > > -derek > > > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > > not > > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > > translation (to conserve addresses). > > > > > > > > > > > > PatC > > > > > > > > > > Pat, > > > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > > is not any less than the accessibility provided by a host with a > > > > > single address. > > > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > > It simply does address multiplexing - optimal use of limited > > > > > addresses available. > > > > > > > > > > I suggest you take a look at > > > > > prior to spreading misinformation. > > > > > > > > > > cheers, > > > > > suresh > > > > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > > directly to me > > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > > requirement (such as > > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > > they looking > > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > > thing since I > > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > > everyone out if > > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > > large for address translated IPSec connections - just with > > > ESP, I don't > > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Thu Jun 10 17:37:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA15020; Thu, 10 Jun 1999 17:37:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01428 Thu, 10 Jun 1999 19:03:09 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 10 Jun 1999 17:11:31 -0600 From: "Hilarie Orman" To: , Cc: , , , , Subject: Re: NAT and IPSEC INCOMPATIBLE??? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA01425 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds like there are only two possibilities. Either all ports are unique on the incoming side P1 <-> P on host Y P2 <-> P on host Z or hosts fall into equivalence classes: P on hosts {Z, Y, W} is always the same service Hilarie >>> Derek Atkins 06/10/99 04:20PM >>> Let me repeat my question: If a packet comes in on port X on the NAT gateway, how do you know whether the packet really goes to port X on host Y or port X on host Z? Remember, this is a protocol with a known port (port X)... It ALWAYS sits on port X. So, how do you address "port X on host Y" when "host Y" is behind a NAT gateway? -derek Pakulski Krzysztof-LKP014 writes: > > I believe that one of the possibilities to make static binding. > > If something comes to port X on NAT gateway, it is forwarded to port Y on > host Z, if policy allowes that. > > Krzysztof > > ---------- > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > Sent: Thursday, June 10, 1999 3:45 PM > > To: pcalhoun@eng.sun.com > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > ipsec@lists.tislabs.com > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > How can you do port address translation on known incoming ports? For > > example, what do I do if I need to get to port X on your host, which > > is sitting behind a NAT firewall? Obviously I don't know you're > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > that a packet coming to port X is destined for host Y or host Z, both > > of whom may be using these NAT-unfriendly protocols? > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > valid answer, as many of these protocols were developed years (or > > decades) before NAT. > > > > -derek > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > not > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > translation (to conserve addresses). > > > > > > > > > PatC > > > > > > > > Pat, > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > is not any less than the accessibility provided by a host with a > > > > single address. > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > It simply does address multiplexing - optimal use of limited > > > > addresses available. > > > > > > > > I suggest you take a look at > > > > prior to spreading misinformation. > > > > > > > > cheers, > > > > suresh > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > directly to me > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > PatC > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > requirement (such as > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > they looking > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > thing since I > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > everyone out if > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > large for address translated IPSec connections - just with > > ESP, I don't > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 10 17:57:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA15192; Thu, 10 Jun 1999 17:57:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01404 Thu, 10 Jun 1999 18:56:41 -0400 (EDT) To: Pyda Srisuresh Cc: Krzysztof_Pakulski-LKP014@email.mot.com, Pat.Calhoun@Eng.Sun.Com, danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? References: <199906102255.PAA02566@kc.livingston.com> From: Derek Atkins Date: 10 Jun 1999 19:05:38 -0400 In-Reply-To: Pyda Srisuresh's message of Thu, 10 Jun 1999 15:55:02 -0700 (PDT) Message-Id: Lines: 156 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Which works fine provided you don't have multiple machines sitting behind the NAT gateway that all want to use that service. As I said, I know (and use) protocols where my (client) machine needs to be contacted on a standard port by a server. These protocols just fail under NAT. -derek Pyda Srisuresh writes: > > > Let me try to respond. I will assume, you are refering to a specific > flavor of NAT, called Network Address Port Translator (NAPT). > > NAT is session-based and does not operate on a per-packet basis. > I.e., once a session is permitted by NAT in a certain direction, > packets flowing in either direction will undergo translation. > So, I will further assume, you are refering to a new inbound > session directed to a well-known TCP/UDP port on the NAPT device. > > Now, when a new session is initiated to port X on the NAPT device, > the session will be directed, by default, to the NAPT. > However, as Mr. Krzysztof pointed, it is possible to set up a > static policy to redirect the session to a different host within > the address realm supported by NAT. For example, if the NAT device > does not have FAX service available on the box, it may be redirected > to a host that does have it. > > cheers, > suresh > > > > > Let me repeat my question: If a packet comes in on port X on the NAT > > gateway, how do you know whether the packet really goes to port X on > > host Y or port X on host Z? Remember, this is a protocol with a known > > port (port X)... It ALWAYS sits on port X. So, how do you address > > "port X on host Y" when "host Y" is behind a NAT gateway? > > > > -derek > > > > Pakulski Krzysztof-LKP014 writes: > > > > > > > > I believe that one of the possibilities to make static binding. > > > > > > If something comes to port X on NAT gateway, it is forwarded to port Y on > > > host Z, if policy allowes that. > > > > > > Krzysztof > > > > ---------- > > > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > > > Sent: Thursday, June 10, 1999 3:45 PM > > > > To: pcalhoun@eng.sun.com > > > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > > > ipsec@lists.tislabs.com > > > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > > > > > How can you do port address translation on known incoming ports? For > > > > example, what do I do if I need to get to port X on your host, which > > > > is sitting behind a NAT firewall? Obviously I don't know you're > > > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > > > that a packet coming to port X is destined for host Y or host Z, both > > > > of whom may be using these NAT-unfriendly protocols? > > > > > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > > > valid answer, as many of these protocols were developed years (or > > > > decades) before NAT. > > > > > > > > -derek > > > > > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > > > not > > > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > > > translation (to conserve addresses). > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > Pat, > > > > > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > > > is not any less than the accessibility provided by a host with a > > > > > > single address. > > > > > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > > > It simply does address multiplexing - optimal use of limited > > > > > > addresses available. > > > > > > > > > > > > I suggest you take a look at > > > > > > prior to spreading misinformation. > > > > > > > > > > > > cheers, > > > > > > suresh > > > > > > > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > > > directly to me > > > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > > > requirement (such as > > > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > > > they looking > > > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > > > thing since I > > > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > > > everyone out if > > > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > > > large for address translated IPSec connections - just with > > > > ESP, I don't > > > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > > Member, MIT Student Information Processing Board (SIPB) > > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > > warlord@MIT.EDU PGP key available > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 10 18:04:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15371; Thu, 10 Jun 1999 18:04:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01468 Thu, 10 Jun 1999 19:21:56 -0400 (EDT) Message-ID: <37604ABD.E072B495@redcreek.com> Date: Thu, 10 Jun 1999 16:31:09 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906102045.NAA26501@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > So we can mandate the support for negotiating up things like key lengths but > not require that it be done every single time. If someone wants to have a > policy that says, "128 bits no more no less" then they are free to do that > without violating any IETF requirements just as Ran (and you, and me) is free > to type telnet 1.2.3.4 and not violate any IETF requirements. > > As I stated before, the text that is causing so many people problems is being > rewritten and the word "policy" will not show up anywhere. No one is advocating > overriding any policy. But the text said SHOULD. Some want MUST. So, keeping > in mind the difference between mandating implementation support versus > mandating use, what should it be? SHOULD or MUST? Is there a reason not to > support this capability (again, keeping in mind the difference between > mandating implementation support versus mandating use)? > > Dan. Maybe part of the problem in this debate is related to another word that keeps cropping up, i.e. "mandate". I have a Webster in hand that lists the first definition for mandate as "1. an authoritative order or command, especially a written one". This has been part of what I viewed as problematic with this argument all along. In most cases, the appropriate behavior is specified by the policy we already support, and is permitted via the use of multiple proposals, e.g. (dh-1 OR dh-2 OR dh-5). The problem seems to be only with certain algorithms which permit variable key lengths (blowfish keeps coming up), and I have come around to agreeing that this case is not so cut-and-dried. Some have suggested a policy capability for specifying "accept keylength >= x", and this seems sensible, since the alternative is exhaustive enumeration in the proposals, which *I* sure don't want to parse. I think the point here is that we need a way to specify ranges somehow, i.e. up to x, x only, a <= x <= b, etc. I guess my bottom line is showing again: the admin needs to be able to control the behavior such that discovery of a weakness only requires reconfiguration, not an IKE patch, and such that if they want to limit strength for whatever reason, they can. It seems to me that this could be accomplished if there were key length attributes of some sort which allowed us to express such key length ranges in our proposals. Then, we could require as part of the spec that implementations support these attributes, subject of course to local policy. Scott From owner-ipsec@lists.tislabs.com Thu Jun 10 18:48:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15905; Thu, 10 Jun 1999 18:48:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01537 Thu, 10 Jun 1999 19:59:48 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199906110008.RAA15946@kc.livingston.com> Subject: Re: NAT and IPSEC INCOMPATIBLE??? To: warlord@MIT.EDU (Derek Atkins) Date: Thu, 10 Jun 1999 17:08:20 -0700 (PDT) Cc: suresh@livingston.com, Krzysztof_Pakulski-LKP014@email.mot.com, Pat.Calhoun@Eng.Sun.Com, danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com In-Reply-To: from "Derek Atkins" at Jun 10, 99 07:05:38 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Which works fine provided you don't have multiple machines sitting > behind the NAT gateway that all want to use that service. ^^^ You are right. It works fine so long as you dont have multiple machines, all wanting to OFFER the same service. This is no less than what a host with a single IP address can offer. But, multiple hosts in the private realm are able to access the same external service using the single IP address of the NAPT. That is the benefit that NAPT brings. > As I said, > I know (and use) protocols where my (client) machine needs to be > contacted on a standard port by a server. These protocols just fail > under NAT. In the protocols you refer to, the server knows its clients, ahead of time, by name (or unicast-IP address) and intitiates service by contacting the clients, right. This is reverse of the client-server concept as generally understood. Anyways, in such a case, NAPT is not the device to use. You need a bi-directional-NAT that has a pool of addresses in the external realm. NAPT is specifically designed for applications that can take advantage of port multiplexing. > > -derek > cheers, suresh > Pyda Srisuresh writes: > > > > > > > Let me try to respond. I will assume, you are refering to a specific > > flavor of NAT, called Network Address Port Translator (NAPT). > > > > NAT is session-based and does not operate on a per-packet basis. > > I.e., once a session is permitted by NAT in a certain direction, > > packets flowing in either direction will undergo translation. > > So, I will further assume, you are refering to a new inbound > > session directed to a well-known TCP/UDP port on the NAPT device. > > > > Now, when a new session is initiated to port X on the NAPT device, > > the session will be directed, by default, to the NAPT. > > However, as Mr. Krzysztof pointed, it is possible to set up a > > static policy to redirect the session to a different host within > > the address realm supported by NAT. For example, if the NAT device > > does not have FAX service available on the box, it may be redirected > > to a host that does have it. > > > > cheers, > > suresh > > > > > > > > Let me repeat my question: If a packet comes in on port X on the NAT > > > gateway, how do you know whether the packet really goes to port X on > > > host Y or port X on host Z? Remember, this is a protocol with a known > > > port (port X)... It ALWAYS sits on port X. So, how do you address > > > "port X on host Y" when "host Y" is behind a NAT gateway? > > > > > > -derek > > > > > > Pakulski Krzysztof-LKP014 writes: > > > > > > > > > > > I believe that one of the possibilities to make static binding. > > > > > > > > If something comes to port X on NAT gateway, it is forwarded to port Y on > > > > host Z, if policy allowes that. > > > > > > > > Krzysztof > > > > > ---------- > > > > > From: Derek Atkins[SMTP:warlord@MIT.EDU] > > > > > Sent: Thursday, June 10, 1999 3:45 PM > > > > > To: pcalhoun@eng.sun.com > > > > > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > > > > > ipsec@lists.tislabs.com > > > > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > > > > > > > How can you do port address translation on known incoming ports? For > > > > > example, what do I do if I need to get to port X on your host, which > > > > > is sitting behind a NAT firewall? Obviously I don't know you're > > > > > sitting behind a NAT gateway; how is the NAT gateway supposed to know > > > > > that a packet coming to port X is destined for host Y or host Z, both > > > > > of whom may be using these NAT-unfriendly protocols? > > > > > > > > > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > > > > > valid answer, as many of these protocols were developed years (or > > > > > decades) before NAT. > > > > > > > > > > -derek > > > > > > > > > > "pcalhoun@eng.sun.com" writes: > > > > > > > > > > > > > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > > > > > not > > > > > > inteded to be IPSec specific. I had *assumed* that they were doing port > > > > > > translation (to conserve addresses). > > > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > Pat, > > > > > > > > > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > > > > > is not any less than the accessibility provided by a host with a > > > > > > > single address. > > > > > > > > > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > > > > > It simply does address multiplexing - optimal use of limited > > > > > > > addresses available. > > > > > > > > > > > > > > I suggest you take a look at > > > > > > > prior to spreading misinformation. > > > > > > > > > > > > > > cheers, > > > > > > > suresh > > > > > > > > > > > > > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > > > > > directly to me > > > > > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > By the way, there are certain markets where NAT is a > > > > > requirement (such as > > > > > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > > > > > they looking > > > > > > > > > > for? If they are looking for the commuter, then NAT is a bad > > > > > thing since I > > > > > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > > > > > everyone out if > > > > > > > > > > > there was a built-in method to scale arbitarily > > > > > > > > > > > large for address translated IPSec connections - just with > > > > > ESP, I don't > > > > > > > > > > > think that AH is as important to these users. > > > > > > > > > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > > > Member, MIT Student Information Processing Board (SIPB) > > > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > > > warlord@MIT.EDU PGP key available > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > warlord@MIT.EDU PGP key available > > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Thu Jun 10 22:06:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02116; Thu, 10 Jun 1999 22:05:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01993 Thu, 10 Jun 1999 22:52:58 -0400 (EDT) Message-Id: <199906110301.UAA28999@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Thu, 10 Jun 1999 16:31:09 PDT." <37604ABD.E072B495@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28996.929070088.1@network-alchemy.com> Date: Thu, 10 Jun 1999 20:01:28 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 10 Jun 1999 16:31:09 PDT you wrote > Dan Harkins wrote: > > So we can mandate the support for negotiating up things like key lengths bu >t > > not require that it be done every single time. If someone wants to have a > > policy that says, "128 bits no more no less" then they are free to do that > > without violating any IETF requirements just as Ran (and you, and me) is fr >ee > > to type telnet 1.2.3.4 and not violate any IETF requirements. > > > > As I stated before, the text that is causing so many people problems is b >eing > > rewritten and the word "policy" will not show up anywhere. No one is advoca >ting > > overriding any policy. But the text said SHOULD. Some want MUST. So, keepin >g > > in mind the difference between mandating implementation support versus > > mandating use, what should it be? SHOULD or MUST? Is there a reason not to > > support this capability (again, keeping in mind the difference between > > mandating implementation support versus mandating use)? > > > > Dan. > > Maybe part of the problem in this debate is related to another word that > keeps cropping up, i.e. "mandate". I have a Webster in hand that lists > the first definition for mandate as "1. an authoritative order or > command, especially a written one". This has been part of what I viewed > as problematic with this argument all along. Look, we "mandate" support for manually keyed IPSec SAs. That doesn't mean that every single IPSec SA must've been manually created. Implementations are free to use key exchange protocols to dynamically establish SAs. Can't you see the difference between mandating support and mandating use? > In most cases, the appropriate behavior is specified by the policy we > already support, and is permitted via the use of multiple proposals, > e.g. (dh-1 OR dh-2 OR dh-5). The problem seems to be only with certain > algorithms which permit variable key lengths (blowfish keeps coming up), > and I have come around to agreeing that this case is not so > cut-and-dried. Some have suggested a policy capability for specifying > "accept keylength >= x", and this seems sensible, since the alternative > is exhaustive enumeration in the proposals, which *I* sure don't want to > parse. I think the point here is that we need a way to specify ranges > somehow, i.e. up to x, x only, a <= x <= b, etc. > > I guess my bottom line is showing again: the admin needs to be able to > control the behavior such that discovery of a weakness only requires > reconfiguration, not an IKE patch, and such that if they want to limit > strength for whatever reason, they can. It seems to me that this could > be accomplished if there were key length attributes of some sort which > allowed us to express such key length ranges in our proposals. Then, we > could require as part of the spec that implementations support these > attributes, subject of course to local policy. I guess I don't see how your bottom line is effected then since we're not talking about mandating use. "require...that implementations support these attributes subject...to local policy"? We're not talking about imposing a mandate on end users or on their policy, we're talking about imposing a mandate on implementors. This idea of a cipher becoming "weak" with longer keys is bizarre. Any cipher which supports a variable-length key that becomes weaker as the key becomes longer is a cipher with a fundamental problem and it should not be used period. There are always ridiculous, hypothetical, and unrealistic edge conditions (and a fictitious and fatally flawed cipher which some admin insists on using is a prime example) but focusing on them only confounds the issue. The issue at hand is whether to impose a requirement on implementations to support negotiating up certain attributes. It is not (and let me say again, IT IS NOT!) whether end users must configure their boxes to do so. Dan. From owner-ipsec@lists.tislabs.com Fri Jun 11 01:58:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA04196; Fri, 11 Jun 1999 01:58:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03691 Fri, 11 Jun 1999 02:49:54 -0400 (EDT) Message-ID: <6078A04DA8A8D21189DD00A024B211101B982E@lasis.bank.lv> From: Ivars Suba To: "'kivinen@iki.fi'" , "'Hilarie Orman'" Cc: ipsec@lists.tislabs.com Subject: RE: RFC2409 Date: Fri, 11 Jun 1999 09:57:21 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="WINDOWS-1257" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The essence of attack is following: Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust Cheater(chess novice) and vice versa, however they don't trust each other. Grandmaster#1 and Grandmaster#2 are convicted that they play chess with novice and are surprised by novice's phenomenal chess proficiency, but have not understood that they actually play each other. In this type of attack novice play pipe role with some cryptographic transformations as decryption of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster public key and forwarding with KEi (KEr). Ivars < < How can the cheater convince the Initiator to use his public key < instead of the responder? If the Initiator uses Responders public key < the C cannot know the value of Ni, thus it cannot calcute the Hash < payload, because the Ni is needed there. I don't think this "attack" < would work. < -- < kivinen@iki.fi Work : +358-9-4354 3218 < SSH Communications Security http://www.ssh.fi/ < SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ < I don't understand what the attack is, I'm sorry. It appears that both the Initiator and Responder believe that they are talking to the cheater, so what is failure? If the Initiator and Cheater are collaborators, then can share signing keys as easily as decryption keys, so the "fix" doesn't make sense to me, either. It's possible that there is a flaw, given that the two sides don't ever prove that they can compute the shared key, but I don't exactly see what's wrong. Please explain. Hilarie From owner-ipsec@lists.tislabs.com Fri Jun 11 04:33:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA07449; Fri, 11 Jun 1999 04:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA04183 Fri, 11 Jun 1999 05:29:35 -0400 (EDT) Date: Fri, 11 Jun 1999 12:38:21 +0300 (IDT) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: Ivars Suba cc: "'kivinen@iki.fi'" , "'Hilarie Orman'" , ipsec@lists.tislabs.com Subject: RE: RFC2409 In-Reply-To: <6078A04DA8A8D21189DD00A024B211101B982E@lasis.bank.lv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As pointed out already by Hilarie and Tero there is no attack here. When you exchange a key with a "cheater" C then you can not guarantee that the key is not known to other people as C can always tell his friends the value of the key... In this case, both I and R which are good guys end their protocols convinced that they talked to C (as it was the case). The only "problem" is that they don't know that there is a third party (R and I, respectively) that knows the key, but as said this is something C can always do (and with less effort). Hilarie mentioned the lack of "explicit confirmation" of the exchanged key. This is not needed here since the KEi values are fully authenticated. A party following the protocol will always know the key evn if it does not explicitly proves that to the other party (the proof is implicit in the security proof of the protocol). Hugo On Fri, 11 Jun 1999, Ivars Suba wrote: > The essence of attack is following: > Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust > Cheater(chess novice) and vice versa, however they don't trust each other. > Grandmaster#1 and Grandmaster#2 are convicted that they play chess with > novice and are surprised by novice's phenomenal chess proficiency, but have > not understood that they actually play each other. In this type of attack > novice play pipe role with some cryptographic transformations as decryption > of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster > public key and forwarding with KEi (KEr). > > Ivars > > < > < How can the cheater convince the Initiator to use his public key > < instead of the responder? If the Initiator uses Responders public key > < the C cannot know the value of Ni, thus it cannot calcute the Hash > < payload, because the Ni is needed there. I don't think this "attack" > < would work. > < -- > < kivinen@iki.fi Work : +358-9-4354 3218 > < SSH Communications Security http://www.ssh.fi/ > < SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > < > > I don't understand what the attack is, I'm sorry. It appears > that both the Initiator and Responder believe that they > are talking to the cheater, so what is failure? If the > Initiator and Cheater are collaborators, then can share > signing keys as easily as decryption keys, so the "fix" > doesn't make sense to me, either. > > It's possible that there is a flaw, given that the two > sides don't ever prove that they can compute the shared key, > but I don't exactly see what's wrong. Please explain. > > > Hilarie > > From owner-ipsec@lists.tislabs.com Fri Jun 11 10:07:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA10124; Fri, 11 Jun 1999 10:07:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05060 Fri, 11 Jun 1999 10:49:47 -0400 (EDT) Date: Fri, 11 Jun 1999 10:53:50 -0400 Message-Id: <199906111453.KAA08621@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: IvarsS@bank.lv Cc: ipsec@lists.tislabs.com Subject: RE: RFC2409 References: <6078A04DA8A8D21189DD00A024B211101B982E@lasis.bank.lv> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ivars" == Ivars Suba writes: Ivars> The essence of attack is following: Initiator(chess Ivars> Grandmaster#1) and Responder(chess Grandmaster#2) trust Ivars> Cheater(chess novice) and vice versa, however they don't trust Ivars> each other. Grandmaster#1 and Grandmaster#2 are convicted Ivars> that they play chess with novice and are surprised by novice's Ivars> phenomenal chess proficiency, but have not understood that Ivars> they actually play each other. In this type of attack novice Ivars> play pipe role with some cryptographic transformations as Ivars> decryption of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) Ivars> with other's Grandmaster public key and forwarding with KEi Ivars> (KEr). But that's not a protocol flaw. If you trust X but X cheating, your trust is inappropriate. NO protocol can ever fix this. Analogous example: if you encrypt traffic to a friend for the purpose of keeping those messages confidential, but your "friend" then posts the messages on alt.gossip, is that a protocol failure? No; you picked the wrong friends! paul From owner-ipsec@lists.tislabs.com Fri Jun 11 10:47:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA10557; Fri, 11 Jun 1999 10:47:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05216 Fri, 11 Jun 1999 11:49:31 -0400 (EDT) Message-ID: From: SMACGREG To: "'ipsec@lists.tislabs.com'" Cc: MFURUSAWA , SJUDY , cnguyen Subject: Date: Fri, 11 Jun 1999 08:57:55 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In reference to discussions made on the proposed draft, we will rename it and resubmit it as: draft-ietf-judy-skipjack-cbc-00.txt. In reference to the SKIPJACK implementation comments, the SKIPJACK algorithm and its cipher modes should be treated as separate items. Please review the SKIPJACK specification with its mode descritpions from NIST at http://www-08.nist.gov/cryptval/des/skipval.htm.. These modes (which are the same as the 4 DES modes) are described pictorially on page 3. [Schneier], and "Cryptography and Data Security" ISBN 0-201-10150-5 by Dorothy Denning also provides a detailed explanation of the modes. In reference to whether to use CBC mode not, NIST specifies two block cipher modes (CBC and ECB) and 2 stream modes for SKIPJACK and DES. In this draft, we propose ONLY the CBC mode. CBC mode is more resistant to cryptanalysis and replay. In ECB mode, there is no IV for messaging, only a cryptovariable key. The key is used to en/decrypt each data block with no chaining of any kind. ECB mode is more susceptible to plaintext attacks. We will be happy to submit a separate additional draft that specifically addresses ECB mode if this is desired. CBC mode is more resistant to the attacks mentioned and hence we have chosen to propose SKIPJACK with CBC mode. The next issue is of Explicit or Implicit IV. We chose an implicit IV because we thought it would provide more efficient transmission. However, the explicit IV does significantly assist the receiver in recovering from the effect of lost packets. If this method is more acceptable, we'll change the (newly named) draft to one with an Explicit IV. Scott Judy Sandra MacGregor From owner-ipsec@lists.tislabs.com Fri Jun 11 11:09:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10809; Fri, 11 Jun 1999 11:09:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05330 Fri, 11 Jun 1999 12:09:55 -0400 (EDT) Message-ID: <376136F7.DD7133C4@redcreek.com> Date: Fri, 11 Jun 1999 09:19:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) References: <199906110301.UAA28999@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, As a preliminary, I should say that I'm assuming that you now agree that the language in question must not apply to DH groups, ciphers (DES vs 3DES), MAC algorithms, etc, and that we are only discussing the case where a symmetric cipher has a variable key length. If that assumption is incorrect, please say so. Lots trimmed where context is not lost... Dan Harkins wrote: > Look, we "mandate" support for manually keyed IPSec SAs. That doesn't mean > that every single IPSec SA must've been manually created. Implementations > are free to use key exchange protocols to dynamically establish SAs. Can't > you see the difference between mandating support and mandating use? After re-reading my text and yours, I see that I muddled the issue. I was only referring to the earlier text (which you plan to change), so let's put this behind us and move on - my mistake. > > I guess my bottom line is showing again: the admin needs to be able to > > control the behavior such that discovery of a weakness only requires > > reconfiguration, not an IKE patch, and such that if they want to limit > > strength for whatever reason, they can. It seems to me that this could > > be accomplished if there were key length attributes of some sort which > > allowed us to express such key length ranges in our proposals. Then, we > > could require as part of the spec that implementations support these > > attributes, subject of course to local policy. > > I guess I don't see how your bottom line is effected then since we're > not talking about mandating use. "require...that implementations support > these attributes subject...to local policy"? We're not talking about > imposing a mandate on end users or on their policy, we're talking about > imposing a mandate on implementors. More on this below... > This idea of a cipher becoming "weak" with longer keys is bizarre. Any > cipher which supports a variable-length key that becomes weaker as the > key becomes longer is a cipher with a fundamental problem and it should > not be used period. There are always ridiculous, hypothetical, and > unrealistic edge conditions (and a fictitious and fatally flawed cipher > which some admin insists on using is a prime example) but focusing on > them only confounds the issue. The issue at hand is whether to impose > a requirement on implementations to support negotiating up certain > attributes. It is not (and let me say again, IT IS NOT!) whether end > users must configure their boxes to do so. I'm not a cryptographer (yet), and I assume you're not (yet) either. Let me know if this is an incorrect assumption. If I am correct, then we are both making assumptions regarding what could happen when key lengths are changed. That is, the idea of a weakness in a cipher at a certain key length may or may not be bizarre, and I guess we should ask the cryptographers. If it *is* a possibility, then we should allow that it is inappropriate for IKE to automatically accept larger key lengths. My intuitive feeling is that such behavior is incorrect in any event, but I am willing to suspend judgement for the moment. Even if we discover that this is not bizzare, and that such behavior is possible, we can still support the ability to negotiate up by simply adding a few other key length attributes. We currently support key rounds, key length, etc. We could add minimum key length and maximum key length attributes, with the following understanding: - the presence of only the key length attribute means "this length and this length only" - the presence of the minimum key length attribute alone means "at least this large, but larger is okay" - the presence of the minimum key length attribute along with the maximum key length attribute means min <= key length <= max, i.e. any key length within the range. - the presence of the key length attribute together with either or both of the others is an error While this adds a small amount of complexity to the attributes, it leaves the responsibility for the decision with the admin. Scott From owner-ipsec@lists.tislabs.com Fri Jun 11 11:49:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA11139; Fri, 11 Jun 1999 11:49:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05522 Fri, 11 Jun 1999 12:42:36 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Fri, 11 Jun 1999 12:44:43 -0400 To: SMACGREG From: Stephen Kent Subject: Re: Cc: "'ipsec@lists.tislabs.com'" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott and Sandy, Because of the unreliable nature of IP layer transmission, an explciit IV with CBC mode is really the right choice here. Steve From owner-ipsec@lists.tislabs.com Fri Jun 11 12:05:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11233; Fri, 11 Jun 1999 12:05:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05682 Fri, 11 Jun 1999 13:02:20 -0400 (EDT) Date: Fri, 11 Jun 1999 13:11:17 -0400 Message-Id: <199906111711.NAA08704@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smacgregor@myko.rainbow.com Cc: ipsec@lists.tislabs.com, MFURUSAWA@myko.rainbow.com, SJUDY@myko-md.rainbow.com, cnguyen@rainbow.com Subject: Re: References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You should take a look at RFC 2451. It already covers CBC in general. No need to discuss it all over again. All you should need is the incremental additions to that RFC to make it cover Skipjack, which is little more than the table entries covering key size, block size, etc., along with a reference to the cipher algorithm specification itself. Come to think of it -- should this sort of thing be done by the creation of a standalone document that accompanies RFC 2451, or a new document that supersedes RFC 2451 (containing all that was there before plus the new cipher)? If the latter, perhaps RFC 2405 could be folded into it as well, making things slightly less confusing. paul From owner-ipsec@lists.tislabs.com Fri Jun 11 13:23:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11929; Fri, 11 Jun 1999 13:23:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05868 Fri, 11 Jun 1999 14:01:38 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 11 Jun 1999 12:09:32 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: What's the attribute value for group generator (MODP) ? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA05865 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It was always my belief that group generator 1 was to be used for MODP groups. The second generator is used for EC groups, and only to specify the second coordinate of the generator. Hilarie From owner-ipsec@lists.tislabs.com Fri Jun 11 21:11:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA02949; Fri, 11 Jun 1999 21:11:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06832 Fri, 11 Jun 1999 22:16:07 -0400 (EDT) Message-ID: <9DBF3C44F94BD2119C4400105A16BC7F500BB3@MAILMAN> From: "Brothers, John" To: "'pcalhoun@eng.sun.com'" , "Brothers, John" Cc: ipsec@lists.tislabs.com Subject: RE: NAT and IPSEC INCOMPATIBLE??? Date: Thu, 10 Jun 1999 12:55:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No - you don't have to trust the hotel. The hotel can't see your data. You still get to encrypt all of your data. All they will change is the source IP address of outgoing packets (to the 'net), and the destination IP address of incoming packets. Is that not acceptable/reasonable? jb > -----Original Message----- > From: pcalhoun@eng.sun.com [SMTP:Pat.Calhoun@Eng.Sun.Com] > Sent: Thursday, June 10, 1999 10:34 AM > To: Brothers, John > Cc: ipsec@lists.tislabs.com > Subject: RE: NAT and IPSEC INCOMPATIBLE??? > > > Linux has a patch available that allows NAT to work with IPSec, as long > as > > AH is turned off. It isn't perfect, > > but it works quite well. > > > > ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html > > > > By the way, there are certain markets where NAT is a requirement (such > as > > running IP to the guest rooms in hotels) > > and IPSec is also extremely high profile. It would help everyone out > if > > there was a built-in method to scale arbitarily > > large for address translated IPSec connections - just with ESP, I don't > > think that AH is as important to these users. > > hmm... so I HAVE to trust my hotel? What kind of customers are they > looking > for? If they are looking for the commuter, then NAT is a bad thing since I > will want to encrypt my data back to my corporate network. > > PatC > > > > jb > > > > > -----Original Message----- > > > From: Tim Lyons [SMTP:tlyons@digitalvoodoo.org] > > > Sent: Thursday, June 10, 1999 12:20 AM > > > To: Makoto Kubota > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > > > Makoto, > > > > > > Your Scenario will work. > > > > > > --Tim > > > > > > > > > On Thu, 10 Jun 1999, Makoto Kubota wrote: > > > > > > > > > Looking at rfc1631 (NAT) and rfc2401 (IPSEC Overview) I have not > yet > > > > > > discovered a reason for conflict in using the two protocols > > > together. Just > > > > > > trying to understand if it is possible.....or if a IPSEC and NAT > are > > > just > > > > > > not made to function together. Specifics of the reason this > will or > > > won't > > > > > > work would be VERY much appreciated. > > > > > > > > > > Yep, NAT breaks IPSEC. > > > > > > > > > > NAT breaks any protocol which protects IP addresses from > modification. > > > > > AH's checksum includes these header fields, so that's one thing > which > > > > > breaks. > > > > > > > > Can I have additional question about this? > > > > > > > > So, if we do NAT before IPSEC, can I usr NAT & IPSec together? > > > > For example, > > > > Home Office ---[NAT]---[IPSec]--->Internet... > > > > Home Office <--[NAT]<--[IPSec]<---Internet... > > > > > > > > Thanks in advance. > > > > > From owner-ipsec@lists.tislabs.com Fri Jun 11 21:11:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA02965; Fri, 11 Jun 1999 21:11:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06899 Fri, 11 Jun 1999 22:21:06 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Fri, 11 Jun 1999 15:29:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B80ED1DB@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > In most cases, the appropriate behavior is specified by the > policy we > > already support, and is permitted via the use of multiple proposals, > > e.g. (dh-1 OR dh-2 OR dh-5). The problem seems to be only > with certain > > algorithms which permit variable key lengths (blowfish > keeps coming up), > > and I have come around to agreeing that this case is not so > > cut-and-dried. Some have suggested a policy capability for > specifying > > "accept keylength >= x", and this seems sensible, since the > alternative > > is exhaustive enumeration in the proposals, which *I* sure > don't want to > > parse. I think the point here is that we need a way to > specify ranges > > somehow, i.e. up to x, x only, a <= x <= b, etc. > > > > I guess my bottom line is showing again: the admin needs to > be able to > > control the behavior such that discovery of a weakness only requires > > reconfiguration, not an IKE patch, and such that if they > want to limit > > strength for whatever reason, they can. It seems to me that > this could > > be accomplished if there were key length attributes of some > sort which > > allowed us to express such key length ranges in our > proposals. Then, we > > could require as part of the spec that implementations support these > > attributes, subject of course to local policy. > > I guess I don't see how your bottom line is effected then since we're > not talking about mandating use. "require...that > implementations support > these attributes subject...to local policy"? We're not talking about > imposing a mandate on end users or on their policy, we're > talking about > imposing a mandate on implementors. > > This idea of a cipher becoming "weak" with longer keys is bizarre. Any > cipher which supports a variable-length key that becomes weaker as the > key becomes longer is a cipher with a fundamental problem and > it should > not be used period. There are always ridiculous, hypothetical, and > unrealistic edge conditions (and a fictitious and fatally > flawed cipher > which some admin insists on using is a prime example) but focusing on > them only confounds the issue. The issue at hand is whether to impose > a requirement on implementations to support negotiating up certain > attributes. It is not (and let me say again, IT IS NOT!) whether end > users must configure their boxes to do so. > > Dan. I think there is agreement that it is generally a good idea to negotiate up (though why would anyone specify shorter keys if there is no downside to specifying longer in the first place?). My only concern is that it increases the asymmetry of IKE. I think the disagreement is on whether it should be part of 'IKE' or 'Security Policy', where the latter is seen as something different to former. IKE specifies that you can only accept one of the proposed SAs unchanged. It is down to local security policy to decide which, if any, should be accepted. Thus this issue is the domain of the Security policy rather than IKE. The contra-view to your own is that security policy should be sufficiently expressive to allow the specification of both fixed values or ranges for key length. This would allow policy specification to be stated explicitly rather than being implicit in the IKE implementation (which may vary from implementor to implementor). Chris From owner-ipsec@lists.tislabs.com Fri Jun 11 21:11:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA02976; Fri, 11 Jun 1999 21:11:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06854 Fri, 11 Jun 1999 22:19:06 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: can ISAKMP cookies be zero? Date: Fri, 11 Jun 1999 11:18:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B80ED1D1@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think you've missed the point. Any process of generating tokens which is properly random will produce a value of 0 eventually (assuming it is U(0, 2**n)). A value of 0 is no more predictable than any other if this condition is met. The problem is that implementations are assuming a special cookie meaning for 0. This implies that (for completeness) any cookies should be tested for a zero value when they are generated and discarded if so. It's always possible that someone else will generate a cookie that you will accept - the important thing is that the probability of this is sufficiently low at to not present a threat. Chris > -----Original Message----- > From: Gabriel Montenegro [mailto:gab@Eng.Sun.Com] > Sent: 09 June 1999 01:12 > To: hugh@mimosa.com > Cc: IPsec List; John D. Hardin > Subject: Re: can ISAKMP cookies be zero? > > > > Are 0 cookies prohibited? If so, where? > > rfc's 2522 and 2408. > > > Does anyone think 0 cookies should be allowed? If not, how should > > this be legislated? > > well, they are only useful as anti-clogging tokens to reduce > off-the-path > denial-of-service attacks if they are unpredictable. a value of 0 does > not satisfy this. photuris (rfc2522.txt) spells out > the cookie generation requirements and isakmp (rfc2408.txt) echoes > them in section 2.5.3. i'd say a 0 cookie does not satisfy requirement > 2: > 2. It must not be possible for anyone other than the issuing > entity to generate cookies that will be accepted by that > entity. This implies that the issuing entity > must use local > secret information in the generation and subsequent > verification of a cookie. It must not be > possible to deduce > this secret information from any particular cookie. > > > > -gabriel > From owner-ipsec@lists.tislabs.com Fri Jun 11 21:12:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03012; Fri, 11 Jun 1999 21:12:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06915 Fri, 11 Jun 1999 22:22:06 -0400 (EDT) Message-ID: <61CD66E671E4D211A19A00A0C978B0DC1213BA@ont15exch1.ont.isg.mot.com> From: Pakulski Krzysztof-LKP014 To: "pcalhoun@eng.sun.com" , "'Derek Atkins'" Cc: Pyda Srisuresh , danmcd@Eng.Sun.Com, johnbr@elastic.com, ipsec@lists.tislabs.com Subject: RE: NAT and IPSEC INCOMPATIBLE??? Date: Thu, 10 Jun 1999 16:25:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that one of the possibilities to make static binding. If something comes to port X on NAT gateway, it is forwarded to port Y on host Z, if policy allowes that. Krzysztof > ---------- > From: Derek Atkins[SMTP:warlord@MIT.EDU] > Sent: Thursday, June 10, 1999 3:45 PM > To: pcalhoun@eng.sun.com > Cc: Pyda Srisuresh; danmcd@Eng.Sun.Com; johnbr@elastic.com; > ipsec@lists.tislabs.com > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > How can you do port address translation on known incoming ports? For > example, what do I do if I need to get to port X on your host, which > is sitting behind a NAT firewall? Obviously I don't know you're > sitting behind a NAT gateway; how is the NAT gateway supposed to know > that a packet coming to port X is destined for host Y or host Z, both > of whom may be using these NAT-unfriendly protocols? > > And no, an answer of "don't use NAT-unfriendly protocols" is not a > valid answer, as many of these protocols were developed years (or > decades) before NAT. > > -derek > > "pcalhoun@eng.sun.com" writes: > > > > > agreed, but my comment was directed to the use of NAT in hotels. It was > not > > inteded to be IPSec specific. I had *assumed* that they were doing port > > translation (to conserve addresses). > > > > > > PatC > > > > > > Pat, > > > > > > The accessability provided by NAPT (Network Address Port Translator) > > > is not any less than the accessibility provided by a host with a > > > single address. > > > > > > Further, Bidirectional-NAT does not preclude inbound connections. > > > It simply does address multiplexing - optimal use of limited > > > addresses available. > > > > > > I suggest you take a look at > > > prior to spreading misinformation. > > > > > > cheers, > > > suresh > > > > > > > > > > > And just to make matters worse, I could not have anyone connect > directly to me > > > > thanks to NAT (i.e. ftp, SIP, etc). > > > > > > > > PatC > > > > > > > > > > > By the way, there are certain markets where NAT is a > requirement (such as > > > > > > > running IP to the guest rooms in hotels) > > > > > > > > > > Until the hotels get more customers like Pat, who say that... > > > > > > > > > > > hmm... so I HAVE to trust my hotel? What kind of customers are > they looking > > > > > > for? If they are looking for the commuter, then NAT is a bad > thing since I > > > > > > will want to encrypt my data back to my corporate network. > > > > > > > > > > And by then they'll be looking for another alternative. > > > > > > > > > > > > and IPSec is also extremely high profile. It would help > everyone out if > > > > > > > there was a built-in method to scale arbitarily > > > > > > > large for address translated IPSec connections - just with > ESP, I don't > > > > > > > think that AH is as important to these users. > > > > > > > > > > And that alternative is IPv6. ESP works just fine over that. > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Fri Jun 11 21:18:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03365; Fri, 11 Jun 1999 21:18:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06845 Fri, 11 Jun 1999 22:18:08 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: NAT and IPSEC INCOMPATIBLE??? Date: Fri, 11 Jun 1999 11:03:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B80ED1CF@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.Com] > Sent: 10 June 1999 23:42 > To: Derek Atkins > Cc: Pakulski Krzysztof-LKP014; pcalhoun@eng.sun.com; Pyda Srisuresh; > danmcd@Eng.Sun.Com; johnbr@elastic.com; ipsec@lists.tislabs.com > Subject: Re: NAT and IPSEC INCOMPATIBLE??? > > > > Let me repeat my question: If a packet comes in on port X on the NAT > > gateway, how do you know whether the packet really goes to port X on > > host Y or port X on host Z? Remember, this is a protocol > with a known > > port (port X)... It ALWAYS sits on port X. So, how do you address > > "port X on host Y" when "host Y" is behind a NAT gateway? > > Derek, That *is* the problem. Huge amounts of > pre-configuration is necessary. > I really doubt that the Hotel chains really understand the amount of > administration required to deploy such a screwy scheme. > > PatC Even more of a problem when several hosts may be offering the same service on the same port. Last time this came up the idea of tunneling IP through to a third party was discussed. Thus NAT only mucks around with the outer header leaving the 'real' inner header intact. Chris From owner-ipsec@lists.tislabs.com Fri Jun 11 21:21:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03487; Fri, 11 Jun 1999 21:21:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06861 Fri, 11 Jun 1999 22:20:06 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: RFC2409 Date: Fri, 11 Jun 1999 13:50:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B80ED1D9@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: 11 June 1999 10:38 > To: Ivars Suba > Cc: 'kivinen@iki.fi'; 'Hilarie Orman'; ipsec@lists.tislabs.com > Subject: RE: RFC2409 > > > As pointed out already by Hilarie and Tero there is no > attack here. When you exchange a key with a "cheater" C then you > can not guarantee that the key is not known to other people > as C can always tell his friends the value of the key... > > In this case, both I and R which are good guys end their protocols > convinced that they talked to C (as it was the case). The > only "problem" > is that they don't know that there is a third party (R and I, > respectively) > that knows the key, but as said this is something C can always do (and > with less effort). > > Hilarie mentioned the lack of "explicit confirmation" of the exchanged > key. This is not needed here since the KEi values are fully > authenticated. > A party following the protocol will always know the key evn > if it does not > explicitly proves that to the other party (the proof is > implicit in the > security proof of the protocol). > > Hugo First off, I agree there is no attack. PKI relies on trust. C has breached trust. He may as well have just created a set of SA's with each party and forwarded the information between the two pipes. I think one of the more curious features of C's behaviour is that it doesn't actually yield the shared keys to him! Given that he just forwards the public KE between the parties, he won't actually be able to recreate the DH shared secret. If DSA were being used then the first phase wouldn't complete. As it is, they will be problems later, eg if AH is used... Chris From owner-ipsec@lists.tislabs.com Fri Jun 11 23:00:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA08259; Fri, 11 Jun 1999 23:00:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06844 Fri, 11 Jun 1999 22:18:08 -0400 (EDT) Message-Id: <199906110921.NAA13006@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Ivars Suba Date: Fri, 11 Jun 1999 13:21:26 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: RFC2409 CC: ipsec@lists.tislabs.com In-reply-to: <6078A04DA8A8D21189DD00A024B211101B982E@lasis.bank.lv> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 11 Jun 99 at 9:57, Ivars Suba wrote: > The essence of attack is following: > Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust > Cheater(chess novice) and vice versa, however they don't trust each other. > Grandmaster#1 and Grandmaster#2 are convicted that they play chess with > novice and are surprised by novice's phenomenal chess proficiency, but have > not understood that they actually play each other. In this type of attack > novice play pipe role with some cryptographic transformations as decryption > of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster > public key and forwarding with KEi (KEr). What benefits will gain Cheater playing such behaviour? Does this situation differ from one when we have 2 "legitimate" ISAKMP SA (one from Grandmaster#1 to Cheater and the other from Cheater to Grandmaster#2) and Cheater just plays the same pipe role? Valery Smyslov. > Ivars > > < > < How can the cheater convince the Initiator to use his public key > < instead of the responder? If the Initiator uses Responders public key > < the C cannot know the value of Ni, thus it cannot calcute the Hash > < payload, because the Ni is needed there. I don't think this "attack" > < would work. > < -- > < kivinen@iki.fi Work : +358-9-4354 3218 > < SSH Communications Security http://www.ssh.fi/ > < SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > < > > I don't understand what the attack is, I'm sorry. It appears > that both the Initiator and Responder believe that they > are talking to the cheater, so what is failure? If the > Initiator and Cheater are collaborators, then can share > signing keys as easily as decryption keys, so the "fix" > doesn't make sense to me, either. > > It's possible that there is a flaw, given that the two > sides don't ever prove that they can compute the shared key, > but I don't exactly see what's wrong. Please explain. > > > Hilarie > > From owner-ipsec@lists.tislabs.com Sat Jun 12 14:01:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24443; Sat, 12 Jun 1999 14:01:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08179 Sat, 12 Jun 1999 14:26:00 -0400 (EDT) Message-Id: <199906121834.OAA00919@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC INCOMPATIBLE??? In-Reply-To: Your message of "Fri, 11 Jun 1999 11:03:31 BST." <1FD60AE4DB6CD2118C420008C74C27B80ED1CF@baltimore.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 12 Jun 1999 14:34:59 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can see no reason for a hotel to use 1-1 address NAT. That gains them nothing if they are doing NAT to conserve IP address space. I can see a need for a nice protocol which would allow a hotel to request a new subnet from a larger block and then advertise it to their ISP. That would allow some hotel chain to purchase a block of addresses from a single ISP and have them allocated to the hotels that need them. That would significantly reduce the cost of provisioning IP addresses. While ESP can co-exist with NAPT provided that the NAPT understands how to map SPIs in/out, there are some more fundamental problems: 1. SPI collision 2. IKE session collision 3. IKE trust relationships (what does the cert contain?) 4. rekeying by "gateway" There has been a long discussion of this on the Linux-Ipsec (FreeSWAN) mailing list: http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/05/msg00293.html http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/03/msg00016.html http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1998/fall/msg00018.html :!mcr!: | Network and security consulting/contract programming Michael Richardson | ...working from my front lawn with a long cord... Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@lists.tislabs.com Sun Jun 13 08:18:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04829; Sun, 13 Jun 1999 08:18:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09166 Sun, 13 Jun 1999 09:09:12 -0400 (EDT) Date: Sun, 13 Jun 1999 16:18:11 +0300 (IDT) From: Hugo Krawczyk To: Valery Smyslov cc: Ivars Suba , ipsec@lists.tislabs.com Subject: RE: RFC2409 In-Reply-To: <199906110921.NAA13006@relay1.trustworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 11 Jun 1999, Valery Smyslov wrote: > On 11 Jun 99 at 9:57, Ivars Suba wrote: > > > The essence of attack is following: > > Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust > > Cheater(chess novice) and vice versa, however they don't trust each other. > > Grandmaster#1 and Grandmaster#2 are convicted that they play chess with > > novice and are surprised by novice's phenomenal chess proficiency, but have > > not understood that they actually play each other. In this type of attack > > novice play pipe role with some cryptographic transformations as decryption > > of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster > > public key and forwarding with KEi (KEr). > > What benefits will gain Cheater playing such behaviour? > > Does this situation differ from one when we have 2 "legitimate" > ISAKMP SA (one from Grandmaster#1 to Cheater and the other from > Cheater to Grandmaster#2) and Cheater just plays the same pipe role? > > Valery Smyslov. I think we all agree that there is no real attack here. On the other hand, the situation is NOT equivalent to what you describe above. If C would only be relaying messages between I and R then I would end thinking he exchanged the key with R, and R will thing she exchanged a key with I. In the scenario described by Ivars they both think they exchanged a key with C which is the correct belief. The fact that C does not know the key is C's problem (a cheater can always exchange a DH key using an exponent g^x for which C does not know x, it's his problem). Hugo From owner-ipsec@lists.tislabs.com Mon Jun 14 16:35:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26011; Mon, 14 Jun 1999 16:35:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12661 Mon, 14 Jun 1999 16:45:58 -0400 (EDT) Message-Id: <199906142054.QAA24869@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-Reply-To: Your message of "Sun, 06 Jun 1999 00:17:11 EDT." <3759F647.5B48EC89@sympatico.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Jun 1999 16:54:56 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sandy" == Sandy Harris writes: Sandy> My query would have been whether they should be prohibited from Sandy> REJECTING a key length greater than they've configured. Sandy> You configure for, say 128-bit Blowfish. I offer 448. The Sandy> algorithm costs no more to run with the longer key. Clearly you Sandy> SHOULD accept. I'd like to see the standard say you MUST accept. I think the text should say SHOULD. Despite Blowfish being able to do flexible key lengths, not all hardware may be configured to do that. :!mcr!: | Network and security consulting/contract programming Michael Richardson | ...working from my front lawn with a long cord... Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@lists.tislabs.com Mon Jun 14 16:51:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26183; Mon, 14 Jun 1999 16:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12786 Mon, 14 Jun 1999 17:50:56 -0400 (EDT) Reply-To: From: "Rob Adams" To: "Michael C. Richardson" , Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Mon, 14 Jun 1999 15:01:11 -0700 Message-ID: <002a01beb6b1$6a1b4030$0400000a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199906142054.QAA24869@istari.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have to agree with Michael. Since it costs no more to do 448bit than 128bit Blowfish, anyone who configures less than 448bits must have a reason. In the example below, there is no obvious cryptographic or computational reason for "you" to configure 128bit Blowfish. A reason that an organization might set the policy in such a manner could be that they can crack 128bit Blowfish and want to keep an eye on you. Or maybe there is some stupid reason like they use IDEA and want key escrow and have a broken system that can only store 128 bit keys. It doesn't really matter. The fact is, some authoritative administrator set the policy and an implementation should obey the policy. Leaving it a SHOULD allows the implementater to decide how it will behave. This leaves the door open for simple implementations that provide straight forward policy handling. It also allows for complex implementations that allow for "key length or greater" policies, along with the auditing systems to show administrators what key lengths users are accepting. Changing the wording to a MUST forces people to accept key lengths they may not want, for whatever reason. It also forces implementations wishing to provide their customers with authoritative policy control to "break" with the standard. I firmly believe the wording must remain a SHOULD. I also would not like to see another globally required policy knob that makes people choose between "I meant what I said" and "You figure it out." Implementations are already free to contain such things under the current wording. -Rob > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael C. Richardson > Sent: Monday, June 14, 1999 1:55 PM > To: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > > >>>>> "Sandy" == Sandy Harris writes: > Sandy> My query would have been whether they should be prohibited from > Sandy> REJECTING a key length greater than they've configured. > > Sandy> You configure for, say 128-bit Blowfish. I offer 448. The > Sandy> algorithm costs no more to run with the longer key. Clearly you > Sandy> SHOULD accept. I'd like to see the standard say you MUST accept. > > I think the text should say SHOULD. > Despite Blowfish being able to do flexible key lengths, not all hardware > may be configured to do that. > > :!mcr!: | Network and security consulting/contract programming > Michael Richardson | ...working from my front lawn with a long cord... > Personal: > http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > Corporate: http://www.sandelman.ottawa.on.ca/SSW/ > ON HUMILITY: To err is human, to moo bovine. > > > > > From owner-ipsec@lists.tislabs.com Mon Jun 14 16:51:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26198; Mon, 14 Jun 1999 16:51:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12770 Mon, 14 Jun 1999 17:46:03 -0400 (EDT) Date: Mon, 14 Jun 1999 17:48:48 -0400 (EDT) From: "David M. Balenson" Message-Id: <199906142148.RAA01867@clipper.gw.tislabs.com> To: ipsec@lists.tislabs.com Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Internet Society's Year 2000 Network and Distributed System Security Symposium (NDSS 2000) deadline for submissions of technical paper and panel proposals has been EXTENDED TO JUNE 23RD due to the large number of requests for an extension and the desire to accomodate people. The complete Call for Papers (CFP) is available at http://www.isoc.org/ndss2000/. Submissions are being accepted electronically at http://www.isi.edu/~ndss00. -David Balenson, NDSS 2000 Publicity Chair From owner-ipsec@lists.tislabs.com Mon Jun 14 17:07:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26341; Mon, 14 Jun 1999 17:07:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12827 Mon, 14 Jun 1999 18:01:06 -0400 (EDT) Message-Id: <199906142210.SAA25212@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-Reply-To: Your message of "Mon, 14 Jun 1999 15:01:11 PDT." <002a01beb6b1$6a1b4030$0400000a@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Jun 1999 18:10:16 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Rob" == Rob Adams writes: Rob> Changing the wording to a MUST forces people to accept key lengths Rob> they may not want, for whatever reason. It also forces Rob> implementations wishing to provide their customers with Rob> authoritative policy control to "break" with the standard. Rob> I firmly believe the wording must remain a SHOULD. I also would not Rob> like to see another globally required policy knob that makes people Rob> choose between "I meant what I said" and "You figure it out." We must all recall that SHOULD means: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Emphasis on "valid reasons". :!mcr!: | Network and security consulting/contract programming Michael Richardson | ...working from my front lawn with a long cord... Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@lists.tislabs.com Mon Jun 14 17:36:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26699; Mon, 14 Jun 1999 17:36:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12908 Mon, 14 Jun 1999 18:24:42 -0400 (EDT) Reply-To: From: "Rob Adams" To: "Michael C. Richardson" , Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long) Date: Mon, 14 Jun 1999 15:35:07 -0700 Message-ID: <002b01beb6b6$27524a00$0400000a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199906142210.SAA25212@istari.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay, how about "authoritative policy control is important to administrators," for a "valid reason". Otherwise, I'd argue to reduce it to a MAY. -Rob > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael C. Richardson > Sent: Monday, June 14, 1999 3:10 PM > To: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > > >>>>> "Rob" == Rob Adams writes: > Rob> Changing the wording to a MUST forces people to accept key lengths > Rob> they may not want, for whatever reason. It also forces > Rob> implementations wishing to provide their customers with > Rob> authoritative policy control to "break" with the standard. > > Rob> I firmly believe the wording must remain a SHOULD. I also would not > Rob> like to see another globally required policy knob that makes people > Rob> choose between "I meant what I said" and "You figure it out." > > We must all recall that SHOULD means: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Emphasis on "valid reasons". > > :!mcr!: | Network and security consulting/contract programming > Michael Richardson | ...working from my front lawn with a long cord... > Personal: > http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > Corporate: http://www.sandelman.ottawa.on.ca/SSW/ > ON HUMILITY: To err is human, to moo bovine. > > > From owner-ipsec@lists.tislabs.com Mon Jun 14 17:41:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26879; Mon, 14 Jun 1999 17:41:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12953 Mon, 14 Jun 1999 18:38:36 -0400 (EDT) Message-Id: <199906142247.SAA25345@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-Reply-To: Your message of "Mon, 14 Jun 1999 15:35:07 PDT." <002b01beb6b6$27524a00$0400000a@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Jun 1999 18:47:48 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Rob" == Rob Adams writes: Rob> Okay, how about "authoritative policy control is important to Rob> administrators," for a "valid reason". Otherwise, I'd argue to Rob> reduce it to a MAY. Sure. IMHO, The point is that SHOULD's ought to be implemented, and a knob provided to select the other behaviour. I MAY chose to implement a MAY or not. In the case of "my hardware doesn't do that" then there may be other options such as slower software. [as in my government won't let me export the hardware if it does that, but you can download a software version from www.myco-intl.com, but it will be slower, so the admin might like to avoid using the slower version gratuitiously] Now, which way the knob points by default is another question which is not our problem. :!mcr!: | Network and security consulting/contract programming Michael Richardson | ...working from my front lawn with a long cord... Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@lists.tislabs.com Mon Jun 14 17:48:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26960; Mon, 14 Jun 1999 17:48:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12987 Mon, 14 Jun 1999 18:45:13 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Tue, 15 Jun 1999 01:54:03 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-Reply-To: <199906142054.QAA24869@istari.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 14 Jun 1999, Michael C. Richardson wrote: > I think the text should say SHOULD. > Despite Blowfish being able to do flexible key lengths, not all hardware > may be configured to do that. Note that there may be unforeseeable complications. For example, what if by some strange reasons IDEA with independent subkeys happens to be actually weaker than the 128-bit IDEA? MUST is a bit too strong. Helger From owner-ipsec@lists.tislabs.com Mon Jun 14 18:41:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27573; Mon, 14 Jun 1999 18:41:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13086 Mon, 14 Jun 1999 19:28:19 -0400 (EDT) Message-Id: <199906142336.QAA20130@potassium.network-alchemy.com> To: adams@cisco.com cc: "Michael C. Richardson" , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) In-reply-to: Your message of "Mon, 14 Jun 1999 15:01:11 PDT." <002a01beb6b1$6a1b4030$0400000a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20127.929403386.1@network-alchemy.com> Date: Mon, 14 Jun 1999 16:36:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 14 Jun 1999 15:01:11 PDT you wrote > > Changing the wording to a MUST forces people to accept key lengths they may n >ot > want, for whatever reason. It also forces implementations wishing to provide > their customers with authoritative policy control to "break" with the standar >d. No it doesn't. This is the difference between mandating support vs mandating use. We don't mandate use. As I said earlier, we require that all IPSec implementations provide for manually keying SAs. That doesn't mean that all IPSec SAs have to be created manually. Dan. From owner-ipsec@lists.tislabs.com Tue Jun 15 09:08:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21339; Tue, 15 Jun 1999 09:08:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15206 Tue, 15 Jun 1999 09:52:00 -0400 (EDT) Message-ID: <002f01beb5c4$0a3649a0$75323ac3@elvis.ru> From: "Valery Smyslov" To: "Hugo Krawczyk" Cc: "Ivars Suba" , References: Subject: Re: RFC2409 Date: Sun, 13 Jun 1999 21:41:50 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sunday, June 13, Hugo Krawczyk wrote: > > Does this situation differ from one when we have 2 "legitimate" > > ISAKMP SA (one from Grandmaster#1 to Cheater and the other from > > Cheater to Grandmaster#2) and Cheater just plays the same pipe role? > > > > Valery Smyslov. > > I think we all agree that there is no real attack here. > On the other hand, the situation is NOT equivalent to > what you describe above. If C would only be relaying messages > between I and R then I would end thinking he exchanged the key > with R, and R will thing she exchanged a key with I. > In the scenario described by Ivars they both think they exchanged a key > with C which is the correct belief. The fact that C does not > know the key is C's problem (a cheater can always exchange a DH key > using an exponent g^x for which C does not know x, it's his problem). > > Hugo Hugo, thanks for clarification. I understand the difference between the scenario described by Ivars and just relaying all messages between I and R by C. I meant slightly different situation - when C has normal SAs with I and R and just forwards information between the two. You've already answered this question in your previous message to the list, thanks. List just works very slowly (at least in my case) - I've got my own message back from the list in 19 hours after it was sent - that's why your answer has appeared there before my question. But it seems to me that there is a small difference between Ivars's scenario and a simple case when C just tells his secret to somebody else. The difference is that in Ivars's scenario C has no ability to know what I and R are talking about after the first phase complete (assuming he continues "blind" forwarding messages to and fro). I don't know whether this is a "flaw", it looks more like a "feature", in fact, like three-party protocol when I and R don't know who are they really talking to (both think they are talking to C), and C does know it, but unable to get know what I and R are talking about. Am I missing something? Valery. From owner-ipsec@lists.tislabs.com Tue Jun 15 09:49:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22961; Tue, 15 Jun 1999 09:49:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15538 Tue, 15 Jun 1999 10:38:58 -0400 (EDT) Message-Id: <199906151447.KAA19370@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gupta-ipsec-remote-access-02.txt Date: Tue, 15 Jun 1999 10:47:03 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure, Remote Access over the Internet using IPSec Author(s) : V. Gupta Filename : draft-gupta-ipsec-remote-access-02.txt Pages : 18 Date : 14-Jun-99 This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt 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-gupta-ipsec-remote-access-02.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-gupta-ipsec-remote-access-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990614112446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-ipsec-remote-access-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-gupta-ipsec-remote-access-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990614112446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 15 11:46:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27242; Tue, 15 Jun 1999 11:46:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16222 Tue, 15 Jun 1999 12:32:56 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 15 Jun 1999 10:41:07 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: RFC2409 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA16219 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suppose you could call it a feature ... if you want a protocol that uses C as a trusted relay. C is trusted to start the game, to relay the messages, and not to read them. Later, I and R can get together and verify that they were using the proper shared key for their messages, and that is reason to believe that C behaved properly. So, if you want anonymous chess tournaments with verifiable results, this is your protocol. So let's change C's name to T, the Tournament Director. And I and R should be F and S (who could have hardly been anonymous to each other). Hilarie From owner-ipsec@lists.tislabs.com Tue Jun 15 14:53:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02370; Tue, 15 Jun 1999 14:53:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17074 Tue, 15 Jun 1999 15:45:57 -0400 (EDT) Message-Id: <199906151954.MAA21779@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: issues from the bakeoff MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21776.929476480.1@network-alchemy.com> Date: Tue, 15 Jun 1999 12:54:40 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was an IPSec + L2TP (and PPoE too) bakeoff the week of May 24th. As usual there were issues in interoperability that came up and I'm presenting them to the list. Not too surprisingly there were no issues with interoperability of the IPSec protocols, it's all IKE. Also there were several IPPCP issues that I'll summarize although they're being taken care of in a different working group in a different area. I'll mention the general consensus of people at the bakeoff but that's just as a starting point for discussion. The resolution (if any) of these issues is work for this group. Please comment to the list. thanks, Dan. -------------------------------------------------------------------------- *) The Commit Bit - Should this be mandatory for every single QM? The consensus was no. QM seems to behave fine when the commit bit is not set and the only difference is the small window of opportunity for packet loss. - There was a desire to weaken the requirement that if the bit is set by either party then it indicates the 4th message must be sent. It was proposed that if the peer didn't acknowledge the commit bit in the next message that the peer was not willing to do it. This didn't get too much support. - Does the bit have to be set in all messages after the first? That is not stated in the RFC and we've approached these issues in the past in an unsoviet-like manner: if it's not forbidden it's allowed. So, no it doesn't have to be. *) ID issues - Are all ISAKMP/DOI identities valid in phase 2? And can pre-shared keys be used with any ISAKMP/DOI identity? The DOI deals with phase 2 negotiation and the identities it defines are for phase 2. But the IKE and DOI authors agreed to include some text in their respective documents that clarified which identities are valid when. - How are subnet ids represented? Is 10.20.30.5/255.255.255.0 valid or does it have to be 10.20.30.0/255.255.255.0? The desire to use the former was because some extra information was being gleaned from the "5" by the implementation that did this. Since subnet identities are only used by intermediate networking devices it would seem to make sense to require subnet identities to be the same as any routing advertisement this device would make. Mentioning RFC1519 in the DOI would do the trick. Is this something that should be done? *) Lifetimes - What is The Right Thing (tm) to do when mismatched lifetimes are seen in phase 1 or phase 2? The DOI discusses what to do in phase 2 and the new IKE draft attempts (very poorly) to describe what to do in phase 1. It is entirely permissible to refuse the negotiation or to accept it and just stick to the locally configured lifetime. The text in the IKE draft is being rewritten. *) Rekeying - There were statements like "we occasionally get out of sync" or "there are stalls". - There was confusion over when to stop using the old SA. - When a 2nd IKE SA is established should the old one be deleted even if the lifetime hasn't expired? It is believed that all these issues can be resolved if the use of the acknowledged delete message (in the new IKE draft) was made mandatory for both phase 1 and phase 2. So text mandating the use of this exchange when deleting any SA will be inserted. *) Failover and Recovery - If a peer crashes and reboots its SA state is lost. How to sync back up? One solution is for the box that rebooted to send and unprotected delete message causing the box that didn't reboot to clear its SAs and begin an IKE exchange. The other is for the peer that rebooted to begin an IKE exchange when it receives IPSec packets for which it has no SA. Both are problematic. It was suggested that a keepalive mechanism be built into IKE. Several people already have proprietary keepalive mechanisms in their implementations. Perhaps the person(s) who brought this up will write up a draft specifying how this is to be done. *) Certificate Requests - Is a NULL certificate request valid? What does it mean? Apparently it is valid but there was discussion on what it meant. "Send me all your certs" seemed to be the winner. The trust model for such behavior was not well explained though. This is really an item for the WG to decide. - If a certificate request is issued in the first message of Main Mode should the peer respond back with his certs in the 2nd message and thereby break the identity protection feature of Main Mode? The consensus was no. RFC2408 doesn't seem to say that the certs have to be in the _next_ message only that they have to be sent. - What is the order of certs in a chain and does it make any difference? The consensus was that there is no order and it doesn't make any difference. *) Misc - Do implementations have to accept an encrypted final Aggressive Mode message? Yes they do. - Does the order of ANDed offers make any difference in IPSec encapsulation? No it doesn't. - If the responder sends a "no proposal chosen" in response to an initial phase 1 message does he have to send a responder cookie? Yes he does. - Can transform numbers in the transform payload begin anywhere and do they have to be sequential? Regrettably, it's yes and no. - Is it OK to send 3 copies of every single message (which one implementation was doing)? Yes. IP Payload Compresion Protocol (PCP) Issues: As I said, these aren't IPSec WG issues but people are using IKE to negotiate PCP and these things came up. The appropriate WG needs to deal with these. - IKE requires consistent attributes accross Quick Mode negotiation. For instance, when doing PFS the group must be in all offers and it has to be the same group. What about PCP? Since it has no keys does it need a group definition if the accompanying IPSec SAs will have PFS? - Do lifetimes in PCP SAs make sense to negotiate? If so, does a KB lifetime expire on pre- or post-compressed data? - Is it valid to pass a SPI (actually a CPI in PCP) of zero? Is this the "well known CPI"? - A CPI is two bytes. Is it OK to send a 4 byte one and have the upper two bytes be zero? - A PCP RFC seems to say that tunnel mode processing is not possible. Is this true? From owner-ipsec@lists.tislabs.com Tue Jun 15 17:07:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07135; Tue, 15 Jun 1999 17:07:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17522 Tue, 15 Jun 1999 17:57:05 -0400 (EDT) Date: Wed, 16 Jun 1999 01:06:17 +0300 (EET DST) Message-Id: <199906152206.BAA01501@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Comments about draft-ietf-ipsec-ike-01.txt X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 16 min X-Total-Time: 19 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here are some comments about the draft-ietf-ipsec-ike-01.txt. I already talked with Dan Harkins about this issues in the interop, but I promised to put those issues also here in the list, so others can comment them. > IPSEC Working Group Dan Harkins, Network Alchemy > INTERNET-DRAFT Dave Carrel, Redback Networks > draft-ieft-ipsec-ike-01.txt May 1999 > > The Internet Key Exchange (IKE) > ... > 1. Abstract > This memo describes a key exchange and security negotiation protocol > which is intended to depricate [HC98]. As such it will not change the > "bits on the wire" for an implementation which is compiant with > [HC98] but will clarify contentious issues with [HC98] and attempt to > explain the protocol in a less haphazard manner. Due to advances in This draft do change some bits on the wire, it for example makes some previously allowed forms of packets not allowed (isakmp cookies). Also the DSA signature is defined quite different what people interpreted from the previous version. > 3. Introduction > > A Domain Of Interpretation defines the attributes (and their > meanings) negotiated by IKE. It may overload payloads that are > defined in [MSST98]. This protocol does not define its own DOI per > se. It does not define DOI nor Situation values for the SA payload > during Phase 1 negotiation. > > The Phase 1 SA MAY use the DOI and situation from a non-ISAKMP > service (such as [Pip97]). In this case an implementation MAY choose > to restrict use of the Phase 1 SA for establishment of SAs for > services of the same DOI. Alternatively, a Phase 1 SA MAY be > established with the value zero in both the DOI and Situation fields > and in this case implementations will be free to establish security What does zero Situation field mean? 1) Use zero length situation field, i.e just leave the whole situation part away? 2) Put zero in the Situation bitmap, and leave rest away? 3) Something else? I would really say it means 1 above. > 3.2 Attribute Negotiation > > During security association negotiation Initiators present offers, in > the form of protection suites, to Responders. Responders MUST NOT > modify any attributes of any offer (with the possible exception of > attribute encoding, see Appendix A). If the Initiator of an exchange > notices that attribute values have been changed or attributes have > been added or deleted from an offer made that response MUST be > rejected. > > The SA payload from [MSST98] is used to negotiate security > associations in both Phase 1 and Phase 2 exchanges. This payload > contains a field for a Security Parameter Index (SPI) and a field for > the length of the SPI. During Phase 1 the SPI field MUST be empty and > the length of the SPI MUST be zero. During Phase 2 the SPI values and > their lengths depends on the particular DOI being negotiated. This is one of the cases this draft forbids previously allowed use. I still agree that this change is one we should make, but we probably should add some comment in the text about this. > Diffie-Hellman groups are specified either using a defined group > description (section 5) or by defining all attributes of a group > (Appendix A) in a protection suite. Group attributes, such as group > type or prime number MUST NOT be offered in conjunction with a > previously defined group, defined either in section 5 or via a > previous New Group Mode exchange (section 6.3). One question about this. Is implementation allowed to define new groups on the fly? I.e include both private group number, and parameters, so this would do implicit new group mode and add that newly defined group with the group number given? If this is allowed I think it should be explicitly said here. > Certain negotiable attributes have ranges or multiple acceptable > values. For instance, if the policy specification on a peer mandates > group 2 but is offered group 5, as part of an otherwise acceptable > protection suite, the peer SHOULD accept that value as it provides > more security than demanded. SA lifetimes pose similar issues. If a > peer has a local policy which requires SAs live for no more than 2 > hours and is offered a protection suite which contains a lifetime > value of 1 hour, the peer SHOULD accept that value as it provides > less opportunity for key exposure. I think it would be more understandable if the text above would say something like this: Certain negotiable attributes have ranges or multiple acceptable values. Examples of that kind of attributes are the group descriptor, key length and lifetimes. Implementations SHOULD allow defining acceptable ranges for those attributes, i.e it SHOULD be possible to configure system to allow groups 2, 4, and 5, or to accept key lengths between 128 and 448 bits. This what this issue is really about. Current implementations have quite often very limited configuration, and they don't allow doing that kind of configurations. If the policy says use only group 2 there is really no use to force him to use group 5, but there should be option to allow saying use group 2 or 5. We can also leave this whole thing out and say it is an implementation issue, and not a protocol issue, thus this kind of thing doesn't belong here... > 6. Modes for IKE Phases ... > 6.1 Phase 1 ... > Use of the commit bit from [MSST98] during Phase 1 is forbidden. > Implementations SHOULD respond with an notify message whose type is > set to INVALID-FLAGS (8). We should probably add text here saying which identities are allowed in phase 1. I think the consensus is something like this: Phase 1 can only use identities that identify one host or security gateway. This includes ipv4/6 address, fqdn, user@fqdn, distinguished name, general name and key id. Subnets or ranges are not allowed in phase 1. > 6.1.1.2 Main Mode Authentication with Digital Signatures ... > In general the signature will be directly over I-digest and R-digest > which are generated by the pseudo-random function. However, this can > be overridden for construction of a signature if the signature > algorithm is tied to a particular hash algorithm by changing the > digest construction from: > > digest = prf(key, msg) > > to > > digest = hash(key | msg) > > For example, DSS is only defined with SHA's 160 bit output and in > this case the digests would be: > > I-digest = SHA(SKEYID | g^i | g^r | CKY-I | CKY-R | SAi_b | > ID_i1_b) > > R-digest = SHA(SKEYID | g^r | g^i | CKY-R | CKY-I | SAi_b | > ID_r1_b) > > The contents of the signature payload would then be the resulting > 320-bit DSA signature of the digest ("r" followed by "s"). This is quite different than was in the previous draft, and I think most of the implementations are using this kind of definition: Sign(hmac-sha(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b)) > 6.1.1.3 Main Mode Authentication with Public Key Encryption ... We should probably add there paragraph either allowing using CERT payloads in the public key encryption (with a warning that it breaks identity protection, because they must be sent clear), or disallow using them (because they break identity protection). > 6.2 Quick Mode ... > In the case of a Quick Mode Initiator, these client IDs are be > supplied by the service requesting SAs. In the case of a Quick Mode > Responder, those IDs are extracted from the Quick Mode message and > supplied to the service identified by the DOI value in the SA payload > (also in the Quick Mode message). If the identities are not > acceptable to the service (due to policy or other reasons), an > Informational message containing a notify payload, with a type of > INVALID-ID-INFORMATION (18), SHOULD be sent back to the Initiator. > The Responder MUST NOT modify the client IDs in any way and they MUST > be delivered back to the Initiator in exactly the order supplied, > that is, IDi2 does not become IDr2 in the message the Responder sends > back to the Initiator. Here should again be some kind of paragraph about acceptable identity types (only those which can be mapped to ip address or ip addresses (ranges, subnets)). I don't think there is any meaning giving out user@fqdn, fqdn, distinguished name, or general name as a proxy identity? Key id should probably be allowed, so people can use that as "policy key id" to their own policy database and fetch the real proxy information from the policy database. > 6.3 New Group Mode ... > New Group Mode MUST NOT be used prior to establishment of an IKE SA. > The description of a new group MUST only follow phase 1 negotiation. > (It is not a phase 2 exchange, though). > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA --> > <-- HDR*, HASH(2), SA > > where HASH(1) is the prf output, using SKEYID_a as the key, and the > message-ID from the ISAKMP header concatenated with the entire SA ^^ > proposal, body and header, as the data; HASH(2) is the prf output, ^^^^^^^^ I think we should say "rest of the packet" instead of only the SA proposal. This way if we add later notifications or something in the same packet those payloads will also be authenticated. > Groups may be directly negotiated in the SA proposal with Main Mode. > To do this the component parts-- for a MODP group, the type, prime > and generator; for a EC2N group the type, the Irreducible Polynomial, > Group Generator One, Group Generator Two, Group Curve A, Group Curve > B and Group Order-- are passed as SA attributes (see Appendix A). > Alternately, the nature of the group can be hidden using New Group > Mode and only the group identifier is passed in the clear during > phase 1 negotiation. This would indicate that we can give "group number" to the private group negotiated in the phase 1, and use that group then in the phase 2. > 6.4 Notification Exchanges > 6.4.2 Acknowledged Informational > > IKE exchanges are sent as ISAKMP messages whose delivery is > unreliable. This fact has been taken into account in the design of > Phase 1 and Phase 2 exchanges since retransmission timers are set to > allow for packet loss. Due to the unreliable nature of the exchange > described in 6.4.1 certain messages should not be sent that way. For > instance, if a notification that an SA has been deleted is lost the > sender may delete it but the intended recipient will have not way of > knowing this fact. > > The first payload of the acknowledged Informational exchange MUST be > a hash payload and the second payload MUST be the nonce of the > > Harkins Carrel [Page 29] > > INTERNET DRAFT May 1999 > > sender. The Responder MUST NOT change the notification payloads > which follow the Initiator's nonce. > > The acknowledged Informational exchange is defined as: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), Ni, N/D --> > <-- HDR*, HASH(2), Nr, N/D > > where HASH(1) is prf output using SKEYID_a from the Phase 1 SA > identified by the cookies in the ISAKMP header as the key, and the > unique, pseudo-random message ID for this exchange concatenated with > the remaining payloads (in this case, a delete or notify and a nonce > payload, but more payloads could be chained to this message) as the > data, and HASH(2) is the prf output using SKEYID_a, from the Phase 1 > SA identified by the cookies in the ISKAMP header, as the key and the > nonce payload sent by the Initiator concatenated with the pseudo- > random message ID for this exchange and the remaining payloads as the > message to hash. The hashes for the above exchange would be: > > HASH(1) = prf(SKEYID_a, M-ID | Ni | N/D) > HASH(2) = prf(SKEYID_a, Ni | M-ID | Nr | N/D) > > This memo does not proscribe which messages should be sent with the > Acknowledged or Unacknowledged Informational. I would really like to see two new kind of notifications here: Initiator Responder ----------- ----------- HDR, SIG, [CERTs], Ni, N/D --> Where SIG (MUST be first payload) is signature of the HASH of the rest of the payload. This would allow sending delete and error notification payloads to the responder even when we do not have ISAKMP SA up yet (for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)). In this case the SIG should also define the HASH algorithm to use, so we should either use signature format that contains it or define it somewhere else. > 8 Security Considerations > The strength of a key derived from a Diffie-Hellman exchange using > any of the groups defined here depends on the inherent strength of > the group, the size of the exponent used, and the entropy provided by > the random number generator used. Due to these inputs it is difficult > to determine the strength of a key for any of the defined groups. The > default Diffie-Hellman group (number two) when used with a strong > random number generator and an exponent no less than 160 bits is > sufficient to use for 3DES. Groups three through five provide 160 bits is not sufficient for 3DES. According the previous version it was sufficient to the DES... Oakley says: ---------------------------------------------------------------------- The modulus size alone does not determine the strength of the Diffie-Hellman calculation; the size of the exponent used in computing powers within the group is also important. The size of the exponent in bits should be at least twice the size of any symmetric key that will be derived from it. We recommend that ISAKMP implementors use at least 180 bits of exponent (twice the size of a 20-year symmetric key). ---------------------------------------------------------------------- So assume 2 * 112 = 224 bits is minimum for 3DES. ... > Optimal Asymmetric Encryption Padding [BR94] MUST be used with PKCS#1 > to avoid the adaptive chosen ciphertext attack against RSA that is > described in [Ble98]. See [PKCS1]. > > The acknowledged Informational exchange is open to replay attacks. There should also be comment here, that main mode (identity protection) is open to man in the middle attack, that will reveal initiators identity. > Appendix A > - Hash Algorithm Defined In > MD5 1 RFC 1321 > SHA 2 FIPS 180-1 > Tiger 3 See Reference [TIGER] Ripemd160 should be added here. Also we should define the length of the tiger meant here. The referenced paper defines Tiger/192, Tiger/160 and Tiger/128. Just changing that line to > Tiger/192 3 See Reference [TIGER] Would solve the issue. > - Life Type > > seconds 1 > kilobytes 2 Is there any need to have life type of kilobytes in the phase 1? I don't really think so, but I think there would be use to have negotiations 3 That would limit the number of phase 2 negotiations done over phase 1 isakmp sa. This way you could say that this Isakmp SA is only valid to negotiate 5 quick mode negotiations, and after that it should be deleted. The negotiations should be defined so that all negotiations that use SKEYID_d (consumes entropy from it) is counted as one negotiation, those negotiations which do not use it (notifications, new group mode etc) are not counted as negotiations here. > The key for DES-CBC is derived from the first eight (8) non-weak and > non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first > 8 bytes of the IV material derived in section 4.1 above. What does the above mean? If the bytes 0-7 are weak do we take bytes 1-8 or 9-15? I assume it is bytes 1-8 (this is how we implemented it). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 15 18:27:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA09568; Tue, 15 Jun 1999 18:27:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17729 Tue, 15 Jun 1999 19:47:37 -0400 (EDT) Message-Id: <4.2.0.56.19990615163856.0098cf00@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Tue, 15 Jun 1999 16:51:36 -0700 To: Dan Harkins , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: issues from the bakeoff In-Reply-To: <199906151954.MAA21779@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:54 PM 6/15/1999 -0700, Dan Harkins wrote: > As I said, these aren't IPSec WG issues but people are using IKE to > negotiate PCP and >these things came up. The appropriate WG needs to deal with these. Just a note that the IPPCP WG is no longer; they finished in December 1998. I hope the mailing list is still active, but I cannot for the life of me find the address of the list. > From adm Tue Dec 22 10:16:41 1998 >Received: by ietf.org (8.9.1a/8.9.1a) id KAA29466 > for ietf-123-outbound.10@ietf.org; Tue, 22 Dec 1998 10:15:02 > -0500 (EST) >Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29411 > for ; Tue, 22 Dec 1998 10:14:01 -0500 (EST) >Message-Id: <199812221514.KAA29411@ietf.org> >To: IETF-Announce: ; >Subject: WG Action: IP Payload Compression Protocol (ippcp) to > conclude >From: The IESG >Date: Tue, 22 Dec 1998 10:14:01 -0500 >Sender: scoya@ns.cnri.reston.va.us > > >The IP Payload Compression Protocol (ippcp) Working Group in the >Internet Area of the IETF has concluded. > >The IESG contact persons are Thomas Narten and Jeff Burgan. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 15 18:27:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA09579; Tue, 15 Jun 1999 18:27:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17713 Tue, 15 Jun 1999 19:41:21 -0400 (EDT) From: Dan McDonald Message-Id: <199906152350.QAA21442@kebe.Eng.Sun.COM> Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt To: kivinen@ssh.fi (Tero Kivinen) Date: Tue, 15 Jun 1999 16:50:28 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <199906152206.BAA01501@torni.ssh.fi> from "Tero Kivinen" at Jun 16, 99 01:06:17 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 6. Modes for IKE Phases > ... > > 6.1 Phase 1 > ... > > Use of the commit bit from [MSST98] during Phase 1 is forbidden. > > Implementations SHOULD respond with an notify message whose type is > > set to INVALID-FLAGS (8). > > We should probably add text here saying which identities are allowed > in phase 1. I think the consensus is something like this: > > Phase 1 can only use identities that identify one host or security > gateway. This includes ipv4/6 address, fqdn, user@fqdn, > distinguished name, general name and key id. Subnets or ranges are > not allowed in phase 1. Along with that text, should we talk about how if we do per-user keying, this means a new phase 1 per-user? Or would that be obvious from the above suggested paragraph? Dan McD. From owner-ipsec@lists.tislabs.com Tue Jun 15 21:10:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA26775; Tue, 15 Jun 1999 21:10:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18059 Tue, 15 Jun 1999 22:11:21 -0400 (EDT) Message-Id: <4.0.2.19990615150140.00fa0910@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 15 Jun 1999 19:18:17 -0700 To: Dan Harkins From: Avram Shacham Subject: Re: issues from the bakeoff Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <199906151954.MAA21779@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, First, thanks for providing the IPComp-related information from the recent bakeoff. Are there more details available regarding implementations, interoperability, etc? Inline comments are embedded. avram At 12:54 PM 6/15/99 -0700, Dan Harkins wrote: > There was an IPSec + L2TP (and PPoE too) bakeoff the week of May 24th. >As usual there were issues in interoperability that came up and I'm >presenting them to the list. Not too surprisingly there were no issues >with interoperability of the IPSec protocols, it's all IKE. Also there >were several IPPCP issues that I'll summarize although they're being >taken care of in a different working group in a different area. As was noted earlier, the ippcp wg has concluded. The mailing-list is (dusty, sure, but) still alive, and CC-ed. >IP Payload Compresion Protocol (PCP) Issues: > > As I said, these aren't IPSec WG issues but people are using IKE to negotiate PCP and >these things came up. The appropriate WG needs to deal with these. > > - IKE requires consistent attributes accross Quick Mode negotiation. For instance, > when doing PFS the group must be in all offers and it has to be the same group. > What about PCP? Since it has no keys does it need a group definition if the > accompanying IPSec SAs will have PFS? > > - Do lifetimes in PCP SAs make sense to negotiate? If so, does a KB lifetime > expire on pre- or post-compressed data? Lifetime has no meaning in the context of compression, imo. > - Is it valid to pass a SPI (actually a CPI in PCP) of zero? Currently, no, as the value 0 is defined to be RESERVED. > Is this the "well known CPI"? Yes, 0 is in the "well known" range. RFC2393 specifies the range 0-63 as pre-defined (3.3) but points the reader to RFC2407 "The Internet IP Security Domain of Interpretation for ISAKMP" for the defined values. There (4.4.5), as with so many other instances in that RFC, 0 is defined to be RESERVED. > - A CPI is two bytes. Is it OK to send a 4 byte one and have the upper two bytes > be zero? RFC2393 sets the CPI field in the header to be 2 octets, so the question seems to be related to the negotiation of CPI via the Internet Key Exchange. Could implementations support both ways, i.e. negotiate using just 2-byte field or using the LS 2-bytes of a 4-byte field? > - A PCP RFC seems to say that tunnel mode processing is not possible. Is this true? No. From owner-ipsec@lists.tislabs.com Tue Jun 15 22:04:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02631; Tue, 15 Jun 1999 22:04:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18172 Tue, 15 Jun 1999 23:14:16 -0400 (EDT) To: Avram Shacham cc: Dan Harkins , ipsec@lists.tislabs.com, ippcp@external.cisco.com In-reply-to: shacham's message of Tue, 15 Jun 1999 19:18:17 MST. <4.0.2.19990615150140.00fa0910@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: issues from the bakeoff Date: Wed, 16 Jun 1999 12:23:05 +0900 Message-ID: <23795.929503385@coconut.itojun.org> From: Jun-ichiro itojun Hagino Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> - Is it valid to pass a SPI (actually a CPI in PCP) of zero? >Currently, no, as the value 0 is defined to be RESERVED. >> Is this the "well known CPI"? >Yes, 0 is in the "well known" range. >RFC2393 specifies the range 0-63 as pre-defined (3.3) but points >the reader to RFC2407 "The Internet IP Security Domain of >Interpretation for ISAKMP" for the defined values. There (4.4.5), >as with so many other instances in that RFC, 0 is defined to be >RESERVED. Well-known CPI is not very friendly with PFKEY interface (RFC2367). RFC2367 expects unique SPI per peer (which can embed CPI in lower 2 bytes), but for well-known CPI we can't. What kind of userland API do you expect to see? I'm now using dummy SPI (= CPI) to designate the SA database entry for compression, and add a flag to force the use of well-known CPI on the packet. itojun From owner-ipsec@lists.tislabs.com Tue Jun 15 23:15:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA07707; Tue, 15 Jun 1999 23:15:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18303 Wed, 16 Jun 1999 00:18:26 -0400 (EDT) Message-Id: <199906160426.VAA23944@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 15 Jun 1999 21:24:43 -0700 To: Jun-ichiro itojun Hagino From: Avram Shacham Subject: Re: issues from the bakeoff Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <23795.929503385@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:23 PM 6/16/99 +0900, Jun-ichiro itojun Hagino wrote: > Well-known CPI is not very friendly with PFKEY interface (RFC2367). > RFC2367 expects unique SPI per peer (which can embed CPI in lower > 2 bytes), but for well-known CPI we can't. Following the IPsec list, one must come to the realization that PFKEY-friendly isn't the characteristic of several protocols, nor it is a requirement. So, IPComp isn't alone. > What kind of userland API do you expect to see? I'm now using dummy > SPI (= CPI) to designate the SA database entry for compression, > and add a flag to force the use of well-known CPI on the packet. The RFC reflects the decision of the ippcp wg in the meeting in Washington, DC (Dec 97) It was also decided not to restrict the CPI values 0-63 only for manual setup but also use it for ISAKMP for well known algorithms. I don't recall any discussion in the wg or on the list regarding "userland API." If the API doesn't fit the protocols, shouldn't the API be adjusted? avram From owner-ipsec@lists.tislabs.com Tue Jun 15 23:44:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA08501; Tue, 15 Jun 1999 23:44:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18372 Wed, 16 Jun 1999 00:57:43 -0400 (EDT) Message-Id: <199906160505.WAA24458@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 15 Jun 1999 22:04:09 -0700 To: itojun@iijlab.net From: Avram Shacham Subject: Re: issues from the bakeoff Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <24769.929507448@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:30 PM 6/16/99 +0900, itojun@iijlab.net wrote: > I just would like to know how we should update RFC2367 for IPComp. >> If the API doesn't fit the protocols, shouldn't the API be adjusted? > > Yes of course, but the question is, what kind of changes are necessary. > PFKEY is used for both manual key setups (from userland program to > manipulate manual keys) and autoconfigured keys (from IKE daemons). > I've described my quickhack above. Rereading your previous message, the method described seems adequate-enough to define the CPI. avram From owner-ipsec@lists.tislabs.com Wed Jun 16 02:45:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA15641; Wed, 16 Jun 1999 02:45:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18709 Wed, 16 Jun 1999 03:50:54 -0400 (EDT) Message-Id: <3.0.5.32.19990616110216.00b77880@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 16 Jun 1999 11:02:16 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: issues from the bakeoff In-Reply-To: <4.0.2.19990615150140.00fa0910@honeybee.cisco.com> References: <199906151954.MAA21779@potassium.network-alchemy.com> 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 DAA18706 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:18 15.6.1999 -0700, Avram Shacham wrote: >At 12:54 PM 6/15/99 -0700, Dan Harkins wrote: >> - A CPI is two bytes. Is it OK to send a 4 byte one and have the upper two bytes >> be zero? > >RFC2393 sets the CPI field in the header to be 2 octets, so the question >seems to be related to the negotiation of CPI via the Internet Key >Exchange. Could implementations support both ways, i.e. negotiate >using just 2-byte field or using the LS 2-bytes of a 4-byte field? > Yes. Since CPI values are two bytes long, we should send two byte SPI values. For compatablities sake, we should accept four byte SPI values too, the CPI is in the LS two bytes. >> - A PCP RFC seems to say that tunnel mode processing is not possible. Is this true? > >No. Just to remind everybody, the proper way to compress in tunnel mode is: IP ESP IPCOMP IP PAYLOAD We did IP ESP IP IPCOMP PAYLOAD, and it was not well received. Jörn Sierwald From owner-ipsec@lists.tislabs.com Wed Jun 16 02:46:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA15678; Wed, 16 Jun 1999 02:46:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18688 Wed, 16 Jun 1999 03:43:49 -0400 (EDT) Message-ID: <6078A04DA8A8D21189DD00A024B211101B9839@lasis.bank.lv> From: Ivars Suba To: "'HORMAN@novell.com'" Cc: hugo@ee.technion.ac.il, svan@trustworks.com, ipsec@lists.tislabs.com Subject: RE: RFC2409 (Chess Tournament) Date: Wed, 16 Jun 1999 10:51:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="WINDOWS-1257" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk < -----Original Message----- < From: Hilarie Orman [mailto:HORMAN@novell.com] < Sent: Tuesday, June 15, 1999 7:41 PM < To: hugo@ee.technion.ac.il; svan@trustworks.com < Cc: IvarsS@bank.lv; ipsec@lists.tislabs.com < Subject: Re: RFC2409 < < < I suppose you could call it a feature ... if you want a protocol < that uses C as a trusted relay. C is trusted to start the < game, to relay the messages, and not to read them. Later, I and < R can get together and verify that they were using the proper < shared key for their messages, and that is reason to believe < that C behaved properly. So, if you want anonymous chess tournaments < with verifiable results, this is your protocol. So let's change < C's name to T, the Tournament Director. And I and R should be < F and S (who could have hardly been anonymous to each other). < < Hilarie It is good idea exploit C as moderator in anonymous chess tournament. One of above idea implementation are described below. I nicknamed this protocol as post - authentication protocol. N A large safe prime (N = 2q+1, where q is prime) All arithmetic is done modulo N. g A generator modulo N s1, s2 I and R salt respectively p1, p2 I and R cleartext Passwords H() One-way hash function ^ (Modular) Exponentiation * (Modular) Multiplication t Security parameter u1, u2 I and R random t -bit scrambling parameter a,b Secret ephemeral values A,B, S1, S2 Public ephemeral values x, y I and R long term private keys (derived from p and s) v, z I and R password verifiers The I and R stores passwords using the following formula: x = H(s1, p1) y = H(s2, p2) (s1and s2 are chosen randomly) I -> C : v = g^x R -> C : z = g^y (computes password verifier, long term) The post - authentication protocol itself goes as follows: I -> C : A = g^a , u1, R -> C : B = g^b, u2, C -> R : u1, S1 = B * z^u2 R : S = S1 ^ (a + u1*x) R : K =H(S) (computes session key) C -> I : u2, S2 = A*v^u1 I : S = S2^ (b+u2*y) I : K = H(S) (computes session key) Now the two parties I and R have a shared, strong session key K. To complete post - authentication and to be sure that C don't fake, they need to prove to each other that their keys match. One possible way: I -> C -> R : M =H(H(N) xor H(g), u1, u2, K) R -> C -> I : H( M, u2, u1, K) After chess game I and R must reveal identity to each other: I -> C ->R : M1 = H(IDi, K), IDi R -> C -> I : M2 = H(IDi, IDr, K), IDr Ivars From owner-ipsec@lists.tislabs.com Wed Jun 16 06:20:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27359; Wed, 16 Jun 1999 06:20:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19324 Wed, 16 Jun 1999 07:07:04 -0400 (EDT) Message-ID: <6078A04DA8A8D21189DD00A024B211101B983A@lasis.bank.lv> From: Ivars Suba To: "'HORMAN@novell.com'" Cc: "'hugo@ee.technion.ac.il'" , "'svan@trustworks.com'" , "'ipsec@lists.tislabs.com'" Subject: RE: RFC2409 (Chess Tournament) Date: Wed, 16 Jun 1999 14:12:48 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="WINDOWS-1257" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologize, here is mistake. For correct version, please look below. Ivars < -----Original Message----- < From: Hilarie Orman [mailto:HORMAN@novell.com] < Sent: Tuesday, June 15, 1999 7:41 PM < To: hugo@ee.technion.ac.il; svan@trustworks.com < Cc: IvarsS@bank.lv; ipsec@lists.tislabs.com < Subject: Re: RFC2409 < < < I suppose you could call it a feature ... if you want a protocol < that uses C as a trusted relay. C is trusted to start the < game, to relay the messages, and not to read them. Later, I and < R can get together and verify that they were using the proper < shared key for their messages, and that is reason to believe < that C behaved properly. So, if you want anonymous chess tournaments < with verifiable results, this is your protocol. So let's change < C's name to T, the Tournament Director. And I and R should be < F and S (who could have hardly been anonymous to each other). < < Hilarie It is good idea exploit C as moderator in anonymous chess tournament. One of above idea implementation are described below. I nicknamed this protocol as post - authentication protocol. N A large safe prime (N = 2q+1, where q is prime) All arithmetic is done modulo N. g A generator modulo N s1, s2 I and R salt respectively p1, p2 I and R cleartext Passwords H() One-way hash function ^ (Modular) Exponentiation * (Modular) Multiplication t Security parameter u1, u2 I and R random t -bit scrambling parameter a,b Secret ephemeral values A,B, S1, S2 Public ephemeral values x, y I and R long term private keys (derived from p and s) v, z I and R password verifiers The I and R stores passwords using the following formula: x = H(s1, p1) y = H(s2, p2) (s1and s2 are chosen randomly) I -> C : v = g^x R -> C : z = g^y (computes password verifier, long term) The post - authentication protocol itself goes as follows: I -> C : A = g^a , u1, R -> C : B = g^b, u2, C -> I : u1, S1 = B * z^u2 I : S = S1 ^ (a + u1*x) I : K =H(S) (computes session key) C -> R : u2, S2 = A*v^u1 R : S = S2^ (b+u2*y) R : K = H(S) (computes session key) Now the two parties I and R have a shared, strong session key K. To complete post - authentication and to be sure that C don't fake, they need to prove to each other that their keys match. One possible way: I -> C -> R : M =H(H(N) xor H(g), u1, u2, K) R -> C -> I : H( M, u2, u1, K) After chess game I and R must reveal identity to each other: I -> C ->R : M1 = H(IDi, K), IDi R -> C -> I : M2 = H(IDi, IDr, K), IDr Ivars From owner-ipsec@lists.tislabs.com Wed Jun 16 06:41:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27623; Wed, 16 Jun 1999 06:41:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19516 Wed, 16 Jun 1999 07:44:48 -0400 (EDT) Date: Wed, 16 Jun 1999 14:53:58 +0300 (EET DST) Message-Id: <199906161153.OAA02241@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt In-Reply-To: <199906160721.LAA01404@relay1.trustworks.com> References: <199906152206.BAA01501@torni.ssh.fi> <199906160721.LAA01404@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > On 16 Jun 99 at 1:06, Tero Kivinen wrote: > > [...] > > I would really like to see two new kind of notifications here: > > > > Initiator Responder > > ----------- ----------- > > HDR, SIG, [CERTs], Ni, N/D --> > > > > Where SIG (MUST be first payload) is signature of the HASH of the rest > > of the payload. This would allow sending delete and error notification > > payloads to the responder even when we do not have ISAKMP SA up yet > > (for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)). > > > > In this case the SIG should also define the HASH algorithm to use, so > > we should either use signature format that contains it or define it > > somewhere else. > What about the situation when Responder doesn't support signatures > at all (i.e. performs only preshared key authentication) or supports > different signature algorithm from that you've used to sign this > message? In your example (sending NO-PROPOSAL-CHOSEN in phase 1) it > will often be the case, making such notification almost useless. > Also, such notification increases IKE vulnerability to DoS attack. Then the responder ignores the SIG payload and it can still read the clear text notification or delete, and act accordinly. Its policy then dictates wheter it will trust the unauthenticated notification or delete or not. > > > The acknowledged Informational exchange is open to replay attacks. > > There should also be comment here, that main mode (identity > > protection) is open to man in the middle attack, that will reveal > > initiators identity. > As far as I understand, it is true for signature authentication > methods only and isn't true for the other methods. Yes, you are correct. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 16 06:41:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27633; Wed, 16 Jun 1999 06:41:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19537 Wed, 16 Jun 1999 07:50:19 -0400 (EDT) Message-ID: <3767921A.2133D3EF@checkpoint.com> Date: Wed, 16 Jun 1999 15:01:30 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt References: <199906152206.BAA01501@torni.ssh.fi> Content-Type: multipart/alternative; boundary="------------79C721E9863F79645EA3C091" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------79C721E9863F79645EA3C091 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > > > 6. Modes for IKE Phases > ... > > 6.1 Phase 1 > ... > > Use of the commit bit from [MSST98] during Phase 1 is forbidden. > > Implementations SHOULD respond with an notify message whose type is > > set to INVALID-FLAGS (8). > > We should probably add text here saying which identities are allowed > in phase 1. I think the consensus is something like this: > > Phase 1 can only use identities that identify one host or security > gateway. This includes ipv4/6 address, fqdn, user@fqdn, > distinguished name, general name and key id. Subnets or ranges are > not allowed in phase 1. > > As Dan McDonald mentioned, the paragraph should look something like: Phase 1 can only use identities that identify a host a security gateway or a user. This includes ipv4/6 address, fqdn, user@fqdn, distinguished name, general name and key id. Subnets or ranges are not allowed in phase 1. > > - Life Type > > > > seconds 1 > > kilobytes 2 > > Is there any need to have life type of kilobytes in the phase 1? I > don't really think so, but I think there would be use to have > > negotiations 3 > > That would limit the number of phase 2 negotiations done over phase 1 > isakmp sa. This way you could say that this Isakmp SA is only valid to > negotiate 5 quick mode negotiations, and after that it should be > deleted. The negotiations should be defined so that all negotiations > that use SKEYID_d (consumes entropy from it) is counted as one > negotiation, those negotiations which do not use it (notifications, > new group mode etc) are not counted as negotiations here. > > I'd like to comment that due to the symmetric nature of IKE SA's (an IKE peer can use the same IKE SA for both encryption and decryption), it seems difficult to enforce a limitation on the number of negotiations or the amount of data encrypted with the IKE SA. Since packets can get lost (especially notifications) the two IKE peers can get out of sync regarding the number of negotiations they had or the amount of data they encrypted. This can lead to a scenario in which one side thinks that the IKE SA has been out used while the other side thinks it is still valid. Time restrictions seem to work fine as long as we don't travel at speeds close to the speed of light. --------------79C721E9863F79645EA3C091 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tero Kivinen wrote:

 
> 6. Modes for IKE Phases
...
> 6.1 Phase 1
...
>    Use of the commit bit from [MSST98] during Phase 1 is forbidden.
>    Implementations SHOULD respond with an notify message whose type is
>    set to INVALID-FLAGS (8).

We should probably add text here saying which identities are allowed
in phase 1. I think the consensus is something like this:

   Phase 1 can only use identities that identify one host or security
   gateway. This includes ipv4/6 address, fqdn, user@fqdn,
   distinguished name, general name and key id. Subnets or ranges are
   not allowed in phase 1.
 
 

As Dan McDonald mentioned, the paragraph should look something like:
  Phase 1 can only use identities that identify a host a security
   gateway or a user. This includes ipv4/6 address, fqdn, user@fqdn,
   distinguished name, general name and key id. Subnets or ranges are
   not allowed in phase 1.
 
>    - Life Type
>
>       seconds                             1
>       kilobytes                           2

Is there any need to have life type of kilobytes in the phase 1? I
don't really think so, but I think there would be use to have

        negotiations                        3

That would limit the number of phase 2 negotiations done over phase 1
isakmp sa. This way you could say that this Isakmp SA is only valid to
negotiate 5 quick mode negotiations, and after that it should be
deleted. The negotiations should be defined so that all negotiations
that use SKEYID_d (consumes entropy from it) is counted as one
negotiation, those negotiations which do not use it (notifications,
new group mode etc) are not counted as negotiations here.
 
 

I'd like to comment that due to the symmetric nature of IKE SA's (an IKE peer can use the same IKE SA for both encryption and decryption),
it seems difficult to enforce a limitation on the number of negotiations or the amount of data encrypted with the IKE SA.
Since packets can get lost (especially notifications) the two IKE peers can get out of sync regarding the number of negotiations they had or the amount of data they encrypted. This can lead to a scenario in which one side thinks that the IKE SA has been out used while the other side thinks it is still valid.
Time restrictions seem to work fine as long as we don't travel at speeds close to the speed of light.
  --------------79C721E9863F79645EA3C091-- From owner-ipsec@lists.tislabs.com Wed Jun 16 07:56:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28344; Wed, 16 Jun 1999 07:56:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19959 Wed, 16 Jun 1999 08:55:59 -0400 (EDT) Date: Wed, 16 Jun 1999 16:05:14 +0300 (EET DST) Message-Id: <199906161305.QAA06098@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt In-Reply-To: <199906161228.QAA13123@relay1.trustworks.com> References: <199906160721.LAA01404@relay1.trustworks.com> <199906161153.OAA02241@torni.ssh.fi> <199906161228.QAA13123@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > Yes, but in this case we have the same situation as with ordinary > notification, but with more computation resources involved. This > makes me think that, at least, in this particular situation > (NO-PROPOSAL-CHOSEN) such notification seems to be more harmful then > useful - it forces responder to perform public key operation in > response to unauthenticated peer (even without cookies been > exchanged) plus it may reveal responder's identity. And at such cost > we have only problematic initiators ability to verify signature. Is > it really worth? In some cases yes. In some cases no. It depends quite a lot about the policy. For example in most VPN cases the security gateway do NOT trust any plain text notifications, just to make denial of service attacks harder. For attacker it is very easy to send NO-PROPOSAL-CHOSEN every time you see first packet of the main mode. It is harder to delete that packet, but to just see that, you need one sniffer between those two vpn gateways. Also the NO-PROPOSAL-CHOSEN packet can be sent from different location, thus making it almost impossible to find the sniffer. The policy for signed notifications can be something like send only one signed notification every 10 seconds, otherwise use unauthenticated notifications. If the other end does trust the unauthenticated notification, then it will retransmit its packet and if we haven't sent out any signed notifications for last 10 seconds, then we reply with signed notification. Of course there is no point of sending signed notifications to peer that is known to support only pre-shared keys. Also if you do not want to send you CERT payload because it would reveal your identity, then you must either create new ISAKMP SA and use that to send notifications (very hard if you are just trying to send NO-PROPOSAL-CHOSEN notification back) or you must send the notification without any protection. I am not suggesting we remove the old unauthenticated notifications, I just say that there is many cases where I do not want to trust unauthenticated notifications. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 16 07:57:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28353; Wed, 16 Jun 1999 07:56:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19779 Wed, 16 Jun 1999 08:43:53 -0400 (EDT) Date: Wed, 16 Jun 1999 15:53:08 +0300 (EET DST) Message-Id: <199906161253.PAA05856@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tamir Zegman Cc: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt In-Reply-To: <3767921A.2133D3EF@checkpoint.com> References: <199906152206.BAA01501@torni.ssh.fi> <3767921A.2133D3EF@checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tamir Zegman writes: > I'd like to comment that due to the symmetric nature of IKE SA's (an > IKE peer can use the same IKE SA for both encryption and > decryption), it seems difficult to enforce a limitation on the > number of negotiations or the amount of data encrypted with the IKE > SA. Since packets can get lost (especially notifications) the two > IKE peers can get out of sync regarding the number of negotiations > they had or the amount of data they encrypted. This can lead to a > scenario in which one side thinks that In encrypted data yes, in negotiations they cannot. When we send packet out we encrypt it only once, if that packet gets lost then we retransmit already encrypted packet, thus we do not encrypt it again. If any of those packets never reaches the destination, we time out the negotiation. Timing out negotiations should quite rare, it normally means that the network connection is broken or the other end rebooted. If the other end rebooted, then this is non issue, because it doesn't have the ISAKMP SA up anymore, so we can remove the ISAKMP SA immediately. If the network connection is broken, then there isn't really anything we can do, and is is almost impossble to distinguishing broken network connection from the reboot of the other end (when the other end has policy that it doesn't send any notifications back). In both cases we can just delete the ISAKMP SA and retry creating the ISAKMP SA, to see if that helps. The negotiation lifetime counter is only incremented when IPSEC SA is really created (thus when we create keying material for it and use SKEYID_d for that). This means that only way we can get out of sync is that network breaks down after second packet of the quick mode, but before the initiator has possibility to send the final third packet. In this case initiator has one negotiation more than the responder has. Actually this is correct, because initiator has already consumed entropy from the SKEYID_d when it created the IPSEC SA and the responder hasn't done that yet. And getting out of sync isn't really a problem. It just means other end will just delete the ISAKMP SA earlier. When we have acknoledged deletes then this is not really a problem. > the IKE SA has been out used while the other side thinks it is still > valid. Time restrictions seem to work fine as long as we don't > travel at speeds close to the speed of light. This is only true if the other end doesn't send (acknowedged) delete notifications. Note, that other end is allowed to delete the ISAKMP SA anyways earlier than its lifetime is due. For example if it is running out of resources it might just start cleaning up old ISAKMP SA to free resources. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 16 08:10:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28510; Wed, 16 Jun 1999 08:10:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20163 Wed, 16 Jun 1999 09:06:28 -0400 (EDT) Message-Id: <199906161228.QAA13123@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: "Valery Smyslov" , Tero Kivinen Date: Wed, 16 Jun 1999 16:28:24 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt CC: ipsec@lists.tislabs.com In-reply-to: <199906161153.OAA02241@torni.ssh.fi> References: <199906160721.LAA01404@relay1.trustworks.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 16 Jun 99 at 14:53, Tero Kivinen wrote: > Valery Smyslov writes: > > On 16 Jun 99 at 1:06, Tero Kivinen wrote: > > > > [...] > > > I would really like to see two new kind of notifications here: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SIG, [CERTs], Ni, N/D --> > > > > > > Where SIG (MUST be first payload) is signature of the HASH of the rest > > > of the payload. This would allow sending delete and error notification > > > payloads to the responder even when we do not have ISAKMP SA up yet > > > (for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)). > > > > > > In this case the SIG should also define the HASH algorithm to use, so > > > we should either use signature format that contains it or define it > > > somewhere else. > > What about the situation when Responder doesn't support signatures > > at all (i.e. performs only preshared key authentication) or supports > > different signature algorithm from that you've used to sign this > > message? In your example (sending NO-PROPOSAL-CHOSEN in phase 1) it > > will often be the case, making such notification almost useless. > > Also, such notification increases IKE vulnerability to DoS attack. > > Then the responder ignores the SIG payload and it can still read the > clear text notification or delete, and act accordinly. Its policy then > dictates wheter it will trust the unauthenticated notification or > delete or not. Yes, but in this case we have the same situation as with ordinary notification, but with more computation resources involved. This makes me think that, at least, in this particular situation (NO-PROPOSAL-CHOSEN) such notification seems to be more harmful then useful - it forces responder to perform public key operation in response to unauthenticated peer (even without cookies been exchanged) plus it may reveal responder's identity. And at such cost we have only problematic initiators ability to verify signature. Is it really worth? Regards, Valery. From owner-ipsec@lists.tislabs.com Wed Jun 16 08:13:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28548; Wed, 16 Jun 1999 08:13:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20067 Wed, 16 Jun 1999 09:02:28 -0400 (EDT) To: Avram Shacham cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-reply-to: shacham's message of Tue, 15 Jun 1999 21:24:43 MST. <199906160426.VAA23944@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: issues from the bakeoff From: itojun@iijlab.net Date: Wed, 16 Jun 1999 13:30:48 +0900 Message-ID: <24769.929507448@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Well-known CPI is not very friendly with PFKEY interface (RFC2367). >> RFC2367 expects unique SPI per peer (which can embed CPI in lower >> 2 bytes), but for well-known CPI we can't. >Following the IPsec list, one must come to the realization that >PFKEY-friendly isn't the characteristic of several protocols, >nor it is a requirement. So, IPComp isn't alone. I agree, I'm not questioning protocol quality (sorry if my English leads you to misunderstand). I just would like to know how we should update RFC2367 for IPComp. >> What kind of userland API do you expect to see? I'm now using dummy >> SPI (= CPI) to designate the SA database entry for compression, >> and add a flag to force the use of well-known CPI on the packet. >The RFC reflects the decision of the ippcp wg in the meeting >in Washington, DC (Dec 97) > It was also decided not to restrict the CPI values 0-63 only for manual > setup but also use it for ISAKMP for well known algorithms. >I don't recall any discussion in the wg or on the list regarding >"userland API." If the API doesn't fit the protocols, shouldn't >the API be adjusted? Yes of course, but the question is, what kind of changes are necessary. PFKEY is used for both manual key setups (from userland program to manipulate manual keys) and autoconfigured keys (from IKE daemons). I've described my quickhack above. itojun From owner-ipsec@lists.tislabs.com Wed Jun 16 08:17:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28595; Wed, 16 Jun 1999 08:17:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20100 Wed, 16 Jun 1999 09:03:29 -0400 (EDT) Message-Id: <199906160721.LAA01404@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, Tero Kivinen Date: Wed, 16 Jun 1999 11:21:21 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt In-reply-to: <199906152206.BAA01501@torni.ssh.fi> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 16 Jun 99 at 1:06, Tero Kivinen wrote: [...] > I would really like to see two new kind of notifications here: > > Initiator Responder > ----------- ----------- > HDR, SIG, [CERTs], Ni, N/D --> > > Where SIG (MUST be first payload) is signature of the HASH of the rest > of the payload. This would allow sending delete and error notification > payloads to the responder even when we do not have ISAKMP SA up yet > (for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)). > > In this case the SIG should also define the HASH algorithm to use, so > we should either use signature format that contains it or define it > somewhere else. What about the situation when Responder doesn't support signatures at all (i.e. performs only preshared key authentication) or supports different signature algorithm from that you've used to sign this message? In your example (sending NO-PROPOSAL-CHOSEN in phase 1) it will often be the case, making such notification almost useless. Also, such notification increases IKE vulnerability to DoS attack. [...] > > The acknowledged Informational exchange is open to replay attacks. > > There should also be comment here, that main mode (identity > protection) is open to man in the middle attack, that will reveal > initiators identity. As far as I understand, it is true for signature authentication methods only and isn't true for the other methods. Regards, Valery. From owner-ipsec@lists.tislabs.com Wed Jun 16 08:19:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28660; Wed, 16 Jun 1999 08:19:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20181 Wed, 16 Jun 1999 09:07:25 -0400 (EDT) Message-ID: <3767A42F.A3E61871@checkpoint.com> Date: Wed, 16 Jun 1999 16:18:39 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt References: <199906152206.BAA01501@torni.ssh.fi> <3767921A.2133D3EF@checkpoint.com> <199906161253.PAA05856@torni.ssh.fi> Content-Type: multipart/alternative; boundary="------------50D540710AC44DB6229C9B1E" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------50D540710AC44DB6229C9B1E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > Tamir Zegman writes: > > I'd like to comment that due to the symmetric nature of IKE SA's (an > > IKE peer can use the same IKE SA for both encryption and > > decryption), it seems difficult to enforce a limitation on the > > number of negotiations or the amount of data encrypted with the IKE > > SA. Since packets can get lost (especially notifications) the two > > IKE peers can get out of sync regarding the number of negotiations > > they had or the amount of data they encrypted. This can lead to a > > scenario in which one side thinks that > > In encrypted data yes, in negotiations they cannot. When we send > packet out we encrypt it only once, if that packet gets lost then we > retransmit already encrypted packet, thus we do not encrypt it again. > If any of those packets never reaches the destination, we time out the > negotiation. Timing out negotiations should quite rare, it normally > means that the network connection is broken or the other end rebooted. > > If the other end rebooted, then this is non issue, because it doesn't > have the ISAKMP SA up anymore, so we can remove the ISAKMP SA > immediately. If the network connection is broken, then there isn't > really anything we can do, and is is almost impossble to > distinguishing broken network connection from the reboot of the other > end (when the other end has policy that it doesn't send any > notifications back). In both cases we can just delete the ISAKMP SA > and retry creating the ISAKMP SA, to see if that helps. > > The negotiation lifetime counter is only incremented when IPSEC SA is > really created (thus when we create keying material for it and use > SKEYID_d for that). This means that only way we can get out of sync is > that network breaks down after second packet of the quick mode, but > before the initiator has possibility to send the final third packet. > In this case initiator has one negotiation more than the responder > has. Actually this is correct, because initiator has already consumed > entropy from the SKEYID_d when it created the IPSEC SA and the > responder hasn't done that yet. > > And getting out of sync isn't really a problem. It just means other > end will just delete the ISAKMP SA earlier. When we have acknoledged > deletes then this is not really a problem. > > Ok, I get your point, so let me ask you another question, what is a negotiation? Is a notification a separate negotiation? Is new group mode counted? What about IKE config? --------------50D540710AC44DB6229C9B1E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tero Kivinen wrote:

Tamir Zegman writes:
> I'd like to comment that due to the symmetric nature of IKE SA's (an
> IKE peer can use the same IKE SA for both encryption and
> decryption), it seems difficult to enforce a limitation on the
> number of negotiations or the amount of data encrypted with the IKE
> SA. Since packets can get lost (especially notifications) the two
> IKE peers can get out of sync regarding the number of negotiations
> they had or the amount of data they encrypted. This can lead to a
> scenario in which one side thinks that

In encrypted data yes, in negotiations they cannot. When we send
packet out we encrypt it only once, if that packet gets lost then we
retransmit already encrypted packet, thus we do not encrypt it again.
If any of those packets never reaches the destination, we time out the
negotiation. Timing out negotiations should quite rare, it normally
means that the network connection is broken or the other end rebooted.

If the other end rebooted, then this is non issue, because it doesn't
have the ISAKMP SA up anymore, so we can remove the ISAKMP SA
immediately. If the network connection is broken, then there isn't
really anything we can do, and is is almost impossble to
distinguishing broken network connection from the reboot of the other
end (when the other end has policy that it doesn't send any
notifications back). In both cases we can just delete the ISAKMP SA
and retry creating the ISAKMP SA, to see if that helps.

The negotiation lifetime counter is only incremented when IPSEC SA is
really created (thus when we create keying material for it and use
SKEYID_d for that). This means that only way we can get out of sync is
that network breaks down after second packet of the quick mode, but
before the initiator has possibility to send the final third packet.
In this case initiator has one negotiation more than the responder
has. Actually this is correct, because initiator has already consumed
entropy from the SKEYID_d when it created the IPSEC SA and the
responder hasn't done that yet.

And getting out of sync isn't really a problem. It just means other
end will just delete the ISAKMP SA earlier. When we have acknoledged
deletes then this is not really a problem.
 
 

Ok, I get your point, so let me ask you another question, what is a negotiation?
Is a notification a separate negotiation?
Is new group mode counted?
What about IKE config?
  --------------50D540710AC44DB6229C9B1E-- From owner-ipsec@lists.tislabs.com Wed Jun 16 08:52:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28904; Wed, 16 Jun 1999 08:52:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20255 Wed, 16 Jun 1999 09:28:23 -0400 (EDT) Message-ID: <3767A7DC.EB16AC6A@ire-ma.com> Date: Wed, 16 Jun 1999 09:34:20 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff References: <199906151954.MAA21779@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > It was suggested that a keepalive mechanism be built into IKE. Several people > already have proprietary keepalive mechanisms in their implementations. > Perhaps the person(s) who brought this up will write up a draft specifying > how this is to be done. It may take some time to write and agree to such draft. Could we meanwhile design some simple (which may not be 100% bullet-proff) logic around unprotected INVALID_SPI notifications that rebooted node most likely to send to another party which is unaware of the re-booted partner and keep sending encrypted traffic to it? -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec@lists.tislabs.com Wed Jun 16 08:58:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28951; Wed, 16 Jun 1999 08:58:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20303 Wed, 16 Jun 1999 09:39:54 -0400 (EDT) Date: Wed, 16 Jun 1999 16:49:10 +0300 (EET DST) Message-Id: <199906161349.QAA07674@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tamir Zegman Cc: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt In-Reply-To: <3767A42F.A3E61871@checkpoint.com> References: <199906152206.BAA01501@torni.ssh.fi> <3767921A.2133D3EF@checkpoint.com> <199906161253.PAA05856@torni.ssh.fi> <3767A42F.A3E61871@checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tamir Zegman writes: > Ok, I get your point, so let me ask you another question, what is a > negotiation? In my first mail I defined it like this: ---------------------------------------------------------------------- The negotiations should be defined so that all negotiations that use SKEYID_d (consumes entropy from it) is counted as one negotiation, those negotiations which do not use it (notifications, new group mode etc) are not counted as negotiations here. ---------------------------------------------------------------------- I agree that negotiation is bad word for that, perhaps we should use some other. I don't want to use "quick mode negotiations" because if somebody add new negotiation that is similar than quick mode then this would not cover it. > Is a notification a separate negotiation? It doesn't consume any entropy from the SKEYID_d so it is not counted. > Is new group mode counted? It doesn't consume any entropy from the SKEYID_d so it is not counted. > What about IKE config? It doesn't consume any entropy from the SKEYID_d so it is not counted. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 16 11:32:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00696; Wed, 16 Jun 1999 11:32:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20978 Wed, 16 Jun 1999 12:32:34 -0400 (EDT) From: Dan McDonald Message-Id: <199906161641.JAA22826@kebe.Eng.Sun.COM> Subject: Re: issues from the bakeoff To: itojun@itojun.org (Jun-ichiro itojun Hagino) Date: Wed, 16 Jun 1999 09:41:37 -0700 (PDT) Cc: shacham@cisco.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <23795.929503385@coconut.itojun.org> from "Jun-ichiro itojun Hagino" at Jun 16, 99 12:23:05 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Well-known CPI is not very friendly with PFKEY interface (RFC2367). > RFC2367 expects unique SPI per peer (which can embed CPI in lower > 2 bytes), but for well-known CPI we can't. Why is this an issue? You can treat the well-known CPI as a pre-added compression association, which, if you use SADB_GET, would reveal a match. If you tried to ADD/UPDATE, you'd just get EEXIST. > What kind of userland API do you expect to see? I'm now using dummy > SPI (= CPI) to designate the SA database entry for compression, > and add a flag to force the use of well-known CPI on the packet. The user app would ask for compression (or not complain if it showed up) on a per-socket basis. I don't see the problem here. Dan From owner-ipsec@lists.tislabs.com Wed Jun 16 19:23:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA09792; Wed, 16 Jun 1999 19:23:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22426 Wed, 16 Jun 1999 20:20:21 -0400 (EDT) Message-ID: <37684195.C37EF28D@redcreek.com> Date: Wed, 16 Jun 1999 17:30:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-notifymsg-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For around a year or so (maybe longer), Bob has been trying to get someone to work on an "ipsec errors" draft. I agreed to do it at the Minneapolis IETF, and have finally completed the first rev of the draft - I just submitted it, so the announcement should hit the list in the next day or so. The draft details the various ISAKMP notify messages, and suggests what should be contained in the notify payloads so that the recipient can determine which SA it applies to, what actually happened, etc. The formats mimic the ones for ipsec (as opposed to isakmp) status messages in the DOI RFC. Ultimately, we may want to include other ipsec-related error/status messages in the discussion, but I didn't want to bite off too much at first. Going through each of the notify types is pretty tedious, and I'm as busy as everyone else, so I want to say up front that there are probable plenty of typos and mistakes. The point of submitting the doc now is to try to solicit comments before Oslo. It's possible that I could actually submit another rev before the deadline, given enough wg input. The bottom line is that I'm hoping people have definite ideas about (at least) some of these messages, and that we can incorporate these in the doc asap. Scott From owner-ipsec@lists.tislabs.com Thu Jun 17 07:54:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA15370; Thu, 17 Jun 1999 07:54:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24151 Thu, 17 Jun 1999 08:41:07 -0400 (EDT) To: Dan McDonald cc: shacham@cisco.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com In-reply-to: danmcd's message of Wed, 16 Jun 1999 09:41:37 MST. <199906161641.JAA22826@kebe.Eng.Sun.COM> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: issues from the bakeoff From: itojun@iijlab.net Date: Thu, 17 Jun 1999 08:57:08 +0900 Message-ID: <10331.929577428@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Well-known CPI is not very friendly with PFKEY interface (RFC2367). >> RFC2367 expects unique SPI per peer (which can embed CPI in lower >> 2 bytes), but for well-known CPI we can't. >Why is this an issue? >You can treat the well-known CPI as a pre-added compression association, >which, if you use SADB_GET, would reveal a match. If you tried to >ADD/UPDATE, you'd just get EEXIST. We need to put explicit (src, dst, cpi) set into the kernel, as we never specify cpi/spi from policy management routines. spi/cpi will be picked by the kernel. Therefore, we need to configure (src, dst, cpi) explicitly (cannot be preloaded). For inbound direction, there is no issue - we can accept any packet with well-known CPI. For outbound direction I'm sure we have issues to be solved. itojun From owner-ipsec@lists.tislabs.com Thu Jun 17 08:18:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15631; Thu, 17 Jun 1999 08:18:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24388 Thu, 17 Jun 1999 09:22:21 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB67D77@exchange> From: Stephane Beaulieu To: Tamir Zegman Cc: ipsec@lists.tislabs.com Subject: RE: Comments about draft-ietf-ipsec-ike-01.txt Date: Thu, 17 Jun 1999 09:34:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 JAA24385 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What's wrong with one peer thinking that it's IKE SA is used up before the other peer does?  If one peer notices that an IKE SA is about to expire, he should establish a new one and send a DELETE for the old one.   Date: Thu, 17 Jun 1999 10:30:38 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: SA Recovery (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB67DD8@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Tim, I agree that active keep-alive will solve the problem, but it will take some time to agree on the standard for that. In the interim I was trying to stimulate discussion on the use of usually long series of INVALID_SPI messages from the re-booted node, which are unfortunately unprotected, but may contain some "clue" of their authenticity. Tim Jenkins wrote: > Slava, > > In the absence of keep-alives, this procedure can be used to allow recovery > after one entity has died and recover. > > Basically, the recovered entity will receive encrypted traffic from a peer > with SPI values that it doesn't understand. The assumption is that the peer > had valid SAs with it that it lost when it died. > > In order to tell the peer that the SA (and any others it may think it had > with it) are invalid is to set up a phase 1 SA with it that includes the > initial contact notification. Receipt of the initial contact notification > should cause the peer sending the packets with invalid SPIs to clear all its > SAs and re-establish new ones. > > A similar approach can be used if an entity receives phase 1 packets with > invalid cookies. > > The problems with this approach are: > 1) Need main mode to authenticate initial contact (unless use of the > encrypted aggressive mode three message with initial contact is okay, but > that's currently prohibited.) > 2) There may be no specific knowledge of the peer that's sending the invalid > SPIs by the entity that's recovered, so initiating back presents a form of > DOS attack if the SPI-sending peer is an attacker that is intentionally > sending packets with bogus SPI values. > > That's why there is a need for SA management while the SAs are up, so that > crash recovery can be active, rather than reactive. > > Tim > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > -----Original Message----- > > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > > Sent: June 16, 1999 9:34 AM > > To: Dan Harkins > > Cc: ipsec@lists.tislabs.com > > Subject: Re: issues from the bakeoff > > > > > > Dan Harkins wrote: > > > > > > > > It was suggested that a keepalive mechanism be > > built into IKE. Several people > > > already have proprietary keepalive mechanisms in > > their implementations. > > > Perhaps the person(s) who brought this up will > > write up a draft specifying > > > how this is to be done. > > > > It may take some time to write and agree to such draft. Could > > we meanwhile design some simple > > (which may not be 100% bullet-proff) logic around > > unprotected INVALID_SPI notifications that > > rebooted node most likely to send to another party which is > > unaware of the re-booted partner > > and keep sending encrypted traffic to it? > > > > > > -- > > Bronislav Kavsan > > IRE Secure Solutions, Inc. > > 100 Conifer Hill Drive Suite 513 > > Danvers, MA 01923 > > voice: 978-739-2384 > > http://www.ire.com > > > > > > -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec@lists.tislabs.com Thu Jun 17 09:33:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16827; Thu, 17 Jun 1999 09:33:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24508 Thu, 17 Jun 1999 10:07:45 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB67DD8@exchange> From: Tim Jenkins To: Slava Kavsan Cc: ipsec@lists.tislabs.com Subject: SA Recovery (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 10:19:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava, In the absence of keep-alives, this procedure can be used to allow recovery after one entity has died and recover. Basically, the recovered entity will receive encrypted traffic from a peer with SPI values that it doesn't understand. The assumption is that the peer had valid SAs with it that it lost when it died. In order to tell the peer that the SA (and any others it may think it had with it) are invalid is to set up a phase 1 SA with it that includes the initial contact notification. Receipt of the initial contact notification should cause the peer sending the packets with invalid SPIs to clear all its SAs and re-establish new ones. A similar approach can be used if an entity receives phase 1 packets with invalid cookies. The problems with this approach are: 1) Need main mode to authenticate initial contact (unless use of the encrypted aggressive mode three message with initial contact is okay, but that's currently prohibited.) 2) There may be no specific knowledge of the peer that's sending the invalid SPIs by the entity that's recovered, so initiating back presents a form of DOS attack if the SPI-sending peer is an attacker that is intentionally sending packets with bogus SPI values. That's why there is a need for SA management while the SAs are up, so that crash recovery can be active, rather than reactive. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: June 16, 1999 9:34 AM > To: Dan Harkins > Cc: ipsec@lists.tislabs.com > Subject: Re: issues from the bakeoff > > > Dan Harkins wrote: > > > > > It was suggested that a keepalive mechanism be > built into IKE. Several people > > already have proprietary keepalive mechanisms in > their implementations. > > Perhaps the person(s) who brought this up will > write up a draft specifying > > how this is to be done. > > It may take some time to write and agree to such draft. Could > we meanwhile design some simple > (which may not be 100% bullet-proff) logic around > unprotected INVALID_SPI notifications that > rebooted node most likely to send to another party which is > unaware of the re-booted partner > and keep sending encrypted traffic to it? > > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > > From owner-ipsec@lists.tislabs.com Thu Jun 17 10:39:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17695; Thu, 17 Jun 1999 10:39:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24843 Thu, 17 Jun 1999 11:27:49 -0400 (EDT) Date: Thu, 17 Jun 1999 11:35:57 -0400 Message-Id: <199906171535.LAA19881@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkavsan@ire-ma.com Cc: tjenkins@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: SA Recovery (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB67DD8@exchange> <3769068E.47D736F8@ire-ma.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> Thanks Tim, I agree that active keep-alive will solve the Slava> problem, but it will take some time to agree on the standard Slava> for that. Slava> In the interim I was trying to stimulate discussion on the use Slava> of usually long series of INVALID_SPI messages from the Slava> re-booted node, which are unfortunately unprotected, but may Slava> contain some "clue" of their authenticity. I've wanted that too, but I haven't been able to come up with a scheme that feels at all comfortable as far as Denial of Service vulnerability. You're suggesting that a message might have some clue of its authenticity -- such as what? I agree that this is possible for the case where I delete an SA and for some reason the other end does not (I can remember the SPI I deleted for a while). But it's hard to see how a freshly rebooted node can look at an incoming SPI, which is typically a random number, and distinguish a valid random number from an invalid one. Rate limiting the recovery mechanisms may help. But I'd rather push harder on the keep-alive solution. Supposedly there are already implementation of proprietary schemes, and it seems to me that in any case the mechanism needed is really trivial. How long can it take to define such a beast? (In other words, can it take significantly longer than the invalid_spi driven recovery mechanisms? I wonder.) paul From owner-ipsec@lists.tislabs.com Thu Jun 17 12:27:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19277; Thu, 17 Jun 1999 12:27:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25254 Thu, 17 Jun 1999 13:11:44 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBD42@new-exc1.ctron.com> From: "Waters, Stephen" To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: SA Recovery (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 18:19:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, A quick proposal for tunnel keep-alive: The client pings the Security Gateway on a configurable timer once the IPSEC-SA is connected. The policy should allow responses to protected pings terminating at the security gateway. A counter of missed echo-replies since the last echo-rely is kept which is reset to zero whenever a reply is received. A configurable miss-replies threshold is used to determine when the SA is 'dead'. When the SA dies, the client deletes the outgoing SA and inbound SA and restarts at Phase1 with the remote security gateway. If the security gateway remains 'unreachable' (more timers and thresholds), the client can try other security gateways. How does that sound? For remote access, I am only really interested in the client detecting that the security gateway has become unreachable. For LAN-LAN, this mechanism can be used symmetrically. In time, it may be possible to define formatted data in the ping payload to allow SLA/QOS info to be exchange between tunnel peers. Since ping data is meaningless to non-participating remote system, this will be treated just like any other ping. Cheers, Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, June 17, 1999 3:19 PM To: Slava Kavsan Cc: ipsec@lists.tislabs.com Subject: SA Recovery (was RE: issues from the bakeoff) Slava, In the absence of keep-alives, this procedure can be used to allow recovery after one entity has died and recover. Basically, the recovered entity will receive encrypted traffic from a peer with SPI values that it doesn't understand. The assumption is that the peer had valid SAs with it that it lost when it died. In order to tell the peer that the SA (and any others it may think it had with it) are invalid is to set up a phase 1 SA with it that includes the initial contact notification. Receipt of the initial contact notification should cause the peer sending the packets with invalid SPIs to clear all its SAs and re-establish new ones. A similar approach can be used if an entity receives phase 1 packets with invalid cookies. The problems with this approach are: 1) Need main mode to authenticate initial contact (unless use of the encrypted aggressive mode three message with initial contact is okay, but that's currently prohibited.) 2) There may be no specific knowledge of the peer that's sending the invalid SPIs by the entity that's recovered, so initiating back presents a form of DOS attack if the SPI-sending peer is an attacker that is intentionally sending packets with bogus SPI values. That's why there is a need for SA management while the SAs are up, so that crash recovery can be active, rather than reactive. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: June 16, 1999 9:34 AM > To: Dan Harkins > Cc: ipsec@lists.tislabs.com > Subject: Re: issues from the bakeoff > > > Dan Harkins wrote: > > > > > It was suggested that a keepalive mechanism be > built into IKE. Several people > > already have proprietary keepalive mechanisms in > their implementations. > > Perhaps the person(s) who brought this up will > write up a draft specifying > > how this is to be done. > > It may take some time to write and agree to such draft. Could > we meanwhile design some simple > (which may not be 100% bullet-proff) logic around > unprotected INVALID_SPI notifications that > rebooted node most likely to send to another party which is > unaware of the re-booted partner > and keep sending encrypted traffic to it? > > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > > From owner-ipsec@lists.tislabs.com Thu Jun 17 12:35:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19324; Thu, 17 Jun 1999 12:35:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25337 Thu, 17 Jun 1999 13:21:52 -0400 (EDT) Message-ID: <71B30BC67510D31184030090277A3DDE13851B@mail.altiga.com> From: "Volpe, Victor" To: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: issues from the bakeoff Date: Thu, 17 Jun 1999 13:29:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One of the biggest issues we ran into was the handling of Phase 1 rekeying. We found that quite a few implementations simply drop the Phase 1 SA when it expires and leave the Phase 2 SAs up. Our implementation does not allow "orphan" Phase 2 SAs to be left around so we take them all down when we receive the delete message (if there is a new Phase 1 SA, we transfer all the Phase 2 SAs to the new one). We are then left with some period of time where one side is sending data over an SPI that has been deleted by the other side. This goes on until the Phase 2 SAs rekey and then the problem clears up. This is one of those issues that will not be affected by the confirmed delete and is really just an interpretation of the spec. In my opinion, Orphan Phase 2 SAs are not a good thing for a number of reasons. I guess many others do not agree. What is the right thing to do here? I apologize if this has been talked about in the past. Victor > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Tuesday, June 15, 1999 3:55 PM > To: ipsec@lists.tislabs.com > Subject: issues from the bakeoff > > > There was an IPSec + L2TP (and PPoE too) bakeoff the week > of May 24th. > As usual there were issues in interoperability that came up and I'm > presenting them to the list. Not too surprisingly there were > no issues > with interoperability of the IPSec protocols, it's all IKE. > Also there > were several IPPCP issues that I'll summarize although they're being > taken care of in a different working group in a different area. > > I'll mention the general consensus of people at the bakeoff > but that's > just as a starting point for discussion. The resolution (if > any) of these > issues is work for this group. Please comment to the list. > > thanks, > > Dan. > > -------------------------------------------------------------- > ------------ > > *) The Commit Bit > > - Should this be mandatory for every single QM? The > consensus was > no. QM seems to behave fine when the commit bit is not set and > the only difference is the small window of opportunity for > packet loss. > > - There was a desire to weaken the requirement that if the bit > is set by either party then it indicates the 4th message must > be sent. It was proposed that if the peer didn't acknowledge > the commit bit in the next message that the peer was > not willing > to do it. This didn't get too much support. > > - Does the bit have to be set in all messages after the > first? That > is not stated in the RFC and we've approached these > issues in the > past in an unsoviet-like manner: if it's not > forbidden it's allowed. > So, no it doesn't have to be. > > *) ID issues > > - Are all ISAKMP/DOI identities valid in phase 2? And > can pre-shared > keys be used with any ISAKMP/DOI identity? The DOI deals with > phase 2 negotiation and the identities it defines are > for phase 2. > But the IKE and DOI authors agreed to include some > text in their > respective documents that clarified which identities > are valid when. > > - How are subnet ids represented? Is > 10.20.30.5/255.255.255.0 valid > or does it have to be 10.20.30.0/255.255.255.0? The > desire to use > the former was because some extra information was > being gleaned > from the "5" by the implementation that did this. Since subnet > identities are only used by intermediate networking devices it > would seem to make sense to require subnet identities > to be the > same as any routing advertisement this device would > make. Mentioning > RFC1519 in the DOI would do the trick. Is this > something that should > be done? > > *) Lifetimes > > - What is The Right Thing (tm) to do when mismatched > lifetimes are > seen in phase 1 or phase 2? The DOI discusses what to > do in phase 2 > and the new IKE draft attempts (very poorly) to > describe what to > do in phase 1. It is entirely permissible to refuse > the negotiation > or to accept it and just stick to the locally > configured lifetime. > The text in the IKE draft is being rewritten. > > *) Rekeying > > - There were statements like "we occasionally get out > of sync" or "there > are stalls". > > - There was confusion over when to stop using the old SA. > > - When a 2nd IKE SA is established should the old one > be deleted even if > the lifetime hasn't expired? > > It is believed that all these issues can be resolved if > the use of the > acknowledged delete message (in the new IKE draft) was > made mandatory for > both phase 1 and phase 2. So text mandating the use of > this exchange when > deleting any SA will be inserted. > > *) Failover and Recovery > > - If a peer crashes and reboots its SA state is lost. > How to sync back up? > One solution is for the box that rebooted to send and > unprotected delete > message causing the box that didn't reboot to clear > its SAs and begin > an IKE exchange. The other is for the peer that > rebooted to begin an IKE > exchange when it receives IPSec packets for which it > has no SA. Both are > problematic. > > It was suggested that a keepalive mechanism be built > into IKE. Several people > already have proprietary keepalive mechanisms in > their implementations. > Perhaps the person(s) who brought this up will write > up a draft specifying > how this is to be done. > > *) Certificate Requests > > - Is a NULL certificate request valid? What does it > mean? Apparently it is valid > but there was discussion on what it meant. "Send me > all your certs" seemed > to be the winner. The trust model for such behavior > was not well explained > though. This is really an item for the WG to decide. > > - If a certificate request is issued in the first > message of Main Mode should > the peer respond back with his certs in the 2nd > message and thereby break the > identity protection feature of Main Mode? The > consensus was no. RFC2408 doesn't > seem to say that the certs have to be in the _next_ > message only that they > have to be sent. > > - What is the order of certs in a chain and does it > make any difference? The > consensus was that there is no order and it doesn't > make any difference. > > *) Misc > > - Do implementations have to accept an encrypted > final Aggressive Mode message? > Yes they do. > > - Does the order of ANDed offers make any difference in > IPSec encapsulation? No > it doesn't. > > - If the responder sends a "no proposal chosen" in > response to an initial phase > 1 message does he have to send a responder cookie? > Yes he does. > > - Can transform numbers in the transform payload begin > anywhere and do they > have to be sequential? Regrettably, it's yes and no. > > - Is it OK to send 3 copies of every single message > (which one implementation > was doing)? Yes. > > IP Payload Compresion Protocol (PCP) Issues: > > As I said, these aren't IPSec WG issues but people are > using IKE to negotiate PCP and > these things came up. The appropriate WG needs to deal with these. > > - IKE requires consistent attributes accross Quick > Mode negotiation. For instance, > when doing PFS the group must be in all offers and it > has to be the same group. > What about PCP? Since it has no keys does it need a > group definition if the > accompanying IPSec SAs will have PFS? > > - Do lifetimes in PCP SAs make sense to negotiate? If > so, does a KB lifetime > expire on pre- or post-compressed data? > > - Is it valid to pass a SPI (actually a CPI in PCP) of > zero? Is this the "well > known CPI"? > > - A CPI is two bytes. Is it OK to send a 4 byte one and > have the upper two bytes > be zero? > > - A PCP RFC seems to say that tunnel mode processing is > not possible. Is this true? > > From owner-ipsec@lists.tislabs.com Thu Jun 17 13:06:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19862; Thu, 17 Jun 1999 13:06:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25499 Thu, 17 Jun 1999 13:48:54 -0400 (EDT) Message-Id: <4.1.19990617135435.00a81530@pop.erols.com> X-Sender: jehorton@pop.erols.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 17 Jun 1999 13:56:48 -0400 To: "Waters, Stephen" , Tim Jenkins From: "John E. Horton" Subject: RE: SA Recovery (was RE: issues from the bakeoff) Cc: ipsec@lists.tislabs.com In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBD42@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen - Clear traffic ICMP messages generated by a client on a LAN behind a FW blocking ICMP will cause a problem for this proposal. IPSEC Encapsulated ICMPs to the gateway would work. Regards, John Horton At 06:19 PM 6/17/99 +0100, Waters, Stephen wrote: >Hi, > >A quick proposal for tunnel keep-alive: > >The client pings the Security Gateway on a configurable timer once the >IPSEC-SA is connected. The policy should allow responses to protected pings >terminating at the security gateway. > >A counter of missed echo-replies since the last echo-rely is kept which is >reset to zero whenever a reply is received. > >A configurable miss-replies threshold is used to determine when the SA is >'dead'. When the SA dies, the client deletes the outgoing SA and inbound SA >and restarts at Phase1 with the remote security gateway. If the security >gateway remains 'unreachable' (more timers and thresholds), the client can >try other security gateways. > >How does that sound? For remote access, I am only really interested in the >client detecting that the security gateway has become unreachable. For >LAN-LAN, this mechanism can be used symmetrically. > >In time, it may be possible to define formatted data in the ping payload to >allow SLA/QOS info to be exchange between tunnel peers. Since ping data is >meaningless to non-participating remote system, this will be treated just >like any other ping. > >Cheers, Steve. > > > > > >-----Original Message----- >From: Tim Jenkins [mailto:tjenkins@TimeStep.com] >Sent: Thursday, June 17, 1999 3:19 PM >To: Slava Kavsan >Cc: ipsec@lists.tislabs.com >Subject: SA Recovery (was RE: issues from the bakeoff) > > >Slava, > >In the absence of keep-alives, this procedure can be used to allow recovery >after one entity has died and recover. > >Basically, the recovered entity will receive encrypted traffic from a peer >with SPI values that it doesn't understand. The assumption is that the peer >had valid SAs with it that it lost when it died. > >In order to tell the peer that the SA (and any others it may think it had >with it) are invalid is to set up a phase 1 SA with it that includes the >initial contact notification. Receipt of the initial contact notification >should cause the peer sending the packets with invalid SPIs to clear all its >SAs and re-establish new ones. > >A similar approach can be used if an entity receives phase 1 packets with >invalid cookies. > >The problems with this approach are: >1) Need main mode to authenticate initial contact (unless use of the >encrypted aggressive mode three message with initial contact is okay, but >that's currently prohibited.) >2) There may be no specific knowledge of the peer that's sending the invalid >SPIs by the entity that's recovered, so initiating back presents a form of >DOS attack if the SPI-sending peer is an attacker that is intentionally >sending packets with bogus SPI values. > >That's why there is a need for SA management while the SAs are up, so that >crash recovery can be active, rather than reactive. > >Tim > >--- >Tim Jenkins TimeStep Corporation >tjenkins@timestep.com http://www.timestep.com >(613) 599-3610 x4304 Fax: (613) 599-3617 > > > >> -----Original Message----- >> From: Slava Kavsan [mailto:bkavsan@ire-ma.com] >> Sent: June 16, 1999 9:34 AM >> To: Dan Harkins >> Cc: ipsec@lists.tislabs.com >> Subject: Re: issues from the bakeoff >> >> >> Dan Harkins wrote: >> >> > >> > It was suggested that a keepalive mechanism be >> built into IKE. Several people >> > already have proprietary keepalive mechanisms in >> their implementations. >> > Perhaps the person(s) who brought this up will >> write up a draft specifying >> > how this is to be done. >> >> It may take some time to write and agree to such draft. Could >> we meanwhile design some simple >> (which may not be 100% bullet-proff) logic around >> unprotected INVALID_SPI notifications that >> rebooted node most likely to send to another party which is >> unaware of the re-booted partner >> and keep sending encrypted traffic to it? >> >> >> -- >> Bronislav Kavsan >> IRE Secure Solutions, Inc. >> 100 Conifer Hill Drive Suite 513 >> Danvers, MA 01923 >> voice: 978-739-2384 >> http://www.ire.com >> >> >> From owner-ipsec@lists.tislabs.com Thu Jun 17 13:23:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19983; Thu, 17 Jun 1999 13:23:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25679 Thu, 17 Jun 1999 14:25:43 -0400 (EDT) Message-ID: <37693FAD.DA644C69@cs.stanford.edu> Date: Thu, 17 Jun 1999 11:34:22 -0700 From: Brian Korver Reply-To: briank@briank.com X-Mailer: Mozilla 4.51 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff References: <199906151954.MAA21779@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: [snip] >*) Certificate Requests > > - Is a NULL certificate request valid? What does it mean? Apparently it is valid > but there was discussion on what it meant. "Send me all your certs" seemed > to be the winner. The trust model for such behavior was not well explained > though. This is really an item for the WG to decide. In sig mode, by the time the recipient receives this message, the recipient already knows they are in sig mode and thus will need to send certificates. Becuase a NULL CERTREQ must mean "send me all your certs" (and I believe this is consistent with the ISAKMP spec), I propose adding language to the spec like: A CERTREQ message with an empty payload conveys to the recipient that an entire certificate chain should be returned (optionally excluding the root, which must already be shared for authentication to succeed). However, absent knowledge that the recipient unambiguously knows which chain to use, the sender of the CERTREQ message SHOULD include a name in the CERTREQ message. Absent other CERTREQ messages, the recipient of an empty CERTREQ message MUST respond with their entire certificate chain (again, optionally exluding the root). > > - If a certificate request is issued in the first message of Main Mode should > the peer respond back with his certs in the 2nd message and thereby break the > identity protection feature of Main Mode? The consensus was no. RFC2408 doesn't > seem to say that the certs have to be in the _next_ message only that they > have to be sent. Agreed. > > - What is the order of certs in a chain and does it make any difference? The > consensus was that there is no order and it doesn't make any difference. Agreed. brian briank@cs.stanford.edu (play) briank@network-alchemy.com (work) From owner-ipsec@lists.tislabs.com Thu Jun 17 13:24:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20005; Thu, 17 Jun 1999 13:24:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25654 Thu, 17 Jun 1999 14:22:29 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB67F71@exchange> From: Tim Jenkins To: "Volpe, Victor" , ipsec@lists.tislabs.com Subject: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 14:34:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phase 1 re-keying is discussed in some detail in . Also, the act of orphaning phase 2 SAs (as described below) in my mind is both unnecessary and also insecure, since the phase 1 SA is what bounds the authenticated lifetime of the end points. So to leave a phase 2 SA up without a valid phase 1 SA is to let it live beyond its allowed limits. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Volpe, Victor [mailto:vvolpe@altiga.com] > Sent: June 17, 1999 1:30 PM > To: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: RE: issues from the bakeoff > > > One of the biggest issues we ran into was the handling of > Phase 1 rekeying. > We found that quite a few implementations simply drop the > Phase 1 SA when it > expires and leave the Phase 2 SAs up. Our implementation > does not allow > "orphan" Phase 2 SAs to be left around so we take them all > down when we > receive the delete message (if there is a new Phase 1 SA, we > transfer all > the Phase 2 SAs to the new one). We are then left with some > period of time > where one side is sending data over an SPI that has been > deleted by the > other side. This goes on until the Phase 2 SAs rekey and > then the problem > clears up. > > This is one of those issues that will not be affected by the confirmed > delete and is really just an interpretation of the spec. In > my opinion, > Orphan Phase 2 SAs are not a good thing for a number of > reasons. I guess > many others do not agree. > > What is the right thing to do here? > > I apologize if this has been talked about in the past. > > Victor > From owner-ipsec@lists.tislabs.com Thu Jun 17 13:25:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20014; Thu, 17 Jun 1999 13:25:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25666 Thu, 17 Jun 1999 14:23:50 -0400 (EDT) Message-Id: <199906171832.LAA04029@potassium.network-alchemy.com> To: "Volpe, Victor" cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff In-reply-to: Your message of "Thu, 17 Jun 1999 13:29:31 EDT." <71B30BC67510D31184030090277A3DDE13851B@mail.altiga.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4026.929644355.1@network-alchemy.com> Date: Thu, 17 Jun 1999 11:32:35 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that if you take an arbitrary action like this then you should actively do something to recover. That is, if you decide to delete all IPSec SAs that were created by an IKE SA that was deleted (for whatever reason) then you should initiate a phase 1 exchange back to the peer. But it doesn't seem to me to be necessary to delete IPSec SAs just because an IKE SA has deleted (I anticipate emails posing the "what about an SA that was authenticated with a certificate that expires during the SA's lifetime?" question). It was OK to create IPSec SAs at one time and I don't see anything changing that just because the IKE SA timed out. From your description it doesn't even sound like you'd rekey with yourself. There would still be a short period (equal to the time necessary to do full renegotiation) where packets would be dropped if one side arbitrarily cleared the IKE SADB. That should tell you something about whether your actions are correct. If you drop packets during a rekey with yourself then you're doing something wrong. If you strongly feel that IPSec SAs have to retire when the IKE SA which created them does then at least keep them around for a short period of time while you renegotiate them. Artificially aging them to (2 * ave-renegotiation-time +- some-fuzz-factor) would seem the prudent thing to do. That will enable you to continue to process packets while you renegotiate. And re-initiate the phase 1 exchange since you're taking this action. Dan. On Thu, 17 Jun 1999 13:29:31 EDT you wrote > One of the biggest issues we ran into was the handling of Phase 1 rekeying. > We found that quite a few implementations simply drop the Phase 1 SA when it > expires and leave the Phase 2 SAs up. Our implementation does not allow > "orphan" Phase 2 SAs to be left around so we take them all down when we > receive the delete message (if there is a new Phase 1 SA, we transfer all > the Phase 2 SAs to the new one). We are then left with some period of time > where one side is sending data over an SPI that has been deleted by the > other side. This goes on until the Phase 2 SAs rekey and then the problem > clears up. > > This is one of those issues that will not be affected by the confirmed > delete and is really just an interpretation of the spec. In my opinion, > Orphan Phase 2 SAs are not a good thing for a number of reasons. I guess > many others do not agree. > > What is the right thing to do here? > > I apologize if this has been talked about in the past. > > Victor From owner-ipsec@lists.tislabs.com Thu Jun 17 13:58:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20236; Thu, 17 Jun 1999 13:58:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25762 Thu, 17 Jun 1999 15:13:54 -0400 (EDT) Message-Id: <4.1.19990617152239.00cc6670@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 17 Jun 1999 15:22:55 -0400 To: "Scott G. Kelly" , ipsec@lists.tislabs.com From: Robert Moskowitz Subject: Re: draft-ietf-ipsec-notifymsg-00.txt In-Reply-To: <37684195.C37EF28D@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:30 PM 6/16/99 -0700, Scott G. Kelly wrote: >For around a year or so (maybe longer), Bob has been trying to get >someone to work on an "ipsec errors" draft. I agreed to do it at the >Minneapolis IETF, and have finally completed the first rev of the draft >- I just submitted it, so the announcement should hit the list in the >next day or so. > THANK YOU SCOTT!!!!! Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Thu Jun 17 14:18:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20503; Thu, 17 Jun 1999 14:18:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25796 Thu, 17 Jun 1999 15:26:21 -0400 (EDT) Message-Id: <199906171934.MAA04398@potassium.network-alchemy.com> To: Tim Jenkins cc: "Volpe, Victor" , ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) In-reply-to: Your message of "Thu, 17 Jun 1999 14:34:09 EDT." <319A1C5F94C8D11192DE00805FBBADDFB67F71@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4395.929648097.1@network-alchemy.com> Date: Thu, 17 Jun 1999 12:34:57 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "bounds the authenticated lifetime"? Does the "authenticatedness" somehow get diluted as time goes on? I guess I hadn't realized that. Phase 1 lifetimes are set to prevent too much use of a key. If it was OK to use the key at X but not a X plus some delta and time delta ticks off then it's not OK to use the key _any more_ but it doesn't necessarily mean that delta seconds ago it wasn't. Using the new lifetime that Kivinen came up with (which is a great idea) makes this more apparent. You want to do negotiate N pairs of IPSec SAs. Once you negotiate that Nth pair it is not OK to negotiate anymore so you delete the IKE SA but that doesn't mean that the Nth pair of IPSec SAs you just negotiated is somehow bad or unauthenticated. What I think is unnecessary is the level of complexity involved in doing what's described in draft-jenkins-ipsec-rekeying-01.txt. Dan. On Thu, 17 Jun 1999 14:34:09 EDT you wrote > Phase 1 re-keying is discussed in some detail in > . > > Also, the act of orphaning phase 2 SAs (as described below) in my mind is > both unnecessary and also insecure, since the phase 1 SA is what bounds the > authenticated lifetime of the end points. So to leave a phase 2 SA up > without a valid phase 1 SA is to let it live beyond its allowed limits. > > > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Thu Jun 17 14:32:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20611; Thu, 17 Jun 1999 14:32:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25825 Thu, 17 Jun 1999 15:36:54 -0400 (EDT) Date: Thu, 17 Jun 1999 15:46:10 -0400 Message-Id: <199906171946.PAA23426@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: vvolpe@altiga.com, ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB67F71@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tim" == Tim Jenkins writes: Tim> Phase 1 re-keying is discussed in some detail in Tim> . A very welcome document indeed. (It should get easier with the proposed addition of acknowledged delete.) Tim> Also, the act of orphaning phase 2 SAs (as described below) in Tim> my mind is both unnecessary and also insecure, since the phase 1 Tim> SA is what bounds the authenticated lifetime of the end Tim> points. So to leave a phase 2 SA up without a valid phase 1 SA Tim> is to let it live beyond its allowed limits. I'm utterly puzzled by this comment. As far as I've seen, there isn't a tie-in between the lifespan of phase 1 and phase 2 SAs. I thought I had seen explicit statements to that effect. In particular, I don't understand the assertion that allowing phase 2 SAs to live past the deletion of the Phase 1 SA is in any way a security issue. What does "bounds the authenticated lifetime of the end points" mean? Could you describe an attack on a system that is made possible by letting the phase 2 SAs live beyond the deletion of a phase 1 SA? Note in particular that the IKE spec says: To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following: o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state. This doesn't work if executing the last step deletes the phase 2 SA just negotiated... paul From owner-ipsec@lists.tislabs.com Thu Jun 17 14:36:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20640; Thu, 17 Jun 1999 14:36:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26007 Thu, 17 Jun 1999 15:54:14 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68047@exchange> From: Tim Jenkins To: Dan Harkins Cc: "Volpe, Victor" , ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 16:05:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 17, 1999 3:35 PM > To: Tim Jenkins > Cc: Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > "bounds the authenticated lifetime"? Does the > "authenticatedness" somehow > get diluted as time goes on? I guess I hadn't realized that. The RFCs state that the lifetime of a phase 1 SA must be limited, in addition to local policy requirements when using certificates, to the lifetime of the certificates involved and the CRL used to verify the certificates. This quite clearly is intended to make sure that the phase 1 SA lifetime is limited to the time that the endpoints can be authenticated. That what I mean by "bounds the authenticated lifetime". Once the original phase 1 and phase 2 SAs are created, the fact that they have different lifetimes means they almost live independently so the phase 1 SA existence is necessary to authenticate the endpoints on a continuous basis. > > Phase 1 lifetimes are set to prevent too much use of a key. > If it was > OK to use the key at X but not a X plus some delta and time > delta ticks > off then it's not OK to use the key _any more_ but it doesn't > necessarily > mean that delta seconds ago it wasn't. Using the new lifetime that > Kivinen came up with (which is a great idea) makes this more apparent. > You want to do negotiate N pairs of IPSec SAs. Once you > negotiate that Nth > pair it is not OK to negotiate anymore so you delete the IKE > SA but that > doesn't mean that the Nth pair of IPSec SAs you just > negotiated is somehow > bad or unauthenticated. They aren't necessarily bad, but they might be. And if you don't some mechanism to verify the authentication of the end points, if it changes, you'll never know until you need the phase 1 SA again. > > What I think is unnecessary is the level of complexity involved in > doing what's described in draft-jenkins-ipsec-rekeying-01.txt. Um, you've said that before about the phase 2 re-keying proposal and you've never said why or pointed out any errors in the logic that lead to that proposal. However, this thread is about phase 1 re-keying, and the document simply proposes that you allow multiple phase 1 SAs to exist and that you always use the oldest one first until it really does expire. Is that really that complicated? (As a side note, if phase 2 re-keying had been done that way in the first place the complex proposal in draft-jenkins-ipsec-rekeying-01.txt wouldn't have been necessary.) Tim > > Dan. > > On Thu, 17 Jun 1999 14:34:09 EDT you wrote > > Phase 1 re-keying is discussed in some detail in > > . > > > > Also, the act of orphaning phase 2 SAs (as described below) > in my mind is > > both unnecessary and also insecure, since the phase 1 SA is > what bounds the > > authenticated lifetime of the end points. So to leave a > phase 2 SA up > > without a valid phase 1 SA is to let it live beyond its > allowed limits. > > > > > > > > --- > > Tim Jenkins TimeStep Corporation > > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@lists.tislabs.com Thu Jun 17 14:39:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20668; Thu, 17 Jun 1999 14:39:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26051 Thu, 17 Jun 1999 16:00:20 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68060@exchange> From: Tim Jenkins To: Paul Koning Cc: vvolpe@altiga.com, ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 16:11:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: June 17, 1999 3:46 PM > To: tjenkins@TimeStep.com > Cc: vvolpe@altiga.com; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > >>>>> "Tim" == Tim Jenkins writes: > > Tim> Phase 1 re-keying is discussed in some detail in > Tim> . > > A very welcome document indeed. Thank you. > > (It should get easier with the proposed addition of acknowledged > delete.) Yes. That's basically the same as the delete mode I described, which I stole from PPP which stole from ... > > Tim> Also, the act of orphaning phase 2 SAs (as described below) in > Tim> my mind is both unnecessary and also insecure, since the phase 1 > Tim> SA is what bounds the authenticated lifetime of the end > Tim> points. So to leave a phase 2 SA up without a valid phase 1 SA > Tim> is to let it live beyond its allowed limits. > > I'm utterly puzzled by this comment. As far as I've seen, > there isn't > a tie-in between the lifespan of phase 1 and phase 2 SAs. I > thought I > had seen explicit statements to that effect. There isn't. That's part of the issue, since there is authentication of the endpoints, and therefore the phase 2 SAs once they are created. > > In particular, I don't understand the assertion that allowing phase 2 > SAs to live past the deletion of the Phase 1 SA is in any way a > security issue. What does "bounds the authenticated lifetime of the > end points" mean? Could you describe an attack on a system that is > made possible by letting the phase 2 SAs live beyond the > deletion of a > phase 1 SA? I tried to explain this in my response to Dan; he had a similar question. If it's still not clear, please let me know. > > Note in particular that the IKE spec says: > > To provide Perfect Forward Secrecy of both keys and all identities, > two parties would perform the following: > > o A Main Mode Exchange to protect the identities of the ISAKMP > peers. > This establishes an ISAKMP SA. > o A Quick Mode Exchange to negotiate other security protocol > protection. > This establishes a SA on each end for this protocol. > o Delete the ISAKMP SA and its associated state. > > This doesn't work if executing the last step deletes the phase 2 SA > just negotiated... Yes, I know. That's why I asked, and Dan Harkins echoed the quesion, why can the phase 1 not be allowed to live on to manage the phase 2 SA that it just created? As far as I know, we got no response. > > paul > From owner-ipsec@lists.tislabs.com Thu Jun 17 15:04:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20976; Thu, 17 Jun 1999 15:04:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26107 Thu, 17 Jun 1999 16:18:14 -0400 (EDT) Date: Thu, 17 Jun 1999 16:27:30 -0400 Message-Id: <199906172027.QAA23901@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB68060@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tim" == Tim Jenkins writes: >> In particular, I don't understand the assertion that allowing >> phase 2 SAs to live past the deletion of the Phase 1 SA is in any >> way a security issue. What does "bounds the authenticated >> lifetime of the end points" mean? Could you describe an attack on >> a system that is made possible by letting the phase 2 SAs live >> beyond the deletion of a phase 1 SA? Tim> I tried to explain this in my response to Dan; he had a similar Tim> question. If it's still not clear, please let me know. That's the note I was referring to. It's not clear in the least. You make a statement "bounds the authenticated lifetime of the end points", whose meaning isn't clear. And then you say that there is a security problem, but you don't spell out what the nature of the problem is. I see no security problem. At the time you run phase 2, you have a phase 1 SA. That has assorted security attributes which you know. Based on that knowledge, you accept the phase 2 exchange with all the attributes in it. You might modify some of what's proposed (for example, you might unilaterally restrict the lifetime of the phase 2 SA based on the impending expiration of the cert that authenticated the phase 1 SA). So you clearly rely on the security properties of the phase 1 SA to establish the security properties of the phase 2 SA. But it does not follow that the continuing security of the phase 2 SA relies on the continued existence of the phase 1 SA. I think you need to exhibit a specific attack to support the point you raised. paul From owner-ipsec@lists.tislabs.com Thu Jun 17 15:19:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21077; Thu, 17 Jun 1999 15:19:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26121 Thu, 17 Jun 1999 16:24:30 -0400 (EDT) From: Dan McDonald Message-Id: <199906172033.NAA25557@kebe.Eng.Sun.COM> Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) To: tjenkins@TimeStep.com (Tim Jenkins) Date: Thu, 17 Jun 1999 13:33:27 -0700 (PDT) Cc: pkoning@xedia.com, vvolpe@altiga.com, ipsec@lists.tislabs.com In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFB68060@exchange> from "Tim Jenkins" at Jun 17, 99 04:11:30 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > This doesn't work if executing the last step deletes the phase 2 SA > > just negotiated... > > Yes, I know. That's why I asked, and Dan Harkins echoed the quesion, why can > the phase 1 not be allowed to live on to manage the phase 2 SA that it just > created? Apart from derivation strengths, do Phase 2 SAs (e.g. the IPsec SAs) need to be that strongly tied to the Phase 1 SAs? I might be missing something here, but apart from the Phase 1 identities (critical for per-user keying), and lifetimes, both of which can be inherited attributes maintained seperately, what else from phase 1 gets associated with a Phase 2 SA? Dan McD. From owner-ipsec@lists.tislabs.com Thu Jun 17 15:37:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21164; Thu, 17 Jun 1999 15:37:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26183 Thu, 17 Jun 1999 16:42:58 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBD48@new-exc1.ctron.com> From: "Waters, Stephen" To: "John E. Horton" Cc: ipsec@lists.tislabs.com Subject: RE: SA Recovery (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 21:51:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, that's what I was suggesting. Thanks, Steve. -----Original Message----- From: John E. Horton [mailto:jehorton@erols.com] Sent: Thursday, June 17, 1999 6:57 PM To: Waters, Stephen; Tim Jenkins Cc: Subject: RE: SA Recovery (was RE: issues from the bakeoff) Stephen - Clear traffic ICMP messages generated by a client on a LAN behind a FW blocking ICMP will cause a problem for this proposal. IPSEC Encapsulated ICMPs to the gateway would work. Regards, John Horton At 06:19 PM 6/17/99 +0100, Waters, Stephen wrote: >Hi, > >A quick proposal for tunnel keep-alive: > >The client pings the Security Gateway on a configurable timer once the >IPSEC-SA is connected. The policy should allow responses to protected pings >terminating at the security gateway. > >A counter of missed echo-replies since the last echo-rely is kept which is >reset to zero whenever a reply is received. > >A configurable miss-replies threshold is used to determine when the SA is >'dead'. When the SA dies, the client deletes the outgoing SA and inbound SA >and restarts at Phase1 with the remote security gateway. If the security >gateway remains 'unreachable' (more timers and thresholds), the client can >try other security gateways. > >How does that sound? For remote access, I am only really interested in the >client detecting that the security gateway has become unreachable. For >LAN-LAN, this mechanism can be used symmetrically. > >In time, it may be possible to define formatted data in the ping payload to >allow SLA/QOS info to be exchange between tunnel peers. Since ping data is >meaningless to non-participating remote system, this will be treated just >like any other ping. > >Cheers, Steve. > > > > > >-----Original Message----- >From: Tim Jenkins [mailto:tjenkins@TimeStep.com] >Sent: Thursday, June 17, 1999 3:19 PM >To: Slava Kavsan >Cc: ipsec@lists.tislabs.com >Subject: SA Recovery (was RE: issues from the bakeoff) > > >Slava, > >In the absence of keep-alives, this procedure can be used to allow recovery >after one entity has died and recover. > >Basically, the recovered entity will receive encrypted traffic from a peer >with SPI values that it doesn't understand. The assumption is that the peer >had valid SAs with it that it lost when it died. > >In order to tell the peer that the SA (and any others it may think it had >with it) are invalid is to set up a phase 1 SA with it that includes the >initial contact notification. Receipt of the initial contact notification >should cause the peer sending the packets with invalid SPIs to clear all its >SAs and re-establish new ones. > >A similar approach can be used if an entity receives phase 1 packets with >invalid cookies. > >The problems with this approach are: >1) Need main mode to authenticate initial contact (unless use of the >encrypted aggressive mode three message with initial contact is okay, but >that's currently prohibited.) >2) There may be no specific knowledge of the peer that's sending the invalid >SPIs by the entity that's recovered, so initiating back presents a form of >DOS attack if the SPI-sending peer is an attacker that is intentionally >sending packets with bogus SPI values. > >That's why there is a need for SA management while the SAs are up, so that >crash recovery can be active, rather than reactive. > >Tim > >--- >Tim Jenkins TimeStep Corporation >tjenkins@timestep.com http://www.timestep.com >(613) 599-3610 x4304 Fax: (613) 599-3617 > > > >> -----Original Message----- >> From: Slava Kavsan [mailto:bkavsan@ire-ma.com] >> Sent: June 16, 1999 9:34 AM >> To: Dan Harkins >> Cc: ipsec@lists.tislabs.com >> Subject: Re: issues from the bakeoff >> >> >> Dan Harkins wrote: >> >> > >> > It was suggested that a keepalive mechanism be >> built into IKE. Several people >> > already have proprietary keepalive mechanisms in >> their implementations. >> > Perhaps the person(s) who brought this up will >> write up a draft specifying >> > how this is to be done. >> >> It may take some time to write and agree to such draft. Could >> we meanwhile design some simple >> (which may not be 100% bullet-proff) logic around >> unprotected INVALID_SPI notifications that >> rebooted node most likely to send to another party which is >> unaware of the re-booted partner >> and keep sending encrypted traffic to it? >> >> >> -- >> Bronislav Kavsan >> IRE Secure Solutions, Inc. >> 100 Conifer Hill Drive Suite 513 >> Danvers, MA 01923 >> voice: 978-739-2384 >> http://www.ire.com >> >> >> From owner-ipsec@lists.tislabs.com Thu Jun 17 15:38:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21194; Thu, 17 Jun 1999 15:38:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26158 Thu, 17 Jun 1999 16:36:12 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68097@exchange> From: Tim Jenkins To: Paul Koning , Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 16:47:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: June 17, 1999 4:28 PM > To: tjenkins@TimeStep.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > >>>>> "Tim" == Tim Jenkins writes: > > >> In particular, I don't understand the assertion that allowing > >> phase 2 SAs to live past the deletion of the Phase 1 SA is in any > >> way a security issue. What does "bounds the authenticated > >> lifetime of the end points" mean? Could you describe an attack on > >> a system that is made possible by letting the phase 2 SAs live > >> beyond the deletion of a phase 1 SA? > > Tim> I tried to explain this in my response to Dan; he had a similar > Tim> question. If it's still not clear, please let me know. > > That's the note I was referring to. It's not clear in the least. You > make a statement "bounds the authenticated lifetime of the end > points", whose meaning isn't clear. And then you say that there is a > security problem, but you don't spell out what the nature of the > problem is. > > I see no security problem. At the time you run phase 2, you have a > phase 1 SA. That has assorted security attributes which you know. > Based on that knowledge, you accept the phase 2 exchange with all the > attributes in it. You might modify some of what's proposed (for > example, you might unilaterally restrict the lifetime of the phase 2 > SA based on the impending expiration of the cert that authenticated > the phase 1 SA). > > So you clearly rely on the security properties of the phase 1 SA to > establish the security properties of the phase 2 SA. But it does not > follow that the continuing security of the phase 2 SA relies on the > continued existence of the phase 1 SA. > > I think you need to exhibit a specific attack to support the > point you > raised. Okay, phase 1 lifetime gets negotiated to 4 hours by a dial-in client. Phase 2 lifetimes are set to expire at 5 Mbyte traffic. At 3 hours and 50 minutes into the phase 1 lifetime, the phase 2 SAs are re-keyed. At 4 hours, the phase 1 SA is deleted. Seems fine so far. A little later the certificate of the dial in client gets revoked. So now we have phase 2 SAs up that may be used by the person whose certificate has been revoked, and they've got 5 Mbyte of data they can move before the system will redo phase 1. If the presence of phase 1 SAs was required, this would have been detected within 4 hours (at the next phase 1 re-key time: the phase 1 re-key would fail) and the system would know to tear down all SAs. Otherwise, you need some other mechanism to know that the phase 2 need to be torn down before they would otherwise normally expire. And in this case, you'd have to do it unilaterally: no polite delete or anything; they would just get removed, and the dial-in client may be hitting you with packets with invalid SPIs. By overlapping phase 1 SAs, if the re-key fails, the existing SA can be used to send deletes for the phase 2 SA and itself, cleaning up the far implementation. It's far cleaner, and it's really not that complicated. Does this help? Tim > > paul > From owner-ipsec@lists.tislabs.com Thu Jun 17 15:55:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21348; Thu, 17 Jun 1999 15:55:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26313 Thu, 17 Jun 1999 17:15:43 -0400 (EDT) Message-ID: <376967DA.6E2AE5CB@redcreek.com> Date: Thu, 17 Jun 1999 14:25:46 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: "Volpe, Victor" , ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB67F71@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tim, Tim Jenkins wrote: > > > Also, the act of orphaning phase 2 SAs (as described below) in my mind is > both unnecessary and also insecure, since the phase 1 SA is what bounds the > authenticated lifetime of the end points. So to leave a phase 2 SA up > without a valid phase 1 SA is to let it live beyond its allowed limits. I have a question about this. I haven't thought about it in depth, so maybe you'll quickly correct me if I'm wrong. It seems to me that AH authenticates the SA endpoints, and that it is sufficiently strong that we need not worry about whether the phase 1 SA is up or not. It also seems to me that authenticated ESP with strong encryption provides pretty good assurance that the packets came from where you think they did unless that source system were somehow compromised, in which case the phase 1 SA would also be worthless (I'm sure the cryptographers here could educate us on the subtleties involved). The real question is, does an active phase 1 SA in any way add to the protection of an authenticated phase 2 SA? Scott From owner-ipsec@lists.tislabs.com Thu Jun 17 16:04:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21432; Thu, 17 Jun 1999 16:04:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26294 Thu, 17 Jun 1999 17:13:24 -0400 (EDT) Message-Id: <199906172122.OAA04728@potassium.network-alchemy.com> To: Tim Jenkins cc: "Volpe, Victor" , ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) In-reply-to: Your message of "Thu, 17 Jun 1999 16:05:54 EDT." <319A1C5F94C8D11192DE00805FBBADDFB68047@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4725.929654527.1@network-alchemy.com> Date: Thu, 17 Jun 1999 14:22:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 17 Jun 1999 16:05:54 EDT you wrote > > Phase 1 lifetimes are set to prevent too much use of a key. > > If it was > > OK to use the key at X but not a X plus some delta and time > > delta ticks > > off then it's not OK to use the key _any more_ but it doesn't > > necessarily > > mean that delta seconds ago it wasn't. Using the new lifetime that > > Kivinen came up with (which is a great idea) makes this more apparent. > > You want to do negotiate N pairs of IPSec SAs. Once you > > negotiate that Nth > > pair it is not OK to negotiate anymore so you delete the IKE > > SA but that > > doesn't mean that the Nth pair of IPSec SAs you just > > negotiated is somehow > > bad or unauthenticated. > > They aren't necessarily bad, but they might be. And if you don't some > mechanism to verify the authentication of the end points, if it changes, > you'll never know until you need the phase 1 SA again. A certificate binds an identity to a key in a verifiable way. You verified it and created IPSec SAs. If later on the cert expires it doesn't mean that you did not authenticate that person, only that the CA wants its pound of flesh again. If I buy a 6pack of beer and use a driver's license to verify my identity and age and that driver's license expires the next day it doesn't mean that I have to throw out all the beer I hadn't drank just because my driver's license is now expired. If you check CRLs every 10 minutes for active sessions and notice that a certificate used to establish a session which is currently active has been revoked then it seems appropriate to clear the IPSec SAs. But in general, and in the case where a certificate is still valid (or you didn't even use certificates to authenticate the person) but the IKE SA has just gone away for whatever reason, it really doesn't make sense to delete the IPSec SAs. It just results in temporary blackouts, as Victor Volpe described in the note that started this thread. Dan. From owner-ipsec@lists.tislabs.com Thu Jun 17 16:21:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21587; Thu, 17 Jun 1999 16:21:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26358 Thu, 17 Jun 1999 17:32:31 -0400 (EDT) Message-ID: <37696BCB.511F91A2@redcreek.com> Date: Thu, 17 Jun 1999 14:42:35 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: Dan Harkins , "Volpe, Victor" , ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB68047@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins wrote: > > > "bounds the authenticated lifetime"? Does the > > "authenticatedness" somehow > > get diluted as time goes on? I guess I hadn't realized that. > > The RFCs state that the lifetime of a phase 1 SA must be limited, in > addition to local policy requirements when using certificates, to the > lifetime of the certificates involved and the CRL used to verify the > certificates. > > This quite clearly is intended to make sure that the phase 1 SA lifetime is > limited to the time that the endpoints can be authenticated. That what I > mean by "bounds the authenticated lifetime". There is a subtlety here: I think this insures that the phase 1 SA lifetime is limited to the time that the CA is willing to vouch for the identity of the holder, not to the time that the endpoints can be authenticated. Presumably, the endpoints can be authenticated (to some degree) so long as their authentication keys have not been compromised. Obviously, the established comfort level regarding key compromise degrades over time for a given session, but in general, don't we set the phase 2 lifetime to reflect our relative paranoia? To put it another way, if my identity has been vouched for by a CA you trust, and then we establish an authenticated SA, aren't you relatively assured that you are, in fact, continuing to talk with me (the "me" you established this "connection" with) so long as I continue to sign/hash with the mutually agreed-upon keying material, AND so long as your comfort level parameters (lifetime) have not been exceeded? And if I am susceptible to compromise, will it really matter if the phase 1 SA remains or not? (I know, it's the same question I asked in my last post...) Scott From owner-ipsec@lists.tislabs.com Thu Jun 17 16:28:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21640; Thu, 17 Jun 1999 16:28:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26377 Thu, 17 Jun 1999 17:42:12 -0400 (EDT) Message-ID: <37696DC3.38E0CC34@cs.stanford.edu> Date: Thu, 17 Jun 1999 14:51:00 -0700 From: Brian Korver Reply-To: briank@briank.com X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) References: <319A1C5F94C8D11192DE00805FBBADDFB68097@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins wrote: [snip] > Okay, phase 1 lifetime gets negotiated to 4 hours by a dial-in client. Phase > 2 lifetimes are set to expire at 5 Mbyte traffic. At 3 hours and 50 minutes > into the phase 1 lifetime, the phase 2 SAs are re-keyed. At 4 hours, the > phase 1 SA is deleted. Seems fine so far. A little later the certificate of > the dial in client gets revoked. So now we have phase 2 SAs up that may be > used by the person whose certificate has been revoked, and they've got 5 > Mbyte of data they can move before the system will redo phase 1. If the > presence of phase 1 SAs was required, this would have been detected within 4 > hours (at the next phase 1 re-key time: the phase 1 re-key would fail) and > the system would know to tear down all SAs. > > Otherwise, you need some other mechanism to know that the phase 2 need to be > torn down before they would otherwise normally expire. And in this case, > you'd have to do it unilaterally: no polite delete or anything; they would > just get removed, and the dial-in client may be hitting you with packets > with invalid SPIs. > > By overlapping phase 1 SAs, if the re-key fails, the existing SA can be used > to send deletes for the phase 2 SA and itself, cleaning up the far > implementation. > > It's far cleaner, and it's really not that complicated. > > Does this help? > Tim, While I'm attracted to the idea of binding phase 2 SA lifetimes to the phase 1 SA lifetimes, I'm not sure that certificate revocation is a good example of an attack here. Revocation mechanisms such as CRLs always have windows where theoretical attacks can occur. Assume, for instance, that your CRLs are issued weekly. Then it is possible that you will be creating SAs for an entire week before you discover the (potential) security breech. And it's worse if there is some period of time before the user notices their key has been compromised, and even worse if you don't obtain the CRL as soon as it is issued by your CA. In this case, the phase 2 SA lifetime starts looking like a rounding error. I believe in revocation, but I recognize it is not perfect. And no amount of fiddling with SA lifetimes will change that. If you're really worried about this, you might think about using short SA lifetimes. And definitely think about something like OCSP, because CRLs are not going to give you what you want. brian briank@cs.stanford.edu (play) briank@network-alchemy.com (work) From owner-ipsec@lists.tislabs.com Thu Jun 17 16:36:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21717; Thu, 17 Jun 1999 16:36:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26415 Thu, 17 Jun 1999 17:57:15 -0400 (EDT) Message-Id: <199906172205.PAA04856@potassium.network-alchemy.com> To: Tim Jenkins cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) In-reply-to: Your message of "Thu, 17 Jun 1999 16:47:56 EDT." <319A1C5F94C8D11192DE00805FBBADDFB68097@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4853.929657158.1@network-alchemy.com> Date: Thu, 17 Jun 1999 15:05:58 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 17 Jun 1999 16:47:56 EDT you wrote > Okay, phase 1 lifetime gets negotiated to 4 hours by a dial-in client. Phase > 2 lifetimes are set to expire at 5 Mbyte traffic. At 3 hours and 50 minutes > into the phase 1 lifetime, the phase 2 SAs are re-keyed. At 4 hours, the > phase 1 SA is deleted. Seems fine so far. A little later the certificate of > the dial in client gets revoked. So now we have phase 2 SAs up that may be > used by the person whose certificate has been revoked, and they've got 5 > Mbyte of data they can move before the system will redo phase 1. If the > presence of phase 1 SAs was required, this would have been detected within 4 > hours (at the next phase 1 re-key time: the phase 1 re-key would fail) and > the system would know to tear down all SAs. What if his certificate gets revoked 2 hours into the phase 1 lifetime? How do you know? Do you constantly recheck CRLs? How often? What if it expires in between checks? I don't see how your concern is addressed by deleting the IPSec SAs when the IKE SA expires. And if this is your concern why not limit this 2nd negotiation to 10 min then and guarantee that the client will not think his IPSec SAs are valid for longer than what you think they are. That would prompt him to renegotiate a phase 1 exchange for you without the obligatory blackout period that happens when you delete the IPSec SAs which he thinks are still valid. Since your overriding concern is a seconds-based lifetime anyway why do you negotiate a volume based SA which has a hidden, unknown-to-client, life? You're defining some space in which you want to act in (the limit is seconds-based) and then intentionally doing something which is outside that space (negotiating a completely different lifetime which could extend beyond the limit). Surprise! It has problems, at least problems as you define them. Your concern is allowing someone to have an IPSec SA when the certificate that was used to (indirectly) authenticate it has been revoked. Deleting IPSec SAs when the IKE SA used to generate them expires is not the answer (and actually causes other problems). Operating in the bounds you place around yourself-- i.e. don't renegotiate an IPSec SA which could live longer that the underlying IKE SA-- will. Not everybody shares your concern though and the beauty of operating within your self-imposed boundaries is that they don't need to. Dan. From owner-ipsec@lists.tislabs.com Thu Jun 17 17:06:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21957; Thu, 17 Jun 1999 17:06:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26521 Thu, 17 Jun 1999 18:27:40 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC839358@new-exc1.ctron.com> From: "Waters, Stephen" To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 23:36:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An interesting point that. Since the lifetime on Phase1 takes notice of the lifetime of the certificate used, the intention is that the certificate user should not be allowed to connect once the certificate has expired. It does not seem sensible to allow Phase-2 SA to live past the lifetime of the certificate either. If the Phase-1 SA used the 'life-left' value of the certificate when it was established, should we restrict the Phase-2 SAs negotiated to live no longer than the parent Phase-1? Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, June 17, 1999 9:06 PM To: Dan Harkins Cc: Volpe, Victor; Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 17, 1999 3:35 PM > To: Tim Jenkins > Cc: Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > "bounds the authenticated lifetime"? Does the > "authenticatedness" somehow > get diluted as time goes on? I guess I hadn't realized that. The RFCs state that the lifetime of a phase 1 SA must be limited, in addition to local policy requirements when using certificates, to the lifetime of the certificates involved and the CRL used to verify the certificates. This quite clearly is intended to make sure that the phase 1 SA lifetime is limited to the time that the endpoints can be authenticated. That what I mean by "bounds the authenticated lifetime". Once the original phase 1 and phase 2 SAs are created, the fact that they have different lifetimes means they almost live independently so the phase 1 SA existence is necessary to authenticate the endpoints on a continuous basis. > > Phase 1 lifetimes are set to prevent too much use of a key. > If it was > OK to use the key at X but not a X plus some delta and time > delta ticks > off then it's not OK to use the key _any more_ but it doesn't > necessarily > mean that delta seconds ago it wasn't. Using the new lifetime that > Kivinen came up with (which is a great idea) makes this more apparent. > You want to do negotiate N pairs of IPSec SAs. Once you > negotiate that Nth > pair it is not OK to negotiate anymore so you delete the IKE > SA but that > doesn't mean that the Nth pair of IPSec SAs you just > negotiated is somehow > bad or unauthenticated. They aren't necessarily bad, but they might be. And if you don't some mechanism to verify the authentication of the end points, if it changes, you'll never know until you need the phase 1 SA again. > > What I think is unnecessary is the level of complexity involved in > doing what's described in draft-jenkins-ipsec-rekeying-01.txt. Um, you've said that before about the phase 2 re-keying proposal and you've never said why or pointed out any errors in the logic that lead to that proposal. However, this thread is about phase 1 re-keying, and the document simply proposes that you allow multiple phase 1 SAs to exist and that you always use the oldest one first until it really does expire. Is that really that complicated? (As a side note, if phase 2 re-keying had been done that way in the first place the complex proposal in draft-jenkins-ipsec-rekeying-01.txt wouldn't have been necessary.) Tim > > Dan. > > On Thu, 17 Jun 1999 14:34:09 EDT you wrote > > Phase 1 re-keying is discussed in some detail in > > . > > > > Also, the act of orphaning phase 2 SAs (as described below) > in my mind is > > both unnecessary and also insecure, since the phase 1 SA is > what bounds the > > authenticated lifetime of the end points. So to leave a > phase 2 SA up > > without a valid phase 1 SA is to let it live beyond its > allowed limits. > > > > > > > > --- > > Tim Jenkins TimeStep Corporation > > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@lists.tislabs.com Thu Jun 17 17:15:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22036; Thu, 17 Jun 1999 17:15:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26539 Thu, 17 Jun 1999 18:33:43 -0400 (EDT) Message-ID: <71B30BC67510D31184030090277A3DDE13851D@mail.altiga.com> From: "Volpe, Victor" To: "'Scott G. Kelly'" , Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Thu, 17 Jun 1999 18:41:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Originally I was concerned about the security problems that the dangling Phase 2 SAs could pose, but I guess I agree that those issues are minimal if any. Let me raise my question to a more functional level so that I can make a decision on how to tweak our implementation. My assumption was that rekeying a Phase 1 SA meant that it was rekeyed/renegotiated with the peer. I assumed that most other implementations would behave the same way. When we rekey with ourselves, we negotiate a new Phase 1 SA before tearing down the old one. When the old one is deleted, the Phase 2 SAs stay up because they are transitioned to the new SA. They then rekey under the protection of the new Phase 1 SA. It seems like a lot of implementations interpreted Phase 1 rekeying as "just drop the old SA". It will then be renegotiated as the result of a Phase 2 rekey. Either way will work and either way can be implemented in a way that is interoperable and prevents data from being lost. I guess the 2 methods will also interoperate if it is clear to everyone that delete messages for Phase 1 SAs do not imply any action to the respective Phase 2 SAs. I wanted to get a feel for where people stood on this and it looks like orphan Phase 2 SAs should be supported to support the widest range of implementations. Tim, is this something that is worth putting in the rekeying draft? Victor > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Thursday, June 17, 1999 5:26 PM > To: Tim Jenkins > Cc: Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > Hi Tim, > > Tim Jenkins wrote: > > > > > > > Also, the act of orphaning phase 2 SAs (as described below) > in my mind is > > both unnecessary and also insecure, since the phase 1 SA is > what bounds the > > authenticated lifetime of the end points. So to leave a > phase 2 SA up > > without a valid phase 1 SA is to let it live beyond its > allowed limits. > > > I have a question about this. I haven't thought about it in depth, so > maybe you'll quickly correct me if I'm wrong. It seems to me that AH > authenticates the SA endpoints, and that it is sufficiently > strong that > we need not worry about whether the phase 1 SA is up or not. It also > seems to me that authenticated ESP with strong encryption provides > pretty good assurance that the packets came from where you think they > did unless that source system were somehow compromised, in which case > the phase 1 SA would also be worthless (I'm sure the > cryptographers here > could educate us on the subtleties involved). > > The real question is, does an active phase 1 SA in any way add to the > protection of an authenticated phase 2 SA? > > Scott > From owner-ipsec@lists.tislabs.com Thu Jun 17 19:04:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24452; Thu, 17 Jun 1999 19:04:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26792 Thu, 17 Jun 1999 20:15:55 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBD4A@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 01:24:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >A certificate binds an identity to a key in a verifiable way. You verified >it and created IPSec SAs. If later on the cert expires it doesn't mean >that you did not authenticate that person, only that the CA wants its >pound of flesh again. If I buy a 6pack of beer and use a driver's license >to verify my identity and age and that driver's license expires the next >day it doesn't mean that I have to throw out all the beer I hadn't drank >just because my driver's license is now expired. I think this analogy is flawed when compared to Phase-2 SA with lifetime. Your beer is not going to expire when your driver's license does perhaps, and there is little that can be done to make it expire - other than planting a time bomb in it, but we can make sure that your Phase-2 SA does expire when your certificate does. In the case of Phase-2 that are only setup with lifedata, then I guess it could be the same as your example. The Phase-1 SA takes notice of the lifetime of the certificate and I think we should probably do the same for Phase-2 SA. The revoked cert problem is another can of worms. Checking the CRL every 10 minutes in case any of the active SA should be killed seems hard work - this is probably only solved by the security manager knowing which Security Gateways the owner can access, and deleting any SA manually, relying on the CRL to block later connections. Steve. From owner-ipsec@lists.tislabs.com Fri Jun 18 06:13:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA00658; Fri, 18 Jun 1999 06:13:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA27808 Fri, 18 Jun 1999 07:06:27 -0400 (EDT) Message-Id: <199906181115.HAA21354@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-notifymsg-00.txt Date: Fri, 18 Jun 1999 07:15:12 -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 : Content Requirements for ISAKMP Notify Messages Author(s) : S. Kelly Filename : draft-ietf-ipsec-notifymsg-00.txt Pages : 20 Date : 17-Jun-99 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-00.txt 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-notifymsg-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-ietf-ipsec-notifymsg-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: <19990617090829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-notifymsg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-notifymsg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990617090829.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 18 07:28:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01589; Fri, 18 Jun 1999 07:28:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27958 Fri, 18 Jun 1999 08:20:32 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68141@exchange> From: Tim Jenkins To: Dan McDonald Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 08:32:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan McDonald [mailto:danmcd@eng.sun.com] > Sent: June 17, 1999 4:33 PM > To: tjenkins@TimeStep.com > Cc: pkoning@xedia.com; vvolpe@altiga.com; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > > > This doesn't work if executing the last step deletes the > phase 2 SA > > > just negotiated... > > > > Yes, I know. That's why I asked, and Dan Harkins echoed the > quesion, why can > > the phase 1 not be allowed to live on to manage the phase 2 > SA that it just > > created? > > Apart from derivation strengths, do Phase 2 SAs (e.g. the > IPsec SAs) need to > be that strongly tied to the Phase 1 SAs? > > I might be missing something here, but apart from the Phase 1 > identities > (critical for per-user keying), and lifetimes, both of which > can be inherited > attributes maintained seperately, what else from phase 1 gets > associated with > a Phase 2 SA? > > Dan McD. > I think maybe my explanation of why I want phase 1 SAs always up is weak since I'm not explicitly saying "authorization". There is implicit authorization in the ability to authenticate an endpoint, and that only happens with phase 1. Part of my concern arises from the independence of phase 1 and phase 2 lifetimes: there is no requirement that phase 2 lifetime be shorter than phase 1. And even if they were, with phase 2 re-keying it is possible that a phase 2 SA could live beyond the time that an entity could know the authorization of the peer. Yes, there are other ways that could solve this rather than dis-allowing dangling SAs. However, by doing that, we increase the chances for interoperability, it reduces the window of uncertainty and allows for better clean up. From owner-ipsec@lists.tislabs.com Fri Jun 18 07:32:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01616; Fri, 18 Jun 1999 07:32:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27939 Fri, 18 Jun 1999 08:13:08 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68136@exchange> From: Tim Jenkins To: "Volpe, Victor" , "'Scott G. Kelly'" , Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 08:24:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Volpe, Victor [mailto:vvolpe@altiga.com] > Sent: June 17, 1999 6:41 PM > To: 'Scott G. Kelly'; Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > Originally I was concerned about the security problems that > the dangling > Phase 2 SAs could pose, but I guess I agree that those issues > are minimal if > any. Let me raise my question to a more functional level so > that I can make > a decision on how to tweak our implementation. > > My assumption was that rekeying a Phase 1 SA meant that it was > rekeyed/renegotiated with the peer. I assumed that most other > implementations would behave the same way. When we rekey > with ourselves, we > negotiate a new Phase 1 SA before tearing down the old one. > When the old > one is deleted, the Phase 2 SAs stay up because they are > transitioned to the > new SA. They then rekey under the protection of the new > Phase 1 SA. It > seems like a lot of implementations interpreted Phase 1 > rekeying as "just > drop the old SA". It will then be renegotiated as the result > of a Phase 2 > rekey. > > Either way will work and either way can be implemented in a > way that is > interoperable and prevents data from being lost. I guess the > 2 methods will > also interoperate if it is clear to everyone that delete > messages for Phase > 1 SAs do not imply any action to the respective Phase 2 SAs. > > I wanted to get a feel for where people stood on this and it > looks like > orphan Phase 2 SAs should be supported to support the widest range of > implementations. > > Tim, is this something that is worth putting in the rekeying draft? This is already in the re-keying draft as I've been presenting: where dangling phase 2 SAs is bad. However, either no one bothered to read it or comment on it, or maybe no one understood it... In any case, the original point you raised is valid. Unfortunately, I see, once again, incompatibilities due to implementations re-keying differently. Another case of too many ways to do it that aren't explicitly allowed or dis-allowed. As for the feel of things, well, it looks like your conclusion that support for dangling SAs is going to be necessary for maximum interoperability. I'm going to make another (futile) attempt to explain why I don't like dangling SAs again, by responding to the latest set of questions. Tim > > Victor > From owner-ipsec@lists.tislabs.com Fri Jun 18 07:46:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01777; Fri, 18 Jun 1999 07:46:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28140 Fri, 18 Jun 1999 08:39:59 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB6815D@exchange> From: Tim Jenkins To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 08:51:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: June 17, 1999 5:43 PM > To: Tim Jenkins > Cc: Dan Harkins; Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > Tim Jenkins wrote: > > > > > "bounds the authenticated lifetime"? Does the > > > "authenticatedness" somehow > > > get diluted as time goes on? I guess I hadn't realized that. > > > > The RFCs state that the lifetime of a phase 1 SA must be limited, in > > addition to local policy requirements when using > certificates, to the > > lifetime of the certificates involved and the CRL used to verify the > > certificates. > > > > This quite clearly is intended to make sure that the phase > 1 SA lifetime is > > limited to the time that the endpoints can be > authenticated. That what I > > mean by "bounds the authenticated lifetime". > > There is a subtlety here: I think this insures that the phase 1 SA > lifetime is > limited to the time that the CA is willing to vouch for the > identity of > the holder, not to the time that the endpoints can be authenticated. > Presumably, the endpoints can be authenticated (to some > degree) so long > as their authentication keys have not been compromised. Obviously, the > established comfort level regarding key compromise degrades over time > for a given session, but in general, don't we set the phase 2 lifetime > to reflect our relative paranoia? Yes, that's correct, but there is always the possibility that due to re-keying combinations, the phase 2 SA can live past that time. And if the phase 2 SA lifetime is limited by traffic, there is no limit on the time that phase 2 SA can live beyond that "vouched" for time. > > To put it another way, if my identity has been vouched for by a CA you > trust, and then we establish an authenticated SA, aren't you > relatively > assured that you are, in fact, continuing to talk with me > (the "me" you > established this "connection" with) so long as I continue to sign/hash > with the mutually agreed-upon keying material, AND so long as your > comfort level parameters (lifetime) have not been exceeded? Yes, that's correct. But one of us may become unauthorized to talk to the other. The window of this time can be reduced by re-keying the phase 1 SA before the old one expires, and making sure there are no dangling SAs. > And if I am > susceptible to compromise, will it really matter if the phase 1 SA > remains or not? (I know, it's the same question I asked in my last > post...) Again, it's about authorization. I didn't say that in previous responses. It the authorization stops, it can be detected sooner. > > Scott > Tim From owner-ipsec@lists.tislabs.com Fri Jun 18 07:58:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01930; Fri, 18 Jun 1999 07:58:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28104 Fri, 18 Jun 1999 08:35:41 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB6814E@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 08:47:23 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFB6814E@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB988.B7805F80" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEB988.B7805F80 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 17, 1999 5:22 PM > To: Tim Jenkins > Cc: Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > On Thu, 17 Jun 1999 16:05:54 EDT you wrote > > > Phase 1 lifetimes are set to prevent too much use of a key. > > > If it was > > > OK to use the key at X but not a X plus some delta and time > > > delta ticks > > > off then it's not OK to use the key _any more_ but it doesn't > > > necessarily > > > mean that delta seconds ago it wasn't. Using the new lifetime that > > > Kivinen came up with (which is a great idea) makes this > more apparent. > > > You want to do negotiate N pairs of IPSec SAs. Once you > > > negotiate that Nth > > > pair it is not OK to negotiate anymore so you delete the IKE > > > SA but that > > > doesn't mean that the Nth pair of IPSec SAs you just > > > negotiated is somehow > > > bad or unauthenticated. > > > > They aren't necessarily bad, but they might be. And if you > don't some > > mechanism to verify the authentication of the end points, > if it changes, > > you'll never know until you need the phase 1 SA again. > > A certificate binds an identity to a key in a verifiable way. > You verified > it and created IPSec SAs. If later on the cert expires it doesn't mean > that you did not authenticate that person, only that the CA wants its > pound of flesh again. If I buy a 6pack of beer and use a > driver's license > to verify my identity and age and that driver's license > expires the next > day it doesn't mean that I have to throw out all the beer I > hadn't drank > just because my driver's license is now expired. I don't think this a valid analogy, because most places don't take away your privilege to buy beer as you get older, and also, the driver's license verifies that you have the privilege to buy the beer, not drink it. A better analogy is a passport. On Canadian passports there is also a requirement that you not use it if it's going to expire in less than 3 months. The point of this is that you shouldn't be in a foreign country with an expired passport, and they want to minimize that possibility. Yes, maybe you are because it expired while you were away, but you better not need it once it expires. My argument is about authorization, which I didn't explicitly mention before. The window of unauthorized use when a certificate becomes revoked can be reduced by requiring the existence of the phase 1 SA. > > If you check CRLs every 10 minutes for active sessions and > notice that > a certificate used to establish a session which is currently > active has > been revoked then it seems appropriate to clear the IPSec SAs. But in > general, and in the case where a certificate is still valid > (or you didn't > even use certificates to authenticate the person) but the IKE > SA has just > gone away for whatever reason, it really doesn't make sense > to delete the > IPSec SAs. It just results in temporary blackouts, as Victor > Volpe described > in the note that started this thread. Yes, that's correct. But it does make sense to define behaviour where there are differences that have the potential to reduce either security or interoperability. And I agree that it would be bad to have different rules depending on how the phase 1 SA is authenticated. Am I not correct in assuming that the phase 1 SA lifetime limit is also the same limit on how long you can verify the authorization of use by the peer? This is really the crux of the matter, combined with the fact that the existence of a phase 1 SA allows easy clean up when/if the peer'd authorization does become removed (because authentication fails). Let me ask you this: What is wrong with the requirement that a phase 1 SA always exist? Is there a security risk if it does? Is it significantly more difficult to implement? > > Dan. > > > Tim ------_=_NextPart_000_01BEB988.B7805F80 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhsMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGABIACAAvABcABQBBAQEggAMADgAAAM8HBgAS AAgALwAZAAUAQwEBCYABACEAAAAwRTQ1NkQxMjc2MjVEMzExOEE2OTAwODBDNzk0NUU2QwDyBgEE gAEAPAAAAFJFOiBEYW5nbGluZyBwaGFzZSAyIFNBcyAod2FzIFJFOiBpc3N1ZXMgZnJvbSB0aGUg YmFrZW9mZikgAGsTAQ2ABAACAAAAAgACAAEDkAYARA8AADEAAAALAAIAAQAAAAsAKwAAAAAAAwAu AAAAAABAADkAEDg2toi5vgEeAHAAAQAAADgAAABEYW5nbGluZyBwaGFzZSAyIFNBcyAod2FzIFJF OiBpc3N1ZXMgZnJvbSB0aGUgYmFrZW9mZikgAAIBcQABAAAAGwAAAAG+uQfube1VPQsk9xHTk1EA EEtqqNgAH5B58AAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAAAB4AMEABAAAACQAAAFRK RU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAADjCQAA3wkAACISAABMWkZ1Eed3VQMACgByY3BnMTI1 4jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMR JfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6djATCjCuMKgD4gLR2yTwUQ HmcLgAdABdAHkHNhZxZlHbMdNkYDYTogRLUDkUgKwGsLgAQgWwDAYQMQdG86ZBPhIKJACQfAdHcF sGstQWwBE9BlbXkuQ09NHl0dNgZgAjAgEEp1bqBlIDE3LCRgOSTAkCA1OjIUQFBNHTb+VCFQJeAH cCQQCfAgoh02lENjIBBWBvBwZSSQxlYN4CFAcjsgBSAUEAhjQGwEAHRzLnRbBAALYGIpMAWgbSNH dUxiagWQI/FSZSATZ7Mo8CtwIHAT4BQQIBRBskEEICh3LAAH8EUgEE8EAQpQBCADUiB0IrAgoGJh a2VvASApHSdFLs5PA6BUaHUkkTdDJBIkpDE2OjAlADWANCBFRFQgeQhgfCB3A2AOsB02M0IzkFDp K/MxICjwZhQgB3MKwLckUBQRLeBvK9AYIHYj0Ys1UTVwbRrQaCB1LBF7LnA00CAuUCLgHSczQkmd NvBpBUAssTLqT0s1Ul82oi3yNzE00AVAWC4gdf0FQG4ysDcBOuALUDagNRC/A3AkUAEAITA3EABw ZC3gzwdxN3s8ZClQY2s4yy5xdy3iA6A4cCcEIDtCOZ8g3l8AcDqQBGAYIF868zhx5GRvB5BuJwVB MvkkQOZjHqIFEGx5MuoHgAORXy3wOrE8ZCixAiBkNMFn7zVwOHRDITdgVQCQK7Et8h8kQAfgNEZF 0zLqS2l2kwuAP+FjYTwxdXAygPc4cDaALKBoDeA2gAQANwHrCcE6sWkBAGEuoADALlC/BCAt8Ewx HTZCEjTQcAqx9SPRLjLqWTJiAHA1Q0Lg30QRRyApUDqwJFBOK9ALcNMUADbSSVAGYGMsUjdgvzBA REAyQ0NsUSZF405Lkf8y6lHCOGJMMUBoUQhB0U5zHzwQMkM8YRQgOhRJS0X/N3ssYDrzReM9W0L1 RZgt8u9VQlZDUioyQ2o2oENOUSXnPOBMMTwSaG8H4DLqLjD3POAFsSQwYTsQP9E+cWDC/09JMugw cDqCTwFDMUQpYnJXJJBbBDqBbR4gaAVAYvplN2BBPNEGkFNLQuBDIt88EjLoB4AT0QMAcy3RNXDf NcAGgTqQLfJjGWkCIDbS5y3yCfA84HBvC4ApICSQ/x02aHE4cWrCHuBuEDLoMlH8J2wDICRAa3E3 IDtAB+D/JDApUAMgMlIkQGDhLfIr5P80IFrRHtALcU9HHTZa4ERA/wAgBpBjgy4gC4BG4j/xAQD9 Y2F0a8E1cDcTKIADoDcQ/2tzBzACYCRQLLA3WVASd4T/CYBuRzthPNEFAEyhYOFSWf84QQtgDrBe IUXCJFB0wm1w/HhwUeAHkUK5RZIdNkXj/1jjTOA7NGMpRdQn0BQAAiDvJJACIGaBXSdDWuBQUn2S XybXbcAkMGKhNvBmWUBzNzaAc0Q4Mkk68TqRIDb/CrA+kDbSZ/ASgTzCNqI3EP9o5wUQa3FAMSjw REAAgDLX/2tIItB2CDzCHtE8tEXziB3/HSd9NkhkDtBo53hAfa5F1P+FgBPgNcA1Ui3wA2AH4Ahg fzthcIEt84aihYAdNhPgZPdDIogAAHBrHTZfU2fwSvD/NqKKIYv/VsMH4H00Y9AdJf8dNIWAaWRN oSaQTZR3YQdAx3/BAHAHQG9neWbhlOb+b19xC1FEQZhmLkE00Hgx/zJCBcA1kEqBWUCLMTVhhaL/ hpRe9B7gBUAG8ASBJJCK4/5sPBAkkC3ylY95RU2Cf0X/kLRyYp0+khYkkDtCiAGZAf84cE9FHTRa 4RQgfDKaBUwk/wqwBBBtwAAgUuISIJoBf7D/A5Gn5o3jNPFMMp/xNwEYIPxxdX1hB4A14n82O0I2 ov9WkjhSQDFHIEgjNXB9NHcit4SRogMDoDNCAQIwaFLR/2UxbbRtBEwxTDF/J4SwCGD/n0BDImfw dyQCEBggHiBK0fmEAXRyOpBLcwORlwWn17+fhGdDUFZnkAMAZ5B6gOa/myAAkHWAKPB2cDdgWW9x /U0xebJRMlI04pTWOHG0Vv9L0XgBMlOqApyCZuQyUqal/ztCcgM4cQIgUyG55ykwl5ryTWViZ3Wr U0wyBuCRov9jIQWwttBssySQS9SYUUzg/0MifTGIkThwZoGrUmzSZ/D/stKvtAPwPNCRYjbwYvTA 4v9g4TaiS9A/4TcQdMsFkQeC/TWhby5QepEDkbJRGCEa0P1g4WI6kKrkSCYOwCkBCfD/UyFtFXKY pbsvKDOQOEEyUuMioYYxQ1JMBCBwwjqQ/jEWULaBOxAtcgWxANApUP+Q0RQQt4ECIHXCPOAdNjtB /4ihWzzGfDahPOGt0SkQd+HfBACEwdBmwYVMMWMIcE8C/2aB0ofQFCvxHSeGkQOgx9b/P8U1ESLA NMFO0ANgo0FUs701cGNZQArBWZNSaEJCgt8DoR1FHuAkQJPAbJ+EdzH/fKMsAsYhTpJ0u2EScYED IPuZpB02KAWxf3VDKjWyNpP/dMlNgXaxgExycYFjLqBnBf9Zy1rR18JfW0cgJEGcg8/C/0vQUWFw 0kyRgYM4cUyRcID/lWGPhpxCFBCMylCiWTcdNv97OgVAX1N9cbHggxJFwSLA76ghCsBmkZtxa5GR bhEswf8oFB0nJ6M8UQTyZ/DRKN41/ztBVNXUcQAgciOw80yRl23/uDNF4kAxBaEYICgw3FVCxP/r uuzzdRAkQWfwkLFs0Jzx/970qeQ04n+wASCqAVMRogX/orgysWNhHmE1YcjEbXBLgf8SgSixCHF2 cQWxbeEEkNpw/92Rt7ZoMoWAHtAJ0UXUOHL/sdKyQmKCNWGQs/w26rGx4P2bomUn0DzQK6Js4WGC cl3/TDJjL6YHJlCFgDtC9/V3I/8tQbaBSEJdRXKZSOco8GeQ/7/0qoIt8h7ADDcFlRewK7H/zcPI YWt9wOfE03LByUHldH0VkD8wYbDE6tV8owSQeP9tBiEApsIkkCnRdYG6YkuC/S3yZtABXRjKW6fB cqlwgP9hkM6RLADO8Nsi40FLUT/R9i9ocRGmJ4sBEDv488dU76rRr1A1wDzgKJTWbC0V0OlxkHMp pbtMNTE9ISwA74ZAMlJNoiswVwIz1+Aykf8rsRVHqu8XjXgxzpHKYhIg/kmpxkZz/7T/wCAhbsRC 4v8lA9misxF1A9aDTnP8MvGw3++hNVI0kMKgq0M/zB/NJd5EUGBznyy8zPRUNJDM9AJ9LxAAHgBC EAEAAAA2AAAAPDE5OTkwNjE3MjEyMi5PQUEwNDcyOEBwb3Rhc3NpdW0ubmV0d29yay1hbGNoZW15 LmNvbT4AAAADAN4/r28AAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAFgAggBgAA AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAACACCAGAAAAAADAAAAAAAAARgAAAABShQAA8BMAAB4A AYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQADAAKACCAGAAAAAADAAAAAAAAA RgAAAAABhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAAAAAA wAAAAAAAAEYAAAAAEYUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ACIAI IAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAmACCAGAAAAAADAAAAAAAAARgAA AAA3hQAAAQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAA AAsAC4ALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwAMgAsgBgAAAAAAwAAAAAAAAEYAAAAA BYgAAAAAAAALAJmACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAQYAIIAYAAAAAAMAAAAAA AABGAAAAAAaFAAAAAAAAAwDxPwkEAAADACYAAAAAAAMANgAAAAAAAwD9P+QEAAADAIAQ/////wIB RwABAAAAOgAAAGM9VVM7YT0gO3A9VGltZVN0ZXAgQ29ycG9yYTtsPUVYQ0hBTkdFLTk5MDYxODEy NDcyM1otNDQ4OAAAAB4AOEABAAAACQAAAFRKRU5LSU5TAAAAAB4AOUABAAAACQAAAFRKRU5LSU5T AAAAAEAABzDQxzS2iLm+AUAACDCAX4C3iLm+AR4APQABAAAABQAAAFJFOiAAAAAAHgAdDgEAAAA4 AAAARGFuZ2xpbmcgcGhhc2UgMiBTQXMgKHdhcyBSRTogaXNzdWVzIGZyb20gdGhlIGJha2VvZmYp IAAeADUQAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZCNjgxNEVAZXhj aGFuZ2U+AAAACwApAAAAAAALACMAAAAAAAMABhCsVCS0AwAHELILAAADABAQAQAAAAMAERAAAAAA HgAIEAEAAABlAAAALS0tLS1PUklHSU5BTE1FU1NBR0UtLS0tLUZST006REFOSEFSS0lOU01BSUxU TzpESEFSS0lOU0BORVRXT1JLLUFMQ0hFTVlDT01TRU5UOkpVTkUxNywxOTk5NToyMlBNVE86VAAA AAACAX8AAQAAADIAAAA8MzE5QTFDNUY5NEM4RDExMTkyREUwMDgwNUZCQkFEREZCNjgxNEVAZXhj aGFuZ2U+AAAAQNA= ------_=_NextPart_000_01BEB988.B7805F80-- From owner-ipsec@lists.tislabs.com Fri Jun 18 08:03:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01989; Fri, 18 Jun 1999 08:03:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28373 Fri, 18 Jun 1999 09:10:06 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB681A0@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: Dangling SA Summary Date: Fri, 18 Jun 1999 09:21:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an attempt to summarize the issue, and list the pros and cons. The purpose of requiring no dangling phase 2 SAs is minimize the window of unauthorized use of a system. With dangling phase 2 SAs, the maximum window size is the sum of the phase 1 SA lifetime plus the phase 2 SA lifetime. Without dangling phase 2 SAs, the maximum window size is the phase 1 SA lifetime. While the differences between the two window sizes can be reduced by careful configuration of lifetimes, it can never be eliminated, and requires knowledgeable system administration, and is dependent on the PKI infrastructure. Advantages ---------- -shorter maximum window size -better clean up if unauthorized use detected: the offending SAs can be deleted using notification mechanisms -system administrators need less understanding of the entire system to minimize the window of unauthorized use (independent of authentication mechanism, one less parameter they need in configuring the system) -allows protocol to inherently maximize security (with respect to this issue) Disadvantages ------------- -risk of "holes" in service if an end that doesn't allow dangling phase 2 SAs has a longer phase 1 lifetime than an endpoint that does allow dangling phase 2 SAs -slightly more complex to implement (? -and I'm not convinced of this) -rules for Identity PFS may need more work; however, it's already a special case anyway Given these trade-offs, I still favour requiring that phase 2 SAs not dangle. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Fri Jun 18 09:14:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03058; Fri, 18 Jun 1999 09:14:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28546 Fri, 18 Jun 1999 10:03:48 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 07:11:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue of dangling phase 2 SAs seems to have created a camp that believes that when a certificate is revoked, a compromise has occured, and therefore any phase 2 SAs created under the phase 1 SA with a now revoked certificate as the authentication mechanism should be removed. Point 1: Compromise? What compromise? There are many reasons to revoke a certificate that in no way invalidates authorizations that certificate performed prior to the revokation. For example, an employee leaves a company, the company revokes that employees certificate. Actions that employee took while still employed are still valid. Point 2: That compromise didn't hurt this old SA. If a compromise occurs on a phase 1 authorization mechanism (such as: private key stolen or shared secret blurted out in the throws of passion), obviously, the phase 2 SAs under that mechanism created _after_ the compromise are suspect :-). But, the phase 2 SAs created _prior_ to the compromised are not suspect if perfect forward secrecy is used (and the Phase 1 SAs get deleted ASAP). The phase 2 SAs may not even be suspect if perfect forward secrecy is not used as long as the host whose authorization is in question is not compromised. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN2pShrXbkJfuXzRQEQIMBgCgvfNKs6RbPoVS5itT2BKbEcuzwJEAn0/Y y8cH7gP/TPTXWz6h/0LTqta5 =8Yuv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 18 09:14:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03059; Fri, 18 Jun 1999 09:14:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28613 Fri, 18 Jun 1999 10:17:20 -0400 (EDT) Date: Fri, 18 Jun 1999 17:26:38 +0300 (EET DST) From: Markku Savela Message-Id: <199906181426.RAA27982@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDFB6815D@exchange> (message from Tim Jenkins on Fri, 18 Jun 1999 08:51:51 -0400) Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My gut feeling vote goes for "let them dangle". -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Fri Jun 18 09:15:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03079; Fri, 18 Jun 1999 09:15:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28492 Fri, 18 Jun 1999 09:50:23 -0400 (EDT) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Boby Joseph" To: "Waters, Stephen" cc: Tim Jenkins , ipsec@lists.tislabs.com Message-ID: <86256794.004D8FB9.00@mwgate02.mw.3com.com> Date: Fri, 18 Jun 1999 09:05:50 -0500 Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the certificate which is used for authenticating the Phase1 SA which authenticates phase 2 SA, then you can delete phase 1 and phase 2 SAs. It is not depending on phase 1 SA exists or not. I might be missing something here, but for me it looks like an implementation issue. "Waters, Stephen" on 06/17/99 05:36:30 PM Sent by: "Waters, Stephen" To: Tim Jenkins cc: ipsec@lists.tislabs.com (Boby Joseph/MW/US/3Com) Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) An interesting point that. Since the lifetime on Phase1 takes notice of the lifetime of the certificate used, the intention is that the certificate user should not be allowed to connect once the certificate has expired. It does not seem sensible to allow Phase-2 SA to live past the lifetime of the certificate either. If the Phase-1 SA used the 'life-left' value of the certificate when it was established, should we restrict the Phase-2 SAs negotiated to live no longer than the parent Phase-1? Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, June 17, 1999 9:06 PM To: Dan Harkins Cc: Volpe, Victor; Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 17, 1999 3:35 PM > To: Tim Jenkins > Cc: Volpe, Victor; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > "bounds the authenticated lifetime"? Does the > "authenticatedness" somehow > get diluted as time goes on? I guess I hadn't realized that. The RFCs state that the lifetime of a phase 1 SA must be limited, in addition to local policy requirements when using certificates, to the lifetime of the certificates involved and the CRL used to verify the certificates. This quite clearly is intended to make sure that the phase 1 SA lifetime is limited to the time that the endpoints can be authenticated. That what I mean by "bounds the authenticated lifetime". Once the original phase 1 and phase 2 SAs are created, the fact that they have different lifetimes means they almost live independently so the phase 1 SA existence is necessary to authenticate the endpoints on a continuous basis. > > Phase 1 lifetimes are set to prevent too much use of a key. > If it was > OK to use the key at X but not a X plus some delta and time > delta ticks > off then it's not OK to use the key _any more_ but it doesn't > necessarily > mean that delta seconds ago it wasn't. Using the new lifetime that > Kivinen came up with (which is a great idea) makes this more apparent. > You want to do negotiate N pairs of IPSec SAs. Once you > negotiate that Nth > pair it is not OK to negotiate anymore so you delete the IKE > SA but that > doesn't mean that the Nth pair of IPSec SAs you just > negotiated is somehow > bad or unauthenticated. They aren't necessarily bad, but they might be. And if you don't some mechanism to verify the authentication of the end points, if it changes, you'll never know until you need the phase 1 SA again. > > What I think is unnecessary is the level of complexity involved in > doing what's described in draft-jenkins-ipsec-rekeying-01.txt. Um, you've said that before about the phase 2 re-keying proposal and you've never said why or pointed out any errors in the logic that lead to that proposal. However, this thread is about phase 1 re-keying, and the document simply proposes that you allow multiple phase 1 SAs to exist and that you always use the oldest one first until it really does expire. Is that really that complicated? (As a side note, if phase 2 re-keying had been done that way in the first place the complex proposal in draft-jenkins-ipsec-rekeying-01.txt wouldn't have been necessary.) Tim > > Dan. > > On Thu, 17 Jun 1999 14:34:09 EDT you wrote > > Phase 1 re-keying is discussed in some detail in > > . > > > > Also, the act of orphaning phase 2 SAs (as described below) > in my mind is > > both unnecessary and also insecure, since the phase 1 SA is > what bounds the > > authenticated lifetime of the end points. So to leave a > phase 2 SA up > > without a valid phase 1 SA is to let it live beyond its > allowed limits. > > > > > > > > --- > > Tim Jenkins TimeStep Corporation > > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@lists.tislabs.com Fri Jun 18 09:19:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03116; Fri, 18 Jun 1999 09:19:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28565 Fri, 18 Jun 1999 10:11:33 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: "'Tim Jenkins'" , "Heyman, Michael" Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 07:19:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > >[SNIP] > > > Let me ask you this: What is wrong with the requirement that > > > a phase 1 SA always exist? > > > > > For secrecy, if a machine is compromised and the phase 1 SA > > is there, all the traffic between phase 2 SAs created under > > the phase 1 SA prior to the compromise is vulnerable. If the > > phase 1 SA is not there, the earlier phase 2 SA's traffic is > > secure. > > Why is there a difference in what is compromised? Is it because > the phase 1 SA keys are still on the compromised machine? > Yes. Possible scenario: Eve records the traffic between Alice and Bob (the traffic is protected by IPsec). Eve, at some later time, compromises Alice's host and retrieves the phase 1 SAs (includes key material and key derivation material). Eve can recreate even old phase 2 SAs that used the phase 1 SA and, thus, decrypt all the old traffic. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN2pUV7XbkJfuXzRQEQI7MACg/hjijEXnsQNMmaREu8TCCvhA5wQAoMgE aREG1Gav9WT+QXzpWyFk5oOw =TaIF -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 18 09:19:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03126; Fri, 18 Jun 1999 09:19:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28589 Fri, 18 Jun 1999 10:15:06 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68231@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: FW: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 10:23:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My response to Michael's private email was sent before his post to the list appeared... -----Original Message----- From: Tim Jenkins Sent: June 18, 1999 10:18 AM To: 'Heyman, Michael' Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > -----Original Message----- > From: Heyman, Michael [mailto:Michael_Heyman@nai.com] > Sent: June 18, 1999 10:10 AM > To: 'Tim Jenkins' > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The issue of dangling phase 2 SAs seems to have created a camp that > believes that when a certificate is revoked, a compromise has > occured, and therefore any phase 2 SAs created under the phase 1 SA > with a now revoked certificate as the authentication mechanism should > be removed. > > Point 1: Compromise? What compromise? > > There are many reasons to revoke a certificate that in no way > invalidates authorizations that certificate performed prior to the > revokation. For example, an employee leaves a company, the company > revokes that employees certificate. Actions that employee took while > still employed are still valid. I don't think system administrators would agree with you here. If an employee leaves a company, he/she is supposed to leave behind all access to that company's assets. The longer SAs are left up after this point, the greater the exposure. Yes, it's a different kind of compromise that key material or authentication, but it's a compromise none the less. > > Point 2: That compromise didn't hurt this old SA. > > If a compromise occurs on a phase 1 authorization mechanism (such as: > private key stolen or shared secret blurted out in the throws of > passion), obviously, the phase 2 SAs under that mechanism created > _after_ the compromise are suspect :-). > > But, the phase 2 SAs created _prior_ to the compromised are not > suspect if perfect forward secrecy is used (and the Phase 1 SAs get > deleted ASAP). The phase 2 SAs may not even be suspect if perfect > forward secrecy is not used as long as the host whose authorization > is in question is not compromised. Yes, you're right, but this isn't the kind of compromise I'm trying to minimize. I'm trying to minimize the unauthorized access window. > > - -Michael Heyman > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.1b23 > > iQA/AwUBN2pSD7XbkJfuXzRQEQI6XwCcCog8f6jE/CaMrMut3dIOg/vFB6UAoORS > LTC7i6XlGKC2gFREN0P0WMdS > =DYTO > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Fri Jun 18 10:44:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04708; Fri, 18 Jun 1999 10:44:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28865 Fri, 18 Jun 1999 11:17:45 -0400 (EDT) Date: Fri, 18 Jun 1999 18:27:02 +0300 (EET DST) From: Markku Savela Message-Id: <199906181527.SAA27995@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: IPSEC, IPv6 and mobile IP Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm hoping to build an IPv6 stack in modular way and minimize the interdependence of various components, such as IPSEC and Mobile-IP. In IPv4 AH implementation was fairly easy and deterministic, but with IPv6 AH appears to be a headache... What I hope is to build the packet incrementally by calling various modules in sequence. Now consider this on mobile hosts with HA=home address, CA=care address , RCA=Remote care address, RHA=Remote home address I have two possible call sequences for outgoing traffic a) mobible-IP, IPSEC Start: ip(HA->RHA) Apply mobile-IP ip(CA,RCA),Rth(RHA),DestOpt(Home=CA) Apply IPSEC (AH) [two possible positions for AH, but not the problem] 1) ip(CA,RCA),Rth(RHA),AH,DestOpt(Home=CA) 2) ip(CA,RCA),Rth(RHA),DestOpt(Home=CA),AH Ooops! I can only create SA's between care addresses, i cannot have associations betwen home addresses (HA/RHA), because at this point I don't see those anymore. b) IPSEC, mobile-IP Start: ip(HA->RHA) Apply IPSEC ip(HA->RHA),AH Apply Mobile-IP Ooops! Cannot insert DestOpt or Routing header, because they are not included in AH. I suppose I could do a "tunnel trick?", and produce ip(CA->RCA),Rth(RHA),ip(HA->RHA),AH This would work? I would not need "home address option"? -- *If* I inserted the DestOpt and routing header, the result would be ip(CA->RCA),Rth(RHA),DestOpt(HA),AH which would fail on remote AH, because it is required to check all headers in front of AH. It would cause no problems if headers were processed sequentially, first Rth and DestOpt, resulting ip(HA->RHA),AH and applying AH to this would succeed nicely (of course, leaving no protection on Rth or DestOpt). (DestOpt could be protected by putting the AH before it, but there is no such solution for the routing header). -- I thougth the IPv6 idea was to allow processing the extension headers sequentially one at time, and IPSEC AH appears to contradict this seriously. Just wondering if it would be a better world if the sequential approach was strictly applied and AH would only protect the plain IPv6 header? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Fri Jun 18 10:48:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04764; Fri, 18 Jun 1999 10:48:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28877 Fri, 18 Jun 1999 11:19:03 -0400 (EDT) Date: Fri, 18 Jun 1999 11:28:12 -0400 Message-Id: <199906181528.LAA25351@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff References: <199906151954.MAA21779@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> - Is it OK to send 3 copies of every single message (which one Dan> implementation was doing)? Yes. I don't think so. The general rule of protocol design and implementation is: be strict in what you send, lenient in what you receive. To put that differently: I don't subscribe to the notion that "everything not prohibited by the spec is permitted". Rather, I interpret the principle above to say: on the transmit side, everything not specifically allowed is prohibited. On the receive side, everything not prohibited that can be handled sensibly without excessive cost is permitted. For example, I don't think the TCP spec says that you shouldn't send each packet twice. Does that mean that an implementation that does this (absent some specifically configured fault tolerance notion) is a valid implementation? No way. Similarly, the IKE spec doesn't specifically prohibit sending 3 copies of the message because, I submit, no one thought that anyone would be silly enough to do this, so it wasn't necessary to make a specific rule "don't do this silly thing". But I would certainly call this implementation broken. paul From owner-ipsec@lists.tislabs.com Fri Jun 18 11:07:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04941; Fri, 18 Jun 1999 11:07:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29043 Fri, 18 Jun 1999 12:08:05 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: "'Tim Jenkins'" , ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 09:04:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >[SNIP > > > > The issue of dangling phase 2 SAs seems to have created a camp > > that believes that when a certificate is revoked, a compromise > > has occured, and therefore any phase 2 SAs created under the > > phase 1 SA with a now revoked certificate as the authentication > > mechanism should be removed. > > > > Point 1: Compromise? What compromise? > > > > There are many reasons to revoke a certificate that in no way > > invalidates authorizations that certificate performed prior to > > the revokation. For example, an employee leaves a company, the > > company revokes that employees certificate. Actions that employee > > took while still employed are still valid. > > I don't think system administrators would agree with you here. If > an employee leaves a company, he/she is supposed to leave behind > all access to that company's assets. The longer SAs are left up > after this point, the greater the exposure. > > Yes, it's a different kind of compromise that key material or > authentication, but it's a compromise none the less. > Hmm, to make sure I understand, a contrived example: . Gary the GVPN administrator has a company issued certificate giving him the privilege to set up a secure link. . He sets up a GVPN link using IPsec/IKE between his company and Widget Inc. using his company issued certificate for authorization. . Gary then leaves the company. The company issues Gary's certificate in a CRL. . Widget Inc. is paranoid (a good thing) and assumes, upon getting the new CRL, that Gary left for evil reasons and before he left, had oppertunity to get key information. What does Widget Inc. do? Dump all the SAs that were in any way under Gary's control to reduce possible exposure. This makes sense - maybe I'm changing my mind :-) . But, on the other hand, if Gary's certificate just expired, I think that does not invalidate what was authenticated with the certificate before the certificate expired. (A document signed before the signature key certificate expired still has a valid signature long after the signature certificate expires.) So, IMHO, dangling phase 2 SAs are ok (and may even be needed) but, implementers may wish to create a way to get rid of phase 2 SAs based upon some types of change of validity of authentication in phase 1. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN2ps8bXbkJfuXzRQEQJO5gCgsvKvtQ7IlCizxZzm77AtgdFrkWUAoMIx dTJbDFr75Kvcn4Yo6ss27dgA =Q1u8 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 18 11:44:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05233; Fri, 18 Jun 1999 11:44:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29190 Fri, 18 Jun 1999 12:53:26 -0400 (EDT) Message-ID: <376A7BEE.F5E813FF@redcreek.com> Date: Fri, 18 Jun 1999 10:03:42 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheila Frankel CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long) References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sheila, Thanks for your very timely review. Comments interspersed... > Sheila Frankel wrote: > > > 1) In a number of messages, rather than placing the erroneous > data > > in the Notification Data field, you've incorporated it into another > > Notification Payload field (e.g., for INVALID-PROTOCOL-ID the invalid > > protocol value is placed in the Protocol ID field). This necessitates > > individualized processing for these messages; whether or not that > > processing will take place, it would be helpful if a standardized > > logging routine could just save the Notify Message Type and the > > Notification Data. Yes, I guess I agree. The intent was to use existing fields which matched the data, but which would be empty (taking up space) if the data were carried in the notification data field. I have no qualms with changing it if others don't object. > 2) For each message, you've indicated the Phase and the > > Differentiators. It would also be helpful to list the relevant > payloads > > to which the message applies. (I've added those in my comments; if the > consensus > > is that this isn't useful, that's OK with me.) > Okay with me. I'm going to clip this message at this point to keep the discussion more manageable, and I'll reply to some of the individual payload issues you raise after giving them some more thought, and perhaps hearing from others. I will comment on one other item, though: regarding the unrecognized vs. unsupported payload types, I think this is a very good point. I guess the question is, if I send a notify such as INVALID-PAYLOAD-TYPE, how could the receiver differentiate between the two cases? Scott From owner-ipsec@lists.tislabs.com Fri Jun 18 11:44:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05247; Fri, 18 Jun 1999 11:44:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29121 Fri, 18 Jun 1999 12:36:45 -0400 (EDT) Message-ID: <376A7806.895ACB0B@redcreek.com> Date: Fri, 18 Jun 1999 09:47:02 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary References: <319A1C5F94C8D11192DE00805FBBADDFB681A0@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins wrote: > > This is an attempt to summarize the issue, and list the pros and cons. > > The purpose of requiring no dangling phase 2 SAs is minimize the window of > unauthorized use of a system. With dangling phase 2 SAs, the maximum window > size is the sum of the phase 1 SA lifetime plus the phase 2 SA lifetime. > Without dangling phase 2 SAs, the maximum window size is the phase 1 SA > lifetime. > > While the differences between the two window sizes can be reduced by careful > configuration of lifetimes, it can never be eliminated, and requires > knowledgeable system administration, and is dependent on the PKI > infrastructure. I think this gets to the heart of it. This situatation is far more complex than is obvious at first blush. Thinking out loud (so to speak), it occurs to me to ask why we limit the cert validity period to begin with. It appears that this serves to limit the vulnerability window in case either the cert is hijacked or the mate to the contained key is compromised. Now, going one step further to ask why we limit the lifetime of the phase 1 SA to the cert validity period, we may arrive at a similar conclusion, that being that since the cert could have been compromised at some point during the validity period, we would like to mitigate the damage by similarly limiting the validity period of the phase 1 SA. Given this general drift, it seems to logically follow that the lifetime of related phase 2 SAs should be similarly constrained for the same reason, i.e. to minimize the damage should compromise occur. This appears to be precisely the conclusion Tim has reached, and I think I'm beginning to agree, at least in principle. If we agree that the phase 2 SA should be similarly bound in terms of lifetime, the remaining question pertains to how we accomplish this. I think we have 2 choices: bind the phase 1 and phase 2 SAs, as Tim suggests, or limit the phase 2 SAs to the remaining cert lifetime if their configured lifetimes would exceed this. I'm still thinking about which is the better approach. Is there a flaw in the reasoning regarding phase 2 lifetimes with respect to cert validity periods? Scott From owner-ipsec@lists.tislabs.com Fri Jun 18 11:46:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05272; Fri, 18 Jun 1999 11:46:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29090 Fri, 18 Jun 1999 12:28:35 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68301@exchange> From: Tim Jenkins To: "Heyman, Michael" , ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 12:40:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Heyman, Michael [mailto:Michael_Heyman@NAI.com] > Sent: June 18, 1999 12:05 PM > To: 'Tim Jenkins'; ipsec@lists.tislabs.com > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >[SNIP > > > > > > The issue of dangling phase 2 SAs seems to have created a camp > > > that believes that when a certificate is revoked, a compromise > > > has occured, and therefore any phase 2 SAs created under the > > > phase 1 SA with a now revoked certificate as the authentication > > > mechanism should be removed. > > > > > > Point 1: Compromise? What compromise? > > > > > > There are many reasons to revoke a certificate that in no way > > > invalidates authorizations that certificate performed prior to > > > the revokation. For example, an employee leaves a company, the > > > company revokes that employees certificate. Actions that employee > > > took while still employed are still valid. > > > > I don't think system administrators would agree with you here. If > > an employee leaves a company, he/she is supposed to leave behind > > all access to that company's assets. The longer SAs are left up > > after this point, the greater the exposure. > > > > Yes, it's a different kind of compromise that key material or > > authentication, but it's a compromise none the less. > > > Hmm, to make sure I understand, a contrived example: > > . Gary the GVPN administrator has a company issued certificate > giving him the privilege to set up a secure link. > > . He sets up a GVPN link using IPsec/IKE between his company and > Widget Inc. using his company issued certificate for > authorization. > > . Gary then leaves the company. The company issues Gary's > certificate in a CRL. > > . Widget Inc. is paranoid (a good thing) and assumes, upon > getting the new CRL, that Gary left for evil reasons and > before he left, had oppertunity to get key information. > What does Widget Inc. do? Dump all the SAs that were in > any way under Gary's control to reduce possible exposure. > > This makes sense - maybe I'm changing my mind :-) . But, on the other > hand, if Gary's certificate just expired, I think that does not > invalidate what was authenticated with the certificate before the > certificate expired. (A document signed before the signature key > certificate expired still has a valid signature long after the > signature certificate expires.) If Gary's certificate just expired, he's not going to be able to re-key eventually anyway unless he's issued an updated certificate. Again, the difference is how soon he will need that updated certificate. If dangling phase 2 SAs is allowed, then he has (up to) the sum of the phase 1 and phase 2 expirations. If dangling SAs are not allowed, he has up to the phase 1 expiration time. Which is more prudent? Reducing the exposure window in case of Gary leaving the company, or opening the window in the case of Gary's certificate expiring? > > So, IMHO, dangling phase 2 SAs are ok (and may even be needed) but, > implementers may wish to create a way to get rid of phase 2 SAs based > upon some types of change of validity of authentication in phase 1. This is an interesting point, since it may be *customer* requirement of products anyway. In which case, the window size when Gary leaves the company may be irrelevant. However, I'm concerned about scalability issues in systems that need to provide that mechanism. CRLs have to be issued and then pushed (or CRL caches flushed) before the checks on local entities can even begin. > > - -Michael Heyman > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.1b23 > > iQA/AwUBN2ps8bXbkJfuXzRQEQJO5gCgsvKvtQ7IlCizxZzm77AtgdFrkWUAoMIx > dTJbDFr75Kvcn4Yo6ss27dgA > =Q1u8 > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Fri Jun 18 12:36:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05666; Fri, 18 Jun 1999 12:36:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29341 Fri, 18 Jun 1999 13:38:06 -0400 (EDT) Message-Id: <199906181746.KAA07670@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary In-reply-to: Your message of "Fri, 18 Jun 1999 09:21:51 EDT." <319A1C5F94C8D11192DE00805FBBADDFB681A0@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7667.929728006.1@network-alchemy.com> Date: Fri, 18 Jun 1999 10:46:46 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Jun 1999 09:21:51 EDT you wrote > > The purpose of requiring no dangling phase 2 SAs is minimize the window of > unauthorized use of a system. With dangling phase 2 SAs, the maximum window > size is the sum of the phase 1 SA lifetime plus the phase 2 SA lifetime. > Without dangling phase 2 SAs, the maximum window size is the phase 1 SA > lifetime. This is large club used to kill a small ant. The window only happens when you 1) are using certs; and, 2) have a case where the certificate expires while IPSec SAs exist. The CRL example is not convincing because there is no way to notice the second a cert has been revoked unless you spend 100% of your time doing LDAP queries for active sessions. That's not realistic and as Brian Korver noted yesterday this window approximates roundoff error for all the other windows. So the way to "fix" this (if you feel that this window is more than a roundoff error and needs to be closed) is to note the expiry of the certificate used to authenticate the IKE SA and use it to constrain IPSec SAs. This leaves one free to have dangling SAs for the 99.976% of the time that there is no window. Dan. From owner-ipsec@lists.tislabs.com Fri Jun 18 12:40:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05698; Fri, 18 Jun 1999 12:40:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29292 Fri, 18 Jun 1999 13:25:00 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68351@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 13:36:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: June 17, 1999 6:06 PM > To: Tim Jenkins > Cc: Paul Koning; ipsec@lists.tislabs.com > Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > On Thu, 17 Jun 1999 16:47:56 EDT you wrote > > Okay, phase 1 lifetime gets negotiated to 4 hours by a > dial-in client. Phase > > 2 lifetimes are set to expire at 5 Mbyte traffic. At 3 > hours and 50 minutes > > into the phase 1 lifetime, the phase 2 SAs are re-keyed. At > 4 hours, the > > phase 1 SA is deleted. Seems fine so far. A little later > the certificate of > > the dial in client gets revoked. So now we have phase 2 SAs > up that may be > > used by the person whose certificate has been revoked, and > they've got 5 > > Mbyte of data they can move before the system will redo > phase 1. If the > > presence of phase 1 SAs was required, this would have been > detected within 4 > > hours (at the next phase 1 re-key time: the phase 1 re-key > would fail) and > > the system would know to tear down all SAs. > > What if his certificate gets revoked 2 hours into the phase 1 > lifetime? > How do you know? Do you constantly recheck CRLs? How often? What if it > expires in between checks? I don't see how your concern is > addressed by > deleting the IPSec SAs when the IKE SA expires. The concern is shortening the window of checking. If we assume that the only checking of certificates is done is when phase 1 is negotiated, then if dangling SAs are allowed, the next check of the certificate will not occur until a new phase 1 is generated, which could be as late as just before the phase 2 SA is going expire. What I proposed in (NOT in -00.txt, I changed this after comments from the WG), is that phase 1 SAs be re-keyed before they expire. Therefore, the certificate is checked before the end of the phase 1 lifetime. If it fails, the new phase 1 SA never comes up. At this point an implementation could choose to tear down the old phase 1 SA and the phase 2 SAs, or just leave them until the old phase 1 SA expires naturally, and then tear down all SAs. There are no requirements in the RFCs for interim checks of certificates that I know of; it seems to me that the RFC requirements of limiting phase 1 SA lifetimes based on CRL next-issue-date and certificate lifetimes (in addition to local policy) is an attempt to address that. However, as I said elsewhere, interim checking by implementations may be a customer requirement anyway. > > And if this is your concern why not limit this 2nd > negotiation to 10 min > then and guarantee that the client will not think his IPSec SAs are > valid for longer than what you think they are. That would > prompt him to... I don't understand what you're saying here. Just because one end limits his lifetime to 10 min. doesn't mean the peer will use that lifetime. > ...renegotiate a phase 1 exchange for you without the obligatory blackout > period that happens when you delete the IPSec SAs which he thinks are > still valid. Since your overriding concern is a seconds-based > lifetime > anyway why do you negotiate a volume based SA which has a hidden, > unknown-to-client, life? You're defining some space in which > you want to > act in (the limit is seconds-based) and then intentionally > doing something > which is outside that space (negotiating a completely > different lifetime > which could extend beyond the limit). Surprise! It has > problems, at least > problems as you define them. With the current RFCs, there is no binding of phase 2 lifetimes to phase 1 lifetimes. Agreed? Then, there are possible combinations of lifetimes and traffic used where phase 2 SA's lives will go past phase 1 SA's lives, right? What I'm proposing is that when this happens, a phase 1 SA MUST be re-keyed such that there is always a valid phase 1 SA underneath. In other words, implementations must support overlapping phase 1 SAs. Is that currently prohibited? I don't see how it can be, since you don't know you've got overlapping phase 1 SAs until they're (almost) completely negotiated anyway (yes, it does depend on the mode). My overriding concern is not seconds based lifetime. I was asked to provide a specific example and I did. The point is that with dangling phase 2 SAs the endpoint identities (and thus indirectly the authorization) is not checked as soon as it could be. > > Your concern is allowing someone to have an IPSec SA when the > certificate > that was used to (indirectly) authenticate it has been > revoked. Deleting > IPSec SAs when the IKE SA used to generate them expires is > not the answer > (and actually causes other problems). Operating in the bounds > you place > around yourself-- i.e. don't renegotiate an IPSec SA which could live > longer that the underlying IKE SA-- will. If I understand what you're recommending here, how do you provide a continuous "tunnel" of SAs even through phase 1 expirations? Are you suggesting allowing multiple phase 1 SA with their own set of phase 2 SAs that live only within the phase 1 SA, but set up such that the phase 1 SAs overlap and the phase 2 SAs from the different phase 1 SAs have the same selectors???? That sounds more complicated than what I propose in the re-keying document... > longer that the underlying IKE SA-- will. Not everybody shares your> concern though and the beauty of operating within your self-imposed > boundaries is that they don't need to. > > Dan. > The only compatibility issue that I can think between allowing dangling phase 2 SAs and doing phase 1 re-keying the way I proposed in my draft is the case where the end that allows dangling SAs to exist has a shorter phase 1 SA lifetime. In this case, that end will send a delete for the phase 1 SA only (hopefully, anyway). The other end will see this and delete all its SAs. It should be self correcting in any case. However, if the end that doesn't allow dangling phase 2 SAs has the shorter phase 1 SAs lifetime, it will generate a second phase 1 SA before the first expires. If this comes up, it really doesn't matter if the other end immediately sends a delete for the old phase 1 SA; the initiating end will leave its phase 2 SAs up since the new phase 1 SA is up and valid. Finally, I'll say it again: with dangling phase 2 SAs, if the eventual phase 1 negotiation later fails, there is no authenticated way to delete the phase 2 SAs cleanly, so the now unauthorized peer may end up with orphaned SAs without having any idea why. Finally, I'm not sure I addressed all your (Dan's) comments because, quite honestly, I didn't understand them; I get the feeling you think I'm proposing the all SAs must be torn down when a phase 1 expires unconditionally. That's not what I'm proposing. Tim From owner-ipsec@lists.tislabs.com Fri Jun 18 12:55:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06000; Fri, 18 Jun 1999 12:55:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29462 Fri, 18 Jun 1999 13:52:34 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68385@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Dangling SA Summary Date: Fri, 18 Jun 1999 14:04:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 18, 1999 1:47 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Dangling SA Summary > > > On Fri, 18 Jun 1999 09:21:51 EDT you wrote > > > > The purpose of requiring no dangling phase 2 SAs is > minimize the window of > > unauthorized use of a system. With dangling phase 2 SAs, > the maximum window > > size is the sum of the phase 1 SA lifetime plus the phase 2 > SA lifetime. > > Without dangling phase 2 SAs, the maximum window size is > the phase 1 SA > > lifetime. > > This is large club used to kill a small ant. The window only > happens when > you 1) are using certs; and, 2) have a case where the > certificate expires > while IPSec SAs exist. The CRL example is not convincing > because there is > no way to notice the second a cert has been revoked unless > you spend 100% > of your time doing LDAP queries for active sessions. That's > not realistic.. I know. That's what my assumptions were in the first place. > ... and as Brian Korver noted yesterday this window approximates roundoff > error for all the other windows. And as I replied to Brian the round off effect is only small if the phase 2 SA lifetime is small compared to the phase 1 SA lifetime. Did you see my summary page? Note that it's not "me" that does this. It's customers. Since it's allowed by the RFCs, we in general have to permit them to do anything they want. But when they ask questions like "How long will it take the system to know that I've revoked a certificate" the answer is (based on the dangling phase 2 SA concept) is "The maximum time will be the sum of the phase 1 SA lifetime plus the phase 2 SA lifetime." > > So the way to "fix" this (if you feel that this window is more than a > roundoff error and needs to be closed) is to note the expiry of the > certificate used to authenticate the IKE SA and use it to > constrain IPSec > SAs. Then, since the phase 1 SA is supposed to be constrained by the same thing, both will expire at the same time. So then what happens? I re-key the phase 2 SAs just before the phase 1 SA expires, the phase 1 SA expires, I drop it, and I still have phase 2 SAs dangling beyond when I would have checked for the authorization of the end points. It is not possible to close the window; it is possible to reduce it's size and also to make the decision process of what lifetimes to apply to the various things a system administrator has to deal with easier. > > This leaves one free to have dangling SAs for the 99.976% of > the time that > there is no window. > > Dan. > Let's turn this around. What are your objections to *not* allowing dangling phase 2 SAs? Tim From owner-ipsec@lists.tislabs.com Fri Jun 18 14:04:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06721; Fri, 18 Jun 1999 14:04:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29666 Fri, 18 Jun 1999 15:24:09 -0400 (EDT) Message-Id: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> X-Sender: frankel@csmes.ncsl.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 18 Jun 1999 12:14:00 -0400 To: skelly@redcreek.com From: Sheila Frankel Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long) Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Courier NewThis is an excellent and much-needed document. I just have 2 general comments: 1) In a number of messages, rather than placing the erroneous data in the Notification Data field, you've incorporated it into another Notification Payload field (e.g., for INVALID-PROTOCOL-ID the invalid protocol value is placed in the Protocol ID field). This necessitates individualized processing for these messages; whether or not that processing will take place, it would be helpful if a standardized logging routine could just save the Notify Message Type and the Notification Data. 2) For each message, you've indicated the Phase and the Differentiators. It would also be helpful to list the relevant payloads to which the message applies. (I've added those in my comments; if the consensus is that this isn't useful, that's OK with me.) >2.1 INVALID-PAYLOAD-TYPE > > The INVALID-PAYLOAD-TYPE error message may be used to communicate > that an unrecognized or invalid payload type was received. > This should also apply to unsupported payloads. As IKE versions proliferate, new payloads may be added that are not supported by existing implementations. It should also apply to out-of-order payload types, e.g., a Phase 2 SA payload that precedes the Hash Payload. Payloads: ALL >2.2 DOI-NOT-SUPPORTED > > o DOI - set to the subject (unsupported) DOI This should (also) be in the Notification Data Field. Payloads: SA >2.3 SITUATION-NOT-SUPPORTED > Payloads: SA >2.4 INVALID-COOKIE > > The INVALID-COOKIE error message may be used to communicate that an > invalid ISAKMP cookie was received. > What's an invalid ISAKMP cookie? Does this message apply when the peer initiates a Quick Mode negotiation for an expired Phase 1 SA? If so, this should be explicitly stated. Payloads: ISAKMP Header >2.5 INVALID-MAJOR-VERSION > Payloads: ISAKMP Header >2.6 INVALID-MINOR-VERSION > Payloads: ISAKMP Header >2.7 INVALID-EXCHANGE-TYPE > > The INVALID-EXCHANGE-TYPE error message may be used to communicate > that that an unrecognized or invalid ISAKMP exchange type was > received. > Should this also apply to unsupported exchange types? (I think this is the only case where we have separate messages for invalid and unsupported.) Payloads: ISAKMP Header >2.8 INVALID-FLAGS > > The INVALID-FLAGS error message may be used to communicate that one > or more of the received ISAKMP header flags were unrecognized or > invalid. > Should this message be used in the following cases: 1) An unencrypted message is received, which should have been encrypted. 2) An encrypted message is received, which should have been unencrypted. If so, this should be explicitly stated. Payloads: ISAKMP Header >2.9 INVALID-MESSAGE-ID > > o Notify Message Type - set to INVALID-MESSAGE-ID > This should (also) be in the Notification Data Field. Payloads: ISAKMP Header >2.10 INVALID-PROTOCOL-ID > > The INVALID-PROTOCOL-ID error message may be used to communicate that > an invalid or unrecognized protocol ID was received as part of a > proposal payload. > Is unrecognized the same as unsupported? In either case, I think unsupported should be mentioned here. (picky, picky!!) Payloads: Proposal >2.11 INVALID-SPI > Payloads: Proposal >2.12 INVALID-TRANSFORM-ID > Payloads: Transform >2.13 ATTRIBUTES-NOT-SUPPORTED > Payloads: Transform >2.14 NO-PROPOSAL-CHOSEN > Payloads: SA >2.15 BAD-PROPOSAL-SYNTAX > Payloads: Generic Payload Header, Proposal, Transform >2.16 PAYLOAD-MALFORMED > > The PAYLOAD-MALFORMED error message may be used to communicate that a > malformed payload was received. > This includes proposals/transforms/attributes that are syntactically incorrect. Anything else? Payloads: Generic Payload Header, Proposal, Transform >2.17 INVALID-KEY-INFORMATION > > The INVALID-KEY-INFORMATION error message may be used to communicate > that the key exchange type specified by the key exchange payload is > not supported. > Wouldn't this also include key info that is not the correct length/size for the key exchange? Payloads: Key Exchange >2.18 INVALID-ID-INFORMATION > Payloads: ID >2.19 INVALID-CERT-ENCODING > Payloads: Certificate, Certificate Request >2.20 INVALID-CERTIFICATE > Payloads: Certificate >2.21 CERT-TYPE-UNSUPPORTED > Payloads: Certificate Request >2.22 INVALID-CERT-AUTHORITY > Payloads: Certificate Request >2.23 INVALID-HASH-INFORMATION > > The INVALID-HASH-INFORMATION error message may be used to communicate > that the required hash type is not supported. > Wouldn't this include a hash of the wrong length/size? Payloads: Hash >2.24 AUTHENTICATION-FAILED > Payloads: Hash, Signature >2.25 INVALID-SIGNATURE > Payloads: Signature >2.26 ADDRESS-NOTIFICATION > Payloads: ?? >2.27 NOTIFY-SA-LIFETIME > Payloads: Transform >2.28 CERTIFICATE-UNAVAILABLE > Payloads: Certificate Request >2.29 UNSUPPORTED-EXCHANGE-TYPE > > The UNSUPPORTED-EXCHANGE-TYPE error message may be used to > communicate that the requested exchange type is not supported. > Do we need this? (I think this is the only case where we have separate messages for invalid and unsupported.) Payloads: ISAKMP Header >2.30 UNEQUAL-PAYLOAD-LENGTHS > > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate > that message length in the ISAKMP header does not match the sum of > the actual payload lengths. This also applies in the case where the message length in the ISAKMP header does not match the length of the message that was actually received. It should probably also apply to other length-related anomalies. Payloads: ISAKMP Header From owner-ipsec@lists.tislabs.com Fri Jun 18 15:13:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA07227; Fri, 18 Jun 1999 15:13:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29879 Fri, 18 Jun 1999 16:38:19 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Fri, 18 Jun 1999 16:33:40 -0400 To: "Heyman, Michael" From: Stephen Kent Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, The generic reason for revoking a cert, is that some value in the attribute set in the cert is not longer valid. In the case of compromise, the public key is no longer consoidered to be accurately bound to the subject name. In general, an access control decision might be based on one of the other attributes that might have been the reason for the revocation, hence it is appropriate to consider killing an SA when a cert has been revoked that was used to authenticate a party to the SA. It may be overkill, but there are times when it wouldbe appropriate. Thus a safe reponse, in general, would be to kill off the SA. Steve From owner-ipsec@lists.tislabs.com Fri Jun 18 15:30:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA07527; Fri, 18 Jun 1999 15:30:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29935 Fri, 18 Jun 1999 17:04:44 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D0BB@md-exchange1.nai.com> From: "Mason, David" To: "'Scott G. Kelly'" Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-notifymsg-00.txt Date: Fri, 18 Jun 1999 14:00:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For ISAKMP header field error messages (flags, version, exchange, cookies, message id) it might be easier to implement and perhaps more beneficial for other reasons if the entire offending header was supplied rather than just the offending field. >2.1 INVALID-PAYLOAD-TYPE > o Notification Data - contains the subject payload Perhaps with this message and in others, when supplying an offending payload the NextHeader field in the subject payload should be set to the type of the payload in question. >2.13 ATTRIBUTES-NOT-SUPPORTED The transform id in addition to the protocol id should probably be supplied. Or better yet supply the SA payload with an offset indicator to the offending attribute. >2.14 NO-PROPOSAL-CHOSEN Optionally supply a proposal(s) that might be considered acceptable in the notification data. >2.15 BAD-PROPOSAL-SYNTAX Should probably contain an offset indicator to the offending byte within the proposal. >2.16 PAYLOAD-MALFORMED Also should have an offset indicator and there could be other messages that might benefit from an offset indicator as well. -dave From owner-ipsec@lists.tislabs.com Fri Jun 18 16:05:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08749; Fri, 18 Jun 1999 16:05:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00004 Fri, 18 Jun 1999 17:34:11 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D0BE@md-exchange1.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Fri, 18 Jun 1999 14:29:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When a customer asks what's the maximum time period after a certificate is revoked will the user of that certificate still have access, the answer with dangling phase 2 SAs would be: CRLexpirationInterval+Phase1Life+Phase2Life without dangling phase 2 SAs: CRLexpirationInterval+phase1Life I believe that the relative difference between these two periods is small and generally the Phase2Life will be by far the smallest component. If a customer is concerned about this question the answer should be: manually force a retrieval of a new CRL and manually delete the associated SAs. -dave From owner-ipsec@lists.tislabs.com Fri Jun 18 16:26:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09029; Fri, 18 Jun 1999 16:26:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00045 Fri, 18 Jun 1999 17:54:30 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D0BF@md-exchange1.nai.com> From: "Mason, David" To: "'Scott G. Kelly'" Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-notifymsg-00.txt Date: Fri, 18 Jun 1999 14:50:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >2.26 ADDRESS-NOTIFICATION This might be used when an initiating peer supplies an IDcr for which she's not allowed full access. The notification data could contain an ID for which she is allowed access. -dave From owner-ipsec@lists.tislabs.com Fri Jun 18 16:36:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09190; Fri, 18 Jun 1999 16:36:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00108 Fri, 18 Jun 1999 18:08:10 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199906181746.KAA07670@potassium.network-alchemy.com> References: Your message of "Fri, 18 Jun 1999 09:21:51 EDT." <319A1C5F94C8D11192DE00805FBBADDFB681A0@exchange> Date: Fri, 18 Jun 1999 18:05:14 -0400 To: Dan Harkins From: Stephen Kent Subject: Re: Dangling SA Summary Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, One minor observation re your comments. A CRL contains a NextIssue date and time. That provides a convenient trigger for fetching a new CRL. One can argue that an IPsec peer ought to attempt to fetch CRLs when they are claimed to be available, and that any SAs that were authenticated under certs that are now invalid, as per the fteched CRL(s), should be deleted. I'm not saying that one has to do this, but rather that it does seem like a reasonable approach. Steve From owner-ipsec@lists.tislabs.com Fri Jun 18 17:06:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09632; Fri, 18 Jun 1999 17:06:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00186 Fri, 18 Jun 1999 18:37:05 -0400 (EDT) Message-Id: <199906182236.PAA08522@potassium.network-alchemy.com> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary In-reply-to: Your message of "Fri, 18 Jun 1999 18:05:14 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8519.929745365.1@network-alchemy.com> Date: Fri, 18 Jun 1999 15:36:05 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, that's eminently reasonable. It sounds like the right thing to do. thanks, Dan. On Fri, 18 Jun 1999 18:05:14 EDT you wrote > Dan, > > One minor observation re your comments. A CRL contains a NextIssue date and > time. That provides a convenient trigger for fetching a new CRL. One can > argue that an IPsec peer ought to attempt to fetch CRLs when they are > claimed to be available, and that any SAs that were authenticated under > certs that are now invalid, as per the fteched CRL(s), should be deleted. > I'm not saying that one has to do this, but rather that it does seem like a > reasonable approach. > > Steve From owner-ipsec@lists.tislabs.com Fri Jun 18 18:14:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA10762; Fri, 18 Jun 1999 18:14:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00304 Fri, 18 Jun 1999 19:13:53 -0400 (EDT) Message-Id: <199906182312.QAA08708@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) In-reply-to: Your message of "Fri, 18 Jun 1999 13:36:46 EDT." <319A1C5F94C8D11192DE00805FBBADDFB68351@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8705.929747574.1@network-alchemy.com> Date: Fri, 18 Jun 1999 16:12:54 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Jun 1999 13:36:46 EDT you wrote > > > What if his certificate gets revoked 2 hours into the phase 1 > > lifetime? > > How do you know? Do you constantly recheck CRLs? How often? What if it > > expires in between checks? I don't see how your concern is > > addressed by > > deleting the IPSec SAs when the IKE SA expires. > > The concern is shortening the window of checking. If we assume that the only > checking of certificates is done is when phase 1 is negotiated, then if > dangling SAs are allowed, the next check of the certificate will not occur > until a new phase 1 is generated, which could be as late as just before the > phase 2 SA is going expire. > > > > > And if this is your concern why not limit this 2nd > > negotiation to 10 min > > then and guarantee that the client will not think his IPSec SAs are > > valid for longer than what you think they are. That would > > prompt him to... > > I don't understand what you're saying here. What I'm saying is that you're concerned about IPSec SAs being used beyond the validity period of a certificate used to authenticate the IKE SA. So when you authenticate with a certificate, note its validity period and use it to constrain IPSec negotiation. If someone sends you an offer for a lifetime that is greater than (cert-expiry-time - current-time) or if they offer no lifetime or a volume-based lifetim then use the RESPONDER- LIFETIME notify to tell the peer that these SAs are only good for (cert-expiry-time - current-time) seconds. > Just because one end limits his > lifetime to 10 min. doesn't mean the peer will use that lifetime. If it's pathological it won't but pathological implementations can do all sorts of things we don't want so let's not get hung up on them here. The point here is that you're telling the peer what the lifetime is and not having that be some hidden limit he doesn't know about (you're going to delete the SA is X seconds but he thinks it's good for X+Y seconds or Z kilobytes). It will allow him to know when he should delete his SAs and when he should initiate a re-key. If at that point he doesn't have a valid cert then don't talk to him. > What I'm proposing is that when this happens, a phase 1 SA MUST be re-keyed > such that there is always a valid phase 1 SA underneath. In other words, > implementations must support overlapping phase 1 SAs. Is that currently > prohibited? I don't see how it can be, since you don't know you've got > overlapping phase 1 SAs until they're (almost) completely negotiated anyway > (yes, it does depend on the mode). Why should I be required to negotiate an IKE SA simply because a pair of IPSec SAs exist? Maybe the IPSec SAs are not being used at the time the IKE SA times out and would not be rekeyed. By imposing this requirement on all you're making people do expensive public key operations for potentially no reason. (Where are all those people who don't want to do group 5 when configured for group 2? How'd you like to do group 2 plus a digital sign and verify for no reason?). This would be a bizarre requirement. It basically means that if at anytime I did an IKE and IPSec exchange with you then I have to keep doing them with you. "No! Stop! Enough! I don't want to talk to you anymore! Go away!" > If I understand what you're recommending here, how do you provide a > continuous "tunnel" of SAs even through phase 1 expirations? There are some simple rules to follow. One is, don't rekey IPSec SAs if they're not "being used." "Being used" is open to interpretation but basically, if it and its pair haven't been used to protect a packet in some time (N units of something) then let it die a quiet death. When re-keying IPSec SAs begin the exchange "enough time" before the SAs expire. "Enough time" is likewise open to interpretation. If you're a 20MHz 680x0 then you should probably give yourself more leeway then if you're a 500 MHz Pentium. When you re-key IPSec SAs do not throw away the old SAs. Artificially age them if necessary (giving them a lifetime of the minimum of their current life and "enough time" is a good way to do this). Begin to use the new IPSec SAs when established but allow traffic in on the old ones. Also, let IKE SAs just go away. If they're needed in the future they'll be established. When you do this the IKE SA dies and the IPSec SAs live on. If they're "being used" then a new request for SAs will be made "enough time" in advance of the IPSec SAs expiring. IKE will notice that it has no SA with the peer and do another exchange. The IPSec SAs will be stuffed in the SADB before the old ones expire (because it had "enough time") and will be used to protect traffic. The old SAs will just go away. The whole thing repeats. That's rekeying in a nutshell. But if this window of "unauthenticated" IPSec SAs is a problem, one can add another rule. When an request for IPSec SAs comes up and an IKE SA exists to the peer in the request then use it unless the lifetime of that SA is "low", where "low" is like everything else here open to interpretation and dependant on the implementation and hardward etc. If it's "low" then don't use it, begin another phase 1 exchange and use that to satisfy the request for IPSec SAs. The other IKE SA will die a normal death. If the other peer does a QM for you and the IKE SA is "low" then do a phase 1 exchange with him to get another IKE SA. But this extra level of complexity is only necessary if you're concerned about the case of a certificate that was used to authenticate a peer who currently has an active IPSec session was revoked. You're free to add this level of complexity to your code if you feel it's a problem. > Are you suggesting allowing multiple phase 1 SA with their own set of phase > 2 SAs that live only within the phase 1 SA, but set up such that the phase 1 > SAs overlap and the phase 2 SAs from the different phase 1 SAs have the same > selectors???? Yeech! No that's not what I'm suggesting. What I'm suggesting is just some simple things to do that makes rekeying a non-issue and to point out that dangling SAs are not a problem. It's really not that complicated. Dan. From owner-ipsec@lists.tislabs.com Fri Jun 18 19:16:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15395; Fri, 18 Jun 1999 19:16:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00509 Fri, 18 Jun 1999 20:39:47 -0400 (EDT) Message-Id: <199906190038.RAA09169@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary In-reply-to: Your message of "Fri, 18 Jun 1999 14:04:19 EDT." <319A1C5F94C8D11192DE00805FBBADDFB68385@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9164.929752722.1@network-alchemy.com> Date: Fri, 18 Jun 1999 17:38:45 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Jun 1999 14:04:19 EDT you wrote > > > This is large club used to kill a small ant. The window only > > happens when > > you 1) are using certs; and, 2) have a case where the > > certificate expires > > while IPSec SAs exist. The CRL example is not convincing > > because there is > > no way to notice the second a cert has been revoked unless > > you spend 100% > > of your time doing LDAP queries for active sessions. That's > > not realistic.. > > I know. That's what my assumptions were in the first place. > > > ... and as Brian Korver noted yesterday this window approximates roundoff > > error for all the other windows. > > And as I replied to Brian the round off effect is only small if the phase 2 > SA lifetime is small compared to the phase 1 SA lifetime. Did you see my > summary page? No it's small due to the other things that are not easy to quantify like how long does it take someone to realize their private key has been compromized? That's probably going to be big compared to the time an SA can dangle. > Let's turn this around. What are your objections to *not* allowing dangling > phase 2 SAs? Because not everyone feels that dangling SAs are a problem. Because your concern about making this window as small as possible can be taken care of in ways that only impact your implementation and not everyone else's. Because I don't want to have to do unnecessary and expensive public key operations which would arise if the IPSec SAs would not be rekeyed when they expire but the IKE SA which established them has timed out. Because it causes temporary blackouts. Because this problem happens very, very, very infrequently and to burden everyone to do something when 99.99% (or more) of the time the "problem" isn't even there and when it is alot of people don't view it as a problem is alot to require. It's an unnecessary burden. This protocol is already too complicated. Dan. From owner-ipsec@lists.tislabs.com Fri Jun 18 21:05:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA00233; Fri, 18 Jun 1999 21:05:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00627 Fri, 18 Jun 1999 22:19:05 -0400 (EDT) Message-ID: <376AFD29.A14DC67C@ire-ma.com> Date: Fri, 18 Jun 1999 22:15:05 -0400 From: bkavsan X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Dan Harkins CC: Tim Jenkins , ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary References: <199906190038.RAA09169@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk is there a problem in allowing co-existence of both dangling and non-dangling implementations? Dan Harkins wrote: > On Fri, 18 Jun 1999 14:04:19 EDT you wrote > > > > > This is large club used to kill a small ant. The window only > > > happens when > > > you 1) are using certs; and, 2) have a case where the > > > certificate expires > > > while IPSec SAs exist. The CRL example is not convincing > > > because there is > > > no way to notice the second a cert has been revoked unless > > > you spend 100% > > > of your time doing LDAP queries for active sessions. That's > > > not realistic.. > > > > I know. That's what my assumptions were in the first place. > > > > > ... and as Brian Korver noted yesterday this window approximates roundoff > > > error for all the other windows. > > > > And as I replied to Brian the round off effect is only small if the phase 2 > > SA lifetime is small compared to the phase 1 SA lifetime. Did you see my > > summary page? > > No it's small due to the other things that are not easy to quantify like > how long does it take someone to realize their private key has been > compromized? That's probably going to be big compared to the time an SA > can dangle. > > > Let's turn this around. What are your objections to *not* allowing dangling > > phase 2 SAs? > > Because not everyone feels that dangling SAs are a problem. Because your > concern about making this window as small as possible can be taken care of > in ways that only impact your implementation and not everyone else's. Because > I don't want to have to do unnecessary and expensive public key operations > which would arise if the IPSec SAs would not be rekeyed when they expire but > the IKE SA which established them has timed out. Because it causes temporary > blackouts. Because this problem happens very, very, very infrequently and to > burden everyone to do something when 99.99% (or more) of the time the > "problem" isn't even there and when it is alot of people don't view it as a > problem is alot to require. It's an unnecessary burden. This protocol is > already too complicated. > > Dan. From owner-ipsec@lists.tislabs.com Sun Jun 20 07:04:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28304; Sun, 20 Jun 1999 07:04:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02798 Sun, 20 Jun 1999 08:18:39 -0400 (EDT) Message-ID: <376CDC88.2768B517@checkpoint.com> Date: Sun, 20 Jun 1999 15:20:25 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: skelly@redcreek.com CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, I have one remark on the Notify message drafts. I believe that there should be room left in the notify payload for a textual message describing the problem. Such an error string along side the pre-defined notify types has the advantages of refining the meaning of the notify message type and it could be used for auditing or for displaying a message whenever a user is involved. So, my proposal is that the notify data field should be structured like a list of data attributes pairs (attribute type + attribute value), one pair would contain the data that you have proposed in your draft, and another (optional) pair would contain a string. Actually, I believe that a similar proposal was raised at the NC bakeoff a while back. Regards, Tamir. From owner-ipsec@lists.tislabs.com Sun Jun 20 17:29:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01951; Sun, 20 Jun 1999 17:29:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03428 Sun, 20 Jun 1999 18:47:48 -0400 (EDT) Message-ID: <729D927EF825D311961000E029101CCC258AE3@mxclsa> From: Black_David@emc.com To: ipsec@lists.tislabs.com Subject: draft-ipsec-ecn-00.txt Date: Sun, 20 Jun 1999 18:47:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to nudge the ipsec-ecn draft forward in hopes of getting it closer to WG last call. Since the original announcement of this draft, a few comments have been made, but none of them appear to require significant changes to the draft. A comment noted that the draft further couples the concepts of Tunnel and Security Association, and expressed the opinion that this coupling is the wrong architectural approach. Since the WG does not seem inclined to make the revisions to the IPsec architecture RFC required to change the architectural approach in this area, leaving the ipsec-ecn draft aligned to the current ipsec architecture seems preferable. A comment indicated that per-node configuration is easier to implement than per-SA configuration. After serious thought and despite initially encouraging per-node configuration, it no longer seems to be a good idea. The concern is that as ipsec and ecn deployment scale up, many ecn-aware ipsec implementations will find themselves communicating with a mixture of ecn-aware and ecn-unaware ipsec tunnel endpoints. In such an environment with per-node configuration, the only reasonable thing to do is turn off ecn support for all ipsec tunnels, which is not the desired outcome. Several comments noted that SA negotiation is complex, and adding to it is non trivial. One comment suggested using ICMP after tunnel setup as a possible alternative. The addition to SA negotiation in the draft is OPTIONAL and will remain so; implementers are free to ignore it. The authors still think that the assurance it provides can be useful in a number of situations. In practice, if nobody implements this, it can be deleted later on. Extending ICMP to negotiate ECN after tunnel setup appears to be a cure that's worse than the disease. Some tunnels do not permit traffic to be addressed to the egress endpoint, hence the ICMP packet has to be addressed to somewhere else, scanned for by the egress endpoint, and discarded there or at its actual destination (not pretty). Beyond that lies a set of problems caused by the fact that ICMP is unreliable delivery, hence there is a possibility of the packet being dropped, entailing the invention of yet another ack/retransmit mechanism. It seems better to optionally extend the existing SA negotiation mechanism. Please send comments on this email and the underlying draft to the list. The default plan in the absence of further major comments is to incorporate the above discussion into a -01 version of the draft for further discussion in Oslo. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Sun Jun 20 19:26:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA07099; Sun, 20 Jun 1999 19:26:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03575 Sun, 20 Jun 1999 20:49:42 -0400 (EDT) To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@lists.tislabs.com In-reply-to: msa's message of Fri, 18 Jun 1999 18:27:02 +0300. <199906181527.SAA27995@anise.tte.vtt.fi> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC, IPv6 and mobile IP Date: Mon, 21 Jun 1999 09:48:58 +0900 Message-ID: <23667.929926138@coconut.itojun.org> From: Jun-ichiro itojun Hagino Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In IPv4 AH implementation was fairly easy and deterministic, but with >IPv6 AH appears to be a headache... I believe that "mobile-ipv6 and ipsec combination" is a headace. mobile-ipv6 document is very silent about: - send/receive processing order of mobile-ipv6 and ipsec - header ordering of ipsec/mobile-ipv6 extension headers - which address (home address or care of address) to use on ipsec key lookup - which part should be protected by ipsec also, ipsec documents has few mobile-ipv6 issues in it. There was some discussion on ipngwg mailing list recently, but there seem to be no consensus about it. There'll be mobile-ipv6 connectivity test workshop in September so we'll see... itojun From owner-ipsec@lists.tislabs.com Mon Jun 21 02:53:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19096; Mon, 21 Jun 1999 02:53:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04167 Mon, 21 Jun 1999 03:44:54 -0400 (EDT) Message-Id: <199906210744.LAA01740@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: "Scott G. Kelly" Date: Mon, 21 Jun 1999 11:43:32 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-ietf-ipsec-notifymsg-00.txt CC: ipsec@lists.tislabs.com X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, some comments below. First of all, most of described error messages are applicable not only to phase 1 or 2, but also to New Group mode and Transaction mode. The problem is that the latter two either don't have SPI (Transaction mode) or it is dummy (New Group). So, you need Message ID to include to Notify payload to unambiguously indentify exchange. Although you've included it into differentiators of most messages, you, in general, don't put them into transferred data. Note, that message ID from ISAKMP header is different and cannot be used if separate informational exchange is used. This problem was discussed (and one solution proposed) in Tero Kivinen's message to the list <199812031546.RAA06867@torni.ssh.fi> from 3 Dec 1998. Then, I agree with proposals to always interpret notification data as ISAKMP attributes list. This will give an extra flexibility in including additional information. > 2.1 INVALID-PAYLOAD-TYPE > > The INVALID-PAYLOAD-TYPE error message may be used to communicate > that an unrecognized or invalid payload type was received. > > Phase: 1 or 2 > > Differentiators: Cookies vs SPI, > subject payload in notify data I think message ID should also be added here. > 2.4 INVALID-COOKIE > > The INVALID-COOKIE error message may be used to communicate that an > invalid ISAKMP cookie was received. > > Phase: 1 or 2 > Differentiator: Cookies, message ID > invalid cookie in notify data > > When present, the Notification Payload MUST have the following > format: > > o Payload Length - set to length of payload + size of data (var) > o DOI - set to IPSEC DOI (1) Why so? Do you think INVALID-COOKIE error message is only valid for IPsec DOI? I don't think so - it is defined in ISAKMP document. > 2.9 INVALID-MESSAGE-ID > > The INVALID-MESSAGE-ID error message may be used to communicate that > the message ID in the received message is unrecognized or invalid. > > Phase: 1 or 2 > Differentiator: Cookies, message ID > > When present, the Notification Payload MUST have the following > format: > > o Payload Length - set to length of payload > o DOI - set to DOI under which message was received > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-MESSAGE-ID > o SPI - empty > o Notification Data - empty > > In this case, the invalid message ID is contained in the ISAKMP > header of the notify message. If separate informational exchange is used to transfer notify message, its message ID may have no connection to your invalid message ID. > 2.13 ATTRIBUTES-NOT-SUPPORTED > > The ATTRIBUTES-NOT-SUPPORTED error message may be used to communicate > that unrecognized or unsupported attributes were received as part of > a proposal. Currently, this message may result from one of the > following events: > > o unacceptable group in IKE new-group-mode negotiation o > conflicting lifetime attributes are detected o invalid or > unsupported SA attributes are received Some formatting problem in the document here. Regards, Valery. From owner-ipsec@lists.tislabs.com Mon Jun 21 06:24:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23080; Mon, 21 Jun 1999 06:24:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04763 Mon, 21 Jun 1999 07:19:23 -0400 (EDT) Message-Id: <199906211117.NAA11125@iabgdns.> Comments: Authenticated sender is From: "Florian Heissenhuber" Organization: IABG mbH To: ipsec@lists.tislabs.com Date: Mon, 21 Jun 1999 13:17:07 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ISAKMP over UDP, TCP of IP Reply-to: heissenhuber@iabg.de X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I've read RFC 2408 (ISAKMP) and I've some questions regarding section 2.5.1 of this RFC: >2.5.1 Transport Protocol > ISAKMP can be implemented over any transport protocol or over IP > itself. Implementations MUST include send and receive capability > for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP > Port 500 has been assigned to ISAKMP by the Internet Assigned > Numbers Authority (IANA). Implementations MAY additionally support > ISAKMP over other transport protocols or over IP itself. What's the reason to allow implementations to support additionally ISAKMP over other transport protocols or over IP itself? I think this may introduce only additional complexity without any benefits. Is there already a port number assigned for ISAKMP over TCP? Is there any assigned Protocol value (IPv4) of Next Header value (IPv6) for ISAKMP over IP? I'm thinking about an IPsec implementation, so I hope somebody can help me. Best regards, Florian __________________________________________________________________ Florian Heissenhuber Phone+49 89 60883539 IABG mbH Fax +49 89 60882845 Einsteinstr. 20 heissenhuber@iabg.de 85521 Ottobrunn http://www.iabg.de Germany From owner-ipsec@lists.tislabs.com Mon Jun 21 06:42:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23182; Mon, 21 Jun 1999 06:42:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04884 Mon, 21 Jun 1999 07:45:54 -0400 (EDT) Date: Mon, 21 Jun 1999 14:45:19 +0300 (EET DST) From: Markku Savela Message-Id: <199906211145.OAA29341@anise.tte.vtt.fi> To: itojun@itojun.org CC: ipsec@lists.tislabs.com In-reply-to: <23667.929926138@coconut.itojun.org> (message from Jun-ichiro itojun Hagino on Mon, 21 Jun 1999 09:48:58 +0900) Subject: Re: IPSEC, IPv6 and mobile IP Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I believe that "mobile-ipv6 and ipsec combination" is a headace. > mobile-ipv6 document is very silent about: As I'm in the process of planning an IPSEC integration with IPv6 stack and mobility, I need to get my thoughts cleared on the issue. CASE A: Receiving packet from mobile (Home Address option) ---------------------------------------------------------- What is the correct processing of a received packet that includes home address option and IPSEC. The packet arrives from a mobile host HA to non-mobile (to keep example simple) host B. Before destination option processing (Home Address) it looks (1) IP(CA->B),DOP(HA),.... and after processing it will look (2) IP(HA->B),DOP(HA),... The simple question is: which of the following alternatives are taken by other implementors? a) Process IPSEC at point (1), e.g. look for matchins SA based on triplet and check header against IP(CA->X), b) Process IPSEC at point (2), e.g. look for matching SA based on triplet and check header against IP(HA->X), c) Try both (a) and (b), and drop packet if neither passes Because I don't like "trial and error solutions", I would prefer either (a) or (b), and to preserve at least some of the IPv6 sequenctial processing of extension headers, one could perhaps give the preference to (b)? [disregarding at the moment the potential complexities in actually generating this packet in the source end...]. CASE B: Receiving packet on the mobile host (routing header) ------------------------------------------------------------ The next issue is when the mobile host HA receives a routed packet from B (B uses routing header to direct the packet to HA): Before processing the routing header (1) IP(B->CA),RTH(HA),.... and after processing the Routing header (RTH) (2) IP(B->HA),RTH(CA),.... Here the situation is simple, because (2) is the only possible choice [IPSEC specifies that routing header should be in the "final state"]. Thus, one should look for PROBLEM? -------- Both seem to lead into solution where associations are between home address(es). What is the arrangement of extension headers that would allow IPSEC associations between the care address(es) (a connection to the issues addressed by some posts from Richard Draves, concerning a mobile host moving into area where care address needs to use security gateways). Especially case B is "nasty". There is no way you can run IPSEC "legally" at stage (1), but even with case A it would require the "trial and error approach": to try both (1) and remove "layer of ipsec headers", if it succeeds. Binding Update issues --------------------- Mobile wants IPSEC to protect the binding updates. As these are destination options, it almost appears if I need to allow destionation options as selectors, so that the IPSEC policy could be properly specified for those too. [without making mobile IP an ugly special cast wart on the IPSEC]. > There was some discussion on ipngwg mailing list recently, but > there seem to be no consensus about it. There'll be mobile-ipv6 > connectivity test workshop in September so we'll see... Hmm.. I suppose the announcement has gone at time when I was not yet too keenly aware of my need of mobile IP integration. Where and when? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Mon Jun 21 08:51:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24963; Mon, 21 Jun 1999 08:51:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04992 Mon, 21 Jun 1999 08:34:15 -0400 (EDT) Date: Mon, 21 Jun 1999 15:33:44 +0300 (EET DST) From: Markku Savela Message-Id: <199906211233.PAA29944@anise.tte.vtt.fi> To: itojun@itojun.org CC: ipsec@lists.tislabs.com In-reply-to: <23667.929926138@coconut.itojun.org> (message from Jun-ichiro itojun Hagino on Mon, 21 Jun 1999 09:48:58 +0900) Subject: Re: IPSEC, IPv6 and mobile IP Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oops, while writing my previous mail I changed X to B, but some slipped... > a) Process IPSEC at point (1), e.g. look for matchins SA based on > triplet and check header against IP(CA->X), > > b) Process IPSEC at point (2), e.g. look for matching SA based on > triplet and check header against IP(HA->X), Should read IP(CA->B) and IP(HA->B), of course... -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Mon Jun 21 08:52:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24977; Mon, 21 Jun 1999 08:52:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04996 Mon, 21 Jun 1999 08:34:21 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68522@exchange> From: Tim Jenkins To: bkavsan Cc: ipsec@lists.tislabs.com Subject: RE: Dangling SA Summary Date: Mon, 21 Jun 1999 08:36:16 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFB68522@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEBBE2.AA1AB000" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEBBE2.AA1AB000 Content-Type: text/plain; charset="iso-8859-1" Yes, and no. If an implementation that itself does not allow dangling phase 2 SAs is connected with an implementation that does allows allow it, if the phase 1 on the latter expires first, and it sends a delete, the former would end up deleting all SAs so there would be a black out. However, if the former implementation allowed that it could be talking to an implementation that allowed dangling SAs, it would use only the delete that it received and not delete the phase 2 SAs. The bottom line is that since dangling phase 2 SAs is allowed, all implementation must be able to support it. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: bkavsan [mailto:bkavsan@ire-ma.com] > Sent: June 18, 1999 10:15 PM > To: Dan Harkins > Cc: Tim Jenkins; ipsec@lists.tislabs.com > Subject: Re: Dangling SA Summary > > > is there a problem in allowing co-existence of both dangling > and non-dangling > implementations? > > Dan Harkins wrote: > > > On Fri, 18 Jun 1999 14:04:19 EDT you wrote > > > > > > > This is large club used to kill a small ant. The window only > > > > happens when > > > > you 1) are using certs; and, 2) have a case where the > > > > certificate expires > > > > while IPSec SAs exist. The CRL example is not convincing > > > > because there is > > > > no way to notice the second a cert has been revoked unless > > > > you spend 100% > > > > of your time doing LDAP queries for active sessions. That's > > > > not realistic.. > > > > > > I know. That's what my assumptions were in the first place. > > > > > > > ... and as Brian Korver noted yesterday this window > approximates roundoff > > > > error for all the other windows. > > > > > > And as I replied to Brian the round off effect is only > small if the phase 2 > > > SA lifetime is small compared to the phase 1 SA lifetime. > Did you see my > > > summary page? > > > > No it's small due to the other things that are not easy to > quantify like > > how long does it take someone to realize their private key has been > > compromized? That's probably going to be big compared to > the time an SA > > can dangle. > > > > > Let's turn this around. What are your objections to *not* > allowing dangling > > > phase 2 SAs? > > > > Because not everyone feels that dangling SAs are a problem. > Because your > > concern about making this window as small as possible can > be taken care of > > in ways that only impact your implementation and not > everyone else's. Because > > I don't want to have to do unnecessary and expensive public > key operations > > which would arise if the IPSec SAs would not be rekeyed > when they expire but > > the IKE SA which established them has timed out. Because it > causes temporary > > blackouts. Because this problem happens very, very, very > infrequently and to > > burden everyone to do something when 99.99% (or more) of > the time the > > "problem" isn't even there and when it is alot of people > don't view it as a > > problem is alot to require. It's an unnecessary burden. > This protocol is > > already too complicated. > > > > Dan. > > > > ------_=_NextPart_000_01BEBBE2.AA1AB000 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhYMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGABUACAAkABAAAQAuAQEggAMADgAAAM8HBgAV AAgAJAAUAAEAMgEBCYABACEAAAAwQTA5NDZDMUQxMjdEMzExOEE2QTAwODBDNzk0NUU2QwABBwEE gAEAGAAAAFJFOiBEYW5nbGluZyBTQSBTdW1tYXJ5ANcHAQ2ABAACAAAAAgACAAEDkAYARA0AADEA AAALAAIAAQAAAAsAKwAAAAAAAwAuAAAAAABAADkA8Kqpp+K7vgEeAHAAAQAAABQAAABEYW5nbGlu ZyBTQSBTdW1tYXJ5AAIBcQABAAAAGwAAAAG+ufp15CFXBSwlmBHTk1EAEEtqqNgAec3/0AAeADFA AQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAAAB4AMEABAAAACQAAAFRKRU5LSU5TAAAAAAMAGUAA AAAAAgEJEAEAAABCCAAAPggAAIMPAABMWkZ1BND9iAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8K gAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J 97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6djATAkIFkHkCwgAHBkIDhuby4KogqECoBJZm0dcSAH cAtQZQeAAjBhZHRpAiAgdBPgBUBpynQUEGwewGRvB5EdwC8FQAdAF7AH4GQAcGdssQuAZyBwE+AU ECAUQZZBBCAEACAFoG5uBZD/DrAdoAPwIAAe3x/lIMMhU38lxSBBHWAGkB/xIoAiRDF+IB/TIoAL YAJAEoEOwHDWaRggBCBmKPBzJsEdgv0gUCAUEB2QJcEgsCCAFCBuZR1gJyICEHIHgAXAd40IYGwd oCoxIHVwKpTnIgIhUSKzc28nEhggK8VeYiKAKoACYADQayfQdcp0HetIIYBldgSQJtf/K2UkXSFT I6EgBSMhLmUBkPRsayICdC3AJC8f9DK23yG3IsEm0QVAK9R1InECIDxseScTKqQzJxggY2X+aTCQ HaAdhCVxOTYnRiKj/R3rVCcxBuACQANwKEALgO8igCMBIAMAkG46MCGvIrbvMrUdYS1BNS1tOFAF QC6i1wJgNCEtwHMscHAXwSBBOx3rHfQtRUA89QdwIEq/CfA0cQQgRo9G4wdiUw6wOyyACFByQ6Ef ox30dGrdRiRAH7AHgUhBLgWgPeAFRudoAkBwOi8vdw1L8C5KKh30KDYxM0ApIDU5OS0cIDFBFlB4 NDMwNEbtRtBheDogTVs3RC8eRaw+IEVBRUBPBRBnC4CHB0AF0AeQc2FnZVJTDVHWRgNhT7Bia2F2 u1NgA6BbAMADEDTAOlTV2kAo8S0AwEqiXVHWBmCTAjBPsEp1PiExOB1gCjFNwDknsDA6MTUoIFBN UdZUVbAgRJ0DkUgKwEZCUdZDY0+wlUXZOzUQcBQQY0A/cNcpcDxwH7BzC2BiPHBMxzlXYXViSaAj gE+wUmWXWeM3Fl4hbQDAcnlR1u9gPj5TLgIqgHADYEMBPeDvC4AhRD+CBaAtDsBcsQnw/T8Bbx7A PZEkAD83UdYdhJxuLT82YTc1O3M/YD5vWgkjwANgDrA6YD5SME9rA6BUcGlYUThX0lhlNA46TnBY 4FigRURUIO55CGBqNGsoPm5pa5E9UHcjASMBC2ByU4AjIApAYr84QjMRLcA0cC1BKoBzAMD7ccIC MC5v4S4hC4AgwAfg/ziSbxwT4EOQCfBqIScwSSX7b3Zt0jFNkArAIoA4UGNj3wSQIGBcIB2BHWAy TZAT4PswkCpxYyJidREuESchbxz/d0IGkA3gH6AigCjFbxx1ENMDECKASVAGYGMis2PT0XKkQ1JM KLFhNTIi8vshEiMxdj7hZtlvdC6geKC/OFIt5AQAbxwdwCPAYTjB/y3AIREN4Dt0XGECIDqBdzMf dIEEIC6gCfA6AXZva/8joVfwNVAEEHVfKhB0wR2g+U4QMCVvHGRxbdEFwEoiAyCxP4JMREFQIHH/ ClAIgSkhBbEA0B+weFEUEO8EEGgycqIfoCeBzznyB0DbXLEN4C4d5W7PSXGQHcDvTBCMNXUBICFt OMAiYENw/zUwaCMjwIFzJ/QpQyIwLwF+ZY5vb2eOUHKgHYKE8UJ7ByEDoEsFsDCRIQIjoXn/SlIL IILycAJzBWWHQ5ADYP9j4ADADrAEIANgV/AgwAEg/28cBJADYAXAivMtQSciZLHvK6JzEzx2k/9B lXSP4Bgg/wtQCJBxU5XUJyKZs2RhHsD/AREjcSLyOJNR1nIUJvsOUP9vKV+RP3ChIIlzIwFyFEqx vwqxcUQnKqR5cqBpB2mW4f+HQgngkRFvGpFxX/IiMFNxe2h3bwlOLcAgUJChchRk/wpQpkacNJeh P1A+ZXaiIRL9jdBzgwNR1opwcnEGkDjA9z9whbBrKGghgRewP5Egw/8p8QGQhbAtoQeAAiBDI43D /no7cyjwYlE6UHrihbA4wJ+E5msopcIDYbQhZD+QVndiYkLxOMBnidM0wS6hYv9SwKW7UdYnIolz A5EiwLYJbwORPzOTeW8aTBQgkKF03whwH+JAgpmzcqBXrqaJI69igF5ikcM0wSohESpleL9jJmaO a4IiSar/a5FCgOX/ryMwkW3QPiGhICCAPmU26v92k2JHp/jGFokitgo+8QSh/wGgL1FCYLLwNIOX uYTxchX9t8Fvi8FDArwyUdY0E4Ww/wOgeKAuEWRwayhi4YLhPmX/OJM1IYsxiRQxzjq1UdbG1/3H gWWMgHKgxhVrKI/gIMD8bic30XJxNLJ4MzTBIMD/heEjYVNCqoEdgijBdNGLYr5wXkA/cH0QUda1 Qm90wP9I1HuJfHET0CvFCsAEAD4x/ycEfNgr1CESLqEYILVBI6H/UdZ1EicSOMAoxC6QL2BrKPne c0tFX4LdJEpRQvEEAP8nMDMSYrGE4koioKEvYcYH/ynxUdaA8z5hH1BIsmAYgLH/LwIvUdYol5Ri ZnSWxuIdYOvraGEobgNQZYpxAjA4sf8dgjTA6EkIcAEAA6DG19i0r7MyriPhFE3ALk3AJU/AfwWx BGAYIE2QZHG6P3lbIv1iZSIi8deiMIEn82ISHZH/4SMp8UCDISFkcXTA2+BDEb9R1teEf4AH0Snx hPFhayi/Ymf2tbOzinAo8XKgSZCS/wOR2RruxKf4b/NiYTTAF5H3gasHQI3BZIMCLcClwtrh/3rh v4DE71IwRuBaAZ0HAr8FA8t9BSAAAB4AQhABAAAAHwAAADwzNzZBRkQyOS5BMTREQzY3Q0BpcmUt bWEuY29tPgAAAwDeP69vAAALAAOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMABYAIIAYA AAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAe AAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUAAwACgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAALAASACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMABoAIIAYAAAAA AMAAAAAAAABGAAAAABGFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAiA CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYA AAAAN4UAAAEAAAABAAAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA AAALAAuACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsADIALIAYAAAAAAMAAAAAAAABGAAAA AAWIAAAAAAAACwCZgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALAEGACCAGAAAAAADAAAAA AAAARgAAAAAGhQAAAAAAAAMA8T8JBAAAAwAmAAAAAAADADYAAAAAAAMA/T/kBAAAAwCAEP////8C AUcAAQAAADoAAABjPVVTO2E9IDtwPVRpbWVTdGVwIENvcnBvcmE7bD1FWENIQU5HRS05OTA2MjEx MjM2MTZaLTU3NjkAAAAeADhAAQAAAAkAAABUSkVOS0lOUwAAAAAeADlAAQAAAAkAAABUSkVOS0lO UwAAAABAAAcw8KWmp+K7vgFAAAgwALAaquK7vgEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAA FAAAAERhbmdsaW5nIFNBIFN1bW1hcnkAHgA1EAEAAAAyAAAAPDMxOUExQzVGOTRDOEQxMTE5MkRF MDA4MDVGQkJBRERGQjY4NTIyQGV4Y2hhbmdlPgAAAAsAKQAAAAAACwAjAAAAAAADAAYQ0beSHAMA BxAPCQAAAwAQEAAAAAADABEQBQAAAB4ACBABAAAAZQAAAFlFUyxBTkROT0lGQU5JTVBMRU1FTlRB VElPTlRIQVRJVFNFTEZET0VTTk9UQUxMT1dEQU5HTElOR1BIQVNFMlNBU0lTQ09OTkVDVEVEV0lU SEFOSU1QTEVNRU5UQVRJT05USEEAAAAAAgF/AAEAAAAyAAAAPDMxOUExQzVGOTRDOEQxMTE5MkRF MDA4MDVGQkJBRERGQjY4NTIyQGV4Y2hhbmdlPgAAAEbn ------_=_NextPart_000_01BEBBE2.AA1AB000-- From owner-ipsec@lists.tislabs.com Mon Jun 21 10:56:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26918; Mon, 21 Jun 1999 10:56:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05617 Mon, 21 Jun 1999 11:49:16 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68669@exchange> From: Tim Jenkins To: "Mason, David" , ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Mon, 21 Jun 1999 11:50:50 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFB68669@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEBBFD.D7864BD0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEBBFD.D7864BD0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Mason, David [mailto:David_Mason@nai.com] > Sent: June 18, 1999 5:30 PM > To: ipsec@lists.tislabs.com > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > When a customer asks what's the maximum time period after a > certificate is > revoked will the user of that certificate still have access, > the answer with > dangling phase 2 SAs would be: > > CRLexpirationInterval+Phase1Life+Phase2Life > > without dangling phase 2 SAs: > > CRLexpirationInterval+phase1Life Where does the CRLexpirationInterval term come from? The RFCs require that the phase 1 lifetime be reduced so that it can't live past your current CRL expiration anyway. Are you assuming that implementations are not using that? > > I believe that the relative difference between these two > periods is small > and generally the Phase2Life will be by far the smallest component. Again, if the system user configures his/her system to be that way, you're correct. However, there is nothing in the RFCs that make that a requirement. Finally, no one seems to repond to my comment that with dangling phase 2 SAs, clean deletion of the phase 2 SAs at both ends if the certificate becomes revoked may not be possible. Is this something else no one cares about? ------_=_NextPart_000_01BEBBFD.D7864BD0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjYPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGABUACwAyADIAAQBhAQEggAMADgAAAM8HBgAV AAsAMgA0AAEAYwEBCYABACEAAAAzMjA5NDZDMUQxMjdEMzExOEE2QTAwODBDNzk0NUU2QwD1BgEE gAEAOwAAAFJFOiBEYW5nbGluZyBwaGFzZSAyIFNBcyAod2FzIFJFOiBpc3N1ZXMgZnJvbSB0aGUg YmFrZW9mZikASxMBDYAEAAIAAAACAAIAAQOQBgCkCQAAMQAAAAsAAgABAAAACwArAAAAAAADAC4A AAAAAEAAOQDQGcvV/bu+AR4AcAABAAAANwAAAERhbmdsaW5nIHBoYXNlIDIgU0FzICh3YXMgUkU6 IGlzc3VlcyBmcm9tIHRoZSBiYWtlb2ZmKQAAAgFxAAEAAAAbAAAAAb650sW7IVb/HyWYEdOTUQAQ S2qo2ACKfUMAAB4AMUABAAAACQAAAFRKRU5LSU5TAAAAAAMAGkAAAAAAHgAwQAEAAAAJAAAAVEpF TktJTlMAAAAAAwAZQAAAAAACAQkQAQAAADkEAAA1BAAAtAYAAExaRnXP8aX2AwAKAHJjcGcxMjXi MgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl 9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFCzCwkBZDM2FlALp2MBMKMK4wqAPiAtHbJPBRAe ZwuAB0AF0AeQc2FnVmUdsx02RgNhOgXQYQJzAiAsIERhdmkYZCBbAMADEHRvOpUgo18gM0AeUGku BaA8bV0dNgZgAjAgEEp1IG5lIDE4IIAxOSEkQCA1OjMWUFBNNR02VCFgIAUgFBBjQMJsBAB0cy50 BAALYI5iJlAigSLHdWJqBZCZI3FSRSAQIKBuZyYQWSiQIHAT4BQQIBRBQfkEICh3IEAoIwQBClAE IBEDUiB0aCPQYmFrtGVvASApHTYr3lcrIOEDoGEgY3UmMANwEoGVIEBrBCB3E+B0JwQg6ysSAMB4 B3B1KvEHcSjwvwZxBHAtkAGALiIdJ2MEkP0mcGYN4C7AI9AEAB02GCDcdm8rcCDgA/BsAyArEv8t 0BKBK5ArAS7AMYsmMDOC/RPgdiPQANAxkAQQIIAdNnsrEgBxdxKBA/ArEB02ZCsojymRdwhgbCDg YmUiOiveQ1JMDsBwaWZyLsAwUG5JAjAEkHZJB0ArUCkSMUwGkGX9POQyPVIr3jfyCGAFQDi//ymB Oo87nzyjKQM9Qx00HTT3LVEYID+wbweRKxJCHzyivysABJAq8CKBI9ADUj8lYDErIVJGQwQgGCBx dZ878CPQNIMrEikEMSAmEO89cC/TOmAy4WQa0DNBIFDvNHQ4AC2wAHAnBUAmEDYRswqwJjAgeQhh LbFyGCBbAjBFsiBF+DdxeSnQeb4uEMEj0E0xLkEqcG0owvVLtG0LUGUHgAIwPBMEIHMKwCPQbm8F QC3QUEY/+0QaLDhJOlEmEDMASRkYIPcLYCZwNhFkBpA9cE2xMZD9OlF0N7AtcSsRKTFW8EuQ/x02 MCQEIAQANYAAwDOQHTa/AHAg4B7gI8A8ADOQeSsD1z2oM2RK0WJasGYKwSsSb1kjB5A0sQNwcAIg I1EueUQaQWcLcSCABpBcpHmvJjBREDP0BaBuMeBnCHD1B5FoBAAvROFftiFQSsLvNINPISCATTEn RQEFoRggsyfwT1BIbzewNhByIID/KxFFAVjxUhFhMCjRC4ArA/9IYzSDAMArcDR0LaBItVEi+14b HTRGHkJaoCCAUhA0QP8jwRQQURAu8UuQGCBdsSDg/WIhbVqwIoFRImJ1OAE/v/spciCAY1EAA5EB AFEATqP/NFNJpilkNKEG4GzBCfBYwv9fZDGaOmBHckiSMxQAwFqwr1ISStFdsAQQaQJgZU9Q/kku 8ljyLgFlZFSQKTFqBV8yAGDyAaA/gVL7fXgwAAAAHgBCEAEAAAA+AAAAPDQ0N0EzRjQwQTA3RkQy MTFCQTI3MDBBMEM5OUQ3NTlCMDVEMEJFQG1kLWV4Y2hhbmdlMS5uYWkuY29tPgAAAAMA3j+vbwAA CwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgABgAggBgAAAAAAwAAAAAAA AEYAAAAAVIUAAAEAAAAEAAAAOC41AAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAE gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAARhQAA AAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYA AAAANoUAAAEAAAABAAAAAAAAAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAA AAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwALgAsgBgAAAAAAwAAA AAAAAEYAAAAAAIgAAAAAAAALAAyACyAGAAAAAADAAAAAAAAARgAAAAAFiAAAAAAAAAsAmYAIIAYA AAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwBBgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAAD APE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD/////AgFHAAEAAAA6AAAAYz1VUzth PSA7cD1UaW1lU3RlcCBDb3Jwb3JhO2w9RVhDSEFOR0UtOTkwNjIxMTU1MDUwWi02MTkxAAAAHgA4 QAEAAAAJAAAAVEpFTktJTlMAAAAAHgA5QAEAAAAJAAAAVEpFTktJTlMAAAAAQAAHMHAny9X9u74B QAAIMNBLhtf9u74BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAADcAAABEYW5nbGluZyBwaGFz ZSAyIFNBcyAod2FzIFJFOiBpc3N1ZXMgZnJvbSB0aGUgYmFrZW9mZikAAB4ANRABAAAAMgAAADwz MTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkI2ODY2OUBleGNoYW5nZT4AAAALACkAAAAA AAsAIwAAAAAAAwAGEO1bx4gDAAcQBAQAAAMAEBABAAAAAwAREAAAAAAeAAgQAQAAAGUAAAAtLS0t LU9SSUdJTkFMTUVTU0FHRS0tLS0tRlJPTTpNQVNPTixEQVZJRE1BSUxUTzpEQVZJRE1BU09OQE5B SUNPTVNFTlQ6SlVORTE4LDE5OTk1OjMwUE1UTzpJUFNFQ0BMSVNUAAAAAAIBfwABAAAAMgAAADwz MTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkI2ODY2OUBleGNoYW5nZT4AAAC5Nw== ------_=_NextPart_000_01BEBBFD.D7864BD0-- From owner-ipsec@lists.tislabs.com Mon Jun 21 10:58:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26941; Mon, 21 Jun 1999 10:58:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05646 Mon, 21 Jun 1999 12:04:24 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68686@exchange> From: Tim Jenkins To: "Mason, David" , ipsec@lists.tislabs.com Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) Date: Mon, 21 Jun 1999 12:06:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: June 21, 1999 11:51 AM > To: Mason, David; ipsec@lists.tislabs.com > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > > > -----Original Message----- > > From: Mason, David [mailto:David_Mason@nai.com] > > Sent: June 18, 1999 5:30 PM > > To: ipsec@lists.tislabs.com > > Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) > > > > > > When a customer asks what's the maximum time period after a > > certificate is > > revoked will the user of that certificate still have access, > > the answer with > > dangling phase 2 SAs would be: > > > > CRLexpirationInterval+Phase1Life+Phase2Life > > > > without dangling phase 2 SAs: > > > > CRLexpirationInterval+phase1Life > > Where does the CRLexpirationInterval term come from? The RFCs > require that the phase 1 lifetime be reduced so that it can't > live past your current CRL expiration anyway. Are you > assuming that implementations are not using that? > Never mind; I see it. But it's actually CRLexpirationInterval + Phase2Life since the phase 1 life isn't supposed to go beyond the CRL expiration; it then has no effect on the result. The no dangling SA case would result in CRLexpirationInterval only. From owner-ipsec@lists.tislabs.com Mon Jun 21 11:47:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27434; Mon, 21 Jun 1999 11:47:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05777 Mon, 21 Jun 1999 12:59:34 -0400 (EDT) Message-Id: <9906211659.AA21342@giove.polito.it> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jun 99 18:59:08 BST From: Madalina Baltatu Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello to all! Does anybody experience problems with the OpenBSD 2.5 IPsec implementation? I can create SAs (with ipsecadm), but I cannot use the ipsecadm flow command for setting-up SA flows. The error is pfkey: not such process. I've seen (with sysctl) that the net.inet.esp.enable and net.inet.ah.enable were 0, so I was thinking that the kernel was compiled without IPsec... Anybody has any idea? Thanks... Madalina. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Madalina Baltatu engineer, Ph.D. Student Politecnico di Torino phone: +39-11-5647090 Dip. Automatica e Informatica fax: +39-11-5647099 corso Duca degli Abruzzi 24 e-mail: baltatu@athena.polito.it 10129 Torino (TO), Italy From owner-ipsec@lists.tislabs.com Mon Jun 21 12:11:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27662; Mon, 21 Jun 1999 12:11:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05862 Mon, 21 Jun 1999 13:23:54 -0400 (EDT) Message-ID: <376E753A.3F9FC093@redcreek.com> Date: Mon, 21 Jun 1999 10:24:10 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> <376CDC88.2768B517@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tamir, Tamir Zegman wrote: > I have one remark on the Notify message drafts. > I believe that there should be room left in the notify payload for a textual message > describing the problem. > Such an error string along side the pre-defined notify types has the advantages of > refining the meaning of the notify message type and it could be used for auditing or for > displaying a message whenever a user is involved. > > So, my proposal is that the notify data field should be structured like a list of data > attributes pairs (attribute type + attribute value), > one pair would contain the data that you have proposed in your draft, and another > (optional) pair would contain a string. > Actually, I believe that a similar proposal was raised at the NC bakeoff a while back. > I agree that some accompanying text would be useful, but I wonder if the field in which the text resides should be fixed, rather than freeform. My initial feeling is that use of A/V pairs raises some concern for buffer overflow attack. Does anyone else have thoughts on this? Scott From owner-ipsec@lists.tislabs.com Mon Jun 21 12:13:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27716; Mon, 21 Jun 1999 12:13:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05858 Mon, 21 Jun 1999 13:23:52 -0400 (EDT) Date: Mon, 21 Jun 1999 20:23:19 +0300 (EET DST) Message-Id: <199906211723.UAA16126@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Koning Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff In-Reply-To: <199906181528.LAA25351@tonga.xedia.com> References: <199906151954.MAA21779@potassium.network-alchemy.com> <199906181528.LAA25351@tonga.xedia.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > >>>>> "Dan" == Dan Harkins writes: > Dan> - Is it OK to send 3 copies of every single message (which one > Dan> implementation was doing)? Yes. > Similarly, the IKE spec doesn't specifically prohibit sending 3 copies > of the message because, I submit, no one thought that anyone would be > silly enough to do this, so it wasn't necessary to make a specific > rule "don't do this silly thing". But I would certainly call this > implementation broken. It might also be that the other end used 100 ms retranmission timers, that was doubled every time, so the first retry was sent 100 ms after first packet, second retry 200 ms after the second packet, and third one 400 ms after the second packet etc. If it took about a second from the other end to process the packet what he sees is that he is receiving three copies of every packet. Anyways sending each packet 3 times should matter, because every implementation MUST be able to interoperate with such system. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 21 13:19:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28287; Mon, 21 Jun 1999 13:19:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06018 Mon, 21 Jun 1999 14:26:23 -0400 (EDT) Message-ID: <014201bebc14$d1895a00$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Markku Savela" Cc: , References: <199906211145.OAA29341@anise.tte.vtt.fi> Subject: Re: IPSEC, IPv6 and mobile IP Date: Mon, 21 Jun 1999 14:35:16 -0400 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > CASE A: Receiving packet from mobile (Home Address option) > ---------------------------------------------------------- > What is the correct processing of a received packet that includes home > address option and IPSEC. The packet arrives from a mobile host HA to > non-mobile (to keep example simple) host B. > > Before destination option processing (Home Address) it looks > > (1) IP(CA->B),DOP(HA),.... > > and after processing it will look > > (2) IP(HA->B),DOP(HA),... > > The simple question is: which of the following alternatives are taken > by other implementors? > > a) Process IPSEC at point (1), e.g. look for matchins SA based on > triplet and check header against IP(CA->X), > > b) Process IPSEC at point (2), e.g. look for matching SA based on > triplet and check header against IP(HA->X), > > c) Try both (a) and (b), and drop packet if neither passes > > Because I don't like "trial and error solutions", I would prefer > either (a) or (b), and to preserve at least some of the IPv6 > sequenctial processing of extension headers, one could perhaps give > the preference to (b)? [disregarding at the moment the potential > complexities in actually generating this packet in the source end...]. > The MSRIPv6 stack does (b). > > CASE B: Receiving packet on the mobile host (routing header) > ------------------------------------------------------------ > The next issue is when the mobile host HA receives a routed packet > from B (B uses routing header to direct the packet to HA): > > Before processing the routing header > > (1) IP(B->CA),RTH(HA),.... > > and after processing the Routing header (RTH) > > (2) IP(B->HA),RTH(CA),.... > > Here the situation is simple, because (2) is the only possible choice > [IPSEC specifies that routing header should be in the "final > state"]. Thus, one should look for > Number 2 in this case for the reason you state. > > PROBLEM? > -------- > Both seem to lead into solution where associations are between home > address(es). > I feel the association should be between the home address since mobility is suppose to be transparent. However when a mobile node visits another network and gets a care-of address, additional IPSec may be required. Note I say additional and not alternative. The IPSec with the home address is still done. The mobile network may have a security gateway protecting the network. I don't think you'd see IPSec done to the actual care-of address because that means the mobile node needs to reconfigure the security policies when it goes mobile. I look at it this way from the correspondent node's view point: Sending: 1. Do IPSec for traffic destined to the home address 2. Discover the care-of address 3. Do IPSec for traffic destined to the care-of address (most likely a security gateway) Receiving: 1. Do IPSec for traffic from the care-of address (security gateway) 2. Discover home address 3. Do IPSec for traffic from the home address 4. Validate IPSec Two problems exist in this example: 1. What happens if there was an SA bundle for the home network 2. Validating the IPSec on the correspondent node to account for the care-of address Both are discussed in "(IPng 7578) mobile-ipv6 and ipsec" 6/2/99, on ipngwg list. > What is the arrangement of extension headers that would allow IPSEC > associations between the care address(es) (a connection to the issues > addressed by some posts from Richard Draves, concerning a mobile host > moving into area where care address needs to use security gateways). > > Especially case B is "nasty". There is no way you can run IPSEC > "legally" at stage (1), but even with case A it would require the > "trial and error approach": to try both (1) and remove "layer of ipsec > headers", if it succeeds. > If there is additional IPSec to the actual care-of address, the problem is the security policies. IPSec can be done but should be tunnel mode to the care-of address. The headers must be processed sequentially so tunnel mode is required to do IPSec before the routing header. An earlier discussion on ipngwg list "(IPng 7193) RE: Last Call: Mobility Support in IPv6 to Proposed Standard" 2/18/99, looked at why tunnel mode is needed for routing headers. Again, I think you would see the IPSec for the care-of address to a security gateway and not the actual node. But if it is to the actual node, then the validation needs to know about the care-of address like my correspondent node example. Basically when mobility is involved, two IPSec lookups are done on the send side (first for the home address second for the care-of address) and the IPSec validation on the receive side needs to account for the care-of address. > Binding Update issues > --------------------- > Mobile wants IPSEC to protect the binding updates. As these are > destination options, it almost appears if I need to allow destionation > options as selectors, so that the IPSEC policy could be properly > specified for those too. [without making mobile IP an ugly special > cast wart on the IPSEC]. > I would just do AH or ESP for all traffic from the mobile node to the correspondent node. Yes if you just wanted the binding updates to undergo IPSec, you would need some selector to indicate this. > > There was some discussion on ipngwg mailing list recently, but > > there seem to be no consensus about it. There'll be mobile-ipv6 > > connectivity test workshop in September so we'll see... > > Hmm.. I suppose the announcement has gone at time when I was not yet > too keenly aware of my need of mobile IP integration. Where and when? > About three weeks ago: "mobile-ipv6 and ipsec" thread starting on 6/2/99 on ipngwg list. I hope this helps. Aaron From owner-ipsec@lists.tislabs.com Mon Jun 21 14:10:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA28604; Mon, 21 Jun 1999 14:10:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06012 Mon, 21 Jun 1999 14:25:41 -0400 (EDT) Date: Mon, 21 Jun 1999 14:25:14 -0400 Message-Id: <199906211825.OAA03173@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kivinen@ssh.fi Cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff References: <199906151954.MAA21779@potassium.network-alchemy.com> <199906181528.LAA25351@tonga.xedia.com> <199906211723.UAA16126@torni.ssh.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Paul Koning writes: >> >>>>> "Dan" == Dan Harkins writes: Dan> - Is it OK to send 3 copies of every single message (which one Dan> implementation was doing)? Yes. >> Similarly, the IKE spec doesn't specifically prohibit sending 3 >> copies of the message because, I submit, no one thought that >> anyone would be silly enough to do this, so it wasn't necessary to >> make a specific rule "don't do this silly thing". But I would >> certainly call this implementation broken. Tero> It might also be that the other end used 100 ms retranmission Tero> timers, that was doubled every time, so the first retry was Tero> sent 100 ms after first packet, second retry 200 ms after the Tero> second packet, and third one 400 ms after the second packet Tero> etc. Tero> If it took about a second from the other end to process the Tero> packet what he sees is that he is receiving three copies of Tero> every packet. Possible. But while some packets take some time (D-H and the like) others don't. So if you're seeing three copies of ALL packets, this explanation doesn't fit well. Tero> Anyways sending each packet 3 times should matter, because Tero> every implementation MUST be able to interoperate with such Tero> system. Of course, and I never said otherwise. But that doesn't mean that a system that always sends three copies of a packet should be considered sane or normal, any more than a TCP stack that did this would be. paul From owner-ipsec@lists.tislabs.com Mon Jun 21 19:03:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02976; Mon, 21 Jun 1999 19:02:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06693 Mon, 21 Jun 1999 20:15:55 -0400 (EDT) Message-ID: <376ED5CE.A531028C@redcreek.com> Date: Mon, 21 Jun 1999 17:16:14 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: ipsec@lists.tislabs.com, Tamir Zegman Subject: Re: draft-ietf-ipsec-notifymsg-00.txt References: <199906210744.LAA01740@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Valery, Valery Smyslov wrote: > > Scott, some comments below. > > First of all, most of described error messages are applicable not > only to phase 1 or 2, but also to New Group mode and Transaction > mode. The problem is that the latter two either don't have SPI > (Transaction mode) or it is dummy (New Group). So, you need Message > ID to include to Notify payload to unambiguously indentify exchange. > Although you've included it into differentiators of most messages, > you, in general, don't put them into transferred data. Note, that > message ID from ISAKMP header is different and cannot be used if > separate informational exchange is used. > > This problem was discussed (and one solution proposed) in Tero > Kivinen's message to the list <199812031546.RAA06867@torni.ssh.fi> > from 3 Dec 1998. Yes, I see that there are some issues here, and thanks for the message pointer. I went back and reviewed this thread, and also saw what Tamir meant by "attributes pair" in his earlier email, which I mistakenly took to mean something else when I read his email earlier today (e.g. TM="here's an example error message"). I think Kivinen's suggestion in that thread makes sense, i.e. use the SPI field for the message ID, and also think Tamir's subsquent suggestion to use attribute lists makes sense, at least in some cases. I need to give this more thought, but wanted to reply to your suggestions. More later. Scott From owner-ipsec@lists.tislabs.com Mon Jun 21 23:02:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA20797; Mon, 21 Jun 1999 23:02:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07003 Tue, 22 Jun 1999 00:11:14 -0400 (EDT) X-Authentication-Warning: brahma.roc.com: anupama owned process doing -bs Date: Tue, 22 Jun 1999 09:43:08 +0530 (IST) From: Anupama Potluri X-Sender: anupama@brahma.roc.com To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt In-Reply-To: <376ED5CE.A531028C@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, I tried mailing this y'day but somehow there was an error. I think you will find a few repeats of what Valery had talked about. I am not editing my mail, though I can delete a few points from my mail.... Hi Scott, I have the following questions regarding the draft. 2.9 INVALID-MESSAGE-ID In this case, the invalid message ID is contained in the ISAKMP header of the notify message. But, the message ID of an informational exchange is supposed to be a unique value (not the same as the message ID which triggered this message). How can the invalid message ID be part of the ISAKMP header of the notify message? In fact, I would like it if they are the same but the ISAKMP RFC clearly states that except for the CONNECTED message, for all other notifies, it is a new message ID. NO-PROPOSAL-CHOSEN : there is no information to find out which QM exchange under an ISAKMP SA, this notify belongs to. Why isnt the protocol ID here the protocol ID from the selected SA? How do we handle this? And, one more question on this - isnt it inconsistent to make the SPI size 0 and the SPI to be the two ISAKMP cookies? INVALID-CERT-ENCODING, INVALID-CERTIFICATE, CERT-TYPE-UNSUPPORTED, INVALID-CERT-AUTHORITY, INVALID-SIGNATURE, CERTIFICATE-UNAVAILABLE : are not valid in quick mode (as far as I know) since signature and RSA encryption authentication modes are for phase 1 and not for QM. If it is any other mode other than QM in phase 2, it is fine but in that case the SPI will not be the 4 byte IPSEC SPI, will it?! UNSUPPORTED-EXCHANGE-TYPE : Wont the protocol always be ISAKMP for this and the SPI none even if we get an invalid exchange type after the ISAKMP SA is mature? Esp. as we dont know that there will be a SA payload in that exchange? (The draft says the protocol is the Protocol ID from the chosen SA.) I have a question regarding the phase 2 notify messages. The following has been stated for all phase 2 notify messages. o SPI - set to empty or to the sender's inbound IPSEC SPI But, the ISAKMP RFC states the following : o SPI (variable length) - Security Parameter Index. The receiving entity's SPI. We did have this problem in the bakeoff and it seemed to me that people agreed that it has to be the receiving entity's SPI. And, the latter choice seems more appropriate if we consider the following scenario : Initiator (I) sends the first message of QM to the responder (R). R finds that the transform ID of a transform is invalid. It may not even have generated a SPI as yet since it cannot parse I's request itself. Also, even if it generates the SPI and sends it out, 'I' does not have any way of identifying the QM from this information - the SPI and protocol are both required to uniquely identify a QM state in ISAKMP (from the requirement that the Dest addr, SPI and protocol form a unique triple). 'I' would have stored its SPI and protocol and the rest of info in its QM state and so will not find the QM based on the sender's inbound SPI. In fact, I think that it will be easier to identify the QM by making the first four bytes of the notification data the message ID of the QM this message corresponds to for all QM notify messages. Still, I think that the SPI should be the receiver's inbound SPI so that the appropriate proposal is identified (unless as in some cases, the entire proposal payload is included as the notification data). regards, Anupama From owner-ipsec@lists.tislabs.com Tue Jun 22 00:30:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22486; Tue, 22 Jun 1999 00:30:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07250 Tue, 22 Jun 1999 01:47:58 -0400 (EDT) X-Authentication-Warning: brahma.roc.com: anupama owned process doing -bs Date: Tue, 22 Jun 1999 11:19:39 +0530 (IST) From: Anupama Potluri X-Sender: anupama@brahma.roc.com To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff In-Reply-To: <199906151954.MAA21779@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, While reading the ISAKMP RFC once again, I discovered that it is not transform numbers alone but even the proposal numbers that can be changed from what the initiator has sent. Is this being done by any implementation? Do we need to support the change in the proposal number? Combining this with the fact that some implementations change the order of proposal payloads in the returned proposal, the checking of the proposal against what the initiator sent can be extremely complex! Cant we mandate that the proposal number MUST be the same as what the initiator sent atleast? thanks, Anupama From owner-ipsec@lists.tislabs.com Tue Jun 22 04:29:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00177; Tue, 22 Jun 1999 04:29:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07914 Tue, 22 Jun 1999 05:31:13 -0400 (EDT) Date: Tue, 22 Jun 1999 17:27:25 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: ipsec@lists.tislabs.com cc: Jianying Zhou Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-Reply-To: <199906142336.QAA20130@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was a security flaw in RFC 2409. When SAi_b is used in HASH_I and HASH_R, an attack is possible so that at the end of Phase 1 negotiation, the SA being negotiated may not be authenticated. (The problem also exists in the new draft.) To avoid the attack, simply replace SAi_b with SAr_b. (The full paper is available by request.) Jianying --------------------------------------------------------------------- Dr. Jianying Zhou | Tel: +65-8742585 Kent Ridge Digital Labs | Fax: +65-7744990 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg Singapore 119613 | WWW: http://homex.s1.net.sg/user/jyzhou/ --------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Jun 22 07:51:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04761; Tue, 22 Jun 1999 07:51:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08349 Tue, 22 Jun 1999 08:40:37 -0400 (EDT) Message-Id: <199906212348.BAA20544@waldorf.appli.se> To: Madalina Baltatu cc: ipsec@lists.tislabs.com In-reply-to: Your message of "Mon, 21 Jun 1999 18:59:08 -0000." <9906211659.AA21342@giove.polito.it> Date: Tue, 22 Jun 1999 01:48:26 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Mon, 21 Jun 99 18:59:08 BST > From: Madalina Baltatu Well this is probably not the right forum at all, next time I suggest misc@openbsd.org or if noone answers there, maybe tech@openbsd.org. I will try to answer anyhow. > Does anybody experience problems with the OpenBSD 2.5 IPsec > implementation? I can create SAs (with ipsecadm), but I cannot use > the ipsecadm flow command for setting-up SA flows. The error is > pfkey: not such process. This is also known as ESRCH and will occur when there is no SA matching the SA ID you give to the ipsecadm flow command. The important values are -proto, -spi and -dst. -spi and -dst obviously must match what you have given to the ipsecadm command that added the SA. -proto should match the ipsecadm subcommand, so if you use: ipsecadm new esp -spi 01234567 -dst 10.0.0.1 ... the flow command has to look something like: ipsecadm flow -proto esp -spi 01234567 -dst 10.0.0.1 ... Now ESRCH can of course occur if you do -delete too, when a former flow does not exist, but it does not sound from your mail that you are doing this. A third possibility is that you already have encap routes setup for these flows somehow... You might try to do: route -n flush -encap before you start using ipsecadm just to make sure all encap routes are gone. > I've seen (with sysctl) that the net.inet.esp.enable and > net.inet.ah.enable were 0, so I was thinking that the kernel was > compiled without IPsec... That was a documentation bug. You enable those in /etc/sysctl.conf, these sysctls was introduced tight before 2.5 was released for paranoia reasons. If you were not actively enabling IPsec you should not have the code path activated so that D.o.S attacks or "death packet"-like exploits could have a chance to succeed. Not that we know of any such case, but our most influential developer, known for his paranoia (which is also why OpenBSD has had such a success), decided he wanted to "harden" the out-of-the-box configuration sligthly more, so I went ahead and implemented it. Anyway, if you need to followup to this article, don't do it to this forum, I think it is out of the charter to discuss certain implemantation's user interface here. Feel free to contact me privately if you want to. Niklas From owner-ipsec@lists.tislabs.com Tue Jun 22 07:51:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04780; Tue, 22 Jun 1999 07:51:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08481 Tue, 22 Jun 1999 08:52:12 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB6892F@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: RE: Dangling SA Summary (final comments???) Date: Tue, 22 Jun 1999 08:54:04 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFB6892F@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEBCAE.4F098C20" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEBCAE.4F098C20 Content-Type: text/plain; charset="iso-8859-1" To all: I'm going preface this response with the comment that I realize that I've lost this battle to not allow dangling SAs. However, I want to make sure that as we move forward from this we understand where we came from. Also, obviously, I'm going to have to update the re-keying document to reflect the fact that systems are free to have dangling phase 2 SAs. However, I must insist that implementations are also free to have multiple phase 1 SAs with peers so that they can choose not to have dangling phase 2 SAs. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 18, 1999 8:39 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Dangling SA Summary > > > On Fri, 18 Jun 1999 14:04:19 EDT you wrote > > ... > > Let's turn this around. What are your objections to *not* > allowing dangling > > phase 2 SAs? > > Because not everyone feels that dangling SAs are a problem. > Because your > concern about making this window as small as possible can be > taken care of > in ways that only impact your implementation and not everyone > else's. Okay, point taken. > else's. Because > I don't want to have to do unnecessary and expensive public > key operations > which would arise if the IPSec SAs would not be rekeyed when > they expire but > the IKE SA which established them has timed out. ... So you aren't going to send a delete? Either in the existing optional unreliable notification or the new required (?) acknowledged notification? It seems to me that you will be trying to negotiate a new phase 1 anyway, no matter what happens. Say you get a dangling phase 2 SA. The things can happen to it are: 1) It needs to be re-keyed. 2) It needs to be deleted due to expiration. 3) It needs to be deleted due to inactivity (if implemented; this is an implementation option). 4) It needs to be deleted because the local administrator said so. 5) It needs to be deleted due to authentication failure (system somehow knows that peer can no longer have access). In case 1, you have to re-key the phase 1. In cases 2, 3, 4 and 5 you SHOULD (I would like to see MUST) send deletes. So in every case, the phase 1 SA has use. Only in case 5 (and maybe case 4), you can't re-key the phase 1, so you can't send the deletes. The only time you waste public key operations is if you create a phase 1 SA that doesn't get used. This implies that (a) the phase 2 lifetime is longer than the phase 1 lifetime, AND (b) there is no inactivity expiration applied to the SAs. I keep being told that (a) is not likely, or otherwise the revocation detection time difference between dangling SAs and no dangling SAs would not be like a round-up error. So then the only waste is perhaps over a year you've created more phase 1 SAs than you needed. > the IKE SA which established them has timed out. Because it > causes temporary > blackouts... Yes, agreed. > blackouts. Because this problem happens very, very, very > infrequently and to > burden everyone to do something when 99.99% (or more) of the time the > "problem" isn't even there and when it is alot of people > don't view it as a > problem is alot to require. Point taken here as well. > ... It's an unnecessary burden. A burden? Unnecessary? Okay. Almost anything can be made to work, even badly. Whether we like it or not, the phase 1 SAs are the "control channel" for the phase 2 SAs. They create them and destroy them. By not having them around when they are needed, for whatever reason, we make the system operate less smoothly. Here's another example of a need for them. A and B have a phase 1 and a phase 2 SA up. A's phase 1 SA expires, so A sends a delete notification that gets dropped (or doesn't send it at all). Then B's phase 2 expires or is terminated due to inactivity. B thinks there still a valid phase 1 SA, so sends a delete using it. A gets it and discards it with an invalid cookie error. Yes, we can recover from this, and yes, eventually maybe we'll be using the acknowledged deletes, so that B knows the SA is gone. Further, I would argue that it's not a large implementation burden. Since the possibility exists that either end will have to re-key a phase 1 that was previously deleted, the work required is similar whether an existing phase 1 is in place or not. We still need to support multiple phase 1 SAs between peers anyway. > ... This > protocol is > already too complicated. One thing that makes it complicated is the lack of written rules for the usage of SAs. There is a problem with a protocol when independent implementations can not break any rules, work with themselves yet not work with other implementations. This happened with phase 2 re-keying; we need to make sure this doesn't happen with phase 1 re-keying. I would also state that some of the complexity comes from having to handle all the myriad possibilities of SA handling. So making restrictions may actually reduce complexity, and not increase it. > > Dan. > > In any case, as I said above, I realize that dangling SAs must be supported. Choose your method... Tim ------_=_NextPart_000_01BEBCAE.4F098C20 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgYMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcGABYACAA2AAQAAgA2AQEggAMADgAAAM8HBgAW AAgANgAEAAIANgEBCYABACEAAAAxMTY5NkVFRTlBMjhEMzExOEE2QjAwODBDNzk0NUU2QwAmBwEE gAEALAAAAFJFOiBEYW5nbGluZyBTQSBTdW1tYXJ5IChmaW5hbCBjb21tZW50cz8/PykAlQ4BDYAE AAIAAAACAAIAAQOQBgBIEQAAMQAAAAsAAgABAAAACwArAAAAAAADAC4AAAAAAEAAOQAgMf1Orry+ AR4AcAABAAAAFQAAAERhbmdsaW5nIFNBIFN1bW1hcnkgAAAAAAIBcQABAAAAGwAAAAG+uex+2CFX A0wlmBHTk1EAEEtqqNgArvPWoAAeADFAAQAAAAkAAABUSkVOS0lOUwAAAAADABpAAAAAAB4AMEAB AAAACQAAAFRKRU5LSU5TAAAAAAMAGUAAAAAAAgEJEAEAAAAYDAAAFAwAACUXAABMWkZ1MB9kIQMA CgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrA c2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6djATCQIFRv IAdAbDoKogMKhAqASSdtIGdvUQuAZyBwGCBmANBlKCB0aAQAIBggc3D7AiAUECAD8B+AH3EfYAWg rm0HgAIwH3FhBUBJH8GZB0Bpeh9iIZIndh9gLRewcyFSH6FiIZB0bLMfYR1Abm8FQB1hbwfgGmQA cGciEB7RU0FzKi4dqkgksGUi0HIsvSGxdwBwIVEdQADAax9gdnMIcCJFYQQgJpAnkG/7ItECEHIn IAsgKTADYR90eSjBdW4EgSMgAHApoHfnIMAoESjBY2EHgCmzJasQQWxzbybgb2J24mkIYHNseSbh HnckEecT4CLRJBF1cCTgDrAgoxUYIC0nwHkewmRvY951ISQdQB8RI+BjIVIpIZMA0CFVc3kjIGVt BCDfCsAsAgngLtck53AT4CAx6xRBJYEgJnltLeAFQAuA/wCQIyMhkQdwC1AzQCExIZB/LcAGMTOC B0AtUDO8NqBstzhQN9E1FTElYiBUcAng3xQAJ+AdQCFzILF5K8EDoP0T0G8jEB9gJEI0HzUqHapR HaQ+IC1A4k8FEGePC4AHQAXQB5BzYWcwUItA4kBmRgNhOiBEA5HKSArAazbxIFsAwAMQWSQQOmQT 4UPSQAfAdHJ3BbBrLS0wE9AzQHngLkNPTV1AZgZgAjAtQ0BKKpA64Tgm4DE5IUfwIDg6M0gQUE3/ QGYdMENAB2FHQAnwQ9JAZpxDY0NABSAUEGNAIhD/IyAlkDhQLfABoCWQIPFGd5h1Ymox4UNAUmVD Q38lFkyxIRAKwDzAQGZO3k9rA6BDAGlHwThHQkfUMRg0OjBRoEfgIEVE+FQgeQhgIFADYA6wQGat TzYuU/BS+EwUICcEIP50CHADoB+DCsAIYCqgNdD+VyhTKBFSYQXALZBM8jhj9SQRKiRBKk9HJIMw oyT1q1L4NSk/Tt5CBZBhLeDvPXQmolJgR3FmCeAtQCFk/yTqOKQe8S2QN+E10FveVtP7QGYFoG4f UAShAaAIYAVAfyehLqMqIwuAMOAH4CiRc98AwB1wKIIgAAQQaV+xPNN+Yh9gQGYBkCfAPQEzgm/+ Zk9HC4AnETMQIWQCIC4A/zeiMnJW0ze8HVArEVzbQGbNXcFlVPAlq09rZ9Am4P8gAAuAIVFmQiWr a9dcR0Bm8yHAMOBuJwVAJyYvFjDg/yqBR3AfUEHhTqErAg7AO7DbAIEi0XBM0CIQY09HMHH7LYA7 sHI4RUBmK0AN4CCQ/0VgOiApoArABAAfYAaQIKP8SVAGYHRAOyN2wyRCZYH/GCAwcQmAKzIDoWXG PKJzUTppKBFiYpF6KSGwS0X/ThJ2VAeQAZFLMSDAKaAgsf8egDUxH3AHcSmgYoE10FP3/R2kUx1A UmIzgXDiLocUEN8rEV9gAQAj4A6wP1IQIHH/EoFnkSCyDsA3IR7CdSA4Uv9BkSqQGCAiEH1hPXMG kA3gP2oEBbEgskdwB+AYIHF1I3shKaAoPykdUGNr9SRAdyPgZEIQaoOFZ1tF/x4FMuEJ4DNRJ3Ii RVJjAxD7AyBlgXROoC6lR3AeoDhQ3y/CX2CGcjqmAHB5Z8Em4H8kQCeRAkASgStAIZET4HD/c3J/ XGfQUlNCECRhPk8/Uf010FQgwR+BHtAEIDzij3TvJAIgcDNyHZsxh2CJ4UdwvwmAV7N5IzBiCYAl pTKVv/uCBCmgZApQJAJ68zhDJaW+M5fPmN1BcVdhLbB0PMDuKHdxN7cJgDsfdFWSA6DraX2D9Ckl pTSa75jWZYCfXHQgshewK9BkYWRtC4DvNyF1UQWxQfBpKaAtUCWl/jWhP5jdXIAgsQIwhYYfMPsD ECgCKDMEPAEHgD0wB+D/h6Jd5TuyPNOOgRewHtASgf8vEwDQcpKgph4FZnI60ibg/1JiLxYwRCCj OqU10K2VBCCqMibgMybgNGpTNVJTwFNIT1VMRIcwJwEfdsMiECfBgWMfYE1VU/5Uh2CBk4IENcGA IWeRXRP/rbMm4K95ThJ+QlyRNdBQULdogq2lsZAoKwIAwHllgf+tw6EgriQ84XDxrw+uETkR/7nI gZMgsrRmHaqS4mhjfoL/UlQokC/Rc/V07Z7CZvC5w+8h4YzztlleBG8HkIDDkUH/XJFWEZLgnsI3 wQiQXeW4gP+HYK94FEAiEF2gvtMfoauVnyFxgwQ6psaWJuBBTrJB/mLFsygRH6GOgZzpmcgdUP+P kMTxfdE8Ih9gJX4hwCfA/GVwZXEupHbhxUfKUwVAf7LyLgIFsSRQK1ED8S/mdr+jkWoTAQAOsFdj vsRkBpD/XaCAoR9RZYBFUAnhXk1qc99eTHiLsvNfYFXTLS+QXQD6cgNgcn9ep9Igo2hjv2T/H6F1 MY9xBCApAQXAX2B5kP8KwVJhIsLBxLixBbA6jMfD/1JilgKXJ3uvfL99z37UXFb/lHFhZ1yCVQEz QCAAdVBOqd8CYIeBYoElkH9MWQeQJuD/QgAJ0d9O5hhcRx+DX4WPZv4gXSIm4Ou4ZwkzwYbQITH/ aIErAiQR6LcIcAEAtTVdYl9x9KmikyN5xEfwLkfwJf+HMAWx3VKHYGbhILK+0yCy9UBmIl+FIp7h cOImoYMD/zjCKxSfMTbRM2EXsGhBZvD/O7B1ICPhQGZwxC2wB9GUcn8zYU9H6rb2VjFzhtMlq1D/ bZgvAPVTKKIdcG49U/GVwX9U8QORclrvBCxs7vWCYFX/cmiCYG0iNdAtMARgIyGOAf/wpGVFRDAP ECQCRWIm4PTj/SOgZC4AJatWQPCRjvLXRb+UcfHRJEG1/jNkILIiYeHfi+DO4D0RDbBHcGz0YClB /8XLNaOS4TzBwdTiE7FSDxDtpEFvr1Nf4UKdcCRCLxH/YvQNQlXTecQ8k18i3vQm4N8LEo8iJqIh 0i1QbibgKML/J7Igsqk1dSQi4UHRZBE9QPs7gAXdSCth/uPQ03NBK+B/9zJm4Y0ieaELFSxdalNC /6v1jXmBwjUoL4EC4VTxtln/evTnsTkRTjCBkvjiggSFLPchc5ExdbBk2ICPkYch8dHfw1aBk5Ry JGOgoCCS0noA/kIcZ5KAHUWF8ioxjuGkAe/dA5x/b4GTE2td4itig5H/ZFLroGRApOG2WLuDHi0t 4P8PMoKQAuEgJJRytDI3IGaRb5YxlHE7Y58ibigkTBBv90PQg0HYcyDnkwdBPOIz0P9MENuyM8Cp sGMj58FqcXmQf+ex9OJVIGRBnXC41NQwJ/+LhCpkvMKHi7Rlu4NeAxnwv6omzOKe4oEAR3DNO0ZV MO+CoufAsnbcMGenUlZSgpD//uHW8l9gS8A4cHdRaYwABf9G4Jzg09Gvc2TDi3DLJEtC/130zoAW 1PWii3KujcI4XgP/v2HqobVQwNBckGiBmNW19P9FYoaoY1Fk4KQAOcF5woKj/2VRg2e2VsEiegD3 MKxQZsH/CAMF/CeGF/OBYtgw5SFiof920MDA9zLdqtQGqtKfAo4i//2fxFX5Ka7QYeCjwIOAWGj9 EmFkr1EVAGHRxNKFkegt/7eQkwVd9BMSK1NPqSSTo1L7h4Fm0nd3II7RLyF20OTB/wsWXJDn4GbD DBbKJF9nLJX/Taj11GOgzkCBoWnRaW2TdP/W8xJhVACOAVTEEsFCYiyj++IStoBsc8B1sHmQleHX Af9caBbEWd29fWNRj3R5oiyy/wuWlsQPMZ6AB0FIJhMTSKD/CYPBIcNWk9Vh2bawYqfNPf84BWwA gXE6oYq1qaLyVk+j/4NhnWFPoVUCL9IPBnGCHkDnhQEicbyzbXl3IKPgPCn/xQJWE2xEZxK04hMR DzIdgX+L4HQwwMS40axBMUWHAXX/09FqWDBU1vI7oRJi47JLvfv+BiLARFuwzTV1CKzdW7L/tbT9 IbJwpMOE4NuhN8ISYf2R0HqKtdSLSSADQYuxSKV9xDJDqeA8QL8D8eHwkW9blzB/TFQ6IJVEfX9A HgBCEAEAAAA2AAAAPDE5OTkwNjE5MDAzOC5SQUEwOTE2OUBwb3Rhc3NpdW0ubmV0d29yay1hbGNo ZW15LmNvbT4AAAADAN4/r28AAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAFgAgg BgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAACACCAGAAAAAADAAAAAAAAARgAAAABShQAA8BMA AB4AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQADAAKACCAGAAAAAADAAAAA AAAARgAAAAABhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAA AAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4A CIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAmACCAGAAAAAADAAAAAAAAA RgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAA AAAAAAsAC4ALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwAMgAsgBgAAAAAAwAAAAAAAAEYA AAAABYgAAAAAAAALAJmACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAQYAIIAYAAAAAAMAA AAAAAABGAAAAAAaFAAAAAAAAAwDxPwkEAAADACYAAAAAAAMANgAAAAAAAwD9P+QEAAADAIAQ//// /wIBRwABAAAAOgAAAGM9VVM7YT0gO3A9VGltZVN0ZXAgQ29ycG9yYTtsPUVYQ0hBTkdFLTk5MDYy MjEyNTQwNFotNzA4NQAAAB4AOEABAAAACQAAAFRKRU5LSU5TAAAAAB4AOUABAAAACQAAAFRKRU5L SU5TAAAAAEAABzBwy/tOrry+AUAACDAgjAlPrry+AR4APQABAAAABQAAAFJFOiAAAAAAHgAdDgEA AAAoAAAARGFuZ2xpbmcgU0EgU3VtbWFyeSAoZmluYWwgY29tbWVudHM/Pz8pAB4ANRABAAAAMgAA ADwzMTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkI2ODkyRkBleGNoYW5nZT4AAAALACkA AAAAAAsAIwAAAAAAAwAGEFe9lmYDAAcQhw8AAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABU T0FMTDpJTUdPSU5HUFJFRkFDRVRISVNSRVNQT05TRVdJVEhUSEVDT01NRU5UVEhBVElSRUFMSVpF VEhBVElWRUxPU1RUSElTQkFUVExFVE9OT1RBTExPV0RBTkdMSU5HU0FTAAAAAAIBfwABAAAAMgAA ADwzMTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkI2ODkyRkBleGNoYW5nZT4AAAAz2A== ------_=_NextPart_000_01BEBCAE.4F098C20-- From owner-ipsec@lists.tislabs.com Tue Jun 22 10:45:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09143; Tue, 22 Jun 1999 10:44:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09013 Tue, 22 Jun 1999 11:35:06 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: ipsec@lists.tislabs.com Subject: IPCP implementations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jun 1999 11:34:36 -0400 Message-Id: <19990622153442.28DC241F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Who is shipping IPCP in their IPSEC implementations? From owner-ipsec@lists.tislabs.com Tue Jun 22 10:47:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09202; Tue, 22 Jun 1999 10:47:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09019 Tue, 22 Jun 1999 11:36:18 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: ipsec@lists.tislabs.com Subject: using por numbers in selectors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jun 1999 11:35:45 -0400 Message-Id: <19990622153551.132E841F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do any commercial IPSEC implementations use port numbers in their policy databases? The ones I've looked at this far seem to use only IP addresses. From owner-ipsec@lists.tislabs.com Tue Jun 22 11:06:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA09803; Tue, 22 Jun 1999 11:06:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09132 Tue, 22 Jun 1999 12:00:54 -0400 (EDT) Message-ID: <376FB34E.D528D26C@redcreek.com> Date: Tue, 22 Jun 1999 09:01:18 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: Dangling SA Summary (final comments???) References: <319A1C5F94C8D11192DE00805FBBADDFB6892F@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tim, > Tim Jenkins wrote: > > Also, obviously, I'm going to have to update the re-keying document to > reflect the fact that systems are free to have dangling phase 2 SAs. > However, I must insist that implementations are also free to have > multiple phase 1 SAs with peers so that they can choose not to have > dangling phase 2 SAs. I must be missing something here - I am under the impression that implementations have *always* been free to have multiple phase 1 SAs with peers. Am I misunderstanding your post? Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 11:18:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10095; Tue, 22 Jun 1999 11:18:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09156 Tue, 22 Jun 1999 12:06:18 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB68A6E@exchange> From: Tim Jenkins To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: Dangling SA Summary (final comments???) Date: Tue, 22 Jun 1999 12:08:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: June 22, 1999 12:01 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Dangling SA Summary (final comments???) > > > Hi Tim, > > > Tim Jenkins wrote: > > > > > Also, obviously, I'm going to have to update the re-keying > document to > > reflect the fact that systems are free to have dangling phase 2 SAs. > > However, I must insist that implementations are also free to have > > multiple phase 1 SAs with peers so that they can choose not to have > > dangling phase 2 SAs. > > I must be missing something here - I am under the impression that > implementations have *always* been free to have multiple phase 1 SAs > with peers. Am I misunderstanding your post? > > Scott > Not at all. I just wanted to make sure that it was clear. I think that there is much too much that is either implicit or not specified in these documents; this is one of those things that I think should stated somewhere. So, it's going into the re-keying document... (Well, that part is already there.) From owner-ipsec@lists.tislabs.com Tue Jun 22 11:42:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10680; Tue, 22 Jun 1999 11:42:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09296 Tue, 22 Jun 1999 12:42:52 -0400 (EDT) From: "Partha Bhattacharya" To: Subject: ID lists in IKE phase 2 Date: Tue, 22 Jun 1999 09:44:00 -0700 Message-ID: <000601bebcce$6e11fcb0$d52447ab@pbhattac-ntl.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to see lists of ID payloads being negotiated in IKE phase 2. At least negotiating multiple networks on two sides seems quite beneficial to me in scenarios where there are disparate networks behind a security gateway. With the current restriction of 1 ID per phase 2 SA, a large number of SAs may be required. I would like to know how the wg feels about this: complexity, benefits etc. - Partha Bhattacharya From owner-ipsec@lists.tislabs.com Tue Jun 22 11:42:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10687; Tue, 22 Jun 1999 11:42:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09351 Tue, 22 Jun 1999 12:50:04 -0400 (EDT) Message-ID: <376FBEDB.2D071D8B@redcreek.com> Date: Tue, 22 Jun 1999 09:50:35 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Anupama Potluri CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Anupama, Thanks for reviewing the draft. Comments below. Anupama Potluri wrote: > I have the following questions regarding the draft. > > 2.9 INVALID-MESSAGE-ID > > In this case, the invalid message ID is contained in the ISAKMP > header of the notify message. > > But, the message ID of an informational exchange is supposed to be a unique > value (not the same as the message ID which triggered this message). How can > the invalid message ID be part of the ISAKMP header of the notify message? > In fact, I would like it if they are the same but the ISAKMP RFC clearly > states that except for the CONNECTED message, for all other notifies, it > is a new message ID. You're right - I'll fix that. > NO-PROPOSAL-CHOSEN : there is no information to find out which QM exchange > under an ISAKMP SA, this notify belongs to. Why isnt the protocol ID > here the protocol ID from the selected SA? How do we handle this? The message ID provides the quick mode info, but as you previously pointed out, it can't be the same as the one in isakmp header. One way to fix this is by putting the message ID in the notification data. If there are no objections, I'll do this. > ... And one > more question on this - isnt it inconsistent to make the SPI size 0 and the > SPI to be the two ISAKMP cookies? Yes - this is a cut-and-paste error. > INVALID-CERT-ENCODING, INVALID-CERTIFICATE, CERT-TYPE-UNSUPPORTED, > INVALID-CERT-AUTHORITY, INVALID-SIGNATURE, CERTIFICATE-UNAVAILABLE : are not > valid in quick mode (as far as I know) since signature and RSA encryption > authentication modes are for phase 1 and not for QM. If it is any other mode > other than QM in phase 2, it is fine but in that case the SPI will not be > the 4 byte IPSEC SPI, will it?! Right. I guess I'm thinking that some of the phase 2 ID payload values (present and future) may require additional cert functionality, and that these messages would then be useful. For example, it seems possible that phase 2 SAs for multiple endpoint pairs (using different DNs for selectors) might be negotiated through a single phase 1 SA. In this case, additional cert/auth exchanges would be required. If this seems far-fetched to folks, I guess we could delete this from the doc, and add it back later if it ever becomes necessary. > UNSUPPORTED-EXCHANGE-TYPE : Wont the protocol always be ISAKMP for this and > the SPI none even if we get an invalid exchange type after the ISAKMP SA is > mature? Esp. as we dont know that there will be a SA payload in that exchange? > (The draft says the protocol is the Protocol ID from the chosen SA.) Yes, this is more cut-and-paste madness, probably the result of the fact that my eyes were glazing over by the time I got that far into the doc. I'll change this. > I have a question regarding the phase 2 notify messages. > The following has been stated for all phase 2 notify messages. > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > But, the ISAKMP RFC states the following : > > o SPI (variable length) - Security Parameter Index. The receiving > entity's SPI. > > We did have this problem in the bakeoff and it seemed to me that people > agreed that it has to be the receiving entity's SPI. Another cut-and-paste from the DOI doc, and as you point out, it's incorrect in this context. I'll fix it. Thanks for your very thorough reading of the doc. Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 12:08:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11496; Tue, 22 Jun 1999 12:08:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09500 Tue, 22 Jun 1999 13:16:09 -0400 (EDT) Message-ID: <376FC4F8.E53D3DB4@redcreek.com> Date: Tue, 22 Jun 1999 10:16:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <19990622153551.132E841F16@SIGABA.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. RedCreek will be supporting ports in an upcoming release. From owner-ipsec@lists.tislabs.com Tue Jun 22 12:59:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14946; Tue, 22 Jun 1999 12:59:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09637 Tue, 22 Jun 1999 13:52:23 -0400 (EDT) Message-ID: <376FCC50.E3715D54@ire-ma.com> Date: Tue, 22 Jun 1999 13:48:00 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <19990622153551.132E841F16@SIGABA.research.att.com> <376FC4F8.E53D3DB4@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IRE IPSec Client supports port selectors "Scott G. Kelly" wrote: > "Steven M. Bellovin" wrote: > > > > Do any commercial IPSEC implementations use port numbers in their > > policy databases? The ones I've looked at this far seem to use only > > IP addresses. > > RedCreek will be supporting ports in an upcoming release. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Jun 22 12:59:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15127; Tue, 22 Jun 1999 12:59:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09810 Tue, 22 Jun 1999 14:08:06 -0400 (EDT) Message-ID: <376FD0C9.80C31E7A@mitel.com> Date: Tue, 22 Jun 1999 14:07:05 -0400 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <19990622153551.132E841F16@SIGABA.research.att.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. Do commercial IPSEC implementations use policy databases separate from the IP filter databases? I'd figured that the policy database was just a glorified IP filter database and thus would indeed also have port numbers and TCP flags. Or am I confused? -- The opinions expressed in this message are my personal opinion and in no way reflect the views of my employer. Søren Kierkegaard says "Life can only be understood backwards; but it must be lived forwards." From owner-ipsec@lists.tislabs.com Tue Jun 22 12:59:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15183; Tue, 22 Jun 1999 12:59:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09860 Tue, 22 Jun 1999 14:15:44 -0400 (EDT) Message-ID: <376FD2EE.67C1C82B@redcreek.com> Date: Tue, 22 Jun 1999 11:16:14 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mason, David" CC: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-notifymsg-00.txt References: <447A3F40A07FD211BA2700A0C99D759B05D0BB@md-exchange1.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry to take so long to reply. Comments interspersed. "Mason, David" wrote: > > For ISAKMP header field error messages (flags, version, > exchange, cookies, message id) it might be easier to > implement and perhaps more beneficial for other reasons > if the entire offending header was supplied rather than > just the offending field. I guess this makes sense. If nobody else objects to this, I can make this change. > >2.1 INVALID-PAYLOAD-TYPE > > o Notification Data - contains the subject payload > > Perhaps with this message and in others, when > supplying an offending payload the NextHeader field in > the subject payload should be set to the type of the > payload in question. I could go either way on this, except that leaving it alone might provide the originator with some context clue. > >2.13 ATTRIBUTES-NOT-SUPPORTED > > The transform id in addition to the protocol id should probably > be supplied. Or better yet supply the SA payload with an > offset indicator to the offending attribute. I agree that the transform ID would be useful, but originally figured the entire SA payload might be overkill in terms of both useful information and bandwidth. If you include the entire payload, you would also need some indication of which attributes were problematic. However, if nobody objects to this, we could make this change. > >2.14 NO-PROPOSAL-CHOSEN > > Optionally supply a proposal(s) that might be considered > acceptable in the notification data. This is a slippery slope - I think this would open an implementation to probing, and that's probably not a GoodThing. > >2.15 BAD-PROPOSAL-SYNTAX > > Should probably contain an offset indicator to the offending > byte within the proposal. > >2.16 PAYLOAD-MALFORMED > > Also should have an offset indicator and there could be > other messages that might benefit from an offset > indicator as well. I can see where offsets would be useful for diagnostics. If nobody objects, these could be added. Thanks for reviewing the draft. Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 13:02:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15758; Tue, 22 Jun 1999 13:02:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09898 Tue, 22 Jun 1999 14:26:28 -0400 (EDT) Message-ID: <376FD568.7461B178@redcreek.com> Date: Tue, 22 Jun 1999 11:26:48 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Partha Bhattacharya CC: ipsec@lists.tislabs.com Subject: Re: ID lists in IKE phase 2 References: <000601bebcce$6e11fcb0$d52447ab@pbhattac-ntl.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Partha Bhattacharya wrote: > > I would like to see lists of ID payloads being negotiated in IKE phase 2. At > least negotiating multiple networks on two sides seems quite beneficial to > me in scenarios where there are disparate networks behind a security > gateway. With the current restriction of 1 ID per phase 2 SA, a large number > of SAs may be required. > > I would like to know how the wg feels about this: complexity, benefits etc. I second the motion. I proposed this around a year ago, but it didn't generate much interest at that time. I remain interested in this functionality. Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 13:06:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16388; Tue, 22 Jun 1999 13:06:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09839 Tue, 22 Jun 1999 14:12:14 -0400 (EDT) Message-Id: <199906221811.LAA24520@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-reply-to: Your message of "Tue, 22 Jun 1999 10:16:40 PDT." <376FC4F8.E53D3DB4@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24517.930075085.1@network-alchemy.com> Date: Tue, 22 Jun 1999 11:11:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I may regret opening this up again but.... So what are you going to do if you're locally configured for, say, "all tcp traffic" or "all IP traffic" and someone gives you an offer of "tcp port X"? Refuse it? Similarly, what do you do if you're configured for "all IP to the 10.20.30/24 network" and someone gives you an offer to 10.20.30.87? Do you refuse it? Dan. On Tue, 22 Jun 1999 10:16:40 PDT you wrote > "Steven M. Bellovin" wrote: > > > > Do any commercial IPSEC implementations use port numbers in their > > policy databases? The ones I've looked at this far seem to use only > > IP addresses. > > RedCreek will be supporting ports in an upcoming release. From owner-ipsec@lists.tislabs.com Tue Jun 22 13:10:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16415; Tue, 22 Jun 1999 13:10:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09886 Tue, 22 Jun 1999 14:23:40 -0400 (EDT) Message-ID: <376FD4CB.A1ABF5EC@redcreek.com> Date: Tue, 22 Jun 1999 11:24:11 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906221811.LAA24520@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Dan Harkins wrote: > > I may regret opening this up again but.... > > So what are you going to do if you're locally configured for, say, > "all tcp traffic" or "all IP traffic" and someone gives you an offer > of "tcp port X"? Refuse it? > > Similarly, what do you do if you're configured for "all IP to the > 10.20.30/24 network" and someone gives you an offer to 10.20.30.87? > Do you refuse it? > I guess I would say that "all" of any type traffic is the same as a wildcard. In this case, if someone offered me tcp port X, I would establish the SA with them, since it matches my policy. I do see your point, however. The question really depends on whether there is some mechanism for specifying how may SAs "all IP to the wxyz network" actually means to permit. Good question. Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 13:44:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA17148; Tue, 22 Jun 1999 13:44:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09964 Tue, 22 Jun 1999 14:46:37 -0400 (EDT) Message-ID: <376FD904.6A2ADE1E@ire-ma.com> Date: Tue, 22 Jun 1999 14:42:12 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906221811.LAA24520@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ...and what do you do if the Policy says use FTP port - but FTP-data port is dynamically assigned? Same for HTTP. Dan Harkins wrote: > I may regret opening this up again but.... > > So what are you going to do if you're locally configured for, say, > "all tcp traffic" or "all IP traffic" and someone gives you an offer > of "tcp port X"? Refuse it? > > Similarly, what do you do if you're configured for "all IP to the > 10.20.30/24 network" and someone gives you an offer to 10.20.30.87? > Do you refuse it? > > Dan. > > On Tue, 22 Jun 1999 10:16:40 PDT you wrote > > "Steven M. Bellovin" wrote: > > > > > > Do any commercial IPSEC implementations use port numbers in their > > > policy databases? The ones I've looked at this far seem to use only > > > IP addresses. > > > > RedCreek will be supporting ports in an upcoming release. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Jun 22 14:00:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17476; Tue, 22 Jun 1999 14:00:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10141 Tue, 22 Jun 1999 15:14:57 -0400 (EDT) Message-ID: <376FDFB2.678FD4A@ire-ma.com> Date: Tue, 22 Jun 1999 15:10:42 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Dan Harkins , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906221811.LAA24520@potassium.network-alchemy.com> <376FD904.6A2ADE1E@ire-ma.com> <376FDC29.4A4B6F38@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am talking about FTP ports (within TCP protocol, of course). FTP ports (typically) means port 21 and 20. But often it also means 21 and some-other-dynamicaly-assigned port - what should be done in this case for selectors? The whole issue of bringing port selectors into IPSec is a big mistake to begin with (IMHO) - ports belong in the Transport Layer, not to IP layer. Bringing them into IPSec is a poor attempt to filter traffic based on selectors that is better implemented by Transport Layers security or firewalls. "Scott G. Kelly" wrote: > Slava Kavsan wrote: > > > > ...and what do you do if the Policy says use FTP port - but FTP-data port > > is dynamically assigned? Same for HTTP. > > I may be misunderstanding, but this sounds like an implementation > problem, and one that is completely unrelated to the original question > at that. First of all, the "protocols" supported as selectors only > include those IP protocols with IANA numbers, of which FTP is not one. > > Secondly, if your configuration utility permits someone to specify "use > FTP port" with no further indication of what "FTP port" means, then I > guess it is up to your implementation to know that FTP runs over TCP, > and to dynamically track which TCP ports are being used for FTP by the > systems it is protecting. This is admittedly a can of worms, but I don't > think it means we shouldn't support port numbers (or ranges, or > wildcards) in selectors. > > Scott -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Jun 22 14:00:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17494; Tue, 22 Jun 1999 14:00:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10095 Tue, 22 Jun 1999 15:05:59 -0400 (EDT) Message-Id: <199906221905.PAA13695@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-isakmp-hybrid-auth-02.txt Date: Tue, 22 Jun 1999 15:05:02 -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 : A Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-02.txt Pages : 10 Date : 21-Jun-99 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectional authenticated. To make this IKE bi-directional authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-02.txt 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-isakmp-hybrid-auth-02.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-isakmp-hybrid-auth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990621135704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990621135704.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 22 14:07:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17649; Tue, 22 Jun 1999 14:07:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10124 Tue, 22 Jun 1999 15:11:48 -0400 (EDT) Message-Id: <199906221910.MAA24864@potassium.network-alchemy.com> To: Slava Kavsan cc: "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-reply-to: Your message of "Tue, 22 Jun 1999 14:42:12 EDT." <376FD904.6A2ADE1E@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24861.930078651.1@network-alchemy.com> Date: Tue, 22 Jun 1999 12:10:51 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was wondering about another example of asymmetric configurations where negotiation in one direction succeed and in the other fail. I intentionally didn't use the P word. But since you asked, I don't know. You can't express "the FTP data port" in IKE. Dan. On Tue, 22 Jun 1999 14:42:12 EDT you wrote > ...and what do you do if the Policy says use FTP port - but FTP-data port > is dynamically assigned? Same for HTTP. > > Dan Harkins wrote: > > > I may regret opening this up again but.... > > > > So what are you going to do if you're locally configured for, say, > > "all tcp traffic" or "all IP traffic" and someone gives you an offer > > of "tcp port X"? Refuse it? > > > > Similarly, what do you do if you're configured for "all IP to the > > 10.20.30/24 network" and someone gives you an offer to 10.20.30.87? > > Do you refuse it? > > > > Dan. > > > > On Tue, 22 Jun 1999 10:16:40 PDT you wrote > > > "Steven M. Bellovin" wrote: > > > > > > > > Do any commercial IPSEC implementations use port numbers in their > > > > policy databases? The ones I've looked at this far seem to use only > > > > IP addresses. > > > > > > RedCreek will be supporting ports in an upcoming release. > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > > From owner-ipsec@lists.tislabs.com Tue Jun 22 14:25:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17992; Tue, 22 Jun 1999 14:25:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10350 Tue, 22 Jun 1999 15:40:55 -0400 (EDT) Message-ID: <3D33CF40366DD111AC4100A0C96B22AC04124B14@fmsmsx34.fm.intel.com> From: "Jeronimo, Michael" To: "'Scott G. Kelly'" , "Steven M. Bellovin" Cc: ipsec@lists.tislabs.com Subject: RE: using por numbers in selectors Date: Tue, 22 Jun 1999 11:10:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Intel also supports selectors using ports. > -----Original Message----- > From: Scott G. Kelly [SMTP:skelly@redcreek.com] > Sent: Tuesday, June 22, 1999 10:17 AM > To: Steven M. Bellovin > Cc: ipsec@lists.tislabs.com > Subject: Re: using por numbers in selectors > > "Steven M. Bellovin" wrote: > > > > Do any commercial IPSEC implementations use port numbers in their > > policy databases? The ones I've looked at this far seem to use only > > IP addresses. > > RedCreek will be supporting ports in an upcoming release. From owner-ipsec@lists.tislabs.com Tue Jun 22 14:39:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA18365; Tue, 22 Jun 1999 14:39:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10453 Tue, 22 Jun 1999 15:54:43 -0400 (EDT) From: "Partha Bhattacharya" To: "Steven M. Bellovin" , Subject: RE: using por numbers in selectors Date: Tue, 22 Jun 1999 12:55:47 -0700 Message-ID: <000c01bebce9$38a4aa30$d52447ab@pbhattac-ntl.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <19990622153551.132E841F16@SIGABA.research.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The current Cisco IOS implementation supports port numbers as well. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin > Sent: Tuesday, June 22, 1999 8:36 AM > To: ipsec@lists.tislabs.com > Subject: using por numbers in selectors > > > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. > > > From owner-ipsec@lists.tislabs.com Tue Jun 22 15:35:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21396; Tue, 22 Jun 1999 15:35:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10669 Tue, 22 Jun 1999 16:59:40 -0400 (EDT) From: xs-dated-6e17eefc8c27e033@rhino.safari.net Delivered-To: xs@rhino.safari.net Delivered-To: xs@SAFARI.NET Message-Id: <199906221905.PAA13695@ietf.org> Mime-Version: 1.0 X-Security: MIME headers sanitized on rhino See http://www.wolfenet.com/~jhardin/procmail-security.html for details. $Revision: 1.84 $Date: 1999-06-12 12:30:37-07 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@odin.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-hybrid-auth-02.txt Date: Tue, 22 Jun 1999 15:05:02 -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 : A Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-02.txt Pages : 10 Date : 21-Jun-99 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectional authenticated. To make this IKE bi-directional authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-02.txt 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-isakmp-hybrid-auth-02.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-isakmp-hybrid-auth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990621135704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990621135704.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 22 15:35:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21404; Tue, 22 Jun 1999 15:35:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10613 Tue, 22 Jun 1999 16:42:01 -0400 (EDT) From: "Partha Bhattacharya" To: "Dan Harkins" , "Scott G. Kelly" Cc: Subject: RE: using por numbers in selectors Date: Tue, 22 Jun 1999 13:42:53 -0700 Message-ID: <000f01bebcef$cd3ee790$d52447ab@pbhattac-ntl.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199906221811.LAA24520@potassium.network-alchemy.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that there are situations where it is reasonable for the responder to demand an exact 5 tuple match; but there are also cases where the responder may require the initiator to propose one address out of the network that is defined in the policy. The first case may arise in gateway-gateway vpns, where it is reasonable to want 1 SA per network; else an SA explosion may occur. The second case may arise in client-gateway vpns (where ip addresses can be used to define policies, e.g. cable modem). The policy may be broad but the initiator must initiate for itself. I think it is hard to make a case for accepting scoped down all other fields other than src address. In the ldap ipsec policy draft, we specify a flag that if set, required the responder to accept only one address out of the src address for the policy. Partha. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Tuesday, June 22, 1999 11:11 AM > To: Scott G. Kelly > Cc: ipsec@lists.tislabs.com > Subject: Re: using por numbers in selectors > > > I may regret opening this up again but.... > > So what are you going to do if you're locally configured for, say, > "all tcp traffic" or "all IP traffic" and someone gives you an offer > of "tcp port X"? Refuse it? > > Similarly, what do you do if you're configured for "all IP to the > 10.20.30/24 network" and someone gives you an offer to 10.20.30.87? > Do you refuse it? > > Dan. > > On Tue, 22 Jun 1999 10:16:40 PDT you wrote > > "Steven M. Bellovin" wrote: > > > > > > Do any commercial IPSEC implementations use port numbers in their > > > policy databases? The ones I've looked at this far seem to use only > > > IP addresses. > > > > RedCreek will be supporting ports in an upcoming release. > From owner-ipsec@lists.tislabs.com Tue Jun 22 15:48:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21786; Tue, 22 Jun 1999 15:48:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10033 Tue, 22 Jun 1999 14:55:05 -0400 (EDT) Message-ID: <376FDC29.4A4B6F38@redcreek.com> Date: Tue, 22 Jun 1999 11:55:37 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: Dan Harkins , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906221811.LAA24520@potassium.network-alchemy.com> <376FD904.6A2ADE1E@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > > ...and what do you do if the Policy says use FTP port - but FTP-data port > is dynamically assigned? Same for HTTP. I may be misunderstanding, but this sounds like an implementation problem, and one that is completely unrelated to the original question at that. First of all, the "protocols" supported as selectors only include those IP protocols with IANA numbers, of which FTP is not one. Secondly, if your configuration utility permits someone to specify "use FTP port" with no further indication of what "FTP port" means, then I guess it is up to your implementation to know that FTP runs over TCP, and to dynamically track which TCP ports are being used for FTP by the systems it is protecting. This is admittedly a can of worms, but I don't think it means we shouldn't support port numbers (or ranges, or wildcards) in selectors. Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 16:04:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22235; Tue, 22 Jun 1999 16:04:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10762 Tue, 22 Jun 1999 17:22:25 -0400 (EDT) Reply-To: From: "Oliver Tavakoli" To: "Steven M. Bellovin" , Subject: RE: using por numbers in selectors Date: Tue, 22 Jun 1999 17:22:24 -0400 Message-ID: <000001bebcf5$527bd850$1bacddcf@sledge.tril-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <19990622153551.132E841F16@SIGABA.research.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Trilogy's AdmitOne IPsec clients (Win95/98/NT) also support port numbers. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin > Sent: Tuesday, June 22, 1999 11:36 AM > To: ipsec@lists.tislabs.com > Subject: using por numbers in selectors > > > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. > > From owner-ipsec@lists.tislabs.com Tue Jun 22 16:23:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22656; Tue, 22 Jun 1999 16:23:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10830 Tue, 22 Jun 1999 17:44:29 -0400 (EDT) From: Jackie Wilson Message-Id: <199906222144.QAA32886@jhwilson.austin.ibm.com> Subject: Re: using por numbers in selectors In-Reply-To: <19990622153551.132E841F16@SIGABA.research.att.com> from "Steven M. Bellovin" at "Jun 22, 99 11:35:45 am" To: smb+lists@research.att.com (Steven M. Bellovin) Date: Tue, 22 Jun 1999 16:44:02 -0500 (CDT) Cc: ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IBM products for their platforms (AIX, AS/400, OS/390) support port numbers. The port numbers must be specified in the configuration files. Jackie Steven M. Bellovin wrote: > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. > > -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec@lists.tislabs.com Tue Jun 22 17:26:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23943; Tue, 22 Jun 1999 17:26:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11002 Tue, 22 Jun 1999 18:46:44 -0400 (EDT) From: Dan McDonald Message-Id: <199906222245.PAA03828@kebe.Eng.Sun.COM> Subject: Re: using por numbers in selectors To: bkavsan@ire-ma.com (Slava Kavsan) Date: Tue, 22 Jun 1999 15:45:30 -0700 (PDT) Cc: skelly@redcreek.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com In-Reply-To: <376FDFB2.678FD4A@ire-ma.com> from "Slava Kavsan" at Jun 22, 99 03:10:42 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I am talking about FTP ports (within TCP protocol, of course). > FTP ports (typically) means port 21 and 20. But often it also means 21 and > some-other-dynamicaly-assigned port - what should be done in this case for > selectors? Wildcard the some-other-port bit, of course. > The whole issue of bringing port selectors into IPSec is a big mistake to > begin with (IMHO) - ports belong in the Transport Layer, not to IP > layer. Bringing them into IPSec is a poor attempt to filter traffic based > on selectors that is better implemented by Transport Layers security or > firewalls. Do you write end-system code that extensively uses transport mode IPsec at all? I'll bet you don't, because if you did you'd totally understand why port selectors are there in the first place. Do you have customers asking you if you can secure their legacy apps end-to-end with IPsec? I do. And yes, Solaris IPsec has port selectors and/or per-socket IPsec policy. To answer Dan H's question about precedence, we parse in order of rule-entry, so it's up to the admin to decide how a question of conflict gets answered. Dan McD. (the other Dan) From owner-ipsec@lists.tislabs.com Tue Jun 22 17:26:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23939; Tue, 22 Jun 1999 17:26:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11017 Tue, 22 Jun 1999 18:51:46 -0400 (EDT) From: Clemen Jue Message-Id: <9906222224.AA08742@hpinrput.cup.hp.com> Subject: Re: using por numbers in selectors To: smb+lists@research.att.com (Steven M. Bellovin) Date: Tue, 22 Jun 1999 15:24:13 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <19990622153551.132E841F16@SIGABA.research.att.com> from "Steven M. Bellovin" at Jun 22, 99 11:35:45 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. The HP/9000 implementation supports port numbers as well. Clemen Jue Hewlett-Packard From owner-ipsec@lists.tislabs.com Tue Jun 22 18:21:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA25072; Tue, 22 Jun 1999 18:21:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11135 Tue, 22 Jun 1999 19:33:09 -0400 (EDT) Message-ID: <37701D59.9482E45D@redcreek.com> Date: Tue, 22 Jun 1999 16:33:45 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheila Frankel CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long) References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sheila, More responses to your comments below... > Sheila Frankel wrote: > > >2.4 INVALID-COOKIE > > > The INVALID-COOKIE error message may be used to communicate that an > > invalid ISAKMP cookie was received.> > > > > What's an invalid ISAKMP cookie? Does this message apply when the peer > initiates a Quick Mode negotiation for an expired Phase 1 SA? > If so, this should be explicitly stated. > This turns up a good point. There are a couple of situations under which an invalid cookie occurs: - one cookie matches, and one doesn't - neither cookie matches In the first case, there is (probably) some sort of bug or error on the other end. In the second case, the SA has probably expired. I can add clarifying language, and I think the receiving end can figure out which case it is based upon the number of cookies returned in the notify message, i.e. if it's the first case, only return the (single) invalid cookie, and in the second case, return them both. Another question I have is, where should the cookies go, in the notification data, or in the SPI field? Any thoughts on this? > >2.8 INVALID-FLAGS > > > > The INVALID-FLAGS error message may be used to communicate that one > > or more of the received ISAKMP header flags were unrecognized or > > invalid. > > > > Should this message be used in the following cases: > > 1) An unencrypted message is received, which should have been > encrypted. > > 2) An encrypted message is received, which should have been > unencrypted. > > If so, this should be explicitly stated. Okay, I'll add clarifying text. > >2.10 INVALID-PROTOCOL-ID > > > > The INVALID-PROTOCOL-ID error message may be used to communicate > that > > an invalid or unrecognized protocol ID was received as part of a > > proposal payload. > > > > Is unrecognized the same as unsupported? In either case, I think > unsupported > > should be mentioned here. (picky, picky!!) > > Payloads: Proposal > I can change unrecognized to unsupported. > >2.17 INVALID-KEY-INFORMATION > > > > The INVALID-KEY-INFORMATION error message may be used to communicate > > that the key exchange type specified by the key exchange payload is > > not supported. > > > > Wouldn't this also include key info that is not the correct > length/size for the key exchange? > This is not specified in the ISAKMP RFC, though it seems sensible. I'll add text to that effect. > >2.23 INVALID-HASH-INFORMATION > > > > The INVALID-HASH-INFORMATION error message may be used to > communicate > > that the required hash type is not supported. > > > Wouldn't this include a hash of the wrong length/size? > This is not specified in the ISAKMP RFC, though it seems sensible. I'll add text to that effect. > >2.29 UNSUPPORTED-EXCHANGE-TYPE > > > > The UNSUPPORTED-EXCHANGE-TYPE error message may be used to > > communicate that the requested exchange type is not supported. > > > Do we need this? (I think this is the only case > where we have separate messages for invalid and unsupported.) > I guess that would be a question for the ISAKMP RFC editor. > >2.30 UNEQUAL-PAYLOAD-LENGTHS > > > > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate > > that message length in the ISAKMP header does not match the sum of > > the actual payload lengths. > > This also applies in the case where the message length in the ISAKMP > header > does not match the length of the message that was actually received. > It should > probably also apply to other length-related anomalies. > I don't understand the difference between the text and what you say here. Please clarify. Thanks for your thorough reading... Scott From owner-ipsec@lists.tislabs.com Tue Jun 22 18:39:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA25464; Tue, 22 Jun 1999 18:39:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11212 Tue, 22 Jun 1999 20:04:51 -0400 (EDT) Date: Wed, 23 Jun 1999 03:04:26 +0300 (EET DST) Message-Id: <199906230004.DAA19742@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jianying Zhou Cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-Reply-To: References: <199906142336.QAA20130@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 21 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jianying Zhou writes: > There was a security flaw in RFC 2409. > When SAi_b is used in HASH_I and HASH_R, an attack is possible so that > at the end of Phase 1 negotiation, the SA being negotiated may not be > authenticated. (The problem also exists in the new draft.) > To avoid the attack, simply replace SAi_b with SAr_b. Changing SAi_B to SAr_b would open another problem. In that case attacker can modify the SA proposal sent by the initiator and remove proposal that he doesn't like from the list and neither side will detect anything. Lets take an example where both ends are configured to prefer 3des. They also accept des as a second choice if the other end doesn't support anything else (say there are some old systems out that only support des). Now even if both of them support 3des, attacker can modify the proposal sent by the initiator and remove 3des from the proposal. Responder doesn't notice anything and it will just select the des that was included in the proposal (it just assumes the other end is one of those old implementations only supporting des). Initiator will not detect anything it will just assume the responder is only supporting des. This is not what was really wanted... In the current case the attacker can change some things inside the proposal, but the SAr_b must be one of the transforms from the original SAi_b (the initiator will reject it if it isn't). Also if the attacker selects different transform from the initiators list it is detected in most cases (because initiator and responder are using different parameters). Here is a list of the possible changes (by attribute class) and how they are detected: 1) Encryption algorithm: Decryption of isakmp packet fails 2) Hash algorithm: Hash calculation fails 3) Authentication method: Decryption of isakmp packet fails, because encryption keys are calculated differently. 4-10) Group description or parameters: Diffie-Hellman will give different results, thus causing decryption of isakmp packet to fail. 11-12) Life duration: This will not be detected, so both ends will use different values, but that is not fatal, nor it should not cause security problems. 13) PRF: Hash calculation fails. 14) Key length: Decryption of isakmp packet fails 15-16) Field size/group order: see group parameters 17) Block size: Decryption of isakmp packet fails So the only change that is not detected inside the ike (or the first quick mode packet if using aggressive mode) is the change in life times. If both ends send out delete notifications even that doesn't cause real problems. > (The full paper is available by request.) I would really like to see that paper. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 22 20:48:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11254; Tue, 22 Jun 1999 20:48:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11452 Tue, 22 Jun 1999 21:55:41 -0400 (EDT) Message-Id: <199906230154.SAA26308@potassium.network-alchemy.com> To: Jianying Zhou cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-reply-to: Your message of "Tue, 22 Jun 1999 17:27:25 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26305.930102890.1@network-alchemy.com> Date: Tue, 22 Jun 1999 18:54:50 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dr. Zhou has forwarded me the paper and I'll try to summarize: The Initiator offers two transforms, T1 and T2 to the Responder who chooses T2 and sends it back. This is intercepted by the attacker and changed to be T1 before being forwarded on to the Initiator. Now the Initiator thinks T1 was accepted and the Responder thinks T2 was accepted. It's noted in the paper (and was pointed out by Kivinen on the list) that the only difference between the two can be the lifetime. The attacker has to send back a transform that the Initiator sent in the first place and if the difference between T1 and T2 is more than just the lifetime the exchange will fail due to various errors (decryption failed, authentication failed, etc). The paper goes on to suggest changing SAi_b in the authenticating hash calculation to SAr_b. But this will allow an attacker to modify the Initiator's offers and remove certain offers-- for instance the offer is [(3DES, group 5, etc) || (CAST, group 5, etc) || (DES, group 1, etc)] and it becomes a single offer of [(DES, group 1, etc)]. The suggested change is flawed but if the working group thinks this attack is serious we can include both SAi_b and SAr_b in the hash calculations to prevent this. Dan. On Tue, 22 Jun 1999 17:27:25 +0800 you wrote > There was a security flaw in RFC 2409. > > When SAi_b is used in HASH_I and HASH_R, an attack is possible so that > at the end of Phase 1 negotiation, the SA being negotiated may not be > authenticated. (The problem also exists in the new draft.) > > To avoid the attack, simply replace SAi_b with SAr_b. (The full paper > is available by request.) > > Jianying > --------------------------------------------------------------------- > Dr. Jianying Zhou | Tel: +65-8742585 > Kent Ridge Digital Labs | Fax: +65-7744990 > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > Singapore 119613 | WWW: http://homex.s1.net.sg/user/jyzhou/ > --------------------------------------------------------------------- > From owner-ipsec@lists.tislabs.com Tue Jun 22 20:53:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11571; Tue, 22 Jun 1999 20:53:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11486 Tue, 22 Jun 1999 22:06:12 -0400 (EDT) Date: Wed, 23 Jun 1999 10:02:05 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-Reply-To: <199906230004.DAA19742@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 23 Jun 1999, Tero Kivinen wrote: > Jianying Zhou writes: > > There was a security flaw in RFC 2409. > > When SAi_b is used in HASH_I and HASH_R, an attack is possible so that > > at the end of Phase 1 negotiation, the SA being negotiated may not be > > authenticated. (The problem also exists in the new draft.) > > To avoid the attack, simply replace SAi_b with SAr_b. > > Changing SAi_B to SAr_b would open another problem. In that case > attacker can modify the SA proposal sent by the initiator and remove > proposal that he doesn't like from the list and neither side will > detect anything. > > Lets take an example where both ends are configured to prefer 3des. > They also accept des as a second choice if the other end doesn't > support anything else (say there are some old systems out that only > support des). > > Now even if both of them support 3des, attacker can modify the > proposal sent by the initiator and remove 3des from the proposal. > Responder doesn't notice anything and it will just select the des that > was included in the proposal (it just assumes the other end is one of > those old implementations only supporting des). Initiator will not > detect anything it will just assume the responder is only supporting > des. This is not what was really wanted... > I agree. But anyway, both ends get the authenticated SA at the end of Phase 1 negotiation. > In the current case the attacker can change some things inside the > proposal, but the SAr_b must be one of the transforms from the > original SAi_b (the initiator will reject it if it isn't). Also if the > attacker selects different transform from the initiators list it > is detected in most cases (because initiator and responder are using > different parameters). > > Here is a list of the possible changes (by attribute class) and how > they are detected: > > 1) Encryption algorithm: Decryption of isakmp packet fails > 2) Hash algorithm: Hash calculation fails > 3) Authentication method: Decryption of isakmp packet fails, > because encryption keys are calculated differently. > 4-10) Group description or parameters: Diffie-Hellman will give > different results, thus causing decryption of isakmp packet > to fail. > 11-12) Life duration: This will not be detected, so both ends will > use different values, but that is not fatal, nor it should > not cause security problems. > 13) PRF: Hash calculation fails. > 14) Key length: Decryption of isakmp packet fails > 15-16) Field size/group order: see group parameters > 17) Block size: Decryption of isakmp packet fails > > So the only change that is not detected inside the ike (or the first > quick mode packet if using aggressive mode) is the change in life > times. If both ends send out delete notifications even that doesn't > cause real problems. > Yes, the change of SA lifetime cannnot be detected in an attack. How will a delete notification be sent out if either side does not detect the attack? Suppose the initiator's SA has a longer lifetime than the responder's SA. Suppose the keys have compromised after the responder's SA expires but before the initiator's SA expires. An attacker can masquerade as the responder in a communication session. A more secure solution is to include both SAi_b and SAr_b in HASH_I and HASH_R. Jianying From owner-ipsec@lists.tislabs.com Tue Jun 22 22:17:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA20574; Tue, 22 Jun 1999 22:17:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11589 Tue, 22 Jun 1999 23:35:04 -0400 (EDT) Message-ID: <377055C6.99C91BDB@cyphers.net> Date: Tue, 22 Jun 1999 20:34:40 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: ipsec@lists.tislabs.com Subject: Re: IPCP implementations References: <19990622153442.28DC241F16@SIGABA.research.att.com> 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 The PGP 6.5 VPN client supports IPCP in its IKE using both LZS and Deflate. PGP 6.5.1 is being released next week and contains a couple of minor improvements to IPCP based on the concensus of the attendees at the Santa Barbara IKE bakeoff. "Steven M. Bellovin" wrote: > Who is shipping IPCP in their IPSEC implementations? - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQA/AwUBN3BVqKy7FkvPc+xMEQLvLQCfRKDv3UIgXh0mArIzLVNRejhl+D0AoMwU ++5FG8I98sG6/FC+THJHozlx =2giz -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jun 23 01:57:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01984; Wed, 23 Jun 1999 01:57:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12032 Wed, 23 Jun 1999 02:52:27 -0400 (EDT) Message-Id: <199906230651.KAA02335@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, "Steven M. Bellovin" Date: Wed, 23 Jun 1999 10:51:10 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: using por numbers in selectors In-reply-to: <19990622153551.132E841F16@SIGABA.research.att.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 22 Jun 99 at 11:35, Steven M. Bellovin wrote: > Do any commercial IPSEC implementations use port numbers in their > policy databases? The ones I've looked at this far seem to use only > IP addresses. TrustWorks products support port numbers. Valery. From owner-ipsec@lists.tislabs.com Wed Jun 23 05:03:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA08260; Wed, 23 Jun 1999 05:03:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12434 Wed, 23 Jun 1999 06:12:14 -0400 (EDT) Message-Id: <199906231011.OAA11264@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Jianying Zhou , Dan Harkins Date: Wed, 23 Jun 1999 14:11:41 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt CC: ipsec@lists.tislabs.com In-reply-to: <199906230154.SAA26308@potassium.network-alchemy.com> References: Your message of "Tue, 22 Jun 1999 17:27:25 +0800." X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 22 Jun 99 at 18:54, Dan Harkins wrote: > The paper goes on to suggest changing SAi_b in the authenticating > hash calculation to SAr_b. But this will allow an attacker to modify > the Initiator's offers and remove certain offers-- for instance the > offer is [(3DES, group 5, etc) || (CAST, group 5, etc) || (DES, group 1, > etc)] and it becomes a single offer of [(DES, group 1, etc)]. > > The suggested change is flawed but if the working group thinks this > attack is serious we can include both SAi_b and SAr_b in the hash > calculations to prevent this. Dan, if you are going to change hash calculation, maybe more general solution would be Tero Kivinen's proposal for these HASHes to be the hash of all packets received/sent so far. It will authenticate all auxiliary payloads either. Please, see his message <199809062326.CAA29797@torni.ssh.fi> to the list from 7 Sep 1998 for details. > Dan. Regards, Valery. From owner-ipsec@lists.tislabs.com Wed Jun 23 07:59:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA15936; Wed, 23 Jun 1999 07:59:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13297 Wed, 23 Jun 1999 09:05:49 -0400 (EDT) From: ville.kukkola@nokia.com Message-ID: <3F5EA2C18BA4D21198C40008C7894C9007FDC4@oueis07nok> To: ipsec@lists.tislabs.com Subject: FW: IPsec-implementations for Linux kernel 2.2.* Date: Wed, 23 Jun 1999 10:46:50 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Knowledge of freely distributed alpha versions are also welcome! > -----Original Message----- > From: Kukkola Ville (NMP/Oulu) > Sent: 23. June 1999 8:44 > To: ipsec@lists.tislabs.com > Subject: IPsec-implementations for Linux kernel 2.2.* > > > Hi, > > Have you any knowledge of IPsec-implementations for Linux > kernel 2.2.*? > > Yours sincerely, > > Ville Kukkola (Ville.Kukkola@nokia.com) > > From owner-ipsec@lists.tislabs.com Wed Jun 23 08:04:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16103; Wed, 23 Jun 1999 08:04:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12859 Wed, 23 Jun 1999 08:43:19 -0400 (EDT) Date: Wed, 23 Jun 1999 15:42:41 +0300 (IDT) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: Dan Harkins cc: Jianying Zhou , ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-Reply-To: <199906230154.SAA26308@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, indeed the definition of HASH_I and HASH_R as described in the IKE documents HASH_I = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b) HASH_R = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1_b) is wrong. The repetition of SAi_b in both HASHs seems like an *unfortunate typo*. The intention is that in HASH_I the initiator authenticates the information that I sends, and in HASH_R the recipient authenticates the information that R sends. Therefore the correct form should have been HASH_I = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b) HASH_R = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAr_b | ID_r1_b) ^^^^^ In this way every party authenticates the information it sends which is the main purpose of authentication. In particular this prevents the problem pointed out by Dr. Zhou. (As pointed out by Tero, ZHou's suggestion to have SAr_b in both HASHs is wrong as it allows an attacker to "degrade" I's offer). The above correction is really necessary in my view. If this is done I would support to go to the more comprehensive change suggested by Tero, namely, incorporating under the prf computation all information sent by the corresponding party. And, well, if we are going to change "the bits in the wire" with such modification then I ask to do two more changes that I suggested in the past but did not make it to the final spec: 1) In the computation of HASH_I prepend a byte = 0x00 to the input (i.e.. before g^i), and in the computation of HASH_R prepend a byte = 0x01 to the input (i.e. before g^r). The goal is to make the two prf computations necessarily different. Otherwise, in theory (but maybe also in practice?) an attacker that impersonates R could choose all the values identically to I and just resend HASH_I as the value of HASH_R (note that this would require ID_i and ID_r to be the same but even this could be possible under some scenario). If you can get convinced that such a "reflection attack" will never be practical then we may forget this, but otherwise the cost of this change is small enough to justify it. 2) Add to HASH_I the value ID_r1_b and to HASH_R the value ID_i1_b. You once had some problem in doing this and I do not remember why, but this lack of authentication of the destination of a message may well open sources of attack. Another minor change would be to rename HASH_I/HASH_R as AUTH_I/AUTH_R. These are not just hashes, they are authenticators (except, maybe, for the signature mode) and it is better to have the notation consistent with the functionality. Hugo On Tue, 22 Jun 1999, Dan Harkins wrote: > Dr. Zhou has forwarded me the paper and I'll try to summarize: > > The Initiator offers two transforms, T1 and T2 to the Responder > who chooses T2 and sends it back. This is intercepted by the > attacker and changed to be T1 before being forwarded on to the > Initiator. Now the Initiator thinks T1 was accepted and the > Responder thinks T2 was accepted. It's noted in the paper (and > was pointed out by Kivinen on the list) that the only difference > between the two can be the lifetime. The attacker has to send > back a transform that the Initiator sent in the first place > and if the difference between T1 and T2 is more than just the > lifetime the exchange will fail due to various errors (decryption > failed, authentication failed, etc). > > The paper goes on to suggest changing SAi_b in the authenticating > hash calculation to SAr_b. But this will allow an attacker to modify > the Initiator's offers and remove certain offers-- for instance the > offer is [(3DES, group 5, etc) || (CAST, group 5, etc) || (DES, group 1, > etc)] and it becomes a single offer of [(DES, group 1, etc)]. > > The suggested change is flawed but if the working group thinks this > attack is serious we can include both SAi_b and SAr_b in the hash > calculations to prevent this. > > Dan. > > On Tue, 22 Jun 1999 17:27:25 +0800 you wrote > > There was a security flaw in RFC 2409. > > > > When SAi_b is used in HASH_I and HASH_R, an attack is possible so that > > at the end of Phase 1 negotiation, the SA being negotiated may not be > > authenticated. (The problem also exists in the new draft.) > > > > To avoid the attack, simply replace SAi_b with SAr_b. (The full paper > > is available by request.) > > > > Jianying > > --------------------------------------------------------------------- > > Dr. Jianying Zhou | Tel: +65-8742585 > > Kent Ridge Digital Labs | Fax: +65-7744990 > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > Singapore 119613 | WWW: http://homex.s1.net.sg/user/jyzhou/ > > --------------------------------------------------------------------- > > > From owner-ipsec@lists.tislabs.com Wed Jun 23 08:05:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16123; Wed, 23 Jun 1999 08:05:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13352 Wed, 23 Jun 1999 09:08:52 -0400 (EDT) Message-Id: <3.0.2.32.19990623084115.006c310c@csmes.ncsl.nist.gov> X-Sender: frankel@csmes.ncsl.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 23 Jun 1999 08:41:15 -0400 To: "Scott G. Kelly" From: Sheila Frankel Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long) Cc: ipsec@lists.tislabs.com In-Reply-To: <37701D59.9482E45D@redcreek.com> References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, One minor clarification: >> >2.30 UNEQUAL-PAYLOAD-LENGTHS >> > >> > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate >> > that message length in the ISAKMP header does not match the sum of >> > the actual payload lengths. >> >> This also applies in the case where the message length in the ISAKMP >> header >> does not match the length of the message that was actually received. >> It should >> probably also apply to other length-related anomalies. >> > >I don't understand the difference between the text and what you say >here. Please clarify. > The 2 cases that I think this message should cover are: 1) The message length in the ISAKMP header accurately reflects the total size of the received packet, but the sum of the individual payload lengths (in the Generic Payload Headers) does not match the total message length. (This often happens when a packet does not decrypt properly - IV problems, etc.) 2) The message length in the ISAKMP header does not match the size of the received packet. Sheila From owner-ipsec@lists.tislabs.com Wed Jun 23 08:50:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16631; Wed, 23 Jun 1999 08:50:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13484 Wed, 23 Jun 1999 09:39:59 -0400 (EDT) Message-Id: <3770E392.67462C0F@raleigh.ibm.com> Date: Wed, 23 Jun 1999 09:39:30 -0400 From: Phuong Nguyen Organization: IBM Research Triangle Park X-Mailer: Mozilla 4.08 [en] (X11; U; AIX 4.1) Mime-Version: 1.0 To: Jackie Wilson Cc: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906222144.QAA32886@jhwilson.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jackie Wilson wrote: > > The IBM products for their platforms (AIX, AS/400, OS/390) > support port numbers. The port numbers must be specified > in the configuration files. > Also, the IBM Nways routers (2210,2212,2216) support port numbers (exact, range, wild card) as well. Phuong > Jackie > Steven M. Bellovin wrote: > > Do any commercial IPSEC implementations use port numbers in their > > policy databases? The ones I've looked at this far seem to use only > > IP addresses. > > > > > > -- > Jacqueline Wilson | Phn: (512) 838-2702 > IBM, AIX/6000 | Fax: (512) 838-3509 > 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 > Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec@lists.tislabs.com Wed Jun 23 08:55:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16703; Wed, 23 Jun 1999 08:55:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13099 Wed, 23 Jun 1999 08:58:49 -0400 (EDT) From: ville.kukkola@nokia.com Message-ID: <3F5EA2C18BA4D21198C40008C7894C9007FDC2@oueis07nok> To: ipsec@lists.tislabs.com Subject: IPsec-implementations for Linux kernel 2.2.* Date: Wed, 23 Jun 1999 08:43:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Have you any knowledge of IPsec-implementations for Linux kernel 2.2.*? Yours sincerely, Ville Kukkola (Ville.Kukkola@nokia.com) From owner-ipsec@lists.tislabs.com Wed Jun 23 08:59:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16756; Wed, 23 Jun 1999 08:59:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13543 Wed, 23 Jun 1999 09:51:14 -0400 (EDT) From: "Catherine A. Meadows" Date: Wed, 23 Jun 1999 09:49:42 -0400 (EDT) Message-Id: <199906231349.JAA21235@liverwurst.fw5540.net> To: jyzhou@krdl.org.sg, dharkins@network-alchemy.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt Cc: ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jianying, Doug: I can see another reason for wanting to include SAr_b in the authenticating hash calculation. The ISAKMP RFC specifically leaves the definition of SA's open-ended, saying what must be included, but not limiting what can be included: The SA attributes required and recommended for the IP Security (AH, ESP) are defined in [SEC-ARCH]. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent security MUST define their requirements for SA attributes. The separation of ISAKMP from a specific SA definition is important to ensure ISAKMP can establish SAs for all possible security protocols and applications. Thus, even if we don't think a possible misunderstanding about key length is a serious enough threat to warrant authenticating SAr_b, if we don't include SAr_b in the authenticating hash calculation there is always the possibility that in the future the SA may contain some *other* security-relevant information that should be authenticated in the hash. Cathy Meadows From owner-ipsec@lists.tislabs.com Wed Jun 23 10:09:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17626; Wed, 23 Jun 1999 10:09:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13982 Wed, 23 Jun 1999 11:14:53 -0400 (EDT) Date: Wed, 23 Jun 1999 08:58:39 -0600 (MDT) From: Jason Poley To: ville.kukkola@nokia.com cc: ipsec@lists.tislabs.com Subject: Re: IPsec-implementations for Linux kernel 2.2.* In-Reply-To: <3F5EA2C18BA4D21198C40008C7894C9007FDC2@oueis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk rob glenns version is the only one that i am aware of... http://snad.ncsl.nist.gov/cerberus/ -jpoley On Wed, 23 Jun 1999 ville.kukkola@nokia.com wrote: > Hi, > > Have you any knowledge of IPsec-implementations for Linux > kernel 2.2.*? > > Yours sincerely, > > Ville Kukkola (Ville.Kukkola@nokia.com) > > > From owner-ipsec@lists.tislabs.com Wed Jun 23 10:15:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17707; Wed, 23 Jun 1999 10:15:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13901 Wed, 23 Jun 1999 11:08:56 -0400 (EDT) Date: Wed, 23 Jun 1999 11:07:46 -0400 (EDT) From: Henry Spencer To: ville.kukkola@nokia.com cc: ipsec@lists.tislabs.com Subject: Re: IPsec-implementations for Linux kernel 2.2.* In-Reply-To: <3F5EA2C18BA4D21198C40008C7894C9007FDC2@oueis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 23 Jun 1999 ville.kukkola@nokia.com wrote: > Have you any knowledge of IPsec-implementations for Linux > kernel 2.2.*? Linux FreeS/WAN now works with the 2.2.xx kernels, although this is quite new and it's possible there's still a bug or two. (Also, the changes have not made it into an actual release, only into our daily code snapshots, although that will change shortly.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Jun 23 10:23:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17824; Wed, 23 Jun 1999 10:23:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14120 Wed, 23 Jun 1999 11:35:04 -0400 (EDT) Message-ID: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> From: "Volpe, Victor" To: "'Dan McDonald'" , bkavsan@ire-ma.com Cc: skelly@redcreek.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: using por numbers in selectors Date: Wed, 23 Jun 1999 11:32:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Isn't there an issue with port number policy lookups and fragmented packets? Victor > -----Original Message----- > From: Dan McDonald [mailto:danmcd@Eng.Sun.Com] > Sent: Tuesday, June 22, 1999 6:46 PM > To: bkavsan@ire-ma.com > Cc: skelly@redcreek.com; dharkins@network-alchemy.com; > ipsec@lists.tislabs.com > Subject: Re: using por numbers in selectors > > > > I am talking about FTP ports (within TCP protocol, of course). > > FTP ports (typically) means port 21 and 20. But often it > also means 21 and > > some-other-dynamicaly-assigned port - what should be done > in this case for > > selectors? > > Wildcard the some-other-port bit, of course. > > > The whole issue of bringing port selectors into IPSec is a > big mistake to > > begin with (IMHO) - ports belong in the Transport Layer, not to IP > > layer. Bringing them into IPSec is a poor attempt to filter > traffic based > > on selectors that is better implemented by Transport Layers > security or > > firewalls. > > Do you write end-system code that extensively uses transport > mode IPsec at > all? I'll bet you don't, because if you did you'd totally > understand why > port selectors are there in the first place. > > Do you have customers asking you if you can secure their legacy apps > end-to-end with IPsec? I do. > > And yes, Solaris IPsec has port selectors and/or per-socket > IPsec policy. > > To answer Dan H's question about precedence, we parse in > order of rule-entry, > so it's up to the admin to decide how a question of conflict > gets answered. > > Dan McD. (the other Dan) > From owner-ipsec@lists.tislabs.com Wed Jun 23 11:26:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18638; Wed, 23 Jun 1999 11:25:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14299 Wed, 23 Jun 1999 12:11:47 -0400 (EDT) Message-ID: <37710758.A591EF81@redcreek.com> Date: Wed, 23 Jun 1999 09:12:08 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheila Frankel CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long) References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov> <3.0.2.32.19990623084115.006c310c@csmes.ncsl.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sheila Frankel wrote: > > Hi Scott, > > One minor clarification: > > >> >2.30 UNEQUAL-PAYLOAD-LENGTHS > >> > > >> > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate > >> > that message length in the ISAKMP header does not match the sum of > >> > the actual payload lengths. > >> > >> This also applies in the case where the message length in the ISAKMP > >> header > >> does not match the length of the message that was actually received. > >> It should > >> probably also apply to other length-related anomalies. > >> > > > >I don't understand the difference between the text and what you say > >here. Please clarify. > > > > The 2 cases that I think this message should cover are: > 1) The message length in the ISAKMP header accurately reflects the total > size of the received packet, but the sum of the individual payload lengths > (in the Generic Payload Headers) does not match the total message length. > (This often happens when a packet does not decrypt properly - IV problems, > etc.) > 2) The message length in the ISAKMP header does not match the size of the > received packet. > > Sheila I get it now - thanks. Scott From owner-ipsec@lists.tislabs.com Wed Jun 23 12:21:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19320; Wed, 23 Jun 1999 12:15:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14199 Wed, 23 Jun 1999 11:48:00 -0400 (EDT) Message-Id: <199906231547.IAA27600@potassium.network-alchemy.com> To: "Volpe, Victor" cc: "'Dan McDonald'" , bkavsan@ire-ma.com, skelly@redcreek.com, ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-reply-to: Your message of "Wed, 23 Jun 1999 11:32:41 EDT." <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27597.930152828.1@network-alchemy.com> Date: Wed, 23 Jun 1999 08:47:09 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For gateways, yes. If you've negotiated port/protocol granulatity for an IPSec SA and a packet gets fragmented prior to being IPSec protected then the other end will have to queue up enough of the decapsulated fragments to get the port/protocol and decide whether to forward it on to the ultimate end-system. Dan. On Wed, 23 Jun 1999 11:32:41 EDT you wrote > Isn't there an issue with port number policy lookups and fragmented packets? > > Victor > From owner-ipsec@lists.tislabs.com Wed Jun 23 12:28:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19432; Wed, 23 Jun 1999 12:27:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14613 Wed, 23 Jun 1999 12:50:47 -0400 (EDT) Date: Wed, 23 Jun 1999 12:50:15 -0400 Message-Id: <199906231650.MAA11334@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> <199906231547.IAA27600@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> For gateways, yes. If you've negotiated port/protocol Dan> granulatity for an IPSec SA and a packet gets fragmented prior Dan> to being IPSec protected then the other end will have to queue Dan> up enough of the decapsulated fragments to get the port/protocol Dan> and decide whether to forward it on to the ultimate end-system. It may not be able to do that, for example if the first fragment went a different route. Also, the problem applies equally well to end systems if using tunnel mode, since the (inner) reassembly occurs after the IPSEC processing. paul From owner-ipsec@lists.tislabs.com Wed Jun 23 12:54:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19678; Wed, 23 Jun 1999 12:54:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14753 Wed, 23 Jun 1999 13:04:38 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199906231650.MAA11334@tonga.xedia.com> References: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> <199906231547.IAA27600@potassium.network-alchemy.com> Date: Wed, 23 Jun 1999 13:02:06 -0400 To: Paul Koning From: Stephen Kent Subject: Re: using por numbers in selectors Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The architecture document notes explicitly that use of port fields as selectors as SGs may pose problems in case of fragmentation and advise caution as a result. The value "OPAQUE" is used in the SPD for selectors that may be unavailable due to fragmentation (or encryption), to help address this problem. Steve From owner-ipsec@lists.tislabs.com Wed Jun 23 13:04:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19741; Wed, 23 Jun 1999 13:01:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15078 Wed, 23 Jun 1999 13:36:32 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB8E6E5@exchange> From: Tim Jenkins To: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: RE: IPCP implementations Date: Wed, 23 Jun 1999 13:38:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To join the list of public declarations... TimeStep has supported IPCP for some time, and will be including it in a public release some time in the fall. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb+lists@research.att.com] > Sent: June 22, 1999 11:35 AM > To: ipsec@lists.tislabs.com > Subject: IPCP implementations > > > Who is shipping IPCP in their IPSEC implementations? > > From owner-ipsec@lists.tislabs.com Wed Jun 23 13:04:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19765; Wed, 23 Jun 1999 13:04:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14320 Wed, 23 Jun 1999 12:16:20 -0400 (EDT) Message-Id: <199906231615.JAA01946@gallium.network-alchemy.com> To: "Volpe, Victor" cc: "'Dan McDonald'" , bkavsan@ire-ma.com, skelly@redcreek.com, dharkins@Network-Alchemy.COM, ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-reply-to: Your message of "Wed, 23 Jun 1999 11:32:41 EDT." <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> Date: Wed, 23 Jun 1999 09:15:15 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not if you reassemble enough of the datagram to do the check properly. Derrell From owner-ipsec@lists.tislabs.com Wed Jun 23 13:10:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19793; Wed, 23 Jun 1999 13:05:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15174 Wed, 23 Jun 1999 13:44:59 -0400 (EDT) Message-Id: <199906231744.KAA02470@gallium.network-alchemy.com> To: Paul Koning cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-reply-to: Your message of "Wed, 23 Jun 1999 12:50:15 EDT." <199906231650.MAA11334@tonga.xedia.com> Date: Wed, 23 Jun 1999 10:44:02 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fine, the first fragment containing the upper-level protocol header may have gone a different route. However, if you let the rest of the fragments through as a result, I'd argue you have a security hole. Derrell From owner-ipsec@lists.tislabs.com Wed Jun 23 13:16:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19855; Wed, 23 Jun 1999 13:14:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15068 Wed, 23 Jun 1999 13:36:10 -0400 (EDT) From: Dan McDonald Message-Id: <199906231735.KAA05251@kebe.Eng.Sun.COM> Subject: Re: using por numbers in selectors To: vvolpe@altiga.com (Volpe, Victor) Date: Wed, 23 Jun 1999 10:35:31 -0700 (PDT) Cc: danmcd@Eng.Sun.Com, bkavsan@ire-ma.com, skelly@redcreek.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com In-Reply-To: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> from "Volpe, Victor" at Jun 23, 99 11:32:41 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Isn't there an issue with port number policy lookups and fragmented packets? Not on an end-system! Dan From owner-ipsec@lists.tislabs.com Wed Jun 23 14:18:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20271; Wed, 23 Jun 1999 14:18:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15682 Wed, 23 Jun 1999 14:58:29 -0400 (EDT) Date: Wed, 23 Jun 1999 14:57:58 -0400 Message-Id: <199906231857.OAA11435@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ddp@network-alchemy.com Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <199906231650.MAA11334@tonga.xedia.com> <199906231744.KAA02470@gallium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derrell" == Derrell D Piper writes: Derrell> Fine, the first fragment containing the upper-level protocol Derrell> header may have gone a different route. However, if you let Derrell> the rest of the fragments through as a result, I'd argue you Derrell> have a security hole. And if you block them, you have a black hole. You have a problem either way, just a different problem. I think the only real answer is: if you do port based stuff, make sure there is no fragmentation of the cleartext. Otherwise, the world will be flaky at best. paul From owner-ipsec@lists.tislabs.com Wed Jun 23 14:18:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20278; Wed, 23 Jun 1999 14:18:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15724 Wed, 23 Jun 1999 15:00:43 -0400 (EDT) Message-Id: <199906231859.SAA04544@orchard.arlington.ma.us> To: "Derrell D. Piper" cc: Paul Koning , dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-Reply-To: Message from "Derrell D. Piper" of "Wed, 23 Jun 1999 10:44:02 PDT." <199906231744.KAA02470@gallium.network-alchemy.com> Date: Wed, 23 Jun 1999 14:59:58 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Fine, the first fragment containing the upper-level protocol header may have > gone a different route. However, if you let the rest of the > fragments through as a result, I'd argue you have a security hole. I don't think this is a major issue. If you're allowing fragments through *at all*, and if you're allowing packets through based on transport protocol and port number, that implies a minimal level of trust in the end systems inside the firewall (to correctly implement reassembly, and to correctly implement services on the ports being let through). - Bill From owner-ipsec@lists.tislabs.com Wed Jun 23 14:19:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20288; Wed, 23 Jun 1999 14:19:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15692 Wed, 23 Jun 1999 14:59:38 -0400 (EDT) Date: Wed, 23 Jun 1999 14:59:16 -0400 Message-Id: <199906231859.OAA11439@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smb+lists@research.att.com, ipsec@lists.tislabs.com Subject: RE: IPCP implementations References: <319A1C5F94C8D11192DE00805FBBADDFB8E6E5@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Xedia supports IPCP. paul From owner-ipsec@lists.tislabs.com Wed Jun 23 14:45:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20493; Wed, 23 Jun 1999 14:45:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15866 Wed, 23 Jun 1999 15:18:32 -0400 (EDT) Date: Wed, 23 Jun 1999 15:18:09 -0400 Message-Id: <199906231918.PAA11483@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rcharlet@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors References: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> <199906231547.IAA27600@potassium.network-alchemy.com> <199906231650.MAA11334@tonga.xedia.com> <3771246F.A72272CB@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ricky" == Ricky Charlet writes: Ricky> We implementors also have an interoperability issue to solve, Ricky> should we force intermediate reassembly (in order to look at Ricky> ports) on the ingress or egress end of the tunnel (or both)? Neither. This is just not a reasonable thing to do in high performance devices. As I pointed out, it's not a solution anyway, because intermediate nodes can't reliably do reassembly, ever. Note also that the problem is fixed in IPv6... :-) paul From owner-ipsec@lists.tislabs.com Wed Jun 23 14:48:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20519; Wed, 23 Jun 1999 14:48:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15812 Wed, 23 Jun 1999 15:11:35 -0400 (EDT) Message-ID: <3771246F.A72272CB@redcreek.com> Date: Wed, 23 Jun 1999 18:16:15 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning , ipsec Subject: Re: using por numbers in selectors References: <71B30BC67510D31184030090277A3DDE13852F@mail.altiga.com> <199906231547.IAA27600@potassium.network-alchemy.com> <199906231650.MAA11334@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Dan" == Dan Harkins writes: > > Dan> For gateways, yes. If you've negotiated port/protocol > Dan> granulatity for an IPSec SA and a packet gets fragmented prior > Dan> to being IPSec protected then the other end will have to queue > Dan> up enough of the decapsulated fragments to get the port/protocol > Dan> and decide whether to forward it on to the ultimate end-system. > > It may not be able to do that, for example if the first fragment went > a different route. Also, the problem applies equally well to end > systems if using tunnel mode, since the (inner) reassembly occurs > after the IPSEC processing. > > paul Howdy () There is no workaround. Administrators must choose between filtering on ports AND knowing that their fragments MUST pass through the same SGW or not filtering on ports and not sweating which path a fragment takes. We implementors also have an interoperability issue to solve, should we force intermediate reassembly (in order to look at ports) on the ingress or egress end of the tunnel (or both)? An inplementor who choses to force re-assembly on the egress end or both ends of the tunnel would not have concerns about interoperability. But it seems MUCH easier to me to do the intermediate reassembly on the ingress end of the tunnel and in my wonderful imaginary world, we could all agree to do it this way. What do you all think? -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Wed Jun 23 15:15:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20799; Wed, 23 Jun 1999 15:15:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16583 Wed, 23 Jun 1999 16:19:09 -0400 (EDT) Message-ID: <377140A6.EB816306@juggernautics.com> Date: Wed, 23 Jun 1999 16:16:38 -0400 From: Joel Odom Organization: Juggernautics, LLC X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPsec Toolkits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have a customer developing an IPsec product and we are currently evaluating toolkits and implementations of IPsec. Our target platforms are Windows and UNIX. Could I have some recommendations of toolkits that may be on the market? It may be advisa ble to contact me directly to avoid clutter on the mailing list. Thanks! Joel Odom P.S. If anybody knows some good system level programmers, please send them my way! -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Wed Jun 23 15:35:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20983; Wed, 23 Jun 1999 15:35:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16735 Wed, 23 Jun 1999 16:46:16 -0400 (EDT) Message-ID: <37714770.B58C8DCA@raptor.com> Date: Wed, 23 Jun 1999 16:45:36 -0400 From: Rafal Boni Organization: Raptor Systems Engineering X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: another public IPCP declaration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Axent's Raptor Firewall and Mobile client will also do IPCP in the next release. Like everyone else's next release, we expect it out in the fall. 8-) --rafal -- Rafal Boni rafal@raptor.com Raptor Systems, Waltham, MA http://www.raptor.com/ 781.530.2200 From owner-ipsec@lists.tislabs.com Wed Jun 23 15:56:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21193; Wed, 23 Jun 1999 15:56:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16990 Wed, 23 Jun 1999 17:26:40 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: smb+lists@research.att.com, ipsec@lists.tislabs.com Subject: RE: IPCP implementations Date: Wed, 23 Jun 1999 14:25:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk VPNet supports IPCP (currently supports only LZS). -- sankar ramamoorthi (sankar@vpnet.com) -- From owner-ipsec@lists.tislabs.com Wed Jun 23 17:13:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21984; Wed, 23 Jun 1999 17:13:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17319 Wed, 23 Jun 1999 18:33:48 -0400 (EDT) Date: Thu, 24 Jun 1999 01:33:19 +0300 (EET DST) Message-Id: <199906232233.BAA27621@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jianying Zhou Cc: ipsec@lists.tislabs.com Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt In-Reply-To: References: <199906230004.DAA19742@torni.ssh.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 12 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jianying Zhou writes: > > Now even if both of them support 3des, attacker can modify the > > proposal sent by the initiator and remove 3des from the proposal. > > Responder doesn't notice anything and it will just select the des that > > was included in the proposal (it just assumes the other end is one of > > those old implementations only supporting des). Initiator will not > > detect anything it will just assume the responder is only supporting > > des. This is not what was really wanted... > I agree. But anyway, both ends get the authenticated SA at the end of > Phase 1 negotiation. With weaker (but allowed) cipher than was requested. I think this is much bigger attack than ability to change life times. > Yes, the change of SA lifetime cannnot be detected in an attack. > How will a delete notification be sent out if either side does not > detect the attack? The site which did get lower lifetime, will send delete notification to the other end, and that end will delete the SA at the same time. > Suppose the initiator's SA has a longer lifetime than the responder's > SA. Suppose the keys have compromised after the responder's SA expires > but before the initiator's SA expires. An attacker can masquerade as the > responder in a communication session. If the attacker can break keys during any lifetime proposed by the initiator, initiator has security problems anyways. I don't really think this will be real problem. > A more secure solution is to include both SAi_b and SAr_b in HASH_I > and HASH_R. That would be one way to fix this problem. Anyways I don't think this is serious enough problem to modify IKE 1.0 protocol now. We can fix this and other problems later when we start thinking about next version of IKE. BTW, this (and other problems) have been pointed out by me in the ipsec-list earlier (Message-Id: <199809062326.CAA29797@torni.ssh.fi>), and that mail was sent to the key people of the ipsec working group at 9th of April 1998. The security problems described in that email waren't serious enough to delay IKE 1.0 at time, and I don't think they are any more serious now. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 23 18:45:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA23291; Wed, 23 Jun 1999 18:45:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17604 Wed, 23 Jun 1999 19:56:20 -0400 (EDT) Message-ID: From: Matt Field To: "'ipsec@lists.tislabs.com'" Subject: redundancy Date: Thu, 24 Jun 1999 09:58:20 +1000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anyone illustrate if and how ipsec could handle multiple ipsec gateways to a single network. I have come accross the following scenario: ----------------------------------------- Network 1 | | D -------------- | | | | A B | | | | \ / \ / \ / C | ----------------------------------------- Network 2 Network 1 has D which is a Front End Processor (FEP) that performs some kind of load balancing that may route packets either through ipsec gateways A or B. C is an ipsec gateway on a remote network. The problem is, if tunnels are created beween gateways A-C and B-C, then when C receives a packet from Network 2 for network 1, how does determine which SA to use since the destination address is behind both gateways? My guess is that this is an implementation detail and outside the scope of IPSEC but any thoughts on this would be useful. regards, Matt Field From owner-ipsec@lists.tislabs.com Wed Jun 23 19:22:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA27390; Wed, 23 Jun 1999 19:22:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17765 Wed, 23 Jun 1999 20:43:45 -0400 (EDT) Message-Id: <199906240043.UAA08112@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: using por numbers in selectors In-Reply-To: Your message of "Wed, 23 Jun 1999 12:50:15 EDT." <199906231650.MAA11334@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Jun 1999 20:43:14 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: >>>>> "Dan" == Dan Harkins writes: Dan> For gateways, yes. If you've negotiated port/protocol granulatity Dan> for an IPSec SA and a packet gets fragmented prior to being IPSec Dan> protected then the other end will have to queue up enough of the Dan> decapsulated fragments to get the port/protocol and decide whether Dan> to forward it on to the ultimate end-system. Paul> It may not be able to do that, for example if the first fragment Paul> went a different route. Also, the problem applies equally well to Paul> end systems if using tunnel mode, since the (inner) reassembly Paul> occurs after the IPSEC processing. This is only relevant for a gateway system. It has no relevance to end systems. IPsec is one way to build a VPN. IPsec is NOT just VPNs. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Thu Jun 24 02:23:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27312; Thu, 24 Jun 1999 02:23:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18635 Thu, 24 Jun 1999 03:05:01 -0400 (EDT) Message-ID: <3771D8E7.A00F7105@checkpoint.com> Date: Thu, 24 Jun 1999 10:06:15 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt References: <319A1C5F94C8D11192DE00805FBBADDFB67D77@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Consider a theoretical scenario in which an attacker filters out some of the IKE packets passed between Alice and Bob. Assume that alice and Bob negotiated an IKE SA that is supposed to be restricted to 16K of encrypted data. Alice and Bob sent 10K of IKE encrypted packets each but only 5K got to the other side. The attacker has now 20K of encrypted data which could (again theoretically) allow him to mount an attack. Stephane Beaulieu wrote: > What's wrong with one peer thinking that it's IKE SA is used up before the > other peer does? If one peer notices that an IKE SA is about to expire, he > should establish a new one and send a DELETE for the old one. > > peer can use the same the amount of data get out of sync of data they encrypted. This can lead thinks that the IKE SA has been out used while the other side still valid. >