From gwz@cisco.com Fri Nov 1 09:32:01 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 1 Nov 2002 01:32:01 -0800 Subject: [eap] FW: I-D ACTION:draft-hiller-eap-tlv-00.txt Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C28146.7A4A03C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit fyi > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, October 31, 2002 10:44 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-hiller-eap-tlv-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : A Container Type for the Extensible > Authentication > Protocol (EAP) > Author(s) : T. Hiller, A. Palekar, G. Zorn > Filename : draft-hiller-eap-tlv-00.txt > Pages : 8 > Date : 2002-10-31 > > The Extensible Authentication Protocol (EAP), defined in RFC 2284, > provides for support of multiple authentication methods. While EAP was > originally created for use with PPP, it has since been adopted for use > with IEEE 802.1X 'Network Port Authentication'. > > Since its deployment, a number of weaknesses in EAP have become > apparent. These include the lack of protection for, and acknowledgement > of Success and Failure messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-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-hiller-eap-tlv-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-hiller-eap-tlv-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_000_000C_01C28146.7A4A03C0 Content-Type: Message/External-body; name="ATT00264.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00264.dat" Content-Type: text/plain Content-ID: <2002-10-31103355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hiller-eap-tlv-00.txt ------=_NextPart_000_000C_01C28146.7A4A03C0 Content-Type: Message/External-body; name="draft-hiller-eap-tlv-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-hiller-eap-tlv-00.txt" Content-Type: text/plain Content-ID: <2002-10-31103355.I-D@ietf.org> ------=_NextPart_000_000C_01C28146.7A4A03C0-- From aboba@internaut.com Sat Nov 2 01:31:14 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 1 Nov 2002 17:31:14 -0800 (PST) Subject: [eap] Strawman agenda for IETF 55, Take 2 Message-ID: Here is take 2 of 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 (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP state machine, Bryan Payne & Nick Petroni, John Vollbrecht (30 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt Tuesday, November 19 0900-1130 EAP security EAP security claims, Glen Zorn (5 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt EAP keying problem, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP Binding Problem, V. Lortz, H. Haverinen (20 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt http://www.saunalahti.fi/~asokan/research/mitm.html EAP key distribution, Jesse Walker (20 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-01.txt Methods (60 minutes) Short (!!) method presentations can go here. Presentations should focus on RFC 2284bis issues encountered during method development, such as usage of NAK/Notification/Identity, uses of sequences or tunnels, acknowledge & protected success/failure, security issues, etc. Roadmap discussion (15 minutes) From gwz@cisco.com Sat Nov 2 06:41:53 2002 From: gwz@cisco.com (Glen Zorn) Date: Fri, 1 Nov 2002 22:41:53 -0800 Subject: [eap] FW: I-D ACTION:draft-zorn-eap-eval-00.txt Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C281F7.E03D63A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, November 01, 2002 5:43 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-zorn-eap-eval-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Specifying Security Claims for EAP Authentication > Types > Author(s) : G. Zorn > Filename : draft-zorn-eap-eval-00.txt > Pages : 4 > Date : 2002-10-31 > > This document describes a method that may be used to enumerate the > claimed security qualities of EAP authentication types in terms of > well-defined objective qualities. These claims may then be used to > evaluate the claims against both the actual operation of the > authentication types themselves and the security requirements of > users (including other standards development organizations). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-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-zorn-eap-eval-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-zorn-eap-eval-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_000_010C_01C281F7.E03D63A0 Content-Type: Message/External-body; name="ATT00124.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00124.dat" Content-Type: text/plain Content-ID: <2002-10-31150311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zorn-eap-eval-00.txt ------=_NextPart_000_010C_01C281F7.E03D63A0 Content-Type: Message/External-body; name="draft-zorn-eap-eval-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-zorn-eap-eval-00.txt" Content-Type: text/plain Content-ID: <2002-10-31150311.I-D@ietf.org> ------=_NextPart_000_010C_01C281F7.E03D63A0-- From henry.haverinen@nokia.com Tue Nov 5 08:23:13 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Tue, 5 Nov 2002 10:23:13 +0200 Subject: [eap] Strawman agenda for IETF 55, Take 2 Message-ID: Hello, Is the second session on Tuesday, as indicated below? The general IETF55 agenda says it's on Thursday: http://www.ietf.org/meetings/agenda_55.html Which agenda is correct? Thanks, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 02 November, 2002 03:31 > To: eap@frascone.com > Subject: [eap] Strawman agenda for IETF 55, Take 2 >=20 >=20 > Here is take 2 of a strawman agenda for the EAP WG meetings=20 > at IETF 55. > Additions/deletions/comments welcome. >=20 > Extensible Authentication Protocol WG (EAP) > IETF 55, Atlanta, GA >=20 > CHAIRS: > Bernard Aboba > Jari Arkko >=20 > AGENDA >=20 > Monday, November 18 1530 - 1730 >=20 > Preliminaries (10 minutes) > Bluesheets and Minutes > Document Status > Interoperability report >=20 > RFC 2284bis Open issues, Bernard Aboba (20 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b > is-07.txt >=20 > EAP IANA considerations, Bernard Aboba (10 minutes) > http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt >=20 > RFC 2869bis Open issues, Bernard Aboba (20 minutes) > http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869 > bis-03.txt >=20 > IEEE 802.1aa reconciliation, Paul Congdon (20 minutes) > http://www.ieee802.org/1/pages/802.1aa.html > Userid: p8021 > Password: go_wildcats >=20 > EAP Design Team report, Jari Arkko (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt >=20 > EAP state machine, Bryan Payne & Nick Petroni, John Vollbrecht (30 > minutes) > http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt >=20 > Tuesday, November 19 0900-1130 >=20 > EAP security >=20 > EAP security claims, Glen Zorn (5 minutes) > http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt >=20 > EAP keying problem, Bernard Aboba (15 minutes) > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-pro blem-03.txt EAP Binding Problem, V. Lortz, H. Haverinen (20 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt http://www.saunalahti.fi/~asokan/research/mitm.html EAP key distribution, Jesse Walker (20 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-01.= txt Methods (60 minutes) Short (!!) method presentations can go here. Presentations should focus = on RFC 2284bis issues encountered during method development, such as usage = of NAK/Notification/Identity, uses of sequences or tunnels, acknowledge & protected success/failure, security issues, etc. Roadmap discussion (15 minutes) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Tue Nov 5 06:37:39 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 05 Nov 2002 08:37:39 +0200 Subject: [eap] Strawman agenda for IETF 55, Take 2 References: Message-ID: <3DC76733.5030500@piuha.net> henry.haverinen@nokia.com wrote: > Is the second session on Tuesday, as indicated below? > The general IETF55 agenda says it's on Thursday: > http://www.ietf.org/meetings/agenda_55.html It was originally on Tuesday, but we've apparently been rescheduled. Given that some people have made travel arrangements counting on Tuesday, we'll try to move it back. Stay tuned for confirmation... Jari From aboba@internaut.com Tue Nov 5 10:58:35 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 5 Nov 2002 02:58:35 -0800 (PST) Subject: [eap] Strawman agenda for IETF 55, Take 2 In-Reply-To: Message-ID: > Which agenda is correct? Not clear yet. I'm looking into it. From dpotter@cisco.com Tue Nov 5 16:13:44 2002 From: dpotter@cisco.com (Darran Potter) Date: Tue, 5 Nov 2002 16:13:44 -0000 Subject: [eap] I-D ACTION:draft-ietf-eap-otp-00.txt In-Reply-To: Message-ID: Bernard Did I miss your response? -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of Darran Potter Sent: 15 October 2002 17:04 To: eap@frascone.com; bernarda@microsoft.com Subject: RE: [eap] I-D ACTION:draft-ietf-eap-otp-00.txt 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Nov 5 17:10:45 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 5 Nov 2002 09:10:45 -0800 (PST) Subject: [eap] Re: EAP OTP In-Reply-To: <200211051658.gA5Gwn307390@internaut.com> Message-ID: > 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 In the original EAP implementation survey, there were no implementations of EAP OTP or GTC. Since the original goal of RFC 2284bis was to advance to Draft Standard (as opposed to recycling at Proposed), OTP and GTC had to be removed from the document. From aboba@internaut.com Wed Nov 6 00:47:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 5 Nov 2002 16:47:31 -0800 (PST) Subject: [eap] Strawman agenda for IETF 55, Take 3 Message-ID: Here is take 3 of 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 (5 minutes) Bluesheets and Minutes Document Status EAP Design Team Report, Jari Arkko (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt EAP Roadmap Discussion (10 minutes) Tuesday November 19 1700-1800 EAP security (cont'd) EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Methods (50 minutes) Short (!!) method presentations can go here. Presentations should focus on RFC 2284bis issues encountered during method development, such as usage of NAK/Notification/Identity, uses of sequences or tunnels, acknowledge & protected success/failure, security issues, etc. If you want to present, please send mail to the Jari or Bernard. From aboba@internaut.com Wed Nov 6 01:15:48 2002 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 5 Nov 2002 17:15:48 -0800 (PST) Subject: [eap] Issue 42: EAP Enhancements Message-ID: Issue 42: EAP Enhancements Submitter: Tena Tsou Submitter email address: tena@huawei.com Date first submitted: November 5, 2002 Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 42 Document: RFC2284bis-07, 802.1aa D3 Comment type: T Priority: S Section: Many Rationale/Explanation of issue: This comment was received during IEEE balloting on IEEE 802.1aa Draft 3. Since it requests EAP protocol changes, it has been filed as an EAP Issue for resolution by EAP WG. For a full transcript of the issue, including the recommended revised EAP packet format, see Issue 42 on the EAP Issues list. Supplementary Comment to IEEE P802.1aa Add this section to the end of Section 8.4: 1.1.1. Handshaking mechanism The Authenticator should be able to detect users abnormal disconnection and provide the online users and charging information as precise as possible. The Authenticator should support the handshaking mechanism with the Supplicant. During the handshaking, the controlled ports keep the authorized status, until the handshaking fails, then the controlled ports turn to the unauthorized status. The Authenticator uses EAP-Request/Identity as the handshaking request packet, and the Supplicant uses EAP-Response/Identity as the handshaking response packet. It is recommended to set the range allowed for the handshaking period (must be configurable) to 5-90s, and its default value to 15s. Moreover, the handshaking period should be less than the parameter value of authPeriod when the Supplicant PAE performs re-authentication for the timer authWhile (see IEEE std 802.1X-2001, 8.5), and the recommended parameter value of authPeriod is as twice as the handshaking period at least. The maximum times of handshaking should be configurable and the recommended value is 3. The requirements on 802.1X Supplicant: The following should be added to the end of the Section 7.7.4 (see the red below): EAP packet format When the protocol field of the PPP frame (see IETF RFC 1661) indicates that the protocol type is C227 (PPP EAP), only one PPP EAP packet is encapsulated in the Information field of the frame in PPP data link layer. The format of EAP packet is shown in Figure A-1.Each field is transmitted from left to right one by one. Figure A-1 EAP packet format (See EAP Issues list for Figure) A.1.1. Code The Code field is one octet in length and identifies the type of EAP packet. EAP Codes are assigned as follows: 1 Request 2 Response 3 Success 4 Failure A.1.2. Identifier The Identifier filed is one octet in length and allows matching of Response with Request. The Identifier field and System Port together uniquely identify an authentication exchange. Thus, the use of a single octet identifier field results in a restriction of 256 authentications per System Port. The operation of the Authenticator PAE determines the value of Identifier used in the EAP-Request/Identify packets. The Supplicant PAE uses the same Identifiers in subsequent EAP-Request/Identify packets responding to that initial frame. The Authenticator PAE uses the same Identifier value in any re-transmissions of the same request. A.1.3. Length The Length field is two octets in length and indicates the length of the EAP packet, including the Code, Identifier, Length, and Data fields. A.1.4. Data The Data field is zero or more octets. The format of the Data field is determined by the Code field. Type The Type field is one octet and mainly defines various authentication mechanisms. The Type values in ITEF RFC 2284 include the first six of the following. As required, the No. 7 and 8 Type values are added into this standard. The Type values 1~2, 4~7 and 13 apply to the Request and Response packet, the Type value 3 only applies to the Response packet and the Type value 8 only applies to the Failure packet. 1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One-Time Password (OTP) (RFC1938) 6 Generic Token Card 7 PAP 8 CauseCode A.1.5. Identity The Identity type is used to query the users status. Each Identity type of Request packet should correspond to an Identity type of Response packet. A.1.6. Notification The Notification type is used to send an on-screen message from the Authenticator to the Supplicant. The Supplicant should display the message for the users. If it can not be displayed, it should be recorded into the log. Each Notification type of Request packet should correspond to a Notification type of Response packet. A.1.7. Nak The Nak type only applies to the Response packet. When the expected authentication mechanism in the Request packet is not accepted, the Nak type of Response packet should be sent. A.1.8. MD5-Challenge The MD5-Challenge type is similar to the MD5 in CHAP protocol (see IETF RFC 1994). The MD5-Challenge type of Request packet includes the Challenge message. Each MD5-Challenge type of Request packet should correspond to an MD5-Challenge type or a Nak type of Response packet. A.1.9. One-Time Password The One-Time Password type of Request packet includes an OTP Challenge. Each One-Time Password type of Request packet should correspond to a One-Time Password type or a Nak type of Response packet. Refer to IETF RFC 1938 for more information about One-Time Password System. A.1.10. Generic Token Card The Generic Token Card type is defined for the users to enter various Token Card messages. The Generic Token Card type of Request packet includes an ASCII text message, and the corresponding Generic Card type of Response packet includes the necessary information related to the Token Card. Usually the information is read by the users from the Token Card device and is entered in ASCII text. A.1.11. PAP The PAP type is similar to the PPP PAP protocol. The difference is that the PPP PAP must be originated by the Supplicant, while the PAP in EAP can be originated by the Authenticator. In the Request packet, use the No.7 type value to originate the PAP authentication and request the password of the other party. The password is sent in plain text on the network. Each PAP type of Request packet should correspond to a PAP type or a Nak type of Response packet. A1.12. CauseCode The CauseCode type is used to give the failure causes of authentication for the Supplicant. The CauseCode Values give the failure causes. The CauseCode Values include the following eight types: 1 Name-Pwd-Failure Incorrect user name and the password 2 IdleCut Idle cut logoff 3 TimeCut Time restriction cut off 4 FlowCut Flow restriction cut off 5 Supplicant-Logoff Supplicant logoff actively 6 Supplicant-Restart Supplicant restarting 7 Reauthen-Failure Re-authentication failure 8 Other-Failure Other causes of failure Tena Tsou Signalling and Protocol Department, R&D Huawei Tech. Tel:86-755-26516939 tena@huawei.com From gwz@cisco.com Thu Nov 7 05:38:40 2002 From: gwz@cisco.com (Glen Zorn) Date: Wed, 6 Nov 2002 21:38:40 -0800 Subject: [eap] Issue 42: EAP Enhancements In-Reply-To: Message-ID: Bernard Aboba [mailto:aboba@internaut.com] writes: > Issue 42: EAP Enhancements Recommend rejection. There are almost too many problems with this issue to list. First, the expected applicability of the "Handshaking mechanism" is unclear: what is the purpose of this heartbeat? AFAIK, virtually all link layers have a link-down indication of some type and reliability; why recover this functionality in EAP? Second, the actual heartbeat mechanism provides virtually no assurance that the user/peer that sent the nth heartbeat is the same as the user/peer that sent the n-1st, since Identity responses are not authenticated. Last but not least, though the ability to transmit plaintext passwords is of indubitable utility, it opens a hole in EAP about a mile wide and is rarely actually necessary. > Submitter: Tena Tsou > Submitter email address: tena@huawei.com > Date first submitted: November 5, 2002 > Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 42 > Document: RFC2284bis-07, 802.1aa D3 > Comment type: T > Priority: S > Section: Many > > Rationale/Explanation of issue: > > This comment was received during IEEE balloting on IEEE 802.1aa Draft 3. > Since it requests EAP protocol changes, it has been filed as an EAP Issue > for resolution by EAP WG. For a full transcript of the issue, including > the recommended revised EAP packet format, see Issue 42 on the EAP Issues > list. > > Supplementary Comment to IEEE P802.1aa > > Add this section to the end of Section 8.4: > > 1.1.1. Handshaking mechanism > > The Authenticator should be able to detect users abnormal disconnection > and provide the online users and charging information as precise as > possible. The Authenticator should support the handshaking mechanism with > the Supplicant. During the handshaking, the controlled ports keep the > authorized status, until the handshaking fails, then the controlled ports > turn to the unauthorized status. > > The Authenticator uses EAP-Request/Identity as the handshaking request > packet, and the Supplicant uses EAP-Response/Identity as the handshaking > response packet. > > It is recommended to set the range allowed for the handshaking period > (must be configurable) to 5-90s, and its default value to 15s. Moreover, > the handshaking period should be less than the parameter value of > authPeriod when the Supplicant PAE performs re-authentication for the > timer authWhile (see IEEE std 802.1X-2001, 8.5), and the recommended > parameter value of authPeriod is as twice as the handshaking period at > least. > > The maximum times of handshaking should be configurable and the > recommended value is 3. > > The requirements on 802.1X Supplicant: > > The following should be added to the end of the Section 7.7.4 (see the red > below): > > EAP packet format > > When the protocol field of the PPP frame (see IETF RFC 1661) indicates > that the protocol type is C227 (PPP EAP), only one PPP EAP packet is > encapsulated in the Information field of the frame in PPP data link layer. > The format of EAP packet is shown in Figure A-1.Each field is transmitted > from left to right one by one. > > Figure A-1 EAP packet format > > (See EAP Issues list for Figure) > > A.1.1. Code > > The Code field is one octet in length and identifies the type of EAP > packet. EAP Codes are assigned as follows: > > 1 Request > 2 Response > 3 Success > 4 Failure > > A.1.2. Identifier > > The Identifier filed is one octet in length and allows matching of > Response with Request. The Identifier field and System Port together > uniquely identify an authentication exchange. Thus, the use of a single > octet identifier field results in a restriction of 256 authentications per > System Port. > > The operation of the Authenticator PAE determines the value of Identifier > used in the EAP-Request/Identify packets. The Supplicant PAE uses the same > Identifiers in subsequent EAP-Request/Identify packets responding to that > initial frame. The Authenticator PAE uses the same Identifier value in any > re-transmissions of the same request. > > A.1.3. Length > The Length field is two octets in length and indicates the length of the > EAP packet, including the Code, Identifier, Length, and Data fields. > > A.1.4. Data > The Data field is zero or more octets. The format of the Data field is > determined by the Code field. > > Type > > The Type field is one octet and mainly defines various authentication > mechanisms. The Type values in ITEF RFC 2284 include the first six of the > following. As required, the No. 7 and 8 Type values are added into this > standard. The Type values 1~2, 4~7 and 13 apply to the Request and > Response packet, the Type value 3 only applies to the Response packet and > the Type value 8 only applies to the Failure packet. > > 1 Identity > 2 Notification > 3 Nak (Response only) > 4 MD5-Challenge > 5 One-Time Password (OTP) (RFC1938) > 6 Generic Token Card > 7 PAP > 8 CauseCode > > A.1.5. Identity > > The Identity type is used to query the users status. Each Identity type of > Request packet should correspond to an Identity type of Response packet. > > A.1.6. Notification > The Notification type is used to send an on-screen message from the > Authenticator to the Supplicant. The Supplicant should display the message > for the users. If it can not be displayed, it should be recorded into the > log. > > Each Notification type of Request packet should correspond to a > Notification type of Response packet. > > A.1.7. Nak > > The Nak type only applies to the Response packet. When the expected > authentication mechanism in the Request packet is not accepted, the Nak > type of Response packet should be sent. > > A.1.8. MD5-Challenge > > The MD5-Challenge type is similar to the MD5 in CHAP protocol (see IETF > RFC 1994). The MD5-Challenge type of Request packet includes the Challenge > message. Each MD5-Challenge type of Request packet should correspond to an > MD5-Challenge type or a Nak type of Response packet. > > A.1.9. One-Time Password > The One-Time Password type of Request packet includes an OTP Challenge. > Each One-Time Password type of Request packet should correspond to a > One-Time Password type or a Nak type of Response packet. > Refer to IETF RFC 1938 for more information about One-Time Password > System. > > A.1.10. Generic Token Card > > The Generic Token Card type is defined for the users to enter various > Token Card messages. The Generic Token Card type of Request packet > includes an ASCII text message, and the corresponding Generic Card type of > Response packet includes the necessary information related to the Token > Card. Usually the information is read by the users from the Token Card > device and is entered in ASCII text. > > A.1.11. PAP > > The PAP type is similar to the PPP PAP protocol. The difference is that > the PPP PAP must be originated by the Supplicant, while the PAP in EAP can > be originated by the Authenticator. In the Request packet, use the No.7 > type value to originate the PAP authentication and request the password of > the other party. The password is sent in plain text on the network. Each > PAP type of Request packet should correspond to a PAP type or a Nak type > of Response packet. > > A1.12. CauseCode > > The CauseCode type is used to give the failure causes of authentication > for the Supplicant. The CauseCode Values give the failure causes. > > The CauseCode Values include the following eight types: > > 1 Name-Pwd-Failure Incorrect user name and the password > 2 IdleCut Idle cut logoff > 3 TimeCut Time restriction cut off > 4 FlowCut Flow restriction cut off > 5 Supplicant-Logoff Supplicant logoff actively > 6 Supplicant-Restart Supplicant restarting > 7 Reauthen-Failure Re-authentication failure > 8 Other-Failure Other causes of failure > > Tena Tsou > Signalling and Protocol Department, R&D > Huawei Tech. > Tel:86-755-26516939 > tena@huawei.com > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From jari.arkko@piuha.net Thu Nov 7 03:50:44 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 07 Nov 2002 05:50:44 +0200 Subject: [eap] Issue 42: EAP Enhancements References: Message-ID: <3DC9E314.2080106@piuha.net> Is there a particular reason why frequent (re-)authentication couldn't provide the desired functionality? Too costly? On some link-layers, the receipt of a packet signed with keys produced during initial EAP authentication may also be taken as a proof that the peer is still connected. Jari From Pascal.Urien@louveciennes.sema.slb.com Thu Nov 7 08:37:28 2002 From: Pascal.Urien@louveciennes.sema.slb.com (Pascal Urien) Date: Thu, 07 Nov 2002 09:37:28 +0100 Subject: [eap] 5 or 10 mn presentation in Atlanta meeting Message-ID: <4.3.2.7.0.20021107092844.00c49f00@slv-smtp> --Boundary_(ID_h28zwtHErP4Fp7V+shgGUQ) Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Dear Sirs, Could you allocate me a 5/10 mn presentation about = http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt (eap support in smartcard) During the next eap working group in Atlanta Regards. Pascal Urien -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 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_h28zwtHErP4Fp7V+shgGUQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear Sirs,

   Could you allocate me a 5/10 mn presentation about

            = ; http://www.ietf.org/internet-drafts/draft-urien-eap-smartc= ard-00.txt
            = ; (eap support in smartcard)

   During the next  eap working group in Atlanta

Regards.
Pascal Urien
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-= *-*-*-*-*-*-
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_h28zwtHErP4Fp7V+shgGUQ)-- From iesg-secretary@ietf.org Thu Nov 7 20:11:40 2002 From: iesg-secretary@ietf.org (The IESG) Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [eap] Note Well Statement Message-ID: <200211072011.PAA08965@ietf.org> >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From aboba@internaut.com Thu Nov 7 21:12:40 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 7 Nov 2002 13:12:40 -0800 (PST) Subject: [eap] Strawman agenda for IETF 55, Take 4 Message-ID: Here is take 4 of 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 EAP Design Team Report, Jari Arkko (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (10 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP TLV method, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt Tuesday November 19 1700-1800 EAP security (cont'd) EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt EAP IANA considerations, Bernard Aboba (10 minutes) EAP Roadmap Discussion (10 minutes) Methods (30 minutes) Short (!!) method presentations can go here. Presentations should focus on RFC 2284bis issues encountered during method development, such as usage of NAK/Notification/Identity, uses of sequences or tunnels, acknowledge & protected success/failure, security issues, etc. If you want to present, please send mail to the Jari or Bernard. From aboba@internaut.com Fri Nov 8 15:02:51 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 07:02:51 -0800 (PST) Subject: [eap] Tentative EAP WG agenda for IETF 55 Message-ID: Extensible Authentication Protocol WG (EAP) IETF 55, Atlanta, GA CHAIRS: Bernard Aboba Jari Arkko AGENDA Monday, November 18 1530 - 1730 Preliminaries (10 minutes) Bluesheets Minutes Document Status EAP Design Team Report, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP TLV method, Glen Zorn (5 minutes) http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Tuesday November 19 1700-1800 EAP security (cont'd) EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt EAP Roadmap Discussion (10 minutes) Methods discussion - anyone interested in this?? No takers so far. From aboba@internaut.com Fri Nov 8 15:08:23 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 07:08:23 -0800 (PST) Subject: [eap] Methods? Message-ID: We had reserved some time on the IETF 55 agenda for methods discussion. The intention was to provide space for SHORT (e.g. 2-3 minute) presentations on EAP methods. The intent is to provide some basic information on the method, plus problems or questions encountered relative to RFC 2284. So far, we don't have any takers. If you're interested in presenting, send mail. From aboba@internaut.com Fri Nov 8 15:18:38 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 07:18:38 -0800 (PST) Subject: [eap] Second state machine draft Message-ID: ---------- Forwarded message ---------- Date: Fri, 8 Nov 2002 11:17:56 -0500 (EST) From: Nick Petroni To: eap-design@internaut.com Cc: Chuk Yang Seng , Bryan D. Payne Subject: [eap-design] Second draft state machine A second draft of our state machine document can be found at http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps. There is a corresponding ascii version, as required, http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt, but this does not contain the diagrams. Major changes: 1. adoption of 802.1x notational convention 2. Change in representation of Method state machine Thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni From aboba@internaut.com Fri Nov 8 15:29:45 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 07:29:45 -0800 (PST) Subject: [eap] Tentative EAP WG agenda for IETF 55, Take 5 Message-ID: Extensible Authentication Protocol WG (EAP) IETF 55, Atlanta, GA CHAIRS: Bernard Aboba Jari Arkko AGENDA Monday, November 18 1530 - 1730 Preliminaries (10 minutes) Bluesheets Minutes Document Status EAP Design Team Report, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP TLV method, Glen Zorn (5 minutes) http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt Tuesday November 19 1700-1800 EAP Methods Smart card support, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt EAP SIM, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-07.txt EAP AKA, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-aka-06.txt EAP Roadmap EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt EAP Roadmap Discussion (10 minutes) From salga@bell-labs.com Fri Nov 8 19:03:15 2002 From: salga@bell-labs.com (Luca Salgarelli) Date: 08 Nov 2002 14:03:15 -0500 Subject: [eap] Methods? In-Reply-To: References: Message-ID: <1036782196.14178.53.camel@valjean> Bernard, I thought that we also would reserve some time to discuss the fact that EAP methods are not in the current charter. Can we do that? Thanks Luca On Fri, 2002-11-08 at 10:08, Bernard Aboba wrote: > We had reserved some time on the IETF 55 agenda for methods discussion. > The intention was to provide space for SHORT (e.g. 2-3 minute) > presentations on EAP methods. The intent is to provide some basic > information on the method, plus problems or questions > encountered relative to RFC 2284. > > So far, we don't have any takers. If you're interested in presenting, send > mail. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Sat Nov 9 00:24:13 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 16:24:13 -0800 (PST) Subject: [eap] Methods? In-Reply-To: <1036782196.14178.53.camel@valjean> Message-ID: Yes, time is set aside for that under "Roadmap". On 8 Nov 2002, Luca Salgarelli wrote: > Bernard, > > I thought that we also would reserve some time to discuss the fact that > EAP methods are not in the current charter. Can we do that? > > Thanks > Luca From aboba@internaut.com Sat Nov 9 00:50:37 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 8 Nov 2002 16:50:37 -0800 (PST) Subject: [eap] Tentative EAP WG agenda for IETF 55, Take 6 Message-ID: Extensible Authentication Protocol WG (EAP) IETF 55, Atlanta, GA CHAIRS: Bernard Aboba Jari Arkko AGENDA Monday, November 18 1530 - 1730 Preliminaries (10 minutes) Bluesheets Minutes Document Status EAP Design Team Report, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP TLV method, Glen Zorn (5 minutes) http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt Tuesday November 19 1700-1800 EAP Roadmap EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt EAP Roadmap Discussion (10 minutes) EAP Methods Smart card support, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt EAP SIM GMM, Victor Lortz (5 minutes) http://www.ietf.org/internet-drafts/draft-buckley-pppext-eap-sim-gmm-00.txt EAP SIM, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-07.txt EAP AKA, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-aka-06.txt From anuraguxa@iwavesystems.com Mon Nov 11 05:24:23 2002 From: anuraguxa@iwavesystems.com (Anurag Uxa) Date: Mon, 11 Nov 2002 10:54:23 +0530 Subject: [eap] EAP- AKA query Message-ID: <009a01c28942$9b7e0790$b202a8c0@iwave120> This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C28970.B22AB140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all =20 I am going to implement ppp authentication for mobile IPv6 = communication. I have implemented EAP ( MD5-Challenge ). But i am not able to understand about AKA , How can i use PPP message = format with AKA? If it is like EAP what is protocol field and length and = optional field. USIM will work like a client .what should be the fuctionality of = authenticator(server)? The use of the AKA also as a secure PPP authentication method in devices = that already contain an USIM.=20 AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart = card like device.=20 Five security feature groups are defined. Each of these feature groups = meets certain threats and accomplishes certain security objectives: - Network access security : the set of security features that provide = users with secure access to 3G services, and which in particular protect = against attacks on the (radio) access link; - Network domain security: the set of security features that enable = nodes in the provider domain to securely exchange signalling data, and = protect against attacks on the wireline network; - User domain security : the set of security features that secure access = to mobile stations; - Application domain security : the set of security features that enable = applications in the user and in the provider domain to securely exchange = messages; - Visibility and configurability of security (V): the set of features = that enables the user to inform himself whether a security feature is in = operation or not and whether the use and provision of services should = depend on the security feature. Thanks Regards Anurag Uxa iWave systems Technologies Pvt. Ltd. Bangalore ph.6786243/5 extn :205 www.iwavesystems.com DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_0097_01C28970.B22AB140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Dear all
 
 =20

I am going to implement ppp = authentication for=20 mobile IPv6 communication. I have implemented EAP ( MD5-Challenge=20 ).

But i am not able = to understand=20 about AKA , How can i use PPP message format with AKA? If it is like EAP = what is=20 protocol field and length and optional field.

USIM will work like a client .what = should be the=20 fuctionality of authenticator(server)?

 

 

The use of the AKA also = as a secure=20 PPP authentication method in devices that already contain an USIM. =

AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart card like device.=20

Five security feature groups are defined. Each = of these=20 feature groups meets certain threats and accomplishes certain security=20 objectives:

- Network access = security :=20 the set of security features that provide users with secure access to 3G = services, and which in particular protect against attacks on the (radio) = access=20 link;

- Network domain = security:=20 the set of security features that enable nodes in the provider domain to = securely exchange signalling data, and protect against attacks on the = wireline=20 network;

- User domain = security : the=20 set of security features that secure access to mobile=20 stations;

- Application = domain=20 security : the set of security features that enable = applications in the=20 user and in the provider domain to securely exchange=20 messages;

- Visibility and = configurability=20 of security (V): the set of features that enables the user to inform = himself=20 whether a security feature is in operation or not and whether the use = and=20 provision of services should depend on the security=20 feature.

 

 
 
 
 
 
Thanks
 
 
Regards
Anurag Uxa
iWave systems = Technologies Pvt.=20 Ltd.
Bangalore
ph.6786243/5 extn :205
www.iwavesystems.com
 

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_0097_01C28970.B22AB140-- From jari.arkko@piuha.net Mon Nov 11 05:10:13 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 11 Nov 2002 07:10:13 +0200 Subject: [eap] EAP- AKA query References: <009a01c28942$9b7e0790$b202a8c0@iwave120> Message-ID: <3DCF3BB5.5080100@piuha.net> Anurag Uxa wrote: > I am going to implement ppp authentication for mobile IPv6 > communication. I have implemented EAP ( MD5-Challenge ). > > But i am not able to understand about AKA , How can i use PPP message > format with AKA? If it is like EAP what is protocol field and length and > optional field. I think draft-arkko-pppext-eap-aka-06.txt answers most of your questions. EAP AKA is an authentication method, similar to MD5 Challenge, under the general EAP protocol framework. For message format see Section 8 of the above draft. EAP AKA type number is 23. Length depends on the particular message. Are you really using PPP or running EAP over something else, e.g. PANA? If you are only using EAP then you don't need PPP protocol fields etc. If there's something unclear in the documents let the authors or the list know. Hope this helps, Jari From jrv@interlinknetworks.com Wed Nov 13 17:46:22 2002 From: jrv@interlinknetworks.com (John R. Vollbrecht) Date: Wed, 13 Nov 2002 12:46:22 -0500 Subject: [eap] State Machines for EAP Peer and Authenticator Message-ID: <3DD28FED.A134131D@interlinknetworks.com> Attached is a draft for EAP Peer and Authenticator state machines that have been discussed in the EAP design team conference calls. We have added some timer events to what was discussed on the conference calls to show retransmission characteristics. The draft is available online at http://ext.interlinknetworks.com/dspence/draft-vollbrecht-eap-state-00c.txt I expect this will be discussed in the EAP wg session next week in Atlanta. John From pascal.urien@louveciennes.sema.slb.com Fri Nov 15 16:28:12 2002 From: pascal.urien@louveciennes.sema.slb.com (pascal urien) Date: Fri, 15 Nov 2002 18:28:12 +0200 Subject: [eap] Short presentation about "eap support in smartcard" Message-ID: <5.1.0.14.0.20021115182736.024d1080@slv-smtp> --Boundary_(ID_BDNOpGSDnjkOSqIRiKfSrw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Dear sirs, Please find enclose a brief presentation about draft-urien-eap-smartcard-00.txt (eap support in smartcards) Regards. Pascal Urien --Boundary_(ID_BDNOpGSDnjkOSqIRiKfSrw) Content-type: application/zip; name=eap-smartcard.ZIP; x-mac-type=705A4950; x-mac-creator=705A4950 Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=eap-smartcard.ZIP UEsDBBQAAAAIAPCSby0I9zyvJFEAAAAYAQASAAAAZWFwLXNtYXJ0Y2FyZDEucHB0 7Fx5cF3ldT/3vfsWPT3pSbJlS0a25QVsEwzXQILBAQwEKAlpM7RjyCQpmJ00EBJo Mk2Xoe10SCeTNn+1SZtQskACWZrSFhKatAEPxKWADWYzwbsWW7ZlyVrfevo757uf 7n1PT5ZsS3ac8Gm+t9z7fec753d+Z7lvxt68qXHnN/9t3i6qGJdQlEpcQ/HQtQjm 39ovDYT7zPLRvj+I+UVMfnecMiNDe6NdDxE5tC+6HL57YA7RTvj27zEvayGK4VrK 932UZJ0OJ0OHo5fjwjm0MdODCx69mnH9dURPZ0RWS3tbe5Jne2v4Y5z0Ul7aq/ca vE52eSktp4/Rx+lP6WbexQ1Y/6gI9SJemus5783j03ghO/zP3te9olfyvuE95MW8 gtfaPr+9hpu9i/kTXOPVenVexmv0fkxe+7nt57VHF+3kGF/mXeFd6V3tXePd4v21 9zfeg97fed/0vu094n3Xe8zb4O3xOr1ur9cb8oa9RXQ6raCz6Gy6iNbQpfQJ+nNa z7fwrXwb38F38l38Sf4j/hTfzffwp/lefoj/BYi9nvgzheGpzAfw+gd0F91Nt9F9 1E6/i/fP4/06+jSurad7cL/tyZt1Ln/iZhrdEvWuxXsS1+X9L16LekQugsnIuga7 7sW+W+h+fDsWWfHF7b6sy+iz0Gw9fUo9cmyyPF/W9ZB0D91Bt/rv9+Ha0ciKUDyy 1pd1Lf0x7LsLstZDo99XCSLvaPQi+k7GZKYIZBA9kknqN1korvl+ZgFeeaHwd62h JN3p3OlsjmyOrHZXuw/HHgaxH8sIsxMqJQ3yrqVvZ0SDGHHxUrwDSmhphn0nX568 MB/SKyaSWuSjo9up3Wk3gRKT9b4G+HxT9Kao/fyA+4AEDN1IHYknPy+fOhM2gjLU lfiWXns6I3KvAmo30ofh0xvAkQ+Dr9fj8zqSyBHL7fd2fJf952J2J26ChOuuueqq G/B+/WXrrrz97vvbG1TJCC1eh1x9g6Pcu3X9/etn30PvjlN0OJMvGTdMxT72+1NZ cywyZsKW8KiUP1M6Ho0d04F1eEzX2unWayrjWPx/PGMm7T9e2eExnZybTp8d6cxq 947n7BPNjZke1bAIX5tu/I5lnCgdqsmczN9Hg1X4/nTUraMdx1OjjjR+HfhwssaJ tr1ynEgsjtfWo9X11zXXzqTPT4bNv83xe6qNmfTVkWTPtM/e5cTUxomM1an4ZKb1 mWlenKz6/ZvA95m0YSK/nOx+61Qfx4rfyeLrdJ17IvWfrrMme7Y8meNU6IGPNYec mBwzPVZOVcp0nHYyc+906P/b1GNW+mo68/504/ibUtMnwuVo8ZouPE5UbjiRz6RH Omuqz68Ojbd5MgyO1cZTod8SHU/1+jAzY2qozKyvAukW38r3qYwTXfumq/5UG9Vk hWPameT7kUYY28o50VozyqVPdtZU9bGDeeqrrV6T7zArJ7LvaIYzwbuMsOyZyBFT zftTG9MTKZPZOTPxeGSplX6uHqMzk8WrnRXWZ3IOBsyqxrHyUe1OZQQF352KGVwN PlfiNpX8UG1UO6u6tuN9VRo7a7ynKuVGQu+R0PfwsDInmtVsm0x++F7lqOZva894 e4NvlbaZOR7xif1S7kvHfw3rG9a/Gk4BVsxTxWgifKqdIWMi/e3ZR/L3+Flus5Vf Csmr1P9obbCjmp7BdMbJrcaVsEy7fiIMquFeTffIuOlMaEM1LKpNKz88jtaXlXsr sZiMKxaDsM4TYVNNfvkM4sBeCcsMyyvXwUSorLa7Kjky0ZgKJpXX7PXwO1H1/eER vmcwsPoa28fr4IztG6+j2WtkBNOeFJZrkTEz4s9yjwayLZoGbQfvToVHx/sskF8K yQ5XuTBOVosoWT+Z3dXsDOQG094b79fKXQHG5aOSZ9X9fyTuVPN7OUeDFZW8NXpN nMuq8Za5XE7YI8XQ2VZ++Jyw3MozZVSLq2o22VGpW4B1pe6Ov9/6rdx/5TLDXJgo 0sOrrZzyrGHuVa42csOxUik7bKvF03KsEsfwtPID1gW+D16dsTOCk8fHVhhH+25t LYZiqzx+g1FuZ2BhNbyr+baaD2VGdQaZQ9aWxvaXx22An+PjZ/6MzDBi47FkX56V GVwJtLf6iU6uPyMUHuFcRFTAzPuzWIZBEKHW7ujYNHeCDDg+9oq+ntYbVherT1Dj zTTyHNXH6lTwdRJZBUwrk8jEgvxbs7i+O6pTRN8j+uf4kVL0ZRp5ph8Ma20jLqpT 9HNUR4N5ObPD/stDVs7Xy3rE8jPAy/HlGZ1E66LOcB0w+oRfg9xvWVLudasRj+FT nt+sLLPa4mJ1Md+DehGsLXK4Xza7LS6WQ2E+hnNkoMd4vodzvcXYyHTK5MmweywP rNzAnuBs17fLct3IDHKYWGeQM1pZvxU50LnA1tMRshk2qjOQYu0PMDFsKPqWumNn lZRxUf9zIcTVgvIwYEbRRzXms1V2yt0YWd+afSKryGZajxX9WLAcyPk8j/geKbBB 1qUgo7gqm8dG1OeYyUHmPpHB3F7LQ2Y25Ie87xsTx0a2WBH3fSD7bFzbuHV8HhfZ YCLsl798SA//aJWTUOyjkO/iu/HuKHZlIUnsHMHqEbbYm8zg4r1GZ4ljZHJNTCUa XJwxXJwxG2RnroILMmOqg3mPY18K7zEq559gMqy4G0xybLhhOUhk4iZOlpeOn/ec sVg1fAowLbHNJUaOrSMRX4Y5P8iTWWCS96/Zquiqrjbe9R83+n41/GTFvQC7C8oo eR3xcSipl8xpMR978YRgUONjYhhrtM37+1n1LnHWx9Jga/SJ+taX2PW9GiHrDZNj ixolYklUI7Pgx5CJNJEV9eOx5GdDoqBu2VyV831n2GLsj+sM6pb5HBnbZ/1fYJNp ivgm04W0uB+dJq+Y6iU2iETxqqwqaNRH1VZhuK0ZBTZVxyVjV0RXmgiSMyO+zKJa LDZFx3SKhXxtc4Hrr3d9LlveyXrh4Sjb+m1GDXancTeusVDihJ5gcRB9Y5ARw3qX bJ0k36+GG3k2q4xvSxzUGtElSSbPDGNVTiMv5mNhEBBMs5ARh3YJZWlOMTD50thS Bxzlr+hHiMlbEb82RcZi3Fhc9JlW4FHIHdBMIl5w1NtiXcSXIPtTPmaG1yW2Wd3E sjlHrqSwqgasLkLLPKbkmAH1UgGyR/A6gNjox2mHIWlIOZJQJoplEhG1+pcAIlHN WkbvYba12/F5WVI8hQspzHrf21m21cZVbxm5EerzOemS9YaJC+GOxHYj1iVxnmhj MnpEuW/r0wDWCv6yIjaWGRyfiWJ3FHa7ZGu/YWze96LJB6NsuG9yYFRjydZO29eM wqpBfwp2EbVEWGQyi7C7FrMBV9I+l23PZvOS8LdfdS6xwSqKay4NYQq/omT0TZGp mCXl5ijXYabVoiJLPAwpoi7WJEkiYJiTynFhSD2u1Pv7c4qjIFdk+38UjPo+E37b /7tCeHDI56BcS5OpASU2tUzsyeg18bkLDFxlWAp+SVBMs9mwZpMctMhijsAnI8qo LK6J5xqAQJJc9ZKsiOr3uKI4AksPK44EX5Hm35LqY+qmrBIMRecBvV5SDdI4u0aj 1XQ9Sdgp+IsM4dFhzGGNRJNVRnBun19To5rzJTaM/4UVtVg1G3calJ2mUtmeW3wl ew/iHJEpWNRoNJpKJtnB6G4q/iDWDfn1Iqr2iJ8ljyQ0YyWBXlzzq6NeqcFswJlp rfx5tjkvqoyULC0yc8DTdNQmb0Yo5+cs0SehuojNeZyd16hyKK1IFWEdgwXig3qs rdXoGMBZQ5oda0nwMyMLiYKJZDLhRD++9/n8iCo/HUqqDkXNhOLfpGrgap7Ns+Gl oCTImDxhqn1SNRmBJiNqcx1W1/kY59W/ccwk7sT1fOGV2DLqd4EmLkxNEGYkgHhK uWQqrtRy+V6nPjQdr2QCyXEJlTYMeVk2PDK1oQ+aHMQcxArROaGSR3FnVP0xC++N fo0w3W4tTkortpIbs2yeyKQWJZWdQ2C+eEEQy2qlPazTVU2E9wm12FRwydMNxJo/ SpoDRzV/usoMF7olqZcz2JvBrgbsqFVGCUqz6TD068OqfvCjDycPsumfTc0S7woy jTixCfq6eA/quavxvBfrurFj1I//GjI9fhKWzcUZ83FWI5lcJNES0wxIODlOHZj7 oHkWKxzoVgBiJu+OcDM8mYFeBTDoEPAY0AwhcZBCvhHtk/BTguYD81a816llJRYp sn8YtnThtUfxNJVqWPOdRH4K9kSoXqO/gFWjmi8FN6k1B8FsqS2Ost/VPOVCeh2s a8M5rRovefXTKAs7h6Af8z6csV+7CNHHweo8m2oifB3RfkMitBf3BzlO9pnTdFKi VYpaVLcazY4RrVwDyrJh+OeAcs888ya0njtaZ1y12eAqqwc1qtKa47MqIaU+S2ns mh5G6m4jdJoFhiTgDcFrlLMqgzWyhdMZtbRJq5V9npBsZWzqw3sXm0oX1yov1T0D veqAU4LaSf4HkBGN6lG1fFC7h93Y08M28+Y0d0gcHYZvmrXjMT2wZFDJUXMgI4J9 naqX2BTFKdIfiA+I5mBlG+4LBtLFdLAgH9PMJR3JsMpJaoyLz/dh/z6W58kRXD0A Of2aYYQjrbgagwaDuDoANkntbsGJguCoynRxdpabaFA506E2jGr2kQ7oAGzo5lrt lqT2DmgGqVWps3F2s/qkSX3dChlprQoiJ6JaSIXs1zqR0gifg6uLNfcIPs2aHwdx pvBnD+SKFnOpB2cdYNN7CDOywEy6G+mBm7TSSb2pJ5GxABxt9TNIv4+wsG8P7myB FnvgG4ZfY8CxyJL59vNS+OdMmgsmtIMdZygnMlqBmoFkAREqp3cprgc0KwxDr0Gt GTnodlD/BxexRrJi2u84Je57od8AS+0a0G4jB4kR5U0P7BIppjOWbi+vOWAe9GnX ay3YLdxoUdt6gMY2zS87+DR6E1e3Y/cB+EY63QJwmwXrF2O2IKNlaClkiDcHNfr6 cX9A8+xerW0xrMixxHwv8uQenCM9qUSKaDGMHNFAu4HEbujfrcwQ7VOa/+YCiVbY vBTf6rX7YY0BOW8YNndDRh/+TJ+U1k6iCAxNRSF4UvJdj/bVSfVdk/I3DWkJWojP 83XlCIvtEaAaI+HwbHisDhpKDdoFeb/S18PKyQHwp0/7HMGhHdqepv6TvmEJ5Itv xds1QFdq5z7s2QodOyCjCWtqsEu6gSbY1azZpYXegb/3I5qLvJ/Nk6+wqYcXQXoD LYcmK5Gr48pRyWydyCc9kFdLr7BBV7QegEe7eBmyR1zZJRVvG/ArQfc2eg2SB7mD ze8ji+FT6Q+6uF3z1EqcMQ9n7MfKw7C9EdiJTZvgZ/HOfGi7BPeL8J/0+guAfRos eRF5bwM4M8pbocUBICSdRit5WH+J5suVOLWN5uGMJbQL7MjQr9TuXTilB/q5tBE6 5MCDhbArQsKrFbCxiZapTbPoJcjv41/CQz9FdtgKP0j16OP3ac99Lu3kK2DjAvhT qoRothQReQh+2cxi0S+BRBe/Cf02s+SfDj4HvmuGZlLx26DlEuB3iN9DL+NuD3cD 6QL2ZWC5ZK+tQEdqfLM+O7QoEnE9cTfL08t+6CjxUQs/Sn3ZztLXHYS3xZ4G7JoP axyctI/lN5khjYYhsFvy9jLgdRHk1WuV6gJXt3Mv4uD/8OlV2BpB3KSwPgcNhE+z 9WlsDvYvJqmFi6Cb+GQQawdRP6VS74UvO7WuN9AKcGmB5toI5utg+17eCTS2aaWS ii5xdz50Ww7engu5UrOlhu7i99IOPhtWLsSeRZAlGWU/zt0EZsgV4eRe4LUfvKql 5+GXrUD8BZZa2Qz/tdLlsPtq6LyaTqfzoW83LHwLKP0cTN4CHV7l17F/BFg2YH2R VyEu03QeNL4AvGkFa+tx2nz4TKrfL6Dx00B/C3Loi/DKS2yeU9bidQ1yy5nQdw30 XYkTpUvaDsyyuDqC+TZYsJOfhb1boN/T0PhF6LAXLLkM3rkOdl8MlN4PZqzQ6nqI n0eGEdu3Af/XgObzYMQQLD4NHMmAe2fi5FXwydnAawe8tRUa7oYH9kHXHs3EBX4/ 7s2mvPbIkr9T8PNOnLkL6OXBmwjJM2VCnxPPhc/aIUGyHsGaBOLpLVjxC2DwCs7v ZMn3kl2SQKgArCL0XuDcBj4s8Tv/DtzbAS6+Aw4d4IJWnxrtiXI4TSJ+BP49oD1K n/aGKcSbozlD+pxlYJswfJnWpbn6LCsyujVa80DQVOcC9GjQLqkLeu5S7RLQvUd7 7BacuRJ350PmLBJZayBHqngtpnimF3r8N/yzjfcgUpgPacUf0ax6GiJZ4qQJElrx Oh/Zox+npsBR0y/noP8eeEciqY2k1x4ABwdV+kro6mr9cIFKDbQ8wJvh6U7Nl72w OovvLdi1CCtWob5dgBUt4FCSPgQbm4FhO/0c0bAN+u3gp9g869cB623g/kH4/gz4 oB5a7Oa3odUWPh3efQeIPIO4y8K7DZC2HxgthcYfR747D347yBuwIgsdVoC7q7E2 DVuWKpc28s+AymN8FuKzBszrh9+XIAIW0A349js4LU0XIo6kAko+i9MT0JNRl14C /l3QZSX48BHIHQQOPdo594LrvfwoPJlDvrtan2xnQcoF9Ie0iC4FEptZeijpOX7K P+Hv8z/hk3RReWA1AHYvpmsRF8uhQSPi+gJgGYMmb2Pf8zjxMF9DEiGva7ZcDSTn 4f4G4PYWMv8gbNkIKc/Bo9IJtgGFQ8hpGchfg70NWOnA9hWIVMmsL8NDO/hqMPB9 8LUwfy98sgg7JQa6WXYsxb1megMy3ka+GIAf34GNT8ILsyBjFUl1leezuagJ0gVv Aj45eHk5nYXs08uS6WvpSni8AZVkEOdlwHsXMr+Ee99j0dEBj6VKpmgdPH4t7JiH SGyFdy/HLGjnvQY7rkcWvgZaS7XZgUz6OG/ih/m/gGMOzCxp93AmNF6J7HIW7DgD e+aCjxkSJnVqZd6rvckuMKMXn6W/W6y/MwzhvC6cO6wc26tPr22IMUHWhY+lh5dO iGF3CjIvhE0X6rNlA/g2Vzn0CLLR4xqRw1pHotD1PPXZJmDejYreCMRWQU4L8sXl QPlK8F5qbQewziJn/QScf4rlN6tGZJshcGU71kRhyVx6Fhr8AOi9iUj5d1j8AmL3 PJwuDD0Ha78ArtxF8mzZAe/188tY+2Wg8l1kR9FzKUn+2YbdeXxPIxakc5+FrmGF PsutwM4PIWPM0me+Pr0n3HkC+yUTyvcYeHI6ouEi5csz8MyPYHcX/BADPyS278Up X0AntAosnoOsIs/ZTwONJ5H5O5BVn4Psn4ERNdC4BWcSUDwbDF+KdZtgeSf/B1j8 I/i4CcybR5+EhfV0J/2YP4h8LHHYSo+x9MPfQqXcBNREjqApzwMevaq/F76FaImC b/WQvY+vg42r6Aq6EZngakTGG7DkVX4N0rr5e4iQH4APg5C0Gyjsh7cvgYSLEIFS 6QW100l+15gPv58PTn8A5yyn7frkL/3jE6htzzDpL0ldLL+7tEHzc7RvEFa/Bz7e DW89hz95wnSQDZqR124Gn2+hO/B5HlbsgOX/y//If4mM8DlI6oZ3F+KkdvoI/R4w uAhXdnKbPgWu1p5oFbxxsXL8FXx7Hh6Yh9dO/hr/J3goT4bSYxf5o3Q/JNyO/a8g Sp7lN/iHqAKfY/nt6zr6E8j/IDRaB51vJqkqX8XdxxEjb/E/8Hf4Syx9+2dwyix4 cy49iDhfC/5t4G8Ak9mQ2kb/CpwX01fg8Y8CqUeB1zCyXxewvQ26yO/Ea8GVF+C1 i6HHFyFvA/b+EH52EP2fATNeBKLPgROXI5PI//z5ZbD/OaD7dcTdOYiIZ/iz/BX4 dJn+hjeb/ofvhv13k/zfmvcBrcWI7nUaPT38EGL9dkTYRiC/HD7bhr7rr2D3Nui8 Ea//T915wEdVpQ3/uZNEUpmQoKIgjoAKKBgIIiihg7CIRspiW0gIEwiSYjKhqEhU LCtiA9HoKtg7qAi23VXsJSq6KqyKom5si0tw3bVyz/t/bkmGmwTcxu/7Jsyce8o9 Ty/n3DPD63iizlBxEBphzAm8I6Lx5zN6w/I79EzzpCNlskyS0VJJrQS668meroQb V0PzRchccR6OpzkJvvxKxsvpRI00/c1beP8lEN8Bl3fNg2YglnYUep4iL5KzjEei g+UBRmwGu43o4IvMGJFHyEOecfb9IsTDjnIDmnMq0k2XM/AEWXIdcnyDv6PkbO55 AOnuYPRX5jnnqovoPs57ZKQbzelgMwBJHoWnHCCLsLLH0e7TseY6sxZfeSkZzP3m XnnSnCS6t3YpWC6WC8nmR8LLb5gxAevT3ZLN8PpiuDMefV6EpO7CQiYggeuBuYoo /SZe8hR0bzC8ew3bHwOv22Ntr+DLTgH/Omh63pyDNU3FQx2Ejr2ExV4G/67EI7yA 1/4OHQ/LJeTBvek9AZlsQQ9Go7lvErWeMJqDaqZ3DLo5CY+eJ3OJZFvxJTvQ0FQy U9tuy6yHYw8HomEZslk0nn2IFRgnm3oCjXsCzTiE2fOQ1k/o1CWyAt5H0YmlcPst 82ui7JX4rDPlROynN9j+YDRe3Q4nOoo4GXwGGqLeI9/ZufsUvP6EHW0xk5HLaiia B95f4bPuQeuHEfGq4Lvu7V4PxQeKOHs1is84+j7h6kni1OtEypvQhD/BqePkZub9 zMzG/xQw9m1zPrDny0qoudBMQv9WY5GXm3lI7GG53eHLPnBtDVyaBtxHkapK5Hby lo7wazIyGYoWbMWP95IrzBooTcEfxuC4yDl4nyfNLc5OTS+gXo62HoQN9UXfnoN3 85DZdDT6Yex6JH/34rcr8U0Xowl1RvcLhqNdx0kRedrX5AMF2MhrxLtSbPNMLPhB /Ot04tJWek5yLCwVn70O73OveQ8+dYMnB5KhjkJL+iLNzdjWh1iC6l0p/mi0zMCv XYHM+gPxUTTlNuLnAqD9nZGDwb4HNjTCybFfBps/QHkPfMps9O0qZzUyFt09AKme LhpN9KnFe+jxYU7W+IVRH3UkMtsEprXw9X20tMEsR8PWyHIyjgFyHvZ0LXguMjVm AVqdR8TPk/Vwdxxyu5MY8RwafBB0P4m31P2eEaLPyTvC25MkCownTSF4toPuRGzk VNY4j+M/XiTrqGV8NXI7EG8wDt5o/jkMj6W7KDuQ9wlY8Cfo/wa42BVbeA2uFcC1 PsjsGtqz8ZKXE/83GeVDT8Z+YuaQvY8lj9mO1mUhvW34uDA6cAb6pj5Gc+rNSGop WNt4ijXgnsnfFcj8ACg7mQh5A35gDVwd5Ty7uBaeTCCejsdKnzeaf1SYaXKKuRrf OwjNOBbtFGxFs9I6cx80aDzsJnPQ/NHwNgxtf0SnxwP7MqOZ3zD8wZvmITCdQiZs 0LIfTbnchE0NQpd6omW95Xx80NVoxKdEoQI5l3ykGn+cTK5YK+tMPfbwDlDrzO/k LPhwIHPcjXf7DXnKCjTqPnDbBykuBI95ZMzTwT1TXsE2l8LX3nIl0jhCCuHfg1Ca jM1V4Nd6o81voFVdnJVgL7zFWjj2Lrl5Ndy7kYh4IrAvIfY/i8UvMb+VY5HnfKS1 EE29jf678Eo9kMNENPhR+H0qNP+MnIvB6xjs6Drscas51FpJLR25rMaTXimWORkt 2mQ6Yh1vmu32GrkFv5kgHyKBj00PazK2+TqaeyVx6xKZimYPdJ689OFzvemPPGqg 7Ecznoi2HF73lrPxUmGkebucgbZEiGVfgskiylOx4rXo1W/xf/fAmWx0cS5yuR1p vIhNPE/vF9QGAD9CNnahKSYPuRf+byO6bDaPIGkD9mcS3cbpjrCpxrbG4s3Phe9t yWJGEQfHm7PgRD72oju1iXIrOr/D3EFcSoG3l5lRRIYDiFFr8H5difKjsRqNWhdT OwBKhoj+driFzf4OHLeZ2VB+LfCGQVdb5JqLjm52svK7kedQfE0yceFX8hvi03rs 6WJscQ7RscycB9V5RKQOcpmzJ3sMWcJ86AlLDTNohD3K+hLt742tXiDf2JebQ4kD deZG1oSPmpXY8w5y5LlkqofCjzuw5XR48w98b4x4cDyUn4nffst0I0e6D7/ziJmM BYsswwLr8ZUfItcnsfNiLHArlqJ7PeOtMOP+jv+sh3tvmUuAdweZxMeMfR6sC5z9 9QngdDNe5H5R77wQDaoyDyHhTXBCPd8DZCPfm3UyGzm+CJdC8hc7BSl+BozTZZ6s hKurseQKLPVJsP8UHv5G8o1y9SKzDF+30RSAexmRZgsa+hne4jyyv/ux3KeR7lTy p8FmHN5nJ1JKwDt9i1ebgv8Zj4SHEUnvxeO+hLVPRE8G4jcM/O+KPb0Pjf+wx5gf 7RK07TxiKBmq9RyWvD/aEJFprMQNc5Ug9bXg9Qw6c4PuE9qzZIv9orkYfnwkc81f ZJnpZX2Kdn9lMrCtA8xarGezlFhfg+9V5mP8Qj96fwsVR4DxI3DuDTlXbsLSb1Kf QtbZ2TxA3EwmfsyUTla6PAa1K/BLxh5vesL/8djvdiLmGVB0KFb2o70NHn1sSvBk o/FjU619uO9LPM6+5jhiweV2ndnPib5JcoJ1GTP1QBu+MZPM06zS22AdfeRC9PJm MD0Ov1tGTJqC7o+EJt257otMumNLx5DHX2pWEdXexNK6SEfrK+LjOPzVeWYftHc+ evErcyv++Gui0CVY0K3k3+3wWK/hgx83XdGyrfiFLrIaH/wG3DvTvAzvivAS3eHq yda1xLQIdE8h04vgX66A0keg8Aa5hsh2ER50Ct7hazMaaBvxtH0lZtY4WdwzjgTf MdfjZ16Db5VoxYtw93o06C9kfhfCtxXEjkvg3lQy/ZXwYCSZ9DKphd5tRP9cyQbC 20TwJUSqI8js1pFlPUnufQirzxq7P35/NdqSJj9aBs/xvbkZKv9K9JuA3mWQv8fs h+BfARnan80XxKfZ2PAPwDkLS1yAhsw187HGNWSaZdjh7UTBm5DhOUC7EK+yAVy7 yktIcDgcaCcPyXI04h2sYD7+M5dMcC3+ZgAR9SLgnYTHmIrmDsVD/5E84mz8Zwd8 ykbyxAvJH1fhT/6JX99iSs0/7dPkZ3s6OdVTRL4V6M5M7DTHyiBuvUk0+i2e4FXn +WEbIsY42WGfKUOxk854gi5k1kdYT8hFzPQGkj0dTAeyMhmI3g5DNzKxv2Fk1PrU O83sS6y8gjxuE5nSDOh+T26Er53Q743IazH57BlmFZr6LDxdgFTPIpvUffaOkgVf XiEnKEAifaz9oKodK/Aocn4dOSdwZUyyWY4eLSE6dJRNjLyWeLwef1ZNDL6WuLfd JnMAv2/xS/lwbyoZ0zPI536ymvfM/fB9qMwE2qFQtw0dPxaPMxpPcCz0PI809Unm B3i3F+gtR4bvmWvAPQyXfyaLbSc1jM0jz57Puu86VgqnoU234n2riNk/kKfdgtZN MN9gLSvJD3NkocwB6svw7UbsaF+x7NlmjZ0tg9RXWKWygQjQ3rocrheC6XGyGO86 mKztTvKrwVKApIcw4i94i/lw82ryt8nYxEd4r7X4vWGyDavNII/9yLQnCx6PzXZD ujEwTWU9h3+SUc46sx3xRc9PqLznQG0P4swX+Jl++LSeUi7XIL0/cqfe91dwecUs kY+Q61PwdSvRqNI8a39n9zMr4cwK84q8L3fBl1vR4vvBc6sR6wCi5mTWWH3kULA/ 1mwHn2NYBfzDHGadhl0+I9PNDAmbY61nyEHqofZtssA3maGMNZuux76wbzaL8Eir zEJ0Ygza39E6yKqSO1lD7iSTu5x4dAmefaQZQ3R/nXzic3KrOfQbczZe5mD83s0m 0aqQCu59CR+3jNjTngztHuR4GJxdbsLEmyJWQvCW+15CPhPINn7NnTeZt+xpJtEI q8xk+jviJyPQdAg51BvygT2NsS9iP7eBxSg8wEHE7Q3EiN+Q3b8H9p3h2WC8lp6q SKJ/KppVKpnWYPQzjN/dYL60x0Fbd/OC/QB+oB/8+1SutP4mx1lncj3L3GZXmp/t 24zu+z0FTTcRqw+HfzehZ0kmCx/1DSuYKnlRelliHQmUsWQl7zPjt2jH8/YgNO9A JJRlZhGvamSKNcL6WH7kjtsYc7P9rp3LOmQhM14ga637ydAuM8cj9y07h8rRuuNH 5n4so7/CVq5H38cQixYw3xvmZCzvN+Zhuyd6cioZ6wAryVpK3GwvY6wH7WKymQHE lWOIPQ1Gz6u8ZZ5Vj4wOb8AvnYctZluz8UwV8g4eQXO732GZi8gLRktnvPwGu958 hgy7kecWWQfJHfJXGWK9gs1MZjW01ny782iy74dYOb9mbrA+Isd/jMhRgx/oJVuI C9l480Q0aT4Z8yypNCHyoHfwq3ew7jvSyiQvWMzKUZ/5F8kBoQ/lYOsnKbFPkN72 13bM9LDzgYQ2mKutCdYQedwaAaX7mNvt96XcdLcuRoJvE+8nyO/tj+1z7bvtmehs BA+aL5HQBPle+lkZ8CnB/gkKkmSwNUIGWf1MEX+r7FLi2/HkfkvkBut96Y+s7yJv ngi164gs18KJD5n7fHiYbpNdkkf1hVfnWFux3+sljzFTyRROIhcaZo0hWqXIx3Zv 5vzJHoyHK5ZfWedaFdaneKRfm5V2uoj9JfZC5hJ61Z5NzFpqP2eesT/B/r+G7jby lrXBXIqnfMSuh+9vis06+hn51F4hP9gD8WabyePXmz/IkdYkqbROJZdrINteJMvt 2/A8XcwGecIeAb9GkYEPcdaTRdY8KLvesrivlznP/qtZZ3cTXc8/JTOQ0pPY+1Fk iutYJS20irCtY1mPPA9V95CjH4Xu5+OnpqOL7eHKFFY+V+FhZ8s/scGL8NzfmH+w GjkanC+EP8Y+VL6y3wGj98wKq8Hsb10vpxHzJ0JjSK43EauTaWP9zOyD5C4i9gC7 o54msh+xjjF3WjtZsz5mjQOXc/E3vzMz7eFY251mOvnwWHxZyHwJfENsKZdjrEEm Sl7zHdnoVXYlPvsyPMGt9onynW1YWz1ufwB/QtaV5Ii5Vq0Zytq2Dxp4Hb69jNzg ftOXfOk5It7B4LRDbDzU57IJT3Gzedf+2ay2U7HgGHGgG7nZs+YHW71Lf/R1qLUF 3/GM1NvHsrr7wf4DXvcUOcyqQr/uBe/DZJIZbH1gj5FR5IZPWluxt2VkLkfTd4P8 dedEOcwchB8qNR2scyTbOtraRlb6KvH3GfO4fb6UmOvIL1aaR2UMK5XD0cS2xJYr RXOax+VY69fWgfKlGUSM6M4K4HI850o7G21eYDKsl+VuK2qtgidzzB1Qcima8LK9 Xg4286z+xKJ15KerzDRs50ZzOZC/NZ3g9yKyzC1kMGeh51km11xFpFpIXHxOhlt1 5lXrenzbq3BlEPZwDX71CzL2WUSBh+x78NzfEAVzpMrqKH8m967C9l7ChoZy3Rmq xplzzP5kn5vJnsYRV862vped8gfrKFbCtWQE48i7bjHDiUX6xLMLGCZC3WFEz3py nVfwFdOsS2SJtT8x/GTz/s6Z5it7MPZag+5vQ4dfYx3xPNnBu+QGn7N6PphcpycS mGzq7W54oFOJoK+h+2cgnSfMaGstVplgdcYTXGQfxJi19sOsSD6VC6x7zUTeY+Qn LOI+6zjTztpEpKyV++wSkwN3rsbzzrQugjdRc4H9KP73RnkB2RVbU00hK8/leIh5 4PYq1vOUXGcs63ZzGVnch2apXMEqcaQMwY+fgJ/MwctUybtkoF+RjyWzrv8M/9XF epIZ+2NVx+MTvzfb7P2xj/vgb5kZap0kV1mPQtc42cgqYxrZ41msqZfJKtkfX5+C 3lyE1ygjx0u3VkqKdRUrzajUkm1fw0pztf2B+WjnOmz4RvO+1V6e5f0u+nMAeriK XONFuL0fq9ADyKMW45leA69brcWsSK9gZahPfReR06zDm5YTE6402XYbcyLZt809 hdZb0pNY1peYe639hf29/SE+SCPU95IFNbbpgOZtIcffTs72gnkHP7CTnHgUdM4n z+hisqwd9kTWW7+y97PWI4vO1iD5O/GrJ3Ekz1xqR/Hox7HSTSIjs82beprB1tOz IvWsap+1BJ8q0mOnyOu2/p9hgn8Uuc5SvL1vHPCeanQFLGTG4uyavs27mjH9Kb/k vu2829M3mrauvGdy/Tfa9JVInTzK2ZVSWKlcn8u7kutTeCuPqilP530710MVB3HH 1NvuPS/wHkP9Zd7tmO/v1Jdz/Tj9Nbyvod45JHI55XO0J/Few/sm6udQdqU8U+nk Wp8I8Q9p8ObiIY82PYXUjvd06jcalw+fKH1c9zbuvYqn/qdbn3N9tnF5pCe03+b6 OsqvjZ6IEdZEgs8SorKwThD0V1ilCHmo/r9fIvsx976876L+I7w/Vdyn6noyVGkp EPc7IQtoW23cE+iH8z5C3G/d6HMlffqqc90m+mxMWJ+LjDd6yktE/2e+LbyX8p5E /QVgl1CeS707QNpYLv59aJ9s3LH9PJnr3HqSWfk31ePPjbRXEQdVpJ34yOC9geuP uUdPZ0yjno22XAPei8WV/xe0DeL6ScYsobx+p+4xiNwR0r0kkZOh+2bbIr6KfEvb 32g79mdjenNfT9rOB95jtG2ifhjzPujxfKHyj7eeuDQeb1Rfuok+Y1Le69kq/caB 5chOT4b/SvSklCurvxlXTjuck5kWeZiesLfgr4WlCV5QnJn1Ww1/4r0/tT96/Nbz 6jqHnnLUM1zap/I4hHvrjPsNjW+NOM+164zqgsG3ujqhstU5fbvSMXqeRfHWp4aq g58b9xuDqgt6rtX/9qKe3tM299S++60//xtK7ll7v6bvkWMn5h+Z7H7HQ/9Px4j3 tsQ7Te9/0bDZq8b5JzU1bqF/XDz99NPy9AdPS8Mrd0piYqIkJydLenq6tGvHOna/ /aRTp07SpUsX6dGjh0yePFnGjx8vw4cPl4EDB0oNZpyfb1j5vitmW5288O52effz z+Wqex4AQi5v3Z2r5V3nVnP5yKUtl7ZcbTPukGLai7kopr24Tjfw3Ntqaa+lvZZK Le26iV+n09FeR3sd7XV1rjgMdaKSmDoXlPNXzLuWt7YZFzwfueCQCw654JALDg5K 4JALDrngkAsOueDgoAkOueCQCw654JALDg7q4JALDrngkAsOueCQSzTMBY9c8MhV PBCcQ56Dif7V8q7Tpw4uyeBSDPBiABUzaTG4OGygs5iLYnApBheHLeBRDB7F4FFc q23GZRV4FINDMTgUg4Oyrhg8isGhGBzqgGX4dFgIHPevzmNvroNRba7WjctqYNeC Uy1AawFQC061wK6ls5ZJamt1LuOKw4FNO/BrgV8LfBVRLfBrtR0casGh1hhHbK4k ih3oipmKtw4c6oBXB2514FEHPEe0igc8qAOPOsUDwhxxc1MduNSBSx1I1AHQUQFw qePGOgbV0VAHLqoWdYoLMqkDlzrlh4OLaoNKodZRJQMOBhwMOBhwINVz1Qkc6sDB gIMBhzpwcFQMHAw4GHAw4KAPl5iaN+3gYMDBgAMpNbbLHEafM9HGoOJilRFyNApD 59YxxXiZO2TatGkyb948ufjii2XFihXy6quvysMPPyybNm2SLVu2yKeffipfffWV 7NixQ77//ntp+MnI7atWYcdq0cYNfTqvUzPi+hct4195vEzgNdh5Oc15XXkFRgzu 6r5ozuu6/vfrf8/lLt09e+bw6klz1/Vt+Nu+Pn4A/Tk5CxZ05tV12/b17l/cAO2v X5CzoL6+Z9629evo/G79d4H+BfU59QfW1sfy1mknf0EAC3LqaxmQt3Tdev1bGsQw R+9fVhtjgA7pGqSwZ9ec+mW1yzrlrV66ev3qpV0HN2NBjnZXxbIYsHT1YOVGPCcH 06LdVSPCI2jPWrrUZZmJH7EtVhXLDufBaheL9csCaHYdMWJEanr6YLDQ7t+v/9of UFBgXDmFBw9OZXodsB1WN01Q4L7aDxmSmle62gGwHVEFhD24YFr6iKy8pT6AYH8B WJRu+2te3mrtbtPsfu2PQUZh3upl65Z9F+x2+2FDp6V5eUuzmnU7/dq9rH5Z5xY0 0bu/E7yu79m5c0v9OoDu2gNRuOb9zgQ9Y8uQdk7Xlvt1QFV9fX3L9xtX2LwW5LTS 72ns7vsXtD6/p5C76Xdsajfdxkzr2iJ1Ta8m5p4wduKkv+ATxp44+qSxI07KP4Tr EeUVCypLZs6KRe6JjC8pqiyvKi+ORUaUV1b0jvQZOHAAo0dMGKn5kNZ65fTp1acv baNOPF5PWAwvmTMnMqV8TnF55Qxa8yeM1Dmb5smfU111yOoI3ZEpJWUzyudVRQYO WM3IiaMn6VnaieXVZTMio8srZ0Yj/Xrn0D5hxPBdZlBMyisLYyXlZRmpJ5VF45Cc UrggI3VCdEZpedmMIyNThkWYO+fovr3655KThCUt8cFsJwNruDtb8559Gr7PEgnN T5GpIXd1o5mS5lKadWu6pNmZ+31c9+V/LzHdKw/wygFemeqVmV45LzA+GuifE6hn eKWfqvlwuwfq/vdl07yyo1f28kr/txD8eToFxh8V6N8YqJ8XqPvl/q20/9LSp/OX jr/IK316Ru9h/J7Ks71yvleODfQv9soLvLIw0O/Lv82/WK71yiA+nyW03O7LtzU6 Ogfqvt74eubroV/38QiO9+tB/W4NH7/fn9+v3+SVHbzSh9stMO5O9+uCjfNWBMYH 8dgTXimBenC+4Hh/Pr9+mrVrPcgnv/Tty6+XtzKufyvtfrnGK1vDL1geHaj7+AXv 9+UTCrT7+uu3/8Yrfb8VvD/Rewf5GtTH3oF6TqAe5LPvf1rr31M58l8c3y5Qz2pl XI9AvU+gHvSjWkbj6r+Ejqi03n+cVwb1vbX5W/MLQfsI8mtEoB4sfbttjV9BPHx4 QwLtXbzS9w9+e1Bfgnr9S+EG/f/wQD1YHhQo/fZDWxkfxLM1Ony8gnT47T4dSa2U QTv26fL7fbpa04cgXX57kC6/PUiXrx/tA+3/bunrZTDuBfX1tEA9aF9BPrWmB62V wbgWlGPGHkpfbu1aKYPjfymee6LL58O/6hd/STn137zv//dyWqBeuJvxwbj53273 y6C8t3qlH4f8/qle6fuFUq/05yn2ytb05nSvvN4rj21l3J7qfr5/hFd288r9vNL3 f34+4be39cpsrwzOO84rT/BKH7/DvdK/P+gv/1O9COaxwX5/feTXg3CDeVEwPgTr rcFvKa/4V8qwVwbxbS3e+PoSnKe18a3pw/+63Nvw9lT68vTtz4/XwbgWXBf67eO9 8j6v9Neby7xyemC8L1d/Pj++B9dHPhy/7q8H/Tw72N+avgXjtb8+D9pHML77duCP 8+3WH/9coO7nHz0D7cd4pb++CuZNfj4TpMeH6+MV1F8/D/Xh+PRPCbQH9zN8OD6e /nx+nuT37xvo9/Ho5pVBvvl+0O9vzd78MphXzmhhnD7dVj4kxbUrnW28NoV9sDdG 9Udj04HeOO1PsNIaCihrnDXw+fqZfKHz+ZSl30V52qKSvMHSHbHnnDGvWr9jgfSa c/2687nR+XzT+dxkOb/2Y+m3160Q18lDQgq1Rg7cERH3EZw+6TG53iM54z8PEfnn UyUyVDrvUP3TfoWs+5P6POlgaQi7ev33BJVDojTRy6tGP8Kysc0ZIaXXOGO4TPRt Rty6/gJLwkynZic4+qBY70zoJ266PSOuPOXh6XLe2wk5+ZTKvjvRkwfJ+W7+yZjf 2+4PLVXITwm+GlYkN9V11qFpikpy4iCnt2UYsx6b6/R2Wj/duUdhnODHPedlzMGt o7zQm8YvW0JZp7sYdFO9tCQe5Uj6rigfn6wot9kF5UO8uf0yiHIqMH6MR9lSlC/N fkuU25dlv+I0PhHWIdOcv3z+JslA6kuy7xfdh3wprHLKkbfCKtMa587V4atEfdGa sGI333IxFLk/nC+/9FUTavp12933+XAWxMHJbGHcEPlz2NWp98Ku/qXLSc3a8sC/ Ifyh0+jqa5bnfBwhWP5sK53xrn+4O6z506hh+ZGq6oqK8spYpKQsUlVaWBkrKqyc USVyS1gn8ow3WWfxDVnk3nCq16cAUhIzvamTvKkjfI6sLCyO9aquLImW9QJMr8a5 e+Xk9I7Nj+ksR4r/U606i+MgnHdKYlZja2Jcq09edoJrjjoiIUCeeDi083GIlE+f HS2KlcyNVvX2UW+a3kfd8m47n8/jywvn9M5olTduV0lVpKi8tKI6Fp2xS3fvjLFl sWhleUW0snB6yZyS2ILeGcNmVkajpdGyWGR6NDYvGi2LlBbOLq9suol6WXVxYVGs ujJaqWjeEh4jTa7cDVYuip3FT/lHNLb54/yQ5odmfwvGJ/sC8cn2OblvHCdDrXBS TcnlZFE5pJXFGtkYltbYeDIXI6PFJWXRqki/SEVlSWmJI4FIYVVVeVFJoXItVh4p Lq+ujAzLHzmZjjJa5pXDy+LyytJCHR0prI7NAl5JkfPkJVJVFC0rrCwpdyXQa+LY 8U45fuTRGRn93Gkyjo/Gpp0YnR+bNnaG3hlb0L1HxogThuUNy4mMPXFiXp/+kfw+ eTl9Ivl983JyIicU5fERzZs/P2NidPf3DMhpumf+fL0pJ0fBT8svLDozGtv1Fh0M mK3BWxYscBCcMPHEaeMLq1CTaWdGA9CGuRjGQctxUOzT31GLTpZ7Ts1ldVsne3KZ nhLX6ucObjbj9vt5np5x8tv8PYX4Nj/PcDMst+0Mr8WF5v7CdXsnU/R/j729lzdp X5YDq+Uea5cZMnY7TpUr4uCzuzE+jm6bquYTfN4qvmq6zsN1IE3OJhTX2qPFsVaL Y3v9C2MTWxzbu8XWtMZW3zQ7xPnwxFZMU+XhK21kRHlZUbQi5htnu8YZdzXOVeFt zDwMzpZJVGIyT8qlUs6kXi1VtFRyVSqFsoByFuVc2iJOz1ynt1DmUD+RGcbSGqFe xV+5FEkJ1zHGzKA1RkuEOwq5o4TramfsAKJuXzJz/QWUIPwq2iNE6lkevFLn3hjz aqlzlvAZ5a4YVzEHvxIPgzI+h8lEHN5Y/vTumAO3TGbuAcNC3hUepBJGVENdocMD l0LFaYqHUTWzzeRaZ9f7ZzEu6vQ1x0w/K5yxR6LlPlVBjk/kb6yM9HCMOLNUgYXi Pt3Ds8ShLubNsCsHFROlfkYjj3rHQXMpiIBB0/1BDJQClWhpIydneFxp0oYy6qVc 6zzFzp0RavOd1gru9blT4YwvdWYZChXlXCtPVbJuTbEbFjf3AZGqAPeKnTsKnety h/LuMtnhUQ8Ham/nW3d7kvnuMC10+nRk1KF2jiMvn0bF8HiHR73gn96rV2MD8u0O NhkywRlXzVxlcXrYXBcUmlLvwlYtrNxF0+Y4ehxzYE/0YLcM0e2tipPnL7ETjRt6 vvXRRs+xqdEbNEWKno1tTZGiU2Pbo41Xbu6pv4fneqJ9uCJltY9obE/Ypb2wlfaj G9t9HPwVsA/f31lQjxYRd2XZPFX8kxX0nAfEJTVJlj/Hrp5TqdA0bqKb4TWmNBnS ste8O5xqOXc0xftdM4bIDC/dKYzEKksq5kRjke5+75ERzVMmLaiIHhkZR8Cv6tGj d8TJXfzJSJHKi6JVVXp/mY6OlFIrnBmNdK+MnlUdrYr10I7KKBliWUtjqirKy6qi PXoH84txTn4xwbuPdCoCjCrNpkqdARESkCNnRGdUF5GRFVeWl4J/VXWR4lJcPae1 DKx3hurUaRKfQaxo5FVTBjGhsa1RDI13rPBKf/QEr2wa6UokrVG+lliJ3mqMVZ9Z JP+V13TeXzmqGZbvE6YkK7TtCf45aivUJsVfv/qvAmloExH3NKO+3BOP4pwA1lO8 etpTT0r645zzj95Y5xRkrTSejNSTlU3z1Tlj9MStTqmnfZ2Z9RRoXXEzuHp6WF96 GlNx0NPQeiKzNfx0DnHO39Y5J61bG6d9enTXaa1tnV49fVzrnOqtc+gVuS08WJRv Zqc+pe0S8XeRQo1P4USGhtwWnW+7O9p5KQQ16kxmWSy6mNRZwvixBGeWWluf5enS pqHZLO7/56Mv56kygqvBRZwlp4RmWa4+aX2OLE7YGHJ9jtZL5cHEnxPc/0EkS1bR cpcOTVqe1D1JR2XiS28LlzXiEk+R4tLduwpS5OOS7uGi6+KIFXERSdLx7h16XZBQ kOBf1yTWOC4qH6gT3CaxUjSf923Caqy7s4Ua6+6MCY11d9bExro7cwEzp0u8jemO jCu1pMaWkPMthabrUON1lufDXe4kNl63RU+bz5IVN0tW3CyZcbO0jZtFMfshIbOx ziupnYSWJOWEJT3xnES10FBDVaLqSHKDvw95mNOe0NDOKRMbVCqWpDT488S/QpLq 3KdA9V5nvKX7AW57miKTqt/6SWtQjdXfvIJ3srzHXDlf5hdaLKFvfUDkQud6sXP9 FNgcHNjL1P+5w93LdPcvjaW/pR6/QwkNDsSNoYdCb+6bnBmWdh7Gz6b5+2Mh8uew ZDRc7LTvGo2Gip6arKyoisyojsRY8EYzRkar55d8URqNlLF2LqzOmFRZXlIV33By dSGhqamBVVK4g/jx1l3buasG/VQZuR54WCNc5Zd+I8rnV7rHL39f1+fXpJ6t8+sS Z67/jGuL5bHQ5n1/bwW5Jg6mLtfc5327Rn3de59UEquMEq0jcwojM0oKK8qrnK0J ZYYuD/1jKS7pfhhwSR8epyrdAqpSI+2PUKL1dYHzeaHzudj59InOaka0NG57+0RL YDPbJ/q9tizeQndlKnGPObO6xLkE3h3uxufEOSVQ1jMjI7+wqqhwTmSy7r9FMk4s nxstnU6075uT01dDtx6ecpfS7t6ezq8/lB9yTJVXwkFxLc4jKfRhc9wG4r3hfhK/ e2c1XqU0XrWRpjStbWOrclKd6HDL5eShHidvg5O6FXyRM87l2EhLOxdZiqPPq0SH V3f3IHBYHZBQS7zKDD0tDftmhhypSZPUnOnwM1XA0nTTlcUy64qVS2S59eEfZgEl i9GuFBITlJYhCarUmYEgePXVVztl4ZU7RVaL/Gx1l9dff10i8kRYOTjCSfndZc5c GSh6GLghIStdKdnhb4nXgIzj3N5Kc53bK5RDPeemqWz7ZNe5zUpr2bnV1Ij3xak4 55bc5Nz0cKJPe0g/UlUv0xpU/otE/9s1l88+h5uboP58+5CQuwHj8vZda0jo120/ Tw0an3I/SY4KKb6PpbrwR8fhG7PcJxGz8Teh/ZrwVRr1OU42eKk++QbrQjteSq1I +PH9dbbOcfanLAztYn+xD9T+Hp2gTqfifqVTrxc7165O/bv2F3bwPw91LiNbnZHi 4q92eLmD6a52qDTka1reUy1Nd8m9R3gdlBenebUEL+Btjts5vzfc2bt2LCXZauFK 5M6wHnnYwdAuoXZWO6tLqEsoNyE3YUTiCMe2ND3yuZTYjEtv/4+5dEWiK+VQkvvl U+WSe7Qknku3hJs8q3hX/n/n5m7i+WmKmyrsSveQ0MHWwWjhkNDUhKkJCxMXOnTr AXLfpyR5dP8Juk+k/ksobk7l697jxdZoVY3+bZqr0b/1LDSe+/s0436/Lf9b7j+O cnUAYi8gP5r6r3Bf/1OqJE8n/1Put9lr3M9Ld7mvZRCL5L2GRYOHRUMLWKTsNSxu z3Cx0DKIRepew2JKWxcLLYNYpO01LNLCLhZaBrFI32tYPOVh8VQLWGTsNSwqM10s tAxi0XavYXF4OxcLLYNYhPcaFu95WLzXAhaZew2LK7JcLLQMYtFur2ExPNvFYnh2 cyyy9hoW//Cw+EcLWGTvNSzuae9ioWWzNYPjNJqvGZa9WMya4ZNFK/7jNUNYXg4/ HVLI6YlXOWWo4dKQHlFxVwJO5HZiS0LDYSFpthLY/Osl0q10iSRQPj17iTSuBNKb VgKaizWuBGgPrF2drPD4ScrdQc6CXa8XO9f/WV7iZvEd9p/apm/K8/v/v5oz63q0 cWXhcael9eie6A8eRPPpXxi6NbQzY0haEFbi/wBW+4y7Q6G2m/ZtpscK63+sx39L aLAUF3cDXV/hpn24Gv1wJdnCNp+4+n+p5ep/jaUboa7+O3sIZ6Q4+t/Baq7/Y7i5 fxt3nCt1T//PSGnU/zkSp/+0R0K6Rk9r6OAg9i15ufLYcqiH5gRna8vj6KqkB62N 7SuSW9puCjsr3gxN/Xjd3LjdFISZ0AzmpA+DMNPiYF6VUpAQyd6a0dLGYGYLMC0P 5pg4mBYwVeL+it/XqCT57+55qNzT2jfJXcFktBX/VaMfe5L7bdmu3G/M1m1qV+66 B9V5lv5XQh12NNGY0HB4dnMd0P78RFcHJobidGBWKzowKyiP9h/tTgd2t+WY4W05 7lEHmsGMNYMZrwOrQgWsKR5s05IOtG0Bpq8DuuJ7y/cwwFQPswyY+lXR5h4m/ujt nnxLQUp+4lXpp2QqFP3ppFvTvfW2B+VZoIxxKHsbynxY6t2fEt1J/Hfjx9C0/MSz 0s5uqxQ/7FC8a/wYyWdLR78Cp7p2eX7b0kksjT7dRH+e1HklK09Hir83kdj4YEQP Jvl7xKPEizOJGmd0166BODPLmmVtDG0MDUgckLgqaVWScuxHaeLYPs04tnzrf5Nj T6dEEi9KfSJVOXaBg/OuHFM8+0UmRivnlhRFI/mNJ/R8DniPZR0O6NjdcWBf+aUc 6GI1WWayx4G1VprDGRezeP0cbmUycIQVyfB3gkdtUNxGb9BDVIss52GDg875VpuA Jm9w7Ok5p7f5IfK3nM8/OZ9vO5/vOJ/+gfLMwL7ypQnarf+RZYOpAZ+aNpGMzOSC dN5S00Y9lr7Ux65K0/72ov+tpQyV+7lv9+8C9Y+uzHIS8jMK9s3PVB/3TaJryydI k49TbkWAdj5GPyWliZMps1KcHdSu6JL6A5eTLs7+3PmJFW0z2w9N83PsLt69qdwb n2PH8/94a1Fb5e32F7KkdS9h35ggSSHdj9/H+RwSUr19KuQoj5djBzFXLDTzbNwZ 8LDwc5N4LFytb90zuRDqPQhaTvYgfCJNPEr3IBShbQ87kLeJ6tYl/9fe1ce2VV3x 854d24md2HGctKXQmdCtBdrQVlkpdEMkaVpCmzaQ0LLRqUkTpzVzbBMnDaUbFLYh BJuWskqbVrb1v21lqqoRoZUhmgF/VLBpmQQaW4UUaIbKmKZqdIhunbrzu/c++/kz TuJUjL1jXb/n+67vuee8c7/OufdcLSVbyGfjb9Ayp8vW5V/fRbPdoIDvXPKEeOjf cbT44yLVB/ji+3LySNk5wdHJACmRlO5zE73MlO5mXrYpSv9sorTSROkxQWmVBkp/ ZKLUIygNZFGa+aZnTmmmRUZSiiOrQOkzIlWlhvGAK4PKFIWDbqnJPMjF3J5DWqrm LC2QR/DwHXXNxOAtCYbXXRIDrpkYfCXB0KIwtOTAUD1nDJA05HzAkxuDf84YHmQM f+Csvu6RV2D4iFK9ZI3qI4zWiUfN75Sil0xvGw/aV3nX1gSd6Culm5b0vlL08k0d la1bN7VtbTV6SLURUvSQSGH0kMEcPaR5eW/hHtJMfSCL+sC7pae+sfy+qubqxRX5 qEeatqbNwc2tdzeDdiwVV5vxBO14bhMfHB2qkZyn25Qdp0KlLo76D03U12ZRPzQP 1C+tWO8743e7Qf1wDuoxb8Fau64tncaLd5mId2YRn/7iXTQb0uuySH9jXl78U9Vd AfniC5HetLnpypG+IIv0xrOlJ33KeWPVK77XXdOR3tnWPr+kY72YQfrCLNIPzwPp Y87N/ks1RwTpD4j4dNLRX7dv+LxBtoyWZMu1HPnJtlOxZMcp1YssYrJvr0jNhMy9 SK71H5LUNw5j5IE0ucYcZoIvOM54j/imnJl4r5pnvF3OZ303VjeWZ+JdnDHzKz3e p6qfql5akYn36nnH+0H1AX8gi95r5hnvBccB//qaMfF+MbI0qtOS7LHDVOmr0ypP t7e65pjQTHxXxKdXJ8yNd4Q3his7jc1+le2xvuFIyKhgyn+FqGDGXqdcE+06lamx oCq1h3G6ygamJ1WCe6+cSjAq2FVYJQjVH/ypQ/VXx9e42eTRJ1W+x7VsdR8UAHiF dxGGn8Cj1H19KXUfBjNJdV+fVL31Mt2pZu0gjU3lUvo9oRaozk31N2jCb1P4Oxn/ EoE58Jdcqr90zEf1g9pEoNs7UwUgvK8b1Q9cRDU4y5i7aPrqZxeij4l8PiVJ/mV3 o44Obbx21JEldX3FSt0S7KefVuqMFeiZK+4hdXoRUpepiMaKV1whjT/UpDQ+reEP KQOEOyKl8YYc0pgJSWmM5JZGeyS3NF5478pIY1kkUxrHgo/p00ljXD9PfwscrZqp NKZJQqS0klCo/TnsmZskrPBISVjK16CSBLTQi+LZJokTeRZo4vnpTQvFjoCkVMRT UtFHKVWcN15epDGweIX9RNkq7+0BKs+UQFs8T3u4cnoJHOV2aVwsrp29BDriWe1h QzHt4SiNekZn3B6Cy2vsErOzIJftJv7aC/A3fRDQXd7ve6u63W20vYbxpTyev+09 Jcr2qAY5PqVdTUsYI+4NjFXYt5HEaKNTusbpL+t1XC8eseG/6WUIOj72kLdbDIMe 49/1il63KoNh7M+mN12qUlTnb/8LcyPo/KPnVFW3CyWBUjNpJIpnGYkaSmnyGHWM el/y3ylmNglRnvShWDV/d4Z6hwdDwoNDa3RPOBoyVkMqN0AuCI28xzAMw6pMlxHT DbemTCS7MoSNp3Q37ZsjmXH3RNXBmvs9hbRVqd1/+bRVBn1a8j5IM9dWTVKKVo+i Nenkh7rO5H699gJ05xe6fPzodpyo/HnVl4X2rkNQk84PpGyLgg9BMla0oqBOkQdy Sg21seVU8sBGBg9AJzbMGnRWZtE5dkXo7HB2VI5VSfHeJMqbPXHfNjwEQuuS0ZJQ ea+bxNlOKfJmZmzyxXMbmyQ2oyaO+ydrToi2yGxsqo5/EoxN/vh8G5tq4v8vxqaA idJj9Gk0NtXOWVqmMzbVlQRDIWPTgpJgKGRsWjhnDNMZmxbNGUMuYxPGIcm5SfzK zE1Y5hZg85zGAglo/ynRnueI/v5jLostSDc9T7TsV3DO5KNbfwtPMEE6wX97YQKp /yk90zH2b9TK3mz723KkC78HQuRLBjjvy264cjMBsEx+6yf/uLhtr+/ZQy66cdlz fwLHDpdLvzN4PkqS9/AHi2K+SrKvABGY/ZwjqcG5QGompsk2HKfhgadbNDnoulcT wkdf0+TABAsE0aIc1qQvgaOa9N2K1RTYyTqmyTK8qEn8U3bpEAuDoPbYvnB0j3CD sINHgLsHYyOJ0GAwHB2KiUio+5eo8hOnxT0k585Yf/9gz/7gyuDGnr2hQVOa/v7M +3oOLbfubO/c1t8f7g3tbI/1nYuEEjtbYgOMa98ttzTEY0Mk8WA/KtYjwQVYcygS CW5tbVkRbIv2NlACz8GvxlsaRVr4azOdaRIbCQ12xLjk4sgSzvd28OLhkcbrnSTk arxrYuTioXFNxFdcev3Auy+J+27thu2vfPtlzabw44o2G0OKCaeQ3suIc1HM1+4R 4wFONGnD24L3I8ndzzm8JGe1kkMSXuBUr+ny/SGFS817JSbEXCdi7LSYurZ2dATo 9HnpyB+9w9SCfSqfCpW6QqTCe7xgS88TJfSqmIBIZWepwHswagBkzK0bdx79Nf0F mxguaZVC3i7pRk1F7Eoldf/S5bJiPKlXT7S0FNc4rqXzNKGPq15VPknPg5Jg5KEr nEbpZKwtiQFPF9tP6w/QQ3pmrrqQ83+nV0PNnI9d0FiOFKL8AZHWJ/51TjZGNKqp v9Q3DYZ7Isn/lonr+Tx54FkD97NivKhpIs81FYf0GlF35XZjH//TwWWsVCPNBsUx nUteTJ7lKs9tgqjVnE9mLpKSD6ehxK4oKSsKq19gHdP9gvdqvzSXxak+NrLPihqv yvc2kVpswKZysb3OOUv+LBY5vqqXCzlI38tdoUrr5nrhFCV2irtsTGZeotbUqdqL 3Ds5HLel/LYbEok6InqvNFlxaHIZ/lIbFjt0cdhJP7MhdKnnRo3R1ZWSb8alsDsE diNdZj0Ia/tt5+mOtH+vzMMtKRtvJmVDXqm+bSDe0zs0OylHO7emYr12iQp7yfRT LfPRKb7lhydnTKNHxQZVTK241vE131vJzYe79NW2H2ijM+DDpOLDi0ZrMac6Imv7 Se09UdulS88FTA+PmFji3FnUFF8/TmpfwLiKhINQqhFc8yufUjPNsV7l+KSGOp3t bbSCOb+Aee9mDFdzqOTSw7rlYXxu7s38XD9ng9ej8D6noyuAT1O34Ezhd5ySefnG fEoPLd8Yj1vrO/cnhkID2ZKb3d+ZIb1/RDUwVB0WWGCBBRZYMDPIN/8XHeObv3vz mYbFvu99n+f/Ky4e38BxZRlxRzkhfOSjp0OP9ATJXgm6AfRmvyDZy42T1AWcJqkL gI4AI8W3SPZrkyTnhNAZYCZ5nqQu4GNSs09NnneAPZ/QffuUbgCbBdFLvpuhC8Bs swnT873YczoZjCx7v3ewJyqeAV/zPVu2BFs61hE/Q3mff1uWG17kcS2jVO+a67q6 1pU8JyXfdYlP3qP8XeGBUCK4NTQSvDs2wOUAD9T4FWyRQzgwYEc4uqePQ0KQtWW4 N9zXE+zsiSbE06SKQfhmLzRszeUb3ZuMTfr5xkw/y79wJWW4zvT45NsD95B1RywS 7mV6hofCkXDi/VAiyTOkgAVd6kTghKtXZhqORUUiTSVaSMpRV4ITJcx+ulKZMaxT Y2LAcvV3eM7Du4buEEl/qX4jgEm7Oto27Np0T9sG8dRjxNyxpW3r5s6klDTxFRaK A9RCN3PYSM20lu/W8dxgI3+38K+VwgvvBnHXzLF4vpJW8Wc1hyZq5O+1nHYdxzeJ UxNkvrAQO1TpnOpq/CZT/GdIapMa+LOTHqQBivAVPmlDSX+2iE+I+F7hrTkiYqPC T3EDxwyJf8m8jKmRBRZYYIEFFlhggQUWWGBBLvjIi50WmC/vGj909um3Mb++YLPR 7jx2a9d0GVpggQUWWGCBBRZYYIEFFlhggQWfMIDFEBZRWCRhZ4XZFZZKWCcx04et HDZV2LFhSYVpGGvxYUqGXRv2Y1iEYZuHDgG2X9jnYcOHiRerK2GqxhpU7GoQDl9J WiuDHK4laQG9juT6/c+SPKl4GUl77/UkT43E2ZMrOGDdJvQVN5F0xriawxoOOCcP Oy5w5iScoN7MYR1Je/6tHNZzwPbML3K4jXDuulxDD2ttM8mDtLG+oZXDRpJr5bFz pI3DnRxw1hT2zrWTtBpvIzgvlt4pYI/G+lrs/72Hw3YOOzjcy+FLJO3U95E8Y/kr JNfg7uLQzaGH5PmEvSTPnQtx6Oewh8NeDmEO93P4KpGw8g5wiBLWbVy+HCecgEeE XdfYDTvEAa6O9qnn2DqKs0EfIli5pVUaNuqH1fODROI4q8eIxFFW3yTsuSF6XD3/ jwpPqt8WfPrgborxB6cdt4rzZAeFxBQPdVSmGXmhDfF959G+I9t+X/34X+kYnbz+ XK7/QJaM+xZxuu6gOs02yPVHHqhVLFxFehL/ZVO+heARfKktLWVcc4e5Vskzdvdz fY+qc4URY5xRnB+Wi3XCRDPBH8OXwt/Bv0YExbgLKy5sEGdZD4vziqOiXueD5WLd sWy7i8UPwHonQFkWrpnxY90s+D+Cr9SWojnDTPGXGv6X8f8XUEsBAhQAFAAAAAgA 8JJvLQj3PK8kUQAAABgBABIAAAAAAAAAAAAgALaBAAAAAGVhcC1zbWFydGNhcmQx LnBwdFBLBQYAAAAAAQABAEAAAABUUQAAAAA= --Boundary_(ID_BDNOpGSDnjkOSqIRiKfSrw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT --Boundary_(ID_BDNOpGSDnjkOSqIRiKfSrw)-- From aboba@internaut.com Sun Nov 17 14:10:38 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 17 Nov 2002 06:10:38 -0800 (PST) Subject: [eap] EAP WG Agenda for IETF 55 Message-ID: Extensible Authentication Protocol (EAP) WG IETF 55, Atlanta, GA CHAIRS: Bernard Aboba Jari Arkko AGENDA Monday, November 18 1530 - 1730 Preliminaries (5 minutes) Bluesheets Minutes Document Status EAP Design Team Report, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt EAP TLV method, Glen Zorn (5 minutes) http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt EAP state machine, Bryan Payne & Nick Petroni (10 minutes) http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt EAP state machine, John Vollbrecht (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt EAP Security EAP Binding Problem, V. Lortz (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt EAP Binding Problem, H. Haverinen (10 minutes) http://www.saunalahti.fi/~asokan/research/mitm.html EAP Binding Problem, H. Krawczyk (10 minutes) EAP keying problem, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt EAP key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Tuesday November 19 1700-1800 EAP Roadmap EAP security claims, Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt EAP IANA considerations, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt EAP Roadmap Discussion (10 minutes) EAP Methods Smart card support, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt EAP SIM, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-07.txt EAP AKA, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-aka-06.txt EAP GSS, Bernard Aboba (5 minutes) http://www.ietf.org/internet-drafts/draft-aboba-pppext-eapgss-12.txt From aboba@internaut.com Sun Nov 17 14:59:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 17 Nov 2002 06:59:43 -0800 (PST) Subject: [eap] Format of Method Presentations Message-ID: We have allocated some time in Tuesday's session to method presentations. Since the allocated time is very short, and because the EAP WG is not chartered to review or standarize EAP methods, we are requesting that the presentations focus on providing the following information: 1. Basic info on the protocol Name: Intended media: (PPP, 802.11, PANA, PIC, etc.) Purpose/rationale (e.g. why it exists) Requested track (Standards, Experimental, Informational) Security claims: a. Mechanism (passwords, certs, token card, etc.) b. Mutual/one-way auth c. Key derivation 1. Supported? 2. Key size 3. Key hierarchy description d. Dictionary attack resistance e. Identity hiding f. Protection 1. Method negotiation 2. Ciphersuite negotiation 3. Success/failure indication 4. Method packets g. Fast reconnect IPR issues (see RFC 2026) 2. Issues encountered with RFC 2284 From bernarda@windows.microsoft.com Thu Nov 21 09:49:40 2002 From: bernarda@windows.microsoft.com (Bernard Aboba) Date: Thu, 21 Nov 2002 01:49:40 -0800 Subject: [eap] FW: Working Group ballot of P802.1aa/D4.1 Message-ID: If you have comments, post them to the EAP list and I will roll them up = in my "comments". -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Wed 11/20/2002 9:17 AM To: stds-802-1@ieee.org Cc: dstanley@agere.com; jesse.walker@intel.com; Tim Moore; = rhousley@rsasecurity.com; dhala@cisco.com Subject: Working Group ballot of P802.1aa/D4.1 =A0 This Email is attached to an official 802.1 Task Group ballot form for=20 P802.1aa/D4.1. As this is a full Working Group ballot, only 802.1 = voting=20 members and liaisons are entitled to vote; however, any non-voting=20 participants in the activities of the 802.1 Interworking Task Group may=20 submit a "Comment Only" ballot on the draft. The list of current voting members of 802.1 is as follows: Floyd Backes Les Bell Laura Bridge Paul Congdon Hesham Elbakoury Norm W. Finn Ran Ish-Shalom Neil Jarvis Tony Jeffree Hal Keen Loren Larsen Frank Reichstein Mick Seaman Michel Thorsen Michael D. Wright The following voting liaisons to 802.1 from 802.11 are entitled to vote = in=20 this ballot: David Halasz Russ Housley Tim Moore Dorothy Stanley Jesse Walker It should be noted that the ongoing retention of 802.1 voting rights is=20 predicated on active participation in Working Group ballots. Active=20 participation is defined to be returning ballot forms in two out of the=20 last three Working Group ballots. The 802 Operating Rules allow = abstention=20 for any cause other than "lack of technical expertise" to be treated as=20 though it were a failure to respond to a ballot. 802.1 applies this = rule. The closing date of this ballot is: 23rd December 2002 The PDF file of P802.1aa/D4.1 can be found at: http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4-1.pdf Username: p8021 Password: go_wildcats If you have any difficulty downloading or reading this file, let me = know. As is normal with such ballots, comments should specify not only what problems have been identified with the text, but also what the commenter proposes as a solution. Any comments accompanying the ballot should be presented using the following template: NAME: COMMENT TYPE: CLAUSE: PAGE: LINE: COMMENT START:
COMMENT END: SUGGESTED CHANGES START:
SUGGESTED CHANGES END: RETURNING YOUR BALLOT FORM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Your ballot must be returned to: stds-802-1@ieee.org You are requested to use (exactly!) the appropriate Subject line from the following set when returning your ballot. Please send your ballot with the Subject line explicitly set, rather than using the Reply function in your mailer. P802.1aa/D4.1 Ballot - Approve P802.1aa/D4.1 Ballot - Comments (with approve) P802.1aa/D4.1 Ballot - Disapprove P802.1aa/D4.1 Ballot - Comments (with abstain) P802.1aa/D4.1 Ballot - Abstain Regards, Tony Jeffree 802.1 Chair. ****************************** Ballot form follows..... ****************************** ------------------------------------------------------------------------ ------------------------------------------------------------------------ NOTE: EMAIL ALL BALLOT RESPONSES ONLY TO: stds-802-1@ieee.org ------------------------------------------------------------------------ ------------------------------------------------------------------------ P802.1aa/D4.1 EMAIL BALLOT 20th November 2002 TO: Tony Jeffree Editor, P802.1aa SUBJECT: P802.1aa/D4.1 - Multiple Spanning Trees _____ 802.1 Voting Member _____ 802.11 Voting Liaison _____ I Approve (may attach non-binding comments below) _____ I Disapprove (must attach binding comments below) _____ I Abstain for the following reasons (may attach non-binding = comments=20 below): ________ Lack of Time ________ Lack of Expertise ________ Other: _______________________________________________ _____ Comment Only - Non-voter (comments attached below) ____________________________________________ (Name) ____________________________________________ (Telephone No.) ------------------------------------------------------------------------ INCLUDE COMMENTS BELOW THIS POINT From aboba@internaut.com Fri Nov 22 23:19:23 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 22 Nov 2002 15:19:23 -0800 (PST) Subject: [eap] Meeting minutes Message-ID: If those who took minutes at IETF 55 can send them to myself and Jari, that would be helpful. We have Dorothy's so far (for session one) but nothing for session 2. Thanks! From aboba@internaut.com Fri Nov 22 23:21:59 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 22 Nov 2002 15:21:59 -0800 (PST) Subject: [eap] Presentations from IETF 55 Message-ID: are up at: http://www.drizzle.com/~aboba/EAP/eap55.zip If I'm missing your presentation, please send it to me. I don't think I have the latest version of the smartcard presentation, for example. From aboba@internaut.com Mon Nov 25 20:31:00 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 25 Nov 2002 12:31:00 -0800 (PST) Subject: [eap] Proposed resolution of Issue 42: Reject Message-ID: It is proposed that Issue 42: EAP Enhancements be rejected. Full text of the issue is available at: http://www.drizzle.com/~aboba/EAP/eapissues.html Rationale for rejection: Detection of disconnection is the responsibility of the link layer and is not an appropriate function for EAP, which focusses on authentication. RFC 2284 does not include support for PAP, since this represents an unacceptable security risk. Not only would PAP result in potential compromise of the password when used within EAP, but since the EAP-Message attribute is not encrypted within RADIUS, it would also expose the password between the NAS and RADIUS server. The Cause Code values can be accomodated within EAP Notification and therefore addition of another EAP method is not required. From paul@funk.com Tue Nov 26 02:31:18 2002 From: paul@funk.com (Paul Funk) Date: Mon, 25 Nov 2002 21:31:18 -0500 Subject: [eap] Proposed resolution of issue #41 Message-ID: <4.1.20021125211404.02741220@mail.funk.com> --=====================_1713331830==_.ALT Content-Type: text/plain; charset="us-ascii" Here is a proposed resolution of issue 41 - Nak of extended types. One thing I learned while writing this proposal: the past tense of Nak is "Nak'd", not "Naked". Out-of-scope changes -------------------------------- I've taken some liberties that go beyond the scope of this issue. Feel free to change things back to the way they were if there are objections: 1 I changed 255 to 254, on the theory that experimental use of EAP using type 255 is legacy behavior that should not be broken. 2 The original Vendor-specific type has everything after the Vendor-Id defined by the vendor, with the suggested format of Vendor-Type immediately following (RADIUS-style). I changed that to make the format uniform (Diameter-style), so all v-s types have a fixed format that includes Vendor-Type and are thus interpretable by anyone. Since Vendor-type is used as part of the protocol when Nak'ing, it's best to make sure everyone uses it the same way. I don't believe this limits vendor flexibility. Interesting implications of this proposal --------------------------------------------------------- Note that by using single-octet types and vendor-specific types in an interchangeable way, it is possible to extend EAP in all kinds of ways without breaking backward-compatibility. For example, if the authenticator starts the conversation with a vendor-specific type (as indicated by the first byte being 254), a legacy peer would Nak but a new peer could respond with a vendor-specific type (possibly a v-s Nak). Once both parties are talking vendor-specific, anything is possible. For example, the issue of bi-directional success and failure packets could be solved within this context. Proposed Text --------------------- 5.5. Vendor-specific Description Due to EAP's popularity, the original Method Type space, which only provides for 255 values, is being allocated at a pace, which if continued, would result in exhaustion within a few years. Since many of the existing uses of EAP are vendor-specific, the Vendor-Specific Method Type is available to allow vendors to support their own extended Types not suitable for general usage. The Vendor-specific type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible types onto a namespace of 2^32-1 possible types, allowing for virtually unlimited expansion. (Note that type 0 is never used.) An implementation that supports the Vendor-specific attribute MUST treat EAP types that are less than 256 equivalently whether they appear as a single octet or as the 32-bit Vendor-Type within a Vendor-specific type where Vendor-Id is 0. The single exception to this rule is the Nak type, as described below. Peers not equipped to interpret the Vendor-specific Type MUST send a Nak, and negotiate a more suitable authentication method. A summary of the Vendor-specific Type format is shown below. The fields are transmitted from left to right. 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 | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 254 for Vendor-specific Vendor-Id The Vendor-Id is 3 octets and represents the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as allocated by IANA. A Vendor-Id of zero is reserved for use by the IETF in providing an expanded global EAP Type space. Vendor-Type The Vendor-Type field is four octets and represents the vendor- specific Method Type. If Vendor-Id is zero, the Vendor-Type field is an extension and superset of the existing namespace for EAP types. The first 256 types are reserved for compatibility with single-octet EAP types that have already been assigned or may be assigned in the future. Thus, EAP types from 0 through 255 are semantically identical whether they appear as single octet EAP types or as Vendor-Types when Vendor-Id is zero. Vendor-Specific The Vendor-Specific field is dependent on the vendor's definition of that attribute. Where a Vendor-Id of zero is present, the Vendor- Specific field will be used for transporting the contents of EAP Methods of Types defined by the IETF. 5.5.1 Vendor-Specific Nak The Vendor-specific type may be Nak'd in either of two ways: Legacy Nak or Vendor-specific Nak 5.5.1.1 Legacy Nak The Legacy Nak, consisting of a single octet of value 3, is used to reject Vendor-specific requests entirely. This type of Nak indicates that the Vendor-specific type itself is unacceptable to the peer. This type of Nak provides backward compatibility for peers that implement RFC2284 or earlier. Peer implementations that do support the Vendor-specific type SHOULD NOT use this type of Nak, even as a shortcut to rejecting all possible Vendor-specific methods at once. Future specifications may depend on an authenticator being able to recognize the implementation level of the peer, and eliciting a Nak may provide a means of doing this. 5.5.1.2 Vendor-specific Nak The Vendor-specific Nak is a Nak within a Vendor-specific type with Vendor-Id of 0, as shown below: 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 = 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Types ... + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Desired Types field contains zero or more Vendor-specific Types, in order of preference, with the most preferred method first; each Type is In order to avoid an interminable negotiation, the Peer MUST only include Types that it is willing to accept. Each Type in the Desired Types field MUST be in the form of a Vendor-specific Type, even if it is a Type from the original namespace 1 - 255. The Vendor-specific Nak allows individual authentication methods expressed as Vendor-specific Types to be Nak'd, without rejecting the Vendor-specific Type in general. In addition, it permits the peer to list any authentication type -- whether IETF- or vendor- defined -- as acceptable. An example of a Vendor-specific Nak indicating that MD5-Challenge would be acceptable is shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_1713331830==_.ALT Content-Type: text/html; charset="us-ascii" Here is a proposed resolution of issue 41 - Nak of extended types.

One thing I learned while writing this proposal: the past tense of
Nak is "Nak'd", not "Naked".


Out-of-scope changes
--------------------------------
I've taken some liberties that go beyond the scope of this issue.
Feel free to change things back to the way they were if there
are objections:

1   I changed 255 to 254, on the theory that experimental use of
EAP using type 255 is legacy behavior that should not be broken.

2   The original Vendor-specific type has everything after the
Vendor-Id defined by the vendor, with the suggested format of
Vendor-Type immediately following (RADIUS-style). I changed that
to make the format uniform (Diameter-style), so all v-s types have
a fixed format that includes Vendor-Type and are thus interpretable
by anyone. Since Vendor-type is used as part of the protocol when
Nak'ing, it's best to make sure everyone uses it the same way. I
don't believe this limits vendor flexibility.


Interesting implications of this proposal
---------------------------------------------------------
Note that by using single-octet types and vendor-specific types
in an interchangeable way, it is possible to extend EAP in all
kinds of ways without breaking backward-compatibility. For example,
if the authenticator starts the conversation with a vendor-specific
type (as indicated by the first byte being 254), a legacy peer would
Nak but a new peer could respond with a vendor-specific type
(possibly a v-s Nak). Once both parties are talking vendor-specific,
anything is possible.

For example, the issue of bi-directional success and failure packets
could be solved within this context.


Proposed Text
---------------------

5.5.  Vendor-specific

Description

   Due to EAP's popularity, the original Method Type space, which only
   provides for 255 values, is being allocated at a pace, which if
   continued, would result in exhaustion within a few years.  Since many
   of the existing uses of EAP are vendor-specific, the Vendor-Specific
   Method Type is available to allow vendors to support their own
   extended Types not suitable for general usage.

   The Vendor-specific type is also used to expand the global Method
   Type space beyond the original 255 values. A Vendor-Id of 0 maps the
   original 255 possible types onto a namespace of 2^32-1 possible types,
   allowing for virtually unlimited expansion. (Note that type 0 is
   never used.)

   An implementation that supports the Vendor-specific attribute MUST
   treat EAP types that are less than 256 equivalently whether they
   appear as a single octet or as the 32-bit Vendor-Type within a
   Vendor-specific type where Vendor-Id is 0. The single exception
   to this rule is the Nak type, as described below.

   Peers not equipped to interpret the Vendor-specific Type MUST send a
   Nak, and negotiate a more suitable authentication method.

   A summary of the Vendor-specific Type format is shown below.  The
   fields are transmitted from left to right.

    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      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   254 for Vendor-specific

Vendor-Id

   The Vendor-Id is 3 octets and represents the SMI Network Management
   Private Enterprise Code of the Vendor in network byte order, as
   allocated by IANA. A Vendor-Id of zero is reserved for use by the
   IETF in providing an expanded global EAP Type space.

Vendor-Type

   The Vendor-Type field is four octets and represents the vendor-
   specific Method Type.

   If Vendor-Id is zero, the Vendor-Type field is an extension and
   superset of the existing namespace for EAP types. The first 256
   types are reserved for compatibility with single-octet EAP types
   that have already been assigned or may be assigned in the future.
   Thus, EAP types from 0 through 255 are semantically identical
   whether they appear as single octet EAP types or as Vendor-Types
   when Vendor-Id is zero.

Vendor-Specific

   The Vendor-Specific field is dependent on the vendor's definition of
   that attribute. Where a Vendor-Id of zero is present, the Vendor-
   Specific field will be used for transporting the contents of EAP
   Methods of Types defined by the IETF.

5.5.1 Vendor-Specific Nak

   The Vendor-specific type may be Nak'd in either of two ways: Legacy
   Nak or Vendor-specific Nak

5.5.1.1 Legacy Nak

   The Legacy Nak, consisting of a single octet of value 3, is used to
   reject Vendor-specific requests entirely. This type of Nak indicates
   that the Vendor-specific type itself is unacceptable to the peer.
   This type of Nak provides backward compatibility for peers that
   implement RFC2284 or earlier.

   Peer implementations that do support the Vendor-specific type SHOULD
   NOT use this type of Nak, even as a shortcut to rejecting all possible
   Vendor-specific methods at once. Future specifications may depend on
   an authenticator being able to recognize the implementation level of
   the peer, and eliciting a Nak may provide a means of doing this.

5.5.1.2 Vendor-specific Nak

   The Vendor-specific Nak is a Nak within a Vendor-specific type with
   Vendor-Id of 0, as shown below:

    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 = 254   |            Vendor-Id = 0                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor-Type = 3                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Desired Types ...
   +
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Desired Types field contains zero or more Vendor-specific
   Types, in order of preference, with the most preferred method
   first; each Type is In order to avoid an interminable negotiation,
   the Peer MUST only include Types that it is willing to accept.

   Each Type in the Desired Types field MUST be in the form of a
   Vendor-specific Type, even if it is a Type from the original
   namespace 1 - 255.

   The Vendor-specific Nak allows individual authentication methods
   expressed as Vendor-specific Types to be Nak'd, without rejecting
   the Vendor-specific Type in general. In addition, it permits the
   peer to list any authentication type -- whether IETF- or vendor-
   defined -- as acceptable.

   An example of a Vendor-specific Nak indicating that MD5-Challenge
   would be acceptable is shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      254      |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               3                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               4                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_1713331830==_.ALT-- From aboba@internaut.com Wed Nov 27 19:25:10 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:25:10 -0800 (PST) Subject: [eap] Issue 43: Security Claims Message-ID: Issue 43: Security Claims Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 25, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 6 Rationale/Explanation of issue: RFC 2284bis does not include definitions of Security Claims or guidance as to how they are to be treated. Proposed change: Delete Section 7.2, and add the following sections to Section 6: 6.3. Security claims In order to clearly articulate the security provided by an EAP method, EAP method specifications accompanying a request for allocation of a Type code MUST include the following declarations: [a] Intended use. This includes a statement of whether the method is intended for use over a physically secure or insecure network, as well as a statement of the applicable media. [b] Mechanism. This is a statement of the authentication technology: certificates, pre-shared keys, passwords, token cards, etc. [c] Security claims. This is a statement of the claimed security properties of the method, using terms defined in the next section. The Security Claims section SHOULD include references to proof, or the proof itself (preferrably in an Appendix). [d] Key strength. If the method derives keys, then the effective key strength MUST be provided. [e] Description of key hierarchy. EAP methods deriving keys MUST either provide a reference to a key hierarchy specification, or describe how keys for authentication/integrity, encryption and IVs are to be derived from the provided keying material, and how cryptographic separation is maintained between keying material used for different purposes. [f] Indication of vulnerabilities. In addition to the security claims that are made, the specification MUST indicate which of the security claims detailed in the next section are NOT being made, and discuss the security implications. 6.4. Security terms Mutual authentication This refers to a method in which, within a single conversation, the Authenticator authenticates the Peer and the Peer authenticates the Authenticator. Two one-way conversations, running in opposite directions, do not provide mutual authentication as defined here. Integrity protection This refers to authentication and integrity protection of EAP messages, including EAP Requests and Responses of types Identity, Nak and Notification, as well as EAP Requests and Responses, and success and failure indications. Replay protection This refers to replay protection of EAP messages, including EAP Requests and Responses of types Identity, Nak and Notification, as well as EAP Requests and Responses, and success and failure indications. Confidentiality This refers to encryption of EAP messages, including EAP Requests and Responses of types Identity, Nak and Notification, as well as EAP Requests and Responses, and success and failure indications. A method making this claim MUST therefore also include support for identity protection. Key derivation This refers to the ability of the EAP method to derive ciphersuite-independent master session keys, used only for further key derivation, as detailed in [KEYS]. Key strength This refers to the effective entropy of the derived master session keys, independent of their physical length. For example, a 128-bit key derived from a password might have an effective entropy much less than 128 bits. Dictionary attack resistance Where password authentication is used, users are notoriously prone to selection of poor passwords. A method may be said to be dictionary attack resistant if a brute force attack would require, on average, sorting through 2^64 or more possibilities. This can be accomplished, for example, by avoiding the use of passwords altogether (e.g. certificates, token cards), or by using a shared secret with sufficiently high entropy. Fast reconnect The ability, in the case where a security association has been previously established, to create a new or refreshed security association in 2.5 round-trips or less (excluding an Identity exchange). including EAP Requests and Responses of types Identity, Nak and Notification, as well as EAP Requests and Responses, and success and failure indications. Man-in-the-Middle resistance The ability, for the peer to demonstrate to the authenticator that it has acted as the peer for each method within a sequence of methods or tunnel. Similarly, the authenticator demonstrates to the peer that it has acted as the authenticator for each method within the sequence or tunnel. If this is not possible, then the authentication sequence or tunnel may be vulnerable to a man-in-the-middle attack. Acknowledged Success/Failure indications The ability of the Peer to provide the Authenticator with a Success/Failure indication in response to such an indication sent from the Authenticator to the Peer. Since cleartext success/failure indications can be spoofed, making this claim requires that the acknowledged Success/Failure exchange be integrity protected. From aboba@internaut.com Wed Nov 27 19:34:52 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:34:52 -0800 (PST) Subject: [eap] Issue 41: NAK of Extended Types Message-ID: Issue 41: NAK of Extended Types 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.3 Rationale/Explanation of issue: Currently it is not possible to effectively NAK within the Extended EAP type space. For example, what happens when the authenticator proposes an Extended or Vendor-Specific EAP Type, and the client supports the Extended type (255), but not the vendorID or Extended Type that is being proposed? Here is the example Extended Type 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proposed solution: Change: "Description 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 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. As a result, a NAK is only sent in response to a method proposal and MUST NOT be sent in the middle of an EAP method conversation. Type-Data This field MUST contain zero or more octets indicating the desired authentication Types, in order of preference, with the most preferred method first. In order to avoid an interminable negotiation, the Peer MUST only include Types that it is willing to accept." To: "Description 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 4 and above. The Response contains zero or one authentication Type desired by the peer. A Nak with no authentication Type 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. As a result, a NAK is only sent in response to a method proposal and MUST NOT be sent in the middle of an EAP method conversation. Type-Data Where the desired authentication Type is within the original EAP Type space (1-254), the Type-Data field, when present, MUST contain a single octet indicating the desired authentication Type. Where the desired authentication Type is a method within the extended EAP Type space (Type=255), the Type-Data field is formatted as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From aboba@internaut.com Wed Nov 27 19:42:17 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:42:17 -0800 (PST) Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP Message-ID: Issue 44: Peer-to-Peer Operation of EAP Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 25, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: Since EAP is a peer-to-peer protocol, this should be added to the description of how the protocol operates. Add the following text to section 2: "[7] Since EAP is a peer-to-peer protocol, after authentication in one direction is complete, the direction of authentication MAY reverse, with the endpoint previously serving as the Authenticator assuming the Peer role, and the former Peer now taking on the Authenticator role. As with the original conversation, the reversal is signaled by the (new) Authenticator sending a Request." From aboba@internaut.com Wed Nov 27 19:43:46 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:43:46 -0800 (PST) Subject: [eap] Recommended resolution of Issue 42: Reject Message-ID: Recommended Resolution: Reject Detection of disconnection is the responsibility of the link layer and is not an appropriate function for EAP, which focusses on authentication. RFC 2284 does not include support for PAP, since this represents an unacceptable security risk. Not only would PAP result in potential compromise of the password when used within EAP, but since the EAP-Message attribute is not encrypted within RADIUS, it would also expose the password between the NAS and RADIUS server. The Cause Code values can be accomodated within EAP Notification and therefore addition of another EAP method is not required. From jari.arkko@piuha.net Wed Nov 27 18:53:11 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 27 Nov 2002 20:53:11 +0200 Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP References: Message-ID: <3DE51497.9090604@piuha.net> Bernard Aboba wrote: > Since EAP is a peer-to-peer protocol, this should be added to the > description of how the protocol operates. > > Add the following text to section 2: > > "[7] Since EAP is a peer-to-peer protocol, after authentication in one > direction is complete, the direction of authentication > MAY reverse, with the endpoint previously serving as the Authenticator > assuming the Peer role, and the former Peer now taking on the > Authenticator role. As with the original conversation, the reversal is > signaled by the (new) Authenticator sending a Request." Hmm... this has interesting implications for the state machine design! Is there any possibility of having two "instances" of EAP running in different directions instead of doing both for the same EAP run? Can EAP "host" protocols such as PPP or 802.1X allow more than one EAP "run"? What about backwards compatibility? I suppose on PPP most implementations would allow this, right? What about 802.1X? Jari From aboba@internaut.com Wed Nov 27 19:53:04 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:53:04 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 40: Accept 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: http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt Document: RFC2284bis-07 Comment type: T Priority: S Section: 7.4 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. Suggested changes Add Section 7.4: 7.4 Man-in-the-middle attacks Where a sequence of methods is utilized for authentication or is tunneled within another protocol that omits peer authentication, there exists a potential vulnerability to man-in-the-middle attack. Where a sequence of EAP methods is utilized for authentication, the peer might not have proof that a single entity has acted as the authenticator for all EAP methods within the sequence. For example, an authenticator might terminate one EAP method, then forward the next method in the sequence to another party without the peer's knowlege or consent. Similarly, the authenticator might not have proof that a single entity has acted as the peer for all EAP methods within the sequence. This enables an attack by a rogue EAP authenticator tunneling EAP to a legitimate server. Where the tunneling protocol is used for key establishment but does not require peer authentication, an attacker convincing a legitimate peer to connect to it will be able to tunnel EAP packets to a legitimate server, successfully authenticating and obtaining the key. This allows the attacker to successfully establish itself as a man-in-the-middle, gaining access to the network, as well as the ability to decrypt data traffic between the legitimate peer and server. This attack may be mitigated by the following measures: [a] Requiring mutual authentication within EAP tunneling mechanisms. [b] Requiring cryptographic binding between EAP methods executed within a sequence or between the EAP tunneling protocol and the tunneled EAP methods. [c] Limiting the EAP methods authorized for use without protection based on peer and authenticator policy. " From aboba@internaut.com Wed Nov 27 19:57:09 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 11:57:09 -0800 (PST) Subject: [eap] Recommended resolution of Issue 32: Accept 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. Proposed Resolution: Accept From jari.arkko@piuha.net Wed Nov 27 19:06:40 2002 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 27 Nov 2002 21:06:40 +0200 Subject: [eap] Proposed Resolution to Issue 40: Accept References: Message-ID: <3DE517C0.80609@piuha.net> Bernard Aboba wrote: > This attack may be mitigated by the following measures: > [a] Requiring mutual authentication within EAP tunneling mechanisms. > [b] Requiring cryptographic binding between EAP methods executed within a > sequence or between the EAP tunneling protocol and the tunneled EAP > methods. > [c] Limiting the EAP methods authorized for use without protection based > on peer and authenticator policy. " [d] Avoiding the use of sequences or tunnels when a single, strong method is available? From aboba@internaut.com Wed Nov 27 20:02:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 12:02:31 -0800 (PST) Subject: [eap] Proposed resolution of Issue 14: Accept Message-ID: Issue 14: EAP transport behavior not specified Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 25, 2002 Reference: Document: RFC2284bis Comment type: T Priority: 1 Section: 4.1 Rationale/Explanation of issue: RFC 2284 does not adequately specify EAP's transport behavior. The EAP implementation survey results indicate that implementations do not use the default retransmission timer of 6 seconds as specified in RFC 2284. In fact, much lower values are often used, sometimes so low that the EAP-Request can be retransmitted prior to arrival of the EAP-Response. This causes problems if the NAS sends a duplicate AAA Request as a result. Similarly, when EAP is run over reliable transport (such as within PIC, which can run over ISKAMP/TCP), it is possible for retransmissions to occur at multiple layers of the stack. Change: "Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. For use in PPP, it is suggested a retransmission timer of 6 seconds with a maximum of 10 retransmissions be used as default. One may wish to make these timeouts longer in certain cases (e.g. where Token Cards are involved). Additionally, the Peer must be prepared to silently discard received retransmissions while waiting for user input." To: "Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer (EAP_RTO) SHOULD be computed as described in [RFC2988]. A maximum of 3-5 retransmissions is suggested. When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Where the authentication process requires user input, the measured round trip times are largely be determined by user responsiveness rather than network characteristics, so that RTO estimation is not helpful. Instead, the retransmission timers SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the Authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). Additionally, the Peer MUST be prepared to silently discard received retransmissions while waiting for user input, so as to mitigate the ill effects of a too small retransmission timer." From aboba@internaut.com Wed Nov 27 20:10:57 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 12:10:57 -0800 (PST) Subject: [eap] Issue 45: Addition of OTP and GTC methods Message-ID: Issue 45: Addition of OTP and GTC methods Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 25, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: Now that RFC 2284bis is merely recycling to Proposed Standard, there is no reason to separate out the OTP and GTC methods. Also, the OTP reference in RFC 2284 is now out of date. Add the following sections: One-Time Password (OTP) Description The One-Time Password system is defined in "A One-Time Password System" [RFC2289] and "OTP Extended Responses" [RFC 2243]. The Request contains a displayable message containing an OTP challenge. A Response MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type(s). Type 5 Type-Data The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [RFC2289]. The messages MUST not be null terminated. The length of the field is derived from the Length field of the Request/Reply packet. Generic Token Card (GTC) Description The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains a displayable message and the Reply contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text. Type 6 Type-Data The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet. From rodrigo.garces@mobilitynetworks.com Wed Nov 27 22:14:03 2002 From: rodrigo.garces@mobilitynetworks.com (Garces, Rodrigo) Date: Wed, 27 Nov 2002 14:14:03 -0800 Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP Message-ID: <9E4B2EDBC48E0F48B9B8F968F817928D17475B@mail1.mobility.int> I do not think that 802.1X allows this switch.=20 Rodrigo -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Wednesday, November 27, 2002 10:53 AM To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 44: Peer-to-Peer Operation of EAP Bernard Aboba wrote: > Since EAP is a peer-to-peer protocol, this should be added to the > description of how the protocol operates. >=20 > Add the following text to section 2: >=20 > "[7] Since EAP is a peer-to-peer protocol, after authentication in one > direction is complete, the direction of authentication > MAY reverse, with the endpoint previously serving as the Authenticator > assuming the Peer role, and the former Peer now taking on the > Authenticator role. As with the original conversation, the reversal is > signaled by the (new) Authenticator sending a Request." Hmm... this has interesting implications for the state machine design! Is there any possibility of having two "instances" of EAP running in different directions instead of doing both for the same EAP run? Can EAP "host" protocols such as PPP or 802.1X allow more than one EAP "run"? What about backwards compatibility? I suppose on PPP most = implementations would allow this, right? What about 802.1X? Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Nov 27 21:30:25 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 13:30:25 -0800 (PST) Subject: [eap] Resolution of Issue 2 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: 2.1, 3.2.1, 3.3.1, 3.3.2, 3.4, 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. 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." Insert Section 2.1: "Success and failure indications Within EAP, success and failure indications may be protected or unprotected. EAP Success and Failure messages are unprotected indications which may be spoofed, since they are sent in cleartext and contain no embedded message integrity check. However, individual EAP methods may include support for acknowledged and protected success and failure indications. Where a protected success/failure indication has been received at the EAP layer by an EAP peer, it MUST accept and process the protected indication. Subsequent unprotected success or failure EAP layer indications MUST be silently discarded by the peer if they contradict the protected indication. For example, if the Peer is configured to require an EAP method providing mutual authentication, then it MUST silently discard a Success packet sent by the Authenticator, prior to the conclusion of mutual authentication. In the absence of a protected EAP layer indication, unprotected EAP layer failure indications MAY be accepted and processed by the EAP implementation. This can result in a denial of service attack. Unprotected EAP layer success indications are only accepted and processed once methods have completed successfully. Whether authentication is mandatory is determined by the Authenticator and Peer configurations. If authentication is not required by the Authenticator, or if the identity of the Peer is verified by another mechanism (e.g. Calling-Station-ID or MAC address), then the Authenticator MAY send a "canned" Success message. However, the Peer may be configured to require the Authenticator to authenticate itself prior to being willing to process a Success message." Insert Section 3.4 : Link layer indications The reliability and security of link layer indications is dependent on the medium. Link layer failure indications accepted by the link layer and provided to EAP MUST be processed. However, as described in Section 2.1, only EAP layer success/failure indications (not link layer success indications) can cause an EAP implementation to conclude that authentication has succeeded. In PPP, link layer indications are not authenticated. They are therefore subject to spoofing. This includes LCP-Terminate (a link failure indication) and NCP (a link success indication). In PPP, a "link down" indication is considered a reliable indication of link failure. In 802.11, control and management frames are not authenticated and are therefore subject to spoofing. This includes Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). In IEEE 802 wired networks, the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated, whereas within 802.11, authentication is possible depending on when they are sent and the ciphersuite that has been negotiated. Therefore, depending on the circumstances, EAPOL-Start and EAPOL-Logoff frames may or may not be subject to spoofing. In 802.11 a "link down" signal is considered an unreliable indication of link failure, since wireless signal strength can come and go." From aboba@internaut.com Wed Nov 27 21:38:08 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 13:38:08 -0800 (PST) Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP In-Reply-To: <3DE51497.9090604@piuha.net> Message-ID: > Hmm... this has interesting implications for the state machine > design! Is there any possibility of having two "instances" of > EAP running in different directions instead of doing both for the > same EAP run? Can EAP "host" protocols such as PPP or 802.1X > allow more than one EAP "run"? > > What about backwards compatibility? I suppose on PPP most implementations > would allow this, right? What about 802.1X? Since PPP is a peer-to-peer protocol, and EAP was developed as part of PPP, peer-to-peer operation is one of the implicit assumptions of EAP. While IEEE 802.1X appears at first glance to be a client-server protocol, it is possible for a peer to implement both Supplicant and Authenticator roles, and in fact, this is required for adhoc operation within IEEE 802.11. So this Issue does not really represent new functionality, but rather clarifying functionality that has been in EAP from the beginning (but which many implementations have missed). Another implication of this occurs within RFC 2869bis, where it has been suggested that RADIUS/EAP should be capable of handling role reversal, thereby carrying an EAP-Request within a RADIUS Access-Request. There is no intrinsic reason why RADIUS cannot do this -- after all, it's just an encapsulation. However, a given RADIUS server may not handle it -- in which case I think that the proper behavior is probably sending an Access-Reject without an embedded EAP-Message attribute. No EAP-Message attribute can be sent because an EAP peer cannot send an EAP-Failure to an Authenticator, and therefore there is no EAP message that means "I don't support role reversal". From aboba@internaut.com Wed Nov 27 21:43:32 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 13:43:32 -0800 (PST) Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP In-Reply-To: <9E4B2EDBC48E0F48B9B8F968F817928D17475B@mail1.mobility.int> Message-ID: > I do not think that 802.1X allows this switch. It's possible for a client to support both Supplicant and Authenticator roles, and in fact this is required in 802.11i adhoc mode. From jose.p.puthenkulam@intel.com Wed Nov 27 23:36:13 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 27 Nov 2002 15:36:13 -0800 Subject: [eap] Proposed Resolution to Issue 40: Accept Message-ID: >> This attack may be mitigated by the following measures: >> [a] Requiring mutual authentication within EAP tunneling mechanisms. >> [b] Requiring cryptographic binding between EAP methods executed within a >> sequence or between the EAP tunneling protocol and the tunneled EAP >> methods. >> [c] Limiting the EAP methods authorized for use without protection based >> on peer and authenticator policy. " >[d] Avoiding the use of sequences or tunnels when a single, strong >method is available? IMHO, I don't think [d] is appropriate. Because it implies that man-in-the-attacks warrant the avoidance of tunnels or sequences which sounds a bit drastic. cheers, jose -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Wednesday, November 27, 2002 11:07 AM To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 40: Accept Bernard Aboba wrote: > This attack may be mitigated by the following measures: > [a] Requiring mutual authentication within EAP tunneling mechanisms. > [b] Requiring cryptographic binding between EAP methods executed within a > sequence or between the EAP tunneling protocol and the tunneled EAP > methods. > [c] Limiting the EAP methods authorized for use without protection based > on peer and authenticator policy. " [d] Avoiding the use of sequences or tunnels when a single, strong method is available? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Nov 27 22:59:01 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 14:59:01 -0800 (PST) Subject: [eap] Recommended Resolution of Issue 23: Reject 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: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 23 Document: RFC2284bis-04 Comment type: T Priority: S Section: 5.1 Resolution: This issue was discussed in depth within the EAP State Machine design team and consensus was not reached. In most cases (though not all), EAP is used in situations where the network to which the peer is connecting is known, either because it is preconfigured (PPP, L2TP, PIC), or due to an advertisement that is received out-of-band (PPPOE, 802.11, 802.1ad, CARD). A possible exception to this is IEEE 802 wired networks where there is currently no advertisement/discovery mechanism. However, one is under development, so that it is possible that it too may provide the peer with indication of what network it is connected to. Another possible exception is IEEE 802.1X pre-authentication which occurs prior to association. Where multiple SSIDs are advertised, each with the same BSSID, it may not be possible to know which network is being pre-authenticated to. However, advertising multiple SSIDs with a single BSSID does not work reliably today anyway, due to station limitations and if each SSID has its own BSSID then the problem goes away. Given that it already appears that a solution exists without adding functionality to EAP, the case for adding this to the EAP-Request/Identity message cannot be made. If there is another reason for doing this, please open another issue describing that (new) case. From aboba@internaut.com Thu Nov 28 00:39:15 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 16:39:15 -0800 (PST) Subject: [eap] Issue 46: Passthrough clarification Message-ID: Issue 46: Passthrough clarification Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 25, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: There is some confusion about whether a AAA Server is always required for use with EAP and whether an Authenticator MUST be a "passthrough" for all traffic or no traffic. Insert the following paragraph in Section 2: "Since a backend authentication server is optional, an Authenticator MAY implement one or more authentication methods locally in order to authenticate local users. An Authenticator MAY act as a "pass through" for non-local users and authentication methods it does not implement, while at the same time authenticating local users with native methods." From aboba@internaut.com Thu Nov 28 01:30:55 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 17:30:55 -0800 (PST) Subject: [eap] Resolution of Issue 7: Accept 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: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 7 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. Recommended resolution: Add the following text to section 2: "If the Peer does not support sequences, it SHOULD respond to the additional Request with a Nak, and no alternative method. However, peer implementations MAY not respond at all, in which case a timeout will result and authentication will fail. Since the Authenticator presumably requires successful completion of the authentication sequence in order to grant access, authentication failure is the intended result. Therefore, it is not necessary for the Authenticator to determine that the peer supports sequences prior to prompting for an additional authentication method." From aboba@internaut.com Thu Nov 28 02:00:12 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 18:00:12 -0800 (PST) Subject: [eap] Resolution of Issue 25: Accept 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: 2.2, 7.7 Proposed resolution: Delete Section 7.7. Add the following text to Section 2.2: "The EAP layer provides sequencing and duplicate elimination to EAP methods. During the period after an EAP Peer receives an EAP-Request, but has not yet sent an EAP-Response, the Peer EAP layer MUST silently discard additional EAP packets upon reception, rather than providing them to the EAP method. This occurs whether the received packet is a duplicate (same Identifier) or not (different Identifier). This provides an opportunity for a denial of service attack: an attacker can swamp a Peer with EAP Requests, preventing valid EAP Requests from being processed. Addressing this requires an EAP method to be able to indicate to the EAP layer that it wants to handle duplicate elimination and packet validation itself, which is not supported." From aboba@internaut.com Thu Nov 28 06:28:29 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 27 Nov 2002 22:28:29 -0800 (PST) Subject: [eap] Request for review Message-ID: A strawman -08 version of RFC 2284bis is available for inspection at: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-08.txt In order to validate the proposed Issue resolutions and find additional Issues, we are requesting that as many EAP WG members as possible read the strawman -08 document. The format for Issues submission is available on the EAP WG Issues web page at: http://www.drizzle.com/~aboba/EAP/eapissues.html Any help that EAP WG members can provide is appreciated. Please send comments to the editor (aboba@internaut.com) and to the EAP WG mailing list (eap@frascone.com). From aboba@internaut.com Thu Nov 28 13:01:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 28 Nov 2002 05:01:43 -0800 (PST) Subject: [eap] Proposed resolution of Issue 37: Accept 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. Add Section 2.1: "The EAP layer provides sequencing and duplicate elimination to EAP methods. During the period after an EAP Peer receives an EAP-Request, but has not yet sent an EAP-Response, the Peer EAP layer MUST silently discard additional EAP packets upon reception, rather than providing them to the EAP method. This occurs whether the received packet is a duplicate (same Identifier) or not (different Identifier). Similarly, during the period after an EAP Authenticator receives an EAP-Response, but has not yet sent an EAP-Request, the Authenticator EAP layer MUST silently discard additional EAP packets upon reception, rather than providing them to the EAP method. This provides an opportunity for a denial of service attack: an attacker can swamp a Peer with EAP Requests, preventing valid EAP Requests from being processed. Addressing this requires an EAP method to be able to indicate to the EAP layer that it wants to handle duplicate elimination and packet validation itself. This is not supported. 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, with some exceptions. 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 unacceptable Type with a Nak Response. Authenticators receiving an EAP Response with a Type for which the authenticator has no outstanding Request MUST silently discard the Response. The Notification method may be considered to reside within the EAP layer. While a Notification Request may be generated at the behest of an EAP method residing on the authenticator, a Notification Response is typically generated automatically by the peer EAP layer, so that it can only be used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request is available to another method. The Identity Request may also be generated at the behest of an EAP method residing on the authenticator. However, the Identity Response can be assumed to be stored within the EAP layer so as to be available to methods of types other than 1 (Identity). EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Given these considerations, 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 below."