From salga@bell-labs.com Tue Oct 1 14:59:06 2002 From: salga@bell-labs.com (Luca Salgarelli) Date: 01 Oct 2002 09:59:06 -0400 Subject: [eap] Re: EAP methods, EAP charter, the marketplace and the IETF In-Reply-To: References: Message-ID: <1033480746.31549.8.camel@valjean> On Mon, 2002-09-30 at 16:16, Bernard Aboba wrote: > > The main concern is that if the IETF (or the EAP WG in particular) > > is going to evaluate EAP methods, it should presumably know beforehand > > what to evaluate them against. > > Specifically, the IANA considerations section of RFC 2284bis will trigger > a new procedure for allocation of EAP types, with a spec and some kind of > Expert Review required prior to allocation. > > RFC 2248bis does lay out guidelines by which the Expert Review might be > conducted. But that isn't the same things as describing guidelines for > standardization, which seems to be what Luca is suggesting is needed. Right. I would actually reinforce that: my opinion is that we need both guidelines for standardization *and* a working Expert Review process right now. I think the WG should start working right now, in parallel to the RFC2248bis effort, on a document that can be used as a basis for evaluating EAP methods. I am not sure that RFC2248bis alone can be such document. Luca From aboba@internaut.com Wed Oct 2 18:48:10 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 2 Oct 2002 10:48:10 -0700 (PDT) Subject: [eap] Re: EAP methods, EAP charter, the marketplace and the IETF In-Reply-To: <1033480746.31549.8.camel@valjean> Message-ID: > Right. I would actually reinforce that: my opinion is that we need both > guidelines for standardization *and* a working Expert Review process > right now. The "Expert Review" process comes into effect when the IANA considerations document goes to RFC. There has been discussion of separating out the IANA considerations into a separate document, so that it could progress separately (and presumably, sooner). The disadvantage is that the EAP WG mailing list will then need to handle the "Expert Review" -- and a concern has been raised about the workload this could entail. From aboba@internaut.com Wed Oct 2 20:22:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT) Subject: [eap] Notification survey Message-ID: In the EAP Design team meeting today, we discussed the use of EAP Notification. The question arose as to what people are using this for today, and why. If you have implemented EAP Notification in your method (or your EAP implementation), can you let us know: a. Whether you are using Notification as part of the method (e.g. Notification Request is delivered to the method) b. Whether you allow Notification to be sent at any time (in the middle of a method exchange) c. Whether Notification results in a state change within the EAP state machine or not d. Whether you would be affected if EAP Notification were to be eliminated or deprecated, and why this would be bad (or good) From Jacques.Caron@IPsector.com Wed Oct 2 22:02:10 2002 From: Jacques.Caron@IPsector.com (Jacques Caron) Date: Wed, 02 Oct 2002 23:02:10 +0200 Subject: [eap] Notification survey In-Reply-To: Message-ID: <5.1.1.6.0.20021002224207.039d8b80@pop.mail.yahoo.com> Hi, I don't use it (yet), but: a. I definitely believe a method on the client side shouldn't expect any such messages (there should be a generic method handler for it that will just display the message to the user - a bit like there should be a generic identity method handler that just returns the identity). b. It should be possible to possible to send this nearly at any time: - there should be only one outstanding request (i.e. not possible to send a Notification request just after some other method request before the response came back) - at the very least it should be possible to use it between two requests from different methods, not necessarily in the middle of the exchanges of one given method. c. Receiving a Notification request should prompt a Notification response, and then return to the same state. If the message is displayed via some kind of alert/dialog box (that requires user action), the question of whether the response is sent immediately or once the user acknowledges the dialog box remains open (in that last case there would be an intermediate state, I guess). d. I believe it's useful to be able to send clear-text messages to the client, in the following (non-exhaustive list of) cases: - an authentication method failed, and the method wants to give the user more information about why - a method (maybe not an authentication one, more an authorization one) got a NAK back, and the method wants to tell something to the user anyway (e.g. connection cost) Of course the problem of the authenticity of the message is present, but that's a more general problem of EAP messages... An important point is that one should just not consider that the message will actually be seen and/or interpreted by anyone, it's purely informative. Just my 0.02 EUR. Jacques. At 21:22 02/10/2002, Bernard Aboba wrote: >In the EAP Design team meeting today, we discussed the use of EAP >Notification. The question arose as to what people are using this for >today, and why. If you have implemented EAP Notification in your method >(or your EAP implementation), can you let us know: > >a. Whether you are using Notification as part of the method (e.g. >Notification Request is delivered to the method) > >b. Whether you allow Notification to be sent at any time (in the middle of >a method exchange) > >c. Whether Notification results in a state change within the EAP state >machine or not > >d. Whether you would be affected if EAP Notification were to be eliminated >or deprecated, and why this would be bad (or good) > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap -- Jacques Caron, IP Sector Technologies Join the discussion on public WLAN open global roaming: http://lists.ipsector.com/listinfo/openroaming From preetida.vinayakray-jani@nokia.com Thu Oct 3 11:00:01 2002 From: preetida.vinayakray-jani@nokia.com (Preeti Vinayakray) Date: Thu, 03 Oct 2002 13:00:01 +0300 Subject: [eap] Notification survey References: Message-ID: <3D9C1521.5611BE38@nokia.com> Hello: Following ans. relevant to my EAP implementation ext Bernard Aboba wrote: > In the EAP Design team meeting today, we discussed the use of EAP > Notification. The question arose as to what people are using this for > today, and why. If you have implemented EAP Notification in your method > (or your EAP implementation), can you let us know: > > a. Whether you are using Notification as part of the method (e.g. > Notification Request is delivered to the method) > Yes, it is used as a part of the method > > b. Whether you allow Notification to be sent at any time (in the middle of > a method exchange) > No, > > c. Whether Notification results in a state change within the EAP state > machine or not > No > > d. Whether you would be affected if EAP Notification were to be eliminated > or deprecated, and why this would be bad (or good) > This very much depends on how implementation is done. In terms of my implementation I consider it is 'good 'as a part of methods I have supported, But it does not change any state info for client/peer. It just provides some line display. So elemination of this not going to affect. -Preeti > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Oct 3 17:54:36 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 3 Oct 2002 09:54:36 -0700 (PDT) Subject: [eap] RE: Notification survey Message-ID: For what it's worth, here are some details on how Windows implements Notification: - EAP-Notification is out-of-band. The EAP layer automatically sends a Notification Response; the Notification Request is not passed to the currently running method. - EAP-Notification can be sent at any time. There are no checks done when the EAP-Notification arrives. - Since EAP-Notification is not passed to the method, it does not result in a state change. - EAP Notification does not have support for internationalization. The lack of language support means that there is no easy way to display a message to the user in a language that they can be guaranteed to understand. - EAP-Notification does not result in a display to the user at present. From simon@instant802.com Thu Oct 3 19:01:57 2002 From: simon@instant802.com (Simon Barber) Date: Thu, 3 Oct 2002 11:01:57 -0700 Subject: [eap] RE: Notification survey In-Reply-To: Message-ID: <00e501c26b06$f70a2c10$2103a8c0@simonlaptop> Internationalization should not be an issue, since the user's location can be derived by other means, as long as the character set for messages is not restricted. Once Notification is displayed will there be an issue with EAP-spam? EAP-Notification social engineering hacks? Simon -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Bernard Aboba Sent: Thursday, October 03, 2002 9:55 AM To: eap@frascone.com Subject: [eap] RE: Notification survey For what it's worth, here are some details on how Windows implements Notification: - EAP-Notification is out-of-band. The EAP layer automatically sends a Notification Response; the Notification Request is not passed to the currently running method. - EAP-Notification can be sent at any time. There are no checks done when the EAP-Notification arrives. - Since EAP-Notification is not passed to the method, it does not result in a state change. - EAP Notification does not have support for internationalization. The lack of language support means that there is no easy way to display a message to the user in a language that they can be guaranteed to understand. - EAP-Notification does not result in a display to the user at present. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Oct 3 18:04:19 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 3 Oct 2002 10:04:19 -0700 (PDT) Subject: [eap] RE: Notification survey In-Reply-To: <00e501c26b06$f70a2c10$2103a8c0@simonlaptop> Message-ID: Language is not the same as location. Just because I'm located in Paris, France doesn't mean I want my Notifications sent in French, n'est pas? On Thu, 3 Oct 2002, Simon Barber wrote: > Internationalization should not be an issue, since the user's location > can be derived by other means, as long as the character set for messages > is not restricted. > > Once Notification is displayed will there be an issue with EAP-spam? > EAP-Notification social engineering hacks? > From Jacques.Caron@IPsector.com Fri Oct 4 10:28:50 2002 From: Jacques.Caron@IPsector.com (Jacques Caron) Date: Fri, 04 Oct 2002 11:28:50 +0200 Subject: [eap] RE: Notification survey Message-ID: <5.1.1.6.0.20021004112846.00b31e50@pop.mail.yahoo.com> At 20:01 03/10/2002, Simon Barber wrote: >Internationalization should not be an issue, since the user's location >can be derived by other means, as long as the character set for messages >is not restricted. User location and user language are two quite different issues I believe, especially in a roaming context. But I guess once we have the identity, then it should be possible to store on the auth server the language to be used. However some way of stating the character set used would not necessarily be a bad idea. >Once Notification is displayed will there be an issue with EAP-spam? >EAP-Notification social engineering hacks? That's the issue I hinted at when I talked about authentication of these messages. The problem is that in some cases legitimate messages might need to be sent before mutual authentication can be established :-( Jacques. -- Jacques Caron, IP Sector Technologies Join the discussion on public WLAN open global roaming: http://lists.ipsector.com/listinfo/openroaming From aboba@internaut.com Fri Oct 4 12:35:21 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Oct 2002 04:35:21 -0700 (PDT) Subject: [eap] Minutes of the 10/2/02 EAP Design team Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --641753990-1507428132-1033731321=:9813 Content-Type: TEXT/PLAIN; charset=US-ASCII --641753990-1507428132-1033731321=:9813 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="minutes-10-2.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="minutes-10-2.txt" TWludXRlcyBFQVAgU3RhdGUgTWFjaGluZSBEZXNpZ24gVGVhbQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF0ZTogMTAvMi8y MDAyIDExYW0tMTI6MTUgRURUIA0KDQpUaGlzIHdlZWsncyBtZWV0aW5nIGNv bXBsZXRlZCBkaXNjdXNzaW9uIG9mIA0KWW9zaGloaXJvIE9oYmEncyAoeW9o YmFAdGFyaS50b3NoaWJhLmNvbSkgcG9zaXRpb24gcGFwZXIgb24gDQp0aGUg RUFQIHN0YXRlIG1hY2hpbmUgZHJhZnQgKHRvcGljIGIpLg0KDQogKiBsYXN0 IHdlZWsgd2UgZGlzY3Vzc2VkIGlzc3VlcyAxLDIsMywgdGhpcyB3ZWVrIGJl Z2luIHdpdGggaXNzdWUgNA0KDQogKiBJc3N1ZSA0OiBTdXBwb3J0IGZvciBt dWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIGEgc2luZ2xlIHNl c3Npb24NCg0KICAgWW9zaGloaXJvJ3MgUG9zaXRpb246IFdlIHNob3VsZCBk ZWZpbmUgcG9saWN5IHBhcmFtZXRlcnMgY29tbW9uIHRvIGFsbA0KICAgRUFQ IG1ldGhvZHMgdGhhdCBwcm92aWRlIGZvciBtdWx0aXBsZSBhdXRoZW50aWNh dGlvbiBtZXRob2RzLg0KICANCiAgIERpc2N1c3Npb246IHRoZSBjb252ZXJz YXRpb24gcmFuZ2VkIG92ZXIgYSB2YXJpZXR5IG9mIHN1YmplY3RzDQogICBy ZWxhdGluZyB0byB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBtdWx0aXBsZSBt ZXRob2RzLCB3aGVuDQogICBub3RpZmljYXRpb25zIHNob3VsZCBiZSBhbGxv d2VkLCB0aGUgbmF0dXJlIG9mIHNwZWNpYWwgInByb3RlY3RlZCINCiAgIG1l dGhvZHMsIHByb3RlY3RlZCBzdWNjZXNzIGFuZCBmYWlsdXJlIG1lc3NhZ2Vz LCBhbmQgd2hlbiBzdWNjZXNzDQogICBhbmQgZmFpbHVyZSBhcmUgdmFsaWQu IA0KICANCiAgIFNvbWUga2V5IHBvaW50cyBmcm9tIHRoZSBkaXNjdXNzaW9u Og0KICAgICAtLSBTb21lIG1ldGhvZHMgcnVuIGFzIGEgcHJvdGVjdGlvbiBv ZiBvdGhlciBtZXRob2RzLiBUaGVzZQ0KICAgICAgICBtZXRob2RzIGFwcGVh ciB0byB0aGUgTVVYIGFzIGEgc2luZ2xlIG1ldGhvZCwgYnV0IG1heSBoYXZl DQogICAgICAgIHNwZWNpYWwgcmVxdWlyZW1lbnRzIHN1Y2ggYXMgYmVpbmcg dGhlIGxhc3QgbWV0aG9kIHJ1biBhbmQgDQogICAgICAgIGRpc3JlZ2FyZGlu ZyBBTEwgdW5wcm90ZWN0ZWQgbWVzc2FnZXMsIGluY2x1ZGluZw0KICAgICAg ICBOb3RpZmljYXRpb25zLiBUaGUgZGlzY3Vzc2lvbiB0aHVzIHR1cm5lZCB0 byB3aGVuDQogICAgICAgIG5vdGlmaWNhdGlvbnMgc2hvdWxkIGJlIGFsbG93 ZWQgYW5kIHdoZXRoZXIgbWV0aG9kcyBhcmUNCiAgICAgICAgY3VycmVudGx5 IHVzaW5nIG5vdGlmaWNhdGlvbnMgb3Igd2hldGhlciB0aGVzZSBhcmUgbWVz c2FnZXMNCiAgICAgICAgdGhhdCBzaG91bGQgYmUgaGFuZGxlZCBhdCB0aGUg TVVYIGxheWVyLiBUaGUgZGVjaXNpb24gd2FzIG1hZGUNCiAgICAgICAgdG8g c2VwYXJhdGUgdGhlc2UgaXNzdWVzIGZyb20gdGhlIGN1cnJlbnQgZGlzY3Vz c2lvbi4NCg0KICAgICAgICAgKiBBIHN1cnZleSB3b3VsZCBiZSBzZW50IHRv IHRoZSBFQVAgbGlzdCB0byBkZXRlcm1pbmUgY3VycmVudA0KICAgICAgICAg ICB1c2FnZSBvZiBub3RpZmljYXRpb24gbWVzc2FnZXMNCg0KICAgICAgICAg KiBQb3NpdGlvbiBwYXBlcnMgd291bGQgYmUgYWNjZXB0ZWQgb24gd2hldGhl ciBvciBub3QgYQ0KICAgICAgICAgICBtZXRob2Qgc2hvdWxkIGJlIGltcGxl bWVudGFibGUgc3VjaCB0aGF0IGl0IGlzIG9ubHkgdGhlDQogICAgICAgICAg bGFzdCBtZXRob2QgYW5kLCBpZiBzbywgaG93IHRoYXQgbWV0aG9kIGludGVy YWN0cyB3aXRoIHRoZQ0KICAgICAgICAgIE1VWC4gU29tZSBmZWx0IHRoYXQg aXQgc2hvdWxkIGJlIGxlZnQgdG8gcG9saWN5IHRvIGRpc2FsbG93DQogICAg ICAgICAgIG90aGVyIG1ldGhvZHMgYWZ0ZXIgbWV0aG9kcyBsaWtlIFBFQVAg YW5kIG5vdCB0aGUgbWV0aG9kIGl0c2VsZi4NCg0KICAgICAtLSBUaGUgZ3Jv dXAgZGlzY3Vzc2VkIHRoZSBuYXR1cmUgb2YgbWV0aG9kLXNwZWNpZmljIHN1 Y2Nlc3MgYW5kDQogICAgICAgIGZhaWx1cmUgYW5kIGhvdyB0aGV5IGludGVy YWN0IHdpdGggRUFQIHN1Y2Nlc3MvZmFpbHVyZS4NCiANCiAgICAgLS0gVGhl IGdyb3VwIGRpc2N1c3NlZCBhbmQgYWdyZWVkIHRoYXQgU3VjY2VzcyBtZXNz YWdlcyBzaG91bGQNCiAgICAgICAgb25seSBiZSBzZW50IGF0IHRoZSBlbmQg b2YgYSBzZXF1ZW5jZSBhbmQgbm90IGFmdGVyIGVhY2gNCiAgICAgICAgaW5k aXZpZHVhbCBtZXRob2Qgc3VjY2VlZHMuIFRoaXMgaW1wbGllcyB0aGF0IGl0 IGlzIHRoZSBNVVggd2hvDQogICAgICAgIGNvbnRyb2xzIHNlbmRpbmcgc3Vj Y2VzcyBtZXNzYWdlcy4gVGhpcyBpc3N1ZSBpcyByZXZpc2l0ZWQgaW4NCiAg ICAgICAgaXNzdWUgNSBiZWxvdy4NCiANCiAgICAgLS0gVGhlIGdyb3VwIGRp c2N1c3NlZCB0aGUgcm9sZSBvZiBwb2xpY3kgaW4gZGVjaWRpbmcgbWV0aG9k DQogICAgICAgIG9yZGVyIGFuZCBjb25jbHVkZWQgdGhhdCBwb2xpY3kgY2Fu IGJlIHJlc3BvbnNpYmxlIGZvcg0KICAgICAgICBzcGVjaWZ5aW5nIG1ldGhv ZCBvcmRlciwgYnV0IHRoYXQgYSBkZWZhdWx0IHBlZXIgcG9saWN5IHNob3Vs ZCBiZQ0KICAgICAgICBkZWZpbmVkIHRoYXQgcHJvdmlkZXMgZm9yIHRoZSBh bGxvd2VkIG1ldGhvZHMgdG8gYmUNCiAgICAgICAgYWNjZXB0ZWQgaW4gYW55 IG9yZGVyLiBUaGVyZSB3YXMgYWRkaXRpb25hbCBkaXNjdXNzaW9uIG9uDQog ICAgICAgIHRoZSBpbXBsaWNhdGlvbnMgb2YgcGVlciBhbmQgYXV0aGVudGlj YXRvciBkaXNhZ3JlZWluZyBhYm91dA0KICAgICAgICBvcmRlciBzaW5jZSB0 aGVyZSBpcyBubyBzeW5jaHJvbml6ZWQgc2NoZW1hIGJldHdlZW4gdGhlIHR3 by4NCiAgIA0KICANCiAqIElzc3VlIDU6IFBhc3MtdGhyb3VnaCBFQVAgYXV0 aGVudGljYXRvciBzdGF0ZSBtYWNoaW5lDQoNCiAgIFlvc2hpaGlybydzIHBv c2l0aW9uOiBTaG91bGQgZGVmaW5lIHNwZWNpYWwgc3RhdGUgbWFjaGluZSBm b3INCiAgICAgcGFzcy10aHJvdWdoIA0KDQogICBEaXNjdXNzaW9uOiBUaGUg Y29udmVyc2F0aW9uIGxlYWQgcHJpbWFyaWx5IGRvd24gdHdvIHBhdGhzLSAN CiAgICgxKSB0aGUgZGlmZmVyZW5jZXMgaW4gMXggYW5kIFBQUCB3aXRoIHJl c3BlY3QgdG8gbGFzdCBtZXNzYWdlDQogICBkZWxpdmVyeSBhbmQgdGhlIG5l Y2Vzc2l0eSB0byBnZW5lcmFsaXplIGZvciBtZWRpYQ0KICAgaW5kZXBlbmRl bmNlLiBBdCB0aGlzIHBvaW50IHRoZSBzZW5kaW5nIG9mIGEgc3VjY2VzcyBt ZXNzYWdlIGJ5IHRoZQ0KICAgTVVYIHdhcyByZXZpc2l0ZWQgY29uc2lkZXJp bmcgYm90aCB0aGUgMXggYW5kIFBQUCBjYXNlDQoNCiAgICgyKSB0aGUgbmF0 dXJlIG9mIElkZW50aXR5IG1lc3NhZ2VzIGluY2x1ZGluZyB0aGUgYWJpbGl0 eSBmb3INCiAgIGVpdGhlciBBdXRoZW50aWNhdG9yIG9yIEF1dGggU2VydmVy IHRvIHJlcXVlc3QgSUQsIHRoZSBwb3NzaWJpbGl0eQ0KICAgZm9yIGRpZmZl cmVudCBhdXRoIHNlcnZlcnMgdG8gYmUgdXNlZCBkZXBlbmRpbmcgb24gdGhl IElEIHJlc3BvbnNlLA0KICAgYW5kIHRoZSBhdXRoZW50aWNhdG9yJ3MgZGVz aXJlIHRvIGFsd2F5cyBrbm93IGF1dGggcmVwbGllcyBmb3INCiAgIGFjY291 bnRpbmcvYXVkaXQgcHVycG9zZXMuIA0KDQogICBBZGRpdGlvbmFsIGRpc2N1 c3Npb24gYnJvdWdodCB1cCB0aGF0IGEgbnVtYmVyIG9mIG5ldyBtZWRpdW1z IGFyZQ0KICAgYmVpbmcgZGlzY3Vzc2VkLCB0aGVyZWJ5IGlsbHVzdHJhdGlu ZyB0aGUgbmVlZCBmb3IgYSBzaW5nbGUgdW5pZmllZA0KICAgcHJvdG9jb2wg ZGVmaW5pdGlvbiANCg0KDQpOZXh0IHdlZWsgd2lsbCBjb250aW51ZSB3aXRo IHRoZSByZW1haW5pbmcgaXRlbSBiIHBvc2l0aW9uIHBhcGVycy4NCg== --641753990-1507428132-1033731321=:9813-- From aboba@internaut.com Fri Oct 4 12:37:02 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Oct 2002 04:37:02 -0700 (PDT) Subject: [eap] Position paper on completeness Message-ID: EAP State Machine Completeness Position Paper, Oct 1, 2002 Jari Arkko, Ericsson Research NomadicLab 1. INTRODUCTION The completeness of the state machine from draft-payne-eap-sm-00.txt was analyzed. By completeness, we mean that the state machine contains a description of what to do for all possible events in all states. Note that in some cases we may well ignore an event, but this should be done on purpose and we should document it clearly. If not, we often tend to forget some events that should have been handled with something else than silent discard. We have already debated a number of issues which are specific examples of the current underspecification that the original RFCs as well as the state machine proposals have, such as when can NAKs come. 2. EVENTS The events that can come to a peer are: - ID Request - Method Request (many types and subtypes) - Notification - Success - Failure - Protocol error (i.e. anything else, such as a NAK sent to the client -- this could be debatable whether we need to deal with this. But some protocols make a state transition e.g. close connection upon getting these.) The events that can come to an authenticator are: - ID response - Methods response - Notification ack - NAK - Protocol error 3. PEER STATE MACHINE Some states in this state machine are just temporary transitions, such as the peer identification state, where we simply respond with an identity response and return back to unauthenticated state: - Initialized - Peer identification - Invalid request - Authenticated The states on which some waiting of events occur are as follows: - Unauthenticated - Method state machine We will study these two states in detail. We note that the Unauthenticated state does not handle the Failure, Notification, or protocol error events. The method state machine state does not handle Identity request, Method request (perhaps this is thought to be on a lower level at the specific method state machine), Notification, and protocol error events. 3. AUTHENTICATOR STATE MACHINE Again, the states which aren't real states in the usual definition of the term are: - Initialization - Failure - Authenticated The real states which we will study are: - Unauthenticated - Peer identification - Method state machine The Unauthenticated state does not handle Notification Response, NAK, and protocol error events (we suspect the right action in these cases would be silent discard). The Peer identification state does not handle Method response, NAK, Notification, or protocol error events. Note that we have already discussed the situation where NAK might be used to signal that we don't want to give an identity. The Method state machine state does not handle Notification response, Identity response, or protocol error events. It also doesn't really handle Method response event, but again we suspect this was expected to be done at the lower layer, in the specific method state machine. 4. FURTHER WORK It is necessary to ensure that the state machines are complete and we have knowingly decided to ignore the events that currently are ignored. We have already begun to debate some of the individual issues around this, such as when can NAKs come. In the above analysis, we have not yet taken a final stand on whether the right action in some of these cases is something else than silent discard. If the right action is silent discard, then everything is currently OK. It is also necessary to take a similar look at the 802.1aa D3 state machines. From james.d.carlson@east.sun.com Fri Oct 4 18:52:48 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 4 Oct 2002 13:52:48 -0400 Subject: [eap] Notification survey In-Reply-To: Bernard Aboba's message of 2 October 2002 12:22:42 References: Message-ID: <15773.54640.995314.725448@gargle.gargle.HOWL> Bernard Aboba writes: > In the EAP Design team meeting today, we discussed the use of EAP > Notification. The question arose as to what people are using this for > today, and why. If you have implemented EAP Notification in your method > (or your EAP implementation), can you let us know: I have this implementation: ftp://playground.sun.com/pub/eap/index.html and I'm working on updating it and integrating it into 'pppd' (since I'm now one of the maintainers of that software) for the next release. > a. Whether you are using Notification as part of the method (e.g. > Notification Request is delivered to the method) No, it's not part of the method. > b. Whether you allow Notification to be sent at any time (in the middle of > a method exchange) Sure. > c. Whether Notification results in a state change within the EAP state > machine or not No. Nothing in the RFC describes it being used that way ... > d. Whether you would be affected if EAP Notification were to be eliminated > or deprecated, and why this would be bad (or good) I wouldn't be affected. I never send them, and I just log them if received (and of course send ack). I don't think it would be good to remove this message. I like having a "I think this is interesting for you to log" message for debug and deployment reasons. If, however, we fixed 'Success' and 'Failure' to be able to include a debug text message (as I think they ought to have from the start), then I'd be somewhat happier with losing Notification. (Not perfect, but good enough.) (I also think that the possible i18n concerns and the spamming concerns are misplaced -- the receiver can do anything it likes with these, including discarding the text.) -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From gwz@cisco.com Fri Oct 4 23:46:21 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 4 Oct 2002 15:46:21 -0700 Subject: [eap] Re: EAP methods, EAP charter, the marketplace and the IETF In-Reply-To: Message-ID: Bernard Aboba [mailto:aboba@internaut.com] writes: > > Right. I would actually reinforce that: my opinion is that we need both > > guidelines for standardization *and* a working Expert Review process > > right now. > > The "Expert Review" process comes into effect when the IANA considerations > document goes to RFC. There has been discussion of separating out the IANA > considerations into a separate document, so that it could progress > separately (and presumably, sooner). The disadvantage is that the EAP WG > mailing list will then need to handle the "Expert Review" -- and a concern > has been raised about the workload this could entail. But the EAP WG isn't an amorphous mass only capable of a single task at a time. Certainly there are people in this group who have more interest in new EAP types than the new RFC; why gate them on the progress made by others? > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Fri Oct 4 23:45:38 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Oct 2002 15:45:38 -0700 (PDT) Subject: [eap] Re: EAP methods, EAP charter, the marketplace and the IETF In-Reply-To: Message-ID: > But the EAP WG isn't an amorphous mass only capable of a single task at a > time. Certainly there are people in this group who have more interest in > new EAP types than the new RFC; why gate them on the progress made by > others? So I take it that you are in favor of advancing the IANA considerations document immediately? From gwz@cisco.com Sat Oct 5 03:55:43 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 4 Oct 2002 19:55:43 -0700 Subject: [eap] Re: EAP methods, EAP charter, the marketplace and the IETF In-Reply-To: Message-ID: Bernard Aboba [mailto:aboba@internaut.com] writes: > > But the EAP WG isn't an amorphous mass only capable of a single > task at a > > time. Certainly there are people in this group who have more > interest in > > new EAP types than the new RFC; why gate them on the progress made by > > others? > > So I take it that you are in favor of advancing the IANA considerations > document immediately? I can't see why not, if only in the interest of expediency. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Sat Oct 5 16:47:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 08:47:43 -0700 (PDT) Subject: [eap] This week's position papers Message-ID: Position Paper: When can Notificaton, Identity, NAK, Success and Failure messages be sent and accepted? 10/2/02 Bernard Aboba aboba@internaut.com When can a NAK be sent? A Nak is sent by the peer in response to a method proposal by the authenticator. The authenticator proposes a method. The peer can accept the proposal (by replying with an EAP method of the same type), or NAK the proposal. Once the proposal is accepted, a NAK cannot be sent by the peer until a new method has been proposed. NAKs are never sent by the authenticator, nor are they sent by the peer in response to a method whose proposal has already been accepted. When can a Notification be sent? EAP Notification Requests can be sent by the authenticator at any time. EAP Notification Responses MUST be sent by the peer in response to a Notification Request sent by the authenticator. EAP Notification is *not* an error message, and so sending or receiving Notification Request/Responses does not change the state of the peer or authenticator. It is assumed that Notification Responses are sent automatically by the EAP layer, so that it cannot be assumed that a Notification Request is delivered to the running EAP method. When can an Identity Request be sent and accepted? The rules for sending an Identity Request are the same as with any other method. An Identity Request may be sent multiple times within a single EAP conversation, as is the case for any other method. As with any other method, an Identity Request can be NAK'd by the peer. When is the Success or Failure message sent? EAP Success or Failure messages are sent by the authenticator EAP layer. When it completes, an EAP method residing on the authenticator indicates the result of the authentication to the EAP layer (Success or Failure). If the method is not the final one in the sequence, then the authenticator EAP layer will propose another EAP method to the peer. The Success message, if sent at all, is only sent after the successful completion of all the authentication methods in a sequence. Note that some EAP methods do not permit other methods to be used afterward as part of a sequence. For example, an EAP method that terminates after sending an EAP Request cannot be followed by another method, since no EAP Response will be forthcoming, and therefore the EAP conversation cannot be continued. This implies that a sequence involving such a method cannot be terminated with an EAP Success or Failure message. This does not cause a problem, assuming that the method supports its own Success and Failure indications. When can a Success or Failure message be accepted? EAP methods may include their own (protected) success and failure indications. Since EAP does not provide support for error messages, several methods have implemented method-specific error message capabilities. For example, TLS-based methods utilize TLS alerts, which are protected within the TLS channel, in order to transmit error messages. Similarly, methods also implement method-specific success indications. For example, a method suporting mutual authentication will expect the authenticator to complete authentication prior to completion of the method. As a result, a method specification may indicate that the method only expects to receive cleartext EAP Failure and Success messages under certain conditions. For example, a cleartext Success message is only expected once mutual authentication has been completed, or a cleartext Failure message is only expected after receipt of a protected failure indication such as a TLS alert. These directives can be indicated via a filter interface between the method and the EAP layer. An EAP method can install a filter in the EAP layer, causing the mux to silently discard EAP packets not meeting the filter criteria while the EAP method is in operation. The operation of the filter MUST be described in detail within the EAP method specification, to enable interoperability. Filters installed by methods are automatically removed once the method terminates operation. For example, an EAP method can negotiate a key early on, and after that, may want to require that all EAP packets be protected using the derived key until a protected success/failure indication is received. To achieve this, the method on the peer may install the following filter: (1) ACCEPT: Code = Request, Type=MyMethod (2) DENY: all This will cause the peer mux to silently discard messages of types Identity, Notification, Success and Failure until the filter is removed or the method terminates. Once a protected Success indication is received (e.g. the authenticator completes mutual authentication), the filter list can be changed to: (1) ACCEPT: Code = Request, Type=MyMethod (2) ACCEPT: Code = Success (3) DENY: all Similarly, once a protected failure message is received, a filter can be plumbed enabling the reception of an EAP Failure: (1) ACCEPT: Code = Request, Type=MyMethod (2) ACCEPT: Code = Failure (3) DENY: all EAP State Machine Completeness Position Paper, Oct 1, 2002 Jari Arkko, Ericsson Research NomadicLab 1. INTRODUCTION The completeness of the state machine from draft-payne-eap-sm-00.txt was analyzed. By completeness, we mean that the state machine contains a description of what to do for all possible events in all states. Note that in some cases we may well ignore an event, but this should be done on purpose and we should document it clearly. If not, we often tend to forget some events that should have been handled with something else than silent discard. We have already debated a number of issues which are specific examples of the current underspecification that the original RFCs as well as the state machine proposals have, such as when can NAKs come. 2. EVENTS The events that can come to a peer are: - ID Request - Method Request (many types and subtypes) - Notification - Success - Failure - Protocol error (i.e. anything else, such as a NAK sent to the client -- this could be debatable whether we need to deal with this. But some protocols make a state transition e.g. close connection upon getting these.) The events that can come to an authenticator are: - ID response - Methods response - Notification ack - NAK - Protocol error 3. PEER STATE MACHINE Some states in this state machine are just temporary transitions, such as the peer identification state, where we simply respond with an identity response and return back to unauthenticated state: - Initialized - Peer identification - Invalid request - Authenticated The states on which some waiting of events occur are as follows: - Unauthenticated - Method state machine We will study these two states in detail. We note that the Unauthenticated state does not handle the Failure, Notification, or protocol error events. The method state machine state does not handle Identity request, Method request (perhaps this is thought to be on a lower level at the specific method state machine), Notification, and protocol error events. 3. AUTHENTICATOR STATE MACHINE Again, the states which aren't real states in the usual definition of the term are: - Initialization - Failure - Authenticated The real states which we will study are: - Unauthenticated - Peer identification - Method state machine The Unauthenticated state does not handle Notification Response, NAK, and protocol error events (we suspect the right action in these cases would be silent discard). The Peer identification state does not handle Method response, NAK, Notification, or protocol error events. Note that we have already discussed the situation where NAK might be used to signal that we don't want to give an identity. The Method state machine state does not handle Notification response, Identity response, or protocol error events. It also doesn't really handle Method response event, but again we suspect this was expected to be done at the lower layer, in the specific method state machine. 4. FURTHER WORK It is necessary to ensure that the state machines are complete and we have knowingly decided to ignore the events that currently are ignored. We have already begun to debate some of the individual issues around this, such as when can NAKs come. In the above analysis, we have not yet taken a final stand on whether the right action in some of these cases is something else than silent discard. If the right action is silent discard, then everything is currently OK. It is also necessary to take a similar look at the 802.1aa D3 state machines. From aboba@internaut.com Sat Oct 5 17:17:23 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 09:17:23 -0700 (PDT) Subject: [eap] EAP Notification Survey Results Message-ID: Based on the survey results (see below), I would like to propose the following conclusions. Comments welcome. a. EAP Notification Requests may be sent at any time by the authenticator. For example, they may arrive in the middle of a method exchange. An EAP Notification Request cannot be NAK'd. b. An EAP Notification Response MUST be sent by the peer in response to an EAP Notification Request. The Response is sent automatically by the peer and confirms receipt, but does not indicate whether the user took any action in response to the message, or even whether the message was displayed to the user at all (e.g. it may be consumed by an embedded device). c. EAP Notification Requests SHOULD be displayed or logged by the peer. It cannot be assumed that Notification Requests are available for processing by the running method. d. EAP Notification Requests or Responses do not result in a state change. e. EAP Notification is *not* an error indication. Below find the original survey and posted responses. Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT) From: Bernard Aboba To: eap@frascone.com Subject: [eap] Notification survey In the EAP Design team meeting today, we discussed the use of EAP Notification. The question arose as to what people are using this for today, and why. If you have implemented EAP Notification in your method (or your EAP implementation), can you let us know: a. Whether you are using Notification as part of the method (e.g. Notification Request is delivered to the method) b. Whether you allow Notification to be sent at any time (in the middle of a method exchange) c. Whether Notification results in a state change within the EAP state machine or not d. Whether you would be affected if EAP Notification were to be eliminated or deprecated, and why this would be bad (or good) --__--__-- Date: Wed, 02 Oct 2002 23:02:10 +0200 To: Bernard Aboba From: Jacques Caron Subject: Re: [eap] Notification survey Cc: eap@frascone.com Hi, I don't use it (yet), but: a. I definitely believe a method on the client side shouldn't expect any such messages (there should be a generic method handler for it that will just display the message to the user - a bit like there should be a generic identity method handler that just returns the identity). b. It should be possible to possible to send this nearly at any time: - there should be only one outstanding request (i.e. not possible to send a Notification request just after some other method request before the response came back) - at the very least it should be possible to use it between two requests from different methods, not necessarily in the middle of the exchanges of one given method. c. Receiving a Notification request should prompt a Notification response, and then return to the same state. If the message is displayed via some kind of alert/dialog box (that requires user action), the question of whether the response is sent immediately or once the user acknowledges the dialog box remains open (in that last case there would be an intermediate state, I guess). d. I believe it's useful to be able to send clear-text messages to the client, in the following (non-exhaustive list of) cases: - an authentication method failed, and the method wants to give the user more information about why - a method (maybe not an authentication one, more an authorization one) got a NAK back, and the method wants to tell something to the user anyway (e.g. connection cost) Of course the problem of the authenticity of the message is present, but that's a more general problem of EAP messages... An important point is that one should just not consider that the message will actually be seen and/or interpreted by anyone, it's purely informative. Just my 0.02 EUR. Jacques. --__--__-- Date: Thu, 03 Oct 2002 13:00:01 +0300 From: Preeti Vinayakray Organization: Nokia Research Centere To: ext Bernard Aboba CC: eap@frascone.com Subject: Re: [eap] Notification survey Hello: Following ans. relevant to my EAP implementation ext Bernard Aboba wrote: > In the EAP Design team meeting today, we discussed the use of EAP > Notification. The question arose as to what people are using this for > today, and why. If you have implemented EAP Notification in your method > (or your EAP implementation), can you let us know: > > a. Whether you are using Notification as part of the method (e.g. > Notification Request is delivered to the method) > Yes, it is used as a part of the method > > b. Whether you allow Notification to be sent at any time (in the middle of > a method exchange) > No, > > c. Whether Notification results in a state change within the EAP state > machine or not > No > > d. Whether you would be affected if EAP Notification were to be eliminated > or deprecated, and why this would be bad (or good) > This very much depends on how implementation is done. In terms of my implementation I consider it is 'good 'as a part of methods I have supported, But it does not change any state info for client/peer. It just provides some line display. So elemination of this not going to affect. -Preeti >From carlsonj@phorcys.east.sun.com Fri Oct 4 09:53:16 2002 To: Bernard Aboba Subject: Re: [eap] Notification survey I have this implementation: ftp://playground.sun.com/pub/eap/index.html and I'm working on updating it and integrating it into 'pppd' (since I'm now one of the maintainers of that software) for the next release. > a. Whether you are using Notification as part of the method (e.g. > Notification Request is delivered to the method) No, it's not part of the method. > b. Whether you allow Notification to be sent at any time (in the middle of > a method exchange) Sure. > c. Whether Notification results in a state change within the EAP state > machine or not No. Nothing in the RFC describes it being used that way ... > d. Whether you would be affected if EAP Notification were to be eliminated > or deprecated, and why this would be bad (or good) I wouldn't be affected. I never send them, and I just log them if received (and of course send ack). I don't think it would be good to remove this message. I like having a "I think this is interesting for you to log" message for debug and deployment reasons. If, however, we fixed 'Success' and 'Failure' to be able to include a debug text message (as I think they ought to have from the start), then I'd be somewhat happier with losing Notification. (Not perfect, but good enough.) (I also think that the possible i18n concerns and the spamming concerns are misplaced -- the receiver can do anything it likes with these, including discarding the text.) -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Date: Thu, 3 Oct 2002 09:54:36 -0700 (PDT) From: Bernard Aboba To: eap@frascone.com Subject: [eap] RE: Notification survey For what it's worth, here are some details on how Windows implements Notification: - EAP-Notification is out-of-band. The EAP layer automatically sends a Notification Response; the Notification Request is not passed to the currently running method. - EAP-Notification can be sent at any time. There are no checks done when the EAP-Notification arrives. - Since EAP-Notification is not passed to the method, it does not result in a state change. - EAP Notification does not have support for internationalization. The lack of language support means that there is no easy way to display a message to the user in a language that they can be guaranteed to understand. - EAP-Notification does not result in a display to the user at present. --__--__-- From aboba@internaut.com Sun Oct 6 03:13:09 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 19:13:09 -0700 (PDT) Subject: [eap] Issue 35: Notification Usage Message-ID: Issue 34: Notification Usage Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 5, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: S Section: 5.2 Rationale/Explanation of issue: RFC 2284bis doesn't answer basic questions about Notification, such as: a. Whether you are Notification is part of the method (e.g. Notification Request is delivered to the method) b. Whether Notification can be sent at any time (e.g. in the middle of a method exchange) c. Whether Notification results in a state change within the EAP state machine or not Change: " The Notification Type is optionally used to convey a displayable message from the Authenticator to the peer. The Peer SHOULD display this message to the user or log it if it cannot be displayed. It is intended to provide an acknowledged notification of some imperative nature. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, notification should not be required." To: " The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time, including in the middle of an ongoing method conversation. The peer MUST respond to a Notification Request with a Notification Response; a NAK response MUST NOT be sent. A Notification Response is typically generated automatically by the EAP layer, so that methods MUST NOT use Notification as an inband communication mechanism. The Peer SHOULD display this message to the user or log it if it cannot be displayed. The Notification Type is intended to provide an acknowledged notification of some imperative nature, but it is not an error indication, and therefore does not change the state of either the authenticator or the peer. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, notification should not be required." From aboba@internaut.com Sun Oct 6 03:19:15 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 19:19:15 -0700 (PDT) Subject: [eap] Issue 35: NAK'ing an Identity Request Message-ID: Issue 35: NAK'ing an Identity Request Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 5, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: 2 Section: 5.1 Rationale/Explanation of issue: RFC 2284bis doesn't state whether an Identity request can be NAK'd. Change: "The Identity Type is used to query the identity of the peer. The Authenticator will typically issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there is an expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity)." To: "The Identity Type is used to query the identity of the peer. The Authenticator will typically issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there is an expectation of interaction with a user. A peer MAY respond to an Identity Request with a NAK if it does not wish to reveal its identity. Otherwise, the peer MUST send an Identity Response in response to an Identity Request." From aboba@internaut.com Sun Oct 6 03:20:45 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 19:20:45 -0700 (PDT) Subject: [eap] Issue 33: Encoding of Identity Response Message-ID: Issue 33: Encoding of Identity Response Submitter: Mark Wodrich Submitter email address: markwo@microsoft.com Date first submitted: August 12, 2002 Reference: Document: RFC2284bis-05 Comment type: T Priority: S Section: 5.2 Rationale/Explanation of issue: Displayable messages are to be encoded in UTF-8. The Identity Request MAY contain a displayable message, and if so, that is UTF-8 encoded. But what about an Identity Response? Is that UTF-8 encoded? Does RFC 2486 allow this? Please clarify in the text. [BA] If the Identity Response contains an NAI, then the Response MUST satisfy the NAI grammar described in RFC 2486. This appears to enable any character to be utilized within the username, so UTF-8 is reasonable there. However, the encoding of the NAI realm is subject to the same restrictions as Internationalized Domain Names, which do *not* use UTF-8 encoding. So I don't think that the Identity Response has the same requirements as a Displayable Message (though it may indeed be displayed). Here is the proposed text: "If the Identity Response contains a Network Access Identifier (NAI), then the NAI MUST conform to the grammar described in [RFC2486]. For example, the realm field of the NAI may contain any characters legal for inclusion within fully qualified domain names, and thus is internationalized as though it were an Internationalized Domain Name (IDN)." From aboba@internaut.com Sun Oct 6 03:28:27 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 19:28:27 -0700 (PDT) Subject: [eap] Issue 36: When may a NAK be sent? Message-ID: Issue 36: When may a NAK be sent? Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 5, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: 1 Section: 5.3 Rationale/Explanation of issue: RFC 2284bis doesn't state when a NAK can be sent, and when not. For example: a. Whether a NAK may only be sent in response to a method proposal or b. Whether NAK can be sent at any time (e.g. in the middle of a method exchange) Change: " The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains zero or more authentication Types desired by the peer. A Nak with no authentication Type(s) indicates that the Peer does not wish to authenticate using the proposed method but is not proposing an alternative. Since the Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method." To: " The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 1 and 4 and above. The Response contains zero or more authentication Types desired by the peer. A Nak with no authentication Type(s) indicates that the Peer does not wish to authenticate using the proposed method but is not proposing an alternative. Since the Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. For example, a NAK MUST NOT be sent in the middle of an EAP method conversation." From james.d.carlson@east.sun.com Sun Oct 6 04:36:26 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Sat, 5 Oct 2002 23:36:26 -0400 Subject: [eap] Issue 33: Encoding of Identity Response In-Reply-To: Bernard Aboba's message of 5 October 2002 19:20:45 References: Message-ID: <15775.44986.562073.765267@gargle.gargle.HOWL> Bernard Aboba writes: > Submitter: Mark Wodrich > Submitter email address: markwo@microsoft.com [...] > Displayable messages are to be encoded in UTF-8. The Identity Request > MAY contain a displayable message, and if so, that is UTF-8 encoded. > But what about an Identity Response? Is that UTF-8 encoded? Does > RFC 2486 allow this? Please clarify in the text. I fail to see how this is an issue. The 'identity' string is a sequence of octets -- period. Any semantics that it might possibly have (including being an NAI, being in Chinese, or any other context) is outside the scope of EAP itself. The things that provide suitable context here are: - the definition of the method to be used; some methods may have stronger requirements on identity values. - the deployment -- some operators may insist on having identities conform to some standard. (For instance, some of our networks require IDs be given as two initials and an employee number. Some networks require NAIs.) - the association -- a system attempting to prove its identity of course needs to have a pre-arranged association with the authenticator, and part of that association is the identity. I think that last bit is the key one -- authentication isn't done in a vacuum. > "If the Identity Response contains a Network Access Identifier (NAI), > then the NAI MUST conform to the grammar described in [RFC2486]. For > example, the realm field of the NAI may contain any characters legal > for inclusion within fully qualified domain names, and thus is > internationalized as though it were an Internationalized Domain Name > (IDN)." I think that makes the text rather worse than better. It seems to imply that there's some sort of constraint on how the identity can be used. Given the linkage to other bits of the authentication infrastruture here, I think this request is somewhat akin to insisting that any strings that appear in an IP datagram be UTF-8 encoded. Perhaps consistency across all protocols could be useful to someone, but I don't think it should be codified. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Sun Oct 6 03:36:28 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 5 Oct 2002 19:36:28 -0700 (PDT) Subject: [eap] EAP issues procedure Message-ID: I'm sure that many of you have issues with the current EAP specification, RFC 2284bis-06. If so, please don't be hesitant about filing them. The odds of your issue being dealt with promptly (and correctly) is much greater if you post an issue (and recommended fix) to the EAP mailing list. The procedure for filing EAP issues is the same as in AAA WG, and is detailed (along with the EAP issue descriptions) at: http://www.drizzle.com/~aboba/EAP/eapissues.html Please have a look at the current issues list and posting template, and if you have a concern or issue that is bugging you, please file it. If WG members go over the specification and file issues, we are likely to find (and fix) the gremlins sooner. From aboba@internaut.com Sun Oct 6 10:37:28 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 02:37:28 -0700 (PDT) Subject: [eap] NAK survey Message-ID: During the last EAP design team meeting, there were also questions about the NAK Type (see issues #35 and 36). Please answer the following questions relating to the operation of your implementation: a. May the NAK be sent by the peer in response to any EAP request? For example, may it be sent in the middle of an EAP method? OR b. May the NAK be sent by the peer only in response to a method proposal (e.g. the first EAP Request for a given Type)? c. Does your implementation tolerate sending more than one Type within a NAK (e.g. may not recognize additional Types, but doesn't blow up)? d. Does your implementation permit a NAK to be sent in response to an Identity Request? If so, what does it do if a NAK is sent? From aboba@internaut.com Sun Oct 6 11:06:56 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 03:06:56 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation Message-ID: Issue 37: EAP stack representation Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 5, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: 1 Section: 2.1 Rationale/Explanation of issue: RFC 2284bis needs an explanation for how EAP multiplexing works. Here is a proposal for material to be added to section 2.1: "Within EAP, the Type field functions much like a port number in UDP or TCP. With the exception of types handled by the EAP layer, it is assumed that EAP implementations multiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type code. This includes the Identity Type, which operates like any other EAP method. The Nak method is utilized for the purposes of method negotiation, and is implemented within the EAP layer. Peers MUST respond to an EAP Request for an unsupported Type with a Nak Response. Authenticators receiving an EAP Response with an unsupported Type MUST silently discard the Response. While a Notification Request may be generated at the behest of an EAP method, a Notification Response is generated automatically by the peer EAP layer in response to it. EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. As a result, the Success, Failure, Nak and Notification messages MUST NOT used to carry data destined for delivery to other EAP methods. The architecture is illustrated in figure 1 on the next page. (see ASCII art at http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2037) Figure 1. EAP Multiplexing Model From aboba@internaut.com Sun Oct 6 11:24:26 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 03:24:26 -0700 (PDT) Subject: [eap] Issue 38: Language Negotiation Message-ID: Issue 38: Language Negotiation Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 5, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: 1 Section: N/A Rationale/Explanation of issue: Currently there is no way to make sure that displayable messages (such as Notifications) are sent in a language that the user understands. Some ideas on how this might be accomplished: a. Add language type to the first octets of the Notification Request AND allow a Notification Response to encode an alternate language. However, the Notification Response is of zero length, so there is a question of whether this would break existing implementations. b. Encode the proposed language type in the Identity Request, and allow the Identity Response to encode an alternate language. From aboba@internaut.com Sun Oct 6 11:33:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 03:33:42 -0700 (PDT) Subject: [eap] Issue 23: Content of the Identity Request Payload Message-ID: Issue 23: Contents of Identity Request Payload Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2284bis-04 Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: Section 5.1 page 13 describes the Identity Type thusly: The Identity Type is used to query the identity of the peer. Generally, the Authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity). This language is good as far as it goes, but I wonder if more formal rules should be specified to enable the more mobile enviroments where EAP is being applied? What I have in mind is that it is likely that many (most?) users/devices will have different sets of credentials for many of the security domains they visit. Each of these credentials will assign to the user/device a different artificial and arbitrary "identity". In the wireless roaming case, it is likely that a user will sometimes cross domain boundaries without even knowing it, so the commonly cited industry goal of "seamless" roaming would imply that the Identity Request from the Authenticator should provide some hint as to which "identity" it is expecting, i.e., which domain is in use. While the cited language above does not preclude this, it does not specify any interoperable way of accomplishing this goal. The obvious suggestion would be to insert the domain name portion of the NAI of the Authenticator in some standard way into the Identity Request. The Peer could parse and then attempt to map this to the credentials it should present to this particular Authenticator. [BA] I think that there are a number of issues here: 1. How the Supplicant knows what NAI to present to the Authenticator, if more than one is available. 2. What certificate the Supplicant presents when queried by the Authenticator. 3. How to route the authentication itself, particularly if EAP pre-authentication is used. (In this case, the selected access point (and in the case of 802.11, SSID) is not known at the time of authentication (assuming that we are talking about a shared use AP advertising multiple SSIDs). Note that knowing the NAI of the Authenticator may not by itself help answer these questions. In the case of wireless the AP is also typically advertising its characteristics, which in the case of 802.11 can include the SSID. Similar advertisements have also been discussed in SEAMOBY. So at the point at which EAP authentication occurs, the Supplicant may have learned information about the AP, based on the L2 or L3 advertisements. So the question is how information to be added in the EAP Identity-Request adds to (or possibly conflicts) with the information in the advertisement. For example, in 802.11 there are quite a few ways to implement a shared use AP that can advertise multiple SSIDs. SSIDs represent the networks to which the AP connects, which may is often more useful than the NAI of the Authenticator itself. For example, a single AP may advertise a roaming consortia SSID, a WISP SSID, and maybe the SSID for a secure network. Each of these SSIDs correspond to a different VLAN and access network. From aboba@internaut.com Sun Oct 6 11:35:35 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 03:35:35 -0700 (PDT) Subject: [eap] Issue 25: Spoofing and duplicate detection Message-ID: Issue 25: Spoofing and duplicate detection Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2284bis-04 Comment type: T Priority: S Section: 9.3 Rationale/Explanation of issue: Section 9.3 page 23, point 1 says: Silent discard. Since only a single EAP Request can be in progress between an Authenticator and a Peer at a given time, if a Peer receives a new Request before sending a Response, the new Request can be silently discarded. This increases resilience against spoofed Requests. Similarly, an Authenticator can silently discard Responses with Identifiers that do not correspond to the Identifier included in the last Request, or that represent duplicate Responses. This advice seems effective only if both the Authenticator and the Peer respond significantly more rapidly than does the active attacker, or their responses are delivered more expeditiously than the attacker's, i.e., you can't depend on it. The Success and Negotiate messages in particular require their own protection. I suggest noting this method does not work except in very constrained environments because of the race conditions cited. Resolution: Possible Reject [BA] For a new Request that arrives before the Response is sent, it seems to me that the proposed behavior is appropriate. Since a compliant Authenticator will never send a new Request before receiving a Response, if the Supplicant sees this, it either implies that the Request has been spoofed, or that a Response was spoofed that caused the new Request to be sent. This behavior cannot be caused merely by a poor RTO estimator since EAP is an ACK/NAK protocol. If the method is protected, then presumably a spoofed Response is not possible. If the Request is spoofed, then silent discard is appropriate. For a Response that does not match the Identifier of the Request the indicated behavior also appears correct. Assuming that we have a compliant EAP client, this can happen in high latency networks where the Response is sent in answer to a retransmitted Request, with the original Response arriving after the Request is retransmitted. If the original Response was invalid, then a new Request would not have been sent, so that discarding the duplicate Response has no ill effect. If Requests are being spoofed, and the EAP method is not protected, then the EAP client may Respond to the bogus Requests, causing the observed behavior. By discarding Responses to bogus Requests, the Authenticator can avoid becoming confused, but the outlook on the client is less sanguine; it seems likely that authentication will fail. So it seems that in this case the specified behavior does no harm, although it may not do much good either. From aboba@internaut.com Sun Oct 6 11:36:19 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 03:36:19 -0700 (PDT) Subject: [eap] Issue 32: Keying confirmation Message-ID: Issue 32: Keying confirmation Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2284bis-04 Comment type: T Priority: S Section: 9.8 Rationale/Explanation of issue: Section 9.8 continues on page 24 at the end of its paragraph 4: This means that it is not possible for the Peer to validate the identity of the Authenticator. Actually, this is not necessarily true, either. Many reasonable keying schemes require a key confirmation handshake, whereby the handshake confers to the Peer assurances concerning some version of the Authenticators identity. What it does imply is that the entire keying mechanism cannot be contained within EAP, nor within AAA nor NASREQ, nor within the media specification. The distribution of symmetric keys is one of those perverse things that does not and cannot follow our normal partitioning of network communication problems, which is why people nearly always make a complete hash of it. I suggest adding the words "within EAP alone" to the quoted sentence. From jari.arkko@piuha.net Sun Oct 6 13:22:37 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 06 Oct 2002 15:22:37 +0300 Subject: [eap] Issue 37: EAP stack representation References: Message-ID: <3DA02B0D.5090402@piuha.net> Bernard, I like your text, but I have a few discussion points below: > The Nak method is utilized for the purposes of method negotiation, > and is implemented within the EAP layer. Peers MUST respond to an EAP > Request for an unsupported Type with a Nak Response. unsupported => unacceptable? (What if I support the method but the password/config file/card is missing, or if I'd rather not do this method even if I do support it. For instance, Nakking an Identity request if I intend to do a tunneled TLS protected EAP first before giving away my real identity?) > Authenticators > receiving an EAP Response with an unsupported Type MUST silently discard the Response. Unsupported or unexpected? Even if I support FOO, I don't want a FOO response if I just initiated BAR by sending its first message to the peer. Perhaps the following text would be more suitable: "Authenticators receiving an EAP Response with a Type for which the authenticator has no outstanding Request MUST silently discard the Response." Jari From jari.arkko@piuha.net Sun Oct 6 13:44:17 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 06 Oct 2002 15:44:17 +0300 Subject: [eap] Issue 23: Content of the Identity Request Payload References: Message-ID: <3DA03021.2060007@piuha.net> I have a few background questions before I can understand this issue: 1) Are we sure that the NAI in the Identity *Response* is not sufficient to handle these situations? Assuming all the domains you visit are still within the same roaming group, this should work. 2) How are EAP peers expected to treat multiple identity requests? Presumably, these could be made for retransmission purposes or because the authenticator doesn't have any information about the given identity. 3) If need to solve this issue, would be better to work on advertisements or re-trials with other identities? 4) In a roaming group, what network domain should be advertised? The user is unlikely to know the local domain, but we can't list all the domains involved in the group. Are roaming groups always associated with a domain? 5) When certificates need to be presented, how are the currently available cert-based methods handling the domain issue? Does TLS allow you to specify the root for which you need the cert? Jari From aboba@internaut.com Sun Oct 6 12:40:26 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 04:40:26 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <3DA02B0D.5090402@piuha.net> Message-ID: On Sun, 6 Oct 2002, Jari Arkko wrote: > unsupported => unacceptable? Done. > Perhaps the following text would be more suitable: "Authenticators receiving > an EAP Response with a Type for which the authenticator has no outstanding > Request MUST silently discard the Response." Done. From aboba@internaut.com Sun Oct 6 16:21:52 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 08:21:52 -0700 (PDT) Subject: [eap] Issue 23: Content of the Identity Request Payload In-Reply-To: <3DA03021.2060007@piuha.net> Message-ID: > I have a few background questions before I can understand this > issue: > > 1) Are we sure that the NAI in the Identity *Response* is not > sufficient to handle these situations? Assuming all the > domains you visit are still within the same roaming > group, this should work. I think the issue arises if the user has multiple identities, and if insufficient information is available on the authenticator network to make a decision on which Identity to use or credentials to present. I am not sure that this is an issue for the NAI, so much as for credentials (such as certificates). I think it is reasonable to expect that prior to use of EAP, some out-of-band information is available on the network to which the authenticator connects. In the case of PPP, there is typically an ISP phone book that was installed beforehand. In the case of 802.11 there are the 802.11 Beacons and Probe Responses, which include the SSID. So if the user's machine has a list of potential networks and the corresponding NAIs to login to those networks, I think that is enough, without adding hints in the Identity Request. > 2) How are EAP peers expected to treat multiple identity > requests? Presumably, these could be made for retransmission > purposes or because the authenticator doesn't have any > information about the given identity. One can conceive of several identities being used in a single authentication -- for example, a machine identity followed by authentication, then a user identity request followed by another authentication. I'm not sure how the peer knows which identity is being requested, though. Distinguishing retransmissions from new requests can be handled via the Identifier. > 3) If need to solve this issue, would be better to work on > advertisements or re-trials with other identities? I think that advertisements handle some of it (NAI selection). However, it's not clear to me how a peer determines which cert to use unless there is an SSID or other field in the cert providing a hint. See: http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt > 4) In a roaming group, what network domain should be advertised? > The user is unlikely to know the local domain, but we can't > list all the domains involved in the group. Are roaming groups > always associated with a domain? In 802.11, it is possible for an AP to advertise multiple SSIDs, one for each network that it connects to. If it does this using multiple BSSIDs, the "virtual APs" are indistinguishable from real APs. However, the SSID is limited to 32 octets, so it cannot represent an arbitrary FQDN or "realm" in the RFC 2486 sense. > 5) When certificates need to be presented, how are the currently > available cert-based methods handling the domain issue? Does > TLS allow you to specify the root for which you need the cert? The TLS certificate request payload includes acceptable certificate types and CAs. However, it is still possible that this guidance will not uniquely point to a client certificate. From aboba@internaut.com Sun Oct 6 16:30:40 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 08:30:40 -0700 (PDT) Subject: [eap] Issue 2: Alternative indications not well defined Message-ID: Issue 2: Alternative indications not well defined Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 25, 2002 Reference: Document: RFC2284bis-02 Comment type: T Priority: S Section: 3.2.1, 3.3.1, 3.3.2, 4.2 Rationale/Explanation of issue: The EAP Implementation Survey results disclose that alternative indications are not being implemented. In addition, alternative indications are not described in enough detail to be interoperable. What is an alternative indication, exactly? It would appear that alternative indications are not available on every media, and also that they increase the ability of an attacker to spoof packets. [BA] Question - are method-specific success and failure indications "alternative indications" in this context? If so, how do existing implementations process them? Resolution Changes: Delete sections 3.2.1, 3.3.1 and 3.3.2. Change the following text in section 4.2 from: "Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer SHOULD allow for this circumstance, by taking alternate indications of Success and Failure into account. The alternate indications are media-specific, and are described in section 3." To: "Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost." From aboba@internaut.com Sun Oct 6 16:35:39 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 6 Oct 2002 08:35:39 -0700 (PDT) Subject: [eap] Issue 7: Ability to authenticate with multiple methods not specified Message-ID: Issue 7: Ability to authenticate with multiple methods one after another not specified Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 2, 2002 Reference: Document: RFC2284bis-01 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: RFC 2284 does not explain how to authenticate with multiple authentication methods one after another. Resolution: Add the following text to Section 2: "An Authenticator MAY authenticate the Peer using a sequence of methods. A common example of this is an Identity request followed by an EAP authentication method such as MD5-Challenge. To accomplish this, the Authenticator and Peer first complete an EAP exchange involving the initial method, with a matching EAP type field included in both Request and Response packets. If the initial authentication method completes unsuccessfully, then the Authenticator sends a Failure packet to the peer. If it completes successfully, and additional authentication methods are required, the Authenticator will send a Request packet for a subsequent authentication method. The Peer will then respond with a Response packet containing a type field matching the Request. The sequence of authentication methods proceeds until either an authentication method fails (in which case the Authenticator sends a Failure packet to the peer) or the final authentication method completes successfully, in which case the Authenticator sends a Success packet to the peer." Comment by Bryan Payne: > > The state machine allows the authenticator to send a new ID request before > > each Auth request if it wants to. This is because each auth request may > > be associated with a different identity. > > Only if the Type code changes, right? Ahh yes, I'm glad that you brought this up. I can't find anything about this in the RFC. The closest thing that I can find is in "step 1" of section 2 (2284bis-03) where it is giving an overview of the protocol. So the answer to your question is "I don't know". There is no mention of the ID request only being allowed at this point in time. As I read the RFC, the authenticator could send identity requests over and over. Yes, this would be pointless...and that's why Nick and I drew the state machine to at least require ID, Auth, ID, Auth requests or Auth, Auth, ID, Auth, etc (because ID, ID, ID just doesn't make sense). Basically, I think that it makes sense to say that all ID requests will be followed by an auth request...and that ID requests are not required. I feel that this is captured in the state machine pretty well. Perhaps the RFC should be more specific in dealing with this issue? -bryan Notes from Bernard Aboba: Yet another question has arisen as to what happens when, in the middle of one EAP method, a Peer receives a Request for a completely different EAP method. Does it silently discard the packet? Call the new EAP method while leaving the old one suspended? Nak the new method with the Type of the previous one? Is this illegal? Also, are there some methods which must be the last method in a sequence? For example, what if the last packet sent within a method is not an EAP Success/Failure, but an EAP Request (say, encapsulating an encrypted Success/Failure). How can another method come after that one, since there will be no EAP Response to continue the conversation? And how can a final EAP Success/Failure ever be sent? From james.d.carlson@east.sun.com Mon Oct 7 12:13:34 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 7 Oct 2002 07:13:34 -0400 Subject: [eap] NAK survey In-Reply-To: Bernard Aboba's message of 6 October 2002 02:37:28 References: Message-ID: <15777.27742.446666.708959@gargle.gargle.HOWL> Bernard Aboba writes: > During the last EAP design team meeting, there were also questions about > the NAK Type (see issues #35 and 36). > > Please answer the following questions relating to the operation of your > implementation: ftp://playground.sun.com/pub/eap/index.html > a. May the NAK be sent by the peer in response to any EAP request? For > example, may it be sent in the middle of an EAP method? OR Yes, it can be sent at any time. > b. May the NAK be sent by the peer only in response to a method proposal > (e.g. the first EAP Request for a given Type)? No, at any time. I don't see how it could be otherwise -- for a multi-stage method, it's entirely possible to get part way down an authentication attempt only to discover that some required feature is missing in the peer and that some other mechanism is necessary. > c. Does your implementation tolerate sending more than one Type within a > NAK (e.g. may not recognize additional Types, but doesn't blow up)? It ignores any additional Types included in a Nak and uses only the first one. (If *no* suggested Type is included with the message, then it logs this fact, and treats it as a failure of the current message.) No, it doesn't "blow up," even though including multiple Types (or any other data) would be a violation of RFC 2284. ;-} > d. Does your implementation permit a NAK to be sent in response to an > Identity Request? If so, what does it do if a NAK is sent? If the identity of the peer was supplied by explicit configuration, then it accepts the Nak and continues with authentication using the suggested Type (if permitted). If the identity was not supplied by explicit configuration, then it treats this case as authentication failure, sends EAP Failure, and shuts down the link. There's one other case that your survey didn't cover (perhaps it's not a bone of contention?): what do you do when you get a Nak Type that isn't one that you want to deal with (either by administrative configuration or because you don't recognize it)? I examine my current state and ask for the "next" possible method on the list, returning to Identify if I fall off the end. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Mon Oct 7 17:32:40 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Oct 2002 09:32:40 -0700 (PDT) Subject: [eap] RE: NAK survey Message-ID: For what it's worth, here's what Microsoft Windows XP does: a. May the NAK be sent by the peer in response to any EAP request? For example, may it be sent in the middle of an EAP method? OR Windows XP peer will send a NAK only for the first packet after the EAP-Response/Identity is sent. It does not NAK an EAP-Request/Identity. b. May the NAK be sent by the peer only in response to a method proposal (e.g. the first EAP Request for a given Type)? Yes. c. Does your implementation tolerate sending more than one Type within a NAK (e.g. may not recognize additional Types, but doesn't blow up)? Windows XP will only send a single EAP type in the NAK packet, but the server will ignore types after the first one, if present. d. Does your implementation permit a NAK to be sent in response to an Identity Request? If so, what does it do if a NAK is sent? Windows does not send a NAK in response to an Identity Request, and on the server, if a NAK is received, then the conversation is terminated. From james.d.carlson@east.sun.com Mon Oct 7 19:12:42 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 7 Oct 2002 14:12:42 -0400 Subject: [eap] RE: NAK survey In-Reply-To: Bernard Aboba's message of 7 October 2002 09:32:40 References: Message-ID: <15777.52890.844105.402447@gargle.gargle.HOWL> Bernard Aboba writes: > For what it's worth, here's what Microsoft Windows XP does: > > a. May the NAK be sent by the peer in response to any EAP request? For > example, may it be sent in the middle of an EAP method? OR > > Windows XP peer will send a NAK only for the first packet after the > EAP-Response/Identity is sent. It does not NAK an EAP-Request/Identity. Interesting question here: was the question above about what you'd *accept* or about what you'd possibly *send*? It looks like I read the question as the former (because "sent by the peer" implies "received by the local system" to me), and you might have read it as the latter. If it's intended as the latter, then I'd say this: I never send Nak in response to an Identity message, but I *do* send Nak in response to *any* message that is malformed for the method in use. In other words, if the method specifies a 16 octet message for the given message subtype, and you send me fewer than 16 octets, then I assume that you're running some new or different version of the protocol, and I send Nak to suggest a different authentication protocol since we're not going to converge. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@interlinknetworks.com Mon Oct 7 20:06:12 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Mon, 07 Oct 2002 15:06:12 -0400 Subject: [eap] Issue 37: EAP stack representation References: Message-ID: <3DA1DB24.9FFBD42F@interlinknetworks.com> I like this a lot. Have we determined that the notification method must be handled by the MUX rather than as a "standard" method? I thought the responses were indeterminate about whether this is a requirement. John Bernard Aboba wrote: > > Issue 37: EAP stack representation > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: October 5, 2002 > Reference: > Document: RFC2284bis-06 > Comment type: T > Priority: 1 > Section: 2.1 > Rationale/Explanation of issue: > > RFC 2284bis needs an explanation for how EAP multiplexing works. > > Here is a proposal for material to be added to section 2.1: > > "Within EAP, the Type field functions much like a port number in UDP or > TCP. With the exception of types handled by the EAP layer, > it is assumed that EAP implementations multiplex incoming > EAP packets according to their Type, and deliver them only to the EAP > method corresponding to that Type code. This includes the Identity Type, > which operates like any other EAP method. > > The Nak method is utilized for the purposes of method negotiation, > and is implemented within the EAP layer. Peers MUST respond to an EAP > Request for an unsupported Type with a Nak Response. Authenticators > receiving an EAP Response with an unsupported Type MUST silently discard the Response. > > While a Notification Request may be generated at the behest of an EAP > method, a Notification Response is generated automatically by > the peer EAP layer in response to it. > > EAP packets with codes of Success or Failure do not include a Type, and > therefore are not delivered to an EAP method. > > As a result, the Success, Failure, Nak and Notification messages > MUST NOT used to carry data destined for delivery to other EAP methods. > The architecture is illustrated in figure 1 on the next page. > > (see ASCII art > at http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2037) > > Figure 1. EAP Multiplexing Model > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Mon Oct 7 21:13:41 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Oct 2002 13:13:41 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <3DA1DB24.9FFBD42F@interlinknetworks.com> Message-ID: > I like this a lot. > > Have we determined that the notification method must be handled by the > MUX rather than as a "standard" method? I thought the responses were > indeterminate about whether this is a requirement. > > John It appears that existing implementations handle generation of the Notification Response automatically, within the EAP layer. I'm not as clear from the Notification Request. You'll notice that the EAP Notification Response is part of the EAP Layer in the ASCII-art figure, but that the Notification Request is not -- it's in the method layer. Also, existing implementations don't treat Notification Requests as data -- it's not delivered to the running method, although it would appear that methods can request that Notification Requests be sent. From galahad@netsgo.com Tue Oct 8 05:14:24 2002 From: galahad@netsgo.com (Donnie Dongkie Lee) Date: Tue, 8 Oct 2002 13:14:24 +0900 Subject: [eap] Vendor-Specific Type in NAK Message-ID: <00a601c26e81$2f9d9c10$6d0d0296@skzeqvuvk0h693> This is a multi-part message in MIME format. ------=_NextPart_000_00A3_01C26ECC.9F55F6B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 QWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtcHBwZXh0LXJmYzIyODRiaXMtMDYudHh0LCBWZW5kb3It U3BlY2lmaWMgYXV0aGVudGljYXRpb24gdHlwZSBjYW4gYmUgdXNlZCBpbiBhIHNwZWNpZmljIHZl bmRvciBkb21haW4uIEFuZCB3aGVuIGEgcGVlciBOYWtzIGF1dGhlbnRpY2F0aW9uIHR5cGUgc3Vn Z2VzdGVkIGJ5IGF1dGhlbnRpY2F0b3IsIGl0J3MgcG9zc2libGUgYSBwZWVyIHB1dCBWZW5kb3It U3BlY2lmaWMgYXV0aGVudGljYXRpb24gdHlwZSBpbiBOYWsuDQoNCkluIHRoaXMgY2FzZSwgYXV0 aGVudGljYXRvciBzaG91bGQgbG9vayBpbnRvIG1vcmUgdGhhbiA0IG9jdGV0cyggMSBvY3RldCBm b3IgdHlwZSwgMyBvY3RldHMgZm9yIFZlbmRvci1JZCkgbm90IGp1c3Qgb25lIG9jdGV0LiBQbHMg Y29ycmVjdCBtZSwgaWYgSSBhbSB3cm9uZyEhDQoNCg0KDQogICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0K ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgIHwgICAgIFR5cGUgICAgICB8ICAgICAgICAgICAgICAgVmVuZG9yLUlk ICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIFN0cmluZy4uLg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KRG9ubmllIERvbmdraWUgTGVlDQpCb25nY2hlb25kb25nIDcyOS0x LCBHd2FuYWtndSANClNlb3VsLCBLb3JlYSANClNLIFRlbGVjb20gDQpQaG9uZTogKzgyLTItODI5 LTQ2NDANCkUtTWFpbDogZ2FsYWhhZEBuYXRlLmNvbQ0KICAgICAgICAgICBnYWxhaGFkQG5ldHNn by5jb20NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K ------=_NextPart_000_00A3_01C26ECC.9F55F6B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTkuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5BY2NvcmRpbmcgdG8gDQpkcmFmdC1pZXRmLXBwcGV4dC1yZmMyMjg0YmlzLTA2LnR4 dCwgVmVuZG9yLVNwZWNpZmljIGF1dGhlbnRpY2F0aW9uIHR5cGUgY2FuIGJlIA0KdXNlZCBpbiBh IHNwZWNpZmljIHZlbmRvciBkb21haW4uIEFuZCB3PC9GT05UPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+aGVuIGEgDQpwZWVyIE5ha3MgYXV0aGVudGljYXRpb24gdHlwZSBzdWdnZXN0ZWQg YnkgYXV0aGVudGljYXRvciwgaXQncyBwb3NzaWJsZSBhIHBlZXIgDQpwdXQgVmVuZG9yLVNwZWNp ZmljIGF1dGhlbnRpY2F0aW9uIHR5cGUgaW4gTmFrLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+SW4gdGhpcyBjYXNlLCBhdXRoZW50aWNhdG9yIHNob3VsZCBs b29rIGludG8gDQptb3JlIHRoYW4gNCBvY3RldHMoIDEgb2N0ZXQgZm9yIHR5cGUsIDMgb2N0ZXRz IGZvciBWZW5kb3ItSWQpIG5vdCBqdXN0IG9uZSANCm9jdGV0LiBQbHMgY29ycmVjdCBtZSwgaWYg SSBhbSB3cm9uZyEhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQoyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KMzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyANCjggOSAwIDE8QlI+Jm5ic3A7Jm5ic3A7IA0KKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8QlI+Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANClZlbmRvci1JZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7Jm5ic3A7IA0KKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8QlI+Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANClN0cmluZy4uLjxCUj4mbmJzcDsmbmJzcDsgDQorLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgDQpmYWNl PUNvdXJpZXI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48QlI+RG9u bmllIERvbmdraWUgDQpMZWU8QlI+Qm9uZ2NoZW9uZG9uZyA3MjktMSwgR3dhbmFrZ3UgPEJSPlNl b3VsLCBLb3JlYSA8QlI+U0sgVGVsZWNvbSA8QlI+UGhvbmU6IA0KKzgyLTItODI5LTQ2NDA8QlI+ RS1NYWlsOiA8QSANCmhyZWY9Im1haWx0bzpnYWxhaGFkQG5hdGUuY29tIj5nYWxhaGFkQG5hdGUu Y29tPC9BPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo8QSANCmhyZWY9Im1haWx0bzpnYWxhaGFkQG5ldHNnby5jb20iPmdh bGFoYWRAbmV0c2dvLmNvbTwvQT48QlI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00A3_01C26ECC.9F55F6B0-- From jrv@interlinknetworks.com Tue Oct 8 17:43:34 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Tue, 08 Oct 2002 12:43:34 -0400 Subject: [eap] Issue 35: Notification Usage References: Message-ID: <3DA30B36.2D5D3A86@interlinknetworks.com> A small change suggestion Bernard Aboba wrote: > > Issue 34: Notification Usage > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: October 5, 2002 > Reference: > Document: RFC2284bis-06 > Comment type: T > Priority: S > Section: 5.2 > Rationale/Explanation of issue: > > RFC 2284bis doesn't answer basic questions about Notification, such as: > > a. Whether you are Notification is part of the method (e.g. Notification > Request is delivered to the method) > > b. Whether Notification can be sent at any time (e.g. in the middle of a > method exchange) > > c. Whether Notification results in a state change within the EAP state > machine or not > > Change: > > " The Notification Type is optionally used to convey a displayable > message from the Authenticator to the peer. The Peer SHOULD display > this message to the user or log it if it cannot be displayed. It is > intended to provide an acknowledged notification of some imperative > nature. Examples include a password with an expiration time that is > about to expire, an OTP sequence integer which is nearing 0, an > authentication failure warning, etc. In most circumstances, > notification should not be required." > To: > > " The Notification Type is optionally used to convey a displayable > message from the authenticator to the peer. An authenticator MAY > send a Notification Request to the peer at any time, including > in the middle of an ongoing method conversation. The peer MUST > respond to a Notification Request with a Notification Response; > a NAK response MUST NOT be sent. A Notification Response is > typically generated automatically by the EAP layer, so that > methods MUST NOT use Notification as an inband communication > mechanism. > Change A Notification Response is typically generated automatically by the EAP layer, so that methods MUST NOT use Notification as an inband communication mechanism. To A Notification Response is typically generated by the EAP layer; the Notification Data MUST NOT be forwarded to methods other than Notification. > The Peer SHOULD display this message to the user or log it if it > cannot be displayed. The Notification Type is intended to provide > an acknowledged notification of some imperative nature, but it is > not an error indication, and therefore does not change the state > of either the authenticator or the peer. Examples include a Change does not change the state of either the authenticator or the peer to does not change the state of the peer. [explanation -- the authenticator is going through a sequence of methods, and where it is in the sequence is part of the state. therefore sending the Notification message would have to change state of the Notification message would be sent over and over and over] > password with an expiration time that is about to expire, > an OTP sequence integer which is nearing 0, an authentication > failure warning, etc. In most circumstances, notification should > not be required." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@interlinknetworks.com Tue Oct 8 17:49:42 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Tue, 08 Oct 2002 12:49:42 -0400 Subject: [eap] Issue 36: When may a NAK be sent? References: Message-ID: <3DA30CA6.9F94CABB@interlinknetworks.com> I am not sure about this. I wonder what a peer method does if it gets req in the middle of a method that doesn't seem right. Does it quietly discard? I should think it might want a way to positively indicate that it was not happy. John Bernard Aboba wrote: > > Issue 36: When may a NAK be sent? > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: October 5, 2002 > Reference: > Document: RFC2284bis-06 > Comment type: T > Priority: 1 > Section: 5.3 > > Rationale/Explanation of issue: > > RFC 2284bis doesn't state when a NAK can be sent, and when not. For > example: > > a. Whether a NAK may only be sent in response to a method proposal or > b. Whether NAK can be sent at any time (e.g. in the middle of a method > exchange) > > Change: > > " The Nak Type is valid only in Response messages. It is sent in reply > to a Request where the desired authentication Type is unacceptable. > Authentication Types are numbered 4 and above. The Response contains > zero or more authentication Types desired by the peer. A Nak with no > authentication Type(s) indicates that the Peer does not wish to > authenticate using the proposed method but is not proposing an > alternative. > > Since the Nak Type is only valid in Responses and has very limited > functionality, it MUST NOT be used as a general purpose error > indication, such as for communication of error messages, or > negotiation of parameters specific to a particular EAP method." > > To: > > " The Nak Type is valid only in Response messages. It is sent in reply > to a method proposal (the initial EAP Request for a given Type) > where the desired authentication Type is unacceptable. > Authentication Types are numbered 1 and 4 and above. The Response contains > zero or more authentication Types desired by the peer. A Nak with no > authentication Type(s) indicates that the Peer does not wish to > authenticate using the proposed method but is not proposing an > alternative. > > Since the Nak Type is only valid in Responses and has very limited > functionality, it MUST NOT be used as a general purpose error > indication, such as for communication of error messages, or > negotiation of parameters specific to a particular EAP method. > For example, a NAK MUST NOT be sent in the middle of an EAP > method conversation." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@interlinknetworks.com Tue Oct 8 18:09:42 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Tue, 08 Oct 2002 13:09:42 -0400 Subject: [eap] Issue 37: EAP stack representation References: Message-ID: <3DA31156.5E362751@interlinknetworks.com> Bernard Aboba wrote: > > > I like this a lot. > > > > Have we determined that the notification method must be handled by the > > MUX rather than as a "standard" method? I thought the responses were > > indeterminate about whether this is a requirement. > > > > John > > It appears that existing implementations handle generation of the > Notification Response automatically, within the EAP layer. I'm not as > clear from the Notification Request. You'll notice that the EAP > Notification Response is part of the EAP Layer in the ASCII-art figure, > but that the Notification Request is not -- it's in the method layer. > > Also, existing implementations don't treat Notification Requests as data > -- it's not delivered to the running method, although it would appear that > methods can request that Notification Requests be sent. So my question is - would it be better to represent (in the formal state machine) that the EAP methods signal a notification request be sent from EAP or just have them originate and send it, or both. If we assume a sequence of methods might be defined somehow, and that EAP is responsible for making the sequence happen, then it would seem that Identity should be able to be treated as an "independent" method called by EAP and not by another method. Of course it could also be called by another method, but then it is the only method called by another method (I think - is that true?) and becomes a "special case". I would like to have us define an API between EAP and methods before deciding for sure how this should work. -- John From james.d.carlson@east.sun.com Tue Oct 8 21:25:34 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 8 Oct 2002 16:25:34 -0400 Subject: [eap] Issue 37: EAP stack representation In-Reply-To: John Vollbrecht's message of 8 October 2002 13:09:42 References: <3DA31156.5E362751@interlinknetworks.com> Message-ID: <15779.16190.838961.179221@gargle.gargle.HOWL> John Vollbrecht writes: > So my question is - would it be better to represent (in the formal state > machine) that the EAP methods signal a notification request be sent from > EAP or just have them originate and send it, or both. That sounds like an implementation detail. I don't see how it affects the observable behavior of the system or the bits on the wire. Is there any way for an outside observer to tell if the implementor chose to create this abstraction in the "EAP layer" or if the method itself just invokes Notification? If there's no actual way to tell, then I would argue that it does not belong in a document that comes from the IETF. (Certainly, other standards bodies have other priorities.) > If we assume a sequence of methods might be defined somehow, and that > EAP is responsible for making the sequence happen, then it would seem > that Identity should be able to be treated as an "independent" method > called by EAP and not by another method. Of course it could also be > called by another method, but then it is the only method called by > another method (I think - is that true?) and becomes a "special case". > > I would like to have us define an API between EAP and methods before > deciding for sure how this should work. If an API is needed at all, and I don't think it is, I would very much prefer to see this done in a group that is equipped to handle the intricacies of API design. The IETF isn't that group. Perhaps The Open Group might be. For that matter the state machine, as useful as it might be, can only be advisory in nature, since there's no way to tell from the bits on the wire whether the internal implementation details match that particular realization. I think it'd be much better to split this portion off into an Informational track RFC describing known-good implementation strategies. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@interlinknetworks.com Tue Oct 8 22:49:00 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Tue, 08 Oct 2002 17:49:00 -0400 Subject: [eap] Issue 37: EAP stack representation References: <3DA31156.5E362751@interlinknetworks.com> <15779.16190.838961.179221@gargle.gargle.HOWL> Message-ID: <3DA352CC.5F01AE2F@interlinknetworks.com> James Carlson wrote: > > John Vollbrecht writes: > > So my question is - would it be better to represent (in the formal state > > machine) that the EAP methods signal a notification request be sent from > > EAP or just have them originate and send it, or both. > > That sounds like an implementation detail. I don't see how it affects > the observable behavior of the system or the bits on the wire. > I agree that from a protocol point of view it is an implementation detail. > Is there any way for an outside observer to tell if the implementor > chose to create this abstraction in the "EAP layer" or if the method > itself just invokes Notification? If there's no actual way to tell, > then I would argue that it does not belong in a document that comes > from the IETF. (Certainly, other standards bodies have other > priorities.) > > > If we assume a sequence of methods might be defined somehow, and that > > EAP is responsible for making the sequence happen, then it would seem > > that Identity should be able to be treated as an "independent" method > > called by EAP and not by another method. Of course it could also be > > called by another method, but then it is the only method called by > > another method (I think - is that true?) and becomes a "special case". > > > > I would like to have us define an API between EAP and methods before > > deciding for sure how this should work. > > If an API is needed at all, and I don't think it is, I would very much > prefer to see this done in a group that is equipped to handle the > intricacies of API design. The IETF isn't that group. Perhaps The > Open Group might be. > > For that matter the state machine, as useful as it might be, can only > be advisory in nature, since there's no way to tell from the bits on > the wire whether the internal implementation details match that > particular realization. I think it'd be much better to split this > portion off into an Informational track RFC describing known-good > implementation strategies. > One point of the state machine is to make it easier to describe what the external behaviour is. Without it one has to imagine all the ways someone might interpret a set of words. A problem with describing it as a state-machine is that the state machine often implies an implementation, and of course ietf describes protocols not implementations. I also am not sure this is the place to define an API. However I do think porting EAP methods accross a variety of platforms will be much easier if there is such an API. - John From jsalowey@cisco.com Tue Oct 8 23:47:37 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 08 Oct 2002 15:47:37 -0700 Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <3DA31156.5E362751@interlinknetworks.com> References: Message-ID: <4.3.2.7.2.20021008154101.021668a8@e2k-sea-xch1.cisco.com> At 01:09 PM 10/8/2002 -0400, John Vollbrecht wrote: >Bernard Aboba wrote: > > Also, existing implementations don't treat Notification Requests as data > > -- it's not delivered to the running method, although it would appear that > > methods can request that Notification Requests be sent. > > >So my question is - would it be better to represent (in the formal state >machine) that the EAP methods signal a notification request be sent from >EAP or just have them originate and send it, or both. > >If we assume a sequence of methods might be defined somehow, and that >EAP is responsible for making the sequence happen, then it would seem >that Identity should be able to be treated as an "independent" method >called by EAP and not by another method. Of course it could also be >called by another method, but then it is the only method called by >another method (I think - is that true?) and becomes a "special case". I like the idea of separating the Identity as a separate method invoked by "EAP". I am uncertain about having Identity invoked from other methods. The Identity messages do not allow you to request a mechanism specific identity so how can a mechanism be sure it is going to get the right type of identity if it invokes the identity method? >I would like to have us define an API between EAP and methods before >deciding for sure how this should work. > >-- John >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Oct 9 01:28:20 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Oct 2002 17:28:20 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <15779.16190.838961.179221@gargle.gargle.HOWL> Message-ID: > Is there any way for an outside observer to tell if the implementor > chose to create this abstraction in the "EAP layer" or if the method > itself just invokes Notification? If one implementation uses Notification to pass in-band data, and another cannot handle that, then the two implementations won't interoperate. I believe that this behavior has been observed in existing implementations. > For that matter the state machine, as useful as it might be, can only > be advisory in nature, since there's no way to tell from the bits on > the wire whether the internal implementation details match that > particular realization. Unfortunately, that is not the case. There are known scenarios in which some implementations will conclude that they have authenticated successfully, and others will not. Again, this has been observed in the field. The response of a peer to an EAP Success packet should not be a mature of conjecture. From aboba@internaut.com Wed Oct 9 05:56:28 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Oct 2002 21:56:28 -0700 (PDT) Subject: [eap] Issue 35: Notification Usage In-Reply-To: <3DA30B36.2D5D3A86@interlinknetworks.com> Message-ID: > To > A Notification Response is > typically generated by the EAP layer; the Notification Data MUST NOT be > forwarded to methods other than Notification. How about this? "A Notification Response is typically generated automatically by the EAP layer; therefore the contents of a Notification Request MUST NOT be delivered to a peer method other than Notification." > to > does not change the state of the peer. Done. From aboba@internaut.com Wed Oct 9 06:00:46 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Oct 2002 22:00:46 -0700 (PDT) Subject: [eap] Issue 36: When may a NAK be sent? In-Reply-To: <3DA30CA6.9F94CABB@interlinknetworks.com> Message-ID: > I am not sure about this. I wonder what a peer method does if it gets > req in the middle of a method that doesn't seem right. Does it quietly > discard? I should think it might want a way to positively indicate that > it was not happy. I think that this requires a method-specific error message, no? The problem with allowing a NAK in the middle of the method is that the NAK is unprotected, and has very limited semantics, so that it can't serve as a general purpose error message, and can be easily spoofed. Plus, like Notification, you can't assume that the Nak is delivered to the method. From aboba@internaut.com Wed Oct 9 06:14:21 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Oct 2002 22:14:21 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <4.3.2.7.2.20021008154101.021668a8@e2k-sea-xch1.cisco.com> Message-ID: > I like the idea of separating the Identity as a separate method invoked by > "EAP". I am uncertain about having Identity invoked from other > methods. The Identity messages do not allow you to request a mechanism > specific identity so how can a mechanism be sure it is going to get the > right type of identity if it invokes the identity method? In reviewing RFC 2284bis, there are a number of places where Identity is treated differently from other methods. For example, RFC 2284bis is clear that an Identity Request MUST NOT be NAK'd (e.g. Identity is explicitly excluded from the list of "authentication methods" which can be NAK'd). So Identity isn't really "just like any other method". It seems like you are arguing that Identity Request (unlike Notification Request) doesn't appear to be invokable from other methods, nor can the Identity Response data be assumed to be delivered to other methods, correct? It seems like the main function of Identity is message routing, but there are circumstances (e.g. an AP used in a home) where there is no message routing, and so the Identity would not be needed -- and in the interest of better roaming performance, the less round-trips the better. So it would seem that if a method needs the user identity, then a method-specific identity exchange is probably the way to go, particularly since this approach allows the method to be more specific about what kind of identity information it wants (e.g. a cert exchange payload). From jrv@interlinknetworks.com Wed Oct 9 12:25:07 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 09 Oct 2002 07:25:07 -0400 Subject: [eap] Issue 36: When may a NAK be sent? References: Message-ID: <3DA41213.12455D2F@interlinknetworks.com> Bernard Aboba wrote: > > > I am not sure about this. I wonder what a peer method does if it gets > > req in the middle of a method that doesn't seem right. Does it quietly > > discard? I should think it might want a way to positively indicate that > > it was not happy. > > I think that this requires a method-specific error message, no? The > problem with allowing a NAK in the middle of the method is that the NAK is > unprotected, and has very limited semantics, so that it can't serve as a > general purpose error message, and can be easily spoofed. Plus, like > Notification, you can't assume that the Nak is delivered to the method. I agree that the NAK doesn't get sent directly to the method. But if there were an API, I would think it would indicate to the method that it was no longer the method of choice so it could clean up. So -- thinking of the possibility of peer and authenticator methods that may have a bug - what does a peer do when it gets arequest for a method that it thinks is done? From jrv@interlinknetworks.com Wed Oct 9 12:20:54 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 09 Oct 2002 07:20:54 -0400 Subject: [eap] Issue 35: Notification Usage References: Message-ID: <3DA41115.315273F3@interlinknetworks.com> Bernard Aboba wrote: > > > To > > A Notification Response is > > typically generated by the EAP layer; the Notification Data MUST NOT be > > forwarded to methods other than Notification. > > How about this? > > "A Notification Response is typically generated automatically by the EAP > layer; therefore the contents of a Notification Request MUST NOT be > delivered to a peer method other than Notification." > sounds good to me From jari.arkko@piuha.net Wed Oct 9 16:03:19 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 09 Oct 2002 18:03:19 +0300 Subject: [eap] Issue 37: EAP stack representation References: Message-ID: <3DA44537.8080709@piuha.net> Bernard Aboba wrote: > It seems like the main function of Identity is message routing, but there > are circumstances (e.g. an AP used in a home) where there is no > message routing, and so the Identity would not be needed -- and in the > interest of better roaming performance, the less round-trips the better. > > So it would seem that if a method needs the user identity, then > a method-specific identity exchange is probably the way to go, > particularly since this approach allows the method to be more > specific about what kind of identity information it wants > (e.g. a cert exchange payload). I'm pretty sure most methods require user identity. How would you otherwise dig up the right password from the db to perform your crypto on? Is the discussion about whether the methods can (a) get the identity information which has already been provided, (b) invoke Identity request when needed before their own execution, or (c) invoke Identity request during their own execution? I'm not sure we should limit identity requests just for message routing purposes. I agree though that in some cases (AP at home, cert exchange) we don't need identity requests, and we should allow the optimization to skip a roundtrip. Jari From jsalowey@cisco.com Wed Oct 9 16:05:45 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 09 Oct 2002 08:05:45 -0700 Subject: [eap] Issue 37: EAP stack representation In-Reply-To: References: <4.3.2.7.2.20021008154101.021668a8@e2k-sea-xch1.cisco.com> Message-ID: <4.3.2.7.2.20021009075426.020a1470@e2k-sea-xch1.cisco.com> At 10:14 PM 10/8/2002 -0700, Bernard Aboba wrote: > > I like the idea of separating the Identity as a separate method invoked by > > "EAP". I am uncertain about having Identity invoked from other > > methods. The Identity messages do not allow you to request a mechanism > > specific identity so how can a mechanism be sure it is going to get the > > right type of identity if it invokes the identity method? > >In reviewing RFC 2284bis, there are a number of places where Identity is >treated differently from other methods. For example, RFC 2284bis is clear >that an Identity Request MUST NOT be NAK'd (e.g. Identity is explicitly >excluded from the list of "authentication methods" which can be NAK'd). >So Identity isn't really "just like any other method". > >It seems like you are arguing that Identity Request (unlike Notification >Request) doesn't appear to be invokable from other methods, nor can the >Identity Response data be assumed to be delivered to other methods, >correct? Mostly. I think some methods require the information from the identity response. Perhaps this should be discouraged. >It seems like the main function of Identity is message routing, but there >are circumstances (e.g. an AP used in a home) where there is no >message routing, and so the Identity would not be needed -- and in the >interest of better roaming performance, the less round-trips the better. >So it would seem that if a method needs the user identity, then >a method-specific identity exchange is probably the way to go, >particularly since this approach allows the method to be more >specific about what kind of identity information it wants >(e.g. a cert exchange payload). I agree with this. Joe From aboba@internaut.com Wed Oct 9 15:06:05 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Oct 2002 07:06:05 -0700 (PDT) Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <3DA44537.8080709@piuha.net> Message-ID: > I'm pretty sure most methods require user identity. How would you > otherwise dig up the right password from the db to perform your > crypto on? Is the discussion about whether the methods can (a) > get the identity information which has already been provided, > (b) invoke Identity request when needed before their own execution, > or (c) invoke Identity request during their own execution? I think that all three issues may be relevant to on-the-wire interoperability. > I agree though that in some cases (AP at home, cert > exchange) we don't need identity requests, and we should > allow the optimization to skip a roundtrip. The Identity Exchange is optional in RFC 2284 -- but is required in 802.1X. So that's a conflict that needs to be resolved. From jsalowey@cisco.com Wed Oct 9 16:24:31 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 09 Oct 2002 08:24:31 -0700 Subject: [eap] Issue 37: EAP stack representation In-Reply-To: <3DA44537.8080709@piuha.net> References: Message-ID: <4.3.2.7.2.20021009081645.021a3318@e2k-sea-xch1.cisco.com> At 06:03 PM 10/9/2002 +0300, Jari Arkko wrote: >Bernard Aboba wrote: > >>It seems like the main function of Identity is message routing, but there >>are circumstances (e.g. an AP used in a home) where there is no >>message routing, and so the Identity would not be needed -- and in the >>interest of better roaming performance, the less round-trips the better. >>So it would seem that if a method needs the user identity, then >>a method-specific identity exchange is probably the way to go, >>particularly since this approach allows the method to be more >>specific about what kind of identity information it wants >>(e.g. a cert exchange payload). > >I'm pretty sure most methods require user identity. How would you >otherwise dig up the right password from the db to perform your >crypto on? Is the discussion about whether the methods can (a) >get the identity information which has already been provided, >(b) invoke Identity request when needed before their own execution, >or (c) invoke Identity request during their own execution? I suggest that identity should be retrieved by the mechanism (in a mechanism specific fashion). I realize that there are some existing mechanism that require identity exchange, but I think we should discourage methods from doing this. >I'm not sure we should limit identity requests just for >message routing purposes. Perhaps not, but right now I think I would like to. >I agree though that in some cases (AP at home, cert >exchange) we don't need identity requests, and we should >allow the optimization to skip a roundtrip. > >Jari From aboba@internaut.com Wed Oct 9 16:28:30 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Oct 2002 08:28:30 -0700 (PDT) Subject: [eap] Issue 39: When can an Identity Request be sent? Message-ID: Issue 39: When can an Identity Request be sent? Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 9, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: >From Jari's position paper: "- Identity request: In theory one might think of a method that requires a second identity to be sent during its progress. However, I think this would complicate the protocol too much. Let's just forbid identity request in all other states than Unauthenticated." Change: " The Identity Type is used to query the identity of the peer. The Authenticator will typically issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there is an expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity)." To: " The Identity Type is used to query the identity of the peer. The Authenticator will typically issue this as the initial Request; an Identity Request MUST NOT be sent in the middle of a method, although it could be sent multiple times within a sequence of methods. An optional displayable message MAY be included to prompt the Peer in the case where there is an expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity). A peer MUST NOT respond to an Identity Request with a NAK. A method resident on the authenticator can be assumed to have access to the Identity Response returned by the peer, even though that message is not directed to the method. Since the Identity Request is often sent automatically by the authenticator, the Identity method may be thought of as residing within the EAP layer. Where the Identity Request is not sent automatically, there SHOULD be a way for a method to request that the Identity Request be sent, in case no method-specific identity request is available, and a claim of identity is required by the method. Sending an Identity Request is optional on the authenticator, and implementations SHOULD provide a way to configure the authenticator so that Identity Requests are not sent." From rodrigo.garces@mobilitynetworks.com Thu Oct 10 19:23:07 2002 From: rodrigo.garces@mobilitynetworks.com (Garces, Rodrigo) Date: Thu, 10 Oct 2002 11:23:07 -0700 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 Message-ID: <9E4B2EDBC48E0F48B9B8F968F817928D1745D8@mail1.mobility.int> Here are some issues and concerns with EAP-SIM 1) It seems to me that the number of messages could probably be reduce = and still achieve the goal of providing SIM based authentication using = EAP. At the same time EAP-SIM should not required any changes or minimum = changes to the operators for it to be accepted as a standard.=20 2) Why should there be any restrictions or additions to the pseudonym = grammar beyond what is there today in 3GPP?=20 3) Is there some protocol that depends upon the Authenticator knowing = the pseudonym? 4) If the pseudonym is lost in the authentication server, the supplicant = can be locked out of the network for ever as it does not have to respond = to the identity request. This sounds bad. 5) The maximum lengths of the fields in the 'message format' section is = 1020 bytes, not 1024. 6) Is the concatenated "1" in front of the IMSI really useful? Will it = save any protocol bytes or messages? =20 If not, let's drop it. I still do not see the usefulness of having the = concatenated "1". 7) The EAP-SIM seems to imply that there is a need for owlan,org. Who = will be running the .owlan.org service? 8) Why is the message subtype included in the MAC_SRES hash? Does this = provide any further security? regards,=20 Rodrigo Garces Mobility Networks From jsalowey@cisco.com Thu Oct 10 19:44:31 2002 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 10 Oct 2002 11:44:31 -0700 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 In-Reply-To: <9E4B2EDBC48E0F48B9B8F968F817928D1745D8@mail1.mobility.int> Message-ID: <4.3.2.7.2.20021010112208.020d27a0@e2k-sea-xch1.cisco.com> At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: >Here are some issues and concerns with EAP-SIM > > >1) It seems to me that the number of messages could probably be reduce and >still achieve the goal of providing SIM based authentication using EAP. At >the same time EAP-SIM should not required any changes or minimum changes >to the operators for it to be accepted as a standard. What do you have in mind? >2) Why should there be any restrictions or additions to the pseudonym >grammar beyond what is there today in 3GPP? I don't think there are any restrictions on the Pseudonym grammar. I don't think the 3GPP restrictions necessarily apply. >3) Is there some protocol that depends upon the Authenticator knowing the >pseudonym? How the authentication server manages the pseudonym is not defined in this document. Is this what you mean? >4) If the pseudonym is lost in the authentication server, the supplicant >can be locked out of the network for ever as it does not have to respond >to the identity request. This sounds bad. THis depends upon the implementation. It is possible for the implementation to allow manual intervention so the client knows they are sending their clear IMSI and can choose to accept that risk. Other implementations on the client are possible. >5) The maximum lengths of the fields in the 'message format' section is >1020 bytes, not 1024. > >6) Is the concatenated "1" in front of the IMSI really useful? Will it >save any protocol bytes or messages? >If not, let's drop it. I still do not see the usefulness of having the >concatenated "1". Good question. >7) The EAP-SIM seems to imply that there is a need for owlan,org. Who will >be running the .owlan.org service? What do you mean by owlan.org service? >8) Why is the message subtype included in the MAC_SRES hash? Does this >provide any further security? See changes in draft 6 which is now available >regards, > >Rodrigo Garces >Mobility Networks >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From rodrigo.garces@mobilitynetworks.com Thu Oct 10 20:49:32 2002 From: rodrigo.garces@mobilitynetworks.com (Garces, Rodrigo) Date: Thu, 10 Oct 2002 12:49:32 -0700 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 Message-ID: <9E4B2EDBC48E0F48B9B8F968F817928D1745DE@mail1.mobility.int> Getting back to point 7, in section 5 of the draft v6, it is stated=20 If no configured realm name is available, the client MAY derive the=20 realm name from the MCC and MNC portions of the IMSI. In this case,=20 the realm name is obtained by concatenating "mnc", the MNC digits of=20 IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org". For example,=20 if the IMSI is 123456789098765, and the MNC is three digits long,=20 then the derived realm name is "mnc456.mcc123.owlan.org".=20 If the client is not able to determine whether the MNC is two or=20 three digits long, the client MAY use a 3-digit MNC. If the correct=20 length of the MNC is two, then the MNC used in the realm name will=20 include the first digit of MSIN. Hence, when configuring AAA=20 networks for operators that have 2-digit MNC's, the network SHOULD=20 also be prepared for realm names with incorrect 3-digit MNC's.=20 What we are concern is who will be maintaining the DNS entry for = owlan.org?=20 Who is in charge of doing so? =20 -----Original Message----- From: Joseph Salowey [mailto:jsalowey@cisco.com] Sent: Thursday, October 10, 2002 11:45 AM To: Garces, Rodrigo Cc: henry.haverinen@nokia.com; eap@frascone.com Subject: Re: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: >Here are some issues and concerns with EAP-SIM > > >1) It seems to me that the number of messages could probably be reduce = and=20 >still achieve the goal of providing SIM based authentication using EAP. = At=20 >the same time EAP-SIM should not required any changes or minimum = changes=20 >to the operators for it to be accepted as a standard. What do you have in mind? >2) Why should there be any restrictions or additions to the pseudonym=20 >grammar beyond what is there today in 3GPP? I don't think there are any restrictions on the Pseudonym grammar. I = don't=20 think the 3GPP restrictions necessarily apply. >3) Is there some protocol that depends upon the Authenticator knowing = the=20 >pseudonym? How the authentication server manages the pseudonym is not defined in = this=20 document. Is this what you mean? >4) If the pseudonym is lost in the authentication server, the = supplicant=20 >can be locked out of the network for ever as it does not have to = respond=20 >to the identity request. This sounds bad. THis depends upon the implementation. It is possible for the = implementation=20 to allow manual intervention so the client knows they are sending their=20 clear IMSI and can choose to accept that risk. Other implementations on = the client are possible. >5) The maximum lengths of the fields in the 'message format' section is = >1020 bytes, not 1024. > >6) Is the concatenated "1" in front of the IMSI really useful? Will it = >save any protocol bytes or messages? >If not, let's drop it. I still do not see the usefulness of having the=20 >concatenated "1". Good question. >7) The EAP-SIM seems to imply that there is a need for owlan,org. Who = will=20 >be running the .owlan.org service? What do you mean by owlan.org service? >8) Why is the message subtype included in the MAC_SRES hash? Does this = >provide any further security? See changes in draft 6 which is now available >regards, > >Rodrigo Garces >Mobility Networks >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From twieland@cisco.com Thu Oct 10 21:43:40 2002 From: twieland@cisco.com (Thomas Wieland) Date: Thu, 10 Oct 2002 13:43:40 -0700 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 In-Reply-To: <9E4B2EDBC48E0F48B9B8F968F817928D1745DE@mail1.mobility.int> Message-ID: <4.3.2.7.2.20021010134049.00ccae10@mira-sjc5-4.cisco.com> Rodrigo, see Chapter 16. IANA Considerations The realm name "owlan.org" has been reserved for NAI realm names generated from the IMSI. Also see: # whois owlan.org Whois Server Version 1.3 Domain Name: OWLAN.ORG Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE Whois Server: whois.melbourneit.com Referral URL: http://www.melbourneit.com Name Server: NS.NOKIA.COM Name Server: NS2.NOKIA.COM Name Server: NSHK.EXT.NOKIA.COM Name Server: NSDA.EXT.NOKIA.COM Updated Date: 01-mar-2002 >>> Last update of whois database: Thu, 10 Oct 2002 04:53:24 EDT <<< So the short answer is: Nokia Regards, Thomas Wieland Cisco Systems, Inc. At 12:49 10-10-02 -0700, Garces, Rodrigo wrote: >Getting back to point 7, in section 5 of the draft v6, it is stated > > > If no configured realm name is available, the client MAY derive the > realm name from the MCC and MNC portions of the IMSI. In this case, > the realm name is obtained by concatenating "mnc", the MNC digits of > IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org". For example, > if the IMSI is 123456789098765, and the MNC is three digits long, > then the derived realm name is "mnc456.mcc123.owlan.org". > > If the client is not able to determine whether the MNC is two or > three digits long, the client MAY use a 3-digit MNC. If the correct > length of the MNC is two, then the MNC used in the realm name will > include the first digit of MSIN. Hence, when configuring AAA > networks for operators that have 2-digit MNC's, the network SHOULD > also be prepared for realm names with incorrect 3-digit MNC's. > >What we are concern is who will be maintaining the DNS entry for owlan.org? >Who is in charge of doing so? > >-----Original Message----- >From: Joseph Salowey [mailto:jsalowey@cisco.com] >Sent: Thursday, October 10, 2002 11:45 AM >To: Garces, Rodrigo >Cc: henry.haverinen@nokia.com; eap@frascone.com >Subject: Re: [eap] Issues and Questions >draft-haverinen-pppext-eap-sim-05 > > >At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: > >>Here are some issues and concerns with EAP-SIM >> >> >>1) It seems to me that the number of messages could probably be reduce and >>still achieve the goal of providing SIM based authentication using EAP. At >>the same time EAP-SIM should not required any changes or minimum changes >>to the operators for it to be accepted as a standard. > >What do you have in mind? > >>2) Why should there be any restrictions or additions to the pseudonym >>grammar beyond what is there today in 3GPP? > >I don't think there are any restrictions on the Pseudonym grammar. I don't >think the 3GPP restrictions necessarily apply. > >>3) Is there some protocol that depends upon the Authenticator knowing the >>pseudonym? > >How the authentication server manages the pseudonym is not defined in this >document. Is this what you mean? > >>4) If the pseudonym is lost in the authentication server, the supplicant >>can be locked out of the network for ever as it does not have to respond >>to the identity request. This sounds bad. > >THis depends upon the implementation. It is possible for the implementation >to allow manual intervention so the client knows they are sending their >clear IMSI and can choose to accept that risk. Other implementations on >the client are possible. > >>5) The maximum lengths of the fields in the 'message format' section is >>1020 bytes, not 1024. >> >>6) Is the concatenated "1" in front of the IMSI really useful? Will it >>save any protocol bytes or messages? >>If not, let's drop it. I still do not see the usefulness of having the >>concatenated "1". > >Good question. > >>7) The EAP-SIM seems to imply that there is a need for owlan,org. Who will >>be running the .owlan.org service? > >What do you mean by owlan.org service? > >>8) Why is the message subtype included in the MAC_SRES hash? Does this >>provide any further security? > >See changes in draft 6 which is now available > > >>regards, >> >>Rodrigo Garces >>Mobility Networks >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap From mayank.chaudhary@mobilitynetworks.com Thu Oct 10 22:47:48 2002 From: mayank.chaudhary@mobilitynetworks.com (Chaudhary, Mayank) Date: Thu, 10 Oct 2002 14:47:48 -0700 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 Message-ID: <9E4B2EDBC48E0F48B9B8F968F817928D171913@mail1.mobility.int> Hi All, I think it is in the best interest of all operators and WISPs involved = to have the domain registered with a third-party "neutral" vendor. Could = IESG or 3GPP take ownership of this domain ? We dont want to be in a = position where RADIUS messages being routed thru the=20 top-level RADIUS domain server are under the control of a single entity. thanks -mayank > -----Original Message----- > From: Thomas Wieland [SMTP:twieland@cisco.com] > Sent: Thursday, October 10, 2002 1:44 PM > To: Garces, Rodrigo > Cc: Joseph Salowey; henry.haverinen@nokia.com; eap@frascone.com > Subject: RE: [eap] Issues and Questions = draft-haverinen-pppext-eap-sim-05 >=20 >=20 > Rodrigo, >=20 > see Chapter 16. IANA Considerations=20 >=20 > The realm name "owlan.org" has been reserved for NAI realm names=20 > generated from the IMSI.=20 >=20 >=20 > Also see: >=20 > # whois owlan.org >=20 > Whois Server Version 1.3 >=20 > Domain Name: OWLAN.ORG > Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE > Whois Server: whois.melbourneit.com > Referral URL: http://www.melbourneit.com > Name Server: NS.NOKIA.COM > Name Server: NS2.NOKIA.COM > Name Server: NSHK.EXT.NOKIA.COM > Name Server: NSDA.EXT.NOKIA.COM > Updated Date: 01-mar-2002 >=20 > >>> Last update of whois database: Thu, 10 Oct 2002 04:53:24 EDT <<< >=20 >=20 > So the short answer is: Nokia >=20 > Regards, >=20 > Thomas Wieland > Cisco Systems, Inc. >=20 >=20 > At 12:49 10-10-02 -0700, Garces, Rodrigo wrote: > >Getting back to point 7, in section 5 of the draft v6, it is stated=20 > > > > > > If no configured realm name is available, the client MAY derive = the=20 > > realm name from the MCC and MNC portions of the IMSI. In this = case,=20 > > the realm name is obtained by concatenating "mnc", the MNC digits = of=20 > > IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org". For = example,=20 > > if the IMSI is 123456789098765, and the MNC is three digits long,=20 > > then the derived realm name is "mnc456.mcc123.owlan.org".=20 > > > > If the client is not able to determine whether the MNC is two or=20 > > three digits long, the client MAY use a 3-digit MNC. If the = correct=20 > > length of the MNC is two, then the MNC used in the realm name will = > > include the first digit of MSIN. Hence, when configuring AAA=20 > > networks for operators that have 2-digit MNC's, the network SHOULD = > > also be prepared for realm names with incorrect 3-digit MNC's.=20 > > > >What we are concern is who will be maintaining the DNS entry for = owlan.org?=20 > >Who is in charge of doing so? =20 > > > >-----Original Message----- > >From: Joseph Salowey [mailto:jsalowey@cisco.com] > >Sent: Thursday, October 10, 2002 11:45 AM > >To: Garces, Rodrigo > >Cc: henry.haverinen@nokia.com; eap@frascone.com > >Subject: Re: [eap] Issues and Questions > >draft-haverinen-pppext-eap-sim-05 > > > > > >At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: > > > >>Here are some issues and concerns with EAP-SIM > >> > >> > >>1) It seems to me that the number of messages could probably be = reduce and=20 > >>still achieve the goal of providing SIM based authentication using = EAP. At=20 > >>the same time EAP-SIM should not required any changes or minimum = changes=20 > >>to the operators for it to be accepted as a standard. > > > >What do you have in mind? > > > >>2) Why should there be any restrictions or additions to the = pseudonym=20 > >>grammar beyond what is there today in 3GPP? > > > >I don't think there are any restrictions on the Pseudonym grammar. I = don't=20 > >think the 3GPP restrictions necessarily apply. > > > >>3) Is there some protocol that depends upon the Authenticator = knowing the=20 > >>pseudonym? > > > >How the authentication server manages the pseudonym is not defined in = this=20 > >document. Is this what you mean? > > > >>4) If the pseudonym is lost in the authentication server, the = supplicant=20 > >>can be locked out of the network for ever as it does not have to = respond=20 > >>to the identity request. This sounds bad.>=20 > > > >THis depends upon the implementation. It is possible for the = implementation=20 > >to allow manual intervention so the client knows they are sending = their=20 > >clear IMSI and can choose to accept that risk. Other implementations = on=20 > >the client are possible. > > > >>5) The maximum lengths of the fields in the 'message format' section = is=20 > >>1020 bytes, not 1024. > >> > >>6) Is the concatenated "1" in front of the IMSI really useful? Will = it=20 > >>save any protocol bytes or messages? > >>If not, let's drop it. I still do not see the usefulness of having = the=20 > >>concatenated "1". > > > >Good question. > > > >>7) The EAP-SIM seems to imply that there is a need for owlan,org. = Who will=20 > >>be running the .owlan.org service? > > > >What do you mean by owlan.org service? > > > >>8) Why is the message subtype included in the MAC_SRES hash? Does = this=20 > >>provide any further security? > > > >See changes in draft 6 which is now available > > > > > >>regards, > >> > >>Rodrigo Garces > >>Mobility Networks > >>_______________________________________________ > >>eap mailing list > >>eap@frascone.com > >>http://mail.frascone.com/mailman/listinfo/eap > > > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From henry.haverinen@nokia.com Fri Oct 11 11:14:12 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Fri, 11 Oct 2002 13:14:12 +0300 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 Message-ID: Hello, Nokia has reserved the owlan.org realm name, just to have=20 a name available for the specification. We don't have any=20 plans to run DNS servers for the realm or (do anything else with the realm), so for now the realm name can only be used for=20 configured RADIUS routing that is not based on DNS. However, as it may be very useful to DNS for AAA routing, we're hoping to find a relevant organization to take up the owlan.org realm name.=20 Regards, Henry > -----Original Message----- > From: ext Thomas Wieland [mailto:twieland@cisco.com] > Sent: 10 October, 2002 23:44 > To: Garces, Rodrigo > Cc: Joseph Salowey; Haverinen Henry (NMP/Tampere); eap@frascone.com > Subject: RE: [eap] Issues and Questions > draft-haverinen-pppext-eap-sim-05 >=20 >=20 >=20 > Rodrigo, >=20 > see Chapter 16. IANA Considerations=20 >=20 > The realm name "owlan.org" has been reserved for NAI realm names=20 > generated from the IMSI.=20 >=20 >=20 > Also see: >=20 > # whois owlan.org >=20 > Whois Server Version 1.3 >=20 > Domain Name: OWLAN.ORG > Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE > Whois Server: whois.melbourneit.com > Referral URL: http://www.melbourneit.com > Name Server: NS.NOKIA.COM > Name Server: NS2.NOKIA.COM > Name Server: NSHK.EXT.NOKIA.COM > Name Server: NSDA.EXT.NOKIA.COM > Updated Date: 01-mar-2002 >=20 > >>> Last update of whois database: Thu, 10 Oct 2002 04:53:24 EDT <<< >=20 >=20 > So the short answer is: Nokia >=20 > Regards, >=20 > Thomas Wieland > Cisco Systems, Inc. >=20 >=20 > At 12:49 10-10-02 -0700, Garces, Rodrigo wrote: > >Getting back to point 7, in section 5 of the draft v6, it is stated=20 > > > > > > If no configured realm name is available, the client MAY=20 > derive the=20 > > realm name from the MCC and MNC portions of the IMSI. In=20 > this case,=20 > > the realm name is obtained by concatenating "mnc", the=20 > MNC digits of=20 > > IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org".=20 > For example,=20 > > if the IMSI is 123456789098765, and the MNC is three digits long,=20 > > then the derived realm name is "mnc456.mcc123.owlan.org".=20 > > > > If the client is not able to determine whether the MNC is two or=20 > > three digits long, the client MAY use a 3-digit MNC. If=20 > the correct=20 > > length of the MNC is two, then the MNC used in the realm=20 > name will=20 > > include the first digit of MSIN. Hence, when configuring AAA=20 > > networks for operators that have 2-digit MNC's, the=20 > network SHOULD=20 > > also be prepared for realm names with incorrect 3-digit MNC's.=20 > > > >What we are concern is who will be maintaining the DNS entry=20 > for owlan.org?=20 > >Who is in charge of doing so? =20 > > > >-----Original Message----- > >From: Joseph Salowey [mailto:jsalowey@cisco.com] > >Sent: Thursday, October 10, 2002 11:45 AM > >To: Garces, Rodrigo > >Cc: henry.haverinen@nokia.com; eap@frascone.com > >Subject: Re: [eap] Issues and Questions > >draft-haverinen-pppext-eap-sim-05 > > > > > >At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: > > > >>Here are some issues and concerns with EAP-SIM > >> > >> > >>1) It seems to me that the number of messages could=20 > probably be reduce and=20 > >>still achieve the goal of providing SIM based=20 > authentication using EAP. At=20 > >>the same time EAP-SIM should not required any changes or=20 > minimum changes=20 > >>to the operators for it to be accepted as a standard. > > > >What do you have in mind? > > > >>2) Why should there be any restrictions or additions to the=20 > pseudonym=20 > >>grammar beyond what is there today in 3GPP? > > > >I don't think there are any restrictions on the Pseudonym=20 > grammar. I don't=20 > >think the 3GPP restrictions necessarily apply. > > > >>3) Is there some protocol that depends upon the=20 > Authenticator knowing the=20 > >>pseudonym? > > > >How the authentication server manages the pseudonym is not=20 > defined in this=20 > >document. Is this what you mean? > > > >>4) If the pseudonym is lost in the authentication server,=20 > the supplicant=20 > >>can be locked out of the network for ever as it does not=20 > have to respond=20 > >>to the identity request. This sounds bad. > > > >THis depends upon the implementation. It is possible for the=20 > implementation=20 > >to allow manual intervention so the client knows they are=20 > sending their=20 > >clear IMSI and can choose to accept that risk. Other=20 > implementations on=20 > >the client are possible. > > > >>5) The maximum lengths of the fields in the 'message=20 > format' section is=20 > >>1020 bytes, not 1024. > >> > >>6) Is the concatenated "1" in front of the IMSI really=20 > useful? Will it=20 > >>save any protocol bytes or messages? > >>If not, let's drop it. I still do not see the usefulness of=20 > having the=20 > >>concatenated "1". > > > >Good question. > > > >>7) The EAP-SIM seems to imply that there is a need for=20 > owlan,org. Who will=20 > >>be running the .owlan.org service? > > > >What do you mean by owlan.org service? > > > >>8) Why is the message subtype included in the MAC_SRES=20 > hash? Does this=20 > >>provide any further security? > > > >See changes in draft 6 which is now available > > > > > >>regards, > >> > >>Rodrigo Garces > >>Mobility Networks > >>_______________________________________________ > >>eap mailing list > >>eap@frascone.com > >>http://mail.frascone.com/mailman/listinfo/eap > > > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap=20 >=20 >=20 From henry.haverinen@nokia.com Fri Oct 11 12:00:50 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Fri, 11 Oct 2002 14:00:50 +0300 Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05 Message-ID: Rodrigo, Thanks for your comments. As Joe pointed out, some of them are resolved in the latest version (06). > From: ext Joseph Salowey [mailto:jsalowey@cisco.com] > At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote: > >5) The maximum lengths of the fields in the 'message format'=20 > section is=20 > >1020 bytes, not 1024. Thanks. > >6) Is the concatenated "1" in front of the IMSI really=20 > useful? Will it=20 > >save any protocol bytes or messages? > >If not, let's drop it. I still do not see the usefulness of=20 > having the=20 > >concatenated "1". >=20 > Good question. EAP SIM and EAP AKA have essentially the same identity format, expect for the leading character. So the leading character could actually save protocol messages because it can be used as a hint of which one of these two EAP types the client wants to use. For an example scenario where roundtrips could be saved is a UMTS subscriber whose terminal only implements EAP SIM.=20 Best regards, Henry From henry.haverinen@nokia.com Fri Oct 11 12:04:46 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Fri, 11 Oct 2002 14:04:46 +0300 Subject: [eap] New EAP SIM and EAP AKA drafts Message-ID: Hello, New versions of EAP SIM and EAP AKA are now available at the IETF directories. The issues previously discussed on this mailing list are now addressed. There is also a new re-authentication procedure. Joe Salowey is a new co-author of EAP SIM. Regards, Henry From aboba@internaut.com Fri Oct 11 16:54:45 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 11 Oct 2002 08:54:45 -0700 (PDT) Subject: [eap] P802.1aa/D3 ballot resolutions (fwd) Message-ID: Note that several of the proposed resolutions bring 802.1X closer to conformance with RFC 2284 and RFC 2869. -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Friday, October 11, 2002 3:16 AM To: stds-802-1@ieee.org Subject: P802.1aa/D3 ballot resolutions I have placed the final ballot resolution document for P802.1aa/D3 at: http://www.ieee802.org/1/mirror/8021/aa-drafts/d3/802-1aa-d3-dis.pdf Username: p8021 Password: go_wildcats Regards, Tony From aboba@internaut.com Fri Oct 11 21:32:16 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 11 Oct 2002 13:32:16 -0700 (PDT) Subject: [eap] P802.1aa/D3 ballot resolutions (fwd) Message-ID: Worth reading. I believe that this resolves quite a few of the incompatibilities between 802.1X and RFC 2284bis. -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Friday, October 11, 2002 3:16 AM To: stds-802-1@ieee.org Subject: P802.1aa/D3 ballot resolutions I have placed the final ballot resolution document for P802.1aa/D3 at: http://www.ieee802.org/1/mirror/8021/aa-drafts/d3/802-1aa-d3-dis.pdf Username: p8021 Password: go_wildcats Regards, Tony From aboba@internaut.com Fri Oct 11 21:34:21 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 11 Oct 2002 13:34:21 -0700 (PDT) Subject: [eap] Minutes of eap design team meeting, october 9th, 2002 (fwd) Message-ID: Minutes of the EAP state machine Design Team conference call Jari Arkko, Scribe Date: October 9th, 2002, 18:00-19:00 EET 1. Agenda - Report on 802.1aa (Bob Moskowitz) - University of Maryland position paper - Bernard's position paper - Jari's position paper 2. Report on 802.1aa Bob was the only one present in the 802.1aa meeting, but he wasn't present in the conference call. 3. Jari's position paper This position paper studied whether the proposed EAP state machine has (message, state) pairs for which no actions have been defined. Several such pairs were found. Some of these pair are missing on purpose, while others are either mistakes or underspecification. The paper classified the issues around the following main problems: - When can Failure come? - When can NAK come? - When can Identity Reques come? - When can Notification come? - Should 2nd, 3rd, ... internal method requests be modelled in the main state machine? - Should we treat protocol errors in the state machine or not? o Failure: - The issue is whether peer should accept Failure only after a method execution, or also in the unauthenticated state before any methods. - DECISION: Peer should accept Failure in unauthenticated state. - There was a discussion of whether such failures can be based on the NAI given in an Identity Response. There are security issues around exposing valid / invalid user names. It was unclear whether ther are similar issues in exposing domains for which the authenticator is unable to perform authentication. - DECISION: We should document the security considerations about this, but not prevent / mandate any specific behaviour. - Bernard: Filters may prevent failure messages if the method is protected and wants a protected failure report. Methods may install such filters. o NAK: - We decided to talk about this in more general manner in the context of protocol errors. o Identity request: - The issue is whether Identity Request can be nakked, whether Identity Request can be repeated, whether it can come during the execution of a method or only in between. - Also, can a method ask for an identity request to be sent? - Can a method get the information from an identity response? - John asked whether the state machine goes through the unauthenticated state as it moves from one method to another. The answer is yes. - Bernard said that we should avoid having to give policy for EAP nodes; this is usually a sign of a lack of specification. Sequences of methods, different combinations can create problems and lots of Nakking if policies dictate too much. - Is identity a method? Can you nak identity? RFC says no, and some implementations are known to not be able to process such Naks. - Bernard: RFC set Identity Requests to be optional, but 802.1x made it mandatory. This is a conflict. What if both sides don't want it? - Bernard: Perhaps we should request 802.1x to make it optional also. This may not be easily adopted by 802.1aa, however. One issue is that they would like to have a solution from the IETF that works without configuration. - Jari: There is a danger that if we don't allow Naks, we will soon develop a convention where an empty NAI implies that the identity does not exist or we don't want to give it. - DECISION: Identity request/response can only appear between methods - DECISION: Our preference is that identity requests be optional. (And we are leaning towards making Nak disallowed.) - DECISION: Work on the text on the list. - DECISION: Talk with 802.1aa about the situation. o Notification: - DECISION: Discussion elsewhere appears to lead to allowing Notification in all states. - DECISION: Can not be Nakked. o 2nd, 3rd messages - John: Multiplexor model will make this clearer - Can we execute methods in parallel, 1st message from 1st method, 1st message from 2nd method, ... 2nd message from the 1st method, 2nd message from the 2nd method, ...? - DECISION: No. Methods must be done one at a time. - There must be a concept of activating and deactivating a method. - Bernard: Acceptance locks you to the method - Jari: Do we need to model this in state machine? - John: yes o Protocol errors: - The issue is whether the state machine should say something about what to do when invalid EAP messages arrive. This may be necessary for recovery etc. purposes. - Bernard: There's certainly errors in individual methods. - Not all protocol errors need the same treatment - Bernard: Its a reasonable question to ask what to do in a protocol ertor situation, if the spec says somethign is that - Should silent discard be used? - We should avoid making Denial-of-Service attacks too easy - John would like to have positive confirmation of a failure rather than stubbornly trying and timing out later - Servers could send a Notification - There is a usability tradeoff: failure report quickly vs better Denial-of-Service resistance - John: Could we send a Nak with a message? - Bernard: Implementation backwards compatibility prevents NAK changes - Is there a need for a new message? - Jari: We have the following options to deal with unexpected protocol messages: 1) Silent discard and wait for proper message; this often leads to a timeout if the discarded message really was from the authenticator. 2) Immediately abort everthing and exit from EAP. This provides a quick indiciation to the user, but is very fragile wrt Denial-of-Service attacks. 3) Provide a new abort message with support for authenticating that the other side really sent the offending message. It is unclear how complicated this is. 4) A new notification message could be design for peer=>authenticator direction. This would allow implementations to report problems, without making the protocol very vulnerable to Denial-of-Service. - DECISION: We need separate discussion on errors. - Jari: I will write something about it. 4. Concluding remarks - Other two position papers will be dealt with later. - John: We've made a lot of progress lately in the issues. The main remaining issues are policy issues and dealing with protocol errors. - Jari: We will continue with the conference calls, but probably need also to do e-mail reviews of the position papers. From aboba@internaut.com Fri Oct 11 22:29:15 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 11 Oct 2002 14:29:15 -0700 (PDT) Subject: [eap] EAP WG agenda items Message-ID: If you have agenda items for IETF 55, please send them to Jari and myself. We have two slots early in the week (see latest agenda). From aboba@internaut.com Sun Oct 13 04:03:58 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 12 Oct 2002 20:03:58 -0700 (PDT) Subject: [eap] EAP IANA Considerations Message-ID: It has been suggested that work on EAP might be sped up by early completion of an EAP IANA Considerations document. In order to encourage discussions on whether this makes sense or not, and if so, what the IANA considerations document should say, I've put up a strawman document for discussion: http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-eap-iana-02.txt Comments welcome. From jas@extundo.com Sun Oct 13 06:05:22 2002 From: jas@extundo.com (Simon Josefsson) Date: Sun, 13 Oct 2002 07:05:22 +0200 Subject: [eap] EAP IANA Considerations In-Reply-To: (Bernard Aboba's message of "Sat, 12 Oct 2002 20:03:58 -0700 (PDT)") References: Message-ID: Bernard Aboba writes: > It has been suggested that work on EAP might be sped up by early > completion of an EAP IANA Considerations document. In order to encourage > discussions on whether this makes sense or not, and if so, what the IANA > considerations document should say, I've put up a strawman document for > discussion: > > http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-eap-iana-02.txt > > Comments welcome. I still thinks this causes lots of work without no clear gain, and even potentially harms progress of EAP implementations if at some point in time the process of apointing and asking the Designated Expert is slowed down due to the busy schedules people have. What is the reason for all the manual work proposed in the draft? If the real reason is that the EAP method type space is limited, why not solve that technical problem with the technial solution, proposed in your document, of using type 255 as an expanded type space with room for 2^32 methods? Then IANA can continue to simply register EAP method types without going through the extra manual work each time. Of course, EAP method types that are proposed as IETF standards need extra scrutiny, but this is already taken care of by the IETF process. IANA need not to do IETF's job. This draft only causes more work for non-standards IETF EAP methods, and this likely means that people will simply pick an unused EAP method type and use it, which sort of destroys the whole point of having a EAP method registry. Sorry if this sounds harsh, but since I haven't understood the rationale behind this document maybe my reasoning is flawed. From aboba@internaut.com Sun Oct 13 05:32:20 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 12 Oct 2002 21:32:20 -0700 (PDT) Subject: [eap] EAP IANA Considerations In-Reply-To: Message-ID: > Sorry if this sounds harsh, but since I haven't understood the > rationale behind this document maybe my reasoning is flawed. The rationale is simple. IETF protocols creating new name spaces require an IANA considerations section. RFC 2284 doesn't have an IANA considerations section, so that there is currently no policy in place that describes how protocol parameters should be allocated. If you think that Designated Expert is unscalable, how about a situation where the WG chairs are asked to rule on the allocation (that's what happens in practice now). I take it that you are advocating a First Come, First Served policy for EAP method types? From jas@extundo.com Sun Oct 13 07:07:02 2002 From: jas@extundo.com (Simon Josefsson) Date: Sun, 13 Oct 2002 08:07:02 +0200 Subject: [eap] EAP IANA Considerations In-Reply-To: (Bernard Aboba's message of "Sat, 12 Oct 2002 21:32:20 -0700 (PDT)") References: Message-ID: Bernard Aboba writes: >> Sorry if this sounds harsh, but since I haven't understood the >> rationale behind this document maybe my reasoning is flawed. > > The rationale is simple. IETF protocols creating new name spaces require > an IANA considerations section. RFC 2284 doesn't have an IANA considerations > section, so that there is currently no policy in place that describes how > protocol parameters should be allocated. OK, so the document is useful. Only remains to argue about the contents then. :-) > If you think that Designated Expert is unscalable, how about a situation > where the WG chairs are asked to rule on the allocation (that's what > happens in practice now). Depends on what "rule on" implies. I don't think there has to be any serious technical evaluation before an EAP method type is allocated. This is how I perceive the current situation -- some of the IANA allocated types are only specified implicitly via running code. If "rule on" only implies a way to stop completely bogus registrations, it sounds fine. > I take it that you are advocating a First Come, First Served policy for > EAP method types? Yes. Unless there is a reason to do anything else, but I don't see one here. From aboba@internaut.com Sun Oct 13 06:44:51 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 12 Oct 2002 22:44:51 -0700 (PDT) Subject: [eap] EAP IANA Considerations In-Reply-To: Message-ID: > If "rule on" only implies a way to stop completely bogus > registrations, it sounds fine. The problem is defining what "completely bogus" means. Is it: a. A method that is non compliant with RFC 2284 in some respect b. A method with a bad security flaw c. A method that requires >N EAP type allocations? d. A method that uses EAP for some inappropriate purpose? And of course, who makes the decision, and on what basis? Is a specification required for a "standard" allocation (37-254)? If so, who says if it is good enough? If not, how do you decide what is "completely bogus"? Is the answer different in the "expanded" space (Type >255)? > Yes. Unless there is a reason to do anything else, but I don't see > one here. Are there limits to "first come, first served"? For example, can I request allocation of Types 37-254? Or is it FCFS for 1 Type, but some other policy for a block request? If so, how big is the block before the alternate policy is triggered? And what is the alternate procedure? And of course, there is a possible difference between "What the WG wants" and "What the IESG will accept". Welcome to the Wonderful World of IANA Allocation Policy :) From jas@extundo.com Sun Oct 13 08:50:07 2002 From: jas@extundo.com (Simon Josefsson) Date: Sun, 13 Oct 2002 09:50:07 +0200 Subject: [eap] EAP IANA Considerations In-Reply-To: (Bernard Aboba's message of "Sat, 12 Oct 2002 22:44:51 -0700 (PDT)") References: Message-ID: Bernard Aboba writes: >> If "rule on" only implies a way to stop completely bogus >> registrations, it sounds fine. > > The problem is defining what "completely bogus" means. Is it: > > a. A method that is non compliant with RFC 2284 in some respect > b. A method with a bad security flaw > c. A method that requires >N EAP type allocations? > d. A method that uses EAP for some inappropriate purpose? > > And of course, who makes the decision, and on what basis? I believe the process should be mechanistic, so the only reason to stop allocating new EAP method types would if the name space would be (nearly) exhausted. > Is a specification required for a "standard" allocation (37-254)? This might be a good solution too. > If so, who says if it is good enough? If it is put on the standards track? Having 37-254 for standard track types and 255+ for IANA FCFS allocation could fly. >> Yes. Unless there is a reason to do anything else, but I don't see >> one here. > > Are there limits to "first come, first served"? For example, can I request > allocation of Types 37-254? Or is it FCFS for 1 Type, but some other > policy for a block request? If so, how big is the block before the > alternate policy is triggered? And what is the alternate procedure? > > And of course, there is a possible difference between "What the WG wants" > and "What the IESG will accept". > > Welcome to the Wonderful World of IANA Allocation Policy :) Making the IANA recommended practice draft say "allocate whatever people want to allocate", does not raise these questions, I think. If the WG feels the name space is being exhausted too fast, it is possible to ask IANA to stop allocate new method types and come up with a technical solution (such as the 255 type) that allows IANA to continue allocate types. 255 should be reserved for this purpose now though. Just my $.2. If having a designated expert feels more comfortable to people I guess it would be fine too. From aboba@internaut.com Sun Oct 13 14:49:30 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 13 Oct 2002 06:49:30 -0700 (PDT) Subject: [eap] EAP IANA Considerations In-Reply-To: Message-ID: > I believe the process should be mechanistic, so the only reason to > stop allocating new EAP method types would if the name space would be > (nearly) exhausted. > > > Is a specification required for a "standard" allocation (37-254)? > > This might be a good solution too. > > > If so, who says if it is good enough? > > If it is put on the standards track? Having 37-254 for standard track > types and 255+ for IANA FCFS allocation could fly. The "standard" space (37-254) need not necessarily require Standards Action for allocation. For example, you could have IETF Consensus, or Designated Expert, or Expert Review. > Making the IANA recommended practice draft say "allocate whatever > people want to allocate", does not raise these questions, I think. If > the WG feels the name space is being exhausted too fast, it is > possible to ask IANA to stop allocate new method types and come up > with a technical solution (such as the 255 type) that allows IANA to > continue allocate types. 255 should be reserved for this purpose now > though. The question is what hurdles are put in place for each space. Today, most EAP Type allocations are made without a specification for uses which appear to be vendor-specific. So creating a vendor-specific space for "Private Use" should take much of the pressure of assignments from the "standard" EAP Type space. So the questions are: a. What do you need to do in order to get a vendor-specific allocation? Answer: get an SMI enterprise code, then allocate types yourself. b. What do you need to do in order to get an allocation from the "standard space" 37-254? 1. Is a specification required? 2. Does someone review the specification? 3. Need the specification be published as an RFC? On the standards track? 4. Does it make a difference if a block of Types is requested, instead of just a single Type? c. What do you need to do in order to get an allocation from the "expanded" space 256+? 1. Is this different from b? > If having a designated expert feels more comfortable to > people I guess it would be fine too. As you mentioned, there are implications from all of these choices. From pcalhoun@bstormnetworks.com Mon Oct 14 09:38:42 2002 From: pcalhoun@bstormnetworks.com (Pat Calhoun) Date: 14 Oct 2002 08:38:42 +0000 Subject: [eap] EAP IANA Considerations In-Reply-To: References: Message-ID: <1034584722.16034.10.camel@dhcp-229-243> > Making the IANA recommended practice draft say "allocate whatever > people want to allocate", does not raise these questions, I think. If > the WG feels the name space is being exhausted too fast, it is > possible to ask IANA to stop allocate new method types and come up > with a technical solution (such as the 255 type) that allows IANA to > continue allocate types. 255 should be reserved for this purpose now > though. I think there's also an implied desire to maintain interoperability among network elements. One can imagine that if we dish out identifiers in a pseudo-random fashion, there would be more methods out there than vendors would be willing to support. So who benefits? Certainly not the internet community. So I think in the interest of maintaining interoperability, we need to set limits on what is assigned by the IETF. On the other hand, if there does not exist a mechanism for vendors to create vendor specific methods, address abuse will occur and then no one benefits (remember RADIUS?). I am OK with this path, as long as these vendors promise not to attempt to shove these methods down our throat later on :) PatC From jas@extundo.com Tue Oct 15 01:23:29 2002 From: jas@extundo.com (Simon Josefsson) Date: Tue, 15 Oct 2002 02:23:29 +0200 Subject: [eap] EAP IANA Considerations In-Reply-To: <1034584722.16034.10.camel@dhcp-229-243> (Pat Calhoun's message of "14 Oct 2002 08:38:42 +0000") References: <1034584722.16034.10.camel@dhcp-229-243> Message-ID: Pat Calhoun writes: >> Making the IANA recommended practice draft say "allocate whatever >> people want to allocate", does not raise these questions, I think. If >> the WG feels the name space is being exhausted too fast, it is >> possible to ask IANA to stop allocate new method types and come up >> with a technical solution (such as the 255 type) that allows IANA to >> continue allocate types. 255 should be reserved for this purpose now >> though. > > I think there's also an implied desire to maintain interoperability > among network elements. One can imagine that if we dish out identifiers > in a pseudo-random fashion, there would be more methods out there than > vendors would be willing to support. So who benefits? Certainly not the > internet community. IETF standardizes the interoperable mechanisms. Just because someone has registered something with IANA doesn't mean everyone will have or want to support it. > So I think in the interest of maintaining interoperability, we need > to set limits on what is assigned by the IETF. Yes, I agree, and we have standards track review for that. I was talking about what is assigned by IANA. > On the other hand, if there does not exist a mechanism for vendors > to create vendor specific methods, address abuse will occur and then > no one benefits (remember RADIUS?). I am OK with this path, as long > as these vendors promise not to attempt to shove these methods down > our throat later on :) The abuse is the problem, yes. If IANA registrations are restricted, people will simply pick a number and use it, but if the IANA registry is open we at least prevent collisions and will have a contact address for each mechanism. The reverse problem is if vendors use an IANA allocation as an "IETF blessing" of the approach in advertisement, which is known to happen, but I think it is a lesser problem. From Internet-Drafts@ietf.org Tue Oct 15 12:30:32 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 15 Oct 2002 07:30:32 -0400 Subject: [eap] I-D ACTION:draft-ietf-eap-otp-00.txt Message-ID: <200210151130.HAA26432@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : The One Time Password (OTP) and Generic Token Card Authentication Protocols Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-eap-otp-00.txt Pages : 14 Date : 2002-10-14 EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods, both of which provide one-way authentication, but not key generation. As a result, the OTP and Generic Token Card methods, when used by themselves, are only appropriate for use on networks where physical security can be assumed. These methods SHOULD NOT be used on wireless networks, or over the Internet, unless the EAP conversation is protected. This can be accomplished using technologies such as IPsec or TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-otp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-otp-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-eap-otp-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: <2002-10-14142121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-otp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-otp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142121.I-D@ietf.org> --OtherAccess-- --NextPart-- From dpotter@cisco.com Tue Oct 15 17:03:47 2002 From: dpotter@cisco.com (Darran Potter) Date: Tue, 15 Oct 2002 17:03:47 +0100 Subject: [eap] I-D ACTION:draft-ietf-eap-otp-00.txt In-Reply-To: <200210151130.HAA26432@ietf.org> Message-ID: Bernard Whats the driving force for making an I-D of the token methods? The methods dont seem to have been changed any from the original EAP RFC. Darran -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of Internet-Drafts@ietf.org Sent: 15 October 2002 12:31 To: IETF-Announce: Cc: eap@frascone.com Subject: [eap] I-D ACTION:draft-ietf-eap-otp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : The One Time Password (OTP) and Generic Token Card Authentication Protocols Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-eap-otp-00.txt Pages : 14 Date : 2002-10-14 EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods, both of which provide one-way authentication, but not key generation. As a result, the OTP and Generic Token Card methods, when used by themselves, are only appropriate for use on networks where physical security can be assumed. These methods SHOULD NOT be used on wireless networks, or over the Internet, unless the EAP conversation is protected. This can be accomplished using technologies such as IPsec or TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-otp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-otp-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-eap-otp-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. From jrv@interlinknetworks.com Wed Oct 16 11:43:58 2002 From: jrv@interlinknetworks.com (John Vollbrecht) Date: Wed, 16 Oct 2002 06:43:58 -0400 Subject: [eap] EAP Design Team -- This week's position papers References: Message-ID: <3DAD42EE.9BAD1A05@interlinknetworks.com> I will try to be on the call today, but I may not make it due to a conflicting obligation. My comment on the state machine issues is that I think there is some confusion (at least for me) in what the model for the interactions is. The current state machine seems to tie together what has been called the "mux" or "EAP-switch" process and the EAP-Methods process. Clearly separating them seems to me to make the description simpler to understand and possibly to implement. Making this distinction means that at each end - Peer and Authenticator - there are two processes. The EAP-switch process and the EAP-Method. The EAP-switch processes at each end communicate to select a (sequence of) method(s) and to decide when the process is done. The EAP-switch sends Success and Failure messages. The EAP methods at each end communicate with each other. They also communicate with the EAP-switch at their end. The methods may have their own state machine independent of the EAP-switch, which also has a state machine. It seems to me to be mostly the EAP-switch state machine we are dealing with. I think the EAP-switch state machine should have events that are messages from the remote EAP-switch AND events that are signals from the local EAP methods. This probably means that a model of an EAP-switch / EAP-method interface needs to be proposed. A high level model. The interface should include signals and variable (such as identity) passing. If people think this would be helpful I can try to put together a straw man proposal for such an interface by next week. -- John From aboba@internaut.com Tue Oct 22 03:06:40 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 21 Oct 2002 19:06:40 -0700 (PDT) Subject: [eap] Issue 26: Unprotected Success and Failure Message-ID: Issue 26: Unprotected Success and Failure Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: May 3, 2002 Reference: Document: RFC2284bis-04 Comment type: T Priority: S Section: 4.2 Rationale/Explanation of issue: Section 4.2 page 12 begins: "The Success packet is sent by the Authenticator to the Peer to acknowledge successful completion of an authentication method. The Authenticator MUST transmit an EAP packet with the Code field set to 3 (Success)." We know from the 802.11 experience that the Success message as formulated today has no reliable meaning within that context. The solution de jour 802.11 has proposed is to use 802.11 link level protections for the Success message. This feels unsatisfactory, because it does not protect the Success message the entire length of the channel between the EAP Authenticator and the EAP Peer. It seems we will not arrive at a satisfactory solution until we find a way to protect the Success message end-to-end across this entire channel. If this observation is valid, it would imply we need a cryptographic key to protect the Success message, and the EAP architecture cannot be considered complete until it deals with this problem (or else make devices that can use EAP in environments like 802.11 non-conformant, which no one wants to do). To be useful, such a key can only come as a bi-product of the authentication, and it can be either a static key identified by the authentication or an ephemeral key constructed as a bi-product of the authentication protocol carried by EAP. I might be wrong, but I haven't convinced myself it is sufficient to simply "tunnel" the EAP Success message through TLS or IPsec or the like; it seems like it is necessary to insert data orgin authentication fields the Success packet itself to guarantee that some entity other than the Authenticator has not forged the Success message; this is an application layer function, and lower level security will not address the concern. It also feels like an abuse to protect the Success via an underlying tunneling protocol, because the EAP exchange exists to establish the trust that is assumed by any such protocol. This suggest either extending the format of the existing Success message, or introducing a new one that has all the necessary bells and whistles for environments like 802.11. An alternate approach might be to require use of a key distribution message in lieu of the Success in these environments. To prevent all kinds of forgeries, it is also necessary to deny replayed Success messages between the same two Peers. For this to work, it is necessary to tie the Success message to the packets conveyed by EAP during this particular authentication. A typical hueristic that accomplishes this is to use the key to hash all the information elements in all the packets we care about, as well as the important fields of the Success message itself, and the Success carries the hash to the Peer for verification; the Peer verification will fail if the messages it exchanged differ. This hueristic applies if the packets contain unguessable data; otherwise, some sort of nonces will have to be introduced into the Request/Reply exchange, or we would need to discover a new way to guarantee a live Success, or ban EAP methods that don't introduce any session-specific material. So the requirements for making the Success message generally meaningful is that there must be some way to authenticate it, that the authentication key used to do this has to stem from the authentication itself, that the Success must be tied to the messages exchanged in this particular authentication session, and that the authentication has to include information by which the Peer can determine liveness and authenticity of the Success. It appears to me today that the Success message itself should carry the protections, although I might have this wrong about this. I am not suggesting that 2284bis address this problem, since this kind of change is out of scope of the document intent. Rather the issue and the requirements for its solution should be noted somewhere, so that we have a starting point if we are ever chartered to extend EAP. Resolution: Discuss [BA] I agree that it is important for EAP to be extended to support acknowledged (and protected) success and failure indications, and that this is a requirement for secure operation on networks where physical security cannot be assumed. This has been added to the requirements in the security considerations section. We should discuss whether this should be handled in RFC 2284bis, possibly along with the cryptographic binding issue (#40), and acknowledged success/failure issue (#10). From aboba@internaut.com Tue Oct 22 03:08:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 21 Oct 2002 19:08:42 -0700 (PDT) Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels Message-ID: Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 21, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: S Section: 4.3 Rationale/Explanation of issue: When EAP methods are used as part of a sequence or within a tunnel, RFC 2284 does not provide a mechanism to cryptographically bind subsequent authentication methods together. The result of this is that neither side of the conversation has any assurance that they are talking to the same endpoint throughout the conversation, making EAP implementations vulnerable to a man-in-the-middle attack. A number of existing EAP methods are vulnerable to such an attack. The problem occurs on the peer, where a rogue NAS could fool a peer into authenticating to it, while acting as a man-in-the-middle, and tunneling the peer's authentication to another authenticator. The vulnerability also exists on the server, where a proxy can handle a portion of an authentication sequence while routing other portions to other servers. With EAP being increasingly adopted across multiple media, including cellular, IEEE 802, and PPP, the need for such a binding facility has become critical. Binding requires both sides to demonstrate that they acted as the endpoint for the sequence of authentication methods. On the peer, this implies that the same entity acted as the peer in each of the sequence of authentication mechanisms. Similarly, on the authenticator, binding implies that the same entity acted as the authenticator in each method within the sequence. There may be situations in which it may not be desirable for binding to be required. For example, the server may not wish to demonstrate binding, but may desire the client to do so. Alternatively, the client may demand that the server demonstrate binding. As a result, some flexibility is required within the binding facility. Note that there are a number of choices as to how binding might be demonstrated: a. Individual EAP methods may incorporate keys derived from previous methods in order to demonstrate not only possession of a shared secret, token or certificate, but possession of previously derived key(s) as well. However, this approach has the disadvantage of requiring that existing EAP methods be modified to accomodate the binding facility. In many cases this will not be possible since those methods are already developed and deployed. b. The binding facility can be provided within individual EAP methods. This has the advantage of not requiring EAP implementations to be upgraded, but has the disadvantage of requiring the same facility to be developed multiple times. This would result in overlapping effort as well as poor interoperability among implementations. c. The binding facility can be provided within EAP itself. This has the advantage of enabling widespread interoperability between implementations, and applicability to multiple EAP methods. However, it has the disadvantage of being harder to deploy. Suggested changes Add to section 7.2: "[7] Protection against man-in-the-middle attacks. Where EAP is tunneled within another protocol, or where a sequence of EAP method is used for authentication, it is necessary for each endpoint to demonstrate that it has participated in each method within the authentication sequence. If this cannot be demonstrated then, the authentication sequence or tunnel is vulnerable to a man-in-the-middle attack. " Add a binding facility to EAP itself, possibly in concert with acknowleged EAP Success/Failure. Resolution: Discuss From aboba@internaut.com Tue Oct 22 20:28:41 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 22 Oct 2002 12:28:41 -0700 (PDT) Subject: [eap] Strawman agenda for IETF 55 Message-ID: Here is a strawman agenda for the EAP WG meetings at IETF 55. Additions/deletions/comments welcome. Extensible Authentication Protocol WG (EAP) IETF 55, Atlanta, GA CHAIRS: Bernard Aboba Jari Arkko AGENDA Monday, November 18 1530 - 1730 Preliminaries (10 minutes) Bluesheets and Minutes Document Status Interoperability report RFC 2284bis Open issues, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt RFC 2869bis Open issues, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-03.txt IEEE 802.1aa reconciliation, Paul Congdon (20 minutes) http://www.ieee802.org/1/pages/802.1aa.html Userid: p8021 Password: go_wildcats EAP Design Team report, Jari Arkko (20 minutes) Draft TBD EAP state machine, Bryan Payne, Nick Petroni (20 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt Tuesday, November 19 0900-1130 EAP security EAP keying problem, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-02.txt EAP security issues, Bernard Aboba (15 minutes) Draft TBD EAP keying issues and the KDF project, John Kane (15 minutes) Draft TBD EAP key distribution, Jesse Walker (15 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-01.txt Methods EAP OTP, Bernard Aboba (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-otp-00.txt Roadmap discussion From aboba@internaut.com Tue Oct 22 22:03:20 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 22 Oct 2002 14:03:20 -0700 (PDT) Subject: [eap] EAP for smartcard (fwd) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --Boundary_(ID_bLbStQzN33JnITioLGsgaw) Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: ---------- Forwarded message ---------- Date: Fri, 18 Oct 2002 16:05:07 +0200 From: Pascal Urien To: bernarda@microsoft.com, aboba@internaut.com, Jari.Arkko@ericsson.com, waa@dsl.cis.upenn.edu Cc: bertrand du Castel Subject: EAP for smartcard Dear Sir, We have written an internet draft for EAP support in smartcards. This draft will be uploaded in a few days on the IETF server. We would like to present this document during the next IETF meeting in Atlanta. Is it possible to get a short time slot for that presentation ?. This draft is issued by the two major smartcard companies, Gemplus and Schlumberger. It is also considering as a reference document by the javacard forum http://www.javacardforum.org/ which comprises around twenty companies and that has recently launched a WiFi task force. Best Regards. Pascal Urien. Jacacard forum WiFi Task Force leader --Boundary_(ID_bLbStQzN33JnITioLGsgaw) Content-Type: APPLICATION/PDF; NAME="draft-urien-EAP-smartcard-01.53.PDF" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-urien-EAP-smartcard-01.53.PDF" JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFIN Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0KPj4NCnN0cmVhbQ0KSImVVsty4zYQ/AL9 w9Se1imTBviUfHMie+NU7ZYTK5WLLxAJSdglCS0Aruy/3wHAl2Q5TnywKUvo6enu Geg7zAgQyGgE2SIDxeEfaGD262qWkjBKIbK/YLV0nyKgtjC7uiOAH4fVZhaQkOT2 /QLfg9UBPv7ORHMBq6+z29XsT5h9fxOeJvk74IhNEg/u6ixSX+K+2UhVMyNkwyoI 4PZ5LxTXsOQFr9dcQUQI+U8c0ncbJGE87Y5OYMfPp1FuQbI8AhKiHJTal1hnM+qY ZUOhE/2SLPIlwtg/uhYNVw03sFRsY/qi2Ei8iDwaQqR5mFqgSUPJIjkpZitENJk2 8RD+rQSfujSy9H/6g5T2zNwTnl3Koq15Y66htMyC1iIFtzcPga6ZMgVTZUBoaJ7P kU7m50mnTrVJbSzdhcr/BwvfhH+EcMeUareCHZvbw8fZv2oSz0f4I1M/w//CS8ni BA+lokdD8ElJac6DRsl5knMMaJRNxY/jI5afwof2q6wqfuIbxWAnY2eURkdUuuG4 PmMHMjhLJUuPIYcJD6PBjXbbamMHLTqmQxcxAqb5VBuSkMWQcPdoed08gG73e6kM iAaG9GiHF9AktghBZJO7BCtHB0G6EXGTAT+40rgH4OmjcCPDqqcL/FDqUSJqgxWg kR0Ined9K3Mae6BHw0yrQW7A7ISGz7yW7nR3uGPgxiHvSURx4g+v7JGyGwrAZ9ZA P7yBp8ia0r6BTW7aqoJC+vXVFN5JAoFbBo5fFOfDviNJJ9VBmB0wPLpX8oew7Tq2 j7ywKxAosa/+uvsN7cAE9aBd0w4p7jcMSeOTDeNJIm9MwEGqb6LZDv10ovCho9eE yaKHpiTuBL1ttqLhXFmoFdPf4E6qgqNF97eru6eLSxC+HtOXXhx82ZV2BVa/WORx 89OM5h55q2S71yHAF2k4MmMGJPJT4N+Amr2gUFpCKbRRYt0afgZ5BO7jPDbM9Il9 ehB0jGKSxhNui7cFdTtyIucPVokS0H5gyPVZ1G1tJdbi+bWyY1RJTDvTatmYnXai 2VbXHNp9yQwvL3GA9xUr7BOiy7WWFcfm1y9eoL57l+J+mvtRnHRv0/oCRtQcRb43 Prdsj8HbK8Gs5hJaPQYiOAKm/XjQPJ0MqVNV8Q1XHEOPzPGswJsbiSJcIZyVvO6s RFcbe+CDNW50bdhrWCnNeuNwqJDbFhecDj+8Nopk6ZDOrB9YDhWmw+petErZsT21 rkAGqC0rCsTlJcpyYs/RpYrd0m4bgP3ZGbO/vro6HA6h4GYTSrW9sg9XVJQBW2Mw WYGx6q9In0nqxtW7nSWvqZ7slMcdK+UBlrjaCyPxDn6TdOcNrruB7Zy+w1Y79HBn 6io8v0hPb5mbrq0zi9PaMB+Wd5bl5xbnQeB6K7kucGhdGsCt8w0m2mbE/sNeGOi1 kYWsoPuOeewImQ/Bjue+ynitXMJhJ4odrt+2KkGjaJjEtjJiX2GxEkkIY2VkWsvC Rr3EwqOC47fQLnlfuLEBhRunN9w7hI3A6yjsb8Sfrv4EAA0KZW5kc3RyZWFtDQpl bmRvYmoNCjkgMCBvYmoNCjExNTANCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBl IC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0K L0YwIDYgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDgg MCBSDQo+Pg0KZW5kb2JqDQoxMSAwIG9iag0KPDwNCi9MZW5ndGggMTIgMCBSDQov RmlsdGVyIC9GbGF0ZURlY29kZSANCj4+DQpzdHJlYW0NCkiJvZfNcpswEICfgHfY U4ccIJIAAUe3Tjtuxq1bO9NLLgTLLq2NEyHHydtXSAL/QWwnTnNSxK720/5o1w9g IUBAMQEaU+AMfkEO1seRhcPADYBG1CUBwKir5BDwKViXnxFIBRhNLOQiGpfLFBzk Er1egd3LBZvyRGT5FK46A8hyKOYJF2nCx8UFjP5YVyPrB1gPrfb9gJSWjwAIA2Vf mleC0npnOV0WAghC5ChbASptkAOGCKZhdVNK1VrauuEZy+EDdGazo2zhAB20hHxS +xTjsPbpZMHn0qeLPJmBA1dP9xlnBXxN8mXCn0+47hGX9bRPteXNY6U+icrM0E5r PcJB1Q10gOQxo+RuxmAxgU8LmR650IlAsCsFHOK7Sq4rA4lwFFYxjbCntYciEcui VBe/swL6bL5Q+thXmsjoboG7B/40gI+Mtr3zpT7Wxup/xw9iBYs9t2LFmOj8szt3 heBJKpQoVQ7ehnoDzq4QDkL3JLjvj4w/Zmz13+G8HTjfZE1JZ9hGjM91LnjxfijP A1azRaiNbO025K3fFFo9Kr2xTNlskqWqAmGW3LFZdd8Gf741A3WgXnDkBq7x4xcm nG/sSTgaVTwbPC88b7jVp4is0fx2tKo72EO2yxW/R7D1jQk6hFa+S3VxyA7lDJL0 LxOFQXuXAjFsGzENXqILTSK5nl6udIQHScZXWcH6SSEYv2bPcGsP+te3F/r4uCHY r89FvUUOE0vgKKjbI6bItMfe8DuEEaaOD51B96YwPniHgqk/xg0O9iLJiqunp2xT sW43Za/DbfWjkKsiig69L9thlnnfKq8lUNzAWe5tkDaUTXhGkF1Z2o5E9O5eqYRH HX8qjhFWM6gRp20uaiwKk2f0nHDmTLzPRBXNuhq2pzlSVzIJiamLIUuXvEwxOQsV 2Zhx1VVMedCz1nC9HZB98qYn2/eqOvYIjcxInefsCXA5zF8Oe30YM5FkMzaG4p6l dVc05qOT+U24NwDDVwESBdjvBmcGNHFZj1z1zEW2I7/+PWL/ZBPGWZ4yHdXwzF14 i8xbk3nVsP4PsY32Yg0KZW5kc3RyZWFtDQplbmRvYmoNCjEyIDAgb2JqDQo3OTUN CmVuZG9iag0KMTAgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAg Ug0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJv Y1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAxMSAwIFINCj4+DQplbmRvYmoNCjE0 IDAgb2JqDQo8PA0KL0xlbmd0aCAxNSAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IA0KPj4NCnN0cmVhbQ0KSImVVl1z2jgU/QX8hzt52Gl3AivJ2CaPbkO3bENIA5nd naYPxiigjbGJJJPw73tlWcYE52NnMoMyts6595yrIz9AhwCBgDIIzgKQHP6GDDqf Zh0a+j0fgkHQYz7A7Lx8j4BcQuePLwRwA8zuOqRHgjOzTKBLesyuH+HDKNN8KWMt siUMoysQGah1LHUSy4X6CLP/OsNZ5zt0Hl7k7/vMML+jgNAv+ZG+fBHZo2JZKA2M EPYuLp8YDvYGEaNB6DoNgnKNXDdS8Ax+gyhN38VFffImE+mzWlNKw1rTu1yuUdM8 i1PowvBpIyRX8FecFbHc/Y9239GsZzW1zF4DFvezgZkML+iFr0JQyvwmymTL5Vbw xxKMUbO7y/oGAb0jlLDKRlx5dseAMESJT8Eu5m6xBMWTQgq9w7YeClRhzTOteiUy aaIyL3TDEQYV6jVPSxHhUeiVRXyyW2e/mz1976weaLvGTcMnzTMl5imHqNArpBOJ RbmSuc6TPIU5z/idcGV0qw69oKqFHogx43KtXlDClUwIHVRvrzjc8x085nh84GR8 M52dnNpfuJyU6+vh95vR9fDcrKdfo4uLeuFUKY2xqvT9ukO7Ro4KZ/p1cnNxvl/t 8T9PxuPh5bmlGEf/4k+cLRrCETZwFnqkQj2ZXM1Gk8vo4sRkgF4JBYs8KYxfEONM 6hx1w0eay43kmi8gxje4SqSY8yY4Cz1Xcz8MKysR8vrLZ5Sanh2bfzDC0fRYBm+f HME+Og7MneLIcvk6NOZbi8Rt5b49RG908ed0/Iyqa/rwqpd6nl2aN9N8jikx3SnN 14DBAeN8LpA4ydfrIqt4j45Mt5GnVeqMp6OW9khQB1S/GfoycwFV8U2LuTVTwmhh Or4TXJ5CodBqtA87whlo+NxmirAbd6BqsJbDfqDUZdRSNQnquScD6uaeazxW9xAl CVeqUeTrBFfjby0TxWhdfFglx1Us5KNQHMYxeiGh3EWpuV1JG/C34c4GiH3H0X+Y jp57j4R1P9RpdaQ3hqS14iCW9nHTJrgToZrONJ7zajSr7Q1N/X6tKQsGjeD+B9SG J3uUH/5PF9cKkwPiwyMwRx84NxnBW5zz6J6lH1iWBgDON/7hv89RVXmA4RYD4Paj yasa344bDfdz7Fe4qthsUgTIdA9mx5AYYXyN4bSwE2xI9wfbQXdLaQKX5L7Dfuny uDUxghVinDE26MMP+vNQvrKUlrC1inhHihj0BE+4UFpBfgcxJKs4TXm25OiC2uAj Xms+z/WqeQZprTYlAbXYG/x8E+icuTXzQlvwBZeWChmMECLb5ukWhUnkbqPzriqE 5r0DUQbukmDUr6A/cQwoDkobCvxiNEjrQheYIocdnZaPoilknONF2LCyS+qrx0Xg 3kYQ7iTgdcORZp4KtSqxFJ55p64BtlPULJhSry44bJ08xbNFOdHmS/caJxwp9ocP KUuiuprW6SMuRPUq1miQLmSmAL8mQNkIdy30IDLhKWEd72AVb00LOOEold5tuGq6 WGP7tG/B0aUKxziZinue7vDCVXkiYnP3VrVmVSTmG2Nv7sIWPwB/ASMaR1cNCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxNSAwIG9iag0KMTE4MQ0KZW5kb2JqDQoxMyAwIG9i ag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8 DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0K L0NvbnRlbnRzIDE0IDAgUg0KPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8DQovTGVu Z3RoIDIwIDAgUg0KL0ZpbHRlciAvRmxhdGVEZWNvZGUgDQo+Pg0Kc3RyZWFtDQpI ib1X23LbNhD9Av3DPnWSTqQAvIlqX+rWTkeZSZqOlWln4jxAJCQz4S0AaVt/3wVI gBBJJ+400xeHsak9Z3fPnl19gQUBAhH1INpEIDj8BSUsft0t6DpchRDF0coLAXaX +j0C4giLl68I4Adgd1iQFYk26jGBJVl53fM9PNuWDT8K1mTlEa4u3kFWgiyYaBIm Uvkcdp8WV7vFn7D48ih+EHoK+QkE1qHGR3j9IqJftMdWNuAR4j0JKyQKw/sGkEej tck0ivQzYr0XGS/hB7jI8ydh0ZB8E4kEnq0ppWtb00MlCqxpVbIclnD1UGeCS3jN ypaJ079I9wnJ+l1NO+TACWvLFXX/fC0NjwZ9a4gXR12s3S2HLOVlkx2yRCcDOdvz HAp2gj2H6gDNqebyJ41JYOmpGJcwokRvnusXaKh/cwkvX1GLbGrn+z0o6Hej1Xp4 2/LE9wj1Bg0ZCSuiJW/uK/EZrq+3l8AkpFwmItvzVAm6wRdi4mGHQDasTFHa8CH4 uNJYS48qtKUGmbD3vht7RZ54pspREA/k315s4UP08YUmajIRnOWFBKQLDCQXd1xA yQr+AlBcpuSWNPEGIZLA7yXPH1hR5xzaMvvScrhjOf6k2zfX2190eBUKrrdvYM8k loq1SAD73XVbY+x+1BG9mPbM/e4Rg3/I0DoE0oVUsEPz8ecnlNP/rmIgvq2nRze9 o0CLxbrBcsixem+evd9e3jwHvjqusK5wcf3bdouKEOh9j1Q1Dq2ReN2zU1UGB2Up aX7SjTmXkx0G4kVDY9ZBzzJJKpEqz20q3fWOanPCTuc80XTVr2Vb1znyLxuQ1aG5 Z4JPSWJ3LEL3jAgl56lU0SU2SIVidS2qWmSscdCUulBYWCO0p+zQYSr7N83XFrdx LK4vs1oPkKE891gIRCkyIVBLGmhQUSVWE3MgXhBaut2zskwHG0zwsmosAJJPuJRj BKPTs4IEoW+7tiZ+hyB4jqmnk4KrUFgHVflGb0GDhAQE/4TNwA/tT+40GAvye/Iq 3oFleYvWnVQpn0ma+pGRqh8Fw+jLdi85zqZqcNd3CcfsjmuOnYnVWg1VV6CCN7cV NhZFnn49cdqj7E/KPwYdqZHvU1TZ4hxoa/x7VFVEwD87MqDUOm8cO4kPLZtJ24+o JdQ9K/GXJX+AquSKxx02AmWEpT5wwcsEO6OGq0AmHQ8zbYo3U2Y1TXttBRWaw2LO 0P4Pfm8uw//Ib2ogoeugv/Nm+ZY/NMttL+DuU2PXJUFgnYtG1HcUN4yYWuRJhYng jlTpYgZFhRoeO2iD7jBjO7FvJL02vsbGvjaEMntNKd6oWq5gd+Zyjt48Mvgmob2r GRMEeVu1eaoaVNTNCOnM3ZgzYk5045lYHZ/0PRmsl+V5dS/HjjR2IcdQ8XJ2DYKE dtrDsF9mo/FSp1OXfTfSMGmsw8IlHppLjZJ1L9iZLaHI4opPVRBgd2hO2kjnOqtZ uINu/Q2F6z2iOsNaSSjT5+5j+wruMe35W4KuzS2hWM5xg1uGXrjnaNEqm5kJDgeV m0N/ukt6kas5riVv06o8FUi9ZEc9yFoopsznhkqG3Rdtep0MIXBF3DzDHPGoGGqs sKf1ErxpRTnuJh1KTXr2rqws0gr6pGbpd6vSCetv4oF2HAwqqQRusxfj8jjcoOb4 zaVUUQ11J+5QbONjk4GvBb/LqlaadfbIkW2/jPa2ds2/6WhkY6+9ddTD/6EMWcFu p/cTVqUfV5vyuc8MndayDEMryzAc2c3kmnKqh7OPhyAegNre3IIMqjfEaRw7m1NT xTUwta7OGdyiKGSpHBq/SDaILV1PiCx1Es1t5hFHDIDiKlhym5Xd4jq0Aj8h3Jix PSXwsd8fzt2gzwNdCoy9fMeSz4pf5wrjMbX5U993N9GMWeD/bI3PSVvA6ZT6w9lD qbn3nCk9ONPZfx10rpbpaGXyzMwj61eb/vrVh+nZwM/lgm0dzZQOe7Vb/AOduQ4r DQplbmRzdHJlYW0NCmVuZG9iag0KMjAgMCBvYmoNCjE0ODkNCmVuZG9iag0KMTYg MCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291cmNl cyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSAxNyAwIFIgDQo+Pg0KL1By b2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTkgMCBSDQo+Pg0KZW5kb2JqDQoy NCAwIG9iag0KPDwNCi9MZW5ndGggMjUgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29k ZSANCj4+DQpzdHJlYW0NCkiJxVdtU9tGEP4F/g/7qUOa2DnJejGTTy6BjkugbnAm H5J8OOQzXJEl5U4C3OHHd/deJBmbhE47jWcQwqz2dp999tnVVxgwYJAEISSHCSgB H6GAwS+LQZDGoxiSSTIKY4DFW2PHQF3B4PUJA3wAFqsBG7HkkG4zGLJRaO/v4GBW 1OJK8VoWV3A8nYMsQK+5qjOulvoFLP4cHC8Gf8Dg65PnR3FIJz8jgDQ25+PxxhBP nzZXja4hZCx81lkxozPC7xwUBknqM00Sc49nfVBSFPATTPP8WWcFMfvuSSwKW0yD IG0xXZVqjZiWBc9hCMf3lVRCw2+8aLja/IN0n5Hs2GJqT457blu4EvvrW2mMfRIs GY+tK7kURS3rDdQlaFFDfS0MQVaKr8VdqW6AZ1mplkQcNKF/V0rcyrKxtGEwNP7f AkETxv0wtcgInJExHIbBCJnhrSkIb36ABw7nPLsRtbbG27ZoGkeTltTM3KP/hYu1 UmUmtAapYSl0puSlWBLDKdj3J0cQhpMIdCUyuZKZqRd8Cr48Cn/IHGtZMHH+eUFu bsv8Fquqxa1QWGc6UImvjdC1BrLAkldlodGksikAt9AsfjZZpq4JtkL7FH6xmQaT NoLXJ6GvFaWZ9qH8HCapsU/MN2QctIX1yIzHibUG6zpsbfskQCxbGkxYZJ/oZfXa JwQzx403toD/c6jD1riFcG+UukYd+1EhIpxR6okTR+k34syueZ6L4kq8Idr8SEit mrg4dZOZ5ikVrLjMGyVcv6K7frOG41bWo0ncNaAZI0BzBFPOhKRe2Wo8oyR6BLMa DWpUZ2exIx8sblu8a8EKm7tSkte21XmDTyIpXRvXm0r4TjfnmI70zrEBqZ3b+mxr 3koKNYJHKay5LGr80a0QIr3w7DXPrmUh2spZ10nUDqAwclMBc2xUQdJgHj+fnjpd ALkyTq1DTfQoMkGidanKG1GMYFps+sIReMDZ4Q6t6DEtkU51vgF5VZSKdKV/gI/4 jmsoyrqLekelqX/Eclulw6gtvBvnB7+KemjF+ZDmDGsNIhOfoVXkQ51zqe6kFmdc 10Kdig18PpifnX5+YU9JR1vqHsXtZAqSwLmY2mEksKDlCrgn6qrJd1hASTdVleMX RQ2FEMvd4cTYpBt/UeA6FUdaUy0JL3LSZ1umNhXNxEbiH4028++aYKWEsHxa49E9 LoTp2PdHGjrvN2JjGdZidzgmeD12291ImIlt0DyZ3OTtkrQwWm99IDtCIpDOry5X 9R1XNkUMibzJQtaS5/IvBFji9woWp7P5K/j4HjmGUnB0dDbfGZDUQVt7CKJVl1mZ 7+UOjZe4Fw5zoMwufod0EiTDCKbztx/0/oG/lxKLa6K93SqIFJTQssyaNZKBtoBb 7GzTeXJd5YK+5T3TXUoERjLdKJwkPim73rhdoiIPGnDVI8cu+JSiz8p1hf4v876C jHqU6DJwaoYSqK/LJl/CpaCmFKRVvAYcDHDL84aCV0bQrsU9Fh9D0T6JJyDeRzti 27m4r4d+gBugn9isorgnu9G4BzTmt7YLTqtoXjld4+X8UuSG4O0amZW0Ku6BOpx4 NUtCL5VN7jJGLBDuFepVu7g9VeaNqPsYh1EbPm42DoCTRhlO48am9/m4kwi4Pw// g9PZxDLycffkjzmOOMq/HLrPy8fXx5ddDDr9CXxvPhw5kB+Ocq71A8zOL+AB5gFd QrzYoo0no77ipm3OgX/Fepeh8TsBD44n5ol+6/5XefTWMpY4Xj+A+zzAlNEVggSv jLJgzF/u7110br7964i6LuiQjYOo202wfXDhsDwikJFTjSKWKpFz6r6tFndE3K1b T8bCieeY601PV8+txxQyxfaDPBj7zekE5YTG+cXsbN80s1UPx23V+9tRW/NGCyWX r2gXoIdmZxczv/9ghjxfOy4YP7180qDLJ/WTcCkqHLUax6GLoazwfacu1VPinhyG /fJdiE5vnpAaNg48EOywV6ZOaLRwL1XdfNJ7dhoU4z3dlQQtQvhpJxQtDX56E+T+ RdPo1koqXKZw3FbAVzTY677yya0XOS+0Qft6CFsbmZdAu+7hwktby1KuVkIRUcyb qtsEt/x2+xO+2rrSGmr5qd+tp/XjhZuUubdqboW7Pav9e4itzfFi8DfAG+ErDQpl bmRzdHJlYW0NCmVuZG9iag0KMjUgMCBvYmoNCjE2MTMNCmVuZG9iag0KMjEgMCBv YmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8 PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSAxNyAwIFIgDQovRjIgMjIgMCBS IA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDI0IDAgUg0KPj4N CmVuZG9iag0KMjcgMCBvYmoNCjw8DQovTGVuZ3RoIDI4IDAgUg0KL0ZpbHRlciAv RmxhdGVEZWNvZGUgDQo+Pg0Kc3RyZWFtDQpIie1X23LbNhD9Av3DPnWcpmRBUqSo p47qOBk3ceuO1Eln4jzAFCTBoQgaACVrRh/fxYWk5Evjdpy3aMYQRJN7OXvOLngL AwIEsiiGbJyBZPARKhj8OhtEozRMIcuzME4BZm/sfQTkEgY/vyWAD8BsMSAhycZm W0BAwtjtt3ByXmm2lFTzaglnk0vgFag1lbqgcq5ewexmcDYb/AmD2yf9D9PYeH5G AKPU+kf39kb0PmmWjdIQExI/y1dKjI/4K47iKBu1mWaZ3aOvvyRnFfwAk7J8lq8o JV/1RIZxh2kUjTpMF0KuEVNR0RICOLuruWQKfqNVQ+XuP6T7jGQTh6nznB2Y7eDK 3NeTNjB2QpLs0M7rwH9e31/vL9YhgcDaeoO1JUkLCImixJnbn4r1mlZz2J+WVKk9 nP8+hT1cRmaJcbFW4iRHIhNrJ+jpYqBt+fKhwJs/MNjbBwL3ROv7JfMISJcFyXKf BfjPHibErBBluOYEF2KWuzu/s8ZmP75AREEchYhDEA+7FB0YBZygXINLWnxhWoUO QHdvX4qYZF0abo8RzFYMCl8PrkDjT1GVO2CVRm7WglcaxMJeNw2BNrirNC8snx+W e0SGXVcZp0PnA43TJZvD9c7aUZpqBmtarHjFQpjdv6RgRTcMtIBr1mJnQh72DBhG XlwopJoVGo2bBKx106/ANCzY8rKEDZN8sesSUOy2YVXBwjb2Ayy/0/5/0D63Kzmm vVm+Ke09LCfvmA4cbmPT1UiHf+oqcHJJudxyxS6o0ky+ZztncRQeS+NAGV4YfyBJ HtIVqamwJxeMb9i8I9W0KQqmFNRWf+byAyQxJD+GUBmjoafv9PwCainsw6g+el1a 3ivmyeyiBgwbGtUrKCdxGP19CHCcR9544rZo3CiDL7xUAYeQfbaQu1qLQDVcPy6C PPeWSJrnfZOweWK4xx0A5pIutBGZMr9S+BR/Bu+YqUeQMCePpJ+SSe6ROMgU21Hd mCPId42+kEYn2bFG7WLG1TfTqKHkKOn4HvtT15QVjeR6B6eiUnzOpCWRemRe2bK0 ESGumSf1BFWCAlwwabo48HVdsjXy0bHRELyWbMNFo1BFhb2IAtugryfY2NeuOxvO maa8VE/PPRSjOSGbf76bXhhZmDHG1cG0ijq7ZOzl6MPxVueiaEzgsOLLVYl/2k3f im1x7GrjDI+LkqsvR2aTvlPluW9VPkFpI6Z1XbZhrukOFhRhwr4hWeCinrO6FDts JhXTWyF7870SLOQjT2XTOARGJqFuZC0UUyG8lWJ9nMVVHCcFrWAnGihKgZ2SWmzs OD6c4v0R2e/RhZ3WV6YbXr36BS0N4dPoM0auEYFFSbfoBsvH7ji+HWyxDu6AUK92 CjMtgdru2zuJWg9e1dhRj08G4VHKcf8i0r4HmYZXUd3g6duXy7wZSUSsRc2FVAnA XJeIjcRzBR7rDzIled9ghpGn1pJp+3J1L3Z4GCJ8xLcG9RPMpLhBXFdCIvJHLT9N +1L5WmGpNlziqFBgirEW7hyl3SHPdVWoS6rNK4myZ6aaSfejVUcLy3jYmk9j31hu xDUW/1ybWYXKE1JTLL0hyL9pUrQKPORx1AZPktwHb6KUrGQbYxS/WGnAx2e1V047 woxEDmiu4LrRR50sa0dY0vXESmgTSSGZmeaOz4Za/rCML0n/AKFl8bANCmVuZHN0 cmVhbQ0KZW5kb2JqDQoyOCAwIG9iag0KMTI2Mw0KZW5kb2JqDQoyNiAwIG9iag0K PDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQov Rm9udCA8PA0KL0YwIDYgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0Nv bnRlbnRzIDI3IDAgUg0KPj4NCmVuZG9iag0KMzEgMCBvYmoNCjw8DQovTGVuZ3Ro IDMyIDAgUg0KL0ZpbHRlciAvRmxhdGVEZWNvZGUgDQo+Pg0Kc3RyZWFtDQpIie1X 227bRhD9Av3DPBVtA9G7y6seFV8AFU7ixgr6YPiBJlcyW4lLL5e2BejjO3shRcqy 4yBuEaClgMWSIs/czgwP72BEgEBEGUSTCCSHP6CE0fv5iMahF0KURB4LAeYn5j4C cgmjozMC+ADMFyPikWiitxmMicfs/gF+npWKL2WqinIJp9MLKEqo16lUWSrz+heY /zk6nY9+h9Hds/aDkGnLr3AgDo19NG9uROvTZtnUChgh7FW2QqJtsK8YYjSK20ij yOzR1hdZ8BJ+gulq9SpbNCRftUQC1uWU0rjL6ULINeZUlOkKxnD6WBWS1/BbWjap 3HxDuK8I1rc5tZbjHiw+zxLNDJu0F5kR+G0UPosSV5uy5I9ANSuOLmcfIOcqLVY8 h7riWbEoMhOgZywy6mFxxyzQZjQMIRF1xSah2SLiR6E4VFIokYkVFOtqxde8VAan hhQDF40CsQB1y6HORMXtSWGJSGBsXD7RoIQlDp+SiatwLrJGA8INwqSIiLlccMnL jO9ZM6BQ88ycLIt7bk3Mf9XYExY5QBNyDU2t20N7pROByC4FmIybDVz51x58wn/l LrgsLeGG9zANpMkwadE7lzQMevxwi/y0pmaXnyBOaDQOYHpx8mXork1Qi22SHcRt su22nwwTnU3pBsN/hLTMIRM52vHavPYLxyZtYkOzRaw5PrwoJHaqHhFVmv3FFRQW VF/5zO8ajv/OcjRYqI0Hc+1wURaqSFdPi8d2XeP2aMTB2tZBBzE7BTr+UKhbY+jz 2TEwlgQanNshBXpKYZFVI8t+AUkUduRwycZ6aE+xDSskG/LBuQpplgmZm/oKY2f2 4XIGK14u1a03SLIf9Vvt3dgd7/bX/aXnWNdmhFLf4myPxXqtS7I9XqV1vYXZx0vY wgXVC8PFNpivW5l0VXKjVI+ddpaeZ3jzOYeteWBsn2iT/v0BkB5WFwVph8UW3LGF KdFrYlZCuiXEhSbOuzdJ6ZC3NPbbmrOJ8+rE9G87UfQgc0w9eqH8p/MzzbWnrE3C tssYDVz1NCHhil73o+pec2SSuGYk8PSgB66xA9f8ZzqdBkELTvFBHwLAYQ8xJDCB b7jWoydN4mE9vu/XQw5I0JHG7jvStMND88VNEJys0p7vjnPTkf+8s8MKJlE4IDhp qzbkcZK86MoeXQ1bu4FNXyCrHVb/s/VfZms3XEnEwiFX3evjx+DqwFU/eI6q+zXC KLi85/mP10yDgNqb99H3otHv693zAzm8PRDhWyafJO07h3SfGUbkqluUMEa03XNZ 70TbUDtDLlDglEJB3VSVkKqv63RFnYY2HxfUieiq5k0uys0aUDWkSyMgtSTNeZ3J 4obrL7hWl2m1Om3wDHlqTR4qjMW9YteH5CANuur1xCBKUYGSRdu4eKIGpRvo2nqt tExLDwh4Pwp7wblaS16hQrOS2MVhJlwu04WCTtI+4+tbCZz/tFCjZnn/lkINv0f/ BmSm5d4NCmVuZHN0cmVhbQ0KZW5kb2JqDQozMiAwIG9iag0KMTExMw0KZW5kb2Jq DQoyOSAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMwIDAgUg0KL1Jl c291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJvY1NldCAy IDAgUg0KPj4NCi9Db250ZW50cyAzMSAwIFINCj4+DQplbmRvYmoNCjM0IDAgb2Jq DQo8PA0KL0xlbmd0aCAzNSAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0KPj4N CnN0cmVhbQ0KSIntV9tu2zgQ/QL/wzwturu1QlJXP+yD2ziAFxu3TVUUi0URMBLt aCGTDkWlNZCP71A3S45zaxdtF6gCJJRAzTlzZoZHuYIRAQIBZRBMAtAC3oOE0Yt4 REPf8SGIAof5APFxtY+AXsHo6IQAvgDxckQcEkzsMoExcVi9/gjP5tKIleYmkyuY TV9DJqFYc20SrtPiV4j/Hc3i0RsYXd2J7/nMIj+CQOhX+AhfbUT0abkqCwOMEPYo LJ9YDPYAEKNB2GYaBNUasd7pTEj4BaZ5/igs6pMHkYjHOk0pDTtNl0qvUVMleQ5j mH3aZFoU8CeXJdfbJ6T7iGTdWtMaOeqF7eQK6j/3pcF2aRDPbQQ7FoZnOaglmEth m+PoTFyVojBHb+enR28NdgnwJFE6tc1jFPzDPmD/JGqN9xURAuMK4xhrTiI/bMtP PbeGwECQcsPb3cxrd9Mo7Cd2UmokoTF8Jy0kXMKFQL0MVvZapLDUal1xnc/iE0g1 X5o9GlV+AWt4uPUSw6cqKddCGpvCB+c2G9d3u9Gp1/jSQhnhQHyZFXAtdGEpNVoV G5FkyyypeaYKay+VgaLcbBSKhltuy8PCDoJiF1QIm0KUqZLbNay55CtRUeQFpKJI dHaBKeO4NsUBq+W0xDtpGuQKJP7NRveo1yVQr23WViGbss1CwDQ+fz07O50uZov4 fH6Mv+fx3+dnszfAZVrBTIfP2/hj0ghKXbfRhmMXXyhzCUWWI6F8C9lKKm2LpDTG ekCz/RKM+6cHmURNhyLurYseeMYOPHMPtAbx2hYl1PNaDIrvu+ABThKEEMEEnvCs V4O9lv59/HU//eoSbze+pCF+Y7NsJtYu8X6e2uZYZjhI1f3u+kvIlbn8FmRp1+XY lD2mQKOWTMuMkuF9nVAhNA77N9HV71QN/Kjh2kyJ4zjVaNw00sEfded9N66uO+nY dgfITTWxLVf4Edj2h7o9NiZscrflFBslC3Gf56jSrNRtzxkcGm7oDy3nwCn/03O+ xHP4XZ7jst2sR4w+zXOe3284WKydHTSWU5tUprE6VgyTXQvAsy5PC7B2ZNXAupVa Yg4X2yq+5b8VxumxZlH37Uh8woatcK/mH7M8t98/eZmKyuJ6UbvZ9JvTuS/uXj// NL8nHXz9b1ccmoH51WfH/8D8du73A5qfH/TMb/Fq8XJ2fhrD0E7878m1PsWe3Rxk z8JooPTBq81qP2ZDtYs8wGjz+W8ywf/aPgN037o2DQplbmRzdHJlYW0NCmVuZG9i ag0KMzUgMCBvYmoNCjkzMw0KZW5kb2JqDQozMyAwIG9iag0KPDwNCi9UeXBlIC9Q YWdlDQovUGFyZW50IDMwIDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9G MCA2IDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAzNCAw IFINCj4+DQplbmRvYmoNCjM3IDAgb2JqDQo8PA0KL0xlbmd0aCAzOCAwIFINCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlIA0KPj4NCnN0cmVhbQ0KSInNV9tu4zYQ/QL/wzwV 6S7skNTNfuiDN04AF9kgzXrbh6JYKBLtqJVFh6KSBvDHdyheLF82cdDstgzAUIw0 l3PODJl76BEgEFMG8SgGyeE3qKD3YdajSTSIIB7GAxYBzCbtewTkAnqnFwTwA5jN e2RA4pFeZtAnA2bWj3AyrRRfyFQV1QLOx9dQVFAvU6myVOb1jzD7s3c+6/0Cvfuv +g8jpj0fEUAStf7Rffsieh83i6ZWwAhhR/mKiPbBXnDEaJy4TOO4XaOvz7LgFfwA 47I8yheNyIueSMg8ppQmHtO5kEvEVFRpCX04/3tVSF7Dz2nVpPLpFekekWxgMDWe Rx2zHq7Y/HouDcaGLg27RmOzOw7qrpB5K4zrNPuLKyhq3OPtjuT3DUf2Pk0/wtld Wpa8WnBIjWoI9FvzE6SbBHG0QYla7iVfISgc9Zdr1Wmr0/PZBeQynSvIRdYs8Y/w O/tj4CyysLWoo0Sb3cTf9+14vzvvTgei86lTGhhz6zOxXKZVDuuzMq3rNUyvPsEa rqmeGE6tFRYMsfKIjynZZOkEfpnhy5cc1u0HffOF8/2WefSJz4LElsA12LGGMdHz sJ0JcVOkJ/rBRjd79zYRdViiruIDx/qEq7QoQcydjE5vjIxOUUanHRllmZC57kpK aA3s00YjDzcZEWu+qDKx1F9pUeapSgegZTy+nnyGTLT2DHXYtBLHnTYWdlQQBp48 lPtKipWoUaSPhbqDAG7GVxPLpjGyiYka3j12VbO85bLe1a/2MTQd6uSikQiExArw PQOytIJbjvWlsGU9oOe5FMudAtmjH3tRzBzaZokRdMtor4609iOfNzNr/OhKKK5x w+QfMHwdkuWrXvGsmBeZiTMX2NQqoaBuVishlX5lnyeWeBd0FBsPq5o3uaieloBV li54G2JaQ87rTBa3m46g+4ymMm3wqVLWs5MrWo9GoU/ArHXWbQvRncOwP/sy/RV0 OSvzdH51dvNlMp6N3WYhEW2dnCoeeMd6MKJeFrao5gUv8xpSbNM6dSSpkRUGfPvU WtfBPmGftIbxLf3mrVB3HbPUllhrdmgxqQtUviqfoFhUQmrWhdT993kSBmAV1DEf bvpQEljrzxL5WJQlIp6VTc6Nyw0tm9bgQ05sse3W6KE+7c98Mhrag5jA/qAH9tiB veCA7kmYOB80DJ0Pit8HEAKef5DAEEbwir0uV7ZSfTv8dz9dmoiXrl37nm17Ytu6 YZpr5aPupHnejEtsldvC+lbB+jKgJKRbpwsd+kPGbtDtZ5NPzSV2su+C6+ZYCMPY xYpVrxu3j9VAB/Dfxmo648nW+cto6OQcRhbrA5XgR/Wuk9jhMdj1qLvlMEpeNn7E 2Bi3WB8A7i3pdee+hiro8vtxfAYWCs/vT1jV/yN+O75aqt1NY30IWDNcVrtGd9H+ hrhv3RgYiT387rw9dKmrV6Kq+atvdXHkj0YaEkuvaNRCbN3qvn6jsrh8/3sV/tf1 Dxd6pHENCmVuZHN0cmVhbQ0KZW5kb2JqDQozOCAwIG9iag0KMTEyNA0KZW5kb2Jq DQozNiAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMwIDAgUg0KL1Jl c291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJvY1NldCAy IDAgUg0KPj4NCi9Db250ZW50cyAzNyAwIFINCj4+DQplbmRvYmoNCjQwIDAgb2Jq DQo8PA0KL0xlbmd0aCA0MSAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0KPj4N CnN0cmVhbQ0KSInFlN9u0zAUxp8g73Cu0AA1HLuJk15wEViRihiCNYgLhKYocdKg 1slsZzBpD4/j/Gk7Cu0EGulFbcs+v+/7jpNrcBAQGKHAZgwkh88gwHkVOyTwXR9Y yFzqA8Tndh+CLMB58QbBHIA4d9BFNmuHKUzQpd34O5wthOaFTHQpCphHH6AUoDaJ 1GkiM/UU4m/OPHY+gnP9W77n05Z8goDAt3yDtxsNPWqKRmmgiPQklo8tgx4BUcKC wSljdmxYn2TJBTyBaL0+iUV8PEpCj46ZEhKMmeaV3JhMK5GsYQLzH3UpuYK3iWgS efsAuyRwj9uddql2bII7lcfEWPf3Ryc4G534Aeuqva80dyFK00pm7Q3Rlb0ky8UF JI1ecaHL1PqETCa5hi/0K+hVqeCGS2WWrRaEicWcm84jmbIBg2HYY6rcnOKgap6W +VixMpGJSoNq6rqS2m6pFW+yStxuYJOIpOAbI8EdKNSzlMnuVcNZ2PffBPTLQw6s 0QNr03tGWgR6wcAgnjcwiDk/BQ9M5hBACDN4wJqlxM9syTDYbevzyd/9dirT7ZVF nPYv4l3r8pKruhKKm6GZL7K2vXnJZTffPu+4KPTqMcSS8UqiR3aUms6FvZhBGSH7 894Qlzc8e5Rc/TFVn4Wj1ii+uoheXy0v58tWWxcdvDR9/49auy/G2d2wsh3t+aBB uJf5wWdwd796L/owY3D2bzyZj91PDpCJsA0KZW5kc3RyZWFtDQplbmRvYmoNCjQx IDAgb2JqDQo1NDQNCmVuZG9iag0KMzkgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K L1BhcmVudCAzMCAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAw IFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgNDAgMCBSDQo+ Pg0KZW5kb2JqDQo0MyAwIG9iag0KPDwNCi9MZW5ndGggNDQgMCBSDQovRmlsdGVy IC9GbGF0ZURlY29kZSANCj4+DQpzdHJlYW0NCkiJ7VfLjts2FP0C/8NdFWkNa/gQ JXkxC3cegItpME3VdlF0Ici0rVaWPJKMZAB/fC5fkvxQZyaZBFmEBmhaJnkf51zy 6AFGBAgElEEwDaCS8BcUMPo5HtFQeAKCKPCYAIiv9TwC1QpGF7cEcAHEyxHxSDBV wxQmxGNm/B7ezItGrqqkyYoV3MzuISug3iRVkybVov4R4n9HN/HoNxg9DNr3BVOW n+FAKLR9NK8novXZbrWrG2CEsGfZEkTZYE8YYjQIXaRBoMdo648qkwX8ALM8f5Yt KsiTlojP2pxSGrY5XZbVBnNaFkkOE7j5sM0qWcMvSbFLqscXhEtD7+lwucmqsU1p b2fcgkWKHCZv/0sOn7tAOAsiC09RyA/AFDEufr0WsJBNkuVyAfVWptkyS3WMnrbI qIf4TpivzKhtMMipxZsKPcQd47WEZVYh5ops2yT9TzaQ1dDgc/XknXzYSfx3vpBF kzWPHsRr/DsrsiZLDG4EJtrta9yYsC7/doxG7LYGBEjLzTbPMP3vs2atDb27vQLG Il9tLg3dQfEdU9/sqsLQPv4JN7X+ExrZjCSFdhPR3JZFLSGzfkKSpmW1UFXUlNrI 29kcclmsmrXn3La5Ua4GfczGE9vGx/1R17XxaSra4rK1tb8qN5ukWMBezw2Zwoe4 2TRqS4T4xCbuKk/qeg/zt7/DHu6p6hh2ej0NxMEGol3OI2vxLsXJpt1J/WVMTxhX LOzD9gXiZy4BSDxuU2C9QbdmRPWR7glpO4GdGCNW3p3GynqM4L+ql72qoCF3VcGm llXXuq6gXLo6uLB1cDHMr/lNfKuYfJSISf+c5aFFRrEd/qb/nKHiNLLnI4HTRs88 Y2ee8TNeED9sy8f3nQ2K6zn4gIcShBDBFF7wrIeN428Lzud9+qh3zCYB64hkIbmk mk/2hFpmsjK/u2aYdAniy7ury487QhHBaOdv/LiVl4T26tAuIPowG/bllCO0RRID GaasORNfzlncNxLOBKM+PyTtmSJqGf6dvsf05ZoD9mCnffoaeC7ZIH1b4vYOxG+Q w2q+aNUKUsed9scmjlA2MoXT4zvMxqNi/jPJd9LdWbRHUGPuzf6UuS4rr5OPw7Jj kctK4LSNViwyLfFeV0Lk/kRBVVZBKb2WrpNcaRAJSX3qeZ8p3GW9klsUN8gNVHn4 LtCvWqOZzlRje1F63AyfeVtig4PrcuBm77Cm1GHdipsBzXII+lS9IjnYadie8BgQ bbWLa3ulXpxy0St7vnyCKDhuQ2Gy7v2MhKRXBdarGTknYcT4yqHcahig4qBcXt1p HrzwajBqpsfH73Lma8mZntAXpNMzTs6QIT1jyXTKL/eC+RGSOKO0DQplbmRzdHJl YW0NCmVuZG9iag0KNDQgMCBvYmoNCjEwMTkNCmVuZG9iag0KNDIgMCBvYmoNCjw8 DQovVHlwZSAvUGFnZQ0KL1BhcmVudCAzMCAwIFINCi9SZXNvdXJjZXMgPDwNCi9G b250IDw8DQovRjAgNiAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29u dGVudHMgNDMgMCBSDQo+Pg0KZW5kb2JqDQo0NiAwIG9iag0KPDwNCi9MZW5ndGgg NDcgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZSANCj4+DQpzdHJlYW0NCkiJ7VZd b9MwFP0F+Q/3CQ1Qs2sncdKHPpR+SEUDjS3Aw7QHk7htIE06JwUm9cdjJ3Hadd3a iU284ErOrWX73I9zbN+AhYDACAXWZSAFfIUMrHehRXzP9oAFzKYeQDis5iHIGVin YwS1AMKphTayrjYj6KBNa/sXnEyyUswkL5NsBqP+OSQZFAsuy4jLuHgN4XdrFFqf wLp5EN/1qEY+wgHfq/AVfDVRofdXs1VRAkWkR2F5qDHoASBKmG8iZayyFdZnmYgM XkE/TY/CIh4eREKXtjklxG9zOs3lQuU0z3gKHRj9XiZSFPCeZysub58QLvHtw+E6 dVZrbLK9c5sxVn8ei4QE/vY+bzt/96u8QOhUAEOdH3ScxlMbPUpqmDWoFt4uRQ9d ba6rdeGbagGhhjDodINmwS4SbNqHodcZzHmaimwm7C88XQmz3U6W1pvxNvBnC9lh VchqawxMxEQxpYYeipInKeRTKOdCS+70QhTLPCvEaWR8Bx5FuYy1Jsu8mjcZhWO4 GA920qowAs83qiKuU2NQGrhwRa7NbOq2RWg1iN2gEQbC/Ub2jNE9Y86eOqNrPELi ugaDqPUOuKDICD4E0IUnjO0p13PytN6Z+o7RMgZINwQ1BeqpQfV/EousTKaJkJqw JhNnqnDlvEfYy/v6mJi2tATrB4Kr7QNiMoIaJjNRlP9OTVvcpYwYOXndhlihEkc5 T2Rc3V7nPPohSkgKIy4oVlEkigKyXJcsqg5l4MV9HTmUtAlyTEalWKqDW5VbxPpm 3FYiaJHZe7zESv9bRW/a291+t9vjU+sRIaZkg3yx4FkM60HKi2INk4+XioTnRHea ntUu1AnUxYG7qte3lLl6zyI1+Uw0JOnUK+7I+Jni6GAbBbJgw9SaotBH3QdVj9h2 bmPduQ9M+R1CjnUKdpz6fxQedbxsO95ta3ZZi6mnifnwSdiehaqKL+ztpqAn45VU 8pRKpu3jCyKewTehXlSlevv9VBqeynyxUXEs+bTcUzWXUUO02lTuxnm0Wqho4Ype X9vmjfUHjPV5VQ0KZW5kc3RyZWFtDQplbmRvYmoNCjQ3IDAgb2JqDQo3ODMNCmVu ZG9iag0KNDUgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCAzMCAwIFIN Ci9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQo+Pg0KL1Byb2NT ZXQgMiAwIFINCj4+DQovQ29udGVudHMgNDYgMCBSDQo+Pg0KZW5kb2JqDQo1MCAw IG9iag0KPDwNCi9MZW5ndGggNTEgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZSAN Cj4+DQpzdHJlYW0NCkiJlVddd9s2DP0F/g84fdiSNdb4IVFS9rC6btKlx8682m3P TpMHRaZtLbLkUlLb/PuBIil/pUvmJ7YCcYGLC4D5Aj0CBARlIGIBSsInKKD3etaj YeAFICLhsQBg9qa1I6CW0Pv1kgBegNmiRzwiYn1MoU88Zs7f4OSqqOVSJXVWLOFi MIGsgGqdqDpN1Lw6hdk/vYtZ7y/offkhvh8wjfyMAMKgxUf41hDRB82yqWpghLBn YQVEY7AngBgVoctUiPaMWB9UJgv4CQZ5/iwsGpAnkYjPOk4pDTtOF6VaI6dlkeTQ h4vvm0zJCt4lRZOoh/+RLg29p9PlhlWDTfmOZ3TBIi0Ow9tzamO8vJcLqWSRSiOB vvDwe5/52gXm6lI2t9D+M70FgJEHrbkINBppjTUvLOg4ityN13lT3J/BO3sFqXP2 hJOo06k5o/3HMs/vlExX9Rm8mEwmSGotiyq7yyUMmnolizpLW8pNxJSHOoh+m+Gb NlgiIqs/EgjrdqLKukzLHG5OUP03py/O4P3lEBiL/DMYJypdAY3jyMPv13++Hw9m Vx8vbk5bCNIRclCCz+y2NeBiJ6eYbnXiU2Oo+216NT6IH+YqWdTwVapK/ytA6Kvr ywPwPjr/ETw/gNe5M+rb3GksfGP4djqGGTJaIHAO041Ms4WLQX+jFGP14E22zGo0 SGWeN3mitviWW3RPaVdiEglb4lrmMi3X66awXiuoHqparjGjySqpJLCXN6e/HSCX C0A2HMNbCO77HYMktilMm7sqVdmdVHA11xTWDzAu5w2Koo+HuwwPF1+abLPGjwir 2cYPT5fQf6SEtCshEb7NcYKjEok6h0/Y4bmsKhgNrmEs51mzhkGa6v8ZlkWtWomN B8ObU0iKOUxWD5Wm/TEyt93ixuQoecAMkbU//sb7e3xVTyQSPCIGSrlrhNgOx2mN UemRDzi6YFRqReg4xxJD35Q5KqCAgZIJXMv6W6nuq3Nwd45yaDEiZjG4OSKIdj0p kbA7LP7ceTqgyTtKiJgoW/H6hNvExC3cMMZnK3noyChhkUmFBr6ZLyyIve1IIlHg PGJjWI9qkQLzI2HSMRe2Iw9biMcuChq7KMJbGCIzD2UDw7wsJCRt60z1CsUvam5E d3P6O1yqcg3DVaJQJiYoHrdzdVuY/SH8WpXlfeUGmjXe0YnP4p3dE5tLCJDh7jEd PKiqMs1MX01l2ijdH29V2WyOSeaBEwUTfujWc70q1c8VDOZzXGCVXQezX9pofeII 4ebY9kOlpdPu2uMe7va/1fU0XeXNGrt3ifJuzWP+X4xM5ToxbBi7R5uGMBsLF30e gWokzCXkCUxUpjcazp32N1lhvc4BXnIOFDiuxQj8CFfwcdws6t4TzJx1eSY4BMKI 4zQflc1X7ElZFFjaS5UgDFyskyxH95tGc/Gqyu88HIbHvHeBW07eNg9WsvHuFt1K 1hLd/IMbUVqxxoe7bmfec275GF1NhO4ZAR+KrF0vqAYcYFkF4jhnus0Zx511Yegc JhucBxmqfZqWdQ3dz1DqNKLDCMT2rRCJbmYiZBgQXBqWrN2fIw6J8GyWr/JsI7yF OmBPe+XcyZabY/eqxJcsvi4uE6WaZZYcJLjHkSVerjd5U+1Ez7sHa/fQ4TBKlmW7 pJFCqJqslqgdYipGIm9HvNTddsvCEmRr1hrviizkjis/DLl7iM2/leUcUqzVIxgu deffcucI8BY2+1dLk1wnwWP4ONi2UEhsxLFPcJsPB2fwYTo4Yv/oGThOvuteaw0D esyEJRrnWm2iQKPHKrJXi/2i+cLtFRq4Thx8lYXu8gYmWdoFQBn/8WiVqk6WthRR 8Oyq7SXFIuHmmU/tkw7O9TjxwWf2XRvv+nahOzEJwL8xuN04uk9360G3M8ec25kD lJAzoDyKKCBLsiirZ2qv1cZ+FgePBTCtS/29wWNMTtbJd28u+0tdvF053Vs9hQcT mVrGT0yLu79K/gXnCaoWDQplbmRzdHJlYW0NCmVuZG9iag0KNTEgMCBvYmoNCjE0 OTANCmVuZG9iag0KNDggMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA0 OSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQo+Pg0K L1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgNTAgMCBSDQo+Pg0KZW5kb2Jq DQo2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0K L05hbWUgL0YwDQovQmFzZUZvbnQgL0NvdXJpZXJOZXcNCi9GaXJzdENoYXIgMzEN Ci9MYXN0Q2hhciAyNTUNCi9XaWR0aHMgWyA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg DQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg DQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgXQ0KL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCi9Gb250RGVzY3JpcHRvciA3IDAgUg0K Pj4NCmVuZG9iag0KNyAwIG9iag0KPDwNCi9UeXBlIC9Gb250RGVzY3JpcHRvcg0K L0ZvbnROYW1lIC9Db3VyaWVyTmV3DQovRmxhZ3MgMzUNCi9Gb250QkJveCBbIC0y NTAgLTI1MCA3NTAgODc1IF0NCi9NaXNzaW5nV2lkdGggNjI1DQovU3RlbVYgMTEz DQovU3RlbUggMTEzDQovSXRhbGljQW5nbGUgMA0KL0NhcEhlaWdodCA4NzUNCi9Y SGVpZ2h0IDYxMg0KL0FzY2VudCA4NzUNCi9EZXNjZW50IC0yNTANCi9MZWFkaW5n IDEyNQ0KL01heFdpZHRoIDYyNQ0KL0F2Z1dpZHRoIDYyNQ0KPj4NCmVuZG9iag0K MTcgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1RydWVUeXBlDQov TmFtZSAvRjENCi9CYXNlRm9udCAvQXJpYWwNCi9GaXJzdENoYXIgMzENCi9MYXN0 Q2hhciAyNTUNCi9XaWR0aHMgWyA3NTAgMjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkg NjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggDQoyNzggNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4 NCA1ODQgDQo1NTYgMTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIy IDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIA0KNzc4IDY2NyA3NzggNzIyIDY2NyA2 MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMjc4IDI3OCAyNzggNDY5IA0KNTU2 IDMzMyA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAw IDIyMiA4MzMgNTU2IA0KNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3 MjIgNTAwIDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IA0KNzUwIDU1NiA3NTAgMjIy IDU1NiAzMzMgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCA3NTAg NzUwIA0KNzUwIDc1MCAyMjIgMjIyIDMzMyAzMzMgMzUwIDU1NiAxMDAwIDMzMyAx MDAwIDUwMCAzMzMgOTQ0IDc1MCA3NTAgDQo2NjcgMjc4IDMzMyA1NTYgNTU2IDU1 NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3MzcgDQo1NTIg NDAwIDU0OSAzMzMgMzMzIDMzMyA1NzYgNTM3IDI3OCAzMzMgMzMzIDM2NSA1NTYg ODM0IDgzNCA4MzQgDQo2MTEgNjY3IDY2NyA2NjcgNjY3IDY2NyA2NjcgMTAwMCA3 MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAyNzggMjc4IA0KMjc4IDcyMiA3MjIgNzc4 IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3 IA0KNjExIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDg4OSA1MDAgNTU2IDU1NiA1 NTYgNTU2IDI3OCAyNzggMjc4IA0KMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiA1NDkgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IA0KNTAwIF0NCi9F bmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQovRm9udERlc2NyaXB0b3IgMTggMCBS DQo+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwNCi9UeXBlIC9Gb250RGVzY3JpcHRv cg0KL0ZvbnROYW1lIC9BcmlhbA0KL0ZsYWdzIDMyDQovRm9udEJCb3ggWyAtMjUw IC0xODggMTI3NiA5MzggXQ0KL01pc3NpbmdXaWR0aCA3NTANCi9TdGVtViA4MA0K L1N0ZW1IIDgwDQovSXRhbGljQW5nbGUgMA0KL0NhcEhlaWdodCA5MzgNCi9YSGVp Z2h0IDY1Ng0KL0FzY2VudCA5MzgNCi9EZXNjZW50IC0xODgNCi9MZWFkaW5nIDE4 OA0KL01heFdpZHRoIDEwNjMNCi9BdmdXaWR0aCA0MzgNCj4+DQplbmRvYmoNCjIy IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05h bWUgL0YyDQovQmFzZUZvbnQgL1N5bWJvbA0KL0ZpcnN0Q2hhciAzMQ0KL0xhc3RD aGFyIDI1NQ0KL1dpZHRocyBbIDYwMCAyNTAgMzMzIDcxMyA1MDAgNTQ5IDgzMyA3 NzggNDM5IDMzMyAzMzMgNTAwIDU0OSAyNTAgNTQ5IDI1MCANCjI3OCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NDkgNTQ5 IDU0OSANCjQ0NCA1NDkgNzIyIDY2NyA3MjIgNjEyIDYxMSA3NjMgNjAzIDcyMiAz MzMgNjMxIDcyMiA2ODYgODg5IDcyMiANCjcyMiA3NjggNzQxIDU1NiA1OTIgNjEx IDY5MCA0MzkgNzY4IDY0NSA3OTUgNjExIDMzMyA4NjMgMzMzIDY1OCANCjUwMCA1 MDAgNjMxIDU0OSA1NDkgNDk0IDQzOSA1MjEgNDExIDYwMyAzMjkgNjAzIDU0OSA1 NDkgNTc2IDUyMSANCjU0OSA1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3MTMgNjg2 IDQ5MyA2ODYgNDk0IDQ4MCAyMDAgNDgwIDU0OSANCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAN CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCANCjYwMCA2MDAgNjIwIDI0NyA1NDkgMTY3IDcxMyA1 MDAgNzUzIDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyA5ODcgDQo2MDMgNDAwIDU0 OSA0MTEgNTQ5IDU0OSA3MTMgNDk0IDQ2MCA1NDkgNTQ5IDU0OSA1NDkgMTAwMCA2 MDMgMTAwMCANCjY1OCA4MjMgNjg2IDc5NSA5ODcgNzY4IDc2OCA4MjMgNzY4IDc2 OCA3MTMgNzEzIDcxMyA3MTMgNzEzIDcxMyANCjcxMyA3NjggNzEzIDc5MCA3OTAg ODkwIDgyMyA1NDkgMjUwIDcxMyA2MDMgNjAzIDEwNDIgOTg3IDYwMyA5ODcgDQo2 MDMgNDk0IDMyOSA3OTAgNzkwIDc4NiA3MTMgMzg0IDM4NCAzODQgMzg0IDM4NCAz ODQgNDk0IDQ5NCA0OTQgDQo0OTQgNjAwIDMyOSAyNzQgNjg2IDY4NiA2ODYgMzg0 IDM4NCAzODQgMzg0IDM4NCAzODQgNDk0IDQ5NCA0OTQgDQo2MDAgXQ0KL0ZvbnRE ZXNjcmlwdG9yIDIzIDAgUg0KPj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8DQovVHlw ZSAvRm9udERlc2NyaXB0b3INCi9Gb250TmFtZSAvU3ltYm9sDQovRmxhZ3MgNg0K L0ZvbnRCQm94IFsgLTI1MCAtMjUwIDEyNzYgMTAwMCBdDQovTWlzc2luZ1dpZHRo IDYyNQ0KL1N0ZW1WIDExMw0KL1N0ZW1IIDExMw0KL0l0YWxpY0FuZ2xlIDANCi9D YXBIZWlnaHQgMTAwMA0KL1hIZWlnaHQgNzAwDQovQXNjZW50IDEwMDANCi9EZXNj ZW50IC0yNTANCi9MZWFkaW5nIDI1MA0KL01heFdpZHRoIDEwNjMNCi9BdmdXaWR0 aCA2MjUNCj4+DQplbmRvYmoNCjIgMCBvYmoNClsgL1BERiAvVGV4dCAgXQ0KZW5k b2JqDQo1IDAgb2JqDQo8PA0KL0tpZHMgWzQgMCBSIDEwIDAgUiAxMyAwIFIgMTYg MCBSIDIxIDAgUiAyNiAwIFIgXQ0KL0NvdW50IDYNCi9UeXBlIC9QYWdlcw0KL1Bh cmVudCA1MiAwIFINCj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PA0KL0tpZHMgWzI5 IDAgUiAzMyAwIFIgMzYgMCBSIDM5IDAgUiA0MiAwIFIgNDUgMCBSIF0NCi9Db3Vu dCA2DQovVHlwZSAvUGFnZXMNCi9QYXJlbnQgNTIgMCBSDQo+Pg0KZW5kb2JqDQo0 OSAwIG9iag0KPDwNCi9LaWRzIFs0OCAwIFIgXQ0KL0NvdW50IDENCi9UeXBlIC9Q YWdlcw0KL1BhcmVudCA1MiAwIFINCj4+DQplbmRvYmoNCjUyIDAgb2JqDQo8PA0K L0tpZHMgWzUgMCBSIDMwIDAgUiA0OSAwIFIgXQ0KL0NvdW50IDEzDQovVHlwZSAv UGFnZXMNCi9NZWRpYUJveCBbIDAgMCA2MTIgNjk2IF0NCj4+DQplbmRvYmoNCjEg MCBvYmoNCjw8DQovQ3JlYXRvciA8RkVGRjAwNEQwMDY5MDA2MzAwNzIwMDZGMDA3 MzAwNkYwMDY2MDA3NDAwMjAwMDU3MDA2RjAwNzIwMDY0MDAyMD4NCi9DcmVhdGlv bkRhdGUgKEQ6MjAwMjA5MjUxNTA1MjUpDQovVGl0bGUgPEZFRkYwMDY0MDA3MjAw NjEwMDY2MDA3NDAwMkQwMDc1MDA3MjAwNjkwMDY1MDA2RTAwMkQwMDQ1MDA0MTAw NTAwMDJEMDA3MzAwNkQwMDYxMDA3MjAwNzQwMDYzMDA2MTAwNzIwMDY0MDAyRDAw MzAwMDMxMDAyRTAwMzUwMDJFMDA2NDAwNkYwMDYzPg0KL0F1dGhvciA8RkVGRjAw NTUwMDUyMDA0OTAwNDUwMDRFMDAyRDAwNTA+DQovUHJvZHVjZXIgKEFjcm9iYXQg UERGV3JpdGVyIDQuMDUgcG91ciBXaW5kb3dzKQ0KPj4NCmVuZG9iag0KMyAwIG9i ag0KPDwNCi9QYWdlcyA1MiAwIFINCi9UeXBlIC9DYXRhbG9nDQovRGVmYXVsdEdy YXkgNTMgMCBSDQovRGVmYXVsdFJHQiAgNTQgMCBSDQo+Pg0KZW5kb2JqDQo1MyAw IG9iag0KWy9DYWxHcmF5DQo8PA0KL1doaXRlUG9pbnQgWzAuOTUwNSAxIDEuMDg5 MSBdDQovR2FtbWEgMC4yNDY4IA0KPj4NCl0NCmVuZG9iag0KNTQgMCBvYmoNClsv Q2FsUkdCDQo8PA0KL1doaXRlUG9pbnQgWzAuOTUwNSAxIDEuMDg5MSBdDQovR2Ft bWEgWzAuMjQ2OCAwLjI0NjggMC4yNDY4IF0NCi9NYXRyaXggWzAuNDM2MSAwLjIy MjUgMC4wMTM5IDAuMzg1MSAwLjcxNjkgMC4wOTcxIDAuMTQzMSAwLjA2MDYgMC43 MTQxIF0NCj4+DQpdDQplbmRvYmoNCnhyZWYNCjAgNTUNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAyMjMxOCAwMDAwMCBuDQowMDAwMDIxODU5IDAwMDAwIG4NCjAw MDAwMjI2OTggMDAwMDAgbg0KMDAwMDAwMTI3OCAwMDAwMCBuDQowMDAwMDIxODkz IDAwMDAwIG4NCjAwMDAwMTc3MTQgMDAwMDAgbg0KMDAwMDAxODgyOCAwMDAwMCBu DQowMDAwMDAwMDIxIDAwMDAwIG4NCjAwMDAwMDEyNTUgMDAwMDAgbg0KMDAwMDAw MjMxMyAwMDAwMCBuDQowMDAwMDAxNDA5IDAwMDAwIG4NCjAwMDAwMDIyOTAgMDAw MDAgbg0KMDAwMDAwMzczNyAwMDAwMCBuDQowMDAwMDAyNDQ2IDAwMDAwIG4NCjAw MDAwMDM3MTMgMDAwMDAgbg0KMDAwMDAwNTQ2OSAwMDAwMCBuDQowMDAwMDE5MTA0 IDAwMDAwIG4NCjAwMDAwMjAyMjIgMDAwMDAgbg0KMDAwMDAwMzg3MCAwMDAwMCBu DQowMDAwMDA1NDQ1IDAwMDAwIG4NCjAwMDAwMDczMzggMDAwMDAgbg0KMDAwMDAy MDQ5NCAwMDAwMCBuDQowMDAwMDIxNTgyIDAwMDAwIG4NCjAwMDAwMDU2MTUgMDAw MDAgbg0KMDAwMDAwNzMxNCAwMDAwMCBuDQowMDAwMDA4ODcwIDAwMDAwIG4NCjAw MDAwMDc0OTcgMDAwMDAgbg0KMDAwMDAwODg0NiAwMDAwMCBuDQowMDAwMDEwMjI2 IDAwMDAwIG4NCjAwMDAwMjIwMDkgMDAwMDAgbg0KMDAwMDAwOTAwMyAwMDAwMCBu DQowMDAwMDEwMjAyIDAwMDAwIG4NCjAwMDAwMTE0MDIgMDAwMDAgbg0KMDAwMDAx MDM2MCAwMDAwMCBuDQowMDAwMDExMzc5IDAwMDAwIG4NCjAwMDAwMTI3NzAgMDAw MDAgbg0KMDAwMDAxMTUzNiAwMDAwMCBuDQowMDAwMDEyNzQ2IDAwMDAwIG4NCjAw MDAwMTM1NTcgMDAwMDAgbg0KMDAwMDAxMjkwNCAwMDAwMCBuDQowMDAwMDEzNTM0 IDAwMDAwIG4NCjAwMDAwMTQ4MjAgMDAwMDAgbg0KMDAwMDAxMzY5MSAwMDAwMCBu DQowMDAwMDE0Nzk2IDAwMDAwIG4NCjAwMDAwMTU4NDYgMDAwMDAgbg0KMDAwMDAx NDk1NCAwMDAwMCBuDQowMDAwMDE1ODIzIDAwMDAwIG4NCjAwMDAwMTc1ODAgMDAw MDAgbg0KMDAwMDAyMjEyNyAwMDAwMCBuDQowMDAwMDE1OTgwIDAwMDAwIG4NCjAw MDAwMTc1NTYgMDAwMDAgbg0KMDAwMDAyMjIxMCAwMDAwMCBuDQowMDAwMDIyNzk2 IDAwMDAwIG4NCjAwMDAwMjI4ODQgMDAwMDAgbg0KdHJhaWxlcg0KPDwNCi9TaXpl IDU1DQovUm9vdCAzIDAgUg0KL0luZm8gMSAwIFINCi9JRCBbPDU5NWEyMjMyNTky YjA1YjFhODE2MjE5M2NhNDk3YzU3Pjw1OTVhMjIzMjU5MmIwNWIxYTgxNjIxOTNj YTQ5N2M1Nz5dDQo+Pg0Kc3RhcnR4cmVmDQoyMzA2Mg0KJSVFT0YNCg== --Boundary_(ID_bLbStQzN33JnITioLGsgaw) Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Ml80GpQYcWrZjloOMnAI0g)" Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --Boundary_(ID_Ml80GpQYcWrZjloOMnAI0g) Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Pascal Urien SchlumbergerSema Smartcard Research Center 36-38 rue de la Princesse BP45 78431 Louveciennes Cedex. T=E9l : 33 1 30 08 48 69 Fax : 33 1 30 08 45 24 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- --Boundary_(ID_Ml80GpQYcWrZjloOMnAI0g) Content-Type: TEXT/HTML; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-= *-*-*-*-*-*-
Pascal Urien
SchlumbergerSema
Smartcard Research Center
36-38 rue de la Princesse
BP45 78431 Louveciennes Cedex.
T=E9l :  33 1 30 08 48 69
Fax : 33 1 30 08 45 24
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-= *-*-*-*-*-*-

--Boundary_(ID_Ml80GpQYcWrZjloOMnAI0g)-- --Boundary_(ID_bLbStQzN33JnITioLGsgaw)-- From aboba@internaut.com Tue Oct 22 23:01:54 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 22 Oct 2002 15:01:54 -0700 (PDT) Subject: [eap] Early cut at I-D Message-ID: Here is an early cut at an I-D based on the minutes and position papers of the EAP Design Team. Suggests for organization, conclusions, etc. welcome. http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-esteem-00.txt From jose.p.puthenkulam@intel.com Wed Oct 23 01:24:27 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Tue, 22 Oct 2002 17:24:27 -0700 Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method seque nces and tunnels Message-ID: Its really good that we are trying to fix this problem in EAP if possible. But don't we need to address the EAP key derivation framework first before we address this issue. The reason is that any key derivation framework we add to EAP will have to be designed with such a cryptographic binding capability between sequenced or tunnelled EAP methods. Thanks, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, October 21, 2002 7:09 PM To: eap@frascone.com Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 21, 2002 Reference: Document: RFC2284bis-06 Comment type: T Priority: S Section: 4.3 Rationale/Explanation of issue: When EAP methods are used as part of a sequence or within a tunnel, RFC 2284 does not provide a mechanism to cryptographically bind subsequent authentication methods together. The result of this is that neither side of the conversation has any assurance that they are talking to the same endpoint throughout the conversation, making EAP implementations vulnerable to a man-in-the-middle attack. A number of existing EAP methods are vulnerable to such an attack. The problem occurs on the peer, where a rogue NAS could fool a peer into authenticating to it, while acting as a man-in-the-middle, and tunneling the peer's authentication to another authenticator. The vulnerability also exists on the server, where a proxy can handle a portion of an authentication sequence while routing other portions to other servers. With EAP being increasingly adopted across multiple media, including cellular, IEEE 802, and PPP, the need for such a binding facility has become critical. Binding requires both sides to demonstrate that they acted as the endpoint for the sequence of authentication methods. On the peer, this implies that the same entity acted as the peer in each of the sequence of authentication mechanisms. Similarly, on the authenticator, binding implies that the same entity acted as the authenticator in each method within the sequence. There may be situations in which it may not be desirable for binding to be required. For example, the server may not wish to demonstrate binding, but may desire the client to do so. Alternatively, the client may demand that the server demonstrate binding. As a result, some flexibility is required within the binding facility. Note that there are a number of choices as to how binding might be demonstrated: a. Individual EAP methods may incorporate keys derived from previous methods in order to demonstrate not only possession of a shared secret, token or certificate, but possession of previously derived key(s) as well. However, this approach has the disadvantage of requiring that existing EAP methods be modified to accomodate the binding facility. In many cases this will not be possible since those methods are already developed and deployed. b. The binding facility can be provided within individual EAP methods. This has the advantage of not requiring EAP implementations to be upgraded, but has the disadvantage of requiring the same facility to be developed multiple times. This would result in overlapping effort as well as poor interoperability among implementations. c. The binding facility can be provided within EAP itself. This has the advantage of enabling widespread interoperability between implementations, and applicability to multiple EAP methods. However, it has the disadvantage of being harder to deploy. Suggested changes Add to section 7.2: "[7] Protection against man-in-the-middle attacks. Where EAP is tunneled within another protocol, or where a sequence of EAP method is used for authentication, it is necessary for each endpoint to demonstrate that it has participated in each method within the authentication sequence. If this cannot be demonstrated then, the authentication sequence or tunnel is vulnerable to a man-in-the-middle attack. " Add a binding facility to EAP itself, possibly in concert with acknowleged EAP Success/Failure. Resolution: Discuss _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Oct 23 17:37:25 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 23 Oct 2002 09:37:25 -0700 (PDT) Subject: [eap] Issue 41: NAK of Vendor-Specific Message-ID: Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 23, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 5.5 Rationale/Explanation of issue: It is possible that both a peer and authenticator will support the Vendor-Specific Type (255), but may support multiple Vendor-Ids and Vendor-Types within those Vendor-Ids. If so, what happens when the authenticator proposes the Vendor-Specific EAP Type, and the client supports the Vendor-Specific type (255), but not the vendorID or Vendor-Specific Type that is being proposed? Here is the example Vendor-ID payload: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=255 | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Do we need to allow for a "Vendor-Specific NAK", which might include a list of vendor-Ids and Vendor-Types that are supported? Or does the peer just NAK with an alternate type, and force the authenticator to guess what Vendor-Ids or Vendor-Types within those Vendor-IDs might be supported? From aboba@internaut.com Thu Oct 24 03:19:09 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 23 Oct 2002 19:19:09 -0700 (PDT) Subject: [eap] 10/23/02 Minutes of the EAP Design Team Message-ID: Short minutes from today. I didn't have time to write down all the discussion on John's paper, so feel free to add items. Jari ------- Date: Oct 23rd, 2002 Present: Bob Moskowitz, Nick Petroni, Jari Arkko, Yoshihiro Ohba, Glen Zorn, John Vollbrecht, Paul Congdon, Joseph Salowey 1. John's position paper. - Was submitted, but bounced the list. He started to do state tables which assumes the methods can also privide information to the EAP mux. Clearly needs more work, but he'd be happy to pursue it. - There's a couple of main things: - It would be possible to map this back to the states that are in the state machine now. Though it doesn't make any distinction about methods, even identity is seen as a method. - Assumes policing. Some of the actions assume that policies will dictate certain things. - Starts to imply things about the API. - Bernard: This is fairly complete. - Bernard: There are two cases when you receive method X request. One, we are done and should change state. Two, we need further requests. In addition, there are error situations. - Bernard: If within a method, you receive another method, is this NAKked or silently discarded. - DECISION: NAK is better than silent discard. - Question: Is a failure of a method terminal? We could either terminate EAP, or allow continuation with another method per policy? - John thinks we should allow the latter. - Jari thinks we should not. - Question: is the treatment of final success or fail dependent on whether the previous method failed or succeeded? - Proposal: We need a new state for this. - Question: is there a global state, what has happened on all methods, useful maybe for reauthentication? How can reauthentication - Answer: Good question. - Jari: Why is not authenticated vs. nocurrent methods there? - Jari: Reformulated question: is Success / Fail illegal at the beginning? - Bernard: Maybe this is policy? - Jari: If we can avoid policy, we should. 2. Moving Forward o Drafts: - Bernard: I encourage John to write up this state machine with this draft. - Jari: Should we have an individual draft by John, or merge drafts to WG draft status. - DECISION: Too early now. - Bernard: It would be better if Brian and Nick could do another revision of their draft as well. - DECISION: Priorities are: 1) follow decisions 2) be complete 3) follow 802 format. - Jari: Need to capture current decisions. Bernard: We are tracking the issues. - Bernard: One of the open issues is described above - Yoshihiro: We also need to consider the passthrough state machine. - Jari: That can also be done as a separate draft. - DECISION: By the I-D deadlines, we will have the following: - 2-3 state machines - rfc2248 updated to -07 - some solved issues - many unsolved issues - position papers and minutes will also be published o IETF-55 and where do we go from there - We will have a total of 4.5 hours and 2 slots. - On the first day, state machine is important and the issues are important - Second day is still unclear - What kind of method discussion we can have is under discussion. - John: Method discussion is key for EAP. - Bernard: We need to try to discuss issues in the methods, see if they are affected by state machine modifications etc. - Process for evaluating methods. Drafts solicited. Luca, Glen are writing something about this. - Glen: Cart is pushing the horse. Compatibility with 802.1x is not so important. Bernard: Tony Jeffrey views the 802 state machine as a way to suffle EAP packets around. The job of the IETF state machine is to decide what to do with the packets. Because the IETF state machine is link layer independent, it is at a higher abstraction layer. We will use similar format, but it is not the intention to force this state machine to comply with 802 state machine. o Continue with dt meetings after initial I-D deadline? - John: Not available next week. - Jari: We should continue. - DECISION: Meetings continue and next week we will go over the open issues. From aboba@internaut.com Thu Oct 24 03:20:30 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 23 Oct 2002 19:20:30 -0700 (PDT) Subject: [eap] This week's position paper: Strawman EAP state machine Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------02FD777D9EE385857BF89D51 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: -------- Original Message -------- Subject: EAP.states.doc/ position paper Date: Tue, 22 Oct 2002 20:38:06 -0400 From: jrv@interlinknetworks.com Reply-To: jrv@interlinknetworks.com To: EAP-Design Attached is a word document which is a position paper with an initial state description using an EAP model with an EAP switch and multiple EAP methods. I apologize for using word, but I wanted to include the state diagram as an spreadsheet and this is the only way I know how to do this easily. John --------------02FD777D9EE385857BF89D51 Content-Type: APPLICATION/MSWORD; NAME="1_EAP.states.doc" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="1_EAP.states.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAfAAAAAAA AAAAEAAAfgAAAAEAAAD+////AAAAAHsAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAWyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA CxcAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAAAAAJBBYAIoIAAIBqAQCAagEA2hIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgAAAAAAAAAqAAAAAAAAABkAQAA AAAAAGQBAAAAAAAAZAEAABQAAAAAAAAAAAAAAHgBAAAAAAAAbCAAAAAAAABsIAAAAAAAAGwg AAAAAAAAbCAAACQAAACQIAAARAEAAHgBAAAAAAAAEk0AAAABAADgIQAAAAAAAOAhAAAAAAAA 4CEAAAAAAADgIQAAAAAAAOAhAAAAAAAAySgAAAAAAADJKAAAAAAAAMkoAAAAAAAAtUwAAAIA AAC3TAAAAAAAALdMAAAAAAAAt0wAAAAAAAC3TAAAAAAAALdMAAAAAAAAt0wAAAAAAAASTgAA IAIAADJQAABmAAAAt0wAABUAAAAAAAAAAAAAAAAAAAAAAAAAZAEAAAAAAADJKAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAhJwAAqAEAAMkoAAAAAAAAySgAAAAAAADJKAAAAAAAALdMAAAAAAAA zTAAAAAAAACoAAAAAAAAAKgAAAAAAAAA4CEAAAAAAAAAAAAAAAAAAOAhAABBBQAAzEwAABYA AADNMAAAAAAAAM0wAAAAAAAAzTAAAAAAAADJKAAA5gIAAKgAAACGAAAA4CEAAAAAAABkAQAA AAAAAOAhAAAAAAAAtUwAAAAAAAAAAAAAAAAAAM0wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAySgAAAAAAAC1TAAAAAAAAM0wAAAsBQAA zTAAAAAAAAD5NQAAqgAAAPFCAAB8AAAALgEAADYAAABkAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaUQAAAAAAADgIQAA AAAAANQhAAAMAAAAkHzhGix6wgF4AQAA9B4AAGwgAAAAAAAArysAAO4DAABtQwAAEgAAAAAA AAAAAAAAaUQAAEwIAADiTAAAMAAAABJNAAAAAAAAf0MAAOoAAACYUAAAAAAAAJ0vAAAwAQAA mFAAAAAAAABpRAAAAAAAAM0wAAAAAAAAeAEAAAAAAAB4AQAAAAAAAKgAAAAAAAAAqAAAAAAA AACoAAAAAAAAAKgAAAAAAAAAAgDZAAAAVGhlIGZvbGxvd2luZyBpcyBhIGZpcnN0IHBhc3Mg YXQgYSBzdGF0ZSBkaWFncmFtIHRoYXQgaW5jbHVkZXMgYW4gRUFQIHN3aXRjaCBhbmQgbXVs dGlwbGUgbWV0aG9kcy4gIEl0IG5lZWRzIG1vcmUgd29yaywgYW5kIEkgYW0gd2lsbGluZyB0 byBmaWxsIGl0IGluIG1vcmUsIGJ1dCBJIGFtIGN1cmlvdXMgYWJvdXQgd2hldGhlciB0aGlz IGlzIHNlZW4gYXMgaGVscGZ1bC4NDVRoZSBwb2xpY3kgaW4gdGhlIHN3aXRjaCBzZWVtcyB0 aGUgbW9zdCBpbnRlcmVzdGluZy4gIEFub3RoZXIgdGhpbmcgdGhhdCBtaWdodCBiZSBpbnRl cmVzdGluZyBpcyB0byB0YWxrIGFib3V0IHdoYXQgY2FuIGJlIHBhc3NlZCBiZXR3ZWVuIG1l dGhvZHMsIGFuZCB3aGV0aGVyIHRoaXMgc2hvdWxkIGFsc28gZ28gdGhyb3VnaCB0aGUgRUFQ IHN3aXRjaCBvciBiZSBsZWZ0IHRvIGxvY2FsIGltcGxlbWVudGF0aW9uIG1ldGhvZHMuICAN DUkgdGhpbmsgdGhpcyBzb3J0IG9mIG1vZGVsIGNvdWxkIGJlIGhlbHBmdWwgaW4gdW5kZXJz dGFuZGluZyBzdGF0ZSB0cmFuc2l0aW9ucywgYW5kIGluIGRlZmluaW5nIHJlcXVpcmVtZW50 cyBmb3IgRUFQIG1ldGhvZHMuDQ0NCAgNDQ0IDQ0IDQgICAgNCA0NDQ0NDVRoZSBtb2RlbCBp cyB0aGF0IHRoZXJlIGFyZSB0d28gRUFQIHN3aXRjaGVzLCBvbmUgYXQgdGhlIFBlZXIgYW5k IG9uZSBhdCB0aGUgYXV0aGVudGljYXRvci4gIFRoZXNlIGVhY2ggaGF2ZSB0aGUgYWJpbGl0 eSB0byBzdXBwb3J0IHNvbWUgaW50ZXJuYWwgcG9saWN5LCB0aGUgZGV0YWlscyBvZiB3aGlj aCBhcmUgbm90IGluY2x1ZGVkLg0NQXQgYm90aCB0aGUgcGVlciBhbmQgYXV0aGVudGljYXRv ciBvbmUgb3IgbW9yZSBFQVAgbWV0aG9kIGV4aXN0cy4gIFRoZSBFQVAgc3dpdGNoZXMgc2Vs ZWN0IHdoaWNoIG1ldGhvZHMgZWFjaCBpcyB3aWxsaW5nIHRvIHVzZSwgYW5kIG5lZ290aWF0 ZSBiZXR3ZWVuIHRoZW1zZWx2ZXMgdG8gcGljayBhIG1ldGhvZCBvciBzZXF1ZW5jZSBvZiBt ZXRob2RzLg0NVGhlIG1haW4gdGhydXN0IG9mIHRoaXMgaW5pdGlhbCBkZXNjcmlwdGlvbiBp cyBnaXZlIGFuIGlkZWEgb2YgaG93IHRoZSBzdGF0ZSBtYWNoaW5lcyBvbiBlYWNoIG9mIHRo ZSBzd2l0Y2hlcyB3aWxsIHdvcmsuICBOb3RlIHRoYXQgdGhlIG1ldGhvZHMgbWF5IGFsc28g aGF2ZSBzdGF0ZSBtYWNoaW5lcywgYnV0IHRoZSBkZXRhaWxzIG9mIHRoZXNlIGFyZSBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgcGFwZXIuDQ1UaGUgcGVlciBFQVAgaGFzIHRoZSBmb2xsb3dp bmcgc3RhdGVzDQ1pbmFjdGl2ZS9ub3QgYXV0aGVudGljYXRlZCCWIHdhaXRpbmcgZm9yIGFu IEVBUCByZXF1ZXN0DWFjdGl2ZS9tZXRob2Q9eCCWIGRvaW5nIG1ldGhvZCB4DWFjdGl2ZS9u b2N1cnJlbnQgbWV0aG9kIJYgd2FpdGluZyBmb3IgcmVxdWVzdCBmb3IgbmV4dCBtZXRob2QN aW5hY3RpdmUvYXV0aGVudGljYXRlZA0NRXZlbnRzIHJlY29nbml6ZWQgYnkgdGhlIHBlZXIg RUFQIGFyZQ0NRUFQLVJlcS9vayAgICAgICAgICAgICAgICAgICAgICAgICAtIEVBUCByZXF1 ZXN0IGFjY2VwdGFibGUgdG8gcGVlciBwb2xpY3kNRUFQLVJlcS9ub3RvayAgICAgICAgICAg ICAgICAgICAgLSBFQVAgcmVxdWVzdCBub3QgYWNjZXB0YWJsZSB0byBwZWVyIHBvbGljeQ1F QVAtIFN1Y2Nlc3MNRUFQLSBGYWlsDU1ldGhvZC1yZXNwLmZpbmFsIC5nb29kICAgICAgIJYg Z29vZCB0ZXJtaW5hdGlvbiBmcm9tIG1ldGhvZA1NZXRob2QtcmVzcC5maW5hbCAuZmFpbCAg ICAgICAgIC0gZmFpbHVyZSB0ZXJtaW5hdGlvbiBmcm9tIG1ldGhvZA1NZXRob2QtcmVzcC1j b250ICAgICAgICAgICAgICAgICAgliBjb250aW51aW5nIHJlc3BvbnNlIGZyb20gbWV0aG9k DQ1BY3Rpb25zIGluaXRpYXRlZCBieSBwZWVyIEVBUCBhcmUNDVNlbmQgRUFQLU5BSw1TZW5k IEVBUC1SZXNwDUZvcndhcmQgRUFQLXJlcSB0byBtZXRob2QNU2VuZCBtZXRob2QgdGVybWlu YXRlIHRvIG1ldGhvZA1TaWduYWwgYWNjZXB0IG9yIHJlamVjdCB0byBzeXN0ZW0gIC0gDQ1T dGF0ZSAtIHBlZXIgRUFQB0V2ZW50B05leHQgU3RhdGUHQWN0aW9uB0FjdGlvbjIHBwcHBwcH B0luYWN0aXZlL25vdCBhdXRoZW50aWNhdGVkB0VBUC1SZXEvb2sHYWN0aXZlL21ldGhvZD14 B0ZvcndhcmQgRUFQLXJlcSB0byBtZXRob2QHBwcHRUFQLVJlcS9ub3Qgb2sHSW5hY3RpdmUv bm90IGF1dGhlbnRpY2F0ZWQHU2VuZCBOQUsHBwcHKgdJbmFjdGl2ZS9ub3QgYXV0aGVudGlj YXRlZAcHBwcHBwcHBwdhY3RpdmUvbWV0aG9kPXgHRUFQLVJlcS9vawdhY3RpdmUvbWV0aG9k PXgHRm9yd2FyZCBFQVAtcmVxIHRvIG1ldGhvZAcHBwdFQVAtUmVxL25vdCBvawdJbmFjdGl2 ZS9ub3QgYXV0aGVudGljYXRlZAdTZW5kIE5BSwdTZW5kIFRlcm1pbmF0ZSB0byBtZXRob2Q9 eAcHB21ldGhvZC1yZXNwLmZpbmFsLmdvb2QHYWN0aXZlL25vY3VycmVudCBtZXRob2QHU2Vu ZCBFQVAgUmVzcAcHBwdtZXRob2QtcmVzcC5maW5hbC5mYWlsB2FjdGl2ZS9ub2N1cnJlbnQg bWV0aG9kB1NlbmQgRUFQIFJlc3AHBwcHbWV0aG9kLXJlc3AtY29udAdhY3RpdmUvbWV0aG9k PXgHU2VuZCBFQVAgUmVzcAcHBwcHBwcHB2FjdGl2ZS9ub2N1cnJlbnQgbWV0aG9kB0VBUC1S ZXEvb2sHYWN0aXZlL21ldGhvZD14B0ZvcndhcmQgRUFQLXJlcSB0byBtZXRob2QHBwcHRUFQ LVJlcS9ub3Qgb2sHYWN0aXZlL25vY3VycmVudCBtZXRob2QHU2VuZCBOQUsHBwcHRUFQLVN1 Y2Nlc3MHaW5hY3RpdmUvYXV0aGVudGljYXRlZAdTaWduYWwgLSBhY2NlcHQHBwcHRUFQLUZh aWwHSW5hY3RpdmUvbm90IGF1dGhlbnRpY2F0ZWQHU2lnbmFsLXJlamVjdAcHBwcqB2FjdGl2 ZS9ub2N1cnJlbnQgbWV0aG9kBwcHBwcHBwcHBwcHBwcHB2luYWN0aXZlL2F1dGhlbnRpY2F0 ZWQHRUFQLVJlcS9vawdhY3RpdmUvbWV0aG9kPXgHRm9yd2FyZCBFQVAtcmVxIHRvIG1ldGhv ZAcHBwdFQVAtUmVxL25vdCBvawdpbmFjdGl2ZS9hdXRoZW50aWNhdGVkB1NlbmQgTkFLBwcH ByoHaW5hY3RpdmUvYXV0aGVudGljYXRlZAcHBwcNDQ0NDQ0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDUZvciBhdXRoZW50aWNhdG9y IHRoZSBmb2xsb3dpbmcgc3RhdGVzIGV4aXN0DQ1pbmFjdGl2ZSAgICAgICAgICAgICAgICAg ICAgICAgICAgLSB3YWl0aW5nIGZvciBzdGFydCBpbmRpY2F0aW9uDSBhY3RpdmUvbWV0aG9k PXguMSAgICAgICAglmZpcnN0IG1lc3NhZ2Ugb2YgbWV0aG9kIHggc2VudA1hY3RpdmUvbWV0 aG9kPXguYyAgICAgICAgIC0gIGNvbnRpbnVpbmcgbWVzc2FnZSBvZiAgbWV0aG9kIHggc2Vu dA1hY3RpdmUvbWV0aG9kPXguYSAgICAgICAgLSBtZXRob2QgeCBhY3RpdmUgb24gYXV0aGVu dGljYXRvcg0NRm9yIGF1dGhlbnRpY2F0b3IgdGhlIGZvbGxvd2luZyBldmVudHMgYXJlIGRl ZmluZWQNDWluaXRpYXRlIEVBUCAgICAgICAtIGV4dGVybmFsIHNpZ25hbCAoZS5nLiBmcm9t IFJBRElVUykgdG8gc3RhcnQgRUFQDXJlY2VpdmUgRUFQLU5BSw1yZWNlaXZlIEVBUC1SZXNw Lm1ldGhvZC5lcS54DXJlY2VpdmUgRUFQLVJlc3AubWV0aG9kLm5lLngNcmVjZWl2ZSBFQVAt cmVxLjEgZnJvbSBtZXRob2QNcmVjZWl2ZSBFQVAtcmVxLmMgZnJvbSBtZXRob2QNcmVjZWl2 ZSBtZXRoLVN1Y2Nlc3Mgb3IgbWV0aC1GYWlsIGZyb20gbWV0aG9kDQ0NCAgICFRoZSBmb2xs b3dpbmcgYWN0aW9ucw0IDWluaXRpYXRlIG1ldGhvZCAod2l0aCBwYXJhbWV0ZXJzKQ1mb3J3 YXJkIEVBUC1SZXEgDXNlbmQgRUFQIFN1Y2Nlc3Mgb3IgRmFpbHVyZQ10ZXJtaW5hdGUgbWV0 aG9kDXNpZ25hbCBhY2NlcHQgb3IgcmVqZWN0IHRvIHN5c3RlbQ0NDQ0NBwcHBwdTdGF0ZSAt IGF1dGhlbnRpY2F0b3IgRUFQBwcHBwcHBwcHB2luYWN0aXZlB2luaXRpYXRlIEVBUAdhY3Rp dmUvbWV0aG9kPXguYQdzdGFydCBtZXRob2QgeAcHByoHaW5hY3RpdmUHBwcHBwcHBwcHBwcH YWN0aXZlL21ldGhvZD14LmEHcmVjZWl2ZSBFQVAtcmVxLjEHYWN0aXZlL21ldGhvZD14LjEH Zm9yd2FyZCBFQVAtcmVxBwcHcmVjZWl2ZSBFQVAtcmVxLmMHYWN0aXZlL21ldGhvZD14LmMH Zm9yd2FyZCBFQVAtcmVxBwcHcmVjZWl2ZSBNZXRoLVN1Y2Nlc3MHYWN0aXZlL25vIG1ldGhv ZAcHBwdyZWNlaXZlIE1ldGgtRmFpbAdhY3RpdmUvbm8gbWV0aG9kBwcHByoHBwcHBwcHBwdh Y3RpdmUvbWV0aG9kPXguMQdyZWNlaXZlLU5BSwdhY3RpdmUvbm9tZXRob2QHBwcHcmVjZWl2 ZS1FQVAtcmVzcC14B2FjdGl2ZS9tZXRob2Q9eC5hB2ZvcncgcmVzcG9uc2UgdG8gbWV0aG9k IHgHBwdyZWNlaXZlLUVBUC1yZXNwLW5vdC14B2luYWN0aXZlB3Rlcm1pbmF0ZSBtZXRob2QH BwcqBwcHBwcHBwcHYWN0aXZlL21ldGhvZD14LmMHcmVjZWl2ZS1OQUsHaW5hY3RpdmUHdGVy bWluYXRlIG1ldGhvZAcHB3JlY2VpdmUtRUFQLXJlc3AteAdhY3RpdmUvbWV0aG9kPXguYwdm b3J3IHJlc3BvbnNlIHRvIG1ldGhvZCB4BwcHcmVjZWl2ZS1FQVAtcmVzcC1ub3QteAdpbmFj dGl2ZQd0ZXJtaW5hdGUgbWV0aG9kBwcHKgcHBwcHBwcHB2FjdGl2ZS9ub21ldGhvZAcobm8g cG9saWN5KQdpbmFjdGl2ZQdTZW5kIEVBUCBTdWNjZXNzL0ZhaWx1cmUHBwcobW9yZSBwb2xp Y3kpB2FjdGl2ZS9tZXRob2Q9eC5hB3N0YXJ0IG1ldGhvZCB4BwcHBwcHBw1QZWVyIG1ldGhv ZA0NQXV0aC0gbWV0aG9kDQ1BdXRoLUVBUA0NUGVlci1FQVANDQ0NAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAE0GAABPBgAAUQYAAFQGAABVBgAAVwYAAFgGAABZBgAAXQYAAF4GAABfBgAA ZQYAAOsLAAD7CwAA/AsAAAEMAAACDAAADAwAAA0MAAATDAAAFAwAABsMAAAcDAAAHQwAACIM AAAjDAAAPQwAAD4MAABIDAAASQwAAFgMAABZDAAAcgwAAHQMAAB1DAAAdgwAAIQMAACFDAAA nwwAAKAMAACoDAAAqgwAAKsMAACsDAAArQwAAK4MAADIDAAAywwAAMwMAADRDAAA0gwAAOEM AADiDAAA7AwAAO0MAAD8DAAA/QwAABYNAAAYDQAAGQ0AABoNAAAoDQAAKQ0AAEMNAABEDQAA TA0AAE0NAABnDQAAaA0AAGkNAABqDQAAgA0AAIENAACYDQAAmQ0AAKYNAACoDQAAqQ0AAPnx 5PHk8eTx5PHk8QDZzNnM2czZzNnMx8zH2czZzNnM2czHzNnM2czZzMfM2czZzMfMx9nM2czZ zNnMx8zZzNnM2czZzMfM2czZzNnMxwAAAAAIQ0oUAGFKFAAAGENKEgBPSgIAUEoDAFFKAgBe SgIAYUoSAAAUQ0oSAE9KAgBRSgIAXkoCAGFKEgAAGANqAAAAAENKFABVCAFtSAAEbkgABHUI AQAPQ0oUAG1IAARuSAAEdQgBC21IAARuSAAEdQgBAE4ABAAA1QQAANYEAADOBQAAzwUAAE0G AABOBgAATwYAAFIGAABTBgAAVAYAAFYGAABXBgAAWQYAAF4GAABgBgAAYQYAAGIGAABjBgAA ZAYAAGUGAAAmBwAAJwcAAPIHAADzBwAA2wgAANwIAAACCQAAAwkAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAAHAAEAADaFgAAChcAAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECAwkAADsJAABcCQAAmgkAALEJAACyCQAA 2AkAANkJAAAkCgAAcQoAAH4KAACICgAAxQoAAAcLAABLCwAATAsAAG4LAABvCwAAfAsAAIoL AACkCwAAxAsAAOoLAADrCwAA/AsAAAIMAAANDAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAAAPAAAWJAEYhPz/ GYQBABsmYCMkAS+EtABJZgEAAAAFAAAKJgALRgMABQAACiYAC0YCAAABAAAFAAAKJgALRgEA ABoNDAAAFAwAABwMAAAdDAAAHgwAAB8MAAAgDAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAA AAA8GAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAswAAFiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8BCeUQQRm1ImUsACcQ Cf////////////////////8AJ+QH/////////////////////wAnXAj///////////////// ////ACd0Cf////////////////////8AJ7AJ/////////////////////w02YA6U/P8PlAEA EJS0ABT2A3QsFTYBGtYU//////////////////////////8b1hT///////////////////// /////xzWFP//////////////////////////HdYU//////////////////////////8elLQA MtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAA MtYGAwQLAw8AMtYGAwQEAwAAMtYGBAULAw8AMtYGBAUEAwAANNYGAAEPAwAAYfYDAAAPAAAW JAEYhPz/GYQBABsmYCMkAS+EtABJZgEAAAAABiAMAAAhDAAAIgwAACMMAAA+DAAASQwAAFkM AADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAADxIAQAAAAAAAAAAAADwAAAAAAAAAAAAAAAA 8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzAAAWJAEXJAFJZgEA AAAHlP8ACNZyAAXx/wEJ5RBBGbUiZSwAIwAA/////////////////////wAjAAD///////// ////////////ACMAAP////////////////////8AIwAA/////////////////////wAjAAD/ ////////////////////DTZgDpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT///////////////// /////////xvWFP//////////////////////////HNYU//////////////////////////8d 1hT//////////////////////////x6UtAAy1gYAAQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy 1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAAy1gYEBQsDDwAy 1gYEBQQDAAA01gYAAQ8DAABh9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQBL4S0AElmAQAAAAAG WQwAAHMMAAB0DAAAdQwAAHYMAACFDAAAoAwAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA PNgAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAALMAABYkARckAUlmAQAAAAeU/wAI1nIABfH/AQnlEEEZtSJlLAAjAAD/ ////////////////////ACMAAP////////////////////8AIwAA//////////////////// /wAjAAD/////////////////////ACMAAP////////////////////8NNmAOlPz/D5QBABCU tAAU9gN0LBU2ARrWFP//////////////////////////G9YU//////////////////////// //8c1hT//////////////////////////x3WFP//////////////////////////HpS0ADLW BgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLW BgMECwMPADLWBgMEBAMAADLWBgQFCwMPADLWBgQFBAMAADTWBgABDwMAAGH2AwAADwAAFiQB GIT8/xmEAQAbJmAjJAEvhLQASWYBAAAAAAagDAAAqQwAAKoMAACrDAAArAwAAK4MAADJDAAA 8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA8hAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAA AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAswAAFiQBFyQBSWYBAAAA B5T/AAjWcgAF8f8BCeUQQRm1ImUsACMAAP////////////////////8AIwAA//////////// /////////wAjAAD/////////////////////ACMAAP////////////////////8AIwAA//// /////////////////w02YA6U/P8PlAEAEJS0ABT2A3QsFTYBGtYU//////////////////// //////8b1hT//////////////////////////xzWFP//////////////////////////HdYU //////////////////////////8elLQAMtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYG AQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAAMtYGBAULAw8AMtYG BAUEAwAANNYGAAEPAwAAYfYDAAAPAAAWJAEYhPz/GYQBABsmYCMkAS+EtABJZgEAAAAABskM AADKDAAAywwAAMwMAADNDAAAzgwAAM8MAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAADwY AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACzAAAWJAEXJAFJZgEAAAAHlP8ACNZyAAXx/wEJ5RBBGbUiZSwAIwAA//// /////////////////wAjAAD/////////////////////ACMAAP////////////////////8A IwAA/////////////////////wAjAAD/////////////////////DTZgDpT8/w+UAQAQlLQA FPYDdCwVNgEa1hT//////////////////////////xvWFP////////////////////////// HNYU//////////////////////////8d1hT//////////////////////////x6UtAAy1gYA AQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYD BAsDDwAy1gYDBAQDAAAy1gYEBQsDDwAy1gYEBQQDAAA01gYAAQ8DAABh9gMAAA8AABYkARiE /P8ZhAEAGyZgIyQBL4S0AElmAQAAAAAGzwwAANAMAADRDAAA0gwAAOIMAADtDAAA/QwAAPAA AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAPBwBAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAA AAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALMAABYkARckAUlmAQAAAAeU /wAI1nIABfH/AQnlEEEZtSJlLAAjAAD/////////////////////ACMAAP////////////// //////8AIwAA/////////////////////wAjAAD/////////////////////ACMAAP////// //////////////8NNmAOlPz/D5QBABCUtAAU9gN0LBU2ARrWFP////////////////////// ////G9YU//////////////////////////8c1hT//////////////////////////x3WFP// ////////////////////////HpS0ADLWBgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgEC BAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADLWBgQFCwMPADLWBgQF BAMAADTWBgABDwMAAGH2AwAADwAAFiQBGIT8/xmEAQAbJmAjJAEvhLQASWYBAAAAAAb9DAAA Fw0AABgNAAAZDQAAGg0AACkNAABEDQAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA8QAEA AAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAswAAFiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8BCeUQQRm1ImUsACMAAP////// //////////////8AIwAA/////////////////////wAjAAD/////////////////////ACMA AP////////////////////8AIwAA/////////////////////w02YA6U/P8PlAEAEJS0ABT2 A3QsFTYBGtYU//////////////////////////8b1hT//////////////////////////xzW FP//////////////////////////HdYU//////////////////////////8elLQAMtYGAAEL Aw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQL Aw8AMtYGAwQEAwAAMtYGBAULAw8AMtYGBAUEAwAANNYGAAEPAwAAYfYDAAAPAAAWJAEYhPz/ GYQBABsmYCMkAS+EtABJZgEAAAAABkQNAABNDQAAaA0AAGkNAABqDQAAgQ0AAJkNAADwAAAA AAAAAAAAAAAA8AAAAAAAAAAAAAAAADwAAQAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAA AAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzAAAWJAEXJAFJZgEAAAAHlP8A CNZyAAXx/wEJ5RBBGbUiZSwAIwAA/////////////////////wAjAAD///////////////// ////ACMAAP////////////////////8AIwAA/////////////////////wAjAAD///////// ////////////DTZgDpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT///////////////////////// /xvWFP//////////////////////////HNYU//////////////////////////8d1hT///// /////////////////////x6UtAAy1gYAAQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQD AAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAAy1gYEBQsDDwAy1gYEBQQD AAA01gYAAQ8DAABh9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQBL4S0AElmAQAAAAAGmQ0AAKcN AACoDQAAqQ0AAKoNAADBDQAA2Q0AAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAPAABAAAA AAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALMAABYkARckAUlmAQAAAAeU/wAI1nIABfH/AQnlEEEZtSJlLAAjAAD///////// ////////////ACMAAP////////////////////8AIwAA/////////////////////wAjAAD/ ////////////////////ACMAAP////////////////////8NNmAOlPz/D5QBABCUtAAU9gN0 LBU2ARrWFP//////////////////////////G9YU//////////////////////////8c1hT/ /////////////////////////x3WFP//////////////////////////HpS0ADLWBgABCwMP ADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMP ADLWBgMEBAMAADLWBgQFCwMPADLWBgQFBAMAADTWBgABDwMAAGH2AwAADwAAFiQBGIT8/xmE AQAbJmAjJAEvhLQASWYBAAAAAAapDQAAqg0AAMANAADBDQAA2A0AANkNAADmDQAA6A0AAOkN AADqDQAA+g0AAPsNAAAKDgAACw4AABgOAAAaDgAAGw4AACAOAAAhDgAAOA4AADkOAABDDgAA RA4AAFMOAABUDgAAbQ4AAG8OAABwDgAAcQ4AAH8OAACADgAAlw4AAJgOAACgDgAAog4AAKMO AACkDgAArw4AALAOAADGDgAAxw4AANYOAADYDgAA2Q4AANoOAADiDgAA4w4AAP0OAAD+DgAA Cw8AAA0PAAAODwAADw8AABAPAAARDwAAKA8AACsPAAAsDwAAMQ8AADIPAAA3DwAAOA8AAE4P AABPDwAAWQ8AAFoPAABpDwAAag8AAIMPAACFDwAAhg8AAIcPAACVDwAAlg8AAKwPAACtDwAA tQ8AALcPAAC4DwAAuQ8AALoPAAC7DwAA0Q8AANQPAADVDwAADBMAAPPo8+jz6PPj8+jz6PPo 8+Pz4+jz6PPo8+jz4/Po8+jz6PPj8+jz6PPo8+Pz6PPo8+jz4/Po8+jz4/Pj8+Po8+jz6PPo 8+Pz6PPo8+jz4/Po8+jz4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACENKFABhShQAABRD ShIAT0oCAFFKAgBeSgIAYUoSAAAYQ0oSAE9KAgBQSgMAUUoCAF5KAgBhShIAVdkNAADnDQAA 6A0AAOkNAADqDQAA+w0AAAsOAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAADzIAAAAAAAA AAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACzAAAWJAEXJAFJZgEAAAAHlP8ACNZyAAXx/wEJ5RBBGbUiZSwAIwAA//////////// /////////wAjAAD/////////////////////ACMAAP////////////////////8AIwAA//// /////////////////wAjAAD/////////////////////DTZgDpT8/w+UAQAQlLQAFPYDdCwV NgEa1hT//////////////////////////xvWFP//////////////////////////HNYU//// //////////////////////8d1hT//////////////////////////x6UtAAy1gYAAQsDDwAy 1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy 1gYDBAQDAAAy1gYEBQsDDwAy1gYEBQQDAAA01gYAAQ8DAABh9gMAAA8AABYkARiE/P8ZhAEA GyZgIyQBL4S0AElmAQAAAAAGCw4AABkOAAAaDgAAGw4AABwOAAAdDgAAHg4AAPAAAAAAAAAA AAAAAADwAAAAAAAAAAAAAAAAPBgAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAA AAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALMAABYkARckAUlmAQAAAAeU/wAI1nIA BfH/AQnlEEEZtSJlLAAjAAD/////////////////////ACMAAP////////////////////8A IwAA/////////////////////wAjAAD/////////////////////ACMAAP////////////// //////8NNmAOlPz/D5QBABCUtAAU9gN0LBU2ARrWFP//////////////////////////G9YU //////////////////////////8c1hT//////////////////////////x3WFP////////// ////////////////HpS0ADLWBgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLW BgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADLWBgQFCwMPADLWBgQFBAMAADTW BgABDwMAAGH2AwAADwAAFiQBGIT8/xmEAQAbJmAjJAEvhLQASWYBAAAAAAYeDgAAHw4AACAO AAAhDgAAOQ4AAEQOAABUDgAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA8PAEAAAAAAAAA AAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAswAAFiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8BCeUQQRm1ImUsACMAAP////////////// //////8AIwAA/////////////////////wAjAAD/////////////////////ACMAAP////// //////////////8AIwAA/////////////////////w02YA6U/P8PlAEAEJS0ABT2A3QsFTYB GtYU//////////////////////////8b1hT//////////////////////////xzWFP////// ////////////////////HdYU//////////////////////////8elLQAMtYGAAELAw8AMtYG AAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYG AwQEAwAAMtYGBAULAw8AMtYGBAUEAwAANNYGAAEPAwAAYfYDAAAPAAAWJAEYhPz/GYQBABsm YCMkAS+EtABJZgEAAAAABlQOAABuDgAAbw4AAHAOAABxDgAAgA4AAJgOAADwAAAAAAAAAAAA AAAA8AAAAAAAAAAAAAAAADzMAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAA APAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzAAAWJAEXJAFJZgEAAAAHlP8ACNZyAAXx /wEJ5RBBGbUiZSwAIwAA/////////////////////wAjAAD/////////////////////ACMA AP////////////////////8AIwAA/////////////////////wAjAAD///////////////// ////DTZgDpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT//////////////////////////xvWFP// ////////////////////////HNYU//////////////////////////8d1hT///////////// /////////////x6UtAAy1gYAAQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYC AwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAAy1gYEBQsDDwAy1gYEBQQDAAA01gYA AQ8DAABh9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQBL4S0AElmAQAAAAAGmA4AAKEOAACiDgAA ow4AAKQOAACwDgAAxw4AAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAPNgAAAAAAAAAAAAA APAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALMAABYkARckAUlmAQAAAAeU/wAI1nIABfH/AQnlEEEZtSJlLAAjAAD///////////////// ////ACMAAP////////////////////8AIwAA/////////////////////wAjAAD///////// ////////////ACMAAP////////////////////8NNmAOlPz/D5QBABCUtAAU9gN0LBU2ARrW FP//////////////////////////G9YU//////////////////////////8c1hT///////// /////////////////x3WFP//////////////////////////HpS0ADLWBgABCwMPADLWBgAB BAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgME BAMAADLWBgQFCwMPADLWBgQFBAMAADTWBgABDwMAAGH2AwAADwAAFiQBGIT8/xmEAQAbJmAj JAEvhLQASWYBAAAAAAbHDgAA1w4AANgOAADZDgAA2g4AAOMOAAD+DgAA8AAAAAAAAAAAAAAA APAAAAAAAAAAAAAAAAA81AAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAswAAFiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8B CeUQQRm1ImUsACMAAP////////////////////8AIwAA/////////////////////wAjAAD/ ////////////////////ACMAAP////////////////////8AIwAA//////////////////// /w02YA6U/P8PlAEAEJS0ABT2A3QsFTYBGtYU//////////////////////////8b1hT///// /////////////////////xzWFP//////////////////////////HdYU//////////////// //////////8elLQAMtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgML Aw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAAMtYGBAULAw8AMtYGBAUEAwAANNYGAAEP AwAAYfYDAAAPAAAWJAEYhPz/GYQBABsmYCMkAS+EtABJZgEAAAAABv4OAAAMDwAADQ8AAA4P AAAPDwAAEQ8AACkPAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAADx4AAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACz AAAWJAEXJAFJZgEAAAAHlP8ACNZyAAXx/wEJ5RBBGbUiZSwAIwAA//////////////////// /wAjAAD/////////////////////ACMAAP////////////////////8AIwAA//////////// /////////wAjAAD/////////////////////DTZgDpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT/ /////////////////////////xvWFP//////////////////////////HNYU//////////// //////////////8d1hT//////////////////////////x6UtAAy1gYAAQsDDwAy1gYAAQQD AAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQD AAAy1gYEBQsDDwAy1gYEBQQDAAA01gYAAQ8DAABh9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQB L4S0AElmAQAAAAAGKQ8AACoPAAArDwAALA8AAC0PAAAuDwAALw8AAPAAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAAPBgAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALMAABYkARckAUlmAQAAAAeU/wAI1nIABfH/AQnl EEEZtSJlLAAjAAD/////////////////////ACMAAP////////////////////8AIwAA//// /////////////////wAjAAD/////////////////////ACMAAP////////////////////8N NmAOlPz/D5QBABCUtAAU9gN0LBU2ARrWFP//////////////////////////G9YU//////// //////////////////8c1hT//////////////////////////x3WFP////////////////// ////////HpS0ADLWBgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMP ADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADLWBgQFCwMPADLWBgQFBAMAADTWBgABDwMA AGH2AwAADwAAFiQBGIT8/xmEAQAbJmAjJAEvhLQASWYBAAAAAAYvDwAAMA8AADEPAAAyDwAA Mw8AADQPAAA1DwAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA8GAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAswAA FiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8BCeUQQRm1ImUsACMAAP////////////////////8A IwAA/////////////////////wAjAAD/////////////////////ACMAAP////////////// //////8AIwAA/////////////////////w02YA6U/P8PlAEAEJS0ABT2A3QsFTYBGtYU//// //////////////////////8b1hT//////////////////////////xzWFP////////////// ////////////HdYU//////////////////////////8elLQAMtYGAAELAw8AMtYGAAEEAwAA MtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAA MtYGBAULAw8AMtYGBAUEAwAANNYGAAEPAwAAYfYDAAAPAAAWJAEYhPz/GYQBABsmYCMkAS+E tABJZgEAAAAABjUPAAA2DwAANw8AADgPAABPDwAAWg8AAGoPAADwAAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAADw4AQAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzAAAWJAEXJAFJZgEAAAAHlP8ACNZyAAXx/wEJ5RBB GbUiZSwAIwAA/////////////////////wAjAAD/////////////////////ACMAAP////// //////////////8AIwAA/////////////////////wAjAAD/////////////////////DTZg DpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT//////////////////////////xvWFP////////// ////////////////HNYU//////////////////////////8d1hT///////////////////// /////x6UtAAy1gYAAQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy 1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAAy1gYEBQsDDwAy1gYEBQQDAAA01gYAAQ8DAABh 9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQBL4S0AElmAQAAAAAGag8AAIQPAACFDwAAhg8AAIcP AACWDwAArQ8AAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAPMgAAAAAAAAAAAAAAPAAAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALMAABYk ARckAUlmAQAAAAeU/wAI1nIABfH/AQnlEEEZtSJlLAAjAAD/////////////////////ACMA AP////////////////////8AIwAA/////////////////////wAjAAD///////////////// ////ACMAAP////////////////////8NNmAOlPz/D5QBABCUtAAU9gN0LBU2ARrWFP////// ////////////////////G9YU//////////////////////////8c1hT///////////////// /////////x3WFP//////////////////////////HpS0ADLWBgABCwMPADLWBgABBAMAADLW BgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADLW BgQFCwMPADLWBgQFBAMAADTWBgABDwMAAGH2AwAADwAAFiQBGIT8/xmEAQAbJmAjJAEvhLQA SWYBAAAAAAatDwAAtg8AALcPAAC4DwAAuQ8AALsPAADSDwAA8AAAAAAAAAAAAAAAAPAAAAAA AAAAAAAAAAA8dAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAswAAFiQBFyQBSWYBAAAAB5T/AAjWcgAF8f8BCeUQQRm1 ImUsACMAAP////////////////////8AIwAA/////////////////////wAjAAD///////// ////////////ACMAAP////////////////////8AIwAA/////////////////////w02YA6U /P8PlAEAEJS0ABT2A3QsFTYBGtYU//////////////////////////8b1hT///////////// /////////////xzWFP//////////////////////////HdYU//////////////////////// //8elLQAMtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYG AgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAAMtYGBAULAw8AMtYGBAUEAwAANNYGAAEPAwAAYfYD AAAPAAAWJAEYhPz/GYQBABsmYCMkAS+EtABJZgEAAAAABtIPAADTDwAA1A8AANUPAADWDwAA 1w8AANgPAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6AAAAAAAA AAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAACzAAAWJAEX JAFJZgEAAAAHlP8ACNZyAAXx/wEJ5RBBGbUiZSwAIwAA/////////////////////wAjAAD/ ////////////////////ACMAAP////////////////////8AIwAA//////////////////// /wAjAAD/////////////////////DTZgDpT8/w+UAQAQlLQAFPYDdCwVNgEa1hT///////// /////////////////xvWFP//////////////////////////HNYU//////////////////// //////8d1hT//////////////////////////x6UtAAy1gYAAQsDDwAy1gYAAQQDAAAy1gYB AgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAAy1gYE BQsDDwAy1gYEBQQDAAA01gYAAQ8DAABh9gMAAA8AABYkARiE/P8ZhAEAGyZgIyQBL4S0AElm AQAAAAAG2A8AANkPAADaDwAA2w8AALQQAAC1EAAA4hAAAOMQAAAkEQAAXhEAAKARAADcEQAA 3REAABASAAAREgAAVhIAAGYSAACDEgAAoBIAAL4SAADcEgAAChMAAAsTAAAMEwAAJhMAACgT AABKEwAAWxMAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAK JgALRgYABQAACiYAC0YFAAUAAAomAAtGBAAAAQAAABsMEwAAEBMAACYTAAAnEwAArhMAALIT AACzEwAAzBMAANATAADREwAA1RMAANYTAADeEwAA3xMAAOsTAADsEwAA/RMAAP4TAAAMFAAA DRQAAA4UAAAPFAAAEBQAABEUAAAZFAAAGxQAABwUAAAgFAAAIRQAACUUAAAmFAAANxQAADgU AABJFAAAShQAAFsUAABcFAAAaxQAAGwUAABtFAAAbhQAAH8UAACAFAAAkRQAAJIUAAChFAAA ohQAAKMUAACkFAAAuBQAALkUAADJFAAAyxQAAMwUAADNFAAA3hQAAN8UAADvFAAA8RQAAPIU AADzFAAA9BQAAPcUAAD4FAAA/BQAAP0UAAAOFQAADxUAABoVAAAbFQAAKhUAACwVAAAtFQAA LhUAAEAVAABBFQAAUhUAAFMVAABsFQAAbRUAAG4VAABvFQAAhRUAAIYVAADzAPMA5uHW5uHm 4dbm1ubW5tbm4ebW5tbm4ebh5uHW5gDT1ubW5uHm1ubW5tbm4ebW5tbm4ebW5tbm4ebW5uHm 4dbm1ubW5uHm1ubW5tbm4ebW5gAAAARQSgMAABRDShQAT0oCAFFKAgBeSgIAYUoUAAAIQ0oU AGFKFAAAGENKFABPSgIAUEoDAFFKAgBeSgIAYUoUAAAYA2oAAAAAQ0oUAFUIAW1IAARuSAAE dQgBU1sTAAB3EwAAiBMAAKoTAACrEwAArBMAAK0TAACuEwAArxMAALATAACxEwAAshMAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAA AAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAGAAAWJAFJZgEAAAAAAQAABQAACiYAC0YGAAALshMAALMTAADNEwAAzhMAAM8TAADQEwAA cXgAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAI4AABYkARckAUlmAQAA AAeU/wAI1lwABPH/AQk+EZoZGiMAJxAJ/////////////////////wAnIAj///////////// ////////ACdcCP////////////////////8AJ3QJ/////////////////////xT2AwAjFTYB GtYQ/////////////////////xvWEP////////////////////8c1hD///////////////// ////HdYQ/////////////////////zLWBgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgEC BAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADTWBgABDwMAAGH2AwAA AAXQEwAA0RMAANITAADTEwAA1BMAANUTAADWEwAA3xMAAOwTAAD+EwAADRQAAA4UAAAPFAAA cRQAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsA AAAAAAAAAAAAAABx4AAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAA AAAAAAAAAAAAawAAAAAAAAAAAAAAAHE4AAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAAjgAAFiQBFyQBSWYBAAAAB5T/AAjWXAAE8f8BCT4RmhkaIwAjAAD///// ////////////////ACMAAP////////////////////8AIwAA/////////////////////wAj AAD/////////////////////FPYDACMVNgEa1hD/////////////////////G9YQ//////// /////////////xzWEP////////////////////8d1hD/////////////////////MtYGAAEL Aw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQL Aw8AMtYGAwQEAwAANNYGAAEPAwAAYfYDAAAADA8UAAARFAAAGhQAABsUAAAcFAAAHRQAAB4U AAAfFAAAIBQAACEUAAAiFAAAIxQAACQUAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAABrFAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAGsUAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAACOAAAWJAEXJAFJZgEAAAAHlP8ACNZcAATx/wEJ PhGaGRojACMAAP////////////////////8AIwAA/////////////////////wAjAAD///// ////////////////ACMAAP////////////////////8U9gMAIxU2ARrWEP////////////// //////8b1hD/////////////////////HNYQ/////////////////////x3WEP////////// //////////8y1gYAAQsDDwAy1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy 1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQDAAA01gYAAQ8DAABh9gMAAAYAABYkAUlmAQAAAAAM JBQAACUUAAAmFAAAOBQAAEoUAABcFAAAbBQAAPkAAAAAAAAAAAAAAABrHAEAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI4A ABYkARckAUlmAQAAAAeU/wAI1lwABPH/AQk+EZoZGiMAIwAA/////////////////////wAj AAD/////////////////////ACMAAP////////////////////8AIwAA//////////////// /////xT2AwAjFTYBGtYQ/////////////////////xvWEP////////////////////8c1hD/ ////////////////////HdYQ/////////////////////zLWBgABCwMPADLWBgABBAMAADLW BgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADTW BgABDwMAAGH2AwAABgAAFiQBSWYBAAAAAAZsFAAAbRQAAG4UAACAFAAAkhQAAKIUAABx2AAA AAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAjgAAFiQBFyQBSWYBAAAAB5Q7 AQjWXAAE8f8BCT4RmhkaIwAjAAD/////////////////////ACMAAP////////////////// //8AIwAA/////////////////////wAjAAD/////////////////////FPYDACMVNgEa1hD/ ////////////////////G9YQ/////////////////////xzWEP////////////////////8d 1hD/////////////////////MtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAA MtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAANNYGAAEPAwAAYfYDAAAABaIU AACjFAAApBQAALkUAADKFAAAyxQAAMwUAADNFAAA3xQAAPAUAADxFAAA8hQAAPMUAABxpAAA AAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAA AAAAAAAAAHGYAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAA AAAAAABrAAAAAAAAAAAAAAAAcRgAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAAAAAAAAAAAGAAAW JAFJZgEAAACOAAAWJAEXJAFJZgEAAAAHlP8ACNZcAATx/wEJPhGaGRojACMAAP////////// //////////8AIwAA/////////////////////wAjAAD/////////////////////ACMAAP// //////////////////8U9gMAIxU2ARrWEP////////////////////8b1hD///////////// ////////HNYQ/////////////////////x3WEP////////////////////8y1gYAAQsDDwAy 1gYAAQQDAAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy 1gYDBAQDAAA01gYAAQ8DAABh9gMAAAAM8xQAAPUUAAD2FAAA9xQAAPgUAAD5FAAA+hQAAPsU AAD8FAAA/RQAAA8VAAAbFQAAKxUAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAGsUAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAAa8AAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAAAAAAAAAI4AABYkARckAUlmAQAAAAeU/wAI1lwABPH/AQk+EZoZ GiMAIwAA/////////////////////wAjAAD/////////////////////ACMAAP////////// //////////8AIwAA/////////////////////xT2AwAjFTYBGtYQ//////////////////// /xvWEP////////////////////8c1hD/////////////////////HdYQ//////////////// /////zLWBgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgID BAMAADLWBgMECwMPADLWBgMEBAMAADTWBgABDwMAAGH2AwAABgAAFiQBSWYBAAAAAAwrFQAA LBUAAC0VAAAuFQAAQRUAAFMVAABtFQAAbhUAAG8VAACGFQAAjxUAAKAVAAChFQAA+QAAAAAA AAAAAAAAAGsEAQAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAAa8wAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABrGAAAAAAAAAAAAAAAAAAAAAAAjgAAFiQB FyQBSWYBAAAAB5T/AAjWXAAE8f8BCT4RmhkaIwAjAAD/////////////////////ACMAAP// //////////////////8AIwAA/////////////////////wAjAAD///////////////////// FPYDACMVNgEa1hD/////////////////////G9YQ/////////////////////xzWEP////// //////////////8d1hD/////////////////////MtYGAAELAw8AMtYGAAEEAwAAMtYGAQIL Aw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAANNYGAAEP AwAAYfYDAAAGAAAWJAFJZgEAAAAADIYVAACOFQAAjxUAAJ8VAACgFQAAoRUAAKIVAACjFQAA phUAAKcVAACrFQAArBUAAL0VAAC+FQAAyRUAAMoVAADSFQAA0xUAAOMVAADkFQAA5RUAAOYV AAD4FQAA+RUAAAoWAAALFgAAJBYAACUWAAAmFgAAJxYAAD0WAAA+FgAARhYAAEcWAABXFgAA WBYAAFkWAABaFgAAWxYAAF4WAABfFgAAYxYAAGQWAABzFgAAdBYAAH8WAACAFgAAiBYAAIkW AAChFgAAohYAAKMWAACkFgAAsRYAALIWAADDFgAAxBYAANIWAADTFgAA1BYAANgWAADZFgAA CxcAAPXo9ejj6PXo4+jj9ej16PXo9ejj6PXo9ej16OPo9ej16PXo4+j16OPo4/Xo9ej16PXo 4+j16PXo9ejj6OMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQ0oUAGFKFAAA GENKFABPSgIAUEoDAFFKAgBeSgIAYUoUAAAUQ0oUAE9KAgBRSgIAXkoCAGFKFAA+oRUAAKIV AACkFQAApRUAAKYVAACnFQAAqBUAAKkVAACqFQAAqxUAAKwVAAC+FQAAyhUAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABrFAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AGvkAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAI4AABYkARck AUlmAQAAAAeU/wAI1lwABPH/AQk+EZoZGiMAIwAA/////////////////////wAjAAD///// ////////////////ACMAAP////////////////////8AIwAA/////////////////////xT2 AwAjFTYBGtYQ/////////////////////xvWEP////////////////////8c1hD///////// ////////////HdYQ/////////////////////zLWBgABCwMPADLWBgABBAMAADLWBgECCwMP ADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLWBgMECwMPADLWBgMEBAMAADTWBgABDwMA AGH2AwAABgAAFiQBSWYBAAAAAAzKFQAA0xUAAOQVAADlFQAA5hUAAPkVAAALFgAAJRYAACYW AAAnFgAAPhYAAEcWAABYFgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABrBAEAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AGvMAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAAAAAAAAAAjgAAFiQBFyQBSWYBAAAAB5T/AAjWXAAE8f8BCT4RmhkaIwAj AAD/////////////////////ACMAAP////////////////////8AIwAA//////////////// /////wAjAAD/////////////////////FPYDACMVNgEa1hD/////////////////////G9YQ /////////////////////xzWEP////////////////////8d1hD///////////////////// MtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYGAQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAA MtYGAwQLAw8AMtYGAwQEAwAANNYGAAEPAwAAYfYDAAAGAAAWJAFJZgEAAAAADFgWAABZFgAA WhYAAFwWAABdFgAAXhYAAF8WAABgFgAAYRYAAGIWAABjFgAAZBYAAHQWAABxGAAAAAAAAAAA AAAAawAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAA AHEUAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABr AAAAAAAAAAAAAAAAcfwAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEA AACOAAAWJAEXJAFJZgEAAAAHlP8ACNZcAATx/wEJPhGaGRojACMAAP////////////////// //8AIwAA/////////////////////wAjAAD/////////////////////ACMAAP////////// //////////8U9gMAIxU2ARrWEP////////////////////8b1hD///////////////////// HNYQ/////////////////////x3WEP////////////////////8y1gYAAQsDDwAy1gYAAQQD AAAy1gYBAgsDDwAy1gYBAgQDAAAy1gYCAwsDDwAy1gYCAwQDAAAy1gYDBAsDDwAy1gYDBAQD AAA01gYAAQ8DAABh9gMAAAAMdBYAAIAWAACJFgAAohYAAKMWAACkFgAAshYAAMQWAADTFgAA 1BYAANUWAADWFgAA1xYAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AGvEAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAAaxQAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAAAAAAAAAI4AABYkARckAUlmAQAAAAeU/wAI1lwABPH/AQk+EZoZGiMAIwAA /////////////////////wAjAAD/////////////////////ACMAAP////////////////// //8AIwAA/////////////////////xT2AwAjFTYBGtYQ/////////////////////xvWEP// //////////////////8c1hD/////////////////////HdYQ/////////////////////zLW BgABCwMPADLWBgABBAMAADLWBgECCwMPADLWBgECBAMAADLWBgIDCwMPADLWBgIDBAMAADLW BgMECwMPADLWBgMEBAMAADTWBgABDwMAAGH2AwAABgAAFiQBSWYBAAAAAAzXFgAA2BYAANkW AADaFgAA5hYAAOcWAAD0FgAA9RYAAP4WAAD/FgAACBcAAAkXAAAKFwAA+QAAAAAAAAAAAAAA AGsAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABp AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA AAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAQAAjgAAFiQBFyQBSWYB AAAAB5T/AAjWXAAE8f8BCT4RmhkaIwAjAAD/////////////////////ACMAAP////////// //////////8AIwAA/////////////////////wAjAAD/////////////////////FPYDACMV NgEa1hD/////////////////////G9YQ/////////////////////xzWEP////////////// //////8d1hD/////////////////////MtYGAAELAw8AMtYGAAEEAwAAMtYGAQILAw8AMtYG AQIEAwAAMtYGAgMLAw8AMtYGAgMEAwAAMtYGAwQLAw8AMtYGAwQEAwAANNYGAAEPAwAAYfYD AAAGAAAWJAFJZgEAAAAADAoXAAALFwAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABIAAxkGgBH7DQLyCw 4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAUAA8ACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8A cgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAA AAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA RgBvAG4AdAAAAAAAAAAAAAAAAAAAAAAADQAAABsAAAAlAAAALwAAAAsTAAABAAAAAAAAAAAA /////wUEAAAAAAAAAQAAAAAAAAAAAP////8EBAAAAAAAAAEAAAAAAAAAAAD/////AwQAAAAA AAABAAAAAAAAAAAA/////wIEAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAA GwAAACUAAAAvAAAAMgAAAAAAAAAACAEAAAAACAIAAAAACAMAAAAACP//AAAAAAAAAAALEwAA BQAAggAAAAD/////AAAAANUAAADWAAAAzgEAAM8BAABNAgAATgIAAE8CAABSAgAAUwIAAFQC AABWAgAAVwIAAFkCAABeAgAAYAIAAGECAABiAgAAYwIAAGQCAABlAgAAJgMAACcDAADyAwAA 8wMAANsEAADcBAAAAgUAAAMFAAA7BQAAXAUAAJoFAACxBQAAsgUAANgFAADZBQAAJAYAAHEG AAB+BgAAiAYAAMUGAAAHBwAASwcAAEwHAABuBwAAbwcAAHwHAACKBwAApAcAAMQHAADqBwAA 6wcAAPwHAAACCAAADQgAABQIAAAcCAAAHQgAAB4IAAAfCAAAIAgAACEIAAAiCAAAIwgAAD4I AABJCAAAWQgAAHMIAAB0CAAAdQgAAHYIAACFCAAAoAgAAKkIAACqCAAAqwgAAKwIAACuCAAA yQgAAMoIAADLCAAAzAgAAM0IAADOCAAAzwgAANAIAADRCAAA0ggAAOIIAADtCAAA/QgAABcJ AAAYCQAAGQkAABoJAAApCQAARAkAAE0JAABoCQAAaQkAAGoJAACBCQAAmQkAAKcJAACoCQAA qQkAAKoJAADBCQAA2QkAAOcJAADoCQAA6QkAAOoJAAD7CQAACwoAABkKAAAaCgAAGwoAABwK AAAdCgAAHgoAAB8KAAAgCgAAIQoAADkKAABECgAAVAoAAG4KAABvCgAAcAoAAHEKAACACgAA mAoAAKEKAACiCgAAowoAAKQKAACwCgAAxwoAANcKAADYCgAA2QoAANoKAADjCgAA/goAAAwL AAANCwAADgsAAA8LAAARCwAAKQsAACoLAAArCwAALAsAAC0LAAAuCwAALwsAADALAAAxCwAA MgsAADMLAAA0CwAANQsAADYLAAA3CwAAOAsAAE8LAABaCwAAagsAAIQLAACFCwAAhgsAAIcL AACWCwAArQsAALYLAAC3CwAAuAsAALkLAAC7CwAA0gsAANMLAADUCwAA1QsAANYLAADXCwAA 2AsAANkLAADaCwAA2wsAALQMAAC1DAAA4gwAAOMMAAAkDQAAXg0AAKANAADcDQAA3Q0AABAO AAARDgAAVg4AAGYOAACDDgAAoA4AAL4OAADcDgAACg8AAAsPAAAMDwAAJg8AACgPAABKDwAA Ww8AAHcPAACIDwAAqg8AAKsPAACsDwAArQ8AAK4PAACvDwAAsA8AALEPAACyDwAAsw8AAM0P AADODwAAzw8AANAPAADRDwAA0g8AANMPAADUDwAA1Q8AANYPAADfDwAA7A8AAP4PAAANEAAA DhAAAA8QAAAREAAAGhAAABsQAAAcEAAAHRAAAB4QAAAfEAAAIBAAACEQAAAiEAAAIxAAACQQ AAAlEAAAJhAAADgQAABKEAAAXBAAAGwQAABtEAAAbhAAAIAQAACSEAAAohAAAKMQAACkEAAA uRAAAMoQAADLEAAAzBAAAM0QAADfEAAA8BAAAPEQAADyEAAA8xAAAPUQAAD2EAAA9xAAAPgQ AAD5EAAA+hAAAPsQAAD8EAAA/RAAAA8RAAAbEQAAKxEAACwRAAAtEQAALhEAAEERAABTEQAA bREAAG4RAABvEQAAhhEAAI8RAACgEQAAoREAAKIRAACkEQAApREAAKYRAACnEQAAqBEAAKkR AACqEQAAqxEAAKwRAAC+EQAAyhEAANMRAADkEQAA5REAAOYRAAD5EQAACxIAACUSAAAmEgAA JxIAAD4SAABHEgAAWBIAAFkSAABaEgAAXBIAAF0SAABeEgAAXxIAAGASAABhEgAAYhIAAGMS AABkEgAAdBIAAIASAACJEgAAohIAAKMSAACkEgAAshIAAMQSAADTEgAA1BIAANUSAADWEgAA 1xIAANgSAADZEgAA2hIAAOYSAADnEgAA9BIAAPUSAAD+EgAA/xIAAAgTAAAJEwAADBMAAJpA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAASAAMAAAAAAAAACAAAAAgJhAASAAMAEAAAAAAACAAAAAgJhA ASAAMAIAAAAAAACAAAAAgJhAASAAMAMAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAiAAMAAAAAAAAACAAAAAgJhA AiAAMAEAAAAAAACAAAAAgJhAAiAAMAIAAAAAAACAAAAAgJhAAiAAMAMAAAAAAACAAAAAgJhA AiAAMAQAAAAAAACAAAAAgJhAAiAAMAUAAAAAAACAAAAAgJhAAiAAMAYAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AyAAMAAAAAAAAACAAAAAgJhAAyAAMAEAAAAAAACAAAAAgJhAAyAAMAIAAAAAAACAAAAAgJhA AyAAMAMAAAAAAACAAAAAgJhAAyAAMAQAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhABCAAMAAAAAAAAACAAAAAgJhABCAAMAEAAAAAAACAAAAAgJhA BCAAMAIAAAAAAACAAAAAgJhABCAAMAMAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhABSAAMAAAAAAAAACAAAAAgJhA BSAAMAEAAAAAAACAAAAAgJhABSAAMAIAAAAAAACAAAAAgJhABSAAMAMAAAAAAACAAAAAgJhA BSAAMAQAAAAAAACAAAAAgJhABSAAMAUAAAAAAACAAAAAgJhABSAAMAYAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhABiAAMAAAAAAAAACAAAAAgJhABiAAMAEAAAAAAACAAAAAgJhA BiAAMAIAAAAAAACAAAAAgJhABiAAMAMAAAAAAACAAAAAgJhABiAAMAQAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlA AAAAMAAAAAAAAACAAAAAgJlAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJpA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJpAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJpAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJpA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgAoAAAAAMAAAAAAAAAAAAAAAAAAE AACpDQAADBMAAIYVAAALFwAAFAAAACEAAAAwAAAAOgAAAAAEAAADCQAADQwAACAMAABZDAAA oAwAAMkMAADPDAAA/QwAAEQNAACZDQAA2Q0AAAsOAAAeDgAAVA4AAJgOAADHDgAA/g4AACkP AAAvDwAANQ8AAGoPAACtDwAA0g8AANgPAABbEwAAshMAANATAAAPFAAAJBQAAGwUAACiFAAA 8xQAACsVAAChFQAAyhUAAFgWAAB0FgAA1xYAAAoXAAALFwAAFQAAABcAAAAYAAAAGQAAABoA AAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcA AAA4AAAAOQAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAAAEAAAKFwAAFgAAAA8AAPA4AAAA AAAG8BgAAAAQBAAAAgAAAA8AAAABAAAAAQAAABAAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8PgEAAAQAAjwCAAAAA8AAAAPBAAADwAD8JYEAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAAKIMCvAIAAAAAgQAAAAKAAAT AAvwBgAAAIAAAAAEAAAAEPAEAAAABwAAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAEAA8ABPBC AAAAogwK8AgAAAADBAAAAAoAABMAC/AGAAAAgAAAAAMAAAAQ8AQAAAAGAAAAAAAR8AQAAAAB AAAAAAAN8AQAAAAAAAMADwAE8EIAAACiDArwCAAAAAQEAAAACgAAEwAL8AYAAACAAAAAAgAA ABDwBAAAAAUAAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAAgAPAATwQgAAAKIMCvAIAAAABQQA AAAKAAATAAvwBgAAAIAAAAABAAAAEPAEAAAABAAAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAB AA8ABPBIAAAAQgEK8AgAAAAGBAAAAAoAAEMAC/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQ ABAAAAAQ8AQAAAANAAAAAAAR8AQAAAABAAAADwAE8E4AAABCAQrwCAAAAAcEAAAACgAAUwAL 8B4AAABEAQQAAAB/AQAAAQC/AQAAEADAAQAAgAD/ARgAGAAAABDwBAAAAAwAAAAAABHwBAAA AAEAAAAPAATwSAAAAEIBCvAIAAAACAQAAAAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQ AP8BEAAQAAAAEPAEAAAACwAAAAAAEfAEAAAAAQAAAA8ABPBIAAAAQgEK8AgAAAAJBAAAAAoA AEMAC/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAAAAAQ8AQAAAAKAAAAAAAR8AQAAAAB AAAADwAE8EgAAABCAQrwCAAAAAoEAAAACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ ARAAEAAAABDwBAAAAAkAAAAAABHwBAAAAAEAAAAPAATwVAAAAEIBCvAIAAAACwQAAAAKAABj AAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQANABAQAAANEBAQAAAP8BGAAYAAAAEPAEAAAAAgAA AAAAEfAEAAAAAQAAAA8ABPBUAAAAQgEK8AgAAAAMBAAAAAoAAGMAC/AkAAAARAEEAAAAfwEA AAEAvwEAABAA0AEBAAAA0QEBAAAA/wEYABgAAAAQ8AQAAAAIAAAAAAAR8AQAAAABAAAADwAE 8FQAAABCAQrwCAAAAA0EAACACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADQAQEAAADR AQEAAAD/ARgAGAAAABDwBAAAAAMAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAIAAAADgQA AAAKAAAzAAvwEgAAAL8BAAAQAM4BBgAAAP8BCAAIAAAAEPAEAAAAAQAAAAAAEfAEAAAAAQAA AA8ABPBCAAAAEgAK8AgAAAAPBAAAAAoAADMAC/ASAAAAvwEAABAAzgEGAAAA/wEIAAgAAAAQ 8AQAAAAAAAAAAAAR8AQAAAABAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/ AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAABPAgAAUAIAAFQCAABX AgAAWQIAAFoCAABbAgAAXAIAAF4CAAAMDwAADQ8AAA4PAAAPDwAAJg8AAAsTAAAPBAAAzBUA ALQAAAB0IgAAQAsAAHQAAAAAAA4EAADI+///AAAAALwHAACMCgAAdAAAAAAACwQAALQAAADS AAAA0AIAAKIDAAB0AAAAAAANBAAABBoAAG4AAACIHQAA1gEAAHQAAAAAAAUEAAB8/P///vz/ /7QAAADO////dAAAAAAABAQAAIgdAACy/f//wCEAAIIAAAB0AAAAAAADBAAAgBYAAIIAAAAE GgAAUgMAAHQAAAAAAAIEAAAcAgAAggAAAKAFAABSAwAAdAAAAAAADAQAAKAFAAC+AAAAgBYA AL4AAAB0AAAAAAAKBAAAtAAAAPwAAAAcAgAAGAMAAHQAAAAAAAkEAAC0AAAA/AAAANACAABk AgAAdAAAAAAACAQAALQAAAD8AAAAHAIAABgDAAB0AAAAAAAHBAAAtAAAAPwAAADQAgAAZAIA AHQAAAAAAAYEAAC0AAAAnAAAABwCAAAEAgAAdAAAAAAAAAAAAEQCAABLAgAAYwUAAGwFAADd BQAA4AUAACgGAAAxBgAAjwYAAJkGAADMBgAA1gYAAA4HAAASBwAAhQcAAIkHAACWBwAAmQcA AEIIAABFCAAAZQgAAGgIAAB6CAAAfQgAAOYIAADpCAAACQkAAAwJAAAeCQAAIQkAAHEJAACA CQAAiAkAAJEJAACiCQAApgkAALEJAADACQAAyAkAANEJAADiCQAA5gkAAPEJAAD1CQAAFAoA ABgKAAAoCgAAMQoAAD0KAABACgAAYAoAAGMKAAB1CgAAeAoAAIcKAACQCgAAGAsAACELAABT CwAAVgsAAHYLAAB5CwAAiwsAAI4LAABsDQAAbw0AAK4NAACxDQAAcg4AAIIOAACPDgAAnw4A AMoOAADPDgAA5A4AAOgOAAD0DgAA+A4AAFYPAABZDwAA+g8AAP0PAAA0EAAANxAAAGgQAABr EAAAehAAAH8QAACOEAAAkRAAAJ4QAAChEAAArBAAALAQAADVEAAA2RAAACIRAAAqEQAAOhEA AD4RAABPEQAAUhEAAFMRAABXEQAAexEAAH8RAAC6EQAAvREAAPIRAAD2EQAABxIAAAoSAAAL EgAADxIAADMSAAA3EgAAaxIAAHMSAADAEgAAwxIAANoSAAAJEwAADBMAAAcABAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcABwADAAAAAAC+AwAAyAMAAAMFAAALBQAAOwUAAEEFAABcBQAAYgUA AJoFAACiBQAAjwYAAJ8GAADMBgAA3AYAAEkIAABPCAAA0ggAANgIAADtCAAA8wgAAGoJAABw CQAAgQkAAIcJAACqCQAAsAkAAMEJAADHCQAA6gkAAPAJAAD7CQAAAQoAACEKAAAnCgAARAoA AEoKAACACgAAhgoAALAKAAC4CgAAEQsAABcLAAA4CwAAQAsAAFoLAABgCwAAlgsAAJ4LAAC7 CwAAwwsAAOMMAADrDAAAJQ0AACsNAABeDQAAZA0AAKANAACmDQAAEQ4AABkOAABWDgAAXQ4A AGYOAABtDgAAgw4AAIoOAACgDgAApw4AAL4OAADFDgAA3A4AAOMOAAAoDwAAMA8AAEoPAABR DwAAWw8AAF8PAAB3DwAAgA8AAIgPAACODwAA1g8AAN4PAADfDwAA5w8AAOwPAADyDwAA/g8A AAMQAAAREAAAGRAAACYQAAAsEAAAOBAAAD8QAABKEAAAUBAAAFwQAABjEAAAbhAAAHUQAACA EAAAhhAAAJIQAACZEAAApBAAAKsQAAC5EAAAvxAAAM0QAADUEAAA3xAAAOUQAAD9EAAAAxEA AA8RAAAWEQAAGxEAACERAAAuEQAANREAAEERAABHEQAAUxEAAFcRAABvEQAAdhEAAIYRAACO EQAAjxEAAJgRAACsEQAAshEAAL4RAADFEQAAyhEAANIRAADTEQAA3BEAAOYRAADtEQAA+REA AP8RAAALEgAADxIAACcSAAAuEgAAPhIAAEYSAABHEgAAUBIAAGQSAABqEgAAdRIAAHcSAACA EgAAiBIAAKUSAACpEgAAshIAALgSAADEEgAAyRIAANoSAAAJEwAADBMAAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAcAAwAA AAAAUQIAAFICAABSAgAAUwIAAFMCAABUAgAAVQIAAFYCAABWAgAAVwIAAFgCAABZAgAAWQIA AF4CAABfAgAAcAYAAIcGAADDBwAA6QcAAOsHAADVCwAA2AsAANgLAADbCwAAswwAAD8NAAA/ DQAAWA0AAF0NAABtDQAAbw0AAHgNAAB5DQAAew0AAJENAACaDQAA2w0AAOQOAADoDgAA6Q4A AOoOAADuDgAA/g4AAAkPAACrDwAArA8AANkSAADaEgAABxMAAAwTAAAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA//8OAAAADwBKAG8AaABuACAAVgBv AGwAbABiAHIAZQBjAGgAdABgAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABT AGUAdAB0AGkAbgBnAHMAXABqAHIAdgBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0 AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBl AHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBuAHQAMQAuAGEAcwBkAA8ASgBv AGgAbgAgAFYAbwBsAGwAYgByAGUAYwBoAHQAJABDADoAXABqAG8AaABuAGYAaQBsAGUAcwBc AGkAZQB0AGYAXABFAEEAUABcAEUAQQBQAC4AcwB0AGEAdABlAHMALgBkAG8AYwAPAEoAbwBo AG4AIABWAG8AbABsAGIAcgBlAGMAaAB0AF0AQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABh AG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAcgB2AFwAQQBwAHAAbABpAGMAYQB0AGkAbwBu ACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBl AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEUAQQBQAC4AcwB0AGEAdABlAHMADwBK AG8AaABuACAAVgBvAGwAbABiAHIAZQBjAGgAdABdAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABz ACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABqAHIAdgBcAEEAcABwAGwAaQBjAGEAdABp AG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABFAEEAUAAuAHMAdABhAHQAZQBz AA8ASgBvAGgAbgAgAFYAbwBsAGwAYgByAGUAYwBoAHQAXQBDADoAXABEAG8AYwB1AG0AZQBu AHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAagByAHYAXABBAHAAcABsAGkAYwBh AHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1 AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARQBBAFAALgBzAHQAYQB0 AGUAcwAPAEoAbwBoAG4AIABWAG8AbABsAGIAcgBlAGMAaAB0AF0AQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAcgB2AFwAQQBwAHAAbABp AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEUAQQBQAC4AcwB0 AGEAdABlAHMADwBKAG8AaABuACAAVgBvAGwAbABiAHIAZQBjAGgAdAAkAEMAOgBcAGoAbwBo AG4AZgBpAGwAZQBzAFwAaQBlAHQAZgBcAEUAQQBQAFwARQBBAFAALgBzAHQAYQB0AGUAcwAu AGQAbwBjAAYAejWGCObW6gH/D/8P/w//D/8P/w//D/8P/w8QAJhUDS8OnHZq/w//D/8P/w// D/8P/w//D/8PEABOIQ03jt0gGP8P/w//D/8P/w//D/8P/w//DxAAMlowOHJZrB//D/8P/w// D/8P/w//D/8P/w8QAHBVU16yyYho/w//D/8P/w//D/8P/w//D/8PEABKeYZ1Kqwmwv8P/w// D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYF AAHQAgZehNACYISY/m8oAAIAAAAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAF EYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAA AAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAA AoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4A AQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8o AAIAAAAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSg BWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAI Bl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYF AAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY /hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Tg EBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgA AA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAA AAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAAuAAEAAAAEgAEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAA AoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4A AQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIA AwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCE mP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E 4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGw EwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXG BQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGE TP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E 0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAA AAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAA AACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAu AAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4C AAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlg hEz/AgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZe hNACYISY/m8oAAIAAAAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXG BQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGE TP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E QAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAY AAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAA AAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAAu AAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4C AAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhg hEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZe hEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQAB EA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TgEBGETP8V xgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMR hJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP hIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4ABgAAADJaMDgAAAAAAAAAAAAAAABK eYZ1AAAAAAAAAAAAAAAAmFQNLwAAAAAAAAAAAAAAAE4hDTcAAAAAAAAAAAAAAAB6NYYIAAAA AAAAAAAAAAAAcFVTXgAAAAAAAAAAAAAAAP//////////////////////////////////BgAA AAAAAAAAAAAAAAAAAP//BgAAABIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQb AAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZAAkEGwAJ BA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJ BBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAAAAADrBwAA/AcAAAIIAAANCAAAFAgA ABwIAAAdCAAAHggAAB8IAAAgCAAAIQgAACIIAAAjCAAAPggAAEkIAABZCAAAcwgAAHQIAAB1 CAAAdggAAIUIAACgCAAAqQgAAKoIAACrCAAArAgAAK4IAADJCAAAyggAAMsIAADMCAAAzQgA AM4IAADPCAAA0AgAANEIAADSCAAA4ggAAO0IAAD9CAAAFwkAABgJAAAZCQAAGgkAACkJAABE CQAATQkAAGgJAABpCQAAagkAAIEJAACZCQAApwkAAKgJAACpCQAAqgkAAMEJAADZCQAA5wkA AOgJAADpCQAA6gkAAPsJAAALCgAAGQoAABoKAAAbCgAAHAoAAB0KAAAeCgAAHwoAACAKAAAh CgAAOQoAAEQKAABUCgAAbgoAAG8KAABwCgAAcQoAAIAKAACYCgAAoQoAAKIKAACjCgAApAoA ALAKAADHCgAA1woAANgKAADZCgAA2goAAOMKAAD+CgAADAsAAA0LAAAOCwAADwsAABELAAAp CwAAKgsAACsLAAAsCwAALQsAAC4LAAAvCwAAMAsAADELAAAyCwAAMwsAADQLAAA1CwAANgsA ADcLAAA4CwAATwsAAFoLAABqCwAAhAsAAIULAACGCwAAhwsAAJYLAACtCwAAtgsAALcLAAC4 CwAAuQsAALsLAADSCwAA0wsAANQLAADVCwAArg8AAK8PAACwDwAAsQ8AALIPAACzDwAAzQ8A AM4PAADPDwAA0A8AANEPAADSDwAA0w8AANQPAADVDwAA1g8AAN8PAADsDwAA/g8AAA0QAAAO EAAADxAAABEQAAAaEAAAGxAAABwQAAAdEAAAHhAAAB8QAAAgEAAAIRAAACIQAAAjEAAAJBAA ACUQAAAmEAAAOBAAAEoQAABcEAAAbBAAAG0QAABuEAAAgBAAAJIQAACiEAAAoxAAAKQQAAC5 EAAAyhAAAMsQAADMEAAAzRAAAN8QAADwEAAA8RAAAPIQAADzEAAA9RAAAPYQAAD3EAAA+BAA APkQAAD6EAAA+xAAAPwQAAD9EAAADxEAABsRAAArEQAALBEAAC0RAAAuEQAAQREAAFMRAABt EQAAbhEAAG8RAACGEQAAjxEAAKARAAChEQAAohEAAKQRAAClEQAAphEAAKcRAACoEQAAqREA AKoRAACrEQAArBEAAL4RAADKEQAA0xEAAOQRAADlEQAA5hEAAPkRAAALEgAAJRIAACYSAAAn EgAAPhIAAEcSAABYEgAAWRIAAFoSAABcEgAAXRIAAF4SAABfEgAAYBIAAGESAABiEgAAYxIA AGQSAAB0EgAAgBIAAIkSAACiEgAAoxIAAKQSAACyEgAAxBIAANMSAADUEgAA1RIAANYSAADX EgAA2BIAANkSAAAMEwAAAAAAAAgAAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEA AAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAAC AQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEA AI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAAC AQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEA AAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAAC AQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEA AI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAAC AQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEA AAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAACAQAAAgEAAI4BAAACAQAAAgEAAAIBAAAC AQAAAgEAAIYBAAAIAAAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAAC AQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAAC AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA AJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA AAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAlgEAAP9AAhAA AAAAAAAACxMAAFAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAA AAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQFAgME h3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwA AAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAA SSaQAYAAAgsGBAICAgICBP/////////pPwAAAAAAAAD/AD8AAAAAAEEAcgBpAGEAbAAgAFUA bgBpAGMAbwBkAGUAIABNAFMAAAAiAAQAcQiIGADw0AIAAGgBAAAAADO0akYjtWpGAAAAAAIA cwAAALoCAACLDwAAAQAHAAAABAADECEAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQMA8BAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQAtACBgTIw AAAAAAAAAAAAAAAAAAAWEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAMoNRAPAQAAgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAAAAAAAAAAAADwBKAG8AaABuACAA VgBvAGwAbABiAHIAZQBjAGgAdAAPAEoAbwBoAG4AIABWAG8AbABsAGIAcgBlAGMAaAB0AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAeAEAABEA AAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAEAAAAsAAAAAUAAADIAAAABgAAANQAAAAHAAAA 4AAAAAgAAAD0AAAACQAAAAwBAAASAAAAGAEAAAoAAAA0AQAADAAAAEABAAANAAAATAEAAA4A AABYAQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAAAOQEAAAeAAAAAQAAAAAAcwAeAAAA AQAAAAAAcwAeAAAAEAAAAEpvaG4gVm9sbGJyZWNodAAeAAAAAQAAAABvaG4eAAAAAQAAAABv aG4eAAAACwAAAE5vcm1hbC5kb3QAZR4AAAAQAAAASm9obiBWb2xsYnJlY2h0AB4AAAACAAAA MgBobh4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAHK4EBAAAABAAAAAABIWugx6 wgFAAAAAAFLzBCx6wgEDAAAAAQAAAAMAAAC6AgAAAwAAAIsPAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAPgAAAAMAAAAAQAAAGgA AAAPAAAAcAAAAAUAAACMAAAABgAAAJQAAAARAAAAnAAAABcAAACkAAAACwAAAKwAAAAQAAAA tAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwAAADZAAAAAgAAAOQEAAAeAAAAEwAAAElu dGVybGluayBOZXR3b3JrcwAAAwAAACEAAAADAAAABwAAAAMAAAAWEwAAAwAAADIRCQALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAG AAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAA BQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIA AAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAA IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0A AAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAA OwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAP7///9DAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAA VgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMA AABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAA/v///2wAAABtAAAAbgAAAG8AAABwAAAA cQAAAHIAAAD+////dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAP7////9////fQAAAP7/ ///+/////v///1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAANAoCRssesIBfwAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCAAAAmFAAAAAAAABXAG8A cgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAiggAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzAAAAABAAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAADQKAkbLHrCAdAoCRssesIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAA wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAA V29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --------------02FD777D9EE385857BF89D51-- From jose.p.puthenkulam@intel.com Thu Oct 24 05:38:36 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 23 Oct 2002 21:38:36 -0700 Subject: [eap] 10/23/02 Minutes of the EAP Design Team Message-ID: 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_01C27B17.378E1D80 Content-Type: text/plain Here is a white paper on some thoughts on making EAP exchanges secure. It is just a framework for thought. Thanks, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Wednesday, October 23, 2002 7:19 PM To: eap@frascone.com Subject: [eap] 10/23/02 Minutes of the EAP Design Team Short minutes from today. I didn't have time to write down all the discussion on John's paper, so feel free to add items. Jari ------- Date: Oct 23rd, 2002 Present: Bob Moskowitz, Nick Petroni, Jari Arkko, Yoshihiro Ohba, Glen Zorn, John Vollbrecht, Paul Congdon, Joseph Salowey 1. John's position paper. - Was submitted, but bounced the list. He started to do state tables which assumes the methods can also privide information to the EAP mux. Clearly needs more work, but he'd be happy to pursue it. - There's a couple of main things: - It would be possible to map this back to the states that are in the state machine now. Though it doesn't make any distinction about methods, even identity is seen as a method. - Assumes policing. Some of the actions assume that policies will dictate certain things. - Starts to imply things about the API. - Bernard: This is fairly complete. - Bernard: There are two cases when you receive method X request. One, we are done and should change state. Two, we need further requests. In addition, there are error situations. - Bernard: If within a method, you receive another method, is this NAKked or silently discarded. - DECISION: NAK is better than silent discard. - Question: Is a failure of a method terminal? We could either terminate EAP, or allow continuation with another method per policy? - John thinks we should allow the latter. - Jari thinks we should not. - Question: is the treatment of final success or fail dependent on whether the previous method failed or succeeded? - Proposal: We need a new state for this. - Question: is there a global state, what has happened on all methods, useful maybe for reauthentication? How can reauthentication - Answer: Good question. - Jari: Why is not authenticated vs. nocurrent methods there? - Jari: Reformulated question: is Success / Fail illegal at the beginning? - Bernard: Maybe this is policy? - Jari: If we can avoid policy, we should. 2. Moving Forward o Drafts: - Bernard: I encourage John to write up this state machine with this draft. - Jari: Should we have an individual draft by John, or merge drafts to WG draft status. - DECISION: Too early now. - Bernard: It would be better if Brian and Nick could do another revision of their draft as well. - DECISION: Priorities are: 1) follow decisions 2) be complete 3) follow 802 format. - Jari: Need to capture current decisions. Bernard: We are tracking the issues. - Bernard: One of the open issues is described above - Yoshihiro: We also need to consider the passthrough state machine. - Jari: That can also be done as a separate draft. - DECISION: By the I-D deadlines, we will have the following: - 2-3 state machines - rfc2248 updated to -07 - some solved issues - many unsolved issues - position papers and minutes will also be published o IETF-55 and where do we go from there - We will have a total of 4.5 hours and 2 slots. - On the first day, state machine is important and the issues are important - Second day is still unclear - What kind of method discussion we can have is under discussion. - John: Method discussion is key for EAP. - Bernard: We need to try to discuss issues in the methods, see if they are affected by state machine modifications etc. - Process for evaluating methods. Drafts solicited. Luca, Glen are writing something about this. - Glen: Cart is pushing the horse. Compatibility with 802.1x is not so important. Bernard: Tony Jeffrey views the 802 state machine as a way to suffle EAP packets around. The job of the IETF state machine is to decide what to do with the packets. Because the IETF state machine is link layer independent, it is at a higher abstraction layer. We will use similar format, but it is not the intention to force this state machine to comply with 802 state machine. o Continue with dt meetings after initial I-D deadline? - John: Not available next week. - Jari: We should continue. - DECISION: Meetings continue and next week we will go over the open issues. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------_=_NextPart_000_01C27B17.378E1D80 Content-Type: application/octet-stream; name="EAP-MACs.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EAP-MACs.ZIP" UEsDBBQAAAAIANOsVy0k2LI7XA4AAAByAAAMAAAARUFQLU1BQ3MuZG9j7V0LcFTVGf7vZjcPYMlC IaZI9QJRUCBseAnMVEITbKCCEVAUFHuze5O9sLt32XsXiDrTWMbn6Ehbp+roIFZrbasIlbFOp9TH 1Ok4haladVoHp2rVglMrBbS1Rrfff869m81m88RRhPtlvnve/39e9zx2z9m88KdRb9y/e9ybVIDz qYQ+y1ZQaZ6fAs50HSGi2Y7fZ9lslr1mgVkPXyn886fP0OL6Cj/R4dFP5VoWQMOvqSQaSS3rW9Zv fXfru9QDFf4qmlhN9OatiuCasp5x8pHNVvZrd3GTeF6rUM7Mt/dmjsmTsM3xry7v3RwBs6ZcpnPj /7mCqAn2RifeUM0VkOODuapCugdi1sA8fTjSImEiSHQL3FvgP5Z6wi23q68Q/eVvS0X3+IX1WSjX dd+GdFUw9znuQpPjTaSecgrdKwr07yvQN1AUymM551JPeR8V5MM1hwpXnqt/ntOfds37zoSqa57N SXf7WyvM2rx0Ltx8PwAzTLL/UV68/wSleYdTr667UI7bf7cVlK83sxCuXBduPNZzBfXsP/sK3L31 w0L01x9dM788jQGilzEiNebl/Yly2Q8Ly/2yM2X5SDnOFvbg4WTHUtPS1eaMHdOTGzJxLRFckrT1 uNpgplNmWrMNM6n+XJ0ZDs8MBhcvalaXLWpQWzRLj6qptGnrERFhmW7HzKjabFqGcDdrKT0dDDZk 0mk9acfbVU7J8c2IGVcTumVpbbqlamldTZq2KwkykQvkJqZt0lVL36SntTjMSCZt2O2qkUjFjYjI kVWrrooZlppiPaqVaYM021LT+ibDMpJtLKa7SttUtXjc3Jynys2FI2qzmYlH1RZdjZpJXW1pV1uN tGWr+paUloy6MiNmFBlLaRFdBteqweAq+LeaLJxjJfXNIpaFpytQbzWSXfUFGwpmcSlUsxUKDMvm lCJVbTA4R/2x2pyLukLfmEHZgnMLfK0U0uvB86bn+a7MRCIoVHBet7gXaEY8k9ZFRlG3ucqXBRZV jTbl/CZSGU6A8qKwmbwq6cp5a9pMqAkt2a6mTMsyWuK6qtm2FtmgWhE9qaUN0xLptbhlOumReJPB 1WanTRQzkbEzaFVNdDjbaU/kKhLTkoaVsLjqUWNaJo7aXcRimns0mSNZi2/W2rnVN2aMdH4u0071 WNPQvZLTiwSoZoutiVYxMzY3g8X1nES7dvUDw4po6agerZVt7ChHW6cTms2G01u7dec2Y5OeRHJ0 h2AwrPZEXRG/mUX8ZgXVMCLPVGeps9U56lz1PHWeOn8wfsGp04/zL3ityEoD93oBuJdEudlaDbx3 wt2FC/Vkmx3rVohrP6888Kizqj2lF+ocAIrkob8kBbg2OFidhehLAhdtyjJti1o3N6y2GLZ1TrFY n0ce+q3r/v5kHho1W1Nra2u75MkXhAsiBxH5Tss3KaqndAwIcNtOHJvbcXPMiMTUzUY8zu+aJsZN EeCMrvLtUjcYnLZVpNPibSYmglgCQ3bQ7RBd42zQKWcYox/GRz29SY+6fnXwa0KS6SubFtW5ntfX BhdryERCTl4yu1ZKjxit7WoMc4V8vfmtjuppvNcYcXjKSYsBA4FGumuCkemc4QwjRjCoFqymT1hg tTwVK+kZ4ALwcnANeM8w7DawE10L7sC25lFwJ7gL3A2+CR4FJ6GcNWAr2AFuBa8HbwZ/CN4J3gXu AB8AfwY+DO4GXwQPgofA98BpI4kawMvBSyrl5w+dxz449o/Ov3ce+MuL8m//8/ufe+a5/XthHnhs +2PbbztwQ+f3O/srZZ8orYqtm7oCu7exseil26kqdlDbTaSOjR1t+BCu5Zk/UsPSMXTR0hK6GFwH anB3xeBn0Rjj+giD1op5ZcLMRrcI82gwKcy/ae9KN9J25eqdCU8KX2HmfEUc+H7/SpSgcqzIbVVs xvTf0PnnKhVVsVuap7ItF8JPuEulbTK3/yjeMZfLfsBtvxZciF1YPXg7uA18CNwLvgQeBA+Bk9A3 asA1Tj+5G3wNHI9+sW6E7DdvjejqHw877fxpfuWf1I7/Hq/jaK+O3tN0y4EDfyW1RUXHETbRaXh3 PN79nK9YIg8nM/x+UhTFHXcXgI3gYvAJ8HnwdfAI2OmMx5eCq8HLnLH5f/niPsx3HM53/OvEcpxC 4DdcvO+Xn/GsYxNTW9cYMFKlum0x5cxdL8xQd73xzQm7yssmgpO27QjUgGft6k+FBw8ePHjw4MGD Bw8ePHjw4MGDhxMbYyhEo0mhe6mSSuD2C99Govp/Z30wR+RiltJyMilNCdIoTvJs43hqWFpNVzUp fg1moqnCn2wa5bdg2jB7amukRfVHsvez3NzZrCq4dGqF1Azk2qRSM+xpsE08UxSD3wXQnUQoYwUZ 9Uezj8PskjKCViFuCyToiN09p+PptI9QttmvlpIyrCQuLQH4aOzto+GIM4U21B/LPgOTcjLLhByV LiSDLKHblyvHmu8qdMSpH/FJGg1DvuPQaCCfKnKj0xYnTSVquehXQACfmR1FVM3Hbvk8LvvBLU4w TuVwcC24ELmqB29X5Em3h8C94EvgQfAQOAmlqQHXgGvBu8HXwPFoiXXgDvAtsCZA1Ao+DL4HTisl WsCn68DF4BPg8+Dr4BGwE7wE+bwUXA1eBl4B3sWZDTtV0uHQcRcNIy/sZAmrPIXDvuh6GVQb3TXE sFQfYUOVOdQwOr4wRrExr3C84zFs5wIl7MpRHN5Rdg+pN9xc9kiRMIkOpa+wnVf3GlbWZ1ieTF9B 2EMI8/eSblT9TzrKwjxvPNjBVzBG5cJI5LPUSVcgUylWdgbKX+Z+L1zOHqXye3t28+Hs4Y4fu4c5 aUogvAysxnwzoUTWbRlm3jLyk7wWcj9CfwFOQ2vMB+sgYX6pG3NWHhnuvLbDaTsZK+CQ0V0Ta8lm uYQhWopZ2xLrgGasKWysH3TMyRvE+kLDqkDWEASL0r3jlCAE8oEMPjDBx0H4QMXW+iuJD2XwAQ3+ 5mzyWY9T8zW/Jv4mvSLzJPExC/5ujY9S8KENXglk60s6FJqInDFf9kUD7yvvK2xnuKYv5KjlBUBI gfZ6vgjDTVBGl4jsJlGMzXiybzl1QcZik5tULhny7agt+nYVLxJ8vtKSgD/gK/HfuAC1kS/DaetV WK4kUD0W8aJJhz4VyypTLJ2SCJ8DOT4KBBSfUlbqC7gXfEJ5ojr4sZLakaYFKXnBNetsoX14qd/H 6FX7IizSDGeRtnCOSFNWUuHzBXx+/41XizQdbsndNA3QkRHpdDzdXBNdjPQdw1DiCr8vUF7if8pH Oz7p/EMs5KS/z1m8LUNeVTx5mRZB1zBZN3KwUEhbiL/rsBiNEF+28NPG8puq6fALSBoT+pv2rm9d B7J9tLiWUw3/b5XyyyOXzyWhYA/foJMHdNfDbn48DBblZTsCe2gPXXfdzNndQ1Y7C9PjgS9nU2Zt vZjbKf+d64km8TzncLZSIWUh0dt+cfnxe72Rh5JsdrSTeiCD1MDi9R/Dg4de8RmmDIzuPfx5tHvj +vuOfHxRLPTLH5TT1MmP/zVMcu85ygnfRvK14bUYD3N7SM6qT5OchA6QWCbQQSIxZx8jOeOWK3Id UaPwIIplnCLXERcq8gbdZYocMqMK3z/F0hQm3xDdosiZB9MrfQ3mTYrUz6/eGSTzVXifBVJEmBi9 ETaYePl2XvMs57P/8dqoadOG/uRwfdTNI5F2DLjMiKRNy2y11dVmOqrWhWvDPOMT/c7/AZdB2Jtf PTz6mmcVYV+1vYRvEZY4+WCTJxU2eWJxlhEePHjw4MGDBw8ePHjw4MHDgNDX/t/3yv5X7q09PfSj O7H/n/bxzjDJvfsIJzxGcl+eIrnfv5Xkfv8Oknvje8HTwAdJ7p8fIbl/588JeP/+W5K/4PJ7kvv9 fSRlH6Lu+3r+jKDHz1JQPPfRakke+WNANh8NDpPfUzi6i5lnhGQ5iu7jR4RkJjgDXKhVhh3Xyd2O e/DgwYMHDx48ePDgwYMHD18piH0+Ue7sP+/jebvL39fzd/X8PT1/N897Zt6b829983fyvO8Pkdw7 8/6c9/NjnHDe0/O+vxr8OjgOPJ34HL4M5y31maAKTiD5q7aTSP76MYefDXMy8Zl8onOo6yz8NCf8 U3CGY3fpYWjgw36muHWxWNyvSFM7DQZVFFBcWdyHSivkZ0lPy+AL8uPumHKF+GXkOuo6rttIGrRq NFQMI19OP6O/+AxxHC8k7XV590aGgpHQz+8QvzMD1S9+zTsk7avFTZUo6sGkCGXEYUz3nstAMA76 ucb5vR2ofgb/bjsjQCuF1oS4c9NOS6C9NXd7xiZD3LvpHVOGUP/f4EdI2gM9Sj64/MyDfh63BqP/ LH6EpF0RB0oTlKKL0AvW95GqOEaLY7eDKz9j8Jp6x1D0u+C+642fpy4UtH7JMNmHCsduHiIKzq01 mpFMQk/aYk2wbCX7wUu8TGyvdcNr59Gx+b/aWLTLeTiB8EXO/+Hz7TmnYf4/j8OdA4ze/P/lzv8n 4vp/KJiLtLwvyN8TzCHv/xH1B3f+H2j787sz8jjaycOJBT5bz22+R5Htz2MBv8dX0SKMSk1iVFqB MWmTuHC1GavldvjwaLmEfyVAjBsjRfzFYoVuIIxX8LyW1hHTdvpV0JEpL6jwmNcVn5x+V91HnEZx Bz8lrrS003JxsUV38rvLL8cf/i9W4h7C9E/28PhSS3x3Xhe/IXAlRps6CtMMmkmz8AzDdK+BsT55 Bc7EXkN1rtDwjLiImmE2ilCD2nI3++W1GtbBe5n1zgWcWuhhFruEUy80sZ444kTEnoMcGVzfxa/u TIO+/Os9nz9Oxf0f95mws/7w9n9f7vq/t/NH7FN4/ojHm0CBH98Z8s4kyTNJbytE7i3IesfzmHR2 dJJM6ldkXkY44/3/AVBLAQIUCxQAAAAIANOsVy0k2LI7XA4AAAByAAAMAAAAAAAAAAAAIAAAAAAA AABFQVAtTUFDcy5kb2NQSwUGAAAAAAEAAQA6AAAAhg4AAAAA ------_=_NextPart_000_01C27B17.378E1D80-- From aboba@internaut.com Thu Oct 24 13:07:36 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 24 Oct 2002 05:07:36 -0700 (PDT) Subject: [eap] RE: authentication/integrity protection of EAP frames In-Reply-To: Message-ID: Since everyone might not have Microsoft Word, in general it is better to post using text if possible. If that is not possible, a pointer to a file in Adobe PDF format is preferred. I'm told by our mailing list sponsor (David Frascone) that pointers to files are strongly preferred to sending files within the messages themselves, due to bandwidth constraints. With respect to the paper you've posted, I have some questions: a) Which of the problems on the EAP issues list is this a solution to? See: http://www.drizzle.com/~aboba/EAP/eapissues.html for a list of issues, or instructions for filing an issue. b) Wouldn't this require existing EAP methods to be rewritten to use the new Request/Response codes? c) How are the keys to be derived with which to calculate the MACs? d) What portions of the EAP header are considered mutable/immutable in calculating the MAC? From pascal.urien@louveciennes.sema.slb.com Fri Oct 25 11:10:37 2002 From: pascal.urien@louveciennes.sema.slb.com (pascal urien) Date: Fri, 25 Oct 2002 13:10:37 +0300 Subject: [eap] draft IETF - EAP support in smartcard version 00 Message-ID: <5.1.0.14.0.20021025131004.02da49f0@slv-smtp> --Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w) Content-type: multipart/alternative; boundary="Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)" --Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw) Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Dear Sirs Please find enclose for comment and review an internet draft named "eap support in smartcard" that has been posted to ietf server. http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt and that we will like to present during the next IETF meeting in= Atlanta. This draft has been issued by the two major manufacturers of smartcards=20 (Gemplus and Schlumberger, around 80% of world market). It is also consider as a reference document by the javacard forum WiFi=20 Task force (www.javacardforum.org) which comprises more than 20 companies. Best Regards. Pascal Urien. Schlumberger Smartcard Reseach Center. >>Date: Tue, 22 Oct 2002 04:48:11 -0700 (PDT) >>From: Bernard Aboba >>Subject: Re: EAP for smartcard >>To: Pascal Urien >>Cc: bernarda@microsoft.com, Jari.Arkko@ericsson.com,= waa@dsl.cis.upenn.edu, >> bertrand du Castel >>X-MIMETrack: Itemize by SMTP Server on SLV-SMTP/CP8(Release 5.0.7 |March= =20 >>21, 2001) at 10/22/2002 >> 14:47:51, >> Serialize by POP3 Server on SLV-SMTP/CP8(Release 5.0.7 |March=20 >> 21, 2001) at >> 10/22/2002 14:51:48, >> Serialize complete at 10/22/2002 14:51:48 >> >>I'd recommend posting a not to eap@frascone.com requesting review of your >>draft. > >-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- >Pascal Urien >SchlumbergerSema >Smartcard Research Center >36-38 rue de la Princesse >BP45 78431 Louveciennes Cedex. >T=E9l : 33 1 30 08 48 69 >Fax : 33 1 30 08 45 24 >-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- --Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable  Dear Sirs

   Please find enclose for comment and review an internet draft named
     "eap support in smartcard"
 
   that has been posted to ietf server.

   http://www.ietf.org/internet-drafts/draft-urien-eap= -smartcard-00.txt

   and that we will like to present during the next IETF meeting in Atlanta.

This draft has been issued by the two major manufacturers of smartcards (Gemplus and
 Schlumberger, around 80% of world market).

 It is also consider as a reference document by the javacard forum WiFi Task force
 (www.java= cardforum.org) which comprises more than 20 companies.

Best Regards.

Pascal Urien.
Schlumberger Smartcard Reseach Center.



Date: Tue, 22 Oct 2002 04:48:11 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: EAP for smartcard
To: Pascal Urien <Pascal.Urien@louveciennes.sema.slb.com>
Cc: bernarda@microsoft.com, Jari.Arkko@ericsson.com, waa@dsl.cis.upenn.edu,
 bertrand du Castel <ducastel@slb.com>
X-MIMETrack: Itemize by SMTP Server on SLV-SMTP/CP8(Release 5.0.7 |March 21, 2001) at 10/22/2002
 14:47:51,
        Serialize by POP3 Server on SLV-SMTP/CP8(Release 5.0.7 |March 21, 2001) at
 10/22/2002 14:51:48,
        Serialize complete at 10/22/2002 14:51:48

I'd recommend posting a not to eap@frascone.com requesting review of your
draft.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-= *-*-*-*-*-*-
Pascal Urien
SchlumbergerSema
Smartcard Research Center
36-38 rue de la Princesse
BP45 78431 Louveciennes Cedex.
T=E9l :  33 1 30 08 48 69
Fax : 33 1 30 08 45 24
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-= *-*-*-*-*-*-*-*-*-*-*-*-*-*-
--Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)-- --Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w) Content-type: text/plain; name=draft-urien-eap-smartcard-00.txt; x-mac-type=42494E41; x-mac-creator=74747874 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-urien-eap-smartcard-00.txt Internet Draft Document: draft-urien-EAP-smartcard-00.txt P.Urien A.J. Farrugia G.Pujolle M.Groot Expires: April 2002 October 2002 EAP support in smartcards Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document will describe the interface to the EAP protocol in smartcards, which could store multiple identities associated to Network Access Identifiers. Urien & All Informational - Expires April 2002 1 EAP support in smartcards October 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 Overview...........................................................3 Terms..............................................................3 Identification label...............................................3 Get-Next-Identity..................................................4 Set-Identity.......................................................4 EAP-Packets........................................................5 Get-PairwiseMasterKey (PMK)........................................5 ISO 7816-4 APDUs...................................................5 Get-Next-Identity APDU..........................................5 Set-Identity....................................................5 EAP-Packets.....................................................6 Get-PairwiseMasterKey...........................................6 Security Considerations............................................6 Annex 1 EAP/SIM detailed specification.............................7 Annex 2 EAP/MD5 detailed specification............................11 References........................................................13 Urien & All Informational - Expires April 2002 2 EAP support in smartcards October 2002 Overview 802.11a, 802.11b, 802.11g security requirements. Relation with 802.1x. Extensible Authentication Protocol benefits. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. AS Authentication Server EAP Extensible Authentication Protocol. GSM Global System for Mobile communications. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. NAI Network Access Identifier PMK Pairwise Master KEy SIM Subscriber Identity Mobile Identification label. 802.1X specification [5] requires an authentication between the authenticator or the authentication server (AS) and the supplicant. The authentication is embedded in the Extensible Authentication Protocol (EAP) RFC2284 [1] specification. The authentication consists of a challenge response between both parties without consideration of the involved crypto-suite. Before starting the mutual authentication, the AS needs the supplicant identity to establish the session. The AS or the authenticator sends an EAP Request Identity to the supplicant that returns its system identity. A user may have several types of identities likely associated to the network operators. Urien & All Informational - Expires April 2002 3 EAP support in smartcards October 2002 The identification label may be of types: 1) The network SSID as described in the 802.11 standard [4]. 2) The NAI [6], the network realms and a server name, for example unique value 1IMSI@realm for SIM based authentication [internet draft]; 3) A user's identification (UID) e.g. an ASCII string, for example a friendly name. According to the identity selection the supplicant software needs to set the appropriate identity and verifies if the smart card is able to mirror the authenticator. If the smart card is not able to process the authentication related to the identity then any setting process is rejected by the failure code. The subsequent sections give the description of the methods used by a supplicant for processing an 802.1X authentication using the smart card. Annex one provides a reference implementation example for a SIM based authentication. Annex one provides a reference implementation example for a MD5 based authentication. Get-Next-Identity. The smart card may contain one or more user's identities according to the user's network subscriptions. The supplicant software should prompt the user's identity and a subsequent selection allows the smart card to process the appropriate EAP authentication type. The method Get-Next-Identity allows the supplicant software to read all available user's identities. The Get-Next-Identity method may inform the supplicant software when all user's identities have been read. If the smart card contains a pseudonym management and the pseudonym is (are) available the Get-Next-Identity returns the appropriate pseudonym. If the pseudonym management is not supported, the smart card returns the permanent Identity according to the previous section. Set-Identity. Once the Identity selection is processed, the supplicant software needs to set the smart card EAP framework according to the selected user's identity. The Set-Identity sets or restarts the smart card EAP framework state machine for further processing using the EAP-Packets method. The supplicant software can set the EAP framework using the pseudonym if available in the smart card. If the pseudonym is not available the supplicant software uses the permanent identity to set the EAP framework according to the previous section. Urien & All Informational - Expires April 2002 4 EAP support in smartcards October 2002 EAP-Packets. The EAP process is described in the RFC 2284 specification [1] and involves several EAP requests and responses packets as described in [2]. - EAP request/response Identity; - EAP request/response start; - EAP request/response challenge; and - EAP success or failure. The smart card receives the RFC 2284 frames. It retrieves the appropriate EAP authentication type in the frame and the identifier. The smart card maintains the EAP state machine and returns an EAP NAK packet if the state sequence is broken. Any EAP request is silently ignored if the state machine was not started. Get-PairwiseMasterKey (PMK) At the end of a successful authentication the supplicant needs to update the appropriate crypto suite using the master session key. The Get-PairewiseMasterKey returns to the supplicant software the key to initialize either TKIP, WRAP or CCMP protocol. ISO 7816-4 APDUs This section of the document provides an implementation of the previous descriptions for an ISO 78176-4 compatible smart card. It should be noted that all values are in hex representation Get-Next-Identity APDU. This command returns an identification label The identity coding rules are not defined in the section of the document yet. Further version of the document will defined these rules. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 01 | 00 | 00 | xx | +--------+-----+-----+----+----+----+----+ The restriction and security related descriptions are not present in the document. For EAP SIM authentication the userid, is the IMSI and the realm depends upon the operator. Set-Identity. The command resets and initializes the state machine for processing the EAP Packets. The first step after this command is an EAP request identity packet. If a different EAP packet is sent to the smart card the smart card return an EAP NAK response. Urien & All Informational - Expires April 2002 5 EAP support in smartcards October 2002 +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 80 | 00 | xx | 00 | +--------+-----+-----+----+----+----+----+ EAP-Packets. The command is the only entry point of the EAP authentication managed by the state machine. The state machines have to be respected and the smart card will verify the EAP sequence. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | xx | xx | +--------+-----+-----+----+----+----+----+ Get-PairwiseMasterKey Once the state machine has received the EAP Success packet the SIM process is able to send the Master Key used by the 802.1X specification for the crypto-suite. The EAP SIM authentication draft version 5 [2] specifies the Master Key computing. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | A6 | 00 | 00 | 00 | 16 | +--------+-----+-----+----+----+----+----+ Security Considerations As a reference implementation the previous section provides the details of the EAP authentication using the GSM SIM. This section of the document highlights the new potential risks providers of application may face by re-using deployed networks for other purposes. From the document _can you clone a GSM smart card (SIM)?_ [7] fatal flaw does exist when have physical access to the smart card. The nature of the Internet network does no longer require getting physical access to the smart card. Worms, Trojan horses or viruses can move to the computing platforms and performs the jobs. It is important for a reference implementation to provide the relevant level of protection for the new applications but not to create other flaws. Urien & All Informational - Expires April 2002 6 EAP support in smartcards October 2002 Annex 1 EAP/SIM detailed specification. Note protocol implementations are out of the scope of this document but as a reference implementation this section gives details using the SIM as specified by [3]. Other protocol can be implemented but when using ISO 7816-4 APDU this section of the document gives the syntax and coding. The first EAP packet is the EAP Request Identity. This initial packet format complies with the RFC 2284. The smart card returns an EAP response identity according to the IMSI length. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 05 | 18 | +--------+-----+-----+----+----+----+----+ Detail of the EAP/Request/identity according to the IETF RFC 2284 [1] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | +-+-+-+-+-+-+-+-+ Detail of the EAP/Response/identity according to the IETF RFC 2284 [1] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | | |-+-+-+-+-+-+-+-+ IMSI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this version of the specification does not support the pseudonym management as describe in the EAP SIM Authentication [2]. The second EAP Packet is the EAP request SIM start as represented in the IETF draft document [2]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 10 | 1B | +--------+-----+-----+----+----+----+----+ Urien & All Informational - Expires April 2002 7 EAP support in smartcards October 2002 Detail of the EAP/Request/SIM/Start according to [2] incoming SIM data Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM Authentication draft [2]. The AT_PERMANENT_IDENTITY_REQ and the AT_IDENTITY_REQ are both silently ignored for this version of the specification. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_PERM..._REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_ID..._REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/SIM/Start according to [2] outgoing SIM data. Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM authentication draft [2]. The AT_PERMANENT_IDENTITY_REQ, the AT_IDENTITY_REQ and their respective fields are not returned by the SIM yet. Further version of the specification will include this management according to [2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_NONCE_MT | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NONCE_MT | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires April 2002 8 EAP support in smartcards October 2002 The third EAP Packet is the EAP request SIM Challenge as represented in the IETF draft document [2]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 50 | 1B | +--------+-----+-----+----+----+----+----+ Detail of the EAP/Request/SIM/Challenge according to [2] incoming SIM data. The APDU coding Lc is proposed with 3 RAND numbers. Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM authentication draft [2]. The AT_IV and the AT_ENCR_DATA and their respective fields are not returned by the SIM yet and there are both silently ignored for this version of the specification. Further version of the specification will include this management according to [2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | n*RAND | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC RAND | Length = 6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/SIM/Challenge according to [2] outgoing SIM data. Further information can be retrieved from the IETF draft document [2]]. Note. According to EAP SIM authentication draft [2] this version of the specification does not support the pseudonym management. Urien & All Informational - Expires April 2002 9 EAP support in smartcards October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC_SRES | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_SRES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires April 2002 10 EAP support in smartcards October 2002 Annex 2 EAP/MD5 detailed specification. The first EAP packet is the EAP Request Identity. This initial packet format complies with the RFC 2284. The smart card returns an EAP response identity according to the NAI length. +--------+-----+-----+----+----+----+--------------+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+--------------+ | | A0 | 80 | 00 | 00 | 05 | 5+NAI.Length | +--------+-----+-----+----+----+----+--------------+ Detail of the EAP/Request/identity according to the IETF RFC 2284 [1]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request=1 | Identifier | Length= 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=01 | +-+-+-+-+-+-+-+-+ Detail of the EAP/Response/identity according to the IETF RFC 2284 [1] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response=2 | Identifier | Length= 5+NAI.Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ | Type=01 | | |-+-+-+-+-+-+-+-+ NAI.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second EAP Packet is the EAP request MD5 challenge as represented in the IETF RFC 2284. +--------+-----+-----+----+----+------- ------------+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+--------------------+----+ | | A0 | 80 | 00 | 00 | 5+Challenge.Length | 15 | +--------+-----+-----+----+----+--------------------+----+ Detail of the EAP/Request/challenge according to the IETF RFC 2284 [1]. Urien & All Informational - Expires April 2002 11 EAP support in smartcards October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request=01 | Identifier | Length 5+Challenge.Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=04 | | |-+-+-+-+-+-+-+-+ MD5-Challenge.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/challenge according to the IETF RFC 2284 [1] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response=02 | Identifier | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=04 | | |-+-+-+-+-+-+-+-+ MD5-Digest.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The third EAP Packet is the EAP success notification as represented in the IETF RFC 2284. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 04 | 00 | +--------+-----+-----+----+----+-- -+----+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Success=03 | Identifier | Length= 04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Further information can be retrieved from the IETF draft document [2]. Urien & All Informational - Expires April 2002 12 EAP support in smartcards October 2002 References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. (NORMATIVE) [2] EAP SIM Authentication draft version 5 (INFORMATIVE) [3] GSM Technical Specification GSM 11.11. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [5] Standards for Local and Metropolitan Area Networks: Standard for Port based Network Access Control. [6] "The Network Access Identifier" rfc 2486 [7] "Can you Clone a GSM Smart Card (SIM)?" From Charles Brookson Chairman GSM Association Security Group Author's Addresses Pascal Urien Schlumberger Sema 36-38 rue de la Princesse Phone: +33 1 30 08 48 69 BP45 78341 Louveciennes France Email: purien@slb.com Guy Pujolle LIP6 _ University Paris 6 8 rue Capitaine Scott Phone: Paris 75015 France Email: Guy.Pujolle@lip6.fr Augustin J. Farrugia Gemplus 3 Lagoon drive suite 300 Phone Redwood city Email: Augustin.farrugia@gemplus.com 94065 CA, USA Max de Groot Gemplus Avenue du Pic de Bertagne Phone :+33 4 42 36 50 36 BP 100, 13881 Gemenos Email :max.de-groot@gemplus.comk France Urien & All Informational - Expires April 2002 13 --Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT --Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w)-- From aboba@internaut.com Sat Oct 26 03:54:02 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 25 Oct 2002 19:54:02 -0700 (PDT) Subject: [eap] EAP.states.txt/ state strawman converted to txt Message-ID: ---------- Forwarded message ---------- Date: Fri, 25 Oct 2002 15:38:14 -0400 From: jrv@interlinknetworks.com To: EAP-Design Subject: [eap-design] EAP.states.txt/ state strawman converted to txt The following is a first pass at a state diagram that includes an EAP switch and multiple methods. It needs more work, and I am willing to fill it in more, but I am curious about whether this is seen as helpful. The policy in the switch seems the most interesting. Another thing that might be interesting is to talk about what can be passed between methods, and whether this should also go through the EAP switch or be left to local implementation methods. I think this sort of model could be helpful in understanding state transitions, and in defining requirements for EAP methods. Peer Auth Method Method \ / \ / Peer Auth EAP ----------------- EAP The model is that there are two EAP switches, one at the Peer and one at the authenticator. These each have the ability to support some internal policy, the details of which are not included. At both the peer and authenticator one or more EAP method exists. The EAP switches select which methods each is willing to use, and negotiate between themselves to pick a method or sequence of methods. The main thrust of this initial description is give an idea of how the state machines on each of the switches will work. Note that the methods may also have state machines, but the details of these are out of scope for this paper. The peer EAP has the following states 1. inactive/not authenticated - waiting for an EAP request 2. active/waiting-method=x - waiting for response from method 3. active/method=x - waiting for next EAP request 4. active/nocurrent method - waiting for request for next method 5. active/failed method - waiting for EAP Fail 6. inactive/authenticated - authenticated possible reauth required Events recognized by the peer EAP are 1. EAP-Req/ok - EAP request acceptable to peer policy 2. EAP-Req/notok - EAP request not acceptable to peer policy 3. EAP- Success 4. EAP- Fail 5. Method-resp.final .good - good termination from method 6. Method-resp.final .fail - failure termination from method 7. Method-resp-cont - continuing response from method Actions initiated by peer EAP are 1. Send EAP-NAK 2. Send EAP-Resp 3. Forward EAP-req to method 4. Send method terminate to method 5. Signal accept or reject to system State - peer EAP Event Next State Action Inactive/not auth EAP-Req/ok active/waiting-mth=x Forw req to method EAP-Req/not ok Inactive/not auth Send NAK EAP-Success/ok inactive/auth Signal - accept EAP-Success/not ok Inactive/not auth Signal-reject * Inactive/not auth silent discard active/wait-mth=x mth-rsp.final.good active/no mth Send EAP Resp mth-rsp.final.fail active/fail-mth Send EAP Resp mth-rsp-cont active/mth=x Send EAP Resp * active/wait-mth=x silent discard active/mth=x EAP-Req/mth=x active/waiting-mth=x Forw req to method EAP-Req/meth.ne.x Inactive/not auth Send NAK Send Term to mth=x * active/mth=x silent discard active/no mth EAP-Req/ok active/mth=x Forw req to method EAP-Req/not ok active/no mth Send NAK EAP-Success inactive/auth Signal - accept EAP-Fail Inactive/not auth Signal-reject * active/no mth silent discard active/fail-mth EAP-Fail Inactive/not auth Signal-reject EAP-Success Inactive/not auth Signal-reject EAP-Req active/fail-mth Send NAK * active/fail-mth silent discard inactive/auth EAP-Req/ok active/mth=x Forw req to method EAP-Req/not ok inactive/auth Send NAK * inactive/auth silent discard -------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------- -------------------------------- For authenticator the following states exist 1. inactive - waiting for start indication 2. active/method=x.1 - first message of method x sent 3. active/method=x.c - continuing message of method x sent 4. active/method=x.a - method x active on authenticator For authenticator the following events are defined 1. initiate EAP - external signal (e.g. from RADIUS) to start EAP 2. receive EAP-NAK 3. receive EAP-Resp.method.eq.x 4. receive EAP-Resp.method.ne.x 5. receive EAP-req.1 from method 6. receive EAP-req.c from method 7. receive meth-Success or meth-Fail from method The following actions 1. initiate method (with parameters) 2. forward EAP-Req 3. send EAP Success or Failure 4. terminate method 5. signal accept or reject to system State - authenticator EAP inactive initiate EAP active/mth=x.a start method x * inactive active/mth=x.a rcv EAP-req.1 active/mth=x.c forward EAP-req rcv Meth-Success active/no mth rcv Meth-Fail active/no mth * active/mth=x.1 rcv-NAK actv/nomth rcv-EAP-resp-x actv/mth=x.a forw response to method x rcv-EAP-resp-not-x inactive terminate method * active/mth=x.c receive-NAK inactive terminate method rcv-EAP-resp-x active/mth=x.c forw response to method x rcv-EAP-resp-not-x inactive terminate method * active/nomth (no policy) inactive Send EAP Success/Failure (more policy) active/mth=x.a start method x From gwz@cisco.com Mon Oct 28 06:38:33 2002 From: gwz@cisco.com (Glen Zorn) Date: Sun, 27 Oct 2002 22:38:33 -0800 Subject: [eap] Re: Language Negotiation Message-ID: Issue 38 says: "Currently there is no way to make sure that displayable messages (such as Notifications) are sent in a language that the user understands. Resolution: Discuss Some ideas on how this might be accomplished: a. Add language type to the first octets of the Notification Request AND allow a Notification Response to encode an alternate language. However, the Notification Response is of zero length, so there is a question of whether this would break existing implementations. b. Encode the proposed language type in the Identity Request, and allow the Identity Response to encode an alternate language." I find both the options above unsatifactory. For example, the Identity Request is for all intents optional, so overloading it with language/charset negotiation seems inappropriate, and breaking existing implementations by overloading the Notification Response doesn't seem right either. OTOH, this seems to be a case where it would be harmless (modulo appropriate defaults) for an implementation to ignore or NAK an unknown Type, so I would suggest that language/char set negotiation be done in a new type. This could be done via a preference-ordered set of TLVs sent by the client, w/the response containing a single TLV representing the server's choice. From gwz@cisco.com Mon Oct 28 08:01:13 2002 From: gwz@cisco.com (Glen Zorn) Date: Mon, 28 Oct 2002 00:01:13 -0800 Subject: [eap] Re: Language Negotiation In-Reply-To: Message-ID: Glen Zorn [mailto:gwz@cisco.com] writes: > Issue 38 says: > > "Currently there is no way to make sure that displayable messages > (such as Notifications) are sent in a language that the user understands. > > > Resolution: Discuss > Some ideas on how this might be accomplished: > > a. Add language type to the first octets of the Notification Request AND > allow a Notification Response to encode an alternate language. However, > the Notification Response is of zero length, so there is a question of > whether this would break existing implementations. > > b. Encode the proposed language type in the Identity Request, and allow > the Identity Response to encode an alternate language." > > I find both the options above unsatifactory. For example, the Identity > Request is for all intents optional, so overloading it with > language/charset > negotiation seems inappropriate, and breaking existing implementations by > overloading the Notification Response doesn't seem right either. > OTOH, this > seems to be a case where it would be harmless (modulo appropriate > defaults) > for an implementation to ignore or NAK an unknown Type, so I would suggest > that language/char set negotiation be done in a new type. This could be > done via a preference-ordered set of TLVs sent by the client, > w/the response > containing a single TLV representing the server's choice. Whoops, I think I've got that backwards: should be a set of options from the _server_, and a single client choice. > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From Internet-Drafts@ietf.org Mon Oct 28 11:27:30 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 28 Oct 2002 06:27:30 -0500 Subject: [eap] I-D ACTION:draft-ietf-eap-esteem-00.txt Message-ID: <200210281127.GAA03154@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Eap STate machinE dEsign teaM (ESTEEM) Discussions Author(s) : B. Aboba Filename : draft-ietf-eap-esteem-00.txt Pages : 44 Date : 2002-10-25 This document describes the deliberations of the EAP STate MachinE DEsign TeaM (ESTEEM). This includes minutes of meetings, as well as position papers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-esteem-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-eap-esteem-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: <2002-10-25110249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-esteem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-esteem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25110249.I-D@ietf.org> --OtherAccess-- --NextPart-- From aboba@internaut.com Mon Oct 28 15:42:39 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 28 Oct 2002 07:42:39 -0800 (PST) Subject: [eap] More details on issue 40 Message-ID: A draft is now available providing more details on Issue 40: http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt From henry.haverinen@nokia.com Tue Oct 29 09:24:55 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Tue, 29 Oct 2002 11:24:55 +0200 Subject: [eap] More details on issue 40 Message-ID: Jose, A slideset about the the man-in-the-middle issue (issue #40) and an accompanying paper are in http://www.saunalahti.fi/~asokan/research/mitm.html We sent this slideset to several people including you at the beginning of this month. Issue #40 and your draft on the topic appeared three weeks later. Please acknowledge this work in your draft. Best regards, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 28 October, 2002 17:43 > To: eap@frascone.com > Subject: [eap] More details on issue 40 >=20 >=20 > A draft is now available providing more details on Issue 40: >=20 > http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jose.p.puthenkulam@intel.com Tue Oct 29 21:16:04 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Tue, 29 Oct 2002 13:16:04 -0800 Subject: [eap] More details on issue 40 Message-ID: Hi Henry, We are willing to acknowledge the Nokia work which showed the Mitm attack with EAP/AKA using tunnelled methods with a false UMTS tower posing as the attacker. We extended on that work for WLAN and also proposed the solution using the stage 3 mutual auth with bound keys. Our first intent was to cite your work as a reference, but as there was no public material available so we couldn't do it easily. But we could have put it in the acknowledgements. As our draft was submitted over the weekend in a hurry to meet the IETF deadline, apologies for the omission. We will include appropriate attribution in our next draft revision. We were aware of this even before you pointed it out, but only after we submitted it :) and cannot change it till after the IETF meeting. thanks, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: henry.haverinen@nokia.com [mailto:henry.haverinen@nokia.com] Sent: Tuesday, October 29, 2002 1:25 AM To: jose.p.puthenkulam@intel.com Cc: aboba@internaut.com; eap@frascone.com Subject: RE: [eap] More details on issue 40 Jose, A slideset about the the man-in-the-middle issue (issue #40) and an accompanying paper are in http://www.saunalahti.fi/~asokan/research/mitm.html We sent this slideset to several people including you at the beginning of this month. Issue #40 and your draft on the topic appeared three weeks later. Please acknowledge this work in your draft. Best regards, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 28 October, 2002 17:43 > To: eap@frascone.com > Subject: [eap] More details on issue 40 > > > A draft is now available providing more details on Issue 40: > > http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From yohba@tari.toshiba.com Wed Oct 30 00:55:10 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 29 Oct 2002 19:55:10 -0500 Subject: [eap] More details on issue 40 In-Reply-To: References: Message-ID: <20021030005510.GA9306@catfish> I also very much appreciate the work related to issue 40, which is also important for PANA over TLS, as pointed out in the documents cited in this thread. The new version of PANA over TLS draft has some improvement on this issue. I'll add the citations for the documents in the refererence section of the draft in the next version. BTW, I would like to make sure that the problem is essentially due to combining multiple authentication methods without cryptographically co-relating them, not due to lack of mutual authentication in some of the methods. Regards, Yoshihiro Ohba On Tue, Oct 29, 2002 at 01:16:04PM -0800, Puthenkulam, Jose P wrote: > Hi Henry, > > We are willing to acknowledge the Nokia work which showed the Mitm attack > with EAP/AKA using tunnelled methods with a false UMTS tower posing as the > attacker. We extended on that work for WLAN and also proposed the solution > using the stage 3 mutual auth with bound keys. Our first intent was to cite > your work as a reference, but as there was no public material available so > we couldn't do it easily. But we could have put it in the acknowledgements. > As our draft was submitted over the weekend in a hurry to meet the IETF > deadline, apologies for the omission. We will include appropriate > attribution in our next draft revision. > > We were aware of this even before you pointed it out, but only after we > submitted it :) and cannot change it till > after the IETF meeting. > > thanks, > jose > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jose Puthenkulam > Senior Software Engineer > Emerging Platforms Lab > Intel R & D > Intel Corporation > 2111 NE 25th Avenue, JF2-58 > Hillsboro, OR 97124 > Tel: (503) 264 6121 > Fax: (503) 264 8154 > Email: jose.p.puthenkulam@intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -----Original Message----- > From: henry.haverinen@nokia.com [mailto:henry.haverinen@nokia.com] > Sent: Tuesday, October 29, 2002 1:25 AM > To: jose.p.puthenkulam@intel.com > Cc: aboba@internaut.com; eap@frascone.com > Subject: RE: [eap] More details on issue 40 > > > > Jose, > > A slideset about the the man-in-the-middle issue (issue #40) and an > accompanying paper are in > http://www.saunalahti.fi/~asokan/research/mitm.html > > We sent this slideset to several people including you at the beginning > of this month. Issue #40 and your draft on the topic appeared three > weeks later. Please acknowledge this work in your draft. > > Best regards, > Henry > > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 28 October, 2002 17:43 > > To: eap@frascone.com > > Subject: [eap] More details on issue 40 > > > > > > A draft is now available providing more details on Issue 40: > > > > http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Oct 30 02:25:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Oct 2002 18:25:31 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <20021030005510.GA9306@catfish> Message-ID: > BTW, I would like to make sure that the problem is essentially due to > combining multiple authentication methods without cryptographically > co-relating them, not due to lack of mutual authentication in some of > the methods. We have set aside some time in the second session at IETF 55 to discuss the problem and potential solution approaches in more detail. If anyone would like to make a presentation on the subject, send mail to myself and Jari. The attack can still be perpetrated even if the methods that are tunneled support mutual authentication. This is because the ends that are authenticated are the client and server, but the man-in-the-middle still obtains the keys from the tunnel authentication which is only one-way. The man-in-the-middle cannot necessarily decrypt the traffic sent by the real client, but this is not necessary since the attacker is already authenticated to the network and in possession of the keys required to authentication and/or encrypt data traffic. Thus the client has served its purpose and the attacker can drop traffic arriving from it. Note that some of the proposed solutions (e.g. compound MAC and/or compound keys) require that the tunneled methods generate keys. Thus these solutions do not apply to methods such as EAP MD5, OTP or GTC. Since these methods are well established, it does not seem practical to modify them so as to incorporate previously derived keys either. From gwz@cisco.com Wed Oct 30 04:16:27 2002 From: gwz@cisco.com (Glen Zorn) Date: Tue, 29 Oct 2002 20:16:27 -0800 Subject: [eap] More details on issue 40 In-Reply-To: Message-ID: Bernard Aboba [mailto:aboba@internaut.com]: The cryptographic solutions to the problem that I have seen are deeply flawed, in that they win the battle (the MitM is kept from highjacking the session) but lose the war (the attacker still ends up with the (weak) user credentials that the tunnel was supposed to protect). In fact, I suspect that combining the e.g. TLS and MS-CHAP v2 keys might weaken the protection of the session. IMHO, the only way to actually solve the problem is through client & server policy. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of > Bernard Aboba > Sent: Tuesday, October 29, 2002 6:26 PM > To: Yoshihiro Ohba > Cc: Puthenkulam, Jose P; 'henry.haverinen@nokia.com'; eap@frascone.com > Subject: Re: [eap] More details on issue 40 > > > > BTW, I would like to make sure that the problem is essentially due to > > combining multiple authentication methods without cryptographically > > co-relating them, not due to lack of mutual authentication in some of > > the methods. > > We have set aside some time in the second session at IETF 55 to discuss > the problem and potential solution approaches in more detail. If anyone > would like to make a presentation on the subject, send mail to myself and > Jari. > > The attack can still be perpetrated even if the methods that are tunneled > support mutual authentication. This is because the ends that are > authenticated are the client and server, but the man-in-the-middle still > obtains the keys from the tunnel authentication which is only one-way. The > man-in-the-middle cannot necessarily decrypt the traffic sent by the real > client, but this is not necessary since the attacker is already > authenticated to the network and in possession of the keys required to > authentication and/or encrypt data traffic. Thus the client has served its > purpose and the attacker can drop traffic arriving from it. > > Note that some of the proposed solutions (e.g. compound MAC and/or > compound keys) require that the tunneled methods generate keys. Thus these > solutions do not apply to methods such as EAP MD5, OTP or GTC. > Since these methods are well > established, it does not seem practical to modify them so as to > incorporate previously derived keys either. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Wed Oct 30 03:29:36 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 29 Oct 2002 19:29:36 -0800 (PST) Subject: [eap] Minutes of the 10/16/02 EAP Design Team Message-ID: -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, October 28, 2002 2:02 AM To: Bernard Aboba; eap-design@internaut.com Subject: minutes of meeting, oct 16 Date: Wednesday, October 16, 2002 and Wednesdays thereafter Time: 8 AM PDT, 11 AM EST Phone #: 425-706-7766 or 800-456-7312 Meeting ID: 124843 Agenda - 802.1aa Comment resolutions - University of Maryland issues for resolution - Bernard's position paper Present: - Paul Congdon - Bernard Aboba - Tony Jeffrey - Jari Arkko - Nick Petroni - Robert Moskovits - Yoshihiro Ohba o Tony Jeffrey and IEEE - An issue has come up when Tony tried to implement the changes they agreed in the last ieee meeting. The primary problem is that request identity not necessarily the first message. They originally planned to change the way EAP exchange was initiated. Now the plan was to send message back to the radius server, to get it to initiate EAP. Then they realized there's a major problem with this: this was not just for initiaing eap, but also to find out if there's a live 802.1x device on the other end of the link. This will lead to calling the radius server every time there's a change on link status Bernard: This also comes up in 802.11. They've overloaded the initial message to signal 1. start and 2. establish that there's someone to talk to. Tony, Paul, Bernard: The easy way is to keep the existing approach, but with the change that the first message can be any message, not just request identity. There are two choices: 1. any message selected by the radius server, or 2. the message is built-in. Typically Radius server will respond in the same way anyway (unless there's a MAC address lookup which we can't have with switches). At the switch end you would configure a message type for the initial exchange, and that would be used for starts within the port. Typically this would be Identity Request, but could also be something else Someone: This would reduce the number of RTTs to the radius server Bernard: In the future we may have the first message of a method hold a challenge; this would be in conflict with this. Do we need to give a type, or a message? Does the authenticator know the method, or just send a canned bytestring? DECISION: Still have to insert the current identifier. The MIB object is essentially a type and text. Jari: What about roaming, does this work? Bernard: Yes. The default is today's Identity Request. We could start with a protected method in this new system. This would provide privacy up to the radius proxy. Everyone on the area must be using the same first method. The main change is in RFC 2869, explaining how this would work. RFC 2284 does not need to be changed. o Other issues while Tony was on line - Bernard: Do you like the approach we've been planning that once a method begins, we lock to this method state and do not accept other methods until its done? Tony: OK. - Is it OK if Notification can be sent at any time? Yes. - Question: Is there a clean management of id values when multiple things are coming around, e.g. Notification and a method? Answer: This is from the server and responded as normally. So yes. Problem with Radius a la 2869, however. - Do you Tony like the approach we've been planning for the documentation of the state machines? Tony: sounds good. formal state machines would be good. Bernard: the format will be as close to the 802.1aa format as possible. - Question: When does a supplicat discard a success or a failure? 802.11aa chose not to address this, but we will handle in IETF. - Bernard: In IETF #55 we probably don't get the state machine completed yet. But hopefully within 1-2 months there's a state machine draft. - DECISION: Tony and Paul try to figure out the exact text for their procudere in the first item of the minutes and get it reviewed. - Bernard: What is the 802.1aa schedule? Tony: Depends on comments, fastest track sponsor ballot before Christmas. - Bernard: Sounds like we are on a similar schedule - 802.1aa has developed some MIB material, which can be posted later as an informational Internet-Draft - RADIUS attributes needs to be a new maintenance revision of 802.1x - We are probably going to move 802.1x support to the Diameter draft, as there is a separate draft on EAP AAA now. - Bernard: Any other issues in IEEE & IETF relationship? - Tony: Things are going pretty well at the moment. o Talk about the issues U of Maryland brought up on the mailing list: - We need to nail down the interface stuff before we proceed. John's proposals helped here. - How is informaton passed mux-method? - DECISION: Use variables. - How is information passed between methods? Open. - What about keying information? Open too. For instance, another method could be following tls, uses cipher determined in tls. - Everyone should have access to the IDs (potentially several). - Ordering: How to decide the policy, how dows policy affect the protocol? Bernard : This is not visible on the wire. Lets talk about this later. Sequencing and tunneling issues do show up on the issue list. One issue is cryptographic binding, talking to the same endpoint all of the time. To fix that, we need a way to push down the keys and use them, using some sort of MAC that shows I know the keys for all previous methods. - One concern with interfaces is that we no longer allow implementations to be stupid. Bernard: we should document the implications. - Bernard: All agree that these issues need to get done. we should focus on interfaces for the next couple of weeks. o Bernard's position paper on primitives - There is a picture about the architecture and layering. - Primitives: - get_identity . Might cause an send_identity invoke. - send_identity - Jari: Why is there no answer_identity? Bernard: Can't do it ; relates to Jessie Walker's issue. Maybe affected by the expected next method, as a policy thing. But you could get it wrong. - complete_method, informs the result. - Jari: Why does this remove all filters, what if this particular method does not want anything run after it (e.g. tunneled EAP TLS)? - Bob: We need authenticated success/failure. Bernard: We've gone from a single method to tunnel/multiple. Jari: Does someone actually use sequences of methods or only tunneling? Answer: Yes, both are done. - request keys, provide keys - Jari: Are these just keys or also the cipher suite? Bernard: Probably we need a separate primitive for that. - Bernard: Do we like this set of primitives? Are primitives a good thing? - Jari: Yes -- need more details though. - Jari: Some of this has to be standardized, like the use of the keys. Other parts is implementation dependent. - Bernard: Its a basic question how the cryptographic binding gets done. Would this be in 2284 bis or not? Jari: Lets do it later. - Do we also need a notification primitive? - DECISION: Bernard: Yes, we do. - Jari: who sends success/failure? - DECISION: Bernard: I think we decided that its the eap layer. Perhaps we need to give a parameter for Complete that says whether to send a success/failure or not. On AAA, we also need to know whether to send Access-Accept or not. It seems like the indication is necessary. o Closing remarks - We need more position papers around these issues. From mohanp@tahoenetworks.com Wed Oct 30 18:24:01 2002 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Wed, 30 Oct 2002 10:24:01 -0800 Subject: [eap] More details on issue 40 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A30D@TNEXVS02.tahoenetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C28041.85631FCF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The paper by N. Asokan et. al. "Man-in-the-middle in Tunneled Authentication", section 3, states the following as one of the reasons as to why this attack is possible : 1. The legacy client authentication protocol is used in other environments, e.g., plain EAP without any tunnelling, or without any encapsulation at all, e.g., direct use of one-time passwords, or cellular authentication protocols. The current IETF drafts do not provide any means for the inner protocol to verify if it is used with tunnelling or not. In the drafts it is considered as a major benefit of the protection protocols that no changes are required in the legacy protocols to be tunnelled. And I did not see such a clear statement (may be I missed it) in the draft that was sent out earlier. If you read section 3 of the draft, it talks about "inducing" the client to authenticate using one of the methods permitted in the tunnel i.e if the MiTM used TLS, it expects the client to use EAP. From this can we conclude, that the attack is possible mainly because we still have clients that just use plain EAP etc. ? One more basic question regarding the draft. In the third step, the client connects to the rogue NAS or AP and the attacker tunnels the authentications method between the client and server. Isn't there a shared secret (which is pre-configured and different from the tunnel keys established in step 1) between NAS and the back-end AS that protects all the messages between NAS and AS ? In that case, wouldn't the AS would discard the message as it is coming from a rogue NAS. Why isn't this happening ?=20 thanks -mohan >=20 > > BTW, I would like to make sure that the problem is=20 > essentially due to=20 > > combining multiple authentication methods without cryptographically=20 > > co-relating them, not due to lack of mutual authentication=20 > in some of=20 > > the methods. >=20 > We have set aside some time in the second session at IETF 55=20 > to discuss the problem and potential solution approaches in=20 > more detail. If anyone would like to make a presentation on=20 > the subject, send mail to myself and Jari. >=20 > The attack can still be perpetrated even if the methods that=20 > are tunneled support mutual authentication. This is because=20 > the ends that are authenticated are the client and server,=20 > but the man-in-the-middle still obtains the keys from the=20 > tunnel authentication which is only one-way. The=20 > man-in-the-middle cannot necessarily decrypt the traffic sent=20 > by the real client, but this is not necessary since the=20 > attacker is already authenticated to the network and in=20 > possession of the keys required to authentication and/or=20 > encrypt data traffic. Thus the client has served its purpose=20 > and the attacker can drop traffic arriving from it. > =20 > Note that some of the proposed solutions (e.g. compound MAC=20 > and/or compound keys) require that the tunneled methods=20 > generate keys. Thus these solutions do not apply to methods=20 > such as EAP MD5, OTP or GTC. Since these methods are well=20 > established, it does not seem practical to modify them so as=20 > to incorporate previously derived keys either. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 ------_=_NextPart_001_01C28041.85631FCF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eap] More details on issue 40

The paper by N. Asokan et. al. "Man-in-the-middle = in Tunneled Authentication", section 3,
states the following as one of the reasons as to why = this attack is possible :

1. The legacy client authentication protocol is used = in other environments, e.g., plain
   EAP without any tunnelling, or without = any encapsulation at all, e.g., direct use of
   one-time passwords, or cellular = authentication protocols.

   The current IETF drafts do not provide = any means for the inner protocol to verify if it
   is used with tunnelling or not. In the = drafts it is considered as a major benefit of the
   protection protocols that no changes are = required in the legacy protocols to be tunnelled.

And I did not see such a clear statement (may be I = missed it) in the draft that was sent
out earlier.  If you read section 3 of the = draft, it talks about "inducing" the client
to authenticate using one of the methods permitted in = the tunnel i.e if the MiTM used TLS, it
expects the client to use EAP. From this can we = conclude, that the attack is possible mainly
because we still have clients that just use plain EAP = etc. ?

One more basic question regarding the draft. In the = third step, the client connects to
the rogue NAS or AP and the attacker tunnels the = authentications method between the client
and server. Isn't there a shared secret (which is = pre-configured and different from
the tunnel keys established in step 1) between NAS = and the back-end AS that protects
all the messages between NAS and AS ? In that case, = wouldn't the AS would discard the message
as it is coming from a rogue NAS. Why isn't this = happening ?

thanks
-mohan


>
> > BTW, I would like to make sure that the = problem is
> essentially due to
> > combining multiple authentication methods = without cryptographically
> > co-relating them, not due to lack of mutual = authentication
> in some of
> > the methods.
>
> We have set aside some time in the second = session at IETF 55
> to discuss the problem and potential solution = approaches in
> more detail. If anyone would like to make a = presentation on
> the subject, send mail to myself and = Jari.
>
> The attack can still be perpetrated even if the = methods that
> are tunneled support mutual authentication. This = is because
> the ends that are authenticated are the client = and server,
> but the man-in-the-middle still obtains the keys = from the
> tunnel authentication which is only one-way. The =
> man-in-the-middle cannot necessarily decrypt the = traffic sent
> by the real client, but this is not necessary = since the
> attacker is already authenticated to the network = and in
> possession of the keys required to = authentication and/or
> encrypt data traffic. Thus the client has served = its purpose
> and the attacker can drop traffic arriving from = it.
> 
> Note that some of the proposed solutions (e.g. = compound MAC
> and/or compound keys) require that the tunneled = methods
> generate keys. Thus these solutions do not apply = to methods
> such as EAP MD5, OTP or GTC. Since these methods = are well
> established, it does not seem practical to = modify them so as
> to incorporate previously derived keys = either.
>
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frasco= ne.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C28041.85631FCF-- From aboba@internaut.com Wed Oct 30 17:57:11 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 09:57:11 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A30D@TNEXVS02.tahoenetworks.com> Message-ID: > expects the client to use EAP. From this can we conclude, that the > attack is possible mainly because we still have clients that just use > plain EAP etc. ? The attack can be perpetrated even against clients that don't support EAP at all. For example, if a client support CHAP (as most PPP implementations do) but not EAP, then if the server allows EAP-MD5 inside the tunnel, then the attacker can bring up a tunnel, get the EAP-MD5 challenge, and get the client to respond to it with a CHAP-Response. In fact, I'd argue that the methods most likely to be used within tunnels (EAP-MD5/CHAP, SIM, OTP, GTC, SECURID, EAP-MS-CHAP-v2) are precisely those that are widely deployed today outside tunnels. After all, a large part of the appeal of tunnels is as a mechanism for improving the security of those methods, most of which do not generate keys. > One more basic question regarding the draft. In the third step, the > client connects to the rogue NAS or AP and the attacker tunnels the > authentications method between the client and server. Isn't there a > shared secret (which is pre-configured and different from > the tunnel keys established in step 1) between NAS and the back-end AS > that protects all the messages between NAS and AS ? There is a shared secret protecting messages sent between the *real* NAS and the AS. However, no shared secret or other mutual authentication is needed between the attacker and the real NAS -- the tunnel authentication is only one-way. In effect, by inventing EAP tunneling methods that only require one-way authenticated tunnel setup, we have created a AAA protocol without support for mutual authentication. This is what enables the vulnerability. > In that case, wouldn't the AS would discard the message > as it is coming from a rogue NAS. Why isn't this happening ? Because the rogue NAS is talking to the real NAS/AP, not the AAA server. The real NAS is taking the EAP messages it receives and tunneling them within AAA, and applying the required mutual authentication, so that the messages look just fine to the AAA server. From yohba@tari.toshiba.com Wed Oct 30 19:17:15 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 30 Oct 2002 14:17:15 -0500 Subject: [eap] More details on issue 40 In-Reply-To: References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A30D@TNEXVS02.tahoenetworks.com> Message-ID: <20021030191715.GC2722@catfish> On Wed, Oct 30, 2002 at 09:57:11AM -0800, Bernard Aboba wrote: > > One more basic question regarding the draft. In the third step, the > > client connects to the rogue NAS or AP and the attacker tunnels the > > authentications method between the client and server. Isn't there a > > shared secret (which is pre-configured and different from > > the tunnel keys established in step 1) between NAS and the back-end AS > > that protects all the messages between NAS and AS ? > > There is a shared secret protecting messages sent between the *real* NAS > and the AS. However, no shared secret or other mutual authentication is > needed between the attacker and the real NAS -- the tunnel authentication > is only one-way. In effect, by inventing EAP tunneling methods that only > require one-way authenticated tunnel setup, we have created a AAA protocol > without support for mutual authentication. This is what enables the > vulnerability. > That is not the actual enabler of the vulnerability, IMO. Even if EAP tunneling methods require mutual authenticated tunnel setup, the attack is still possible if there is no cryptographic binding between outer and inner authentication methods. If that is true, combining multiple authentication methods in a single authentication conversation without cryptographically binding would be the actual enabler of the vulnerability. On the other hand, one-way authentication would make it worse. Yoshihiro Ohba From mohanp@tahoenetworks.com Wed Oct 30 19:33:21 2002 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Wed, 30 Oct 2002 11:33:21 -0800 Subject: [eap] More details on issue 40 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A30E@TNEXVS02.tahoenetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C2804B.347863EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, Thanks for the clarification. >=20 > > expects the client to use EAP. From this can we conclude, that the=20 > > attack is possible mainly because we still have clients=20 > that just use=20 > > plain EAP etc. ? >=20 > The attack can be perpetrated even against clients that don't=20 > support EAP at all. For example, if a client support CHAP (as=20 > most PPP implementations > do) but not EAP, then if the server allows EAP-MD5 inside the=20 > tunnel, then the attacker can bring up a tunnel, get the=20 > EAP-MD5 challenge, and get the client to respond to it with a=20 > CHAP-Response. >=20 Agreed. These attacks will happen as long as clients contiune to use the untunneled legacy authentication protocols but the backend server supports tunneled authentication protocols also which can be used by the attacker. We assume that these clients will continue to exist for sometime.=20 > In fact, I'd argue that the methods most likely to be used=20 > within tunnels (EAP-MD5/CHAP, SIM, OTP, GTC, SECURID,=20 > EAP-MS-CHAP-v2) are precisely those that are widely deployed=20 > today outside tunnels. After all, a large part of the appeal=20 > of tunnels is as a mechanism for improving the security of=20 > those methods, most of which do not generate keys. >=20 > > One more basic question regarding the draft. In the third step, the=20 > > client connects to the rogue NAS or AP and the attacker tunnels the=20 > > authentications method between the client and server. Isn't there a=20 > > shared secret (which is pre-configured and different from=20 > the tunnel=20 > > keys established in step 1) between NAS and the back-end AS that=20 > > protects all the messages between NAS and AS ? >=20 > There is a shared secret protecting messages sent between the=20 > *real* NAS and the AS. However, no shared secret or other=20 > mutual authentication is needed between the attacker and the=20 > real NAS -- the tunnel authentication is only one-way. In=20 > effect, by inventing EAP tunneling methods that only require=20 > one-way authenticated tunnel setup, we have created a AAA=20 > protocol without support for mutual authentication. This is=20 > what enables the vulnerability. >=20 > > In that case, wouldn't the AS would discard the message > > as it is coming from a rogue NAS. Why isn't this happening ? >=20 > Because the rogue NAS is talking to the real NAS/AP, not the=20 > AAA server. The real NAS is taking the EAP messages it=20 > receives and tunneling them within AAA, and applying the=20 > required mutual authentication, so that the messages look=20 > just fine to the AAA server. >=20 Ok. In Figure (1), not sure what the "tunnel keys" (that extend from Auth server to NAS) refer to. -mohan >=20 ------_=_NextPart_001_01C2804B.347863EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eap] More details on issue 40

Bernard,

Thanks for the clarification.

>
> > expects the client to use EAP. From this = can we conclude, that the
> > attack is possible mainly because we still = have clients
> that just use
> > plain EAP etc. ?
>
> The attack can be perpetrated even against = clients that don't
> support EAP at all. For example, if a client = support CHAP (as
> most PPP implementations
> do) but not EAP, then if the server allows = EAP-MD5 inside the
> tunnel, then the attacker can bring up a tunnel, = get the
> EAP-MD5 challenge, and get the client to respond = to it with a
> CHAP-Response.
>
Agreed. These attacks will happen as long as clients = contiune
to use the untunneled legacy authentication protocols = but the backend
server supports tunneled authentication protocols = also which can be
used by the attacker. We assume that these clients = will continue to
exist for sometime.

> In fact, I'd argue that the methods most likely = to be used
> within tunnels (EAP-MD5/CHAP, SIM, OTP, GTC, = SECURID,
> EAP-MS-CHAP-v2) are precisely those that are = widely deployed
> today outside tunnels. After all, a large part = of the appeal
> of tunnels is as a mechanism for improving the = security of
> those methods, most of which do not generate = keys.
>

> > One more basic question regarding the draft. = In the third step, the
> > client connects to the rogue NAS or AP and = the attacker tunnels the
> > authentications method between the client = and server. Isn't there a
> > shared secret (which is pre-configured and = different from
> the tunnel
> > keys established in step 1) between NAS and = the back-end AS that
> > protects all the messages between NAS and = AS ?
>
> There is a shared secret protecting messages = sent between the
> *real* NAS and the AS. However, no shared secret = or other
> mutual authentication is needed between the = attacker and the
> real NAS -- the tunnel authentication is only = one-way. In
> effect, by inventing EAP tunneling methods that = only require
> one-way authenticated tunnel setup, we have = created a AAA
> protocol without support for mutual = authentication. This is
> what enables the vulnerability.
>
> > In that case, wouldn't the AS would discard = the message
> > as it is coming from a rogue NAS. Why isn't = this happening ?
>
> Because the rogue NAS is talking to the real = NAS/AP, not the
> AAA server. The real NAS is taking the EAP = messages it
> receives and tunneling them within AAA, and = applying the
> required mutual authentication, so that the = messages look
> just fine to the AAA server.
>
Ok. In Figure (1), not sure what the "tunnel = keys" (that extend
from Auth server to NAS) refer to.

-mohan

>

------_=_NextPart_001_01C2804B.347863EA-- From aboba@internaut.com Wed Oct 30 18:47:55 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 10:47:55 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <20021030191715.GC2722@catfish> Message-ID: > That is not the actual enabler of the vulnerability, IMO. Even if EAP > tunneling methods require mutual authenticated tunnel setup, the > attack is still possible if there is no cryptographic binding between > outer and inner authentication methods. If that is true, combining > multiple authentication methods in a single authentication > conversation without cryptographically binding would be the actual > enabler of the vulnerability. On the other hand, one-way > authentication would make it worse. If there is mutual authentication within the tunnel, then the real NAS knows the identity of the attacker. It can then make a decision about whether to allow the tunneled authentication method or not. L2TP is a good example. This protocol was designed to allow tunneling of PPP authentication. However, this is not a "man in the middle" attack because the two ends of the L2TP tunnel are authenticated using IPsec. If the L2TP server doesn't want to accept PPP authentications from a given L2TP client, it can choose not to. From aboba@internaut.com Wed Oct 30 18:50:40 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 10:50:40 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A30E@TNEXVS02.tahoenetworks.com> Message-ID: > Ok. In Figure (1), not sure what the "tunnel keys" (that extend > from Auth server to NAS) refer to. In the case of EAP, those are the keys derived by the EAP tunnel method (e.g. EAP TTLS, PEAP), used to encrypt/authenticate subsequent data traffic. From yohba@tari.toshiba.com Wed Oct 30 20:06:27 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 30 Oct 2002 15:06:27 -0500 Subject: [eap] More details on issue 40 In-Reply-To: References: <20021030191715.GC2722@catfish> Message-ID: <20021030200627.GC3779@catfish> On Wed, Oct 30, 2002 at 10:47:55AM -0800, Bernard Aboba wrote: > If there is mutual authentication within the tunnel, then the real NAS > knows the identity of the attacker. It can then make a decision about > whether to allow the tunneled authentication method or not. > > L2TP is a good example. This protocol was designed to allow tunneling of > PPP authentication. However, this is not a "man in the middle" attack > because the two ends of the L2TP tunnel are authenticated using IPsec. If > the L2TP server doesn't want to accept PPP authentications from a given > L2TP client, it can choose not to. That scenario would be safe because there seem to be an assumption that the identity used for IPsec and the identity used for PPP are tied at the same authentication server. But I'm not sure the assumption should always hold for all possible multi-method authentication scenarios. In general, different authentication methods in a single authentication conversation may use different identities that are authenticated at different authentication servers and a different kind of MiTM attack is possible, I think. Yoshihiro Ohba > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Oct 30 19:39:12 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 11:39:12 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <20021030200627.GC3779@catfish> Message-ID: > That scenario would be safe because there seem to be an assumption > that the identity used for IPsec and the identity used for PPP are > tied at the same authentication server. The L2TP server typically evaluates the IKE credentials, such as certificates; the AAA server handles the validation of the PPP credentials. So the authentications are typically *not* evaluated at the same place. However, based on the certificate mutual authentication, the L2TP server can decide what PPP userIDs it will allow for a given L2TP client identity. The L2TP client identity is a machineID and the PPP clientID is a userID, so this provides the ability for the L2TP server to decide which users can access the network from which machines. Now, the L2TP server could recognize a particular L2TP client as a NAS doing "compulsory tunneling" and decide to allow *any* PPP user to authenticate to it via the L2TP client. That's the "attack" we're discussing -- except that the "attacker" (L2TP client) has identified itself and been granted the permission to tunnel authentications from other users. On the other hand, if the L2TP server recognizes a particular L2TP client as just an ordinary VPN client (machine bernarda.bigco.com), then it might decide only to forward PPP authentications for user "aboba@bigco.com" to the AAA server, and not any other user. From jose.p.puthenkulam@intel.com Wed Oct 30 21:19:43 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 30 Oct 2002 13:19:43 -0800 Subject: [eap] More details on issue 40 Message-ID: In our draft we mention that there are two mechanisms which provide the maximum protection 1.The additional exchange with Compound MACs and 2.Compound keys for ciphering the link. As you point out, there is a possiblity for the Compound keys may be weaker than the TLS keys generated by the tunnel method. To address this the best way is to define a strong compound key derivation method which doesn't reduce the entropy of the Tunnel keys. Our suggestion would be to form a design team at the next IETF if there is wide support for this proposal to specify the MAC calculation and the Compound key derivation. Server and client policies are hard to administer consistently and leave the problem to the abilities of the Sys Admin. If the protocols and their implementations could simplify administration hazzles I would vouch for it :) thanks, jose -----Original Message----- From: Glen Zorn [mailto:gwz@cisco.com] Sent: Tuesday, October 29, 2002 8:16 PM To: Bernard Aboba Cc: Puthenkulam, Jose P; henry.haverinen@nokia.com; eap@frascone.com; Yoshihiro Ohba Subject: RE: [eap] More details on issue 40 Bernard Aboba [mailto:aboba@internaut.com]: The cryptographic solutions to the problem that I have seen are deeply flawed, in that they win the battle (the MitM is kept from highjacking the session) but lose the war (the attacker still ends up with the (weak) user credentials that the tunnel was supposed to protect). In fact, I suspect that combining the e.g. TLS and MS-CHAP v2 keys might weaken the protection of the session. IMHO, the only way to actually solve the problem is through client & server policy. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of > Bernard Aboba > Sent: Tuesday, October 29, 2002 6:26 PM > To: Yoshihiro Ohba > Cc: Puthenkulam, Jose P; 'henry.haverinen@nokia.com'; eap@frascone.com > Subject: Re: [eap] More details on issue 40 > > > > BTW, I would like to make sure that the problem is essentially due to > > combining multiple authentication methods without cryptographically > > co-relating them, not due to lack of mutual authentication in some of > > the methods. > > We have set aside some time in the second session at IETF 55 to discuss > the problem and potential solution approaches in more detail. If anyone > would like to make a presentation on the subject, send mail to myself and > Jari. > > The attack can still be perpetrated even if the methods that are tunneled > support mutual authentication. This is because the ends that are > authenticated are the client and server, but the man-in-the-middle still > obtains the keys from the tunnel authentication which is only one-way. The > man-in-the-middle cannot necessarily decrypt the traffic sent by the real > client, but this is not necessary since the attacker is already > authenticated to the network and in possession of the keys required to > authentication and/or encrypt data traffic. Thus the client has served its > purpose and the attacker can drop traffic arriving from it. > > Note that some of the proposed solutions (e.g. compound MAC and/or > compound keys) require that the tunneled methods generate keys. Thus these > solutions do not apply to methods such as EAP MD5, OTP or GTC. > Since these methods are well > established, it does not seem practical to modify them so as to > incorporate previously derived keys either. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From mohanp@tahoenetworks.com Wed Oct 30 21:49:46 2002 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Wed, 30 Oct 2002 13:49:46 -0800 Subject: [eap] More details on issue 40 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A310@TNEXVS02.tahoenetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C2805E.43148E44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > On Wed, Oct 30, 2002 at 10:47:55AM -0800, Bernard Aboba wrote: > > If there is mutual authentication within the tunnel, then=20 > the real NAS=20 > > knows the identity of the attacker. It can then make a=20 > decision about=20 > > whether to allow the tunneled authentication method or not. > >=20 > > L2TP is a good example. This protocol was designed to allow=20 > tunneling=20 > > of PPP authentication. However, this is not a "man in the middle"=20 > > attack because the two ends of the L2TP tunnel are=20 > authenticated using=20 > > IPsec. If the L2TP server doesn't want to accept PPP=20 > authentications=20 > > from a given L2TP client, it can choose not to. >=20 > That scenario would be safe because there seem to be an=20 > assumption that the identity used for IPsec and the identity=20 > used for PPP are tied at the same authentication server. But=20 > I'm not sure the assumption should always hold for all=20 > possible multi-method authentication scenarios. In general,=20 > different authentication methods=20 > in a single authentication conversation may use different identities=20 > that are authenticated at different authentication servers and=20 > a different kind of MiTM attack is possible, I think. >=20 I am not sure which particular case is problematic here : 1) Tunneled authentication method using a different identity going to the same authentication server. 2) Tunneled authentication method using a different identity going to a different authentication server. In case (1), I think we need the ability to restrict what identities can be used on a secure channel that was established using some identity. It looks like it is possible to do it in L2TP case as Bernard explained. In case (2), you still need to mutually authenticate with the new AS. Am I missing something ? -mohan > Yoshihiro Ohba >=20 >=20 > >=20 > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 ------_=_NextPart_001_01C2805E.43148E44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eap] More details on issue 40

 
>
> On Wed, Oct 30, 2002 at 10:47:55AM -0800, = Bernard Aboba wrote:
> > If there is mutual authentication within = the tunnel, then
> the real NAS
> > knows the identity of the attacker. It can = then make a
> decision about
> > whether to allow the tunneled = authentication method or not.
> >
> > L2TP is a good example. This protocol was = designed to allow
> tunneling
> > of PPP authentication. However, this is not = a "man in the middle"
> > attack because the two ends of the L2TP = tunnel are
> authenticated using
> > IPsec. If the L2TP server doesn't want to = accept PPP
> authentications
> > from a given L2TP client, it can choose not = to.
>
> That scenario would be safe because there seem = to be an
> assumption that the identity used for IPsec and = the identity
> used for PPP are tied at the same authentication = server.  But
> I'm not sure the assumption should always hold = for all
> possible multi-method authentication = scenarios.  In general,
> different authentication methods
> in a single authentication conversation may use = different identities
> that are authenticated at different = authentication servers and
> a different kind of MiTM attack is possible, I = think.
>
I am not sure which particular case is problematic = here :

1) Tunneled authentication method using a different = identity
   going to the same authentication = server.
2) Tunneled authentication method using a different = identity
   going to a different authentication = server.

In case (1), I think we need the ability to restrict = what identities
can be used on a secure channel that was established = using some
identity. It looks like it is possible to do it in = L2TP case as
Bernard explained.

In case (2), you still need to mutually authenticate = with the new
AS. Am I missing something ?

-mohan

> Yoshihiro Ohba
>
>
> >
> > = _______________________________________________
> > eap mailing list
> > eap@frascone.com http://mail.frasco= ne.com/mailman/listinfo/eap
> >
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frasco= ne.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C2805E.43148E44-- From jose.p.puthenkulam@intel.com Wed Oct 30 21:53:10 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 30 Oct 2002 13:53:10 -0800 Subject: [eap] More details on issue 40 Message-ID: One additional point I would also add is that, in our analysis we did find that if only Compound MACs are used and instead of Compound keys, just the tunnel keys are used, the solution is still relatively strong. As possession of the all the method keys by the client are proven just by the Compound MACs. thanks, jose -----Original Message----- From: Puthenkulam, Jose P Sent: Wednesday, October 30, 2002 1:20 PM To: 'gwz@cisco.com'; Bernard Aboba Cc: Puthenkulam, Jose P; henry.haverinen@nokia.com; eap@frascone.com; Yoshihiro Ohba Subject: RE: [eap] More details on issue 40 In our draft we mention that there are two mechanisms which provide the maximum protection 1.The additional exchange with Compound MACs and 2.Compound keys for ciphering the link. As you point out, there is a possiblity for the Compound keys may be weaker than the TLS keys generated by the tunnel method. To address this the best way is to define a strong compound key derivation method which doesn't reduce the entropy of the Tunnel keys. Our suggestion would be to form a design team at the next IETF if there is wide support for this proposal to specify the MAC calculation and the Compound key derivation. Server and client policies are hard to administer consistently and leave the problem to the abilities of the Sys Admin. If the protocols and their implementations could simplify administration hazzles I would vouch for it :) thanks, jose -----Original Message----- From: Glen Zorn [mailto:gwz@cisco.com] Sent: Tuesday, October 29, 2002 8:16 PM To: Bernard Aboba Cc: Puthenkulam, Jose P; henry.haverinen@nokia.com; eap@frascone.com; Yoshihiro Ohba Subject: RE: [eap] More details on issue 40 Bernard Aboba [mailto:aboba@internaut.com]: The cryptographic solutions to the problem that I have seen are deeply flawed, in that they win the battle (the MitM is kept from highjacking the session) but lose the war (the attacker still ends up with the (weak) user credentials that the tunnel was supposed to protect). In fact, I suspect that combining the e.g. TLS and MS-CHAP v2 keys might weaken the protection of the session. IMHO, the only way to actually solve the problem is through client & server policy. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of > Bernard Aboba > Sent: Tuesday, October 29, 2002 6:26 PM > To: Yoshihiro Ohba > Cc: Puthenkulam, Jose P; 'henry.haverinen@nokia.com'; eap@frascone.com > Subject: Re: [eap] More details on issue 40 > > > > BTW, I would like to make sure that the problem is essentially due to > > combining multiple authentication methods without cryptographically > > co-relating them, not due to lack of mutual authentication in some of > > the methods. > > We have set aside some time in the second session at IETF 55 to discuss > the problem and potential solution approaches in more detail. If anyone > would like to make a presentation on the subject, send mail to myself and > Jari. > > The attack can still be perpetrated even if the methods that are tunneled > support mutual authentication. This is because the ends that are > authenticated are the client and server, but the man-in-the-middle still > obtains the keys from the tunnel authentication which is only one-way. The > man-in-the-middle cannot necessarily decrypt the traffic sent by the real > client, but this is not necessary since the attacker is already > authenticated to the network and in possession of the keys required to > authentication and/or encrypt data traffic. Thus the client has served its > purpose and the attacker can drop traffic arriving from it. > > Note that some of the proposed solutions (e.g. compound MAC and/or > compound keys) require that the tunneled methods generate keys. Thus these > solutions do not apply to methods such as EAP MD5, OTP or GTC. > Since these methods are well > established, it does not seem practical to modify them so as to > incorporate previously derived keys either. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From yohba@tari.toshiba.com Wed Oct 30 21:58:54 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 30 Oct 2002 16:58:54 -0500 Subject: [eap] More details on issue 40 In-Reply-To: References: <20021030200627.GC3779@catfish> Message-ID: <20021030215854.GD3779@catfish> On Wed, Oct 30, 2002 at 11:39:12AM -0800, Bernard Aboba wrote: > > That scenario would be safe because there seem to be an assumption > > that the identity used for IPsec and the identity used for PPP are > > tied at the same authentication server. > > The L2TP server typically evaluates the IKE credentials, such > as certificates; the AAA server handles the validation of the PPP > credentials. So the authentications are typically *not* evaluated at the > same place. OK, the assumption would be that the identity used for IKE and the identity used for PPP are statically tied. > Now, the L2TP server could recognize a particular L2TP client as a NAS > doing "compulsory tunneling" and decide to allow *any* PPP user to > authenticate to it via the L2TP client. That's the "attack" we're > discussing -- except that the "attacker" (L2TP client) has > identified itself and been granted the permission to tunnel > authentications from other users. Exactly. The "attack" might be a _weaker_ MiTM attack in the sense that the attacker needs to have at least credentials for outer authentication. > > On the other hand, if the L2TP server recognizes a particular L2TP > client as just an ordinary VPN client (machine bernarda.bigco.com), then > it might decide only to forward PPP authentications for user > "aboba@bigco.com" to the AAA server, and not any other user. > Yes. Yoshihiro Ohba From yohba@tari.toshiba.com Wed Oct 30 22:26:33 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 30 Oct 2002 17:26:33 -0500 Subject: [eap] More details on issue 40 In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A310@TNEXVS02.tahoenetworks.com> References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A310@TNEXVS02.tahoenetworks.com> Message-ID: <20021030222633.GF3779@catfish> On Wed, Oct 30, 2002 at 01:49:46PM -0800, Mohan Parthasarathy wrote: > I am not sure which particular case is problematic here : > > 1) Tunneled authentication method using a different identity > going to the same authentication server. > 2) Tunneled authentication method using a different identity > going to a different authentication server. > > In case (1), I think we need the ability to restrict what identities > can be used on a secure channel that was established using some > identity. It looks like it is possible to do it in L2TP case as > Bernard explained. Yes. > > In case (2), you still need to mutually authenticate with the new > AS. Am I missing something ? In this case, _either_ inner and outer authentication methods need to be cryptographically bound _or_ the inner and outer identities need to be statically tied, regardless of whether mutual authentication is performed with the new AS. > > -mohan > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Thu Oct 31 01:30:56 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 17:30:56 -0800 (PST) Subject: [eap] More details on issue 40 In-Reply-To: <20021030215854.GD3779@catfish> Message-ID: > Exactly. The "attack" might be a _weaker_ MiTM attack in the sense that > the attacker needs to have at least credentials for outer authentication. Specifically, if the "attacker" is granted permission by the administrator to act as an access server itself for specific users. Since this is under the administrator's control, it seems more like a "feature" than a "bug". From yohba@tari.toshiba.com Thu Oct 31 04:02:23 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 30 Oct 2002 23:02:23 -0500 Subject: [eap] More details on issue 40 In-Reply-To: References: <20021030215854.GD3779@catfish> Message-ID: <20021031040223.GB1147@catfish> On Wed, Oct 30, 2002 at 05:30:56PM -0800, Bernard Aboba wrote: > > Exactly. The "attack" might be a _weaker_ MiTM attack in the sense that > > the attacker needs to have at least credentials for outer authentication. > > Specifically, if the "attacker" is granted permission by the administrator > to act as an access server itself for specific users. Since this is under > the administrator's control, it seems more like a "feature" than a "bug". > If that is the feature, then yes, cryptographic binding is not necessary for that specific case. Yoshihiro Ohba From aboba@internaut.com Thu Oct 31 03:24:42 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 30 Oct 2002 19:24:42 -0800 (PST) Subject: [eap] 10/30/02 EAP Design Team Conference call minutes Message-ID: EAP Design Team meeting, Wednesday October 30th, 2002. Minutes taker: Jari Arkko o Agenda Discussion of unresolved EAP issues: http://www.drizzle.com/~aboba/EAP/eapissues.html Discussion of cryptographic binding problems: http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt http://www.saunalahti.fi/~asokan/research/mitm.html Latest RFC 2284bis draft: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt o Issue 2: Alternative indications - Should these be kept or not? - Are protected success and failure a form of alternative indications - Can the 802.1X messages be considered alternative indications - Proposal: rate of loss is low enough, not a problem. Bernard: But PANA folks are expecting to run this on GPRS! - Question: what is the right thing to do from a security point of view? Bob: we should require a success. Jari: depends on whether the indication is protected. Bernard proposes that if a protected indication is available, no alternative indications should be listened. - Is link up and down an alternative indication? Bernard thinks its a different issue. In PPP, you would get back to LCP. - EAPOL logoff, is it an indication or not? What if there's link layer security? Will it help? - Bernard: We probably need to listen to these alternative forms of failure indiciation. THis will open a DoS attack. Jari: The question is if this makes the situation any worse, there may be other equivalent attacks already. - Bernard: I don't like the argument but I can't argue much about it. Let's look at EAPOL logoff as an example. Attacker sends unencrypted EAPOL logoff messages to a multicast address. The access point will have to relay those to all devices on the wireless media, or even to the wired media. Debate whether peer swill act on this? Bernard: it doesn't matter, we can get mac addresses and send unicast messages. - Proposal (Bernard): Lots of ways to do these DoS attacks. Doesn't seem possible to ignore these indiciations. - Bob: we will see link ups and downs all the time anyway, we need to ignore them in case the link comes back online soon. Bernard: Agree. - Bernard: This is like IPsec and ICMP; most implementations don't believe ICMP but rather wait for an IKE timeout. - Jari: the action depends on link layer, e.g. l2tp vs. physical link. Bob: this should go to the link layer specific specs. - DECISION Bernard & Jari: if an authenticated indication exists, should not believe alternative indiciations (unless have to, like the link really went away). In the absense of authenticated indication, alternative failure indications may be accepted if the lower layer specs say so. Success indication should not be believed. - Jari: I'm still unsure about this. What if I have successfully and mutually authenticated the other side? Why would I not believe an alternative success indication. Jari promises to write something about this later. o Issue 7: How to run multiple methods one after another - Bob: What would a non-supported peer do if it get another method and was expecting success or failure? Bernard: This ties to the last issue. If it gets a packet it can't make any assumption about the state. In Windows, authentication will time out. In a later version with support, how would you know if the peer supports sequences or not? Invent a new method to signal that you support them or have it written in the specification that the methods always support sequencing. Or negotiate? Bernard doesn't want to add a roundtrip for negotiation. - Bernard: We also need to discuss whether the end points have to be the same all the time. - Questions: 1) How to do sequences? 2) how to prevent mitm attacks? - Question: Could we add a continuation flag to the header in a backwards compatible way? (Bernards go look at the header.) - Question: Can we send a NAK? Bob: In the Windows version it just sits there and can't even Nak after having executed a method. So we can't rely on Nak. The same applies to a new Command. So the end result is in any case a timeout. The good news is that all the latency is at the end. - Yoshihiro says that if this results in a failure it is not a problem. This is because if the authenticator wanted to do multiple methods, the authentication will fail anyway. - Bernard: Can we change the identity request to specify if the peer can do multiple methods? Or we could have this as a part of the user data base. - DECISION (Jari): Its better to take the timeout at the end for the people who will fail, than spend negotiation time for everyone at the beginning. o Issue 10: Lack of authenticated success and failure indications - Bob: Security people want to have one point where success or failure is indicated. - Bernard: Can we require authenticated indications in some situations, such as for sequences or tunnels? Probably we can't mandate it for existing clients and the basic EAP situation. - Bernard: Can't have authentication until keys are generated. Bob: We can always do a Chap-like request-response which authenticates an indication. We could have an acknowledge-accept approach, and have it mandatory for some new places where EAP is used, such as GPRS or PANA EAP-over-IP. - Jari: One idea is that if someone supports sequences, they could use a protected success -method as the last one in the sequence. - Question: Is it sufficient to protect tunneled indiciations, or do we really have to support also secure indications in sequences? (No opinion) - DECISION: We can't put this in situations where there are no sequences or tunnels. The rest of the discussion has to be taken in IETF #55. o Issue 13: Identifier usage not specified? - Can we specify it to start from 0? It appears more important to specify how it increases and how ordering / duplicates are detected. - Seems like the existing text is quite appropriate. Does not mandate too much, but specifies enough. - DECISION: Existing text is OK for #13 & #18. o Issue 23: Contents of identity request payload - The problem is if we have enough information in Identity Request to be able to answer? In most cases we have some lower layer information, such as the dialled phone number that tells you which identity to use. Do we need something like this in the Identity Request message? - Bernard: Should the authenticator tell its NAI? Jari: Isn't this a chicken and egg problem, how can the authenticator know what to tell before it knows from which roaming ISP this user is from? Bernard: There's methods out-of-band to EAP for knowing e.g. that we clicked the AOL icon so we are looking to give AOL identity. - Bob: I'm working on an extension to give a list of NAIs in the identity request (or in the response). The request contents are treated just as an advertisement. Bernard: This sounds good. o Next meeting - We will have a meeting next week (the last meeting before IEEE and IETF)