From urienp@libertysurf.fr Sat Mar 1 22:31:29 2003 From: urienp@libertysurf.fr (Pascal Urien) Date: Sat, 01 Mar 2003 23:31:29 +0100 Subject: [eap] EAP support in smartcard version 01 Message-ID: <5.1.0.14.0.20030301233047.00b25b70@pop.libertysurf.fr> --=====================_2580330==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Every body, New version of the internet draft draft-urien-EAP-smartcard-01.txt - EAP support in smartcard has been dowloaded to the IETF web site. I hope to meet you again during the next IETF meetinf in SF Regards Pascal Urien --=====================_2580330==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-urien-EAP-smartcard-01.txt" Internet Draft P.Urien=20 Document: draft-urien-EAP-smartcard-01.txt A.J. Farrugia=20 M.Groot=20 G.Pujolle=20 Expires: August 2003=20 =20 EAP-Support in smartcard=20 =20 =20 Status=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC 2026.=20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsolete by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html. =20 =20 Abstract=20 =20 This document will describe the interface to the EAP protocol in=20 smartcards, which could store multiple identities associated to=20 Network Access Identifiers.=20 =20 =20 Urien & All Informational - Expires August 2003 1 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Table of Contents=20 =20 Status.............................................................1=20 Abstract...........................................................1=20 Table of Contents..................................................2=20 Overview...........................................................2=20 Terms..............................................................3=20 Identification label...............................................4=20 Identification Label Coding Rules..................................4=20 Add-Identity.......................................................5=20 Delete-Identity....................................................5=20 Get-Preferred-Identity.............................................5=20 Get-Next-Identity..................................................5=20 Get-Subscriber-Profile.............................................6=20 Set-Identity.......................................................6=20 EAP-Packets........................................................6=20 Get-Pairwise-Master-Key (PMK)......................................6=20 ISO 7816-4 APDUs...................................................7=20 Add-Identity....................................................7=20 Delete-Identity.................................................7=20 Get-Preferred-Identity..........................................8=20 Get-Next-Identity...............................................8=20 Get-Subscriber-Profile..........................................8=20 Set-Identity....................................................8=20 EAP-Packets.....................................................8=20 Get-Pairwise-Master-Key.........................................9=20 State Machine Sequence............................................10=20 Security Considerations...........................................10=20 General Considerations.........................................10=20 PEAP Consideration.............................................10=20 Intellectual Property Right Notice................................11=20 Annex 1 (Informative) - EAP/SIM packet detail.....................11=20 Annex 2 (Informative) - EAP/MD5 packet details.................15=20 Annex 3 (Informative) TLS support.................................17=20 Fragment maximum size..........................................17=20 EAP/TLS messages format........................................17=20 Example of EAP/TLS Authentication..............................17=20 Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile=20 information.......................................................18=20 References........................................................18=20 Author's Addresses................................................19=20 =20 =20 Overview=20 =20 All technologies derived from 802.11 specifications such as 802.11a,=20 802.11b, 802.11g need a strong security protocols for data privacy,=20 integrity and network access. Where the 802.1X [8] specification=20 describes the risks and the protocols for the protection of the=20 exchanged data during the network connection. The very same=20 Urien & All Informational - Expires August 2003 2 =0C =20 Integrating EAP in smartcards March 2003=20 =20 specification remains compatible with other standard for the=20 authentication and the network access.=20 802.1X specification requires the Extensible Authentication Protocol=20 (EAP) to be used as the framework for application dependent=20 authentication processes with a mutual authentication between the=20 supplicant and the authenticator. It is obvious that the role of the=20 supplicant in this specification has partly been implemented in the=20 smart card has an authentication processing mean. The flexibility of=20 EAP (RFC 2284) specification does not provide a Mandatory-to- implement solution. The structure of the EAP frames allows the=20 applications to identify the EAP type of consequently to operate the=20 appropriate authentication.=20 Terms=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119.=20 =20 Authentication Agent: A piece of software implemented in the=20 supplicant that processes the authentication sequence.=20 =20 AS=20 Authentication Server=20 =20 Authenticator: See the IEEE 802.1X specification for a definition of=20 this concept.=20 =20 EAP=20 Extensible Authentication Protocol.=20 =20 GSM=20 Global System for Mobile communications.=20 =20 IMSI=20 International Mobile Subscriber Identifier, used in GSM to =20 identify subscribers.=20 =20 NAI=20 Network Access Identifier=20 =20 PMK=20 Pairwise Master Key=20 =20 SIM=20 Subscriber Identity Mobile=20 =20 Supplicant: an IEEE 802.1X concept, which in the context of IEEE=20 802.11 represents a STA (station) seeking to attach to an IEEE 802=20 LAN via an IEEE 802.1X Port. See the IEEE 802.1X specification for a=20 complete definition=20 Urien & All Informational - Expires August 2003 3 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Identification label=20 =20 802.1X specification [5] requires an authentication between the=20 authenticator or the authentication server (AS) and the supplicant.=20 The authentication is embedded in the Extensible Authentication=20 Protocol (EAP) RFC2284 [1] specification. The authentication=20 consists of a challenge response between both parties without=20 consideration of the involved crypto-suite. Before starting the=20 mutual authentication, the AS needs the supplicant identity to=20 establish the session. The AS or the authenticator sends an EAP=20 Request Identity to the supplicant that returns its system identity.=20 A user may own several identities likely associated to the network=20 operators.=20 =20 The identification label is a pointer to a system identity stored in=20 smartcard; it may be of various types:=20 =20 1. A network SSID as described in the 802.11 standard [4].=20 2. A user=92s identification (userid) e.g. an ASCII string. A network=20 access identifier, NAI [6] may be used as userid.=20 3. A pseudonym, e.g. a friendly name. =20 According to the network environment, the supplicant software needs=20 to set the appropriate identity and verifies if the smart card is=20 able to mirror the authenticator.=20 =20 If the smart card is not able to process the authentication related=20 to the identity then any setting process is rejected by the NAK=20 code.=20 =20 The subsequent sections give the description of the methods used by=20 a supplicant for processing an 802.1X authentication using the smart=20 card.=20 =20 Annex one provides a reference implementation example for a SIM=20 based authentication. Annex two provides a reference implementation=20 example for a MD5 based authentication. Annex three provides a=20 reference implementation for a TLS based authentication.=20 =20 Identification Label Coding Rules=20 =20 The Get-Next-Identity section didn=92t define the coding rules of the=20 identification label. This section describes the structure and the=20 architecture of the userid. =20 =20 A userid consists of 2 fields separated by the Internet symbol "@".=20 The right hand side of the "@" symbol is the userid realms while the=20 left hand side is an application dependent and unique identification=20 number. EAP/SIM has defined the userid where the application=20 identification is "1IMSI". Other userid such as email address can be=20 used by the application.=20 =20 Urien & All Informational - Expires August 2003 4 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Add-Identity=20 =20 This command and the Delete-Identity are part of the user=92s identity=20 management protocols. The smart card is initially manufactured=20 without any identification label. The personalization or the=20 supplicant software adds in the smart card user=92s identification=20 label that can be retrieved by other smart card command.=20 =20 If the smart card manages pseudonyms the command does not allows=20 setting the user pseudonyms. The smart card command only adds=20 permanent identification label in the list.=20 =20 Delete-Identity=20 =20 This command and the add-Identity are part of the user=92s identity=20 management protocols. The smart card contains a list of one or=20 several identification labels that can be retrieved by the=20 supplication software. The command deletes one entry of the smart=20 card list.=20 =20 Get-Preferred-Identity=20 =20 The smart card contains at least one user=92s identity related to the=20 user=92s network subscription. The supplicant software gets from the=20 smart card the initial and preferred identification label. If the=20 user has more than one identities the supplicant software uses the=20 Get-Next-Identity to read all the available other user=92s identities.=20 If the smart card manages pseudonyms and a pseudonym is available as=20 preferred identity, the Get-Preferred-Identity shall return the=20 pseudonym.=20 =20 Get-Next-Identity=20 =20 The smart card may contain one or more user=92s identities according=20 to the user=92s network subscriptions. The supplicant software should=20 prompt the user=92s identity and a subsequent selection allows the=20 smart card to process the appropriate EAP authentication type. The=20 method Get-Next-Identity allows the supplicant software to read all=20 the available user=92s identities.=20 =20 The Get-Next-Identity method may inform the supplicant software when=20 all user=92s identities have been read. Otherwise the supplicant=20 software detects the identity list end when it gets again the first=20 identity.=20 =20 If the smart card contains a pseudonym management and the pseudonym=20 is (are) available the Get-Next-Identity returns the appropriate=20 pseudonym. If the pseudonym management is not supported, the smart=20 card returns the permanent Identity according to the previous=20 section.=20 =20 Urien & All Informational - Expires August 2003 5 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Get-Subscriber-Profile=20 =20 The Authentication Agent or the authenticator may request the=20 subscriber profile information. The Get-Subscriber-Profile returns=20 all related information available in the smart card. This=20 specification does not provide the detail of the subscriber profile=20 information. The implementation of the information may be ruled but=20 ASN.1 BER coding specification [9] or by an XML dialect [10].=20 Set-Identity=20 =20 Once the Identity selection is processed, the supplicant software=20 needs to set the smart card EAP framework according to the selected=20 user=92s identity. The Set-Identity sets or restarts the smart card=20 EAP framework state machine for further processing using the EAP- Packets method.=20 =20 The supplicant software can set the EAP framework using the=20 pseudonym if available in the smart card. If the pseudonym is not=20 available the supplicant software uses the permanent identity to set=20 the EAP framework according to the previous section.=20 EAP-Packets=20 =20 The EAP process is described in the RFC 2284 specification [1] and=20 involves several EAP requests and responses packets,=20 =20 1. EAP request/response Identity;=20 2. A suite of EAP request/response related to a particular=20 authentication scenario; and=20 3. EAP success or failure.=20 =20 The Set-Identity restarts the smart card EAP framework state machine=20 for further processing using the EAP-Packets method.=20 =20 The smart card receives the RFC 2284 frames. It retrieves the=20 appropriate EAP authentication type in the frame and the identifier.=20 The smart card maintains the EAP state machine and returns an EAP=20 NAK packet if the state sequence is broken. Any EAP request is=20 silently ignored if the state machine was not started.=20 =20 The last step of the protocol retrieving the Pairwise Master Key=20 from the smart card can be accomplished only if the last EAP packet=20 received from the authentication is an EAP success packet.=20 =20 Get-Pairwise-Master-Key (PMK)=20 =20 At the end of a successful authentication the supplicant needs to=20 update the appropriate crypto suite using the master session key.=20 The Get-Pairwise-Master-Key returns to the supplicant software the=20 key to initialize radio security protocols like TKIP, WRAP or CCMP.=20 Urien & All Informational - Expires August 2003 6 =0C =20 Integrating EAP in smartcards March 2003=20 =20 For obvious security reasons the Get-Pairwise-Master-Key is=20 available only if the smart card has received an EAP success packet.=20 =20 ISO 7816-4 APDUs=20 =20 This section of the document provides an implementation of the=20 previous descriptions for an ISO 78176-4 compatible smart card. The=20 section does not preclude of the transport protocol used between the=20 smart card and the reader. Thus, this specification does not=20 mandate-to-implement any transport protocol such as T=3D0 or T=3D1,=20 which are not in the scope of this document. It should be noted that=20 all values are in hex representation.=20 =20 The restriction and security related descriptions are not present in=20 the document. Annexes of this document give implementation examples.=20 Add-Identity=20 =20 This command adds an identification label as described in the=20 section: Identification Label Coding Rules. The smart card list is=20 managed by the smart card. The identification label is appended as=20 the last element of the list if the parameter Po is 0x00. If this=20 parameter has any value, it represents the identification label=20 position.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 81 | Po | 00 | XX |=20 +--------+-----+-----+----+----+----+----+=20 =20 Delete-Identity=20 =20 This command deletes the identification label as described in the=20 section: Identification Label Coding Rules. The command parameter=20 gives the identification label to be deleted and the smart card=20 leave the space empty.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 82 | Po | 00 | 00 |=20 +--------+-----+-----+----+----+----+----+=20 =20 Urien & All Informational - Expires August 2003 7 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Get-Preferred-Identity=20 =20 This command returns the user=92s preferred identification label as=20 described in the section: Identification Label Coding Rules=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 02 | 00 | 00 | XX |=20 +--------+-----+-----+----+----+----+----+=20 =20 Get-Next-Identity=20 =20 This command returns a user identification label as described in the=20 section: Identification Label Coding Rules.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 01 | 00 | 00 | XX |=20 +--------+-----+-----+----+----+----+----+=20 =20 Get-Subscriber-Profile=20 =20 The command returns the related subscriber profile information=20 according to the application requirements and format.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 08 | 00 | 00 | YY |=20 +--------+-----+-----+----+----+----+----+=20 =20 Set-Identity=20 =20 The command resets and initializes the state machine for processing=20 the EAP Packets. The first step after this command is an EAP request=20 identity packet. If a different EAP packet is sent to the smart card=20 the smart card return an EAP NAK response.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 16 | 80 | 00 | XX | 00 |=20 +--------+-----+-----+----+----+----+----+=20 =20 EAP-Packets=20 =20 The command is the method for EAP packet management. The smart card=20 identifies the EAP packet type and processes the EAP authentication=20 according to current state machine. The state machine sequences have=20 Urien & All Informational - Expires August 2003 8 =0C =20 Integrating EAP in smartcards March 2003=20 =20 to be respected and the smart card enforces the EAP sequence=20 processing.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | XX | YY |=20 +--------+-----+-----+----+----+----+----+=20 =20 The EAP request or response packet lengths are represented by the=20 unknown value XX and YY. The supplicant software should set these=20 elements in accordance with the EAP packet types.=20 =20 EAP Identity packets are independent of the authentication type and=20 can be the same for any type of authentications. This section of the=20 document provides the packet details. The rest of the EAP packet=20 being authentication protocol dependent, they are detailed in the=20 informative annex of this document.=20 =20 The description of the EAP/Request/identity is detailed according to=20 the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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=206 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length =3D 5 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 |=20 +-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/identity is detailed according=20 to the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 | |=20 +-+-+-+-+-+-+-+-+ |=20 | |=20 | User Identity |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Get-Pairwise-Master-Key=20 =20 Once the state machine has received the EAP Success packet the=20 smartcard process is able to send the Master Key used by the 802.1X=20 specification for the crypto-suite.=20 =20 Urien & All Informational - Expires August 2003 9 =0C =20 Integrating EAP in smartcards March 2003=20 =20 As an illustration the EAP SIM authentication [2] specifies the=20 Pairwise Master Key usage according to the system cryptographic=20 suite.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | A6 | 00 | 00 | 00 | 20 |=20 +--------+-----+-----+----+----+----+----+=20 =20 State Machine Sequence=20 =20 +----------------------+ +----------------------+=20 | Get user=92s identity |>>>| Set user=92s identity |>>>=20 +----------------------+ +----------------------+=20 =20 +----------------------+ +----------------------+=20 | EAP request/response |>>>| EAP request/response |>>>=20 | Get identity | | |=20 +----------------------+ +----------------------+=20 =20 +----------------------+ +----------------------+=20 | EAP request/response |>>>| EAP Notification |=20 | | | Success |=20 +----------------------+ +----------------------+=20 =20 Security Considerations=20 General Considerations=20 =20 As a reference implementation the previous section provides the=20 details of the EAP authentication using the GSM SIM. This section of=20 the document highlights the new potential risks providers of=20 application may face by re-using deployed networks for other=20 purposes. From the document [7] fatal flaw does exist when have=20 physical access to the smart card.=20 =20 The nature of the Internet network does no longer require getting=20 physical access to the smart card. Worms, Trojan horses or viruses=20 can move to the computing platforms and performs the jobs. It is=20 important for a reference implementation to provide the relevant=20 level of protection for the new applications but not to create other=20 flaws.=20 =20 Other consideration have been introduced in [2] to protect the smart=20 card against crypto attack and recommends the authentication should=20 take place in a PROTECTED ENVIRONMENT.=20 =20 PEAP Consideration=20 =20 Urien & All Informational - Expires August 2003 10 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Protected Extensible Authentication Protocol (PEAP) [12] is a pre- processing protocol that allows the privacy of data when processing=20 EAP [1] protocol. EAP protocol, as defined in [1], starts by an EAP=20 packet request/Identity. The EAP packet response Identity returns=20 the user=92s identification label with no privacy being not part of=20 [1].=20 =20 PEAP protocol allows both part of the EAP packet exchange creating a=20 session key that can be for privacy over the subsequent execution of=20 the EAP protocol.=20 =20 This implementation of EAP in the smart card shall allow performing=20 a PEAP tunnel for privacy. Once PEAP first phase has been=20 successfully preformed, the EAP protocol has defined shall be=20 performed according the EAP smart card requirements.=20 =20 Intellectual Property Right Notice=20 =20 To be specify according to the author and participant.=20 =20 Annex 1 (Informative) - EAP/SIM packet detail.=20 =20 The protocol implementation is out of the scope of this document but=20 as a reference implementation this section gives details using the=20 SIM as specified by [3]. Other protocol can be implemented using ISO=20 7816-3 TPDU. This section of the document gives the APDU syntax and=20 coding which makes the specification protocol free.=20 =20 The first EAP packet is the EAP Request Identity. This initial=20 packet format complies with [1]. The smart card returns an EAP=20 response identity according to the IMSI length and the supported=20 version according to [2].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | 05 | YY |=20 +--------+-----+-----+----+----+----+----+=20 =20 The description of the EAP/Request/identity is detailed according to=20 the IETF RFC 2284 [1]. This EAP packet doesn=92t respect the EAP/SIM=20 format since it is only part of [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length =3D 5 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 |=20 +-+-+-+-+-+-+-+-+=20 =20 Urien & All Informational - Expires August 2003 11 =0C =20 Integrating EAP in smartcards March 2003=20 =20 The description of the EAP/Response/identity is detailed according=20 to the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 | |=20 +-+-+-+-+-+-+-+-+ |=20 | |=20 | User Identity |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Note the EAP/Response/Identity when returning the user=92s identity=20 that includes the IMSI includes the real coded IMSI in the EAP=20 packet and not the IMSI coded for GSM network. Further information=20 can be retrieved in [3] for the IMSI coding in the SIM during the=20 SIM setting.=20 =20 The user Identity field can contains the user=92s permanent pseudonym=20 or re-authentication identity.=20 The second EAP Packet is the EAP request SIM start as represented in=20 the IETF draft document [2].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | XX | YY |=20 +--------+-----+-----+----+----+----+----+=20 =20 The description of the EAP/Request/SIM/Start is detailed according=20 to [2] incoming SIM data where further information can be retrieved.=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 18 | Subtype =3D 10 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AT_PERM..._REQ | Length =3D 1 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AT_FULL..._RES | Length =3D 1 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AT_ANY_ID_REQ | Length =3D 1 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AT_VERSION_L...| Length | Actual Version List Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Supported version 1 | Supported version 2 |=20 Urien & All Informational - Expires August 2003 12 =0C =20 Integrating EAP in smartcards March 2003=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Supported version 3 | Padding |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/SIM/Start is detailed according=20 to [2] outgoing SIM data where further information can be retrieved.=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 18 | Subtype =3D 10 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AT_NONCE_MT | Length =3D 5 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | NONCE_MT |=20 | |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_SELECTED | Length =3D 1 | Select Version |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_IDENTITY | Length | Actual Identity Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | User Identity (Optional) |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/SIM/Start is detailed according=20 to [2] outgoing SIM data where further information can be retrieved.=20 The third EAP Packet is the EAP request SIM Challenge as represented=20 in the IETF draft document [2].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | XX | 1C |=20 +--------+-----+-----+----+----+----+----+=20 =20 The description of the EAP/Request/SIM/Challenge is detailed=20 according to [2] incoming SIM data where further information can be=20 retrieved. =20 =20 =20 Urien & All Informational - Expires August 2003 13 =0C =20 Integrating EAP in smartcards March 2003=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 18 | Subtype =3D 11 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_RAND | Length | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | n*RAND |=20 | |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_MAC | Length =3D 5 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | MAC |=20 | |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_IV | Length =3D 5 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | Initialization Vector (Optional) |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_ENCR_DATA | Length | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | Encrypted Data (Optional) |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/SIM/Challenge is detailed=20 according to [2] outgoing SIM data where further information can be=20 retrieved.=20 =20 0 1 2 3 =20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 18 | Subtype =3D 11 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AT_MAC | Length =3D 5 | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | MAC |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Urien & All Informational - Expires August 2003 14 =0C =20 Integrating EAP in smartcards March 2003=20 =20 =20 The last EAP Packet is the EAP success notification as represented=20 in the IETF RFC 2284 [2].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | 04 | 00 |=20 +--------+-----+-----+----+----+-- -+----+=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Success | Identifier | Length =3D 04 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Annex 2 (Informative) - EAP/MD5 packet details=20 =20 The first EAP packet is the EAP Request Identity. This initial=20 packet format complies with the RFC 2284. The smart card returns an=20 EAP response identity according to the NAI length.=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | 05 | YY |=20 +--------+-----+-----+----+----+----+----+=20 =20 The description of the EAP/Request/identity is detailed according to=20 the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length =3D 5 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 |=20 +-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/identity is detailed according=20 to the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 01 | |=20 |-+-+-+-+-+-+-+-+ Identity Value |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Urien & All Informational - Expires August 2003 15 =0C =20 Integrating EAP in smartcards March 2003=20 =20 =20 The second EAP Packet is the EAP/request/MD5/challenge as=20 represented in the IETF RFC 2284 [1].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | XX | 16 |=20 +--------+-----+-----+----+----+----+----+=20 The description of the EAP/Request/MD5/challenge is detailed=20 according to the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request | Identifier | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 04 | |=20 |-+-+-+-+-+-+-+-+ MD5-Challenge.Value |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The description of the EAP/Response/MD5/challenge is detailed=20 according to the IETF RFC 2284 [1].=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Response | Identifier | Length =3D 16 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 04 | Type_Size=3D10 | |=20 |-+-+-+-+-+-+-+-+---------------+ MD5 Digest Value | = =20 | |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The third EAP Packet is the EAP success notification as represented=20 in the IETF RFC 2284 [1].=20 =20 +--------+-----+-----+----+----+----+----+=20 |Command |Class| INS | P1 | P2 | Lc | Le |=20 +--------+-----+-----+----+----+----+----+=20 | | A0 | 80 | 00 | 00 | 04 | 00 |=20 +--------+-----+-----+----+----+-- -+----+=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Success | Identifier | Length =3D 04 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Urien & All Informational - Expires August 2003 16 =0C =20 Integrating EAP in smartcards March 2003=20 =20 Further information can be retrieved from the IETF draft document=20 [2].=20 =20 Annex 3 (Informative) TLS support=20 =20 Fragment maximum size.=20 =20 A single TLS record may be up to 16384 octets in length, but a TLS =20 message may span multiple TLS records, and a TLS certificate message=20 may in principle be as long as 16MB. The group of EAP-TLS messages=20 sent in a single round may thus be larger than the maximum RADIUS=20 packet size of 4096 octets, or the maximum 802 LAN frame size. =20 =20 Due to smartcard constraints, the maximum EAP message length of a no=20 fragmented packet is set to 240 bytes. For a fragmented EAP message,=20 the maximum length value is 240 bytes.=20 =20 When the smartcard receives an EAP-Request packet with the M bit=20 set, it MUST respond with an EAP-Response with EAP-Type=3DEAP-TLS and=20 no data. This serves as a fragment ACK.=20 =20 EAP/TLS messages format.=20 =20 0 1 2 3 =20 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Code | Identifier | Length <=3D 240 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type =3D 13 | Flag | TLS Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | TLS Message Length | TLS DATA |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20 | |=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Flags=20 0 1 2 3 4 5 6 7 8=20 +-+-+-+-+-+-+-+-+=20 |L M S R R R R R|=20 +-+-+-+-+-+-+-+-+=20 L =3D Length included.=20 M =3D More fragments=20 S =3D EAP-TLS start, set in an EAP-TLS Start message.=20 R =3D Reserved=20 =20 Example of EAP/TLS Authentication=20 =20 Smartcard Authentication Server=20 <- EAP-Request/=20 Identity=20 Urien & All Informational - Expires August 2003 17 =0C =20 Integrating EAP in smartcards March 2003=20 =20 EAP-Response/=20 Identity (MyID) ->=20 <- EAP-Request/=20 EAP-Type=3DEAP-TLS=20 (TLS Start)=20 EAP-Response/=20 EAP-Type=3DEAP-TLS=20 TLS client_hello)->=20 <- EAP-Request/=20 EAP-Type=3DEAP-TLS=20 (TLS server_hello,=20 TLS certificate,=20 TLS certificate_request,=20 TLS server_hello_done)=20 EAP-Response/=20 EAP-Type=3DEAP-TLS=20 (TLS certificate,=20 TLS client_key_exchange,=20 TLS certificate_verify,=20 TLS change_cipher_spec,=20 TLS finished) ->=20 <- EAP-Request/=20 EAP-Type=3DEAP-TLS=20 (TLS change_cipher_spec,=20 TLS finished)=20 EAP-Response/=20 EAP-Type=3DEAP-TLS ->=20 <- EAP-Success=20 =20 Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile=20 information=20 =20 To be defined according to the EAP type.=20 =20 References=20 =20 [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol=20 (EAP)", RFC 2284, March 1998. (NORMATIVE)=20 =20 [2] EAP SIM Authentication draft version 8 (NORMATIVE)=20 =20 [3] GSM Technical Specification GSM 11.11. Digital cellular=20 telecommunications system (Phase 2+); Specification of the=20 Subscriber Identity Module - Mobile Equipment (SIM - ME)=20 =20 [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical=20 Layer (PHY) Specifications=20 =20 [5] Standards for Local and Metropolitan Area Networks: Standard for=20 Port based Network Access Control.=20 =20 Urien & All Informational - Expires August 2003 18 =0C =20 Integrating EAP in smartcards March 2003=20 =20 [6] "The Network Access Identifier" rfc 2486=20 =20 [7] "Can you Clone a GSM Smart Card (SIM)? " From Charles Brookson=20 Chairman GSM Association Security Group=20 =20 [8] Part 11: Wireless Medium Access Control (MAC) and physical layer=20 (PHY) specifications: Specification for Enhanced Security=20 =20 [9] ASN.1 standard 2002 edition ISO/IEC 8825.1.=20 http://asn1.elibel.tm.fr/en/standards/index.htm=20 =20 [10] Extensible Markup Language (XML) 1.0 (Second Edition), W3C=20 Recommendation 6 October 2000=20 =20 [11] B. Aboba, D. Simon, EAP TLS Authentication Protocol RFC 2716,=20 October 1999.=20 =20 [12] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar,=20 "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- 05.txt, work-in-progress, September 2002. (INFORMATIVE)=20 =20 Author's Addresses=20 =20 Pascal Urien=20 ENST=20 46 rue Barrault=20 75013 Paris Phone: NA=20 France Email: Pascal.Urien@enst.fr=20 =20 Augustin J. Farrugia=20 Impasse des CAMEGIERS Phone: NA=20 Ceyreste, 13600 France Email: afarrugia@csi.com=20 =20 Max de Groot=20 Gemplus=20 Avenue du Pic de Bertagne=20 BP 100, 13881 Gemenos Phone: +33 442 365 036=20 France Email: max.de-groot@gemplus.com=20 =20 Guy Pujolle=20 LIP6 - University Paris 6=20 8 rue Capitaine Scott Phone: NA=20 Paris 75015 France Email: Guy.Pujolle@lip6.fr=20 Urien & All Informational - Expires August 2003 19=20 --=====================_2580330==_-- From jari.arkko@piuha.net Sun Mar 2 11:44:28 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 02 Mar 2003 13:44:28 +0200 Subject: [eap] comments on the binding draft version 01 Message-ID: <3E61EE9C.9020203@piuha.net> Hi, I have looked at the binding problem draft and I have some questions and comments. I've inserted these to the draft itself, marked by "JARI:". The URL is http://www.piuha.net/~jarkko/publications/eap/binding_review.txt From jari.arkko@piuha.net Sun Mar 2 21:32:29 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 02 Mar 2003 23:32:29 +0200 Subject: [eap] Question regarding draft-puthenkulam-eap-binding-01 In-Reply-To: <4D1E846548771F4AA7FAE28F4B358DB5012EF46E@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> References: <4D1E846548771F4AA7FAE28F4B358DB5012EF46E@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Message-ID: <3E62786D.6040405@piuha.net> Joe Salowey wrote: > It is also not always necessary for the method to be the same inside and > outside the tunnel to expose this vulnerability(although this makes > things easier). If the same credentials are used in different protocols > inside and outside the tunnel you may still be vulnerable (of course > using the same credentials in two different mechanism may create other > vulnerabilities as well.) Right. Specifically, any messages M1, M2, ..., Mn that you need inside the tunnel have to be derivable from messages M1', M2', ..., Mm' used outside the tunnel somewhere else, without knowledge of secrets associated with the victim(s). In the basic case of the mitm attack, n = m and Mi = Mi' so the attack is easy. But its also possible that you have to change some headers, maybe even to the point where the actual _method_ can be said to be different, as long as the cryptographic information in the method stays unchanged. This necessarily includes use of the same password or shared secret inside and outside tunnel. Here's one example where the credentials stay the same but the method can be said to have "changed" in a very strict sense of the word: if someone uses CHAP on credential X, I think you catch that and replay inside a tunnel using EAP MD5-Challenge. Jari From aboba@internaut.com Mon Mar 3 01:11:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 2 Mar 2003 17:11:15 -0800 (PST) Subject: [eap] IEEE 802.1 and IEEE 802.11 Archive access Message-ID: By arrangement with IEEE 802.1 chair Tony Jeffree, EAP WG participants have access to work in progress in IEEE 802.1, using the userID and password noted on the EAP issues web site: http://www.drizzle.com/~aboba/EAP/eapissues.html Recently, IEEE 802.11 has granted access to their archive to individuals authorized to access the IEEE 802.1 archive. As a result, EAP WG members also now have access to IEEE 802.11 work in progress. In particular, the following documents may be of interest to EAP WG participants: IEEE 802.1aa, Draft 5 (forthcoming, includes revised IEEE 802.1X state machine) IEEE 802.1i, Draft 3.1 (includes description of TKIP, CCMP and WRAP key hierarchy) IEEE 802.11f, Draft 5 (includes support for predictive handoff) From aboba@internaut.com Mon Mar 3 05:15:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 2 Mar 2003 21:15:05 -0800 (PST) Subject: [eap] Item to discuss in Dallas (fwd) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------_=_NextPart_000_01C2DF69.FD0F6580 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Fri, 28 Feb 2003 12:43:02 -0800 From: "Walker, Jesse" Subject: Item to discuss in Dallas Hi Everyone, Attached is a document proposing a new EAP method, called EAP-Archie. This document is outside the scope of TGi. However, it is worth considering since we are reviewing what we want the IETF can accomplish for 802.11i. I will ask for a few minutes on the TGi agenda for a presentation outlining it in Dallas. One motive for the protocol this document defines is that the current mandatory-to-implement EAP method (MD5 Challenge) is unsuitable for our environment. One reason for not making an issue of this before is no one had proposed appropriate substitutes. We believe EAP-Archie changes this. We believe EAP-Archie is light-weight enough that it can be implemented for all environments that implement 802.11, and it incorporates all the security measures 802.11i needs. Thus, it may be worth considering whether to ask the EAP WG to consider deprecating MD5 Challenge and replacing it with EAP-Archie or some similar scheme. Other groups (e.g., IPsec) have successfully deprecated widely deployed algorithms that were found to be no longer secure, so I don't think asking for such a step is necessarily a roadblock. Even if TGi chooses not to make such a request, or if the EAP WG declines to accept a request, EAP-Archie is still a protocol that I think vendors will find attractive to for 802.11 authentication in many markets (e.g., SoHo and consumer). The deadline for submitting individual contributions for the San Fransisco IETF meeting was unfortunately three days ago, so this document won't be posted on Internet-drafts directory until after the IETF meeting. Therefore, it is attached in case you want to read it before Dallas. -- Jesse Walker <> ------_=_NextPart_000_01C2DF69.FD0F6580 Content-Type: APPLICATION/X-ZIP-COMPRESSED; NAME="draft-jwalker-eap-archie-00.ZIP" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-jwalker-eap-archie-00.ZIP" UEsDBBQAAAAIAA5fXC61NeTdni8AAFbMAAAfAAAAZHJhZnQtandhbGtlci1lYXAtYXJjaGllLTAw LnR4dO19a3PbRpbod1XpP3T5w41UQzIiJct2ZrK1tETHHD2vKCcz5fJWgWRTwhgEuAAoWVP58fe8 +gWAIp1Id2c2RmrGFB6nT58+7z7dvb21bf8bpqXOU12q4zyalWqD66+6KLT6JUo+63x7a/BlEedR GWfpD2qkF6Wej3Wuent7+6u+xxYTdZTli4w/3N56Fyf6B/WXKaLQ/sc9gW7raNGO8sltrNt7e53y S/kfHpCrZVGo99mySPSDIKGLH1R/ebMsStV73XoUBaV+jm/iBBCeLPO4fFDbW6tfXXW90+N8GeUP rjWmaPPb17daDfqXqk89Upd5VmaTLMEPRmVULguVzVR5GxfqTM8zvH2Nf0yzyXKu01LB7yhVZrTa PFpROsUHcapmyyRRkyydZfk8Sida3cflLSAUwe1Fnt3FBRCa2oA+I9FVdw//unp31NvrHXZ8VmDg 0F4OYLL8c5zeWDwETW0xUYP0Jk61zvEtQDoqPqt3WQ4Y7AwH1+92WypmUFHRYnzhTwP1Js+Wi6Kj 1HlWagAblQAiA/C5PFLz6EFFSZGpaVyUeTxelk04RYWjzPYWo7+yS8Rl3sd3URJPFRBORdDcl3i+ nGMni/gLIDPP0vK2IMQRlbFWy8U0KvW0pXK9SKIJ/oJPs3GRJRruq/GD4h64FmAYcKweVBnPNfR2 WPKoRQsYmkUeR9j5TC0LrWoI49e5nulc46jO4VV4P8Em4YtJTGTTc2kSKJjiJy+QRMgWAP8GBKPo vGCO0ioBOmL3gPFz5KtqgxOAAL2MJhMU86mKyu2t27Jc/PD99/f3951Yl7NOlt98jz++78bTdjSG gYkmQHAQ0WorFX4d3UbT7F4dg7BOyiyP9ebtFfRp57acJx2Ws6Ns8ZDHN7clck880eG9naNdkjnL p6NsAsAe1A6K6i6MQh9E4wrfLdSVLnR+p6cCuS9dslI4B5FUUz0DRicxREGOlkDyFBomHYaUJoFW 4wi7QXd0G7DO4a/trc/6Afh/AuIIf7IO6CiCbT9c6BylF1pblksY4koDwETAhAVQCf8CeIBQHt/x Q9toAboknvhtw5sdo3Vi5KapLuKbFEkNfVEpvH/Hqmmuy9vM0CD8j7W9+j9G5TbruNXXx8voRqvu Jx/m8Px6cHU+uG4fX/XfXde/AZTagndw9V57qhfG0sC7jsaJRqY7AplFucOb3Q5yQJ5Nl6z1Ol9x UWv7pNC7HQA0WuhJPDPjgcpT//cSWJmFfAMYPRhync/jNEuym4eNcTEw4HNjNtTFHTBsrO83BUIw DgiPHvbFfg/d8Ai9OQxA5kqXMARv9W10F4M+evRbcxGMQ4Gx31Hv8ugG6Rd9xegEMA5ggKcoJiDa P4NA2PHZAMYrgfGyo06Ap4+dPD3+sVwGBnTjKH9YlKBqo8UtSF8/uQHlVt7OV3FFBcZrwmMfx6U/ GLWP3h61z/pH7S5wOsq8f+/NYR1kAAN5DNQej2f78urdWhToIhhvtreAnMe6jGJUU8e6mOTxwnD7 WjYxMJBLqC/88hmoLJT+d+iagB5ezucouhvA6FkYKGkaTIqB1fyxB6O7JzD2PRjFAnwgvREQgtET GAcWBqiWWZzPNwLBMA4FxksL412cxsXtZiAYBowtfD7sn/cRgSIGxU9sup696EIYPaDHYcc5vF8L x8CAfw47rFR1OgUm+VCs64K9Ahgwtmd6Av5KXMw3BdCpwNj3O5RE8QbyhlcA44Blf1SCN3QDLvO6 j+UiGD2BIfrjfQz0hDHeVLMHMGBwfl4mKUAYx0lcomu07nu8DIxXwF6Tz9k9yO3Nowap4TIwXqNK F0/zKz6ni2CAjXoDeIDfAuagP52i5/kVkAgG2JfuHtgFjGecN4chEnVrHTALA3jUhabqGD5f86W7 CMbLJjfoedyi3rO6RUCIwAUiVwmD0S8gwUWMPlM/9DStk7EDbUEANyU7MAZhh4ji48GnFjiRFFNO 0RtGlzOdRjkESFaeMZgqlgsI8CkKiKbTGCGDUwtebNgYO50FxasA/vLyskPOKMa7GPct0bGVh8PB YKBe7/UACnj0GOMUEPJAoHhzyzGpPO90/6Y+vv6kZnk01/ga+bQIVZDCuBLCsQoqxQQiKQ1uepxO kuUUQ8wCTFUJbns+LbDXJzof6zyD35fLcQKWHsS+pS5Sra4hslOXUVFAc/ju9emIw10KzArx9SmO QA9cIgmVggfWiIWNFUrOG7RNzIC/IUJhBlgTMmD7MxDC2yBswPaNo9NykUO0InZgHkIuqvm/uef/ GrbCFogG6sXZh9H1ixb/q84v6PfV4P9+GF4NjvH36H3/9NT+kDe2t+DPiw+n8gb+ct8eXZydDc6P +fOz/t9fMI1fXFxeDy/O+6cvkEMpiQKdNJkTjPkhVoYgM8ZYELpXcvAT8vWrT9LVnu+kc7f8RMwM ew0/kgfkzYIGaJYlSXaPDAMNzIsf8Ku30eSzRu8tHJMRBpq5nyXqwxjwq1VOoFcl8yMuLuVIjPD5 UDDwr38OYTH2PXyY5R31C/xBstXygRDppNnyYREjDz4o/QWMbAldRQk6E3lFEQeIQUfCJj4S3Uov 4AlkOk79bz+i7HZAdtvdv3VAfXU/dT4ZoQ3g+h8hvyHdJCWF7yZxiokPUDdABBwPuR/SxgciCgjw xSTUD+r3Yc0MeRsxXxSgf6ABUIqAirCm/71hqk9WQV1qva6Lp9hF4oOcPFoYDBjiylhUhlv6Nkwb UaZh15RL9GF8TrN7SidhyyPQnKDxorR0A1PnZUbXcSrTMSpFThryJpSnrCC/ACKgi0nfTEBBqXtQ opTpyimJkWaqWbx8KIyd9A4RUZRHM9RSNdYiqcgDTBrfU9kCHWdNidcF6Py2GCHMdUojARBu71GF YLMuT+NS7D+jSwGeez0PwQ9WJhaEY0wrcSXz1OgToM2MMFPa8hHc3mJ9uCL9xvInTkk7SjKwzYBR 4cWw1npmyxJjILnPfFVKmm/aqaAMwwyiingDzJt2AqhP1cturz2GMS/0BKyKEqs5Bt9E69Qyz/YW SjUhZm7JoLOy8QAKoLjwzT8a5O0tAc5vcJDvWWr5EBUPEIcMHbpbRZmD17fMwXEYYm59gmFfwVn8 HgS4rwl9TE4K3XovD82tFukXnC2402AFPIQondmecCzM9Eezv3NydLLbojfwOYQRmBVxTwf41FCB YXgpTH7n+GTX9E04zBrZxja3t0C62PtJAodOW1o/QnzNnmxDQxXky2ACQoidZhQokV3Y3iKftzE7 +1iHKgSg7tA9jUzsgasy1cpeBSxuuJaVcSPLAK+xos/S5MHXjR7bOvgiXxV55ZmRSTaHTs5jspMz GeVmHr3H3IMjKRKpIm9EpVm2zEEbUKKkUMK8aEvRHN5nhFfOqaHvc5Pe2d7SXzAQgU8gGOXIQuE8 2MDmuItWhWzGZZCRcSAgEo1vQH5UF4YFHKLSGjKDqKCnZuABkuPHCpUHaOVVMZ8/yrX6gx/t5ZuW 5usv7XabUJS02ff4+/phoX802ngdBL520FQNj9WvgCpx4vB41/SvbdJpVeAKGv8PbmEHaUDfv4+K 2y78e44ic6l+FQzeximFWb+qs/5Rd9dvez2OT9ZLRK5nkOvDD4vWpiAU4t/7Otpgq/vc8/1d4Rt7 Gabr2Iljw242mwrsZmIuUIlFaRnRGQ+wBPLVqMQ4Vt7wM8TyZHvLfh0Igtewk4jrUHQKTS4oiU1T c75OIaGIU5lDMyNn3wSxBg0I9PKmyHRjH4zYe6rNwg9yDBonnHUyA4WCQ+o69Ahsih+XqQ8FrPoS J41ZDd2hSYCvYzPz4LnnRk9imA3+hKYZYRYk45wAIWF8gJY497zUmGHhN62YGeP0lD7hwTP6hKIo 2DU77w/VxzefhDqzBz8O862I7S37g+BAivORw9NszsSRYWL4EYbZRTjawF2moZUmh4PVmMau1F/K jtc2hbsY9QJelKBaLPNFVqDxeIdy1VLAOBNkI0RzmQL0KdgBnGzk2gactq8gtr0lskHWvAQfiqsF wEMpSwgDwOfDiXwOCZ1rQOlsCOgojghzbOIJSE9j+FYCcAq3ck88jVKw9lDEL+D00MGsTpBYbeBk nUjtJL36RYOoWxr44l55HcVmhbTXkQm8uzoTNHGYVRKgVUKlhUmRBiVRUVU2bccIkP98h87yDB00 4k83q8/GrsW2riWmrmWMCSOEZq4jnlUgL02y0tyzjhhTUlKR9eEJGXUT3xkI3UM1z0C34mQ/Ze3S UmWTUrsSntH7fhfVVHyDOpgBfHz5yTxuNh1iwUlijbxub/kSC2ySAMez4vP70lLiVcOjZTrVzL8Q Fohu5kHqD0Y0m/JLHi3Ux8NPfw7pEbqjJHz4fKoN5O0t8ssFlxXudAvTGvoLiCTGeuC8gvh2aHSM LmpgOvx2kk3Z0V1iW9mddGKR4wz4atYFiU3Q6+SOUrePTkxqBd37+jxvy0SiACZObdnWfqfL6LbM 5/A66B+Zce4IGz6mkQJ1WVeWUolkMqk2bkE0MKyeaMOCNEtFL1V7juKlFsA48WSZRJYy21vG4mN/ 0Z+3uVRUdn6gUoWIcTIMI8SxM2GUZerYyR/yaLHQUV6IFQH1nUEIAO5/ScrSsQm/bcSUQ6llYW+M NQ5VRd9jtRIZDC6eAYVgTHnHeo0xU50dqUSN5bZIFXMjpdYLCcrxBafTPBUfMD4FRKaALjbTr6iS 5vNlavMgQPMURe3+Np7cEi42j1tkcxBOmZM55wkU1afCK8sfaPRSfLuFfkqWY6EWy4UQt6aDmxQ1 pkCpXm2NKltjq2r2otFsYdUXz8rXrFbNQ5VPKh9gs85CrPdRV9msGiYrTJYTRb9N4/OtwNGaHoyJ jemh0EVsTd+zNVwshkEJy2rPcOVXmYvtrQaDEZiL0FRUxwstnQRVgb1Yay2EQNgHCMUfNRrUvGcy VpgLq//qBmNTc4FJgYrB8EQepWVBgQDpekMZmgFI8f9mOXS59Ee4Sq6W0Yo47qESARt8A6pZdAnS FceW293AUq0wVI5ff4N9Mk8JFd8AMb+JbWiUtcA0DChf9ZSBzsvnDHTM0HHKwQ6hcb/J3Pi2LLIE 4DwUG56YhVO4TmwbERkpY0vBre11lhc/a2F6TeC0GnRMTQvV9LHTQKHesxp5hlbAC7aDiaaKGpW6 7iJMEcs7Uu20YUARvq0oHVrB+avCCXKSPQ1qk9+cfRElud+Rv0meAhVp/AAm04Y+9SMqssFYIQJG PVdETABZfJ0C3N4CAa2EJxLJppmaBOWIEtC2KIURF55fyZEtRr4PRGJj62Ri39Y6G0oH1k7Gyk8d YdkEfEU9KlEOADSQCNEuWclD1HqDrUkcbD0g+ZK7WY2aC1aeXOMuarmwrIoaPZv52YTUF2qTI2eT aaIzMZxsYYQZ0GOmsHq+TMp4kQBFY/wZpRrUkW24ORXPFrfi2zSUyZISkaQ0dwi/MYLekJgujHdE pTqIXk4At7fGAtKyQZSK0omr6SjOXOH0Fjh0mu0b0hbBWMO0oBgNOJ8KNqBV7aYXrBuECIhvyal8 BLq99aAt6GlVPkG6snt9x3OxHslMXYhpivP/ValmWmXAupzmZHnEiYZFo9dAhH8HWOov0XxBSZpZ YEsbU34F8qkHy/oL99qWjyQZZoNQ2Yb9uM+WyTQgbhkoHg5BvJdImVIkVtIMBY5FAYxWG/ztLf7M G4vmqPyi5mzbwQi0cfAZjTU3QOCrapU9TuMQrHRbKCRzbCIPm+lWy8PU+tc0SvBxHt/c8BojxsX2 E5qocaqwnYiaoy6n8EAXsiyxfU69gcQw0YzhdEn1DqW2fBnEAbKaCae+qHX3uo8DKLi3GRc4+EjX 5+1UcUuUGGOMyguqNLEIeBXTxHIU444Fog+iYKo19HjX036e3JNKx5o493JlrcfTuF+Hz+h+YY9X VfxXeh4l92g5Hi+R6/jtc4QNVDbT+t7EfC1N0nKB+rQ2wzF+qHH6dwXm+STPUHNqKpkyfrmj6jOi +BauC6i5IePYOSEesmDjpTaBnYOoqXjClPldh0iRvzSlihm/c8WSUga44jCccZ+yW8q5IZPtdHHP qqAe6/PGKCTkz4JCTJVfXqRi1OJujUi4EoFsSBEnnESaxgXWaios7lxlTUInkSt2SOLFKMcp++fc DQiBc+kHhUhEp1E8jyF0wSRJQJk6wUwg20ylnmLgvRqRah58rj3y2AbBc/ptxPEVmrVTX0cbhzy4 EI42FR466//dqh6b2zNhM0fK1b5jkrDCImPrvKOZNiVjWNjD8mfm4Tq4yES5RGUraG5OpeRB9pNC Vy5U9+fwOB0DymuGNMDyiEIEC0u/xLE3k0o1q419nupJEnHJmvISY9b/jc1iXw8Bq6vnUTm5rSoE XAaKtcvQXdQNrAtrK5dICUbonQkJKiyBZARKUTmnTXGwVuLEB2tAv/JkZ3Sy6wbp5PhEIRrCbXir WU0azcMxg5f2DOKw3stDUl3iwxaS5TaludjtW/DKsZnRCQcvBIgCB14YbF/FF4vlOMunVHJIKVYJ lYUFMVrOLTLVkpNcJ5i0yLAW2piAmt6vWwwe4oJm7r5KN4tmpkzyyeDEZO2gVQsX0FCJjprg8WfH J9QLKecNZ7gr2okTbeQP+fk3Cdp5ToqydS11D5FjwYg05dhctqeSkqN8woKWGhCzk3xLA36ineN+ mUpqDPFlLmiVx2lxRZaQtGJRy/tubxEhETPjca3oBnmRE8qSWdCrVL1NKj9GTpywFmKCE//byemI +bRO2qtndNLqw96vDXu/5jPJXPjqPIklqYy5CsfcTZIY8nFwv9moW+A06hROjY3j7hvylOd5wS2/ kzccWuahHXf4+MHkk0WDeQnWY5B4j028Lw2zYqkCqpaSAp8XQhpPN78wGVuQtWXKqrM2QYKLQH/A XsGAAQY/erd3CIkmwOpXr2O/OuSoUuk9BCcsDy9+faGKh/k4S6SGpVCCLWhD9HZScbPd9CX6C2YB TIik9R+MsWCNv0xjcFTAgfEcbvGXJ9l8HKfW9TFVNmZ+vVJm0pIyclesgjBsDU9lqKmOBNMCRYU1 K4Fgy8y4NsHzYr6V0JomAYLSGOZh0TKV2qEq1itacROvRpwaaC1bMVA9K6XB0FM0fFV0aJ2Tl7in SWLCzk6a8GKjRRTn93HBBjiwyCLzI2A6bAAhmGRaZf4NiRDZ5JXGhSwtjDxu2e5VZi/tkO2c90e7 4kugs4Dl307koI/Wd/TYjlQIow6D7iFvkQuTBJjGF5cNFzlehsiajVe8N0Z+1nX8YIQRWwikceQJ o48HSSPB4X8vd83o1Qlu2BAV5KOOSLYsF0tULzuSwe4qs5ZuvydF2JFdw4luEwxXu5A1YOxp2xSb TALZ1+HZ8NL7e2KSG8hcDFvysTNZKjoSdc0UNcVNDf2DGGA+p+jBuKS8Pkl0QCTRo7FXtSkUXg8W fYZhXRmabm9JzFCwD2NSXA/0car1FF1J45h64ge+Wp6aQWd3jjvkTSy6xZANvZO6MGSXBc7w8yws eqSfORVnd4DhfWiUXXRpdtfBj83KBsSumEDMIpWV/kI20gD7HbV67wJ+YaNNCZgfPQc+17gIhFmR OD/2IwbvY0LjFNzgE7EgOIJor3naFVpK4CF+MOB5YPOawDElHaSvwVkrqUjkOmyEsEbmMNYpkEin ILCK36zkAz5b8Eq+p/O6Xj+j1yUFxFFHITVPfTIlvLQdJ0nQLrC8y3vfgQo6VX9SC2MdF8qVIosu YQtMRScQvKo99Zcf4bW/4HQYywImuCm6B3A0h2ZnUBwsaL2L+0zRH2NuPcXGv/u+e8gjTcaF+ATx BJEB28EDVojyp0Y8oCMAMPrY/QT/1/uEa8PhR9rGv7/7mH5qsTLGF1r0RgtfaZl3HJhwZQF0S1Si xkia7DGCW/kahZgG1gIpsEdfdQ/bCzs/CIQkMeeejxDejwx3778s8eGnB8q4VAtvkvGfOoeoIJoa Sk7QtyrV8GdUMYASPZcRllemrKxjaK+Lb0F4nQXl5vDxj76I7ZwgjeJP6m8XV/BwV17WNJe1zFO4 5+d6aqpWEql3ESiqlKYvq7JooiS4DZ6+VSNiuc2H03g2w2ya09MVMG4FL+jaMTjyxN64jgWlV+mW m6qS3boKz/5Cj76zXULwNXsJ0bejvHQaPdjrwIGoKb9m99a6Up3K9yZVvb11o1NZWYiBv7HWbKkb FCUlbn1AK1Xc+OER/YaUALVxwQ4Bek48BxP/06W2U9yPgSELW40rXHVQ4SoB96P58Wt19IjL4HYM /zs8ECab2AHhz0hPpjycY445kiwDGQPb+AU+jXHhKpa6yHZWqMpxFygcNX+xWQo2Lwfzxk7z4UHl Q3KI8Bu19+Vgj0h9AKZxg61w+FVcqGGSrpLrC7e7wdf6oMN475uwJqBWTLLAlaI01TqnBZA4OXSf Inlw0pcqj8j5o6wr+zMQHRRg/GiKHaUl0TOq5KTtMyrTPE9p0d48u0Xbq4MBhqtfvYZ7+wZEFx7v A4u+VIfqlXqt3nzNPQLyp/bv/I+g/EpoHWFpFl3499AVfMpzuU7ZbPvXr0+OC65OcrjQdRyVEdjJ r2lKBgs7ZpUrELNteNvc6tEtZnN50XXffYnc7S91oIQS+rWpEVMKueIpxbmULge5N1/nZvKVzb9Z BNAR+EzWsDEhtW0IFxeK5ievOqjQde5U6datYxAQFsIYpxKJ0vK62ZLWWkR7UlIGCFLeTDSpC7E8 ni+fY4mZ0R4+zgaAm0Uucx3JPhcElXYNOI0eMEeAIQgmjTAlZz4wEMD6ZZicJh9+ohd2mlgxr3h0 ezuC0WRxlrvYUkhY0WGCsusfGyfeHsDZJxIMjrhYr67cAUxaWaNS7YhUVSlrUe7U79akT6JPZYfE vefWp3t1KF+pTr9Cc/7Btel5FNtWA1waLoPL49efNoLSWfPWuqvzhFCa+y0p2B3MUrGeDRb/ete/ S4/ctXYMN4Ky9vkfiV9cOnxnv/c4w/yb9Mi71o7hRlA25IdmR22NKzb8za7YVeiKXRlXrBks1atg rQeV0lunBlwRSsQ0TWGofzl/zgCwyr8VrP52rGz8vGFZuHUAvTcHG3tbtoWw7xDq4hb8mDjgHsvG VewfseKVrDa+zk3vqaf1Y55zq2d+Zsqdq/N5tBO+syvYcR5gQ1d+PaSZTxZcFSWcgStz8V8vw88z zN4iSgNm9Qpis0GDcwf8NQM0hcYguHmaYsjSNmbyKIGVYE78AdzxeRTTTmLhkgPBPQRiRAmBmI5b 1gv7XuFIpKNVsrWSCoJr0lS2TeoFT1AmDzaJh3yVazsjibiaKWbZcD/ovV+xJCSsZhYlKthfuacv Pl8dE1SqypqDAuqxKWn7fSHBpv89jcg97zai6lvo4F/fQofm6/kdJ6m2+BY6rLzWPv9D8YsUcu90 17HLv0+P7LV2DDeCsvb5H4pfpCp152DvG780X2uf/6H4xawu2DlYk5n4F+zRujFad23GL+uuXx+F QotvdrrriLsGyqbXZry77mpOs/TkZ5hmeboA4Dk3/TV92CwdRFGiW8Xid5jBzMKVP7TRDK2KRUmS Cbt/n/yOqTZet/OXn/IxYGzmZ/9V71kzP+I3N2Z+GITLqIQVzWszKvx6iIvf3IqMilexv1E+RdZ3 P39GRXAPgTRlVGjAw36zt2kZ03qdPskNliFgA6W03XMVZll9d4nmCU8LJJPSp8btuQzji9DZqXHm 3LBD4g/ZHlm/qLL0IswMYelSyOJRIcckuKIjKjv6yXwSmUUdLsm/G24Fab4ad+jYIer+oHFlhyn8 wWUgldVqBghcj63vxZoxulG4mvFgdYCFAqQ2Naj4UgVjelE0QUjYcBUkUtZl3Ya8twIVgN17+3mb 7+2+3j84hf80RuQ5dwkl7NfmRNb9R1DYzr+1SRP6G/gbR2eq1vsBm9n5/y0+qhSk7/S+xTQrrrXP /3j8cvmNX1ZfG/KD0/hvQ6cO79BSe1vmxv4R3ctmdoGROG9mE0nvc+9oB7QmsjAHlJ8srJE9lYIm 98CRPM9Ks0pM7aSZBR3z2dFoKne9T7CID4/cCtb3eM+xom94eXfQ+HCfHx42PjwwX9L8Cp0VJq95 L700EB576bDde4kv5qL/XZ+vanfg2nN/kV4MHuIdf1AquwPgEoUH9gjubyV6QbfAg8CrxCKa8sqU 254Tl0zavTgj8IRHsrDNblRmQYjbao8c4UJ4HDGZs+LVQbIQofQdSw8K3mcL6Tn9jk8YlGUUz5N4 Sn/iOTfj84XJeAJs6X5GcniPSRrtD74CuZDLrtZDLz+QArmQhBVxcEtqvCV0h5WxsBe1wCGhfPTK fgTqFkMViTDsJ3Y+DRsniXFr6xobP9i88ZfrGt+vNH64rvHuV3S9u7bvB37z5RP1nxSt1Sd22YqE zwaietlqBGJiC/qYv6FdJtweEw6nV7KqsQ7l9Z/NO4f0zptGSuC6w4hbagJiMA62eJpyBwMMXhPI JhDeIogq7V+aH0829BsSvvvq91O++2Yl6Xt7tri6+9oIu0/qkKxNIBpJLU3K+HmEbYLgpxGUOFyB RltpiYzJCe0MrqW2gaoPhreOxbj2oSj1fI0RYsvjf/+brFAViZoZYgi0lC5fJtqeJygauAGNxcIc T2TRhEB8DA7L3NARc2yOhtiMy7pRMiYsa9k0GVPZlFO6t66s30BYnydEpgmSAXYjXh8L3JB3o413 3LYy/iis2PLrkcOt8fGqWprq/lTPVkrzNE7I825Jp76VxvjXc5fGeFmepwrTNoLyNOHp00B5pNSh 963UYfW19vkfil9kJ6ZvpQ4rr7XP/1D88q3UYR0/rLvWljr0/neUOnxbUeJXHDylK/ucG/fZb35f ZYRx0FYfTyMFET2/IMJWQlgeou1i6K+1BRH1PK9J8hIK4VCyl/Q/MEVvd5cSKE1z9NXIqnGKvh92 SOz4Y1P0jy7fiC31v03Sf90kfRzsIlLdc4/BVKsuaoMyen/x4fSYzw8qaxxowMzCkikLle8L3exx Qw17oTIY3Jw4SnCTMUKVsi2yBdulmTrCchzRZ3RoWHnrJyPucxgRR+9aUYkhmQDb0Z2bTisYVW61 cetjTBygtuGqH0xP0ZZPsyy/j3I+8EwGtKHpXT7ihFUVi5FBhhNQVTnm7NoED1iSDayEjhZy8L2X Z6qoFKfM/sfyTCu17ur0Egnf0YkF8RzppZc2vSTnxXjZpaezis+7sdqqLFjltKInTIKpbykl//qW Umq+njJAeiSltP8tpbT6Wvv8CfllXVvrrrXh5/7ThZ9re7wRlA2pJzpzk3p7foZKeX0Q+keoYw/9 hv0Ws0FTYKb2N9+bYEVA9pQ2/zm3nlOi+MLRYl34/z1wNL6sBdIUN1Z8kWrYiIMadsYN87+Ay4rM 7lG35qE2eaYGyhoPdYVnur0Fnqka9s/7SF86tode4G2Pr/2dkrH8mo9hYAFN9T1/OAk+JLDvcHBb vOGonKFIr8KY4fmCE46hEQIKLs+KZ7nHnQRlRIeJNIOZRykOMHatWES8XcLY7FZdLBdyRszYHEEV 7J2wvXXYwY0gJssct6hv6Pkh7mU5NMdLL3mbPk94kC4a90jVtDcob+k9WyZ8xGyEteoFgsdtsmmP duMAu424zZFFhdu8mmJOfAMPfYyC8xvNyaqsZbe36NCFaFK6A1OLgn7TiZId7kOvA3GGwK50YMNT Xq490nF4igfL0+l9ZR4Dlmb3b5OJKPhsHSzK1HjQX26DW3wTGplkc4JCOxvTKYaVgxHD5rAxUOi5 jiSLopEL+YhhHtlKKiSlNS330cOfzYmH4QsWKh5PC6MOUMwpGghTwHsHHI74CA2E6p9aTucE0PkX iaaTww1iIHD3OklkCPY7Hp8lUTwvKgMhaAR70DYe0iamatyhdRA3BFF4xT2ddHiL38qjJzE4YnF6 z7k5Hz6ZdmgP+Kk9zUn6pjuy833OapTvzjoKD6bHreRzc6Aqsmdszr6KzMaSwGigNdpx2gaytufx FE8UdG92WOPVE5U4+s1pSXBPJni2dEI2hwdte6t6tl4TTHOMudTARBWTVz1hOTwWo/QBhjs8Atwy At2j6ACAZQoijdSJ8KDHypkZLbflTTOOZ8MjPPnN+j1yivb0caPUoET4cFtMDM5AjO0BrihRDDPi kwCSBzXOlqRxoynogwJHlIqHRaOIxEcLPIEsj9GKEJKMojkgVRCj80bHD1y5RRt4tqq0raTsUKJp 2+yxDrTYODyW0HWoMMci/eaubW+5zmEb5DrDb+iWPRY7SKdWE+PbW03dJn9lvqRzYp1f7q8ePOdd 8eUoOkCjcqCKtFqjEQ4jMvwkxi+54BFfXFJGf0WqXxbPNQiSNwnBnsOwQbdho07Q0OJWGjbNihtG x3DQ2ewmtX7E54NdVVXjo5DdjlAIR/pgUlhGEvn1+nHK5Mb5Z8K6DPTkNstw5s7BN3tGidXh0ytC 4WUT5DEPiUKugds0LZLDkA1N/YTGrvdfaNTgx80SWxFxldkNAIVHJqfmPG9fnmxJ5QLPhEIOxvei OiN4VZaGaXnRJzeCUhCXtfw7itiUDw9YotJkY0UJ7UDfhn48blevdJ5nfAS1O1qTnWVOseNJhd45 Zd7hz8G5b44OMhOiMcAEUbQD7EYjIDgSGcSFdsdfQWxuwxGWMpkGsChdkE4ign+yt67JhXca5Ri1 y5134KR0t+JHmHML2TGUQ1W8s6zouCGk2WyZI+dAE9VTAtF14ZMsguP9aofnyonBzgcrzPc5H21D h8KgR2dtqm+4jbgG3lTsiIvPqu9ubzWcuFg3NSFNvis8847aNkvbRIJsNmsnMYxh3XPgYl705zLW gE2Yo9lDON6UXf1kQ2WPfqyN1IyaiG7QUpcNTongErvW8MzjVX2X444ASZwz0ikrsEz6biICJatr 5HirO3NoqDPmUX7DgR7m7fEmeuwe3k/kRooX+ZxbI3oqfdWJx+ydH/DBoSMZX8OtejbTHFp9Hd9G ZcCvrP0CEEB9lCSI5kDO7PF9LRiRSbSUCAc5nXJwdC69DU7C/QYOzaGn72MIXIEyDxUuk9NHwEJp 3U5AGBPC5Na8TlBO6X6Xcm6NAqXMGWIuSkQo9oga0tykPqkhtYj1BGIZgtbtvbYfTFiv2eSD2gGu 3nWHrIG+a4x5aoBEaTswgxBMSkf13cauwgIhyNmYlbhCIByf7NoTUmSzCP80N/w+xSMImYgywCEd cZzl6NPmtwyFQ4Usa9Hk3vaWSLJhMHfa7JE7upM6WPhnaNJ48xFu21tvhZHiUvKgpLvpkzilEgcv rqLv51GB8+DStjkAjv6EcBisPDxMzYGTbBtDvOVLPB9Y/GeZt64c9e65n4ZmsxiX868gGU0SVuTN DBTrV3KpKWfizuMzTX5vjgKM4hx8g2MBcmLslIEKDp0hs98h8rc4cxGHy0LtGg23ppEtPiGBfsgo JntTJxERt8VFV/5RwOYRDuAFEfDWJEj93ERU/UhkNXDFfJwsRk3WvH4QGyk0FqNKuhCpMfy5EM1z 2FE/LxMshRnHSYwt1ELnMCoFVO/kg4QMMXh62YxSP95XtdMZ3Xl5YMCAuxI9vUHngqsbAOg9PSeF moDnl3I1D2uyDJrC0+AKj5gGLtIS3BczOtAkIAbWgqyfl6MzJy2GiT9wm/6BvhuZWHTfqgZelLxJ MDVqNmPc7UnJ4C2sPyuZOBOYl2UNs6npgyzGpZO1qPcROy6e1210h41gmxG+ATMKjWsvMDQMV2Fk yW1ihoGyX/hqElXY9VHc63riMVyHKxy+mraMVJLdt00q7r+X0B2MJWkgn9Z/ec59ZukMJ8zo3oN/ LkHhSh4khx8826pDC2DI8ytaPk0NjOqAOnjWOd7eqrnHrLgzcWGtB9vQOr/fcmluSa5LlRcaGL3A GhDwc4VX3L5NHp42DMJjWGicSduZiMg7VD4UL6xGQ76k+NykR+r8s72VxDNdxnNz4iyjB0pQNHj9 E073SymtEWM6WguxZ8+uoIIxbB60eibnuFzf+udwshIWQRIxchkBa2pNIqbQaSEr2ylpXkkPiCpo zDm5GJbyETiv4jWDWASwhN8w9qUxlKgd3ARQznk01byWs6Jiyso51sZILpb5ImPMpeDS+C21PBwb g6BRwkQS2uVtPbFEGbSqsitRC9ABojyu9zaTLy9MUB8Dddh8xEWx1D5VzGQh3HvVUarvbA9P11SU p77LEqd/sKQ6T3AyHYi6HEtaSV61o2/Ofqbc4ttsrM6y4jMEXeU/W+oYOFb9chuX5MH+lOsbdQRx TIH+2l/hX61YgeEE4tUSuEbUGDPw9W0GI6XeR/n0H1maeX153cGpRlq6OtHcC7iPp0aCwzJfEPxf Oi01AH8gA+gvcDQuM3Du22XWph/q0nRg5/LycvdFS42uj80EpIIIoaWu3h2p7uEh/PrrEkjcfeN2 8sezKdXoMyhoRP4EmjpNsgfQb2/h59kEe4rt/gR/HUU5/DrucJc6romjDDmwLGOD3+WlOsNTNhM8 2Mmhd0bYETJv3uy1HID+8gbTonDXllV/3F9JAgR/enSpBl9KkD9UYAbqy1d70MUoXdKpdgZ60N0D APs2WaagBU+5J38FxylLkjHosttSwAtoFOJ+oMIcVNctYDvTr17v9QGQDV1lbPa1bfblJ1xtKy7d W9Au0RKlb1QCBsAVYA5ejFjrYDrJ3gew74aXI6/VD29V9/Veu6t2+os8TrCVl7u2mUNoxnLeVQeP bJ7eUaJl4EI0AxxADEa7tvrZGw5TBi292t9/c4ATE4tSkzoFm2j3A/z4CgkK458i/4ywSQSINrKw B2mDugQ4NJE6lLKRp7X7z7m9pHl6xYk2ckcpREe2ewt82D2Qwe9233iD/8qS6DWQaDgYDFAwcYeO TvdvLTf0RKXTDCt9kR3PNLpJGbjwoLb6wCgOAzlZHCL5S9wK4G2EUbEcM36UoXuVoISnmlCCHpil Lh/fAAb9cTaOWK6pnY56q6MpmDiR2sq55a5E4oUnqdTPg9eHVsywp288hfamw6dYSN22piO2zUP4 P1aWVx3Rl3wT5xcSVCOLjOf7+TYQtKvOO4MOeLDgXvTvdLqUGo/3cZIU4wz3TLy4UurNq173gJ98 GPX5xz+wpc49NfOfODubdCY0S09PUUnrJDFsR/d+jm9AoszMMCiI0yO6/6b7Wo0WdHLpSQqqQh2j c8t46BwcAtBQP/eB4N1XewYH+veWgf/nHQIGrwIRYKbq7nXUO9y78ghcYs5IA0OUxF343N3eOdrl ijDaZw+P580msQb3eQdZdBfJDWCu8N1CmaoVm1i0dSLkbWJxbxLZzGiMaU6ZWFtg2lEy0alMu6Ad pwhGvFWTpIAAlfiQIxKMbrEFTIPm7ixhcLrAQ6D0BoLJccoPM5+S8AhdUIMHeDyLiPauYIxayplr PrIc5ynyeIxTnrSlxj14chobht8Yc7XsjKOphoiz1MSW4ODGWLsiQeDUhVR8Qu/EUh0csHiixUcH SgLoiI4hlySHpHHoLMIokaCUcC4aSdVRfj1FODSymyiSgJcZQOw55TywK5xo2bh3TJuDZt5UUQ1t IEfunArxAmsMZEZL8QQfPcvymyiN/8k80iLHeVG6KYgmDxLdJtCG0HdAyAIqrHqjQcL00MRUiwD5 J3q6xMohTmzYDrhTgcXDdkhbePR14WZSzcHByBDEZmZKhDjY8Lwk3+BOAjHCkqIX7j3F5uA8pjfI aB2uQMPMBU5CLfAUSHJBC3VDcfhUeAX5AJ4uNOcRUmTQe9BKZgxzcEE/aztP3UR9lAMYVexNlheK czwFZhwKQiP26rxMtOjnvKSuABrBSceYJk4pUcLMTSki8ABGajh6ocZRETNvXr8fKGMi1ejiaDi4 /rvqnx/TA2c91eD8p+H5YHA1PP9JXfdHJ+rdxdXRQB0PR0en/eHZSPVPT9Uv/aur/vn1cDACD+1v l1eD0Qg1MoA5uzwdDo5b0NTR6YdjBPL2w7U6v7hWp8Oz4fUA2ruAZv9uQPwd2u9fExIfRgN18Q6A MKrQ7ln/enhxrt4PrgbDc/XLEFpGSPAM0RsQnKvhT++vqXX8S9pXT+toPOcWpI6U2PmzwdXRe/iz /3Z4OgTiQLfeDa/Pkb7vsIvqsn91PTz6cNq/Aq/w6vJiNOi8EOOCRz4PvixiMabH4m8RR81Bd1Bu kw6PBmn5yzSPZmX7H2wp2zpatCPOXu/tdcov5X+w8tcIj2x54Ajud3yCPO1/TzNkuMvb/wNQSwEC FAsUAAAACAAOX1wutTXk3Z4vAABWzAAAHwAAAAAAAAABACAAAAAAAAAAZHJhZnQtandhbGtlci1l YXAtYXJjaGllLTAwLnR4dFBLBQYAAAAAAQABAE0AAADbLwAAAAA= ------_=_NextPart_000_01C2DF69.FD0F6580-- From jose.p.puthenkulam@intel.com Mon Mar 3 08:56:23 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Mon, 3 Mar 2003 00:56:23 -0800 Subject: [eap] RE: comments on the binding draft version 01 Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2E162.C472D5E0 Content-Type: text/plain Hi Jari, Thanks for your review comments. Hopefully our updated draft will address them. Here's the updated version 02 that has just been submitted to the IETF. best regards, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Sunday, March 02, 2003 3:44 AM To: Puthenkulam, Jose P; eap@frascone.com Subject: comments on the binding draft version 01 Hi, I have looked at the binding problem draft and I have some questions and comments. I've inserted these to the draft itself, marked by "JARI:". The URL is http://www.piuha.net/~jarkko/publications/eap/binding_review.txt ------_=_NextPart_000_01C2E162.C472D5E0 Content-Type: application/octet-stream; name="draft-puthenkulam-eap-binding-02.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-puthenkulam-eap-binding-02.ZIP" UEsDBBQAAAAIAEgEYy5aVIMRhl0AAFdSAQAkAAAAZHJhZnQtcHV0aGVua3VsYW0tZWFwLWJpbmRp bmctMDIudHh07b1tcxNZtib6eYjgP2Twpe1pSWAbKKDP6Rhhm8INNjqWi+q6BNGRltJ2NpJSJzOF cQ13vp0/MDP3/971rJf9kpmyqcLumZhpEd0FUubae6+99npfa+8PR8nPRfkpX5wnP5bFapl82+cv RZUlo1V9kS0+rWbp/P69g6OT/eOj/ZP+3vHw1clN78ef9/mkLsrkbVHWv96/d9PTaz4HizqbJbtF uSzKtM6Lxf17u2mdnRfl1Qv68awo5/x1OrsJEn2G1cVlvkhG6Sz7lJa/e0722UsXyTifY07/Mi3T s7q/9LjrZ+myf5ovprQJ/Ufbg/pL/ee1kA7zSVlUxVl9/95OcpiWk4tk+9GjnbXP3/T57qXhc/8e /oTfnFxktBXzZbFaTJMhr7XOJ4z/5KUsNRmVxeksm+PVk4u8SqbFZDWn5xL6O+EL+1kusrq/B4TR N1P8QJtytprNkkkhO7qYZMllXl8k6Wx2/96yLD7nFQ1SJcVZMs4mPODWI/zr+NUuoWr76QADxsBp vJLA6DmweTAMmrmbSbK/OM8XWVbiqZO0+nT/3quipAlsHOyfvNrsJblASqueTJf+aUDPcbiqQZIc FXVGUNM6KQh2qT/cvzdPr2gNVZFM86ou89NV3TWjtGrgpVq7HKaz4NXP6SyfJoS0JE3m6Zd8vppj gVX+JSHCrC9oDpg05nGaJavllA7PtJeU2XKWTvA3erM4rYpZRt8np1c6/2Bu2KSr+/fqfJ7RQg9q 2a90SbuyLPMU6y6SVRUg1KZb0TBnWZlhN+mUEoZT2k0akF6Y5IywbK4DEu4WeOMBsAN6IPDnZVZV gwdCSlkyIxRibZNVWYKgmuiZEARaYzqZ0Gu0mJRO00VdL188fHh5eTnIs/psUJTnD/GXh1v5tJ+e 0p6kE8I2Hc7mKA1CHV+k0+Iy2cvLDFwtz759vIpfHVzU8xlv626xvCrz84saVJNPsvi7jd1NPmcO m+NiQqCukg1whE3agiEdlGM8WyXHWZWVn7Mpwx3qcnQlRCwgmCr7nJXEHec01mc+qhWTy6oCDU7s NKfxaZ5n9UUxJeKRx+rVYpHN6AAQAdNWLvr5ok/P9+f5dDqjceo6nXwSAl0WVZUTB8AeTrKyTum/ 9+9N8pIIqqpxsun40FDY/Ct+g2iH6BDHvSDok/JqWdPWp8sLmsxsRnSrnAWHlk6UzIxo6DwD5QyI IcgKiWLqYlLMKqMQvJvhTZBqgS3CIPlCIeF48wQ+r2YLgoBJE2XSj5VbEp3+xWS24vEP3uwLU/rr 8KeT171kdLDbIzCj4dEwKWgKycnbcS/ZJ9l7wn/DuRvRPwdJzAirmuARFjCLpXDLKpFjWq3Oz7OK NnZJ/IR2g1ZFR3Mlu0Zzm+d1fp7qyRkIg/Z/AsmdEOGks0HIvG8Wlh9G6XmWbH1k3rNG8Dv23+D3 IZxQhMnMThi5dKp2iSeBreDLLZkeEXpZTFfC1Aff/OGBWDxtDbZ04PGkWGa/AUYEZFuBHDYOilvx oVJeF5DHCsREtmFlXNNu8a53Dd8A8kSBPFYgx9m/r4jfCB9+my7OV9ifbwTyRIGcZOU8XxSz4vzq pjnIR4FsD6KF7GXVpMyXQMtNAPDBqz/wTLbd7ryjM/I5zy6/bRqDGIjtzpDPJe10tkjLvGjvRheQ 5w0gRIXT3O8wDqKc92uAbGEZpJ4pWtz5HLvzue7l4AM42zyZHU+0CoA4X84y8iZAALKjQLZbQAri sMv6xtkAyGMFstMEMs8mJI7zan4DGAB5okCMaE8uLtOyNn59PVodkOcKxIjWzYTVjHRCLPnGmWxv KZCnTSDVN7IFAKHdeSxbfOx0FweIRMcJS0JlfCxuOoDI7jx2W+x45UVKomX/C7B7nnXOoQ3EE63x oeEuy5YxqR2Y1RuSo1MiHGFaMZAnCsS22GZySO+CmbxikXANcgHkBwViW3wAiUdnqMppWOGUa983 IDu0nCeC2CMRQ58zrx7eSK4eyFOTGme/BwyAEE6Gu2+O3v38dn/vx8P9o5Pxja/FHwB5SkBIC3h3 PP5DMtzbO94fj/d/ExwAIcS+gtnjtb9vlhfyAZDnaqc1tYG70Q6270A7EFUg1APw3bBqKqVewcs+ FzNSe0XtgmVC+mOWfqJ/FAuigov0MxS8LGfT4jQjbdMMHtg782Kan+X0d2hUGeECnIr0PNh4mHSV kQKZk8pNViF0YDr2CxJb2eJzXhYLFscD1tGnpHnOiiXvF4wuvJepsswckPjoIv/3FU1pln8iRf8D KYYf+fB+OBiN93c/ylTPM+ifMMDSZFYwrBzqP6mC4DkyH4I3y87TyRWWcP+ernctiiLFfZD8nCXQ pknDJNSz1l+JBCSD7CyZr2Z1voQmvw4c27amrbNuD0FT1sAh6a4TgCTTiSz2BAMTqOWqhNLdW+sx UH2KUXnFFur9e6c6AMSyWS4KKNLF6aHW2vEO2Q0LCJ/798h0YlNSzDPgjLBJaijNEQBSv8tpVZGJ 5WGQtVIszoi3sYDnJ2D204ac8/NAivogCHVkUKcJ2V1nZ/lENXLC9QWd5hmfaLOB/kfLbPqfzvDI aRRYBDYTtVTI6CYiCzaLrd/rLTa/UWL6sPdEjB/4CGZE49Mr7B8s9rqYpleM/ypT5LZIwOBiMgqZ pjAvFmRdEc9NlxVxFJsxwU0hJqfZMltMxQQL4NFTBIZJUubJnp0pVj4VhUzNOKD3M1tHS0IfoYas vGKeJdmXlMgsYx8Otul6VERHwK2PLLLDvSf6Ix1J+jfstY+9BH89HO++Ho7eb3/UBz7AgqPfIiuP vqV/ykugDYLCNuFHsQ8PxsM3hyN4M5akCrEz4c2+odl5hGw+7uzRMVq3DjlyFdkDrJCw/ezeI76l tCoWOIx2eYHYHEtG2JzEvBlt8RiDRNgvGDBbT2ytxX47Bn5mFut669/Rh7kAiElhosSS+5dpkxBs WxxPIUaiW88EtlroFDFrYlKLjAnYI6G1FsPXn3hPSMeCM4T0ol915vfvmS29UW3qbKdT+JhCVZUZ +wRm6hcz1dlFiUdwZjCZdYTHHCirWftVvnNWFnOcicaTNBc4bkrz861yEPzsquf4hWHV0ctp4Fth MjNM6GlYQzzEROlEnnl3y4IEzCpwhtj2RBD8BonP55KEXbH47yHGECuonBkGf9NAmR+wdsUIKwsa bJLScM7tKuviLVLxGbg45MylyTz/wnJpWcxyEninKfvXsKuhd4jWmC5EtomPlW1UuOQCx6PfdRxI yNdz+JWIlZAFx/ozER5tEPw2Mo6X3yb+cEpeF5cZaxu0hiqdgznRCc6ZG02K1WyanHrhKD7NyYwY +prt8ZKVZnWZzWbOm3M7etrOHehpW4Ptwc3ukYjrCjtRygPqzorZrLikJ17gpw9bH5PxarksiE0C mCo4a0i5Qw97kegIRIzN30S3Oi2LFeQwfi1Dh4pXJoTD1VeQlbS2CZ3C+apeEX7jifSaE2PZ31AW etAX26qCutxFl5jm/F1aXtlxCHQK9gOSKgwlhugLhPQpuwo8FdEpJTr91CPVZpmR4gBvqbo3jYMx 7V3Somc4taoUQZzeoKuymMNUVJiJPiLz8qqTF9AmyumEgZngTHmdsL6QGE8KxqcHD2yMZAnpPz19 lzVcAk8LnuVnGS+YNPIriy8ocSg18HlhQgXIF8lPVaAhj+gwM4Mng5sYHhAYmMiYyrNH24OtreTn t8MjsDiwv5JwweQApbvitTBb6EM9SDrVFt4Pr7qwsmX7CONBPfMfSJ1ge7mqWRh3oI8jOJ1kLyQ+ XFyxoUP4BSV7mZ/UV8tMYjJiP8GZTks4zQj9GbYccgikxpo60QVtIllZScqqJOI+Da5qrMlF4HiZ Hg5kV2sBZIDRuxeYCAQMYU62Lq0+xcQgApb44ec0n4nqewUqBQ/slxkchJ08uJssNTg4FeZSMCch zaHm1fq1VjlWWjpOAmzHaKxUv0VQh1Vjcc4Hij6+MSIgWVM0t0usv9kV7fi7BY5B49CR6cXTw6LW 2Vs6vx6fGKLrBfzmFS+kSTtMMAiZxpQg5wIHApQ7PjhMHFkrTXNMIiJnFs9pElC5mEF+/SqcPuzE 7PqwQwXFc0eE2uqKJjwnfC69fROEhCYpBlWG3EQDLNKizHhLWEEJV3lK6IRFT0hNlllWVhpfqYjc cUIc1GqtTsSEHSjHHeexZoULpC5K1nSQvLxyuGQlwBRRh1hBHp8+2znH2WguIT2RJCBytD0EOGNr SeizuS1t4PEdaAMfHn9M9kimFVdsJqQQQXWllnvssIg4GY5/lrImTTzZvX+D/2SlnhkozW1tKp2B SFKmMOMQrBIejEjQJRsILZ5fqA4MBYRAdIr4TRL96Sfd4rkozyBF0kSXtAcl+MM0RxC90kPi1lo7 A+F6NUZ2GCcUmAgOHTJTcDQ1ruzcFaqq2+JjqBahTe1nHDCy1qAdDJIjYoKzHOgNvg6dOYxdOkal WI0lf6vnZzowtW9n0A5oyW+NyKaFL4WVGlnZsWN9zFx3bBhBRiKGChODVpWXkbeD3RO8q5x0sIQ9 l7N8g1jHecc2tuzRplcl5DphGFotcrjS1Cz6tCguYXkJr4e0rVmzDP1lCT+tK0XKxKo2fyM7Gs94 ySVJS/Z+fDg8ODn8OEiG1Rp8XEKRWMItA7Jekow0ZbO+KWosqSlxaJ3IsxFK9tYVCFYjyI7CA4sL lOtkv9PT8CLgRaaYP5iORhA1iQKWMw1YMudZxKvpOeceScZp7ASo8vNFfqb2YwgQljczXui6Z86B oX4VD6g4o4lD8OQ1aeS/gnXzUYMSyE/dv/fg8KfxyYNewv9Njt7x34/3/+2ng+P9Pfx9/Hr49q37 iz0xfv3up7d7/m8k6ezV3XeHh/tHe/w2gR3+8kBcQw/ejU4O3h0N3z4QzTzcUraJIGfEZCiJCtgH XDlLlo3JD8evdre3tp5/dLhGICWI63YdxbOSxRNIkMV7HdpetH/lvGILLPDJFlFGHLNpWoBqPrAz dDuM2TU8SXcht57cgdwakc4gv2GJYqkHC10WtBf9uujzX2TdG6PRiCRD/FOILLIiiKLPGfMbB/v7 +2JffNmEz0pNDacPisnm1OUQjvhsYwvvVI5CtFEDwmDix/mrMosQFJZEXylLEwKA7gb+sqi90yRU m86yUjNgQkiMMPad7IosUUwNo/0ni1LEEwEdNCjL/xzCPbCcwIyt76ThEV50DUDsX/01IaQGbkQd 1KcTGlW8lyxxMPHQYRqC0bEdyrHwnrwxS3POqzNXAWkJpPIFz/GSx/lMjtxeXk3SchqfJ5oUO6z4 HTZIQC/qSZAXlL2nk090ZjQjKgRytiqZXmmmsMaIWJS3NcAJe3I2eWNDnU7OhhdxkHM70llZFmUY Z+HFa86O7nsIqbIF6/wJdzJ5YX46DRKGxHZlgM8gILgCIjCYdkX7x640sEJBp+ne5ltas+eRas/H KgxUeYcxVESSDUSjixBSuhAmcMk5c1mqATJYxiL6ascnAIImW2oAMIISzyevvHktgwLKWQ5+J3NV T02EB2dS+LdFC5O0g25MnDDgsqoNcJXRZq2WziIRl9LqVMDbY3CCkz0TQgrS4+RNHjvKXmgO7BQG jjAoDjkp1ZlyTNIw1KKzhiSRSb4UVcQ5ra4L6DBW0rLMs+hgIWlQt1VNKcyX6H7lUK2qVozSMJ8i IiyXHNEgsd2CjtIGPb3JkFZgzqI+kWaB/4RQLN9VuI6z95shndSv+RpikreUsSlt8PBTb3polmSE Y2xYvNY32VW0DZZDwh7G7lWtWUm02PWrumElEVtavypZikQAxDqyKHEEgL2lLEFFhSdtB85E2Noc AYYQ8xq2UyR59YPb1Fue3oHesj3oSsZL7MetgUuwE23QhVoiZTLWQBWZc2a6tFnnZCRVcA0uVvNT SGsxCSR+zPmyzh3XmRmrYdDeh9HBLv7foqRRmJXTHzisOkj2wW2FR1SemVTmK6sCZwB7sq8PEHBy A20yQrisNm89f/74I+fk9hHzZU16+9ljTOjdIuufkN7TH6VVBbMg2Xh3Mtq013botR+RlkHkcVJ8 IoNiN8UzP57sbkZwJBNrsioP9pIP4/3dn44P9j5yDIjEYalRTfWMC1axklMCfUbWG4xfj0f2gRJh ELnWBTG82G3dS85S2hxIU8LJpHZRiqY75LfFGjTmAVeGIH3QoB8iGHFnTSXwvO5sB96aFM47yetO zeYQR4RIVPFVsJctVHZF+Ko0Bj1B3nLFAPtgXEjz96cdiPdZ3MEgdA2yFhPaQJeW7hwyVQsKpz04 RVJdLqIy6wKFvkUO1ia1G5ii2US4ggOGDHPW9mn1PvwwhXSLvIsWXoPiwGFIr8yqKqjP2WxI8uEF uDdAiJkUsJgeC/oDE0gREKi4hqThTuklM2HHq0W1Yh9fuJmS/RNuIX2T07DqV1isOat0VPOak8Kl FiHjc1CZI982K/Fk2KguYM+cd+u5dAJaTpmFhNHkLKs6h1NAzlpKbPzqV2itAecRHkLsW0IMfNgf P3omeVuc/cHH//FTYhGnGUe3u+OFBGNDz5SfD2+wG27TAiY4LGpDQAGsWY3J2eHddI4vGtRdtWmR sKDbX5TepJI3+aA4YGdSqkTbAtZUXeTLZEOIl79HECDrVxeE+6koCU611vUQ798UmjdcYDb8KLMu KGv2qObFKBotGcFrphy+5KyYaVsXBaBuvs82WpkJKmnUOcd9lCldqC4ggz+kgRFXmbIJX7mwNB8l tZLXnVr3FhnPGK81ncahNqa57kjzPlnMwMguLo3JJRjFjjtTvCwdLtnIBmT+TYlEsE/0yGV22nRn AxQzRzlEGTuwQQCrCYc3w0NtRNPkyj0B4iJGrXCNbJVLgmpJfyf7QY0q+UHqrzSi7VYUpYhwHGWe fspkVzVaI9lPtZSMtbdAuYsqog1+4rUKOa6ttxEVLGqREaEX+SrJvuTwpdIGIUKN//KuYoDqdl1e P9yB6mgnzRz7HMB0xyQLjbFiYcbYEsHYYlUlDwR7TWw9sMwV/DewLuOnKuENHnH374W8IdT1M82L d4zBifMEOxuaIffv/WfSK/6zI5h4SFVgVhY4wCMzaDJInxQS76TgiOtaUJCW7fNDe1B+yCZR/tTM KxDnOPQql1XVjTtBis3pQRx/V5vngY90MnvvmI7zTqxjWXocmAlaSJKPTUTd7E20NIaeIs3H+y3x RHhkNABLW+dLk5hpePZCdoe9EiHN+0M2zFJrQJnU0pll9d0c0TF5QgaJRKnZAyGGSsqmCUmVC0vK IlLKpk4QVLFCATpjjJQZaZS1BCURgkjOZullFUg5UwSek9gnZhYoAYQfxO2IAZpdIDG+gxHtWvJ+ dNRwz5mXyqLfmlXTqUM44RmwMdLYC7EsRG3EAVp7AG2Vfs+tzBHqreY8og7Ekmt7IoPebp+MJOFV loG17WzBLmJZI1/qhObwjHzYe7074q8JJXnllYQw9tjFci0IGSsavUAUmJJk2h9i8dgxi0Zch8Dk c57G0U9OIw0GJUXaDduLxIWoVMUpYoea7KPygBDIfmVxAPsEsjhPRJjNIFTLFSayOjHLWPmBc+KK s+kRJ4DftSxmkS05y2nDr+FeQdDYmTwgRc1e7CWBbtfEuFftNlJzM81FHoD8D1PI+ENsdZOc+Wyp cHWmgSRZXC3SeS51vLAExY46GNEiJZE0q0h7lMBUJvXn7Wxh4WSuJC208uXMqZlft8Q2TNcv7L1A fjNr1p1LV8NumtUcVcvaSjHCvJGds9DqEgyqQmUBd1TtdHHHSQPK9czUqesZFANoY9Gu85RiTybP xUQeT3Cga2J/B44zR5Ml5LdOW+61tEFUvdA755x1LJOABqirAgOaSTYG5noOHYUe5CHjAQYa5GCL v2LbTxEjyYMIRZGMOs+iNTS2QpLF1hmj4vEzh72gJMaI+S60DhI/+nQnrAKpAxyo9/lyIDsJ2HNv BgzJYoX7DzhyE602TP1f49NyZ62W9AInl8QLDXK4ymqZxHJlKR40AlGyqUulf0629P49yZVxWRm3 o20+uwNt0/fCuFmS20JTr29IjmKQ5f8gSP4qMyLtB4NYXtUwl5BKInLOIIGonWMnsvPic9Gsn1AF xviwqaeWxgd5Evjzyf5qTIclJ6sCT59uQVyyPDXf+AN2c8+qorzyVIlkgapazS03x001SqxzkwMT YftjNBJzGjqGzHbA38EoFNuxdDYuLci7mSQlE+Sd8sunwWQYgoTxgqCpLt9JJ2VgG0fD8aZ5wABJ 6xqch39ObIUbMbBzgJQlzOPiqlKhoDlflpjcI8HMeZ6tlGVJdrlIVRIi2wYJrl1cYmA+cdSwa8G4 VSrITxohFieo+ccJenH5DTQrTnMkyNCBzLmdSmAJIRK68lTD3twZB1K66iCgC/8seWOucE4JCUj1 ZWT1hUv7Ie1H0qW45nHB1W3wjbMkCtKnnMLdF7vk+phMZRqzx+yS7EIwRSkhgVVzWhYp8G/Z5eaM ZDnLs3YMeJ7+HZmAivZGnb0Iq+sKg+CkMS/v9fqtS6uDFcNTsUGZMzivhvc7a7TU6UpB6iYgmw8q 0Ktc1ZqWIbE7unMeG9Vm5LZ0o7GHA9YbjSZNe7y3pfYKAWbplbjK+32ZL+RxTisbm+ByixAE2cw9 VVp5d+R9jnGpEsS0UqmXTsMBHLRbwCuvtqwan6G2wKLJaTeMF1K9SSmoLYjTyrSv1PEwIwtvUa91 ++hZslMTaXGsR02LTECRUKsRmQq8QAHrcsYgDRzZbA0iAxNP79/r0kD+hMYuJu3FUONz23IHW4SC lIW2wvonkEnkLA6TOPtNJ674BCot3ZNYWoeiETjQJEHr7Axbpz4Olhh9rCukGYc5i0N1m0mR5RK4 SHnL3plP2pEC1KgwQ9XTaUjOYolnGaoDC3j42e8YBA80lCVRAxUavq+SlgyIhqaBDKY6N415WhFT KJGMI9Vd2TlREXxFlnal4kqyuTaGI07J2gfpkGQh+iVcIw/LLBoM8QGZVfT61l+h2bE4PFLhPxRo 40D49YDw8cHIjl+Q5g8luSf2pheNLuXSp06Ihnm7fsTnd6DZ8ZvCtYLPv/S/HhfnZEwTNuifX+17 +WfjM6TFdeSCxZ+vKrUzJOp97f/ZPelgNx6/+Rv74X8FqBM5Ge64cOj98mHw6DeDUsIbxmd3Y2vT PXoTqH/512/8/PlGUN/wjf2wDtTGUbHoDyPW3PkcndzwobUzs0ROxvim/741s/jBf8BK/9iPPn/0 b8TPtR5cB/Cr0ZX9c2N7s+u51oPrASI7KNlTz/zX4IfrH/yHLXntt799O+zbmzqs+M+NoOJ/Rjhv PnoTqJvm4j83gpL/bOwvOMiQWXLXidcK7Zh8I6hrv7Ef/jGgTq4Pe2zsBBwgBvXNXLD78w/hjWu/ vR7U2lP3DaC6DuJXzTnteONGeM13BV6DzWw8dhSYND8teG3O85XNkpX4eH/z/I5IMf7JvXsX+Fvz Zve3t0kloPHA+HPE+ztAdTwlP9wIStTFP8Dbwpmm3wGqqosZGaTBN2s+Aaiuw/vH1un/87eACr/e Q+E/vvx+XE3LYrmERfrbQJEZnZ/Dc7ZFFt/hmp4scSi6281C9sbI+St3fviowcCmge6Nv3aAGGam up/EODjNNMVk2srwU/PQGXCWJ9YRrdCAT5Ac185PtyKSWVXcgumkDVAf3YHpFGOLlxD6nYOVKQ6d dagxfjPq29LOPXnqfdy9pCrcSNfgtszmHNsUjxQ7qruyK4PxBxHt5bPZSpJIwiY6PefuQ5l34H73 nqQJZ9OgKrp0tiO9o/b1CNY6pyVUdbZMtnrx25LiFzjHJEouD8VLjdzR8CxIRGDKfZylXQa7eqSp mrVx4tlz4xAaA1MTMt3XtGKN8dv0tnuhk017MGmCi2VCrvf7sC/KJQQiC1fiTU1/U6/h0OIVdwdy ESSLfE8WKPQnB6cmzC+JfHy1d+Dcv8eBBv+NOAHtacQ1rYGSy6I/0CN6kZdTxpAVUUklsrh8KmMF 8f6Pep7g3Sgy5aprf03XC9fiHb6uzVIQgl+rLiImX0hoXrKPsIGSiyAVyvmZeSKdo5jHOytQlhWs VAE6arBkJ8Q+4gkGiHUR6mg7nPdOHLqCmAB+GGS21I5pxrq+daUj+MyTBUFdyAmyA/JZFuIQyLCc zmhUP28JEKP5hIZ08DzTeXAozJMqLXkwD1lPZsV2frdDEpoh4d3j1WHFUjJ8uDog2ShFesVP4HKB q7X7H2dRmaf8JBiQjrPtA6/Aj6t4QiegHgI4KN6qJWXeDC5jTdG+cUU4+lQh64g3sYFFrajjiXGf IdlFRZal915eFPIiF9at3JvqVp2uMonlW6oZjbdEdDWKBMRe3cjvipjbPGfNrcdRn3yx4jhmnXE1 vmafRGSt1Ogl3mrBkTxi2jHec9eqY9qsOQhqVkS6uwyKnjYzayTU6KCMHKmyWyMIjopLObfc7EVJ u5018hnxUg7z0IucBhmmN+c0tHWTSVz3L9cdpJDU2rpcVeys0himsDbk70ist5c4XSBejBGkLKQl vvUpocSER0GERZJxkKyitcVc3wOsaD0egnMaSQgILWjagHBtMdWCwQk41xywoVekKIFh9mCZCC7y x8TAgfDaLUTyaJS9MkguhJHyT5ZwXZ0bLCbqipp2Bl29usU5bBTjq9oxYZQzc6Q15dtE7FXX8aKZ 1phz630hujpqsscl0rP0VHKeqywE51342Vn+JdndlTqgsIJ6Hqa2uhZ006CN+u0prHfRsp+Uod3d /vCjOfyxvmEnHWpniEahT7I2N5QVClUszTZR9ajLRKkEt0HWvNx8gA4qw1ZjxTgIU7nSL6fASTcv VmLAVlzVUxBC03Pt0zYwWZSZ2ustdVJzPFyJU2ntV1fLcwSnoDEFDYek3r7QiiN9ppKqKS4GWeQc iIV9I8xOMwyRfiAzgkbtAeYLrVtOK03XDxPRkkvjUF5D4JDvWZmupiuUcEsGwmLqzijetoMxkLuA QA8vP4pcVE7JDYw6UiZq5tftmFxYYsCCp3PzgmyKxtvB80Wj7kpmn5U4MUJiZ6vFRI5rlSNhJ11k xMe5QZdST9gFzoXjmVOANC60HiRqYUVjGlypEiIaGEoSjh8vrThRgLfsSuT/nFjwhOVIztX0YQms 8G60/3T97oLmeef5Z9Vr0bdoUsj1NJCby7mtuy6KGbNNBqqX/QRgWZCBXPIJkpzjAcCW6Iz2yZA4 Ji1cNkE0eWz5rmw5cXPfM2D93iExVqWNl24+ByN+hw8PM8lGDy06G/k55IecHIHBZ9Pi0nGxDvSU bHZGc05ka3++kNQFWGx6nEk6VzaOZAUKKyBCQkQ9yvz18e9E8y5EwY7YE+kzrG6RZojOqFxdp4+D +wVLqJ3KwP2dwjSLVPqBYARNxMg0qUObS7hgvjOvsCl7simsGPL7XZ1DWHUi7spJpWGPyj7T7fQh Ld31quz74cMOnmLEoCoYHYp8kkflTdygsYYaDQ7hYeM5j153AE8MlnbJvWrsV/h6x5appW3lc4m0 szbxRbpD1zUdojbkXelfay7dwcRbLM54Y8Uck/mKV1rtcEseEbiYZYVJooVTByAj5dKPnmWsklbo c5174QUYqhXmpVxooS2xdUvu3+PUcNEB9csqCxYCXDFbI3ZWr8rbyiNVDeT2rwXYkZ7UhqldxdM1 Wp9iwl2jIsKpvam88Je0d5fccQV8kBYozM35aO0z9JtlvaJc3YbcI+DzZ7hILI97MPCn099QOacM Hwomdd9CgTP+W4BYiS64kooFAtqkFuv6zflyxF4LkK+d0IsRrAefrcFlBaa4mVCrhhpATgsYqLl0 5pxdmY63gHW85OpeRvUYyTUk/Eh04BNgVPvDpNMpGZkLEvKzpGQ6qUlHtrN3EzZ92dhiKs0Mpnpv Ql5XrZelyYQRNKSp6OHmQ72eGn5UWQyZ5HatUfbpM7i4xLgFI8yaCjtPNuqP44qjFpS2d7BRmQxs HA/3Dn7Sb589ffKxF7fd4c968ha02jaERdSWxocDxA39GEIL9Elo+ehen2YOxdbHPN7PFhTf3CFo n9qVwYYVkzRpAfDpiC5c4AjUnAlummIxt0mdeyWCF2qZDrrCg8EsXeviqDOro44WJDpja0tcZKGa tRc4IVtAxKUWFsK4Jhe9dyejrtYVvaRo8xNtXIE06bDpXJaWtECrYPCsgEUI3yDRghQXl6n/Cau6 yP9OrJYwwUQzJBafQ81YlelNh82J7DZpkqo9TbkAiaggBNk+756Iw4PHZxbN86DTGx5dinsDhmXK R9sVuNThFArhsR3XhKE3b2iBjhVz6CbaLJ2h5jhqNyU2OOwOZ7p7WamahMpK7Br7sT5ngnT5FYp1 waGQistT2u0hcVLEAOTbeHBOuKG/5qEnl6k6BxeceMvyl4BKh4OMSw8m6pNUw4yrktZ3abIIWHei ek/ab3ndKa9UIHJa69/hqsIEBkFjP6//WFI3LtUpczXUCnWoN9qnmSZxU8J8wVYI/f/nIp9aBn7L 9xT13zGtc3uwk2zAwTIYDKDPb96qOnYX3f/HBV/ygKsg+I5U20dPTwQxVMQaCikcFGK/jLc+Ykje tYBu8A6RdocLyFt9uTjN7aAvM/WWqu937e0kLtIclVoLEK23VqVdHSCV38EERjDPnDEjxoNRIdem uEbOxJf7zLJDDWoVFkQnCsXi10NW6sUTgAUsS1KDyqumxxDUo2/mWuVgTZx03hwFABo4TxkTWhSL fteEFI45tU4JndzxmLZgliHgwkUOZ8wcvFxUrRpWB5GAwmBDlbuTc1VOhBlMoWt4pYHtj8mPqxTX NWWBp0Bu1sgkxmtFX7C+M8mcFpnti8ttHt1dcgJ3ukXV2VfZ3GqFEu34cN2OO54Wb73rRcKRwrAd +YXvBMmuN3D+noVmVHX3jbArUd0klOQcigvXM0khcbmbKNzV1WJyURYLtLo1nWTp/bJaXyqkMnSN M+Mbl4SfS6AqXKxSJR0r4is+PlKtMpuIroOf6rqRSK9h+JzpbAWU67HJG274bxbqKKnsgF2IWxLe tiBFINmg5b5EFKcSTrP5cNc5GE+5S1Bp0GngfKlpDXWxzlUoRoTUP/nKl0FICd0c4uU6esEbVv0b O964pIpmeCWsMptaXVXP5sylcFxCxsi6TOvJxdmK+OGVZOXM0st4f1EZ5nfEnXQcjcZ9CxeilYnr 0KLINDa6LcMR+WWJ7s+ybcZ5TEqaoAYjxjGYTSVk82H82HP2NEgziQ8JhGCJ4sK8qwFi04r1gQNA cdyEvV7SRj+4JUVOtkLq3qi9tQd7VhU9USMY75BTPeGrzOccY+V/gbXZEWhyOM6gWsd+e3LELovF H4RZ27rlqAlLvSjQu1YUHA46Bs642t9aqK+2ubQaaLxD+a8s+ExMj7eYyMePIckBu/NOpfG2+aYB gNkuY0YYq7KWwPItmqkXxnxJdKtnegW3vrCCwL9ml25Y4MGpFS09Cj5DrunGaeOmM8623DEP7efc KcW3o0nd/s0JO4hqemX90Dn7zLXllhX0PHCX87lG7d3t2CWvo0PVsX0dIvQs6n3a0aIfhgIXk9r9 k+IWXzeabCY3bM/RVtoK/SaZ3o6gh8AfkQ3lhVcq+TbXKdeX0mKrszVOM8UAld56O0A607b+hDK+ aUDVcu8v9Fh9wTzLKaOiMSxTbokUijBxJKKY2vd/9n3dRBuRkxgFKiV6KZwRPzK3CbrwBCETtEaQ YGAaXegSxB4EBgePpsoLV1Xr8hFJ68JKJCHa4kGnfH+bzvL0KpRtEguFm5l0Tyxd8zq0DI8j/wCk rfZYVRU4zpT6LMoYMbMq4+h4WLkpo1tgSxQdladyM9K+NsBo8w5jM4XFMThK2eEu8gZkhPoI85Km wRQreR0B2Qb3kIhy49S4FIlTtbliC+m5mp8F6ShpFV74gn215p44Sc0TJnBEqAlvpc3k+UgtJ8fr HPtuHR8nQ8Ib/cQPnZ7OrFWbpifcv4c1ppx7oT3/skaDudblQEpG4oiQtNowJGwBYTE5WAEO82J8 Mo55gu7fm4pDeQWNp6uoeIpYN3scUtMPiMoLPxdovStOFY3jSxJIZQbOiZzo2+UPpHvfpbexq8Vw UokGvfS9UDkGVS3JHDVnFZhxwIMDX0PrwqzizPGbCXcIY2YiN5T4vierhbTjrxtJ0FEgjQP5Dabo Usd0kGlDdWrrTEE0UvwxqdxrJF0knPIWXqDk56kBZJfeWHLv+09xP+j7doWXbHQ4iot/ORkbtW1O /cWosIfry6Iv3cNdhEa1Sf6S+HPUgdzdny72ihPBb0gp5mbeLEhfq6si+5JNVrUo897i2Wb/K0GZ VhfE32xDvE/fXN0JN7uC3HNf4arphO9SzuVM/I/u6f1PszL5W7nOCzJVw7vmeJYTA9xbllLbP7am lY/nd27uzUbnycYJO22YCeMqzDkYHxmwolJJZrZJVeHU2mI96KvOFBmmvMkNqNwg358uE1an2VXB YlDjlBbAnxdsomwmt6ec3cX1IAdyN1lcDx8os+KHgkQWOcsn5Lo8PRaCyCXRXOncOxijNEIJtGsj D+HO7oANmqFyRyMegAsQ+yQGl4Cs4XGNfjGkLGgIgkPDvUu6PJWPB9sD4YXttv4xBGWmlesjjkfW 5/n1zORxfJCoZ7UwhnIOuli4dBOopA1sEe25vj6a9gVrg5iK7ThfgkMTebmlaar009bfaLIOVypS LGel4jYEmnQ1z+QegNzqI4IXuGHgssBwrvTg5bZ7Jc4iolG3ZdT4gm8MRhQXcYIoYzlIpckUhqWe u+btE7nbSu8vrMVHm1qzjO7WOGFlkeHqWHC18XJr88P4b0fvjnb3B4PBGGN+TJqfrwTjO2soUYe2 tsLpWz93AMPjQ1KlN15ub37YdQgZ7HZhBDBuWu8Nnz/f0lpcdc72i4bgtHstXqE/m6mYk1lasqpO Um3B3bGUtwjzYN867DkixVXm8xOYz1wWaACDm8UHmiNG3EXZlObqmmzRCxxoWifjN+70aUwKvbbf VBLf8TpQeN7NqGPYvrWn10BOszO9MbI5pssPsPPi5ZvMeprR+ZlVntH4gLFPpHGsNOaMrCbSgvA5 EbY7Vh5P+ohP8jN9h6eXCrxQmTLnF338mlxeVVsv4Uh2gAdz3Xsw20+eEiLUd2wKJllnkpQMo0Jt 3Vx99Yq1XgAD5of7ui7TRcXdJxdyvx3MPq1yYPfZQlRyufnYA7EqQmY9B4qrA97bAFWOYGTXuyt0 1FrxsDtaxu83SUd4sWCgkn1kn56HIon0C17ur1lZJDRLRrDL7Ked+0zHhHdlJv2OpDkxcOkBqROM teAJXxdp1Au/bMd2PX3Me8R06MF8insoLeWypwblgao4M3WWiTt3MY3zDZoTxhFTiWvNxXFa4Uer QRMu1210/Eo2S6WAkVJCBDDFpY1yi4VzyYpSYbqQ07pEx/DzgfxTJmJ7TWLZBOaGyOVNxxoCYeph bIgM3LxFB99dXNWy+/2I68CbR9t2gLYAIWBmxNUcDz5HEojk0MYcqNupZnTmTUQMzZB2D9/87aX4 jfmv226bdnFUOn4uOTOTr8DuWGughKlmVGZL834woYvppwdjdywtgD04+X2bl62jBzfRy7S9Wd0m NzziSM7jeuKzwyxXaGv7mfBRmpWcJPvFwLO3xcPAvcQsMkW5tUPkEKb/ZnuZ9sNdWNZi3THZCCNn lTIM3REHn6NrrRiPHgbhkxTUjDMaPjOH6LQZrNRGt+0bcLjdwKHQ329GoQlGhe/fd9q0Ic5dlJh2 I0ZoQOWKm38gWoK7Fln82iELzsdZmBu1ksKFtaLaUOEjULpQD2Lr+XZyesXmRLjksGSDc9l8ri4O UqADlCpF8EimDrEdgZlMLlaLTxoTlhusmivwo6xM8Jo/BCYeWXiifckhcxvqNCWuHGC2wXc6+4AZ HaFB02DA8bGfxd3szabUWWBcvdhQaAIHeO3ln/7mC0VcpNbyNIZzJMBKgk9wAHKv/gSZ1500QzY5 2dTN49lxGdsncyr1jGepCe0D2LKGQlwgUvRRepnleQ4TQKloCQ1n5wMikhRe1nPHzsCsZaFF1PqR V6HdkZEqx131JaHDIBnkOGAH+Gbewx1srh/R82xMgxGuyGEwj42DphKdOymS+8s7jZOZ6uHOZnTg Nkh12SLLi/6z2IwdIH7DQ0dI2y3WcI2wUNsgxX2T81nY6yKAApwEgQjREL1hFPODrgkFwV63V6H/ JMK+aoZs+uPYBQSIp6xo150sYsKswp5mfK6C86l10+bByhfiuJAJRGX41i+ZfSZ8UGUQtzULuWsv qCZmT4bPp+9ItnIK8+3pZ7d/H4p8q+KR13mqMRTeV+18TGxmVuk1CYZ3CfUo6g1QtkiDhhlK/Svf 9tf7jWUv6/JKAlu5hM3DnVZyU0vVc/dIf0uD5iAi2fwpkBhI5XhlwLm3By3Xhv/VxDG7pgUvVUAU OJ+q4AWs1ZxaAbleo5/4a+7WMGUHBM71LNKWhNPoeDEDdRwar010FwxSkyt77cVM/5BJefhoRyvd CTxqI4doMrRzZIpSoBA2mbXXDGQEGtsXQ5uv1K7sk6oiIRbVygLQBsi1OFirX9r5lVoy34OC+XpI c4FWnFdm2E992Doxd2jwIDs1Fx3sxbj8tsNLJHcE1XnjToQOk08L13EI0jPYBI42ClxatJpwcGMM TdsTaV4JO+StNd0ibIFrQMx7ARL2rwNbyNjjwMdiGnI+JNWpFpJ6IHSSTcVFutREM8tYfyT+eun2 BgSRcaKXvGQgnO839tNFLmAXafGasS4tkNfi9/L4Uycxs/s1McLcXzE8SA6LUhxf4gnjfVzjRcvX hgm2NExABOB8dBYwzRacPuC6RZsOfYi4gbUqcg0L0IIcvcY/+R4r2BjtQlDHLaUGrMtVuBUT9swB 7Iw5tOsUl1fUoA+9KMJlma5ZGofGXaa62gDWToI7/UBNKRzeWiWwsmbL1cFISyuqdK1IHp4Rilel xPf0RX+aj+UWopO370MTyaMbPVs8vkVE2WUYdZqEEdf0tNA28aYW2UKncufjaZBWp5kWoYZSSnl4 IrXi7IgyT57F/ITsmjF0fKcdFXLX/9/9wjuO44XzLXd54eumNj8IIsDbHzvtuir5UQy4HGkgHLlT twAMHTPuNB6faYDNNYKwUJx5q1FA6TMK43rZhm8zWDC0qGpwItdK8Rly9oFs6tpwnYv31a1oXyId D5jsvb4qbE0axiBnhd9XUdmNnvv3NsiqrDbFnLTL7VXVDlbL8srfnRytVe7XktVGTng72bzbVbUq U6mG0Qi23R8hziQJlTr6S8JuTT4PQcmiQ6/MGZAlXmt/IzszYT21IKkLHUnk14eocNpVK9h5W7rr XdyuoolYTFeIsfMVplVe9RrB2NAW00QKNxCtL86kCDfTd0jxO8/RobREoy7e4TNO7otTyO1IwNic uPQhloZ6jEWnGAmDxTxsXi5Rt/PKH6z0XC8zaF5/YJeeHGi01UE6o39GDDqbco44p8CI1iyT1Hvf OJ9mL1ugEUJx1h+TiEUGrnWGkWTJ4Pn79/Iz0a10ccypae2yyHec4hE2lbfHXCMpq2ULsBgUv0oC Go0Sp5Z1ttoIV9kjPNRCIlwTgwwsbR3Gx9Zx/OBCDbCC/owQ11lS6UM87noztB0w+YRc9qzyslXV Yp82zWqUOCcMndouJa/dj5XTAPIwB4BOuuR2C/ckCgcqueuBXD2RzhuNtILdQFlDikxTtnJXaH7B Uzu9snYR0tcEKbmPsZzLtHRMJXU9hlw8dQcC/lJuiUEK5XTqfDGR+jYy48yOV9hkSybGROpUjOuq llQR1gNql7yU6F5oboVO1LvMAbMvlBWQEo9kMtX3tYHhxpNNZ+6uU8NDnRRaNuloVwGmsmbnQJkG lB3aHTmNsX6qern0b7A+gnY3ihlKrzPriOe4WyS4N+gUqtDnekCQN9/wEDp6IIHU01Gb+Bt6Qkfs M/TlDTRZ/bqdibZRkypu+nM7MuX273Xg94R0gs8/b3Xo/t39TcP9/7zVof3IP291aIH61s7g/7zV 4bpv7IebQF17ZUL0uRFU/M8I581HbwJ101z850ZQ8p+N/+NudZAF0Hq6W3yo6Rxd7HDzrC4fukg2 g/mWWX0zQ+3+/EPY7Npvrwd12xccfPVaR/ONG+E13xV4DY71nRdE3PZ617zZ/e137Gozzv4doEjB 9+kua59Lkls8Af/Yayaaka3vALXxdNOltax/LolA3YSLGz7/G3CLofVd1h6A/MPvAXVUsPiB5/Eh AuxsdP0+UN2f7wD1Sl3v7offAWrNsfgaOQquuZKjZjdDxvkjURZIGEblT6fFe2uG5PZd3HKxM3gS 1jb75oX4kV0zVbIF83zbYtzORybeSp+5hHrPF3gNjR7lc6CdTwysBEnXBHO4uMyhMMKsCxlzeMVX 8mpPYm4Getpw32GkEIbvOldpsC9oXcl9TdmXzkk07chbCMlH4UL1LfbZq3+inQceAlLPBuYhfv1c 2wjiF3Eihtl5Pt89nkscVRenfCcpWgcs1zIwhIRZxF2VCJL2wNK5eIRFtZWNnQJgl2rTXKL1QOPb 3LPyLIWzyHU2DyG5sTFZK1A0QsKWSLxoJn4ycUVKnzdMLoK0CO/KdsXwkoHrvrdCOf9eN/XWjTeS dMJu4UrXHkJwaLBYvpJFkGzSXSfY48ihB/QNVLGOEjqpJaaKJll0ICs+AcGlB9L1zkgh2lc4rX06 mlJGJ3ok5rYGE9EeNCsBwrmYf75CzWSZ9YM+c8xdOsm+QfI+MGHNpKd5lU5xFXIqPMo34owwG3St wzSbVCI9gixFh+MX2qE4xqwRtaRroEOgtHAIKm2tpWXG/kzkC06s+DGieu1264PR7mqg3Peikoss NE7iMqwaRCPdoqRqZ0WU6LLhXAdFIqz5aoG/cfj+c07s9Tr0BKWyHlO2x8H1JnrxQLAqL6Os6NlC D8g1SKKtWnJbJa6ibuMnOIPqenYtAa98p0b2l2sPnrrwzQgiCrxIJYgmIVRmSCi9AUMCMpEJMTDB GHUVkE+bz7A8cclJOBzYam5GHvLgRttChFtKkoya1lZ3dmy3nKtcMpnD94MAk0s2b3AGd7gt8UxE cRO32Rf+VkrQK3C9YNo9pnvN+JBYJU5s+D5x/vDs5v7akSRvIIsvdbKInDCLiF6MWBRAtbYHcDxF DjiGgJjvyDVWYfOJU65NQ0W+J9qYYRGVhnBAsNqNNPssuTG2nRLkNJTqPfHceDRaUTvgp0zYJVAI Vx8iDZLbLcBRe4sRje27uL3C/6a9TEVQSlasdYCog7YY+BlZf+hTnLjOEg31qlxBIMWdMuy2cs26 dhuFnXDNNOPzzYod1hAWz2duWkGztKXryS6ZMh6KNarQqJvvE8ONVqy3H8uuT82+DR6Kdo13ZeZA 3UuWEIXJhMI0QN/FMWAtlxCNYNeSRGxiRYuRvQLFOSEhs8lyRpdGJZt6E/eq1d/wVtSAYSCWxtPQ 0uBOA6yBXTS6FQUNPC6zOHXNhB5zQssAwcm8f8/1+oq1PZuCtodxNdipZLP6fjiSBYDJNLsw+dm4 IaRxpHBojwPGu8vUathJnYhJNKmuy0xIubkbWrqxWoLZyR0J1lAqmoEk4nT3nvENBazzkR+Th1+k piItfVbILC3PM9aqZpr3jEdD+NbjpHL199fOQPXEJaSuayqIuci1fUoDAb6j/gbGFTjZSXOwJP82 kQ4xrqFVMXONUNalUjYz+5AEtrDCBsvDjK+YIhlBu27GyMtV2F0nc3fQcR5kpJCgQWCJnVYMScdi 61Cserhsr7GW3ElHiX4TXMni6RGnv1zw3TNOvWOrU/Ny9VJFkXCEM9Cbi6yH1MW4tbnLtTjar6ku rzgF81za1QUFP5ZZC9bgan2MhoKUXRNg6zqBKcm3tpuTg8OuVjr0/Xsu956pSEoKoUgKQwqGTIoZ zCRkp+RBoZZkxMm6dar8lrBtiJHFBXLhuJkn5qctWVZQdmiGabUq2QAiquLW+5LoQiKS0e3rKzj9 0gr0uv7cjvi9/asb7t97TDM5ztiTQ+tzXJpW7Dn9yPEmptagPg1HlC0bA+A64nU1tlNKUJHTzS5N WgsVqxHUOMWeV3L3R75ghJVe+OvWJoKYK0EbM8m+muLMrLThoPJNh9Q5FOWGRjq9yzOur+885RKA JIuShpPmsMUnrhphSrNhus1ivuuMe0F2mP2aq11lPnPIbkBrWxaylFZnb5eEyzQeiQxRL2l8tpMF WLxMNsdP28k/8Zb7smqfyipoCQs1NX3yUttTcwol9yiz61kI1/46IOIdiwla2mriHBfwmcxXvbu2 DGzZsC4BETFK3AqhnWs4D8/fjnHJmb98N2Agx41zZUEPbPx63S2HfKKRTwmUcuFBtwgIh3FaBOc0 M1MqhNktPRekH88L1BjxaVzSlmuNplaztCTKQEvSoMhU4VXA8eJyd33jdevq8ZbnzdoEOHFrcarL /bp8sNqDnCMhWVh4OxPbUe+1t0eK21AujtNbHFuIDGsxu6BoNaFzdzAkbgskCkMapXzOgV6+3FcP oXiHF9P2kJwBF/aEIAHGDon2uedU2ISVEPwa41PgOLe0sXSfPyx5jq+Nk8kDjJpmYzU+j52C207R FPKXPVmyFi9evcKqePdggx23foaG3Dn9zs0CEcryl1C6TeIrZa9pMqL2l+e+0nsmCRuINiotcp9t fWqXJb80qWTRW/RV4m1rhioRbNy0xEipe+gnr/PzC7zljp1UyPlYRRQRiC4Ulm9g5RlVAGCgDTgz 7hosDJJDORv11TLr2TR6DDX/NXO+GMd0dw/fRG5kVqytWaq1H8PrYbKyoKu77Xc/OaGhMRBfLZr4 rqaueCie+SDBlWJ65Q1GOhqO+yPCVh+Abi+rf/v2L1cAfTV2mh1ExlVJ45+RqTf55PR0V0DRPDNO W2WCN0228wiKEctlOIRQk2HNoE2o4ho49EizeXuexgwk6nG3vu6FmaOw0YCM8ZNekttRLKojHXE7 qg2trdvsJa7mprqmsH5Dis83jYXTE05qR8jxaUJiIbQ8BgtiS+YtYNawUJliDdyyuAedMQDrvsWM gLEqreHktf7E6oYCNcIpYUF7nHYHubjrwmkxvRIlVMp06zZtqSHT5rPApce3Ypg2JDneH//09uRv J2/fJ1Z/DG00vLOwYQRjBlbfJo29DvdPXr/b+9vB3v7RycHJLwyM2ZD5QDAnFw/EKHzJKXf91rKh 9XX9XcCNTTiO6IW4K8lXQceI12LhvLJq4Qilp0h7rzXgw0PS62QXo94dvU2IvaF3lByMdckLDZpg Uuj8fL21/nof3u8fjw/eHfVsO/1e9rrQxvmHPUHPx+Tr7fSku0sYTXnK4rTr8/XWevQ5nO7+Jpxu 3ypOXbrJ42v7/BGnlJOZ7NJvnBOtjkkRu8QW4iYfQZm3lHDkZVXbKeEL4dHCWNiptZrHe2Ehuj3l WwrfJA06TEJmrXnYm7P2BzfuJ6Os9xScj/3RWnsPA+9z1ur+xAea2SdA8fGtstof4QPtwtqojeeJ cIgz7v2ZrtHpfKGNOOh954RODq+dvJKX3MowHKbHdWDRRgCKldiLbNsmUXjWbhOjTUPDnYql7bpd 6UW7an0BCFAT6yzLk1mhIXz1BpgUUTJTqa0HZnOgRBjUGvGm5HxZc47WeRpw9FsQaga8fhVr9+/d LNe8VNttSrXESTVWo0SukZKlpMtxORMla8WdBZJUiH6HvPPSDiL0O+Sdc3gK7FQafC8Mr7ovG7kV NoZl66/+be/IXKsODncHVSWIvWPWrQRBcY6BZptBYwyeekjZkvh0e3r47V/NEVRvCzKbepU/Q3Lk er4pQ8RJ2OkNXqI06y7wcFpk2InkTPm41hc6GzJwt+lbSnXc38da/tGbUs/+2a73swtTnHdMGvT7 bh3YWj+BStwq6GESkICzd19gnP/vPx1EvT4EAv4mvwFvqdzp2TRFwpe9nAy/7SBmjDlcX33nF1Wz TyRcdCHpd62mFsXCWhnIFsavxap+o1+iZ+RCmY1enDvqzgvd1ygSra2yn5tz8onWHBDjGq1sCu6u gMXjWhItyvPiOQ1brtj28SE4C8/0Wb6YqrBs2CCscDqhxCFmBdiT9ml2mbk0hVpcJdYdRfqh0gTm 7Lrmylzzl07LYinju2s/cT22nB+kq9glGerlm0jHai0CZeU5nellVAynzM8vzN4DOoZoA17DWmss qIpWFLZTYC+yT0GZXbFtE0T7sC+6cvxVRa34KVZ2peUyGlJl+/17scfGNeqQMDdtPJiHZu/McHny VLJBA24qbaDo2OV8312Za4tj/QGxU22goH6vmff5uOzHPxlzITjIECKSzXyFaxBKENAGUduUaGGv z7hFtNFf5SFeF7i2FojZuvQA3Niyay3EZCmOPJtUqck1IOueEac6Ci7T3NhsUJrN6NgQHPDfSSQz cjZFF+XvrD8Pdydrk57McuejVVV2H5/tjuNThS9kVfT8dU67nmUCgNlMWGJ3Hgo9BtEhsDPA9ONP gaifcg4Ecbi77yo5W5WNcyDzEQaWny+I5xFFcy5QrklqzkMzFa0Z+OMbZ1ymmd827bvy2GGvY4+3 1+9xgMU1+1VwYI/2t5esuJ/ODj9UabAZidThbMB15nLvWJbETZWkoRKPkNfO64Kms5dOtIrjejtu a4q5hI1BvMfnVtWTu7icAsdY2jabstftXL+UaF7kBDoxN0jUI4abIPacXhlZAUtLPw+jbj00kt4C N6X/bvf+g/7/SDn5aSY30wv/OVrnXw9yR1S6isYatZdBBgSU5FNrvs05TPA9Kzfjv4b+YOaDoQs6 uCJTcKYT69Kdo+SQHIQQindDfURGbgdUkWZ5ux03sdazEP0mHXHioOllEfDhQ+u6bM19fMdl7aAp l09k2i+Zde6OVOwENTisdQeRVc7sCjTMdq/LdsjG931SRtkKvwVuY7AfSf6acRKrNWRhmbIuiN5L tPcEd/KtVCKzPbkoasvSaAW9glgwmIsk1ZxKKJjs1CgWHLWh583UVqshenE1QbA5aaVqsG9ZzoaP qbgSVOBEgdaU5GT9ia87YP7omhN6IwK5CCdvEa1IZ+dFSQxwnmwcv9rd/mHrqdMvdwbozqGSHo2F CzJAa9dOf+s/cAQXiQYIpfCCT3GEH+kBYwRnR3GLo8FQsYiPc7Igq6B8xnNxJ/C39HdNj8YQi9Vs pk3jk40HD6T5uCYQMI7+Nn497G+hkXzcZYnZEK1Xv1S+8AEr3n789KP20YhOWYNBOzyxVULzPuHr m/ioQZv31x4Q1wDqNwhjfcYYRn443iWZh52SPumbjMTR4ZtHyb/icfwTi/47/VNwQxKLRyK+T4/h e1rVBv6+8ff+1mbvwQHSelhZqpU69Pw+YCz+ffNPvCY5uP7tRe8BP6xiln5zr1lkw7233fGeqmC+ 0eIDc0Z+9e9DVX3w9QEhEBF/vgcVVrqERDftICyrbDUttBWn3YTLA37qzVJi6j3Z683IW86VBqM+ 7fSWPffVntsopL9QndcrtCQiTcR1leqxWSHaPAjEe16mK04Elwb2SNP1eqG00N5EWrTlD8hzwipc X0A2sOYYQK6+sCQv62i14cs7HKGwOwYYvNUr2Ldv/16BJDgaof7iu+AlG0wbwaUcWNaLxCsPPort Ntr5vPhoO1R9irOGxSoFgwxpMRFi7JI+RP4NggxvFkne8fa9lX0FaMkM0bPGQ7xB6/a3TIDJmCmr 13wtAJW8ePGvydFPb9/qt9jWnCb7CHSxEb73cPtR0k/IbJwWbQj616+JkrafBH0ns6C/5PS/rqmQ ZrsqF8kWKazhz8qyQdTyNZZ5w8m8ntCvJXPs1TdQOmk2jvxcyED8G0ou7FbK5OrDU+jfnPIilAVl 71L1PlMH1MDEZDgRR+1S0mtKLwAkv2a4+8YXuLAqCErS2JzCMyvAJUGvheb9soBbSOkjsxgRse/B YcygDoc7cOljIezg2jtvRRMXwwV60BNROjJIuMdbtCJ6VdfEDqpioRZe3Nfz/r0hyU9reCmT0gC7 vZKGL9jZjYM8Kxh9zvGBre109oQZJ0hGCc1XUXXOWC3Q/iFv34t6fRXNnr7+mzrL1Z3smMZ6Pzhp EXivoW0H/F4AtLJppG9pughRr9qP0xukuhM7cb5QA0DsHX9JAFGySyDXUhas0KVZ9l2aZZAf2nPL bU47D2wNoos8Y2vYjaYakIRonBNQgemrqr4uFOf8qzbVDm1qdTHKUeCZkwqu/v251HnYptHMP9Av H0N35M4A9gGATldILGSVkw+rijfwqUdJ+7PV8d12x3c7BmKLft5JHidPkqfJD8mz5Plv+Y6B/LH/ nX8YytfDr8dxQJUzh9wn+k0Zcvj5eptzSa79vMc9PoPB4LZGZDiHtqvYlD4ibX2SDVM0trtK2Jcu P25JW4Lwh9tSdm6/Sb+j1WObPvEu6MpkXgax2mTj0aY+iE33mBgmW4/7pxw1zWbTnghas7vI6qTz iXA20tvQ+hDRSxYf70cMyFX9qQvlRYhhm0mI2OZ32x3f7ch3yteTjaELMtLI8oMtRsjULwe8QO/x 0pjEe7kSihNQIO28UZgoncVvyxVS+nJx+ndiF8oQ/JReiKjJqwaTmZYkEfsXZF1nZT9Ll/169rn/ 6NGg/lInH8rsrMGAttcxoMREWYCFQJJIcplw2AAzlr8AkK9ciY0Tfb5rg7+YSWbuzfcX/1cwvpjt /a9kfOM6rVfV7xirzdI6uZb9uR3udRdtmhPmXN/Mu+ggxPwLvEIJ/+ErS6nrZA3b+lfBeXzoK9kH 5RIVOxqVUwiPqFoMbssPHPKyYA6aGXxg2b0R48BKTFeqg/raNWoe69iq5JlmyLcn5ss0KHVcU1gh Bz50ciso0lJxFjZQyHEwGmcToo7Jpmh3MRuFeugrR4K0nCTsFy5v7npfqbptNMM5z2IVLy91FDBk 7MMhB9N4Ts5tvKZWxNy1ljDgL+J4lLQ/38m7fuO/v+0M3/Sng3cZ/fsJ/4N5l9I0z4GHfq8ps/Fc 4G5pT+Y7svludxVGoe5ohnO9aZY3/X7N59tWcQOQmxTo5tq6P3e+ipv+uFUoi/g/ci+aa+v+3Pkq bvpzwyqEKze1pubnf4NV3Jaic/u9w79JW0u+UxfqyqgmEsySg+ERQp/aUIidTmaG2NQ8X/fw3i0y 0YJc7a4oKeiZQipI4HdiiY3USUh3Z1xZXptAuxkqxL0mw5naEYyhoBP30WG8rPEzfxvpLmEKNbu+ 6qrnNK8OfUZgeK3G7KW2VoRruul9BNACeAYhqrFJG0HnoH5GPYkWmaxS35aHi8gwRYSivWOqW34F uq7TXqFV+bRf9a9H1WFNWKwErxnHjzBUx7pCTP0+OmW0e5LicQySrnoGklMTLu1mREBwhXFhaUv8 i92bKg5ijrwvXBu6g+ZTRqLu3q9wRD1mj5QuxRgQr7cBLOZ5zSs8u2aF7IE1WGZ0dAq537dhTVhu w26NAe7cRc/LFhKuI6Y69MR0Iy/MJzRAzoyKaKQI09bERNF0jjxKJguObtpxOb1jlU4a+hWcXFgm YLRVa+2x7HxgJZi4KMLAoAxTQMsN8HriD6Jaw+SoqNUO5f/bW2WWshPYWZK2iJUx469qNskmJfIs 7eRxkh3DcHcMuvrfdsJL04iTo1ip696Qh3dvjLB01/TiXqD/rpcTW5Au56419UTvhc6+pJO6kRch 21upk0+uPxeb3LIAq3o11dsEgU6bhRnkapLHuctRJOPaRaUzl5TTXJ/SKMeguHwCW7t7/Mvo5N3f Xh4c7R0c/ShSGmvz43J4/pwbDvqIBOjjUdL+/NO0/b4/MhcPNrRo/VjB38er05YufEdz+V0fncs1 T0hi6PWfW53LTeu+6U9jLqYaN8aihTnBGV10vbHYTL5rLXeyiuYnKB6+5nM3GPWfrqxPMjo6nrz7 ufgPCkOvfeDO59KJl0W/szD5DufSOQ3NqhRqb0zoDufymz83cqYopXHd51bnctO6b/pzezr37bf3 TO7e5dClyziPw27kcWi5BQzG+8Dkb7RYcpWpYgNbFskB398uN+zVgfrvzK115pV+w0W29tuOt72s 9vU4Da9bl8qTypV4LDO2cl1NkYBpB0es7DhMy9VITraYmlMhtUINA+T0TV9TzVqmu7HcPeBLI20r g7JBA9cMU2tHRx7eNRc1D0zazFNymqfRE7OfxKX7iHT4D/BBG/DGgeEA4vCXpkBpskEr8hUiRNqp dtVJhEWjg2unKcS16VBjE2zMI2KmrVl5KwLDoKxToW09DUz4vHLpct5gPwz7k8TOF/ykcHx9u9CH SyR2BfqZdN0IrBjLppPkNAWER18TJM7P7G9tP2tW5XJ5qyROOw9XuVqID6cuDA7ehMtscHus7m5a KT7u4jo8EL7mJjKVJsIBB1yOAD1ej/nODlMajNmBswk7OJHQc6VVVmbVSWphVA9y/54lfEqdR5BF 2Mwz6+CjyRP9qUviP9Xf0L0useuDxWsSJs54frAZpqngMU5VQVJcjzM8P8pccCvJkWzh58w3lmQs 0sPjj34HXDUC/4ZEwcO9Jx/D355J4fmHg/HwzeHIXuXfHj96pr+92W/CfPxI3O8fMK/3j+znNynN 6qKXvB/QjNNZ9ikte8mQ/vFzMS3zyUXvkP7+4DCHh6M4q/9QSZGBMRH3MQfzo2Sj4VYhzPxMG4Yq lr+OkvFoa/NBL3k3qQtQRwsOUd52ssFdZXNODj8viW9uCh4l29B9XnNGUC85ac79/ynKRS/5cZYh RZxJl6tPSnMvNcY0zr8vxAh/TeMuzJHRK0L6NP8WCFvP9dOnfdh6+nRLlzDO58sKwf2fgWK4KkZo sNiviz7/JRh1NMKoyfhkL3my1R6d4CYA3Ev+siLpvfX8+eOBG/D5zjMd8HUq+DqSep5d7rL2K6OI hEf/BLWMIzrMNP1pMr6q6mxOgxKM1oAA2iNewWM9DcZ6/rhzcTT/ZPcCw+POGte5r4Hm1jAeAbuv Ge+yUhqF9nl1jsJMN778uR1Gevst1gQ/21tbzxU/L8t0usBmjIEfBFuA9SrMJaYXOPX9QPUIx9X8 51juAeAmIW9xg3alOMJIPZ0DoeiHwUc3BzAQncNstfjUS97SDN4Xs9lpmU0uaqIh27G15+Gajdr3 +4SRgjk8c2Sy/eypsbRjCI6rHtEivbM6zZC2jRMckc/POOf4hXDVGvrBcTZHP9HGid1DC+ODRfIT qd6sKeA69Q3xDXcdYJ4wzQtHaIHrqR49cvPdIXLX+Y5oH2a95CXNSsiLUDXO9Lqlt9snIxoQfz0Y VdlE8YDX2wMekeIxV5axNTBuf+KlwSvenBGN8HJGZ6VPWGCMMMGAB59YT2F6pwV+DQNDVRgqxhY0 e5ZVjlm1IDjm1UteZaflClU5YG8y173Xu6ODJS2SZ9uFFjzx+TGYLzcYcU5lRo1OvjXoYTHN1s8x nJMkheZZfdZvQckxsf70YrLsb+0gTdTvqqKahbN7fojbUyrG7utwCSNX1wF8B+x4jRT45mn/vaiy MwzYnvtyuSSlSNNcK/7voyeyhnG2rB3N6D6MDnYDiTi+yFDG20t+oem/KdPLya9Xn2RRw9PiNJUt ekAv0Re0oKxPmkJrCrtlxjEJOkEjpMdCsCufu46I2tuwbsNof8q0v8wn/UdPG0vrVAhkqQej8fHw eP/fZL1vshm6auA0HJMOMy+Ksr7I9XgEfFFYKhNdB/sU1iEJvuNJtkjLvKh+3yFprQ/h0Xldtbfv mjX+uH+yu398Ygya1kj410MPmX1YVJ+KyxxSm3dSDZ1d3wMJj7UGgHw5zuoyxxVLgpA3+9+zzFOd mS71PKvRUEKTsuW0da1Seep4f/en44M9XeVf7DDo5p2oFcF89WBvo9wkPUUb6wdzbsH/9kOHQ9V6 XfohT/vEIngNbaZ3O8rFXfSN+jAiW8yLjncXOOq/RKwMxhrbuvTY9xzggmD3l+mC/q8Ag7It/xbq /uvwp5PXjl2NyArKS5roMWRclq6Illcm36B6oOj+BsVDs+/FFnr4Lv00k8pnXV1/LU10Uw/RtUyj n5PE/QLPSJ8mHy+wF1Dywf7+/rNH27om/AuJ0ItparrcW/Slk6NL56/A7Q/0ezIsszQ5kuszUB7Q mMy7z9BYyA7Gi8Pg9ihi20fjg4c60DShsXtQruLpbP31461Oh+PncmuBPmQ8c1cuBOkl4YwGW3/t Q9S2kdyQwjZdsYjCHtH+9rKkn5yQljORO9m0tq+TyYVOLnc/pnUqrticqQiaQ0ELwDxESQqU6AUn eG2swfEkki0jvuCgAWdr60VCSmtJ0yYUvR0ecXLDat5AWrJhzTraCL+4qlBnmLzlmzQ3Rq9/2XQz EBR4lA9ar/MebPWh+PdE/Rc2gTuLHJbbnghYcE+2zDXwpriYiTFwlK3m6UKUdObOb7KSzkFRGTXc pH06/fv9E2fE0UChRkOz3PEGAhwgAmkvz0o06DgRmxVG63Amhj1mgnYOTi8zj/fW4NE6DZ8A97zq HVslj5/ZoMSMpjP0oThsKE4YsnECJH3mjKa5bkyCS3hMFyxMaMjnwZCPzBkwrD/lC5aB4IZvMlxm OPbWRX0VsQFzWazXQANdTSZBx3Htwh0D43ExbDydBwej5pa+JhRhyZ3uAUC8ZrSnN4+2v5iky4qv 9iMZ6HAwSq9mRdo+Lxv7Y2920gDXDP6DWXL5Eqx8z7bVYe5g5MfbK+YoQo5vFuQPP74sM39tqcgg P4kfuiZxW0rEXXR3ci5EeeAwXZ1fXODcA0fjyQUpeOw+OpR/LjK4g+WfOJonqxIOjTbP5y017Hpy Di6dwOtQUQ/5Hi1w1jZHdMaX4DnY7WfX7La5W16nJUhM1rKbliXM1fbeYxL7KjraREY6czDs8/XD btl5elcy43xtA4mCwsPsRfdDxMcVkBqDAygPOGgOtmO+CfV6YoHF6amyD+e5TdgH93ro3DokQ9Ye 350d76KNh3u684ND6fzX7IJ4VaRmxh7MruuWGoNtjEYnfjcJvHdiBozSe01PistFNYPPCK6h9ylu jM1T8RqFHqRROpsJNhgvrXF/VLKl52qQMfN3Ebcnl0XHzNm9s47Hs/PVuySDmf+wZewuECTjfF7I wRJHG7w5JMm+0ctmyCLQ0TaFoz553qKK62mh58Tn9jqyIKBekKkOrP48W2Poz3ugmZiQlMSNwMlt 5vRCy9G2t7+7Pzo5eHfEoMbE+mkHU89fkn9b5XXNPlNmKYcpaXQldzXZyyYZtwUZPGjNmk4+Mfrd Yjbj839ESvUvJL5ZL3oiI785fjk8ORnuvuGRf15JROHBkFS9dNb/uShnpIQTPyadjIdz6o85y1uD Gpd70GP9+wwO9Z8WOQdJiPftSvCxJDaaZ0HM3H32MuTJypXGF3W9fPHwIVFGUV4NKgU3yKarh/+t /vvlw0/l6ZLmMbio5zNbztuDQzOzQh8CUHmYlTSzWvD64C1uoVKd2pUkyupak2re4WMBAiLLSZZB zjgYhNstRH3qDnPwp/H+0cFf2S8oymcvWS6RJLDT334q+qqaB2/2j18+/nl/KPuyV8wyOT1vi2no Exkv0zOgpJfsC5VXfK/dFGHXqm5bM277Hkc9yrpXstbbMCbpldFemjqImezllVb2W/zEUUL7/SuS 0RVZBbL8p4/6PzyKPPYilG9LYbj9flDwOhDr/myMWXUC5qW0kNUUnUkf7CJ0mwaHJwolsrRooYbE R7JOfnTv0pP6IhnuHrYgeSJD38Hdlg0ZnETdp14nnBGcBp3yXk1YlcEH43dkm+8mz+ir/s5ai7YF v9vCvdaibcHosHCvt2iBjg4pE2WB4znYuMnOi4T1ppxxhRzzw9Wsxt10agi14HBDVea7fMT2MruL dWN3fDh8uLu3aSaUVkl9gyHcNIE3OEgfu0RaMGAN78AYfrrZC+KVhwcnjkkiHPMp57ZHfFl3spst WCs4XNcyEt6kNuFaRGbdBXxt7UG5++Xl5aBKV3RO0os6H5zlD/9bWhWf0sXDUqf0kBj1nJn89dFn tzZ3LknVBiTEfel/eTbPJdx/dEXvnIsC96C10NYg+WLd+h4EJ8OmMIxuMGD/ws+40aO6kKKKdPEJ cWib2nvWwsrc5vcmzatUZ8iU/DpbcMfq1+lnNNTM2OSSTTvjhluWujZPue5kRSfoErkh/lYGZmiy 7ZLRxNSUzmQ2HGp9Sbw+JVmtqtrRwOb3F6LTLPk5nX0CVbxKy5wempZ0IHPajqN0MSGpns77JPNw 2Sxm/JciS8bprLgkZV/N9bzkAhS+IG/Ct1bXctDv36tW5+dZxWTN5DmU6ofOiTE4vijoC6k2NNqU vSsARGyxLtAwj4sdUJ+Cu2AFIu1ZUVZ/oHlPwc7E6QPnexKIGLTirLMZHVy9QxQcYntrays52icZ DT77OVusiLX/5dV2/8kz2pF8NqtOC1w28O44ef7D1vZjAN4/TPPZiwRO98FysPQj/BeoBbPBBBeK jy6KRfYi+eNW8uTRDmnRj5OnW9tb9++9Sr8Qvwm/f7b15LFJxNuSiXfRNuh9TmcRftay/vW34JKU n0dPb0LmZwY+mAH49WjcIXWqC42Pt3ceMTFUF5d0oDVr5v69PZIPbJTcv+ethGjeSC/0P/2cXqFz z5TeIL3r52Hy/NmjJ9vBVP9ryiMse8k0JQODnvt//8vcXm/O+vH2ExKZ28Spnz0KZ43vn+88TX7Y 2X4u6H2F3q+7xfJKepOj6Yj6C9Cd0r7e2N1MIrvelLUNbBT6eKIF3jGerVx27kBz06bFZMUJFThP 3JZv5hXkvLZOtJNimWu66tmqXBBj4/S++/e4s14lqqnlqH7OEpG6cieGHH2oJIXefEeMEVVYpLjm fOkQqr7k/Cb8RZXEF+PZLJYlLAWkFst8SJlcnc5kMixPp14l7QHU5QVuFGeOybV4coUIeqGUdn28 uLNQOEicdNpzzfK0RQq4aXpa8KXShnA0t1IOxMWfBDnldD3pC695pLiYhrtqVys6MzzhqhNNaLQq 14f3BJ7bE8JENju7f09vKAcK3AXh+YInfZmSEscjpBXuLCizeeFul2pOmaZUBm5wK/hrEY7tk/+l KM/TRf6raiJ8TRzZoBhT20VbVpl2fgZOp0jRoWUjQcTgVC4+g7jr5UUO1KTayngJVXe6Ki0P0mZf NfMOvZni4z38MsoS4ZQ4tearoAMCRfMsJZDBSalG59zMnjgL0fGMhNuK6wdl5dyuf39xDuoaaEsw WI8EYAlPFltSVULbztdeC4mk6NlDPy+zeqU6KXfm170rs8/Fp8xdLdGF9hzKg6ZPF2Ulc0e+aTXQ XOP4wF5kkdqsfSRBfGgomnOHG0fQ7HskS39MmvsDRLhyIciT1/uJyYVk/G73YP/kF1Iz9/CDlxjJ /tGPB0f7+8cHRz8mJ8Pxm+TVu+Pd/WTvYLz7dnhwOE6Gb98Sczw+Hh6dHOyPyUD96+h4fzwm3k5Q DkdvD/b3ejTQ7tufkJ+avPzpJDl6d5KQ+X5wsk+jvaNBfzEIv9DowxOeG9nQybtXNhsa9XAIz0ny ev94/+Ao+fmAxgUg+g2T22cwxwc/vj7B2PwvHZ7UMjc/gDzcP959Tf8cvjx4ixRvevrVwckRJv0K byaj4fHJwe5Pb4fHyein49G78T6cLrcrmO+iIxZ8bAdVtRK1590SN1TwP4kINcxA5wAdmxJ/+ydT kzzVuIgzr3BbjRCeXOFCR2jySWgKr/lWx5fZaVLlXFtMROj1/WmZ//rrLIMwJG0fit1DGv5hli5l SOfR2f+yzDV/ak/zALWydl6AnM9y1smr5F8kiB0oW5zqoPnSGsn+c08kQwaoGV9M5MNwOxzc3nHO h+/9czv0IJnL/z9QSwECFAsUAAAACABIBGMuWlSDEYZdAABXUgEAJAAAAAAAAAABACAAAAAAAAAA ZHJhZnQtcHV0aGVua3VsYW0tZWFwLWJpbmRpbmctMDIudHh0UEsFBgAAAAABAAEAUgAAAMhdAAAA AA== ------_=_NextPart_000_01C2E162.C472D5E0-- From jrv@umich.edu Mon Mar 3 11:38:31 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 03 Mar 2003 06:38:31 -0500 Subject: [eap] Conf Call this week (March 5) ? In-Reply-To: References: Message-ID: <1865502.1046673510@[10.0.1.2]> I am assuming we will have a call this week -- right? -- John From jari.arkko@piuha.net Mon Mar 3 12:58:00 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 03 Mar 2003 14:58:00 +0200 Subject: [eap] Conf Call this week (March 5) ? In-Reply-To: <1865502.1046673510@[10.0.1.2]> References: <1865502.1046673510@[10.0.1.2]> Message-ID: <3E635158.1040600@piuha.net> John Vollbrecht wrote: > I am assuming we will have a call this week -- right? I think we should! Jari From jukka.ylitalo@lmf.ericsson.se Mon Mar 3 18:55:22 2003 From: jukka.ylitalo@lmf.ericsson.se (jukka.ylitalo@lmf.ericsson.se) Date: Mon, 3 Mar 2003 20:55:22 +0200 (EET) Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt Message-ID: Hi, I have read the draft-puthenkulam-eap-binding-01.tx and I have a question. Currently, the outer protocol is used for (1) server authentication and (2) the session keys are derived on the basis of that protocol. Therefore, the protocol is also called network authentication protocol. On the other hand, the inner protocol is used to authenticate the client to the server. However, several inner protocols generate keying material (while some others do not). That keying material is currently not used to protect the network traffic. Why we wouldn't solve the case in the following way: (1) The outer protocol should be used only for server authentication and to offer privacy for the client during authentication. The keying material produced by the outer protocol would not be used anymore for session protection. (2) The session keys would be derived on the basis of the inner protocol. The outer protocol would still have two roles. It is used for server authentication and to guarantee privacy for the client during authentication. Unfortunately, all inner protocols do not generate keys. However, such protocols are quite insecure from the man-in-the-middle attacks point of view anyway. The main problem here is in attitudes. Can we use inner authentication protocol for session keying? All in all, I think we are then doing very much the same thing as with combound keys. In some cases the client may not even want to know the actual identity of the server. The client only requires privacy for authentication. In such cases opportunistic server authentication can take place without being worried about the session security. Any opinions? -- Jukka Jukka Ylitalo Tel: +358 9 299 2622 NomadicLab, Ericsson Research Fax: +358 9 299 3535 Oy L M Ericsson Ab Mobile: +358 400 615 821 FIN-02420 Jorvas, Finland E-mail: jukka.ylitalo@nomadiclab.com From sebastian.hans@sun.com Mon Mar 3 17:12:29 2003 From: sebastian.hans@sun.com (Sebastian Hans) Date: Mon, 03 Mar 2003 18:12:29 +0100 Subject: [eap] EAP support in smartcard version 01 References: <5.1.0.14.0.20030301233047.00b25b70@pop.libertysurf.fr> Message-ID: <3E638CFD.4040108@sun.com> I would suggest to use instead of the CLA byte A0, the CLA byte AX and use the possibilities of logical channels supported by cards comming into the market. Regards Sebastian Hans Pascal Urien wrote: > > Hi Every body, > > New version of the internet draft > > draft-urien-EAP-smartcard-01.txt - EAP support in smartcard > > has been dowloaded to the IETF web site. > > I hope to meet you again during the next IETF meetinf in SF > > Regards > > Pascal Urien > > > ------------------------------------------------------------------------ > > > > > Internet Draft P.Urien > Document: draft-urien-EAP-smartcard-01.txt A.J. Farrugia > M.Groot > G.Pujolle > Expires: August 2003 > > EAP-Support in smartcard > > > Status > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsolete by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Abstract > > This document will describe the interface to the EAP protocol in > smartcards, which could store multiple identities associated to > Network Access Identifiers. > > > > > > > > > > > > > > > > > > > > > > > Urien & All Informational - Expires August 2003 1 > > Integrating EAP in smartcards March 2003 > > Table of Contents > > Status.............................................................1 > Abstract...........................................................1 > Table of Contents..................................................2 > Overview...........................................................2 > Terms..............................................................3 > Identification label...............................................4 > Identification Label Coding Rules..................................4 > Add-Identity.......................................................5 > Delete-Identity....................................................5 > Get-Preferred-Identity.............................................5 > Get-Next-Identity..................................................5 > Get-Subscriber-Profile.............................................6 > Set-Identity.......................................................6 > EAP-Packets........................................................6 > Get-Pairwise-Master-Key (PMK)......................................6 > ISO 7816-4 APDUs...................................................7 > Add-Identity....................................................7 > Delete-Identity.................................................7 > Get-Preferred-Identity..........................................8 > Get-Next-Identity...............................................8 > Get-Subscriber-Profile..........................................8 > Set-Identity....................................................8 > EAP-Packets.....................................................8 > Get-Pairwise-Master-Key.........................................9 > State Machine Sequence............................................10 > Security Considerations...........................................10 > General Considerations.........................................10 > PEAP Consideration.............................................10 > Intellectual Property Right Notice................................11 > Annex 1 (Informative) - EAP/SIM packet detail.....................11 > Annex 2 (Informative) - EAP/MD5 packet details.................15 > Annex 3 (Informative) TLS support.................................17 > Fragment maximum size..........................................17 > EAP/TLS messages format........................................17 > Example of EAP/TLS Authentication..............................17 > Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile > information.......................................................18 > References........................................................18 > Author's Addresses................................................19 > > > Overview > > All technologies derived from 802.11 specifications such as 802.11a, > 802.11b, 802.11g need a strong security protocols for data privacy, > integrity and network access. Where the 802.1X [8] specification > describes the risks and the protocols for the protection of the > exchanged data during the network connection. The very same > > > Urien & All Informational - Expires August 2003 2 > > Integrating EAP in smartcards March 2003 > > specification remains compatible with other standard for the > authentication and the network access. > 802.1X specification requires the Extensible Authentication Protocol > (EAP) to be used as the framework for application dependent > authentication processes with a mutual authentication between the > supplicant and the authenticator. It is obvious that the role of the > supplicant in this specification has partly been implemented in the > smart card has an authentication processing mean. The flexibility of > EAP (RFC 2284) specification does not provide a Mandatory-to- > implement solution. The structure of the EAP frames allows the > applications to identify the EAP type of consequently to operate the > appropriate authentication. > > Terms > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119. > > Authentication Agent: A piece of software implemented in the > supplicant that processes the authentication sequence. > > AS > Authentication Server > > Authenticator: See the IEEE 802.1X specification for a definition of > this concept. > > EAP > Extensible Authentication Protocol. > > GSM > Global System for Mobile communications. > > IMSI > International Mobile Subscriber Identifier, used in GSM to > identify subscribers. > > NAI > Network Access Identifier > > PMK > Pairwise Master Key > > SIM > Subscriber Identity Mobile > > Supplicant: an IEEE 802.1X concept, which in the context of IEEE > 802.11 represents a STA (station) seeking to attach to an IEEE 802 > LAN via an IEEE 802.1X Port. See the IEEE 802.1X specification for a > complete definition > > Urien & All Informational - Expires August 2003 3 > > Integrating EAP in smartcards March 2003 > > Identification label > > 802.1X specification [5] requires an authentication between the > authenticator or the authentication server (AS) and the supplicant. > The authentication is embedded in the Extensible Authentication > Protocol (EAP) RFC2284 [1] specification. The authentication > consists of a challenge response between both parties without > consideration of the involved crypto-suite. Before starting the > mutual authentication, the AS needs the supplicant identity to > establish the session. The AS or the authenticator sends an EAP > Request Identity to the supplicant that returns its system identity. > A user may own several identities likely associated to the network > operators. > > The identification label is a pointer to a system identity stored in > smartcard; it may be of various types: > > 1. A network SSID as described in the 802.11 standard [4]. > 2. A user’s identification (userid) e.g. an ASCII string. A network > access identifier, NAI [6] may be used as userid. > 3. A pseudonym, e.g. a friendly name. > According to the network environment, the supplicant software needs > to set the appropriate identity and verifies if the smart card is > able to mirror the authenticator. > > If the smart card is not able to process the authentication related > to the identity then any setting process is rejected by the NAK > code. > > The subsequent sections give the description of the methods used by > a supplicant for processing an 802.1X authentication using the smart > card. > > Annex one provides a reference implementation example for a SIM > based authentication. Annex two provides a reference implementation > example for a MD5 based authentication. Annex three provides a > reference implementation for a TLS based authentication. > > Identification Label Coding Rules > > The Get-Next-Identity section didn’t define the coding rules of the > identification label. This section describes the structure and the > architecture of the userid. > > A userid consists of 2 fields separated by the Internet symbol "@". > The right hand side of the "@" symbol is the userid realms while the > left hand side is an application dependent and unique identification > number. EAP/SIM has defined the userid where the application > identification is "1IMSI". Other userid such as email address can be > used by the application. > > > Urien & All Informational - Expires August 2003 4 > > Integrating EAP in smartcards March 2003 > > Add-Identity > > This command and the Delete-Identity are part of the user’s identity > management protocols. The smart card is initially manufactured > without any identification label. The personalization or the > supplicant software adds in the smart card user’s identification > label that can be retrieved by other smart card command. > > If the smart card manages pseudonyms the command does not allows > setting the user pseudonyms. The smart card command only adds > permanent identification label in the list. > > Delete-Identity > > This command and the add-Identity are part of the user’s identity > management protocols. The smart card contains a list of one or > several identification labels that can be retrieved by the > supplication software. The command deletes one entry of the smart > card list. > > Get-Preferred-Identity > > The smart card contains at least one user’s identity related to the > user’s network subscription. The supplicant software gets from the > smart card the initial and preferred identification label. If the > user has more than one identities the supplicant software uses the > Get-Next-Identity to read all the available other user’s identities. > If the smart card manages pseudonyms and a pseudonym is available as > preferred identity, the Get-Preferred-Identity shall return the > pseudonym. > > Get-Next-Identity > > The smart card may contain one or more user’s identities according > to the user’s network subscriptions. The supplicant software should > prompt the user’s identity and a subsequent selection allows the > smart card to process the appropriate EAP authentication type. The > method Get-Next-Identity allows the supplicant software to read all > the available user’s identities. > > The Get-Next-Identity method may inform the supplicant software when > all user’s identities have been read. Otherwise the supplicant > software detects the identity list end when it gets again the first > identity. > > If the smart card contains a pseudonym management and the pseudonym > is (are) available the Get-Next-Identity returns the appropriate > pseudonym. If the pseudonym management is not supported, the smart > card returns the permanent Identity according to the previous > section. > > > Urien & All Informational - Expires August 2003 5 > > Integrating EAP in smartcards March 2003 > > Get-Subscriber-Profile > > The Authentication Agent or the authenticator may request the > subscriber profile information. The Get-Subscriber-Profile returns > all related information available in the smart card. This > specification does not provide the detail of the subscriber profile > information. The implementation of the information may be ruled but > ASN.1 BER coding specification [9] or by an XML dialect [10]. > > Set-Identity > > Once the Identity selection is processed, the supplicant software > needs to set the smart card EAP framework according to the selected > user’s identity. The Set-Identity sets or restarts the smart card > EAP framework state machine for further processing using the EAP- > Packets method. > > The supplicant software can set the EAP framework using the > pseudonym if available in the smart card. If the pseudonym is not > available the supplicant software uses the permanent identity to set > the EAP framework according to the previous section. > > EAP-Packets > > The EAP process is described in the RFC 2284 specification [1] and > involves several EAP requests and responses packets, > > 1. EAP request/response Identity; > 2. A suite of EAP request/response related to a particular > authentication scenario; and > 3. EAP success or failure. > > The Set-Identity restarts the smart card EAP framework state machine > for further processing using the EAP-Packets method. > > The smart card receives the RFC 2284 frames. It retrieves the > appropriate EAP authentication type in the frame and the identifier. > The smart card maintains the EAP state machine and returns an EAP > NAK packet if the state sequence is broken. Any EAP request is > silently ignored if the state machine was not started. > > The last step of the protocol retrieving the Pairwise Master Key > from the smart card can be accomplished only if the last EAP packet > received from the authentication is an EAP success packet. > > Get-Pairwise-Master-Key (PMK) > > At the end of a successful authentication the supplicant needs to > update the appropriate crypto suite using the master session key. > The Get-Pairwise-Master-Key returns to the supplicant software the > key to initialize radio security protocols like TKIP, WRAP or CCMP. > > Urien & All Informational - Expires August 2003 6 > > Integrating EAP in smartcards March 2003 > > For obvious security reasons the Get-Pairwise-Master-Key is > available only if the smart card has received an EAP success packet. > > ISO 7816-4 APDUs > > This section of the document provides an implementation of the > previous descriptions for an ISO 78176-4 compatible smart card. The > section does not preclude of the transport protocol used between the > smart card and the reader. Thus, this specification does not > mandate-to-implement any transport protocol such as T=0 or T=1, > which are not in the scope of this document. It should be noted that > all values are in hex representation. > > The restriction and security related descriptions are not present in > the document. Annexes of this document give implementation examples. > > Add-Identity > > This command adds an identification label as described in the > section: Identification Label Coding Rules. The smart card list is > managed by the smart card. The identification label is appended as > the last element of the list if the parameter Po is 0x00. If this > parameter has any value, it represents the identification label > position. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 81 | Po | 00 | XX | > +--------+-----+-----+----+----+----+----+ > > Delete-Identity > > This command deletes the identification label as described in the > section: Identification Label Coding Rules. The command parameter > gives the identification label to be deleted and the smart card > leave the space empty. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 82 | Po | 00 | 00 | > +--------+-----+-----+----+----+----+----+ > > > > > > > > > > Urien & All Informational - Expires August 2003 7 > > Integrating EAP in smartcards March 2003 > > Get-Preferred-Identity > > This command returns the user’s preferred identification label as > described in the section: Identification Label Coding Rules > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 02 | 00 | 00 | XX | > +--------+-----+-----+----+----+----+----+ > > Get-Next-Identity > > This command returns a user identification label as described in the > section: Identification Label Coding Rules. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 01 | 00 | 00 | XX | > +--------+-----+-----+----+----+----+----+ > > Get-Subscriber-Profile > > The command returns the related subscriber profile information > according to the application requirements and format. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 08 | 00 | 00 | YY | > +--------+-----+-----+----+----+----+----+ > > Set-Identity > > The command resets and initializes the state machine for processing > the EAP Packets. The first step after this command is an EAP request > identity packet. If a different EAP packet is sent to the smart card > the smart card return an EAP NAK response. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 16 | 80 | 00 | XX | 00 | > +--------+-----+-----+----+----+----+----+ > > EAP-Packets > > The command is the method for EAP packet management. The smart card > identifies the EAP packet type and processes the EAP authentication > according to current state machine. The state machine sequences have > > Urien & All Informational - Expires August 2003 8 > > Integrating EAP in smartcards March 2003 > > to be respected and the smart card enforces the EAP sequence > processing. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | XX | YY | > +--------+-----+-----+----+----+----+----+ > > The EAP request or response packet lengths are represented by the > unknown value XX and YY. The supplicant software should set these > elements in accordance with the EAP packet types. > > EAP Identity packets are independent of the authentication type and > can be the same for any type of authentications. This section of the > document provides the packet details. The rest of the EAP packet > being authentication protocol dependent, they are detailed in the > informative annex of this document. > > The description of the EAP/Request/identity is detailed according to > the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | > +-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/identity is detailed according > to the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | | > +-+-+-+-+-+-+-+-+ | > | | > | User Identity | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Get-Pairwise-Master-Key > > Once the state machine has received the EAP Success packet the > smartcard process is able to send the Master Key used by the 802.1X > specification for the crypto-suite. > > > Urien & All Informational - Expires August 2003 9 > > Integrating EAP in smartcards March 2003 > > As an illustration the EAP SIM authentication [2] specifies the > Pairwise Master Key usage according to the system cryptographic > suite. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | A6 | 00 | 00 | 00 | 20 | > +--------+-----+-----+----+----+----+----+ > > State Machine Sequence > > +----------------------+ +----------------------+ > | Get user’s identity |>>>| Set user’s identity |>>> > +----------------------+ +----------------------+ > > +----------------------+ +----------------------+ > | EAP request/response |>>>| EAP request/response |>>> > | Get identity | | | > +----------------------+ +----------------------+ > > +----------------------+ +----------------------+ > | EAP request/response |>>>| EAP Notification | > | | | Success | > +----------------------+ +----------------------+ > > Security Considerations > > General Considerations > > As a reference implementation the previous section provides the > details of the EAP authentication using the GSM SIM. This section of > the document highlights the new potential risks providers of > application may face by re-using deployed networks for other > purposes. From the document [7] fatal flaw does exist when have > physical access to the smart card. > > The nature of the Internet network does no longer require getting > physical access to the smart card. Worms, Trojan horses or viruses > can move to the computing platforms and performs the jobs. It is > important for a reference implementation to provide the relevant > level of protection for the new applications but not to create other > flaws. > > Other consideration have been introduced in [2] to protect the smart > card against crypto attack and recommends the authentication should > take place in a PROTECTED ENVIRONMENT. > > PEAP Consideration > > > > Urien & All Informational - Expires August 2003 10 > > Integrating EAP in smartcards March 2003 > > Protected Extensible Authentication Protocol (PEAP) [12] is a pre- > processing protocol that allows the privacy of data when processing > EAP [1] protocol. EAP protocol, as defined in [1], starts by an EAP > packet request/Identity. The EAP packet response Identity returns > the user’s identification label with no privacy being not part of > [1]. > > PEAP protocol allows both part of the EAP packet exchange creating a > session key that can be for privacy over the subsequent execution of > the EAP protocol. > > This implementation of EAP in the smart card shall allow performing > a PEAP tunnel for privacy. Once PEAP first phase has been > successfully preformed, the EAP protocol has defined shall be > performed according the EAP smart card requirements. > > Intellectual Property Right Notice > > To be specify according to the author and participant. > > Annex 1 (Informative) - EAP/SIM packet detail. > > The protocol implementation is out of the scope of this document but > as a reference implementation this section gives details using the > SIM as specified by [3]. Other protocol can be implemented using ISO > 7816-3 TPDU. This section of the document gives the APDU syntax and > coding which makes the specification protocol free. > > The first EAP packet is the EAP Request Identity. This initial > packet format complies with [1]. The smart card returns an EAP > response identity according to the IMSI length and the supported > version according to [2]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | 05 | YY | > +--------+-----+-----+----+----+----+----+ > > The description of the EAP/Request/identity is detailed according to > the IETF RFC 2284 [1]. This EAP packet doesn’t respect the EAP/SIM > format since it is only part of [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | > +-+-+-+-+-+-+-+-+ > > > Urien & All Informational - Expires August 2003 11 > > Integrating EAP in smartcards March 2003 > > The description of the EAP/Response/identity is detailed according > to the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | | > +-+-+-+-+-+-+-+-+ | > | | > | User Identity | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note the EAP/Response/Identity when returning the user’s identity > that includes the IMSI includes the real coded IMSI in the EAP > packet and not the IMSI coded for GSM network. Further information > can be retrieved in [3] for the IMSI coding in the SIM during the > SIM setting. > > The user Identity field can contains the user’s permanent pseudonym > or re-authentication identity. > The second EAP Packet is the EAP request SIM start as represented in > the IETF draft document [2]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | XX | YY | > +--------+-----+-----+----+----+----+----+ > > The description of the EAP/Request/SIM/Start is detailed according > to [2] incoming SIM data where further information can be retrieved. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 18 | Subtype = 10 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |AT_PERM..._REQ | Length = 1 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |AT_FULL..._RES | Length = 1 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |AT_ANY_ID_REQ | Length = 1 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |AT_VERSION_L...| Length | Actual Version List Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Supported version 1 | Supported version 2 | > > Urien & All Informational - Expires August 2003 12 > > Integrating EAP in smartcards March 2003 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Supported version 3 | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/SIM/Start is detailed according > to [2] outgoing SIM data where further information can be retrieved. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 18 | Subtype = 10 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |AT_NONCE_MT | Length = 5 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | NONCE_MT | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_SELECTED | Length = 1 | Select Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_IDENTITY | Length | Actual Identity Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | User Identity (Optional) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/SIM/Start is detailed according > to [2] outgoing SIM data where further information can be retrieved. > The third EAP Packet is the EAP request SIM Challenge as represented > in the IETF draft document [2]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | XX | 1C | > +--------+-----+-----+----+----+----+----+ > > The description of the EAP/Request/SIM/Challenge is detailed > according to [2] incoming SIM data where further information can be > retrieved. > > > > > > > > > Urien & All Informational - Expires August 2003 13 > > Integrating EAP in smartcards March 2003 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 18 | Subtype = 11 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_RAND | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | n*RAND | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_MAC | Length = 5 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | MAC | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_IV | Length = 5 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Initialization Vector (Optional) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_ENCR_DATA | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Encrypted Data (Optional) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/SIM/Challenge is detailed > according to [2] outgoing SIM data where further information can be > retrieved. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 18 | Subtype = 11 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_MAC | Length = 5 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | MAC | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Urien & All Informational - Expires August 2003 14 > > Integrating EAP in smartcards March 2003 > > > The last EAP Packet is the EAP success notification as represented > in the IETF RFC 2284 [2]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | 04 | 00 | > +--------+-----+-----+----+----+-- -+----+ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Success | Identifier | Length = 04 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Annex 2 (Informative) - EAP/MD5 packet details > > The first EAP packet is the EAP Request Identity. This initial > packet format complies with the RFC 2284. The smart card returns an > EAP response identity according to the NAI length. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | 05 | YY | > +--------+-----+-----+----+----+----+----+ > > The description of the EAP/Request/identity is detailed according to > the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | > +-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/identity is detailed according > to the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 01 | | > |-+-+-+-+-+-+-+-+ Identity Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Urien & All Informational - Expires August 2003 15 > > Integrating EAP in smartcards March 2003 > > > The second EAP Packet is the EAP/request/MD5/challenge as > represented in the IETF RFC 2284 [1]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | XX | 16 | > +--------+-----+-----+----+----+----+----+ > The description of the EAP/Request/MD5/challenge is detailed > according to the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 04 | | > |-+-+-+-+-+-+-+-+ MD5-Challenge.Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The description of the EAP/Response/MD5/challenge is detailed > according to the IETF RFC 2284 [1]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Response | Identifier | Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 04 | Type_Size=10 | | > |-+-+-+-+-+-+-+-+---------------+ MD5 Digest Value | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The third EAP Packet is the EAP success notification as represented > in the IETF RFC 2284 [1]. > > +--------+-----+-----+----+----+----+----+ > |Command |Class| INS | P1 | P2 | Lc | Le | > +--------+-----+-----+----+----+----+----+ > | | A0 | 80 | 00 | 00 | 04 | 00 | > +--------+-----+-----+----+----+-- -+----+ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Success | Identifier | Length = 04 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Urien & All Informational - Expires August 2003 16 > > Integrating EAP in smartcards March 2003 > > Further information can be retrieved from the IETF draft document > [2]. > > Annex 3 (Informative) TLS support > > Fragment maximum size. > > A single TLS record may be up to 16384 octets in length, but a TLS > message may span multiple TLS records, and a TLS certificate message > may in principle be as long as 16MB. The group of EAP-TLS messages > sent in a single round may thus be larger than the maximum RADIUS > packet size of 4096 octets, or the maximum 802 LAN frame size. > > Due to smartcard constraints, the maximum EAP message length of a no > fragmented packet is set to 240 bytes. For a fragmented EAP message, > the maximum length value is 240 bytes. > > When the smartcard receives an EAP-Request packet with the M bit > set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and > no data. This serves as a fragment ACK. > > EAP/TLS messages format. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | Identifier | Length <= 240 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 13 | Flag | TLS Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLS Message Length | TLS DATA | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Flags > 0 1 2 3 4 5 6 7 8 > +-+-+-+-+-+-+-+-+ > |L M S R R R R R| > +-+-+-+-+-+-+-+-+ > L = Length included. > M = More fragments > S = EAP-TLS start, set in an EAP-TLS Start message. > R = Reserved > > Example of EAP/TLS Authentication > > Smartcard Authentication Server > <- EAP-Request/ > Identity > > Urien & All Informational - Expires August 2003 17 > > Integrating EAP in smartcards March 2003 > > EAP-Response/ > Identity (MyID) -> > <- EAP-Request/ > EAP-Type=EAP-TLS > (TLS Start) > EAP-Response/ > EAP-Type=EAP-TLS > TLS client_hello)-> > <- EAP-Request/ > EAP-Type=EAP-TLS > (TLS server_hello, > TLS certificate, > TLS certificate_request, > TLS server_hello_done) > EAP-Response/ > EAP-Type=EAP-TLS > (TLS certificate, > TLS client_key_exchange, > TLS certificate_verify, > TLS change_cipher_spec, > TLS finished) -> > <- EAP-Request/ > EAP-Type=EAP-TLS > (TLS change_cipher_spec, > TLS finished) > EAP-Response/ > EAP-Type=EAP-TLS -> > <- EAP-Success > > Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile > information > > To be defined according to the EAP type. > > References > > [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol > (EAP)", RFC 2284, March 1998. (NORMATIVE) > > [2] EAP SIM Authentication draft version 8 (NORMATIVE) > > [3] GSM Technical Specification GSM 11.11. Digital cellular > telecommunications system (Phase 2+); Specification of the > Subscriber Identity Module - Mobile Equipment (SIM - ME) > > [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical > Layer (PHY) Specifications > > [5] Standards for Local and Metropolitan Area Networks: Standard for > Port based Network Access Control. > > > Urien & All Informational - Expires August 2003 18 > > Integrating EAP in smartcards March 2003 > > [6] "The Network Access Identifier" rfc 2486 > > [7] "Can you Clone a GSM Smart Card (SIM)? " From Charles Brookson > Chairman GSM Association Security Group > > [8] Part 11: Wireless Medium Access Control (MAC) and physical layer > (PHY) specifications: Specification for Enhanced Security > > [9] ASN.1 standard 2002 edition ISO/IEC 8825.1. > http://asn1.elibel.tm.fr/en/standards/index.htm > > [10] Extensible Markup Language (XML) 1.0 (Second Edition), W3C > Recommendation 6 October 2000 > > [11] B. Aboba, D. Simon, EAP TLS Authentication Protocol RFC 2716, > October 1999. > > [12] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar, > "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- > 05.txt, work-in-progress, September 2002. (INFORMATIVE) > > Author's Addresses > > Pascal Urien > ENST > 46 rue Barrault > 75013 Paris Phone: NA > France Email: Pascal.Urien@enst.fr > > Augustin J. Farrugia > Impasse des CAMEGIERS Phone: NA > Ceyreste, 13600 France Email: afarrugia@csi.com > > Max de Groot > Gemplus > Avenue du Pic de Bertagne > BP 100, 13881 Gemenos Phone: +33 442 365 036 > France Email: max.de-groot@gemplus.com > > Guy Pujolle > LIP6 - University Paris 6 > 8 rue Capitaine Scott Phone: NA > Paris 75015 France Email: Guy.Pujolle@lip6.fr > > > > > > > > > > Urien & All Informational - Expires August 2003 19 -- _____________________________________________________________________ Sebastian J. Hans Java Card Marketing email: sebastian.hans@sun.com Sun Microsystems Tel: +49-(0)30-74 70 96 701 Sebastian J. Hans Fax: +49-(0)30-74 70 96 99 Komturstrasse 18a mobile: +49-(0)174-300 75 34 12099 Berlin Germany _____________________________________________________________________ From aboba@internaut.com Mon Mar 3 17:17:40 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 3 Mar 2003 09:17:40 -0800 (PST) Subject: [eap] Preliminary EAP WG Agenda, IETF 56 Message-ID: Here is an (early) shot at an EAP WG agenda for IETF 56. Comments welcome. EAP WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba Jari Arkko Monday, March 17, 2003 1530 - 1730 Afternoon Session II Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status RFC 2284bis (25 minutes) RFC 2284 Issues, Henrik Levkowetz, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt Reconciliation of EAP State machine and RFC 2284bis, 15 minutes EAP State Machine Design Team (ESTEEM) (Bernard Aboba, Nick Petroni, John Vollbrecht, Jari Arkko, Bob Moskowitz, etc.) http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-01.txt Keying Framework (25 minutes) EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-06.txt EAP Key Derivation, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt Man-in-the-Middle Attacks (10 minutes) Compound Binding, Jose Puthekulam, 10 minutes http://www.ietf.org/internet-drafts/draft-puthekulam-eap-binding-02.txt EAP Methods (Part 1), 20 minutes EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-00.txt Tunneled MD5, Paul Funk, 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-md5-tunneled-00.txt EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/ ====================================================================== Thursday, March 20, 2003 1530-1730 Afternoon Sessions II EAP State Machine, Nick Petroni & John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/draft-payne-eap-sm-02.txt http://www.ietf.org/internet-drafts/draft-payne-eap-sm-02.ps EAP Methods (Part 2) EAP SIM, Henry Haverinen, 10 minutes http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-09.txt EAP AKA, Jari Arkko, 10 minutes http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-08.txt EAP over CDMA2000, P. Agashe, 10 minutes http://www.ietf.org/internet-drafts/draft-pagashe-eapcdma2000-00.txt EAP GPRS,A. Salkintzis, 10 minutes http://www.ietf.org/internet-drafts/draft-salki-pppext-eap-gprs-00.txt EAP Authorization, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-00.txt From jose.p.puthenkulam@intel.com Mon Mar 3 22:53:37 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Mon, 3 Mar 2003 14:53:37 -0800 Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt Message-ID: Hi Jukka, Some comments below >Why we wouldn't solve the case in the following way: > >(1) The outer protocol should be used only for server authentication > and to offer privacy for the client during authentication. The keying > material produced by the outer protocol would not be used anymore for > session protection. >(2) The session keys would be derived on the basis of the inner protocol. > This is a possible solution, but then cryptographic binding can provide stronger keys than session keys generated by some inner methods like EAP-SIM or EAP-MSCHAPv2. Also tunnel keys afford the only protection for non-key deriving methods. So don't see why tunnel keys that are typically strong need to be avoided. best regards, jose _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Pasi.Eronen@nokia.com Tue Mar 4 07:54:41 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 4 Mar 2003 09:54:41 +0200 Subject: [eap] Sending new requests before response? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA40@esebe023.ntc.nokia.com> Is EAP "lock-step" or not? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: March 4th, 2003 Reference: - Document: RFC2284bis and RFC 2869bis (and maybe state machine) Comment type: T Priority: 1 Section: various Rationale/Explanation of issue: I know this issue has been discussed before (e.g. James Carlson's email on January 6th [1]), but since it has come up in PANA again (and might cause extra complexity there), I would like to see the issue explictly clarified in 2284bis and/or 2869bis. [1] = http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html So, the question is: Is the Authenticator/EAP Server allowed to send a new Request (with different Identifier and contents) before it has received a Response to the previous outstanding Request? (that is,=20 is EAP "lock-step" protocol or not?) At least it seems that 2869bis does not support this kind of behavior (since the authentication server can send an Accept-Challenge only in response to an Access-Request). So, even if we allow "non-lock-step behavior" in 2284bis, perhaps it should be explicitly forbidden in 2869bis? (I don't think this is a problem, since 2869bis does not support all EAP features anyway, like role reversal). I don't have a strong opinion on this one: allowing such behavior might increase complexity, but as James said, there was no such restriction in RFC2284 (or at least so it seems).=20 If we get some kind of consensus on which option should be chosen (allow non-lock-step behavior in 2284bis but prohibit it in 2869bis, or prohibit it in both), I can try to propose some text. (Or, it might be that the specs already say this, but I can't find it :-) (BTW, there are some parts in 2284bis which assume lock-step behavior and need changing if non-lock-step is allowed. For example, Section 4.1: "In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation.") Best regards, Pasi From jari.arkko@piuha.net Tue Mar 4 07:57:51 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 04 Mar 2003 09:57:51 +0200 Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt In-Reply-To: References: Message-ID: <3E645C7F.2020205@piuha.net> Puthenkulam, Jose P wrote: >>Why we wouldn't solve the case in the following way: >> >>(1) The outer protocol should be used only for server authentication >> and to offer privacy for the client during authentication. The keying >> material produced by the outer protocol would not be used anymore for >> session protection. >>(2) The session keys would be derived on the basis of the inner protocol. >> > > This is a possible solution, but then cryptographic binding can provide > stronger keys than session keys generated by some inner methods like EAP-SIM > or EAP-MSCHAPv2. Also tunnel keys afford the only protection for non-key > deriving methods. So don't see why tunnel keys that are typically > strong need to be avoided. This is an interesting discussion! I'd like to understand more about exactly when Jukka's solution (inner keys), Jose's solution (compound keys), and the current tunneling solution (outer keys) can and should be used. There's a number of relevant cases: * Non-key deriving methods: here we have a choice of no keys at all, or the keys from the outer method. What are the tradeoffs? Or perhaps there are only positive effects from the use of the keys? * Strong, modern methods that generate good keys: should we only rely on the inner keys here, or consider only the use of the tunnel keys or compound keys? Again, what are the tradeoffs? There seems to be at least some issues in exporting e.g. TLS keys from the tunnel and use them elsewhere. What are the advantages of the compound keys in this scenario? * Methods that generate bad keys ;-) Jari From jrv@umich.edu Tue Mar 4 17:20:47 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Mar 2003 12:20:47 -0500 Subject: [eap] Sending new requests before response? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA40@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA40@esebe023.ntc.nokia.com> Message-ID: <1139498.1046780446@[10.0.1.2]> --On Tuesday, March 4, 2003 9:54 AM +0200 Pasi.Eronen@nokia.com wrote: > > Is EAP "lock-step" or not? > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: March 4th, 2003 > Reference: - > Document: RFC2284bis and RFC 2869bis (and maybe state machine) > Comment type: T > Priority: 1 > Section: various > Rationale/Explanation of issue: > > I know this issue has been discussed before (e.g. James Carlson's > email on January 6th [1]), but since it has come up in PANA again (and > might cause extra complexity there), I would like to see the issue > explictly clarified in 2284bis and/or 2869bis. > > [1] http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html > > So, the question is: Is the Authenticator/EAP Server allowed to send a > new Request (with different Identifier and contents) before it has > received a Response to the previous outstanding Request? (that is, > is EAP "lock-step" protocol or not?) > The state machine at least assumes that lock step is required. I believe this was the consensus on an EAP-design group call, but I am not positive I remember correctly, or that all who might disagree were on the call. I think the alternative is very hard to describe and implement at the detail level. Specifically, if one allows multiple Requests in parallel, then each will need to have a separate id. each id will need to be unique. If a Request is retransmitted, the peer may respond to both the original and retransmitted request, or to only one of them. The authenticator will not know whether the response is coming or not, so it won't be able to reuse the id until a timeout. The assumption of ordering doesn't help this since the authenticator can never be sure the peer won't send a response. Lock step makes it much simpler and more understandable. If a response comes that is not for the just send id, it can be dropped. > At least it seems that 2869bis does not support this kind of behavior > (since the authentication server can send an Accept-Challenge only in > response to an Access-Request). So, even if we allow "non-lock-step > behavior" in 2284bis, perhaps it should be explicitly forbidden in > 2869bis? (I don't think this is a problem, since 2869bis does not > support all EAP features anyway, like role reversal). > > I don't have a strong opinion on this one: allowing such behavior > might increase complexity, but as James said, there was no such > restriction in RFC2284 (or at least so it seems). > > If we get some kind of consensus on which option should be chosen > (allow non-lock-step behavior in 2284bis but prohibit it in 2869bis, > or prohibit it in both), I can try to propose some text. (Or, it > might be that the specs already say this, but I can't find it :-) > > (BTW, there are some parts in 2284bis which assume lock-step behavior > and need changing if non-lock-step is allowed. For example, > Section 4.1: "In order to avoid confusion between new Requests > and retransmissions, the Identifier value chosen for each new Request > need only be different from the previous Request, but need not be > unique within the conversation.") > > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From ngoel@intellinet-tech.com Tue Mar 4 19:33:16 2003 From: ngoel@intellinet-tech.com (Narendar Goel) Date: Tue, 4 Mar 2003 14:33:16 -0500 Subject: [eap] EAP-SIM Message-ID: Hi All, Recently draft draft-haverinen-pppext-eap-sim-10.txt was posted at IETF. Does someone have a list of major differences from Draft 8? I am also looking for test vectors to validate EAP-SIM implementation. Someone please suggest how to get the test vectors for EAP-SIM. Best Regards, -Narender From jrv@umich.edu Tue Mar 4 22:32:13 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Mar 2003 17:32:13 -0500 Subject: [eap] editorial issues 2284bis Message-ID: <1845935.1046799133@[10.0.1.2]> Following are several editorial issues fore 2284 bis. Description of issue: simplify Introduction by not introducing concepts before needed Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: 3/4/03 Reference: Document: Document Requiring change RFC2284bis Comment type:E Priority: 1 Section: 1 Rationale/Explanation of issue: Concept of backend server is best introduced in its own sections Length description of problem Requested change:change wording from middle of 3rd paragraph from: Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and users. Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication to: Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the authenticator to use a backend server to do the actual authentication method. ---------------------------------------- Comment type:E Priority: 1 Section: 1.2 Rationale/Explanation of issue: Definition of EAP server is confusing See discussion on EAP list on EAP State machine. proposal: change: EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server. to: EAP server The entity that terminates the EAP authentication method with the peer. In the case where there is no backend authentication server the EAP server is part of the authenticator. In the case where the authenticator operates in pass through mode, the EAP server is located on the backend authentication server. ----------------------------- Comment type:E Priority: 2 Section: 1.2 Rationale/Explanation of issue: clarification of Mutual Authentication definition Change: Mutual authentication This refers to an EAP method in which, within an interlocked exchange, 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. To: Mutual authentication This refers to an EAP method in which, within an interlocked exchange, the authenticator authenticates the peer and the peer authenticates the authenticator. Two independent one-way methods, running in opposite directions do not provide mutual authentication as defined here. ---------------------- Comment type:E Priority: 2 Section: 1.2 Rationale/Explanation of issue:clarification proposal: change : Security claims terminology (see Section 7.2): to: Security claims terminology for EAP Methods (see Section 7.2): ----------------- Comment type:E Priority: 2 Section: 1.2 Rationale/Explanation of issue:clarification of integrity protection definition proposal: change: Integrity protection This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses, and method-specific success and failure indications. When making this claim, a method specification MUST describe the fields within the EAP packet that are protected. to: Integrity protection This refers to per-packet authentication of all EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the fields within the EAP packet that are authenticated. -------------------- Comment type:E Priority:1 Section: 2 Rationale/Explanation of issue: Simplify description proposal: change: [1] The authenticator sends a Request to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, etc. The MD5-challenge type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports); or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.). to: [1] The authenticator sends a Request to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, etc. Typically, the authenticator will send an initial Identity Request. [Note: an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports); or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.).] From jsalowey@cisco.com Tue Mar 4 22:38:43 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 4 Mar 2003 14:38:43 -0800 Subject: [eap] EAP-SIM In-Reply-To: Message-ID: <000001c2e29e$cfe385e0$0200000a@amer.cisco.com> There have been no wire protocol changes since Draft 6. The major differences are in the following areas: 1. Security considerations section has been reworked to be more in line with what is required by 2284bis. 2. The handling and requesting of identity and pseudonyms has been clarified. 3. There were some modications to the terminology in the key derivation section (this may change again). I don't think anyone has had a chance to work on test vectors yet. Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Narendar Goel > Sent: Tuesday, March 04, 2003 11:33 AM > To: eap@frascone.com > Subject: [eap] EAP-SIM > > > Hi All, > Recently draft draft-haverinen-pppext-eap-sim-10.txt was > posted at IETF. Does someone have a list of major differences > from Draft 8? I am also looking for test vectors to validate > EAP-SIM implementation. Someone please suggest how to get the > test vectors for EAP-SIM. Best Regards, -Narender > > > _______________________________________________ > eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Mar 4 22:48:23 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Mar 2003 17:48:23 -0500 Subject: [eap] 2284 bis issues Message-ID: <1904132.1046800103@[10.0.1.2]> Description of issue : simplify description of sequences / separate description from security issues Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: 3/4/03 Document: RFC2284bis Comment type: E Priority: S Section: 2.1 Rationale/Explanation of issue: Description implies that sequences are not supported. The rationale for this is security indications, and should be in the security section. Requested change: change: An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. 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 sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. to: An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. 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 sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. and rewrite the following and add to security section: However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. From ngoel@intellinet-tech.com Tue Mar 4 22:48:39 2003 From: ngoel@intellinet-tech.com (Narendar Goel) Date: Tue, 4 Mar 2003 17:48:39 -0500 Subject: [eap] EAP-SIM In-Reply-To: <000001c2e29e$cfe385e0$0200000a@amer.cisco.com> Message-ID: Joe, Thanks. Can you suggest any commercially/freely available eap-sim client adaptors which can be used to do interoperability testing for EAP-SIM protocol? Or is anyone planning inter operability testing/bakeoff for eap-sim. Best Regards, -Narender -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of Joseph Salowey Sent: Tuesday, March 04, 2003 5:39 PM To: 'Narendar Goel'; eap@frascone.com Subject: RE: [eap] EAP-SIM There have been no wire protocol changes since Draft 6. The major differences are in the following areas: 1. Security considerations section has been reworked to be more in line with what is required by 2284bis. 2. The handling and requesting of identity and pseudonyms has been clarified. 3. There were some modications to the terminology in the key derivation section (this may change again). I don't think anyone has had a chance to work on test vectors yet. Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Narendar Goel > Sent: Tuesday, March 04, 2003 11:33 AM > To: eap@frascone.com > Subject: [eap] EAP-SIM > > > Hi All, > Recently draft draft-haverinen-pppext-eap-sim-10.txt was > posted at IETF. Does someone have a list of major differences > from Draft 8? I am also looking for test vectors to validate > EAP-SIM implementation. Someone please suggest how to get the > test vectors for EAP-SIM. Best Regards, -Narender > > > _______________________________________________ > eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Tue Mar 4 23:28:12 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 04 Mar 2003 18:28:12 -0500 Subject: [eap] rfc2284bis issue Message-ID: <2047455.1046802492@[10.0.1.2]> Description of issue Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: 3/4/03 Document: Document Requiring change RFC2284bis Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue:Peer Continuing after NAK to unexpected REQ Length description of problem As described in the current draft, the Authenticator can send a Request for a new method type before completing the current method. As described, the peer would then NAK the Request with the data field containing the current type. while I thought this might work at one time, I am now convinced that this would be a bad idea for the following reasons: 1. sending a new REQ in the middle of a method seems like it would be an attempt to "negotiate" after seeing how the method is going - seems like bad security practice. 2. if the peer and authenticator don't understand how to do a method in the same way, then probably this should just fail. It is badly implemented or badly designed. 3. if the intent is to avoid a DOS attack the better way would be to have the peer silently discard the unexpected Req rather than NAK it. The unexpected Request is treated as an invalid message, which it is. this is the way the current state machine treats it. 4. if the intent is to allow parallel methods to operate, this doesn't do it. Requested change: Proposal change: If the authenticator sends a message of a different Type prior to completion of the final round of a given method the peer SHOULD silently discard such a Request. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. to: If the authenticator sends a message of a different Type prior to completion of the final round of a given method the peer SHOULD silently discard the Request. Since an EAP packet with a different Type may be sent by an attacker, this behaviour will allow the peer to continue if the authenticator sends additional Request for the current type. If it does not receive a request for the current type it will time out and the EAP conversation will fail. From jsalowey@cisco.com Tue Mar 4 23:37:22 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 4 Mar 2003 15:37:22 -0800 Subject: [eap] EAP-SIM In-Reply-To: Message-ID: <001f01c2e2a7$01c9e6a0$0200000a@amer.cisco.com> Someone just remided me that there was a somewhat significant change in one of the previous drafts. The order of the keys sent in the RADIUS attributes changed to line up with what is done in EAP-TLS. Right now I don't know of any freely/commercially available implementations that are up to the current draft, but perhaps some vendors on the list have implementations available. Does anyone know if there are any inter operability testing/bakeoff events for EAP, perhaps EAP-SIM testing could be done in conjunction with this? Joe > -----Original Message----- > From: Narendar Goel [mailto:ngoel@intellinet-tech.com] > Sent: Tuesday, March 04, 2003 2:49 PM > To: Joseph Salowey; eap@frascone.com > Subject: RE: [eap] EAP-SIM > > > Joe, > Thanks. Can you suggest any commercially/freely available > eap-sim client adaptors which can be used to do > interoperability testing for EAP-SIM protocol? Or is anyone > planning inter operability testing/bakeoff for eap-sim. Best > Regards, -Narender > > -----Original Message----- > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com]On Behalf Of > Joseph Salowey > > Sent: Tuesday, March 04, 2003 5:39 PM > To: 'Narendar Goel'; eap@frascone.com > Subject: RE: [eap] EAP-SIM > > > There have been no wire protocol changes since Draft 6. The > major differences are in the following areas: > > 1. Security considerations section has been reworked to be > more in line with what is required by 2284bis. > > 2. The handling and requesting of identity and pseudonyms has > been clarified. > > 3. There were some modications to the terminology in the key > derivation section (this may change again). > > I don't think anyone has had a chance to work on test vectors yet. > > Joe > > > -----Original Message----- > > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com] On Behalf > > Of Narendar Goel > > > Sent: Tuesday, March 04, 2003 11:33 AM > > To: eap@frascone.com > > Subject: [eap] EAP-SIM > > > > > > Hi All, > > Recently draft draft-haverinen-pppext-eap-sim-10.txt was posted at > > IETF. Does someone have a list of major differences from > Draft 8? I am > > also looking for test vectors to validate EAP-SIM implementation. > > Someone please suggest how to get the test vectors for > EAP-SIM. Best > > Regards, -Narender > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From paul.congdon@hp.com Tue Mar 4 15:04:50 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Tue, 4 Mar 2003 10:04:50 -0500 Subject: [eap] IEEE 802.1 and IEEE 802.11 Archive access Message-ID: <499DC368E25AD411B3F100902740AD651299257C@xrose03.rose.hp.com> Just as an FYI... 802.1aa/D5 does NOT include the latest statemachines. We did not have enough time to get them in, but will be reviewing them at the next 802.1 meeting next week. Paul > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Sunday, March 02, 2003 5:11 PM > To: eap@frascone.com > Subject: [eap] IEEE 802.1 and IEEE 802.11 Archive access > > > By arrangement with IEEE 802.1 chair Tony Jeffree, EAP WG > participants have access to work in progress in IEEE 802.1, > using the userID and password noted on the EAP issues web site: > http://www.drizzle.com/~aboba/EAP/eapissues.html Recently, IEEE 802.11 has granted access to their archive to individuals authorized to access the IEEE 802.1 archive. As a result, EAP WG members also now have access to IEEE 802.11 work in progress. In particular, the following documents may be of interest to EAP WG participants: IEEE 802.1aa, Draft 5 (forthcoming, includes revised IEEE 802.1X state machine) IEEE 802.1i, Draft 3.1 (includes description of TKIP, CCMP and WRAP key hierarchy) IEEE 802.11f, Draft 5 (includes support for predictive handoff) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Pasi.Eronen@nokia.com Wed Mar 5 12:54:52 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 5 Mar 2003 14:54:52 +0200 Subject: [eap] RE: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA42@esebe023.ntc.nokia.com> (BTW, there is already open issue (#87) related to this.) Both the current and proposed text (sort of) assume that EAP methods either have a single well-defined "final round", or they have internal mechanisms for signalling end of method (e.g. TLS alert in EAP-TLS). I don't think this applies to all methods;=20 and the correct action to take also depends on the client's and server's local policy (see below). First, not all methods have a well-defined final round: consider a method that first authenticates the client to the server, and then the server to the client. Suppose that the client authentication fails (but the client doesn't know this!), and several more rounds are still left in the method. What should the server do, if the method does not have an internal "failure" message (which adds another round-trip anyway), but the server's policy allows trying other methods? Clearly sending a new Request for the next method type (or Identity) seems reasonable in this case. (Obviously, if only a single method is supported by both the client and the server, this issue is quite trivial.) When the client receives this Request (with new Type), it=20 can silently discard it only if 1) the current method can only fail after the last Response, or 2) the current method has an internal "failure" message (which should have been used instead, so the request with new type shouldn't have been sent), or 3) the client's policy allows only a single EAP method, or 4) the client's policy says that if one method has been started=20 (Response sent) and fails (either after final round or in the = middle), the whole EAP conversation fails. In cases 3 and 4, the client can ignore the message hoping that it was spoofed by the attacker (if it was not, then the whole conversation fails anyway); however, see below for this DoS point. If none of these hold (method can fail in the middle but no internal failure message; multiple methods allowed; if one method fails, trying others is allowed), the client should either send a Response (if it permits the new method), or Nak it (so the server can propose something else), no matter if the previous method was completed or not. Methods in which the server can discover failure before the last message, and which don't have any internal "failure end of method" message include at least EAP-SIM, EAP-AKA and EAP-SRP. However, even if the method has an internal failure mechanism, silently discarding the message (cases 3-4 above) doesn't change the DoS situation significantly because the internal failure messages are not authenticated anyway in most cases (e.g. MS-CHAPv2, EAP-TLS alerts). If the EAP state machine includes a concept of "packet filter", an EAP method could use it to specify rule "ignore all other messages except my messages, until I change this otherwise" (However, it seems that the state machine will end up specifying only a subset of behavior allowed by 2284bis anyway; I think this is sad, but getting the two to agree seems to require a lot of restrictions to 2284bis which weren't in RFC2284, and many people=20 seem to oppose adding such restrictions on behavior?). Best regards, Pasi ---Original message---- > Description of issue > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: 3/4/03 > Document: Document Requiring change RFC2284bis > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue:Peer Continuing after NAK to unexpected = REQ > Length description of problem > As described in the current draft, the Authenticator can send a = Request for=20 > a new method type before completing the current method. As described, = the=20 > peer would then NAK the Request with the data field containing the = current=20 > type. >=20 > while I thought this might work at one time, I am now convinced that = this=20 > would be a bad idea for the following reasons: > 1. sending a new REQ in the middle of a method seems like it would be = an=20 > attempt to "negotiate" after seeing how the method is going - seems = like=20 > bad security practice. > 2. if the peer and authenticator don't understand how to do a method = in the=20 > same way, then probably this should just fail. It is badly = implemented or=20 > badly designed. > 3. if the intent is to avoid a DOS attack the better way would be to = have=20 > the peer silently discard the unexpected Req rather than NAK it. The=20 > unexpected Request is treated as an invalid message, which it is. = this is=20 > the way the current state machine treats it. > 4. if the intent is to allow parallel methods to operate, this doesn't = do=20 > it. > Requested change: > Proposal >=20 > change: > If the > authenticator sends a message of a different Type prior to = completion > of the final round of a given method the peer SHOULD silently = discard > such a Request. Otherwise it MAY send a Response with the same Type = as > the Request. Since an EAP packet with a different Type may be sent > by an attacker, an authenticator receiving a Nak including a > preference for the Type in progress SHOULD log the event, but > otherwise not take any action. > > to: > > If the authenticator sends a message of a different Type prior to > completion of the final round of a given method the peer SHOULD = silently > discard the Request. Since an EAP packet with a different Type may = be > sent by an attacker, this behaviour will allow the peer to continue = if > the authenticator sends additional Request for the current type. If = it > does not receive a request for the current type it will time out and = the > EAP conversation will fail. From aboba@internaut.com Wed Mar 5 12:38:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 04:38:24 -0800 (PST) Subject: [eap] Re: RFC 2284bis issue In-Reply-To: <20030305125502.17551.35080.Mailman@wolverine> Message-ID: The text that is proposed to be changed does not actually exist within RFC 2284bis-01. Please revise this issue and resubmit. > > Description of issue > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: 3/4/03 > Document: Document Requiring change RFC2284bis > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue:Peer Continuing after NAK to unexpected REQ > Length description of problem > As described in the current draft, the Authenticator can send a Request for > a new method type before completing the current method. As described, the > peer would then NAK the Request with the data field containing the current > type. > > while I thought this might work at one time, I am now convinced that this > would be a bad idea for the following reasons: > 1. sending a new REQ in the middle of a method seems like it would be an > attempt to "negotiate" after seeing how the method is going - seems like > bad security practice. > 2. if the peer and authenticator don't understand how to do a method in the > same way, then probably this should just fail. It is badly implemented or > badly designed. > 3. if the intent is to avoid a DOS attack the better way would be to have > the peer silently discard the unexpected Req rather than NAK it. The > unexpected Request is treated as an invalid message, which it is. this is > the way the current state machine treats it. > 4. if the intent is to allow parallel methods to operate, this doesn't do > it. > > Requested change: > Proposal > > change: > If the > authenticator sends a message of a different Type prior to completion > of the final round of a given method the peer SHOULD silently discard > such a Request. Otherwise it MAY send a Response with the same Type as > the Request. Since an EAP packet with a different Type may be sent > by an attacker, an authenticator receiving a Nak including a > preference for the Type in progress SHOULD log the event, but > otherwise not take any action. > > to: > > If the authenticator sends a message of a different Type prior to > completion of the final round of a given method the peer SHOULD silently > discard the Request. Since an EAP packet with a different Type may be > sent by an attacker, this behaviour will allow the peer to continue if > the authenticator sends additional Request for the current type. If it > does not receive a request for the current type it will time out and the > EAP conversation will fail. From aboba@internaut.com Wed Mar 5 12:57:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 04:57:29 -0800 (PST) Subject: [eap] Re: Issue 91: Definitions Message-ID: I'd like to recommend that the proposed changes be accepted. Any objections? Issue 91: Definitions Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 3, 2003 Document: EAP-01 Comment type: Editorial Priority: S Section: 1.2 Rationale/Explanation of issue: change: "EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server." to: "EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used the EAP server is part of the authenticator. In the case where the authenticator operates in pass through mode, the EAP server is located on the backend authentication server." Change: "Mutual authentication This refers to an EAP method in which, within an interlocked exchange, 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." To: "Mutual authentication This refers to an EAP method in which, within an interlocked exchange, the authenticator authenticates the peer and the peer authenticates the authenticator. Two independent one-way methods, running in opposite directions do not provide mutual authentication as defined here." From aboba@internaut.com Wed Mar 5 13:03:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 05:03:07 -0800 (PST) Subject: [eap] Re: Issue 92: Integrity Protection Message-ID: Since the EAP Failure and Success messages don't have a built-in integrity check, it would appear that this change makes the Integrity Protection claim impossible to satisfy. Am I missing something? ------------------------------------------------------------------------- Issue 92: Integrity Protection Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 3, 2003 Document: EAP-01 Comment type: Technical Priority: 2 Section: 1.2 change: "Integrity protection This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses, and method-specific success and failure indications. When making this claim, a method specification MUST describe the fields within the EAP packet that are protected." to: "Integrity protection This refers to per-packet authentication of all EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the fields within the EAP packet that are authenticated." From aboba@internaut.com Wed Mar 5 13:09:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 05:09:43 -0800 (PST) Subject: [eap] Re: Issue 93: Simplify Description Message-ID: I'd like to recommend that this change be accepted. Any objections? -------------------------------------------------------------------- Issue 93: Simplify Description Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 3, 2003 Document: EAP-01 Comment type: Editorial Priority: 1 Section: 2 change: "[1] The authenticator sends a Request to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, etc. The MD5-challenge type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports); or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.)." to: "[1] The authenticator sends a Request to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, etc. Typically, the authenticator will send an initial Identity Request. [Note: an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports); or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.).]" From aboba@internaut.com Wed Mar 5 13:36:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 05:36:10 -0800 (PST) Subject: [eap] Re: Issue 90: Simplify introduction Message-ID: There had been some confusion about the behavior of authenticators in pass-through mode versus non-pass-through, and the clarification was added to address that. Removing the clarification as requested in this change seems like a bad idea since it would cause the specification to again become ambiguous. Comments? --------------------------------------------------------------------- Issue 90: Simplify Introduction Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 3, 2003 Document: EAP-01 Comment type: Technical Priority: S Section: 1 Rationale/Explanation of issue: change wording from middle of 3rd paragraph from: "Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and users. Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication" to: "Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the authenticator to use a backend server to do the actual authentication method." From jrv@umich.edu Wed Mar 5 14:53:04 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 05 Mar 2003 09:53:04 -0500 Subject: [eap] RE: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA42@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA42@esebe023.ntc.nokia.com> Message-ID: <113123.1046857974@[10.0.1.2]> --On Wednesday, March 5, 2003 2:54 PM +0200 Pasi.Eronen@nokia.com wrote: > > (BTW, there is already open issue (#87) related to this.) > > Both the current and proposed text (sort of) assume that EAP > methods either have a single well-defined "final round", or they > have internal mechanisms for signalling end of method (e.g. TLS > alert in EAP-TLS). I don't think this applies to all methods; > and the correct action to take also depends on the client's and > server's local policy (see below). > > First, not all methods have a well-defined final round: consider > a method that first authenticates the client to the server, and > then the server to the client. Suppose that the client > authentication fails (but the client doesn't know this!), and > several more rounds are still left in the method. > > What should the server do, if the method does not have an > internal "failure" message (which adds another round-trip > anyway), but the server's policy allows trying other methods? > Clearly sending a new Request for the next method type (or > Identity) seems reasonable in this case. > this is a good question. it is not handled well in the current state machine. > (Obviously, if only a single method is supported by both > the client and the server, this issue is quite trivial.) > > When the client receives this Request (with new Type), it > can silently discard it only if > 1) the current method can only fail after the last Response, or > 2) the current method has an internal "failure" message > (which should have been used instead, so the request with > new type shouldn't have been sent), or > 3) the client's policy allows only a single EAP method, or > 4) the client's policy says that if one method has been started > (Response sent) and fails (either after final round or in the middle), > the whole EAP conversation fails. > > In cases 3 and 4, the client can ignore the message hoping that > it was spoofed by the attacker (if it was not, then the whole > conversation fails anyway); however, see below for this DoS > point. > I guess you could make 3 a subset of 4 > If none of these hold (method can fail in the middle but no > internal failure message; multiple methods allowed; if one method > fails, trying others is allowed), the client should either send a > Response (if it permits the new method), or Nak it (so the server > can propose something else), no matter if the previous method was > completed or not. > I think this can be made to work in the state machine- it requires changes but seems doable - as long as methods are single threaded, i.e. the authenticator doesn't send a request for a new method and continue the old. But I wonder if this is good practice. Can a server negotiate down in the middle of a method? this seems particularly bad if client has negotiated to a mutual authentication method which is satisfactory to it, then the server is trying to "negotiate down". > Methods in which the server can discover failure before the last > message, and which don't have any internal "failure end of > method" message include at least EAP-SIM, EAP-AKA and EAP-SRP. > > However, even if the method has an internal failure mechanism, > silently discarding the message (cases 3-4 above) doesn't change > the DoS situation significantly because the internal failure > messages are not authenticated anyway in most cases > (e.g. MS-CHAPv2, EAP-TLS alerts). > silent discard is not necessarily for DOS, but to make the state sequence "logical" - it refuses messages which logically should not be there. What you are suggesting is that logically they could be there, so we should talk about it and see if we agree. If so, the state machine can be changed. > If the EAP state machine includes a concept of "packet filter", > an EAP method could use it to specify rule "ignore all other > messages except my messages, until I change this otherwise" > (However, it seems that the state machine will end up specifying > only a subset of behavior allowed by 2284bis anyway; I think this > is sad, but getting the two to agree seems to require a lot of > restrictions to 2284bis which weren't in RFC2284, and many people > seem to oppose adding such restrictions on behavior?). > I am not sure what subset of behaviour you are suggesting will be prohibited. Some of what you are suggesting can be allowed even with the current state machine if the methods are written to allow it. I do think that what you are suggesting is different than allowing "parallel" methods. That still seems hard to me. Hopefully we will continue this conversation. John > Best regards, > Pasi > > ---Original message---- > > Description of issue > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: 3/4/03 > > Document: Document Requiring change RFC2284bis > > Comment type: T > > Priority: S > > Section: 2.1 > > Rationale/Explanation of issue:Peer Continuing after NAK to unexpected > > REQ Length description of problem > > As described in the current draft, the Authenticator can send a Request > > for a new method type before completing the current method. As > > described, the peer would then NAK the Request with the data field > > containing the current type. > > > > while I thought this might work at one time, I am now convinced that > > this would be a bad idea for the following reasons: > > 1. sending a new REQ in the middle of a method seems like it would be > > an attempt to "negotiate" after seeing how the method is going - seems > > like bad security practice. > > 2. if the peer and authenticator don't understand how to do a method in > > the same way, then probably this should just fail. It is badly > > implemented or badly designed. > > 3. if the intent is to avoid a DOS attack the better way would be to > > have the peer silently discard the unexpected Req rather than NAK it. > > The unexpected Request is treated as an invalid message, which it is. > > this is the way the current state machine treats it. > > 4. if the intent is to allow parallel methods to operate, this doesn't > > do it. > > > Requested change: > > Proposal > > > > change: > > If the > > authenticator sends a message of a different Type prior to completion > > of the final round of a given method the peer SHOULD silently discard > > such a Request. Otherwise it MAY send a Response with the same Type > > as the Request. Since an EAP packet with a different Type may be sent > > by an attacker, an authenticator receiving a Nak including a > > preference for the Type in progress SHOULD log the event, but > > otherwise not take any action. > > > > to: > > > > If the authenticator sends a message of a different Type prior to > > completion of the final round of a given method the peer SHOULD > > silently discard the Request. Since an EAP packet with a different > > Type may be sent by an attacker, this behaviour will allow the peer > > to continue if the authenticator sends additional Request for the > > current type. If it does not receive a request for the current type > > it will time out and the EAP conversation will fail. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Mar 5 13:44:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 05:44:03 -0800 (PST) Subject: [eap] Re: Issue 94: Is EAP a lock-step protocol? Message-ID: Is there a proposed change to the text of EAP-01 or RFC 2869bis in order to address this issue? --------------------------------------------------------------------------- Issue 94: EAP a lockstep protocol? Submitter name: Pasi Eronen Submitter email address: pari.eronen@nokia.com Date first submitted: March 4, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html Document: EAP-01 Comment type: Technical Priority: 1 I know this issue has been discussed before (e.g. James Carlson's email on January 6th [1]), but since it has come up in PANA again (and might cause extra complexity there), I would like to see the issue explictly clarified in 2284bis and/or 2869bis. So, the question is: Is the Authenticator/EAP Server allowed to send a new Request (with different Identifier and contents) before it has received a Response to the previous outstanding Request? (that is, is EAP "lock-step" protocol or not?) At least it seems that 2869bis does not support this kind of behavior (since the authentication server can send an Accept-Challenge only in response to an Access-Request). So, even if we allow "non-lock-step behavior" in 2284bis, perhaps it should be explicitly forbidden in 2869bis? (I don't think this is a problem, since 2869bis does not support all EAP features anyway, like role reversal). I don't have a strong opinion on this one: allowing such behavior might increase complexity, but as James said, there was no such restriction in RFC2284 (or at least so it seems). If we get some kind of consensus on which option should be chosen (allow non-lock-step behavior in 2284bis but prohibit it in 2869bis, or prohibit it in both), I can try to propose some text. (Or, it might be that the specs already say this, but I can't find it :-) (BTW, there are some parts in 2284bis which assume lock-step behavior and need changing if non-lock-step is allowed. For example, Section 4.1: "In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation.") Best regards, Pasi From jose.p.puthenkulam@intel.com Wed Mar 5 18:04:56 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 5 Mar 2003 10:04:56 -0800 Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt Message-ID: This discussion need some more contextual information to be considered for getting sense of what keys to use where. Today, one key issue in WLANs is a consistent level of security. 802.11i prescribes 256 bits of keying material that is needed. Now several methods may be capable of generating the required keying material but with varying strengths. So assuming that each WLAN hotspot could support multiple credentials, the security of the air link is going to be different for each method. So tunnel methods will help provide a consistent strength for the keying material irrespective of the specific method used. Now specific method keys if they are strong could also be used, but for some methods like EAP-SIM the strength can vary based on the specific SIM algorithm in use. So what is the best solution? Is it good to rely on method specific keys and then have the air link security only as good as your weakest link. Or provide method independent keys like tunnel methods do and provide a consistent level of security. Just some thoughts to consider in this discussion, best regards, jose -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, March 03, 2003 11:58 PM To: Puthenkulam, Jose P Cc: 'jukka.ylitalo@lmf.ericsson.se'; eap@frascone.com Subject: Re: [eap] Review: draft-puthenkulam-eap-binding-01.txt Puthenkulam, Jose P wrote: >>Why we wouldn't solve the case in the following way: >> >>(1) The outer protocol should be used only for server authentication >> and to offer privacy for the client during authentication. The keying >> material produced by the outer protocol would not be used anymore for >> session protection. >>(2) The session keys would be derived on the basis of the inner protocol. >> > > This is a possible solution, but then cryptographic binding can provide > stronger keys than session keys generated by some inner methods like EAP-SIM > or EAP-MSCHAPv2. Also tunnel keys afford the only protection for non-key > deriving methods. So don't see why tunnel keys that are typically > strong need to be avoided. This is an interesting discussion! I'd like to understand more about exactly when Jukka's solution (inner keys), Jose's solution (compound keys), and the current tunneling solution (outer keys) can and should be used. There's a number of relevant cases: * Non-key deriving methods: here we have a choice of no keys at all, or the keys from the outer method. What are the tradeoffs? Or perhaps there are only positive effects from the use of the keys? * Strong, modern methods that generate good keys: should we only rely on the inner keys here, or consider only the use of the tunnel keys or compound keys? Again, what are the tradeoffs? There seems to be at least some issues in exporting e.g. TLS keys from the tunnel and use them elsewhere. What are the advantages of the compound keys in this scenario? * Methods that generate bad keys ;-) Jari From jsalowey@cisco.com Wed Mar 5 18:24:26 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 5 Mar 2003 10:24:26 -0800 Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt In-Reply-To: Message-ID: <000b01c2e344$7510c5f0$0301a8c0@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Puthenkulam, Jose P > Sent: Wednesday, March 05, 2003 10:05 AM > To: 'jari.arkko@piuha.net'; Puthenkulam, Jose P > Cc: 'jukka.ylitalo@lmf.ericsson.se'; eap@frascone.com > Subject: RE: [eap] Review: draft-puthenkulam-eap-binding-01.txt > > > This discussion need some more contextual information to be > considered for getting sense of what keys to use where. > Today, one key issue in WLANs is a consistent level of > security. 802.11i prescribes 256 bits of keying material that > is needed. Now several methods may be capable of generating > the required keying material but with varying strengths. So > assuming that each WLAN hotspot could support multiple > credentials, the security of the air link is going to be > different for each method. So tunnel methods will help > provide a consistent strength for the keying material > irrespective of the specific method used. Now specific method > keys if they are strong could also be used, but for some > methods like EAP-SIM the strength can vary based on the > specific SIM algorithm in use. > [Joe] All the EAP methods I can think of have variable security properties including PEAP and EAP-TLS. The security will vary based on the ciphersuites used and the parameters of the ciphersuites (key length etc.), some of which is not typically specified. The security of EAP-SIM is more associated with the strength of Ki ranther than the SIM algorithm (unless you are using the same Ki outside of EAP-SIM). > So what is the best solution? Is it good to rely on method > specific keys and then have the air link security only as > good as your weakest link. Or provide method independent keys > like tunnel methods do and provide a consistent level of security. > [Joe] Currently I am of the opinion that combined keys provides the best solution. Combined keys should provide the potential to be stronger than either individual key. I need to think more about Jukka's proposal. > Just some thoughts to consider in this discussion, > > best regards, > jose > > > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, March 03, 2003 11:58 PM > To: Puthenkulam, Jose P > Cc: 'jukka.ylitalo@lmf.ericsson.se'; eap@frascone.com > Subject: Re: [eap] Review: draft-puthenkulam-eap-binding-01.txt > > > Puthenkulam, Jose P wrote: > > >>Why we wouldn't solve the case in the following way: > >> > >>(1) The outer protocol should be used only for server authentication > >> and to offer privacy for the client during > authentication. The keying > >> material produced by the outer protocol would not be > used anymore for > >> session protection. > >>(2) The session keys would be derived on the basis of the inner > >>protocol. > >> > > > > This is a possible solution, but then cryptographic binding can > > provide stronger keys than session keys generated by some inner > > methods like > EAP-SIM > > or EAP-MSCHAPv2. Also tunnel keys afford the only protection for > > non-key deriving methods. So don't see why tunnel keys that are > > typically strong need to be avoided. > > This is an interesting discussion! I'd like to understand > more about exactly when Jukka's solution (inner keys), Jose's > solution (compound keys), and the current tunneling solution > (outer keys) can and should be used. There's a number of > relevant cases: > > * Non-key deriving methods: here we have a choice of no keys at all, > or the keys from the outer method. What are the tradeoffs? Or > perhaps there are only positive effects from the use of the keys? > > * Strong, modern methods that generate good keys: should we only > rely on the inner keys here, or consider only the use of the tunnel > keys or compound keys? Again, what are the tradeoffs? There seems > to be at least some issues in exporting e.g. TLS keys from the > tunnel and use them elsewhere. What are the advantages of the > compound keys in this scenario? > > * Methods that generate bad keys ;-) > > Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Thu Mar 6 00:10:30 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 05 Mar 2003 19:10:30 -0500 Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: References: Message-ID: <1773877.1046891429@[10.0.1.2]> --On Wednesday, March 5, 2003 5:03 AM -0800 Bernard Aboba wrote: > Since the EAP Failure and Success messages don't have a built-in integrity > check, it would appear that this change makes the Integrity Protection > claim impossible to satisfy. Am I missing something? > I think you are correct. It is impossible to have integrity check on success and failure messages. My understanding is that these are claims made for a method, not for eap as a whole. > ------------------------------------------------------------------------- > > > > Issue 92: Integrity Protection > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: March 3, 2003 > Document: EAP-01 > Comment type: Technical > Priority: 2 > Section: 1.2 > change: > > "Integrity protection > This refers to per-packet authentication and integrity > protection of EAP packets, including EAP Requests and > Responses, and method-specific success and failure > indications. > When making this claim, a method specification > MUST describe the fields within the EAP packet that are > protected." > > > to: > "Integrity protection > This refers to per-packet authentication of all EAP packets, > including EAP Requests and Responses. When making this claim, > a method specification MUST describe the fields within the EAP > packet that are authenticated." > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Mar 5 23:58:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 15:58:30 -0800 (PST) Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <1773877.1046891429@[10.0.1.2]> Message-ID: > I think you are correct. It is impossible to have integrity check on > success and failure messages. My understanding is that these are claims > made for a method, not for eap as a whole. Right. But since the claims can't be made for Success and Failure packets, why change the text to say "all EAP packets" instead of just "EAP Requests and Responses"? > > > ------------------------------------------------------------------------- > > > > > > > > Issue 92: Integrity Protection > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: March 3, 2003 > > Document: EAP-01 > > Comment type: Technical > > Priority: 2 > > Section: 1.2 > > change: > > > > "Integrity protection > > This refers to per-packet authentication and integrity > > protection of EAP packets, including EAP Requests and > > Responses, and method-specific success and failure > > indications. > > When making this claim, a method specification > > MUST describe the fields within the EAP packet that are > > protected." > > > > > > to: > > "Integrity protection > > This refers to per-packet authentication of all EAP packets, > > including EAP Requests and Responses. When making this claim, > > a method specification MUST describe the fields within the EAP > > packet that are authenticated." > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > From jrv@umich.edu Thu Mar 6 03:14:15 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 05 Mar 2003 22:14:15 -0500 Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: References: Message-ID: <2435408.1046902455@[10.0.1.2]> --On Wednesday, March 5, 2003 3:58 PM -0800 Bernard Aboba wrote: > > I think you are correct. It is impossible to have integrity check on > > success and failure messages. My understanding is that these are claims > > made for a method, not for eap as a whole. > > Right. But since the claims can't be made for Success and Failure packets, > why change the text to say "all EAP packets" instead of just "EAP Requests > and Responses"? > I agree. take "all" out - how about changing the text to "Integrity protection This refers to per-packet authentication of EAP Requests and Responses. When making this claim, a method specification MUST describe the messages in the Method and the fields in the messages that are authenticated." -- John > > > > > > --------------------------------------------------------------------- > > > ---- > > > > > > > > > > > > Issue 92: Integrity Protection > > > Submitter name: John Vollbrecht > > > Submitter email address: jrv@umich.edu > > > Date first submitted: March 3, 2003 > > > Document: EAP-01 > > > Comment type: Technical > > > Priority: 2 > > > Section: 1.2 > > > change: > > > > > > "Integrity protection > > > This refers to per-packet authentication and integrity > > > protection of EAP packets, including EAP Requests and > > > Responses, and method-specific success and failure > > > indications. > > > When making this claim, a method specification > > > MUST describe the fields within the EAP packet that are > > > protected." > > > > > > > > > to: > > > "Integrity protection > > > This refers to per-packet authentication of all EAP packets, > > > including EAP Requests and Responses. When making this claim, > > > a method specification MUST describe the fields within the EAP > > > packet that are authenticated." > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Mar 6 05:50:41 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 5 Mar 2003 21:50:41 -0800 (PST) Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <001d01c2e39d$20544740$0200000a@amer.cisco.com> Message-ID: > [Joe] does this refer to requests and responses that are part of the > method? Does it include the identity request and response? I don't > think you can protect the initial identity request/response either > (although you may be able to protect subsequent ones) Right. You can't protect Identity Request/Response or Nak, because it's too early. You can't protect Notification Request/Response, Success and Failure, because they they don't have room for a MIC. That means that you're left with method requests and responses, which is, after all, all a method can affect :) From henrik@levkowetz.com Thu Mar 6 14:07:34 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 6 Mar 2003 15:07:34 +0100 Subject: [eap] Re: Issue 91: Definitions In-Reply-To: References: Message-ID: <20030306150734.2867af8b.henrik@levkowetz.com> On Wed, 5 Mar 2003 04:57:29 -0800 (PST) Bernard Aboba wrote: > I'd like to recommend that the proposed changes be accepted. Any > objections? > Both of these look good to me. Henrik > Issue 91: Definitions > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: March 3, 2003 > Document: EAP-01 > Comment type: Editorial > Priority: S > Section: 1.2 > Rationale/Explanation of issue: > change: > "EAP server > The entity that terminates the EAP authentication with the > peer. In the case where there is no backend authentication > server, this term refers to the authenticator. Where the > authenticator operates in pass-through, it refers to the > backend authentication server." > to: > "EAP server > The entity that terminates the EAP authentication method with > the peer. In the case where no backend authentication > server is used the EAP server is part of the authenticator. In the > case where the authenticator operates in pass through mode, > the EAP server is located on the backend authentication server." > > Change: > "Mutual authentication > This refers to an EAP method in which, within an > interlocked exchange, 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." > To: > "Mutual authentication > This refers to an EAP method in which, within an > interlocked exchange, the authenticator authenticates the > peer and the peer authenticates the authenticator. Two > independent one-way methods, running in opposite directions do > not provide mutual authentication as defined here." > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- In a mature society, "civil servant" is semantically equal to "civil master". From henrik@levkowetz.com Thu Mar 6 14:13:48 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 6 Mar 2003 15:13:48 +0100 Subject: [eap] Re: Issue 93: Simplify Description In-Reply-To: References: Message-ID: <20030306151348.16d3203e.henrik@levkowetz.com> On Wed, 5 Mar 2003 05:09:43 -0800 (PST) Bernard Aboba wrote: Personally, I think the text reads better as-is, without breaking it up. With respect to removing the reference to CHAP, I'm indifferent. Henrik > I'd like to recommend that this change be accepted. Any objections? > > -------------------------------------------------------------------- > Issue 93: Simplify Description > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: March 3, 2003 > Document: EAP-01 > Comment type: Editorial > Priority: 1 > Section: 2 > change: > "[1] The authenticator sends a Request to authenticate the peer. The > Request has a type field to indicate what is being requested. > Examples of Request types include Identity, MD5-challenge, etc. > The MD5-challenge type corresponds closely to the CHAP > authentication protocol [RFC1994]. Typically, the authenticator > will send an initial Identity Request; however, an initial > Identity Request is not required, and MAY be bypassed. For > example, the identity may not be required where it is determined > by the port to which the peer has connected (leased lines, > dedicated switch or dial-up ports); or where the identity is > obtained in another fashion (via calling station identity or MAC > address, in the Name field of the MD5-Challenge Response, etc.)." > > to: > "[1] The authenticator sends a Request to authenticate the peer. The > Request has a type field to indicate what is being requested. > Examples of Request types include Identity, MD5-challenge, etc. > Typically, the authenticator will send an initial Identity Request. > > [Note: an initial > Identity Request is not required, and MAY be bypassed. For > example, the identity may not be required where it is determined > by the port to which the peer has connected (leased lines, > dedicated switch or dial-up ports); or where the identity is > obtained in another fashion (via calling station identity or MAC > address, in the Name field of the MD5-Challenge Response, etc.).]" > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- It is impossible for a man to love his wife wholeheartedly without loving all women somewhat. I suppose that the converse must be true of women. From aboba@internaut.com Thu Mar 6 13:00:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 05:00:59 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 Message-ID: I would like to propose that Issue 87 be resolved as follows: Change the text of Section 2.1 to the following: "An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, a particular named peer SHOULD NOT utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. 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 sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 4.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed." From henrik@levkowetz.com Thu Mar 6 14:27:23 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 6 Mar 2003 15:27:23 +0100 Subject: [eap] Re: Issue 90: Simplify introduction In-Reply-To: References: Message-ID: <20030306152723.0560e1d9.henrik@levkowetz.com> On Wed, 5 Mar 2003 05:36:10 -0800 (PST) Bernard Aboba wrote: > There had been some confusion about the behavior of authenticators in > pass-through mode versus non-pass-through, and the clarification was added > to address that. Removing the clarification as requested in this > change seems like a bad idea since it would cause the specification to > again become ambiguous. > > Comments? I would prefer to keep the text as is. I find it clear, it reads well, and it makes it easy to continue into the document with the understanding that both non-pass-through and pass-through operation exist. Henrik > > --------------------------------------------------------------------- > Issue 90: Simplify Introduction > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: March 3, 2003 > Document: EAP-01 > Comment type: Technical > Priority: S > Section: 1 > Rationale/Explanation of issue: > change wording from middle of 3rd paragraph from: > "Rather than requiring the authenticator to be updated to support each > new authentication method, EAP permits the use of a backend > authentication server which may implement some or all authentication > methods, with the authenticator acting as a pass-through for some or > all methods and users. > > Within this document, authenticator requirements apply regardless of > whether the authenticator is operating as a pass-through or not. > Where the requirement is meant to apply to either the authenticator > or backend authentication server, depending on where the EAP > authentication" > > to: > "Rather than requiring the authenticator to be updated to support each > new authentication method, EAP permits the authenticator to use a > backend server to do the actual authentication method." > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Error message in Haiku form: Stay the patient course Of little worth is your ire The network is down -- David Ansel From aboba@internaut.com Thu Mar 6 13:17:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 05:17:53 -0800 (PST) Subject: [eap] Proposed resolution of Issue 83 Message-ID: Change Section 2.5 to the following: A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD return an Access-Reject. In order for the RADIUS server to communicate that an invalid EAP packet has been received, but that the problem is non-fatal, an Access-Challenge containing a Service-Type=Packet-Reject MAY be sent. A NAS receiving an Access-Challenge with a Service-Type=Packet-Reject that is compliant with this specification MUST discard the current EAP packet, and check whether it has received additional EAP Response packets with an Identifier matching that of the last Request. If so, a new EAP Response packet MUST be sent to the RADIUS server within an Access-Request packet. Once the RADIUS server responds with a packet containing a non-null EAP-Message attribute, the NAS updates the Identifier value, and any pending Responses that do not match this value can be discarded. If another EAP Response packet is not available, then the retransmission timer is reset and the NAS retransmits the outstanding Request to the peer. A NAS that does not support Service-Type=Packet-Reject behaves as specified in [RFC2865], Section 5.6: "A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead." From henrik@levkowetz.com Thu Mar 6 14:52:43 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 6 Mar 2003 15:52:43 +0100 Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <2435408.1046902455@[10.0.1.2]> References: <2435408.1046902455@[10.0.1.2]> Message-ID: <20030306155243.5e42a89f.henrik@levkowetz.com> On Wed, 05 Mar 2003 22:14:15 -0500 John Vollbrecht wrote: > > > > I think you are correct. It is impossible to have integrity check on > > > success and failure messages. My understanding is that these are claims > > > made for a method, not for eap as a whole. > > > > Right. But since the claims can't be made for Success and Failure packets, > > why change the text to say "all EAP packets" instead of just "EAP Requests > > and Responses"? > > > I agree. take "all" out - how about changing the text to > > "Integrity protection > This refers to per-packet authentication of EAP Requests and Responses. > When making this claim, a method specification MUST describe the messages > in the Method and the fields in the messages that are authenticated." Mmm, the original text talks about both authentication and integrity protection; why remove integrity protection and have this only talk about authentication? Yes, providing message authentication without integrity protection is rather meaningless, but do we gain anything by taking out integrity protection from this paragraph? We could omit mentioning "method-specific success and failure indications", and get this: A) "This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the fields within the EAP packet that are protected." We could also explicitly limit this to EAP requests and responses, as in the following (but that would seem to ignore the possibility of methode- specific integrity protection carried in requests and responses also covering previous non-protected messages): B) "This refers to per-packet authentication and integrity protection of EAP Requests and Responses. When making this claim, a method specification MUST describe the fields within the EAP packet that are protected. If we want to change this paragraph, I'd propose that we use 'A' above. Henrik > > > -- John > > > > > > > > > --------------------------------------------------------------------- > > > > ---- > > > > > > > > > > > > > > > > Issue 92: Integrity Protection > > > > Submitter name: John Vollbrecht > > > > Submitter email address: jrv@umich.edu > > > > Date first submitted: March 3, 2003 > > > > Document: EAP-01 > > > > Comment type: Technical > > > > Priority: 2 > > > > Section: 1.2 > > > > change: > > > > > > > > "Integrity protection > > > > This refers to per-packet authentication and integrity > > > > protection of EAP packets, including EAP Requests and > > > > Responses, and method-specific success and failure > > > > indications. > > > > When making this claim, a method specification > > > > MUST describe the fields within the EAP packet that are > > > > protected." > > > > > > > > > > > > to: > > > > "Integrity protection > > > > This refers to per-packet authentication of all EAP packets, > > > > including EAP Requests and Responses. When making this claim, > > > > a method specification MUST describe the fields within the EAP > > > > packet that are authenticated." > > > > > > > > > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Never try to outstubborn a cat. From jari.arkko@piuha.net Thu Mar 6 16:56:31 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 06 Mar 2003 18:56:31 +0200 Subject: [eap] state machine design team minutes Message-ID: <3E677DBF.6030201@piuha.net> Date: Wednesday, March 5, 2003 Time: 07:00 - 08:30 AM PST Present: Nick L. Petroni, Henrik Levkowetz, Jari Arkko, John Vollbrecht, Paul Congdon, Bernard Aboba First set of minutes Scribe: Jari Arkko o Agenda - Reconciliation of EAP State Machine docs and RFC 2284bis o Draft status A new state machine draft has been submitted. It is available from http://www.cs.umd.edu/~npetroni/EAP/ before it makes it to the I-D directories. o Pasi Eronen's question - Pasi Eronen has asked on the list whether a request for a new method is allowed before the previous method has completed. - John: Here we are performing an EAP method, and the authenticator believes the client has failed. The question is, do we allow that? What if the client believed it needed to continue? Reportedly SIM and AKA might be able to detect failure before the method has fully completed. This sounds dangerous from a security perspective. - Bernard: This issue is number 87 "Handling of EAP Type change" in the issue data base. Our specifications must be backwards compatible. Most current implementations would hang upon this. John: How is this different from a method that has variable number of messages? Methods must be able to say when they are done. Bernard: this is already the case. - John: The issue is what happens when authenticator fails, can he send Failure immediately. Unclear whether the state machine does this or not. Bernard: RFC 2284bis and the state machine both say the failure must be accepted. (John wasn't sure about this.) Also, method switching is considered as a sequence. The specifications allows the functionality, but warns that it doesn't really work with existing clients. RFC 2284bis and the state machine are again in agreement. - Henrik: I think Pasi is saying that there might be a method-specific failure. Nick: The question is if the method should be able to fail gracefully. Bernard: No this is not required anywhere. - John: My problem is this: All of a sudden I am requested to do a completely different method from what I am executing right now. What am I supposed to do? Jari: You either support this or not. Bernard: You don't need to do anything special, the MUX just does not send anything to the first method any more. John: But there must be policy about this, I just killed the current method. Bernard: methods could install filters. - Summary: (1) Methods can change in the middle. (2) Support not likely in current implementations. (3) RFC 2284bis and state machine are in sync. (4) Parallel methods are not supported. o Filtering - Are success and failure acceptance also governed by filters? - What is the benefit of the filter? John: Just denial-of-service protection. Nick: I think filters are overly complex. Someone else: its simple, but it confuses the operation of the protocol. Nick: In the state machine, is it parseReceivedMessage() or policyAllow() who actually performs the filtering? parseReceivedMessage() does not do more than simple parsing. Jari: But policyAllow() only provides the capability to Nak, not to silently discard. One way to fix this is to return three values from the policyAllow() function. Bernard: PolicyAllow() shall not be a substitute for a good specification. John: But its not complicated. Just a question of whether to accept or nak a method. Bernard: What's in the nak? The current method? But what would the authenticator do, silently discard that Nak if some attacker had sent the request? Bernard: In practice many methods do not allow Failure in the middle. Nick: so it would make sense to fix RFC 2284bis to align with this. Bernard: Its what john explained: "I just want this type until I'm done". Jari: Ok, then I don't worry about the complexity any more. Nick: What we need is a third procedure, not parseReceivedMessage() or policyAllow(). Bernard: Its like this: filter is either installed or not. If installed the code has to match the current method. - What are the changes in the peer state machine due to this? There's either a new variable (not_interruptable), or a new state. There was a discussion on which approach is better, but we did not produce a conclusion. Nick and John will talk about this offline and resolve it Paul: Be careful to not end up with two true exit conditions after the Dialog state. - Bernard: What does this imply about validity checks in general? How is a MIC failure handled? Nick: I can silently discard today, if you look at the state machine. John: It is allowed but most methods don't do it. - Paul: The filter concept needs to consider Notifications. It can't just look for frames of the current type and Failures. o Identity appearing at any time (issue 52: identity requery) - Bernard: I have another question: can identity be sent at any time, like a notification? John: I think we agreed that it shouldn't come in the middle. Bernard: Yes, but identity is different because we can't nak it like methods. Nick: What are the options, either you discard or answer? Bernard: Yes. - Bernard: For methods, if you accept a method in the middle then its an abort for the current method. Here, its not aborting. John: But it is an abort, not treated like a notification. (Everyone agrees). Bernard: can someone post a response to issue 52? I think we got a response to 52, 80, and 87 then. - Bernard: if you install a filter, then you'd throw identity requests away as well. But if we receive it, do we have to respond always? John: unclear now, but that's what we'd be saying. Bernard: I have to check what RFC 2284 said about this. John: We can always respond with an empty response. Jari: What if filter is on, do we still respond like that? John: no, then we just throw away. - John: Is the identity a global variable that other methods should be able to read? Bernard: There's no communication between methods. But identity response is a global variable. It is available to any methods. John: Is there a reason to not allow other variables? Bernard: It would be implementation specific and would cause EAP to not interoperate well. The situation in EAP is already getting bad, because people are putting all kinds of strange things in it. John: But it would be useful to communicate things within a sequence. Bernard: If we start to go the authorization area, the IESG will shut us down! John: I suspect people will do this anyway. Jari: We can monitor method specifications as they appear in IETF, and request them to be changed if they break the EAP rules. o Administrative - Bernard: What i'd like to have for IETF #56 is a clear recommendation on what to do for each of the issues, and why. We have to discuss on the design team list what the text changes are, and what the recommendations are. - Jari: We will have the next design team meeting on Wednesday March 12th, and also in the IETF before the thursday meeting. Second set of minutes Scribe: Paul Congdon o Pasi's issue about Authenticator's requesting before previous completion 1. Doesn't seem to be compatible with current implementations. John V is asking a question of whether we want to support the ability to switch methods in the middle. Bernard feels strongly that we can't support this because it will hang current implementations. 2. The current state machine proposal (according to Nick) will accept a failure message in addition to any EAP packet of the expected type. Everything else will be tossed (in theory), but what you want to do is NAK new requests. 3. So according to Bernard, what Pasi is saying is already in the state machine and 2284bis. This would look like a sequence and would be dealt accordingly. In today's implementations, most won't respond to sequences and will hang. We are recommending that people respond with a NAK and the state machine supports this. 4. John's interpretation of Pasi's proposal is that you should be able to start a new method and have it complete when the previous method hasn't completed correctly. John wants to know if future implementations wanted to support this or not. 5. Looking at the current Peer machines, it looks like this is handled in the parseReceivedMessage() routine. If the method knows how to support seeing a new type, then it should work, but this isn't recommended. The Policy.allow() results for the method determine what to do, either NAK, silently discard or continue on. 6. The filter concept needs to consider Notifications. It can't just look for frames of the current type and Failures. 7. No support for parallel methods (issue #94). This is outlawed. 8. The exit conditions from Dialog need a little work to determine how the filter concept can be included. 9. I'm not sure the Pasi resolution actually works (IMHO) because if we are going to allow a new request without terminating the previous one, the state machines don't really support this because you will have two methods running at the same time. If there isn't a proper termination of the first method, the next method can't really start off. Bernard asserts that we are saying that only requests of a particular type are delivered to methods of a particular type, but if the previous method is going to allow switching to a new method, it must terminate itself somehow, but it isn't clear where this is done to me. The method-state variable must also be set in Dialog and not just Method if it isn't going to terminate itself because a new method is started. The policy.allow() function must also be changing method-state. Not clear this is articulated well. o Issue #52, #80, #87 1. We are not going to allow identity requests in the middle at anytime. They would be treated like sequences and methods themselves 2. It is just like any other method, but it can't be NAKed for backward compatibility. So, if the filter is on, then it will be discarded. What if the filter isn't turned on? Do you always have to respond to it? You can't NAK, so you must ignore. From aboba@internaut.com Thu Mar 6 17:19:50 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 09:19:50 -0800 (PST) Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <20030306155243.5e42a89f.henrik@levkowetz.com> Message-ID: > A) "This refers to per-packet authentication and integrity > protection of EAP packets, including EAP Requests and > Responses. When making this claim, a method specification > MUST describe the fields within the EAP packet that are > protected." > > We could also explicitly limit this to EAP requests and responses, as in > the following (but that would seem to ignore the possibility of methode- > specific integrity protection carried in requests and responses also > covering previous non-protected messages): > > B) "This refers to per-packet authentication and integrity > protection of EAP Requests and Responses. When making this > claim, a method specification MUST describe the fields > within the EAP packet that are protected. > > If we want to change this paragraph, I'd propose that we use 'A' above. I'd agree. I'd also add the following: "This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected." From aboba@internaut.com Thu Mar 6 17:29:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 09:29:26 -0800 (PST) Subject: [eap] Re: Issue 93: Simplify Description In-Reply-To: <20030306142801.10699.92658.Mailman@wolverine> Message-ID: On Thursday, March 6, 2003, Henrik Lefkowetz wrote: >Personally, I think the text reads better as-is, without breaking it >up. With respect to removing the reference to CHAP, I'm indifferent. Given that this is purely an editorial change, the opinion of the editor should be given deference, I think. If you believe that the old text reads better, then it is hard to justify making the change or removing the reference. Based on your recommendation, I would propose that instead we Reject the change. > I'd like to recommend that this change be accepted. Any objections? From aboba@internaut.com Thu Mar 6 18:28:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 10:28:47 -0800 (PST) Subject: [eap] Proposed resolution to Issue 92 Message-ID: I would propose that this change be accepted with modifications, as noted by Henrik and others, below. Comments? ------------------------------------------------------------------------- Issue 92: Integrity Protection Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 3, 2003 Document: EAP-01 Comment type: Technical Priority: 2 Section: 1.2 change: "Integrity protection This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses, and method-specific success and failure indications. When making this claim, a method specification MUST describe the fields within the EAP packet that are protected." to: "Integrity protection This refers to per-packet authentication of all EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the fields within the EAP packet that are authenticated." [Based on comments from Henrik, and others]: Revise to: "Integrity protection This refers to per-packet authentication and integrity protection of EAP packets, including EAP Requests and Responses. When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected." From aboba@internaut.com Thu Mar 6 18:46:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 10:46:36 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 Message-ID: Add as an Appendix: "Appendix A - Method Specific Behavior A.1 Message Integrity Checks Today, EAP methods commonly define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP methods such as EAP-TLS [RFC2716] define a MIC covering an extended PDU that could be split into multiple fragments, or that can cover portions of earlier messages (FINISHED message). Where the MIC covers more than one EAP packet,a validation failure typically needs to be considered a fatal error. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC, A MIC validation failure SHOULD be considered a fatal error and SHOULD be logged. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet. In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code')." From aboba@internaut.com Thu Mar 6 19:03:39 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 11:03:39 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 Message-ID: Replace section 4.2.1 with the following: "4.2.1 Strict Interpretation In order to decrease vulnerability to spoofing of EAP packets, including Success and Failure packets, EAP methods MAY indicate within their specification that they follow a "strict interpretation" from the point where an initial Request is answered with a Response of the same Type, until the method completes. An EAP method making use of "strict interpretation" MUST include a definition of completion for both the peer and authenticator, and also MUST indicate the conditions under which an EAP Failure or Success are accepted, and when they should be silently discarded. Methods supporting "strict interpretation" behave as follows: [a] On the peer, all EAP packets are silently discarded, except for those with Code=1 (Request) and Type=EAP-Method-Type. Methods supporting "strict interpretation" therefore MUST NOT support Identity requery or Notification. [b] On the authentication server (pass-through) or authenticator (non-pass-through), all EAP packets are silently discarded, except those with Code=2 (Response) and Type=EAP-Method-Type. Methods supporting "strict interpretation" MUST NOT send send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Note that authenticators operating in pass-through mode MUST NOT support "strict interpretation", since this would require method-specific knowledge." From jari.arkko@piuha.net Thu Mar 6 21:34:50 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 06 Mar 2003 23:34:50 +0200 Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: References: Message-ID: <3E67BEFA.40402@piuha.net> Ok for the rest, but the following still troubles me: > In this document, descriptions of EAP message handling > assume that per-packet MIC validation, where it occurs, > is effectively performed as though it occurs before > examining any of the EAP message fields (such as 'Code')." So, we first validate the MIC and only then look at the packet if it was even a Response, or for the right Identifier? Why? And I don't understand how this works. Assume I'm the peer who is running some method with per-packet MICs. I get a Failure, or a Request for another Type. But I ignore these and just proceed to verify the MIC? If the concern is avoidance of side effects on a packet that fails the MIC check, then maybe the following text might do it: "... is effectively performed as though it occurs before sending any responses or changing the state of the node which received the packet." Jari From jari.arkko@piuha.net Thu Mar 6 21:54:43 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 06 Mar 2003 23:54:43 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: References: Message-ID: <3E67C3A3.3030306@piuha.net> Bernard Aboba wrote: > I would like to propose that Issue 87 be resolved as follows: > > Change the text of Section 2.1 to the following: > > "An EAP conversation MAY utilize a sequence of methods. A common example > of this is an Identity request followed by a single EAP authentication > method such as an MD5-Challenge. However, within or associated with each > EAP server, a particular named peer SHOULD NOT utilize multiple > authentication methods (Type 4 or greater), either by > supporting a choice of methods or by using multiple methods in sequence. > This would make the peer vulnerable to attacks that negotiate the least > secure method from among a set (negotiation attacks, described in > Section 7.8) or man-in-the-middle attacks (described in Section 7.4). > Instead, for each named peer there SHOULD be an indication of exactly > one method used to authenticate that peer name. If a peer needs to make > use of different authentication methods under different circumstances, > then distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. I support this. The protocol is simpler, smaller likelihood of interoperability problems, well in line with original RFC 2284, etc. > If additional authentication methods are required beyond the initial > one, the authenticator MAY send a Request packet for a subsequent Is this MAY against the SHOULD NOT? If yes, you could just use a "may" and avoid the dueling keywords... > authentication method, or it MAY send another Identity request. If the > peer does not support additional methods, it SHOULD respond with a Nak, > indicating no acceptable alternative, as described in Section 5.3. > 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 sequence > in order to grant access, authentication failure is the correct result. > Therefore, it is not necessary for the authenticator to determine that > the peer supports sequences prior to sending a Request for a subsequent > authentication method. > > The above prescription also applies in the situation where an > authenticator sends a message of a different Type prior to completion of > the final round of a given method. If the peer wishes to continue > authenticating with the method in progress, it SHOULD send a Nak in > response to such a Request, indicating the Type in progress as the > alternative. Otherwise it MAY send a Response with the same Type as the > Request. Since an EAP packet with a different Type may be sent by an > attacker, an authenticator receiving a Nak including a preference for > the Type in progress SHOULD log the event, but otherwise not take any > action. > > Once a peer has sent a Response of the same Type as a Request, some > existing peer implementations might expect the method to run to > completion. As a result, these implementations silently discard EAP > Requests of a Type different from the method in progress, despite the > requirement for a Response in section 4.1. For this reason, EAP > authenticators that must interoperate with these peers are discouraged > from switching methods before the final round of a given method has > completed." The same may apply in some of the above as well. Jari From aboba@internaut.com Thu Mar 6 22:16:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 14:16:15 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: <3E67BEFA.40402@piuha.net> Message-ID: > If the concern is avoidance of side effects on a packet > that fails the MIC check, then maybe the following text > might do it: "... is effectively performed as though it occurs > before sending any responses or changing the state of the > node which received the packet." Yes, that is the concern (that the Id was updated even though the MIC check failed). Your text sounds fine. From henrik@levkowetz.com Thu Mar 6 23:48:52 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Mar 2003 00:48:52 +0100 Subject: [eap] "MIC" Message-ID: <20030307004852.76b07e9b.henrik@levkowetz.com> The following may be a general language issue with 2284bis, but I'm not sure, so I'll pose it as a question with a lead-in: Prompted by Bernard proposal of an Appendix section on Message Integrity Checks, and remembering Yoshihiro's reference to what RFC 2828 recommends with respect to this term (don't use it), I did a search through existing RFCs, and found that: "MIC" is used in 34 rfcs. The context is: email or MIME 22 counts GSS-API 6 counts generic 1 count FTP 1 count PGP 1 count FDDI 1 count The term is not used in RFC 2716 (PPP EAP TLS), and not in RFC 2246 (TLS). "..message integrity check.." occurs once in 2246, but it is not used as an established concept, exactly: "Message transport includes a message integrity check using a keyed MAC." So here is the question: Is the term MIC in broad use today when talking about integrity protecting checksums for EAP methods, so that it's use in 2284bis is simply a reflection of current practice; or is it just an expression which happened to be used at some early point in the life of 2284bis, and has been carried along without a great deal of deliberation? Henrik From aboba@internaut.com Thu Mar 6 22:34:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 14:34:35 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3E67C3A3.3030306@piuha.net> Message-ID: OK. How about this? "An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, a particular named peer SHOULD NOT utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator may send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. However, peer implementations MAY NOT respond at all, in which case a timeout will result and authentication will fail. As a result, use of sequences is likely to result in interoperability problems. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 4.1. For this reason, EAP authenticators SHOULD NOT switch methods before the final round of a given method has completed." From aboba@internaut.com Thu Mar 6 22:36:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 14:36:27 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: <3E67BEFA.40402@piuha.net> Message-ID: OK. How about this? Appendix A - Method Specific Behavior A.1 Message Integrity Checks Today, EAP methods commonly define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP methods such as EAP-TLS [RFC2716] define a MIC covering an extended PDU that could be split into multiple fragments, or that can cover portions of earlier messages (FINISHED message). Where the MIC covers more than one EAP packet,a validation failure typically needs to be considered a fatal error. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC, A MIC validation failure SHOULD be considered a fatal error and SHOULD be logged. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet. In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before sending any responses or changing the state of the host which received the packet." From aboba@internaut.com Fri Mar 7 00:31:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 16:31:16 -0800 (PST) Subject: [eap] Proposed resolution to Issue 95 Message-ID: Issue 95, given below, is really a duplicate of Issue 87. However, the current WG sentiment seems to be running toward *strengthening* the language against sequences, rather than weakening it. So this looks like a potential Reject to me. Any comments? ---------------------------------------------------------------------- Issue 95: Sequences Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: March 4, 2003 Document: EAP-01 Comment type: Technical Priority: S Section: 2.1 Rationale/Explanation of issue: Description implies that sequences are not supported. The rationale for this is security indications, and should be in the security section. Requested change: change: An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. 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 sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. to: An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. 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 sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. and rewrite the following and add to security section: However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. From aboba@internaut.com Fri Mar 7 00:49:06 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 16:49:06 -0800 (PST) Subject: [eap] Proposed resolution to Issue 94 Message-ID: In EAP-01, Section 2, change: " [3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed." to: " [3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed. EAP is a 'lock step' protocol, so that a new Request cannot be sent prior to receiving a valid Response." In RFC 2869bis, add the following text to Section 2.1: "EAP is a 'lock step' protocol, so that a new Request cannot be sent prior to receiving a valid Response." From aboba@internaut.com Fri Mar 7 01:02:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 17:02:18 -0800 (PST) Subject: [eap] Re: "MIC" In-Reply-To: <20030307014601.28182.93491.Mailman@wolverine> Message-ID: I believe that MAC is the recommended usage. However, EAP is often used in layer 2 authentication, where the term "MAC" could easily be confused with terms like "MAC address", "MAC layer", etc. For this reason, IEEE 802.1X and IEEE 802.11i have adopted the term "MIC" to refer to a message integrity check, rather than MAC. Since it is likely that one or more IEEE 802 groups will be referencing RFC 2284bis and 2869bis, we are respecting their choice of terms and are also using the term "MIC" instead of "MAC". On March 7, 2003, Henrik Levkowetz stated: > The following may be a general language issue with 2284bis, but I'm not sure, > so I'll pose it as a question with a lead-in: > > Prompted by Bernard proposal of an Appendix section on Message Integrity > Checks, and remembering Yoshihiro's reference to what RFC 2828 recommends > with respect to this term (don't use it), I did a search through existing > RFCs, and found that: > > "MIC" is used in 34 rfcs. The context is: > > email or MIME 22 counts > GSS-API 6 counts > generic 1 count > FTP 1 count > PGP 1 count > FDDI 1 count > > The term is not used in RFC 2716 (PPP EAP TLS), and not in RFC 2246 (TLS). > > "..message integrity check.." occurs once in 2246, but it is not used as > an established concept, exactly: "Message transport includes a message > integrity check using a keyed MAC." > > So here is the question: > > Is the term MIC in broad use today when talking about integrity protecting > checksums for EAP methods, so that it's use in 2284bis is simply a reflection > of current practice; or is it just an expression which happened to be used > at some early point in the life of 2284bis, and has been carried along > without a great deal of deliberation? > > > Henrik From jrv@umich.edu Fri Mar 7 02:19:56 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 06 Mar 2003 21:19:56 -0500 Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: References: Message-ID: <3056448.1046985594@[10.0.1.2]> Just to have one more round on this one - I prefer to not include integrity protection in the definition of integrity protection. I believe, perhaps incorrectly, that message authentication is the means of providing message integrity. Is there a different term that we could use instead of message integrity so we don't have a circular definition? -- John --On Thursday, March 6, 2003 10:28 AM -0800 Bernard Aboba wrote: > I would propose that this change be accepted with modifications, as noted > by Henrik and others, below. Comments? > > ------------------------------------------------------------------------- > Issue 92: Integrity Protection > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: March 3, 2003 > Document: EAP-01 > Comment type: Technical > Priority: 2 > Section: 1.2 > change: > > "Integrity protection > This refers to per-packet authentication and integrity > protection of EAP packets, including EAP Requests and > Responses, and method-specific success and failure > indications. > When making this claim, a method specification > MUST describe the fields within the EAP packet that are > protected." > > > to: > "Integrity protection > This refers to per-packet authentication of all EAP packets, > including EAP Requests and Responses. When making this claim, > a method specification MUST describe the fields within the EAP > packet that are authenticated." > > [Based on comments from Henrik, and others]: > > Revise to: > "Integrity protection > This refers to per-packet authentication and integrity > protection of EAP packets, including EAP Requests and > Responses. When making this claim, a method specification > MUST describe the EAP packets and fields within the EAP packet > that are protected." > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Fri Mar 7 02:26:00 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 06 Mar 2003 21:26:00 -0500 Subject: [eap] Re: Issue 90: Simplify introduction In-Reply-To: <20030306152723.0560e1d9.henrik@levkowetz.com> References: <20030306152723.0560e1d9.henrik@levkowetz.com> Message-ID: <3078395.1046985960@[10.0.1.2]> I think the discussion of pass thru and non pass thru builds the idea the two are somehow different. I don't think this is an important distinction for this document, and therefore think it should not be emphasized. I continue to think this change should be made. Perhaps we need to have more discussions on how important the distinction actually is. John --On Thursday, March 6, 2003 3:27 PM +0100 Henrik Levkowetz wrote: > On Wed, 5 Mar 2003 05:36:10 -0800 (PST) > Bernard Aboba wrote: > > > There had been some confusion about the behavior of authenticators in > > pass-through mode versus non-pass-through, and the clarification was > > added to address that. Removing the clarification as requested in this > > change seems like a bad idea since it would cause the specification to > > again become ambiguous. > > > > Comments? > > I would prefer to keep the text as is. I find it clear, it > reads well, and it makes it easy to continue into the document with > the understanding that both non-pass-through and pass-through operation > exist. > > Henrik > > > > > --------------------------------------------------------------------- > > Issue 90: Simplify Introduction > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: March 3, 2003 > > Document: EAP-01 > > Comment type: Technical > > Priority: S > > Section: 1 > > Rationale/Explanation of issue: > > change wording from middle of 3rd paragraph from: > > "Rather than requiring the authenticator to be updated to support each > > new authentication method, EAP permits the use of a backend > > authentication server which may implement some or all authentication > > methods, with the authenticator acting as a pass-through for some or > > all methods and users. > > > > Within this document, authenticator requirements apply regardless of > > whether the authenticator is operating as a pass-through or not. > > Where the requirement is meant to apply to either the authenticator > > or backend authentication server, depending on where the EAP > > authentication" > > > > to: > > "Rather than requiring the authenticator to be updated to support each > > new authentication method, EAP permits the authenticator to use a > > backend server to do the actual authentication method." > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > Henrik > > -- > Error message in Haiku form: > > Stay the patient course > Of little worth is your ire > The network is down > > -- David Ansel > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Fri Mar 7 02:34:05 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 06 Mar 2003 21:34:05 -0500 Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: References: Message-ID: <3107501.1046986445@[10.0.1.2]> I think this is fine, except for the last paragraph about pass thru authenticators, which I think should be deleted. Pass thru authenticators can act in the same way as you described in the first paragraphs - if RADIUS is the backend protocol then there would be changes to RADIUS to support it, but it could be done. Protocols other than RADIUS could do it in the future. I think this paragraph is best left to the EAP/RADIUS doc. John --On Thursday, March 6, 2003 11:03 AM -0800 Bernard Aboba wrote: > Replace section 4.2.1 with the following: > > "4.2.1 Strict Interpretation > > In order to decrease vulnerability to spoofing of EAP packets, > including Success and Failure packets, EAP methods MAY indicate > within their specification that they follow a "strict interpretation" > from the point where an initial Request is answered with a > Response of the same Type, until the method completes. > > An EAP method making use of "strict interpretation" MUST > include a definition of completion for both the peer > and authenticator, and also MUST indicate the conditions > under which an EAP Failure or Success are accepted, and > when they should be silently discarded. > > Methods supporting "strict interpretation" behave as follows: > > [a] On the peer, all EAP packets are silently discarded, except > for those with Code=1 (Request) and Type=EAP-Method-Type. Methods > supporting "strict interpretation" therefore MUST NOT support > Identity requery or Notification. > > [b] On the authentication server (pass-through) or > authenticator (non-pass-through), all EAP packets are > silently discarded, except those with Code=2 (Response) > and Type=EAP-Method-Type. Methods supporting "strict > interpretation" MUST NOT send send a Nak (legacy or > expanded) in reply to a Request, after an initial > non-Nak Response has been sent. > > Note that authenticators operating in pass-through mode > MUST NOT support "strict interpretation", since this > would require method-specific knowledge." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Fri Mar 7 02:53:58 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 06 Mar 2003 21:53:58 -0500 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: References: Message-ID: <3179076.1046987638@[10.0.1.2]> I believe that much of the discussion of appropriate use of methods belongs in the security considerations section of the document, not here. Here we should describe the behaviour of the protocol. Having a SHOULD NOT at this point and winking under the table that it is not a MUST NOT so and implementer could do something else is something of an end run. This paragraph implies that additional methods that support QoS or other non authentication methods are inappropriate. I feel pretty strongly that they are appropriate, and so find this wording in the main description of how the protocol works limiting. The same wording in the security considerations (with reference to the different types of methods, both authentication and non authentication methods) would be appropriate and would serve the same purpose. --On Thursday, March 6, 2003 2:34 PM -0800 Bernard Aboba wrote: > OK. How about this? > > "An EAP conversation MAY utilize a sequence of methods. A common example > of this is an Identity request followed by a single EAP authentication > method such as an MD5-Challenge. However, within or associated with each > EAP server, a particular named peer SHOULD NOT > utilize multiple authentication methods (Type 4 or greater), either by > supporting a choice of methods or by using multiple methods in sequence. > This would make the peer vulnerable to attacks that negotiate the least > secure method from among a set (negotiation attacks, described in > Section 7.8) or man-in-the-middle attacks (described in Section 7.4). > Instead, for each named peer there SHOULD be an indication of exactly > one method used to authenticate that peer name. If a peer needs to make > use of different authentication methods under different circumstances, > then distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. > > If additional authentication methods are required beyond the initial > one, the authenticator may send a Request packet for a subsequent > authentication method, or it MAY send another Identity request. If the > peer does not support additional methods, it SHOULD respond with a Nak, > indicating no acceptable alternative, as described in Section 5.3. > However, peer implementations MAY NOT respond at all, in which case a > timeout will result and authentication will fail. As a result, > use of sequences is likely to result in interoperability > problems. > > The above prescription also applies in the situation where an > authenticator sends a message of a different Type prior to completion of > the final round of a given method. If the peer wishes to continue > authenticating with the method in progress, it SHOULD send a Nak in > response to such a Request, indicating the Type in progress as the > alternative. Otherwise it MAY send a Response with the same Type as the > Request. Since an EAP packet with a different Type may be sent by an > attacker, an authenticator receiving a Nak including a preference for > the Type in progress SHOULD log the event, but otherwise not take any > action. > > Once a peer has sent a Response of the same Type as a Request, some > existing peer implementations might expect the method to run to > completion. As a result, these implementations silently discard EAP > Requests of a Type different from the method in progress, despite the > requirement for a Response in section 4.1. For this reason, EAP > authenticators SHOULD NOT switch methods before the final > round of a given method has completed." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Fri Mar 7 01:46:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 17:46:47 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3179076.1046987638@[10.0.1.2]> Message-ID: > Having a SHOULD NOT at this > point and winking under the table that it is not a MUST NOT so and > implementer could do something else is something of an end run. If you're arguing that the SHOULD NOT should be changed to MUST NOT, I would agree. Authentication sequences introduce considerable extra complexity and interoperability issues to the protocol that I would just as soon be rid of. From jsalowey@cisco.com Fri Mar 7 04:06:11 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 6 Mar 2003 20:06:11 -0800 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: Message-ID: <002401c2e45e$e3f4b880$0200000a@amer.cisco.com> Is the main reason why were are limiting this based on security considerations or is it that it will truly break the protocol state machine? If it is due to security considerations then I agree with John that it should be discussed in the security considerations section and not mandated in this section. There are ways to mitigate the risks of chaining (PEAP for example). If it is going to break the protocol state machine then SHOULD NOT is appropriate. I think chaining will happen in some cases. It looks like it will be required in PEAP and it probably will happen elsewhere. MUST NOT is too prohibitive in this case. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Thursday, March 06, 2003 5:47 PM > To: John Vollbrecht > Cc: Jari Arkko; eap@frascone.com > Subject: Re: [eap] Proposed resolution to Issue 87 > > > > Having a SHOULD NOT at this > > point and winking under the table that it is not a MUST NOT so and > > implementer could do something else is something of an end run. > > If you're arguing that the SHOULD NOT should be changed to > MUST NOT, I would agree. Authentication sequences introduce > considerable extra complexity and interoperability issues to > the protocol that I would just as soon be rid of. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Mar 7 04:24:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 20:24:30 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <002401c2e45e$e3f4b880$0200000a@amer.cisco.com> Message-ID: > Is the main reason why were are limiting this based on security > considerations or is it that it will truly break the protocol state > machine? Both, I think. The implementation survey shows no current implementations that support this, so that interoperability would be compromised. Also, introducing sequences complicates the state machine, and adds security vulnerabilities. Plus, the reasons that have been given for this "extension" (e.g. QoS negotiation) all seem to be out of scope of the EAP WG charter. Since the scope of RFC 2284bis is largely to *fix* interoperability problems, not to create them, it's hard to justify. > it will be required in PEAP and it probably will happen elsewhere. MUST > NOT is too prohibitive in this case. Why would this be required in PEAP? From the perspective of the EAP state machine, PEAP is a single EAP method. From jsalowey@cisco.com Fri Mar 7 05:50:24 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 6 Mar 2003 21:50:24 -0800 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: Message-ID: <002e01c2e46d$73021640$0200000a@amer.cisco.com> > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, March 06, 2003 8:25 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Proposed resolution to Issue 87 > > > > Is the main reason why were are limiting this based on security > > considerations or is it that it will truly break the protocol state > > machine? > > Both, I think. The implementation survey shows no current > implementations that support this, so that interoperability > would be compromised. Also, introducing sequences complicates > the state machine, and adds security vulnerabilities. Plus, > the reasons that have been given for this "extension" (e.g. > QoS negotiation) all seem to be out of scope of the EAP WG > charter. Since the scope of RFC 2284bis is largely to *fix* > interoperability problems, not to create them, it's hard to justify. > > > it will be required in PEAP and it probably will happen elsewhere. > > MUST NOT is too prohibitive in this case. > > Why would this be required in PEAP? From the perspective of > the EAP state machine, PEAP is a single EAP method.\] Yes, but EAP also runs within PEAP. > From jari.arkko@piuha.net Fri Mar 7 06:04:12 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 08:04:12 +0200 Subject: [eap] Proposed resolution to Issue 95 In-Reply-To: References: Message-ID: <3E68365C.2030404@piuha.net> Bernard Aboba wrote: > Issue 95, given below, is really a duplicate of Issue 87. However, the > current WG sentiment seems to be running toward *strengthening* the > language against sequences, rather than weakening it. So this looks like a > potential Reject to me. Any comments? I think so too. Jari From jari.arkko@piuha.net Fri Mar 7 06:10:43 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 08:10:43 +0200 Subject: [eap] Proposed resolution to Issue 94 In-Reply-To: References: Message-ID: <3E6837E3.3000201@piuha.net> Bernard, I'm fine with the changes you proposed. This makes the specification clear on the nature of the protocol. I'm not quite sure how clear this was in RFC 2284, but this needs to be clarified. You could perhaps call it tightening of the spec, but I think we *should* tighten the spec where we can and where there are no known implementations that would make use of the looseness of the original specification. Jari From jari.arkko@piuha.net Fri Mar 7 06:17:18 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 08:17:18 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <002e01c2e46d$73021640$0200000a@amer.cisco.com> References: <002e01c2e46d$73021640$0200000a@amer.cisco.com> Message-ID: <3E68396E.5010900@piuha.net> Joseph Salowey wrote: >>Why would this be required in PEAP? From the perspective of >>the EAP state machine, PEAP is a single EAP method.\] > > > Yes, but EAP also runs within PEAP. EAP runs both inside and outside PEAP. But I would expect these runs to be "independent" instantiations of the EAP state machine. Or do you actually perform one EAP run on the outside for PEAP, and then *multiple* methods inside, one after another? Jari From jari.arkko@piuha.net Fri Mar 7 06:21:53 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 08:21:53 +0200 Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: <3107501.1046986445@[10.0.1.2]> References: <3107501.1046986445@[10.0.1.2]> Message-ID: <3E683A81.6070209@piuha.net> John Vollbrecht wrote: > I think this is fine, except for the last paragraph about pass thru > authenticators, which I think should be deleted. Pass thru > authenticators can act in the same way as you described in the first > paragraphs - if RADIUS is the backend protocol then there would be > changes to RADIUS to support it, but it could be done. Protocols other > than RADIUS could do it in the future. I think this paragraph is best > left to the EAP/RADIUS doc. For what its worth, I think the statement adds value, because it points out a limitation in how the strict mode can be implemented. However, I do agree with you that we shouldn't be putting in keywords for these cases. I would suggest a compromise: s/MUST NOT/typically can not/. Would that work for you? Jari From npetroni@cs.umd.edu Fri Mar 7 06:41:20 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 01:41:20 -0500 (EST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: > If a per-packet MIC is employed within an EAP method, > then peers, authentication servers, and authenticators > not operating in pass-through mode MUST validate the MIC, > A MIC validation failure SHOULD be considered a fatal error > and SHOULD be logged. > > However, it is also possible to develop EAP methods > that support per-packet MICs, and > respond to verification failures by silently > discarding the offending packet. So we are saying that a MIC failure SHOULD end the conversation (isn't that what fatal error means?), but that you COULD discard instead? My current understanding would be that discard should be chosen over failure, but I am open to being convinced otherwise. nick From aboba@internaut.com Fri Mar 7 05:27:31 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 21:27:31 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: <3107501.1046986445@[10.0.1.2]> Message-ID: > I think this is fine, except for the last paragraph about pass thru > authenticators, which I think should be deleted. Pass thru authenticators > can act in the same way as you described in the first paragraphs - if > RADIUS is the backend protocol then there would be changes to RADIUS to > support it, but it could be done. Protocols other than RADIUS could do it > in the future. I think this paragraph is best left to the EAP/RADIUS doc. The problem is that in practice, authenticator implementations do not act this way -- and changing the spec to create "flexibility" would cause interoperability problems. From aboba@internaut.com Fri Mar 7 05:31:39 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 21:31:39 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: > So we are saying that a MIC failure SHOULD end the conversation (isn't > that what fatal error means?), but that you COULD discard instead? > My current understanding would be that discard should be chosen over > failure, but I am open to being convinced otherwise. RFC 2869 indicates sending a Reject as a SHOULD so I think we have to be consistent with that. While some might argue that discard would be a more appropriate choice, the main focus of RFC 2284bis and RFC 2869bis is to more clearly specify current practice, without breaking backward compatibility. From npetroni@cs.umd.edu Fri Mar 7 06:47:36 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 01:47:36 -0500 (EST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: Message-ID: > > I think this is fine, except for the last paragraph about pass thru > > authenticators, which I think should be deleted. Pass thru authenticators > > can act in the same way as you described in the first paragraphs - if > > RADIUS is the backend protocol then there would be changes to RADIUS to > > support it, but it could be done. Protocols other than RADIUS could do it > > in the future. I think this paragraph is best left to the EAP/RADIUS doc. > > The problem is that in practice, authenticator implementations do not act > this way -- and changing the spec to create "flexibility" would cause > interoperability problems. I don't understand why one would do this at all if it doesn't work in pass through. My understanding of the reason is to avoid DoS or other problems that occur from invalid packet injection. I would think almost any method implemented in non-passthrough would basically be extremely simple and not have the problem of getting additional requests in the middle of it anyway. Am I missing something? From aboba@internaut.com Fri Mar 7 05:40:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 21:40:36 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: Message-ID: > I don't understand why one would do this at all if it doesn't work in pass > through. My understanding of the reason is to avoid DoS or other problems > that occur from invalid packet injection. I would think almost any method > implemented in non-passthrough would basically be extremely simple and not > have the problem of getting additional requests in the middle of it > anyway. Am I missing something? The issue is that in pass-through authenticators keep very little state (the Identifier). They do not look at the Type and make sure they match. That's actually a *good* thing -- if they check Type codes, then we wouldn't have the ability to introduce expanded Nak, for example. So if you're going to do that kind of thing, it needs to be done on the authentication server or the peer. Authenticators are largely forwarding engines. From npetroni@cs.umd.edu Fri Mar 7 07:02:03 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 02:02:03 -0500 (EST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: Message-ID: ok, sorry I misread. It doesn't say it doesn't work in pass-through, it says AUTHENTICATORS don't do it in pass through, but rather the authentication server handles this. My bad. nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Thu, 6 Mar 2003, Bernard Aboba wrote: > > I don't understand why one would do this at all if it doesn't work in pass > > through. My understanding of the reason is to avoid DoS or other problems > > that occur from invalid packet injection. I would think almost any method > > implemented in non-passthrough would basically be extremely simple and not > > have the problem of getting additional requests in the middle of it > > anyway. Am I missing something? > > The issue is that in pass-through authenticators keep very little state > (the Identifier). They do not look at the Type and make sure they match. > > That's actually a *good* thing -- if they check Type codes, then we > wouldn't have the ability to introduce expanded Nak, for example. > > So if you're going to do that kind of thing, it needs to be done on the > authentication server or the peer. Authenticators are largely forwarding > engines. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Mar 7 05:51:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 21:51:59 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: Message-ID: I should also add that "strict interpretation" as it is proposed here is method-specific. That is, some methods may not require it, and others may. That means that a pass-through authenticator attempting to implement it would need method-specific knowledge -- it couldn't act the same way for each method. That's what makes it particularly hard to think of implementing this on a pass-through authenticator. Note that alternative approaches have been proposed that would work for *all* EAP methods. From some perspectives that approach could be said to be more consistent. But the complaint was that it would impose an extra round-trip on protocols such as EAP SIM, so that they could terminate "normally". As with everything else, we've got to find the balance between: a. Backward compatibility. b. Simplicity. c. Security. d. Existing and future EAP methods. From aboba@internaut.com Fri Mar 7 06:03:39 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 22:03:39 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: <3E683A81.6070209@piuha.net> Message-ID: > For what its worth, I think the statement adds value, because it > points out a limitation in how the strict mode can be implemented. > However, I do agree with you that we shouldn't be putting in keywords for > these cases. I would suggest a compromise: s/MUST NOT/typically can > not/. Would that work for you? We can certainly change the text to incorporate this (as below). But I think the bigger question is whether the "strict interpretation" advocated in this proposed resolution is the right way to go. In practice, my understanding is that some EAP methods do implement filters similar to the ones described here. On the other hand, some of the filtering (for Success/Failure in the middle, for example) is handled in the EAP layer. And of course, there are some implementations that do nothing. So the existing practice is all over the place. In addition to being somewhat complex, this proposed resolution really doesn't provide any guaranteed security properties -- it's all up to the method. That makes it hard to test an EAP implementation for compliance, particularly since the specs of existing EAP methods don't include any mention of "strict interpretation". -------------------------------------------------------------------------- Proposed resolution (rewrite of Section 4.2.1): "4.2.1 Strict Interpretation In order to decrease vulnerability to spoofing of EAP packets, including Success and Failure packets, EAP methods MAY indicate within their specification that they follow a "strict interpretation" from the point where an initial Request is answered with a Response of the same Type, until the method completes. An EAP method making use of "strict interpretation" MUST include a definition of completion for both the peer and authenticator, and also MUST indicate the conditions under which an EAP Failure or Success are accepted, and when they should be silently discarded. Methods supporting "strict interpretation" behave as follows: [a] On the peer, all EAP packets are silently discarded, except for those with Code=1 (Request) and Type=EAP-Method-Type. Methods supporting "strict interpretation" therefore MUST NOT support Identity requery or Notification. [b] On the authentication server (pass-through) or authenticator (non-pass-through), all EAP packets are silently discarded, except those with Code=2 (Response) and Type=EAP-Method-Type. [c] Peer methods supporting "strict interpretation" MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Note that authenticators operating in pass-through mode typically cannot support "strict interpretation", since this would require method-specific knowledge." From npetroni@cs.umd.edu Fri Mar 7 07:19:55 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 02:19:55 -0500 (EST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: So, to be clear, the state machine draft is explicitly wrong in this case. Methods should return methodState = FAIL instead of going to the discard state? This may be another problem of how to indicated different levels of requirements in the same state machine, but I am unclear how to resolve fatal error being preferred, but discard being allowed. Should the check be more complex such that in the METHOD state the MIC is checked AND a determination is made whether or not that failure is a fatal error? As an additional note, I understand the need for backwards compatibility, but to keep this as a SHOULD seems to imply to me that it's better to implement it this way in the future. I don't necessarily agree that it is and in the very least I think it would be nice to explain why failing on invalid MICs could lead to denial of service. Also, my understanding of why the Packet-Reject attribute was added in the first place is to be consistent with how the non-passthrough works (or should work). If that is the case, then since this appendix applies to both cases perhaps we should make that distinction? If that is not the case, then I think I am confused why Packet-Reject was created. comments welcome. nick On Thu, 6 Mar 2003, Bernard Aboba wrote: > > So we are saying that a MIC failure SHOULD end the conversation (isn't > > that what fatal error means?), but that you COULD discard instead? > > My current understanding would be that discard should be chosen over > > failure, but I am open to being convinced otherwise. > > RFC 2869 indicates sending a Reject as a SHOULD so I think we have > to be consistent with that. While some might argue that discard would be a > more appropriate choice, the main focus of RFC 2284bis and RFC 2869bis is > to more clearly specify current practice, without breaking backward compatibility. > > > From jrv@umich.edu Fri Mar 7 07:40:33 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 02:40:33 -0500 Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: <3E683A81.6070209@piuha.net> References: <3107501.1046986445@[10.0.1.2]> <3E683A81.6070209@piuha.net> Message-ID: <152707.1047004833@[10.0.1.2]> --On Friday, March 7, 2003 8:21 AM +0200 Jari Arkko wrote: > John Vollbrecht wrote: > > I think this is fine, except for the last paragraph about pass thru > > authenticators, which I think should be deleted. Pass thru > > authenticators can act in the same way as you described in the first > > paragraphs - if RADIUS is the backend protocol then there would be > > changes to RADIUS to support it, but it could be done. Protocols other > > than RADIUS could do it in the future. I think this paragraph is best > > left to the EAP/RADIUS doc. > > For what its worth, I think the statement adds value, because it > points out a limitation in how the strict mode can be implemented. > However, I do agree with you that we shouldn't be putting in keywords for > these cases. I would suggest a compromise: s/MUST NOT/typically can > not/. Would that work for you? > sure > Jari From aboba@internaut.com Fri Mar 7 06:26:50 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 6 Mar 2003 22:26:50 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: > Methods should return methodState = FAIL instead of going to the discard > state? Depends on whether you want to illustrate the more secure approach, or describe what implementations do today. One advantage of having the state machine be a separate document, is that you could conceivably say "this state machine chooses the most secure alternative when available, even if it is only a MAY." > This may be another problem of how to indicated different levels of > requirements in the same state machine, but I am unclear how to resolve > fatal error being preferred, but discard being allowed. Should the check be > more complex such that in the METHOD state the MIC is checked AND a > determination is made whether or not that failure is a fatal error? I think you have to put a stake in the sand and say "this is the approach we think the state machine should take." I would say that the state machine doesn't have to implement every conceivable option or exhibit every behavior. It just has to be consistent in its philosophy -- and upfront about what it is trying to do. > As an additional note, I understand the need for backwards compatibility, > but to keep this as a SHOULD seems to imply to me that it's better to > implement it this way in the future. Yes, that is a problem. Part of the issue is that in TLS a MIC failure is fatal, so it's hard to get around that in TLS-based methods: EAP TLS, TTLS, PEAP, etc. Is this another example of behavior that is really method-specific, and *not* handled in a consistent way by EAP and/or RADIUS? If so, then the answer is to say that the RADIUS implementation MAY send a Reject or MAY silently discard, depending on the requirements of the method in question. > I don't necessarily agree that it is > and in the very least I think it would be nice to explain why failing on > invalid MICs could lead to denial of service. Yes, I do think that is less robust than silent discard. > Also, my understanding of > why the Packet-Reject attribute was added in the first place is to be > consistent with how the non-passthrough works (or should work). Yes -- it was added to allow for silent discard where an authenticator in pass-through is present. An authenticator without pass-through can already silently discard invalid packets. > If that is > the case, then since this appendix applies to both cases perhaps we should > make that distinction? If that is not the case, then I think I am > confused why Packet-Reject was created. It probably should. Or we could change both RFC 2869bis and RFC 2284bis to make it clear that this is *not* a RADIUS decision, but rather a decision made by the EAP method. From Pasi.Eronen@nokia.com Fri Mar 7 07:58:56 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 09:58:56 +0200 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: <052E0C61B69C3741AFA5FE88ACC775A62CB41D@esebe023.ntc.nokia.com> > -----Original Message----- > From: ext Joseph Salowey [mailto:jsalowey@cisco.com] > Sent: Wednesday, March 05, 2003 8:24 PM > To: 'Puthenkulam, Jose P'; jari.arkko@piuha.net > Cc: jukka.ylitalo@lmf.ericsson.se; eap@frascone.com > Subject: RE: [eap] Review: draft-puthenkulam-eap-binding-01.txt ... > [Joe] Currently I am of the opinion that combined keys=20 > provides the best solution. Combined keys should provide the = potential=20 > to be stronger than either individual key. I need to think more about = > Jukka's > proposal. =20 I agree with you; using only the inner protocol keys for session key derivation would be weaker, and loses some good properties provided by tunnels, e.g. Perfect Forward Secrecy (PFS) in some cases. A tunneling scheme such as PEAP (fixed to provide some kind of cryptographic binding) could be used without server authentication in the tunnel (e.g. client doesn't verify the certificate at all, or uses anonymous-DH TLS cipher suite) to provide PFS for other EAP methods. For instance, it doesn't really matter that much if the EAP-SIM Kc keys are weak, or MS-CHAPv2 keys are vulnerable to dictionary attacks, if they are used together with the tunnel keys. Even if the tunneling does not perform server authentication, the attacker would have to break the "weak" keys in real-time, and also perform man-in-the-middle attack for the EAP conversation. This is much more difficult than simply recording some WLAN traffic and attacking it off-line. So, provided that the keys are combined properly, compound keys from both inner and outer methods is probably the best choice. Best regards, Pasi From jari.arkko@piuha.net Fri Mar 7 08:15:32 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 10:15:32 +0200 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A62CB41D@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A62CB41D@esebe023.ntc.nokia.com> Message-ID: <3E685524.8090805@piuha.net> Pasi.Eronen@nokia.com wrote: > keys are weak, or MS-CHAPv2 keys are vulnerable to dictionary attacks, > if they are used together with the tunnel keys. Even if the tunneling > does not perform server authentication, the attacker would have to > break the "weak" keys in real-time, and also perform man-in-the-middle > attack for the EAP conversation. This is much more difficult than > simply recording some WLAN traffic and attacking it off-line. Could you break this down a bit? I see that dictionary attacks could be a problem. But then again, you don't actually have to *break* the method in-real time. You just have to act as a mitm long enough to see what the parties exchange, and *then* you go off-line to perform the dictionary attack. So what is added here is the need to be a mitm. But I don't see how this adds the need to do things in real-time. Secondly, isn't there a distinction between weak keys and dictionary attacks? In the dictionary attack case you acquire the permanent credentials and can afterwards freely use the victim's account. This is valuable, even if you'd have to spend some time off-line first. But the weak key case appears somewhat different. You still have to do the attack fast if your intention is to gain access; once the user logs out or re-authenticates the attack is no longer possible. Of course, if you succeed in breaking the keys, this might give you an ability to read the packets that were exchanged. However, it isn't clear to me if the four-way handshake in 802.11i would prevent these attacks. Does it do Diffie-Hellman? > So, provided that the keys are combined properly, compound keys > from both inner and outer methods is probably the best choice. Ok. But are there any downsides to making the combination? Does it add a requirement to access generated master secrets from either the inner or outer method? Jari From npetroni@cs.umd.edu Fri Mar 7 08:18:44 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 03:18:44 -0500 (EST) Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: <3056448.1046985594@[10.0.1.2]> Message-ID: > Just to have one more round on this one - I prefer to not include integrity > protection in the definition of integrity protection. I believe, perhaps > incorrectly, that message authentication is the means of providing message > integrity. Is there a different term that we could use instead of message > integrity so we don't have a circular definition? I agree with John, the circular nature of this definition is an issue. Typically in security, integrity is one of the three primary services and includes both authentication and unauthorized modification. Practically speaking, when talking about message integrity, message authentication is roughly equated to "insuring" or "verifying" the integrity of messages. Since source authentication is closely related to message modification, I think it's sufficient to simply use "per-packet authentication" and remove "integrity protection" from the definition. However, if people would like to separate the concepts of source identification and message modification we could replace "integrity protection" with "protection against unauthorized modification or destruction of information" in the definition. These and other definitions can be found in the INFOSEC glossary at http://www.nstissc.gov/Assets/pdf/4009.pdf nick > > -- John > > --On Thursday, March 6, 2003 10:28 AM -0800 Bernard Aboba > wrote: > > > I would propose that this change be accepted with modifications, as noted > > by Henrik and others, below. Comments? > > > > ------------------------------------------------------------------------- > > Issue 92: Integrity Protection > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: March 3, 2003 > > Document: EAP-01 > > Comment type: Technical > > Priority: 2 > > Section: 1.2 > > change: > > > > "Integrity protection > > This refers to per-packet authentication and integrity > > protection of EAP packets, including EAP Requests and > > Responses, and method-specific success and failure > > indications. > > When making this claim, a method specification > > MUST describe the fields within the EAP packet that are > > protected." > > > > > > to: > > "Integrity protection > > This refers to per-packet authentication of all EAP packets, > > including EAP Requests and Responses. When making this claim, > > a method specification MUST describe the fields within the EAP > > packet that are authenticated." > > > > [Based on comments from Henrik, and others]: > > > > Revise to: > > "Integrity protection > > This refers to per-packet authentication and integrity > > protection of EAP packets, including EAP Requests and > > Responses. When making this claim, a method specification > > MUST describe the EAP packets and fields within the EAP packet > > that are protected." > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From Pasi.Eronen@nokia.com Fri Mar 7 08:46:24 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 10:46:24 +0200 Subject: [eap] Re: "MIC" Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612224A@esebe023.ntc.nokia.com> Sounds reasonable. Should we add this to terminology section? MIC terminoloy Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: March 7th, 2003 Reference:=20 Document: RFC2284bis Comment type: Editorial Priority: 2=20 Section: 1.2 Rationale/Explanation of issue: Add the following to terminology list: Message Integrity Code (MIC): A keyed hash function used to protect integrity of data. This is usually called a Message Authentication=20 Code (MAC), but IEEE 802 specifications (and this document) use the=20 acronym MIC to avoid confusion with Medium Access Control. Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, March 07, 2003 3:02 AM > To: eap@frascone.com > Subject: [eap] Re: "MIC" >=20 >=20 > I believe that MAC is the recommended usage. However, EAP is=20 > often used > in layer 2 authentication, where the term "MAC" could easily=20 > be confused > with terms like "MAC address", "MAC layer", etc. >=20 > For this reason, IEEE 802.1X and IEEE 802.11i have adopted=20 > the term "MIC" > to refer to a message integrity check, rather than MAC. Since=20 > it is likely > that one or more IEEE 802 groups will be referencing RFC 2284bis and > 2869bis, we are respecting their choice of terms and are also=20 > using the > term "MIC" instead of "MAC". From jari.arkko@piuha.net Fri Mar 7 08:48:39 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 10:48:39 +0200 Subject: [eap] Re: "MIC" In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612224A@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612224A@esebe023.ntc.nokia.com> Message-ID: <3E685CE7.2010806@piuha.net> Ok. > Sounds reasonable. Should we add this to terminology section? > > MIC terminoloy > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: March 7th, 2003 > Reference: > Document: RFC2284bis > Comment type: Editorial > Priority: 2 > Section: 1.2 > Rationale/Explanation of issue: > > Add the following to terminology list: > > Message Integrity Code (MIC): A keyed hash function used to protect > integrity of data. This is usually called a Message Authentication > Code (MAC), but IEEE 802 specifications (and this document) use the > acronym MIC to avoid confusion with Medium Access Control. From Pasi.Eronen@nokia.com Fri Mar 7 09:07:52 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 11:07:52 +0200 Subject: [eap] Re: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA45@esebe023.ntc.nokia.com> (See comments inline) > -----Original Message----- > From: ext John Vollbrecht [mailto:jrv@umich.edu] > Sent: Wednesday, March 05, 2003 4:53 PM > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > Subject: Re: [eap] RE: rfc2284bis issue ...=20 > > If none of these hold (method can fail in the middle but no > > internal failure message; multiple methods allowed; if one method > > fails, trying others is allowed), the client should either send a > > Response (if it permits the new method), or Nak it (so the server > > can propose something else), no matter if the previous method was > > completed or not. > > > I think this can be made to work in the state machine- it requires > changes but seems doable - as long as methods are single threaded, = i.e. > the authenticator doesn't send a request for a new method and=20 > continue the old. >=20 > But I wonder if this is good practice. Can a server=20 > negotiate down in the middle of a method? this seems particularly=20 > bad if client has negotiated to a mutual authentication method=20 > which is satisfactory to it, then the server is trying to "negotiate=20 > down". Is this "negotiating down" in the middle of a method any different from "negotiating down" after the method has completed (and failed)? After all, the server could always continue the current method to its end (and send intentionally invalid messages). Also, I think "negotiating down" is a policy issue. An active man-in-the-middle can always choose the negotiation result if multiple methods are allowed, so the client's and server's policy has to specify what methods are considered acceptable. EAP currently can't provide "ordering guarantees" for allowed methods (meaning that if methods A and B are allowed, and both parties would prefer A,=20 then A is actually used). Both parties have to take this into account when selecting what methods are acceptable. > > Methods in which the server can discover failure before the last > > message, and which don't have any internal "failure end of > > method" message include at least EAP-SIM, EAP-AKA and EAP-SRP. > > > > However, even if the method has an internal failure mechanism, > > silently discarding the message (cases 3-4 above) doesn't change > > the DoS situation significantly because the internal failure > > messages are not authenticated anyway in most cases > > (e.g. MS-CHAPv2, EAP-TLS alerts). > > > silent discard is not necessarily for DOS, but to make the=20 > state sequence "logical" - it refuses messages which logically=20 > should not be there. What you are suggesting is that logically=20 > they could be there, so we should talk about it and see if we agree. =20 > If so, the state machine can be changed. Very well put! Totally illegal messages (which couldn't have been sent by a party following the specs) can (and maybe should) be silently=20 discarded, but these messages actually could be there. BTW, this issue also applies to methods that "silently discard" messages with invalid MACs, such as EAP-SIM and EAP-AKA. The reason for wrong MAC could be that an attacker (trying to DoS) sent the message, but it could be simply that the authentication didn't work out. If the method silently discards the message, it's not possible to try some other method in the same EAP conversation. So, these methods can be really used only when the client and the server have only a single common allowed method. In many cases, having only a single allowed method in the policy is probably the best solution anyway. Should this common case be treated separately in the specs (it might simplify things)? Best regards, Pasi From Pasi.Eronen@nokia.com Fri Mar 7 09:40:26 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 11:40:26 +0200 Subject: [eap] Re: Proposed resolution to Issue 94 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612224B@esebe023.ntc.nokia.com> Looks good. To avoid any confusion, should we add "(however, retransmissions of the current Request are allowed)"? Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, March 07, 2003 2:49 AM > To: eap@frascone.com > Subject: [eap] Proposed resolution to Issue 94 >=20 >=20 > In EAP-01, Section 2, change: >=20 > " [3] The authenticator sends an additional Request packet, and the > peer replies with a Response. The sequence of Requests and > Responses continues as long as needed." >=20 > to: >=20 > " [3] The authenticator sends an additional Request packet, and the > peer replies with a Response. The sequence of Requests and > Responses continues as long as needed. EAP is a 'lock step' > protocol, so that a new Request cannot be sent prior to > receiving a valid Response." >=20 > In RFC 2869bis, add the following text to Section 2.1: >=20 > "EAP is a 'lock step' protocol, so that a new Request cannot=20 > be sent prior > to receiving a valid Response." From Pasi.Eronen@nokia.com Fri Mar 7 10:09:46 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 12:09:46 +0200 Subject: [eap] Re: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA47@esebe023.ntc.nokia.com> See comments inline. > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, March 07, 2003 10:16 AM > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: Re: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt >=20 > Pasi.Eronen@nokia.com wrote: >=20 >> keys are weak, or MS-CHAPv2 keys are vulnerable to dictionary = attacks, >> if they are used together with the tunnel keys. Even if the tunneling >> does not perform server authentication, the attacker would have to >> break the "weak" keys in real-time, and also perform = man-in-the-middle >> attack for the EAP conversation. This is much more difficult than >> simply recording some WLAN traffic and attacking it off-line. >=20 > Could you break this down a bit? I see that dictionary attacks > could be a problem. But then again, you don't actually have to > *break* the method in-real time. You just have to act as a mitm > long enough to see what the parties exchange, and *then* you > go off-line to perform the dictionary attack. So what is added > here is the need to be a mitm. But I don't see how this adds > the need to do things in real-time. >=20 > Secondly, isn't there a distinction between weak keys and > dictionary attacks? In the dictionary attack case you acquire > the permanent credentials and can afterwards freely use the > victim's account. This is valuable, even if you'd have to spend > some time off-line first. But the weak key case appears somewhat > different. You still have to do the attack fast if your intention > is to gain access; once the user logs out or re-authenticates > the attack is no longer possible. Of course, if you succeed > in breaking the keys, this might give you an ability to read > the packets that were exchanged. However, it isn't clear to > me if the four-way handshake in 802.11i would prevent these > attacks. Does it do Diffie-Hellman? You're right, I wasn't thinking clearly: there is an important distinction between weak long-term secrets and weak sessions keys produced by some methods. (In all cases, I'm assuming that the conversation is protected by an anonymous tunnel which does not=20 do server authentication). For weak long-term secrets, - If the inner protocol derives session keys from the long-term secret without PFS (e.g. MS-CHAPv2), and we use only the inner protocol=20 keys, even a passive attacker can mount a dictionary attack to get the long-term secret (he then also gets the session keys=20 since there is no PFS). - If combined keys are used, the attacker has to do a MitM attack on the tunnel (which is possible, since the tunnel is not =20 authenticated), but can do the dictionary attack against the long-term secret off-line (however, he doesn't get the session keys for this session). For strong long-term secrets but weak sessions keys,=20 - If we use only inner protocol keys, a passive attacker can do an off-line attack to get the session keys (but not the long-term = secret). - If we use combined keys, the attacker has to do a MiTM attack=20 on the tunnel (again, possible) AND break the keys in real-time (difficult) to get the session keys. The last case is relevant for e.g. EAP-SIM; the long-term Ki key can be assumed to be strong, but the Kc keys are (kind of) weak if the same SIM is also used for GSM. So, it seems that using combined keys=20 makes the attacker's work more difficult in all cases. The four-way handshake in 802.11i basically binds the keys to MAC addresses, and it does not do Diffie-Hellman (and so doesn't=20 provide PFS). >> So, provided that the keys are combined properly, compound keys >> from both inner and outer methods is probably the best choice. >=20 > Ok. But are there any downsides to making the combination? Does > it add a requirement to access generated master secrets from > either the inner or outer method? It requires access to some secret material from both inner and outer methods. But, in case of e.g. PEAP, it does not have=20 to be the TLS master secret; it could be output from the PRF=20 keyed with the master secret instead. Best regards, Pasi From Preetida.Vinayakray-Jani@nokia.com Fri Mar 7 10:27:14 2003 From: Preetida.Vinayakray-Jani@nokia.com (Preetida.Vinayakray-Jani@nokia.com) Date: Fri, 7 Mar 2003 12:27:14 +0200 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: see comment inline > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 07 March, 2003 10:16 > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: Re: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt >=20 >=20 > Pasi.Eronen@nokia.com wrote: >=20 > > keys are weak, or MS-CHAPv2 keys are vulnerable to=20 > dictionary attacks, > > if they are used together with the tunnel keys. Even if the=20 > tunneling > > does not perform server authentication, the attacker would have to > > break the "weak" keys in real-time, and also perform=20 > man-in-the-middle > > attack for the EAP conversation. This is much more difficult than > > simply recording some WLAN traffic and attacking it off-line. >=20 > Could you break this down a bit? I see that dictionary attacks > could be a problem. But then again, you don't actually have to > *break* the method in-real time. You just have to act as a mitm > long enough to see what the parties exchange, and *then* you > go off-line to perform the dictionary attack. So what is added > here is the need to be a mitm. But I don't see how this adds > the need to do things in real-time. >=20 > Secondly, isn't there a distinction between weak keys and > dictionary attacks? In the dictionary attack case you acquire > the permanent credentials and can afterwards freely use the > victim's account. This is valuable, even if you'd have to spend > some time off-line first. But the weak key case appears somewhat > different. You still have to do the attack fast if your intention > is to gain access; once the user logs out or re-authenticates > the attack is no longer possible. Of course, if you succeed > in breaking the keys, this might give you an ability to read > the packets that were exchanged. However, it isn't clear to > me if the four-way handshake in 802.11i would prevent these > attacks. Does it do Diffie-Hellman? As per IEEE802.11i Std. a 4 way key exchange handshake between AP and = STA not only mutually authenticates one another but also validates the = capabilities and ciphersuites - TKIP , AES etc. in a secure manner. = Supporting mutual authentication with improved privacy algorithms like = TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM = attack. =20 Preeti From jrv@umich.edu Fri Mar 7 13:27:23 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 08:27:23 -0500 Subject: [eap] Re: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA45@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA45@esebe023.ntc.nokia.com> Message-ID: <406267.1047025642@[10.0.1.2]> --On Friday, March 7, 2003 11:07 AM +0200 Pasi.Eronen@nokia.com wrote: > (See comments inline) > > > -----Original Message----- > > From: ext John Vollbrecht [mailto:jrv@umich.edu] > > Sent: Wednesday, March 05, 2003 4:53 PM > > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > > Subject: Re: [eap] RE: rfc2284bis issue > ... > > > If none of these hold (method can fail in the middle but no > > > internal failure message; multiple methods allowed; if one method > > > fails, trying others is allowed), the client should either send a > > > Response (if it permits the new method), or Nak it (so the server > > > can propose something else), no matter if the previous method was > > > completed or not. > > > > > I think this can be made to work in the state machine- it requires > > changes but seems doable - as long as methods are single threaded, i.e. > > the authenticator doesn't send a request for a new method and > > continue the old. > > > > But I wonder if this is good practice. Can a server > > negotiate down in the middle of a method? this seems particularly > > bad if client has negotiated to a mutual authentication method > > which is satisfactory to it, then the server is trying to "negotiate > > down". > > Is this "negotiating down" in the middle of a method any different > from "negotiating down" after the method has completed (and failed)? > After all, the server could always continue the current method to > its end (and send intentionally invalid messages). > I think it is not different, and I don't think it should normally be allowed after method completion. I suppose there might be cases where trying something different after a method fails would be ok but I haven't seen it. Perhaps I am missing your point. Are you suggesting that the method might want to send a Failure before all the possible steps are complete in order to terminate in fewer steps? I think this is a reasonable situation and could be handled by the state machine. > Also, I think "negotiating down" is a policy issue. An active > man-in-the-middle can always choose the negotiation result if multiple > methods are allowed, so the client's and server's policy has to > specify what methods are considered acceptable. EAP currently can't > provide "ordering guarantees" for allowed methods (meaning that if > methods A and B are allowed, and both parties would prefer A, > then A is actually used). Both parties have to take this into > account when selecting what methods are acceptable. > I agree with this as well. I do think policy must be used to decide which methods to use, and each chosen method must succeed. Is this what you mean? > > > Methods in which the server can discover failure before the last > > > message, and which don't have any internal "failure end of > > > method" message include at least EAP-SIM, EAP-AKA and EAP-SRP. > > > > > > However, even if the method has an internal failure mechanism, > > > silently discarding the message (cases 3-4 above) doesn't change > > > the DoS situation significantly because the internal failure > > > messages are not authenticated anyway in most cases > > > (e.g. MS-CHAPv2, EAP-TLS alerts). > > > > > silent discard is not necessarily for DOS, but to make the > > state sequence "logical" - it refuses messages which logically > > should not be there. What you are suggesting is that logically > > they could be there, so we should talk about it and see if we agree. > > If so, the state machine can be changed. > > Very well put! Totally illegal messages (which couldn't have been sent > by a party following the specs) can (and maybe should) be silently > discarded, but these messages actually could be there. > > BTW, this issue also applies to methods that "silently discard" > messages with invalid MACs, such as EAP-SIM and EAP-AKA. The reason > for wrong MAC could be that an attacker (trying to DoS) sent the > message, but it could be simply that the authentication didn't work > out. If the method silently discards the message, it's not possible to > try some other method in the same EAP conversation. So, these methods > can be really used only when the client and the server have only a > single common allowed method. > I think you are suggesting that one should be able to try a second method if the first one fails. This is being highly discouraged because of the negotiating down problem. Are there cases where this is expected to be the practice? > In many cases, having only a single allowed method in the policy is > probably the best solution anyway. Should this common case be treated > separately in the specs (it might simplify things)? > I am not sure how this would be done. Do you have a suggestion? > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Fri Mar 7 12:19:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 04:19:35 -0800 (PST) Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: Message-ID: OK. How about this? Integrity protection This refers to providing data origin authentication and protection against unauthorized modification of information for EAP packets (including EAP Requests and Responses). When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected. From aboba@internaut.com Fri Mar 7 12:40:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 04:40:38 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3E67C3A3.3030306@piuha.net> Message-ID: > I support this. The protocol is simpler, smaller likelihood of > interoperability problems, well in line with original RFC 2284, etc. > > Is this MAY against the SHOULD NOT? If yes, you could just use a > "may" and avoid the dueling keywords... > > The same may apply in this case as well. OK. How about this? "An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, a particular named peer SHOULD NOT utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator may send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. However, peer implementations may not respond, in which case a timeout will result and authentication will fail. As a result, use of authentication sequences is likely to result in interoperability problems. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations may expect the method to run to completion. These implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 4.1. For this reason, EAP authenticators SHOULD NOT switch methods before the final round of a given method has completed." From npetroni@cs.umd.edu Fri Mar 7 14:15:13 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 09:15:13 -0500 (EST) Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: Message-ID: This looks good to me. nick On Fri, 7 Mar 2003, Bernard Aboba wrote: > OK. How about this? > > Integrity protection > This refers to providing data origin authentication and protection > against unauthorized modification of information for EAP packets > (including EAP Requests and Responses). When making this claim, > a method specification MUST describe the EAP packets and fields > within the EAP packet that are protected. > > From aboba@internaut.com Fri Mar 7 13:02:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 05:02:56 -0800 (PST) Subject: [eap] Proposed resolution of Issue 80 In-Reply-To: Message-ID: Is this more clear? "4.2.1 Strict Interpretation In order to decrease vulnerability to spoofing of EAP packets, including Success packets, EAP methods MAY indicate within their specification that they follow a "strict interpretation" of EAP. When requested by a method, "strict interpretation" causes the EAP implementation to impose inbound filter rules from the point where an initial Request is answered with a Response of the same Type, until the method completes. "Strict interpretation" also implies that on completion the peer method will indicate whether it succeeded (was able to authenticate the authenticator) or failed (did not succeed in authenticating the authenticator). Unsuccessful method completion results in termination of EAP authentication and silent discard of EAP Success packets. An EAP method making use of "strict interpretation" MUST include a definition of completion for both the peer and authenticator, and also MUST indicate the conditions under which successful completion will be indicated. The filter rules are as follows: [a] On the peer, all EAP packets are silently discarded, except for those with Code=1 (Request) and Type=EAP-Method-Type. Therefore when "strict interpretation" is in effect, Identity requery or Notification cannot be supported. [b] On the authentication server (pass-through) or authenticator (non-pass-through), all EAP packets are silently discarded, except those with Code=2 (Response) and Type=EAP-Method-Type. [c] When "strict interpretation" is in effect, a peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Implementation note: Authenticators operating in pass-through mode cannot support "strict interpretation", since this would require that the authenticator be upgraded to support new methods." From aboba@internaut.com Fri Mar 7 13:27:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 05:27:18 -0800 (PST) Subject: [eap] Proposed resolution to Issue 83 In-Reply-To: Message-ID: I've updated the proposed resolution to Issue 83 (which also relates to Issue 74), to reflect your points. How does this look? "2.5 Invalid packets A RADIUS server receiving EAP-Message attribute(s) it does not understand MAY return an Access-Reject. In order for the RADIUS server to communicate that an invalid EAP packet has been received, but that the problem is non-fatal, an Access-Challenge containing a Service-Type=Packet-Reject MAY be sent. In some cases, the EAP method may make the determination of whether the error is fatal or non-fatal. A NAS compliant with this specification, on receiving an Access-Challenge with a Service-Type=Packet-Reject, SHOULD discard the current EAP packet, and check whether it has received additional EAP Response packets with an Identifier matching that of the last Request. If so, a new EAP Response packet, if available, MUST be sent to the RADIUS server within an Access-Request packet. In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the authenticator to allocate a finite Response buffer, and to discard packets according to an appropriate policy once that buffer has been exceeded. Once the RADIUS server responds with a packet containing a non-null EAP-Message attribute, the NAS updates the Identifier value, and any pending Responses that do not match this value can be discarded. If another EAP Response packet is not available, then the retransmission timer is reset and the NAS retransmits the outstanding Request to the peer. A NAS that does not support Service-Type=Packet-Reject behaves as specified in [RFC2865], Section 5.6: "A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead." From Pasi.Eronen@nokia.com Fri Mar 7 14:46:36 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 7 Mar 2003 16:46:36 +0200 Subject: [eap] RE: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA49@esebe023.ntc.nokia.com> > -----Original Message----- > From: ext John Vollbrecht [mailto:jrv@umich.edu] > Sent: Friday, March 07, 2003 3:27 PM > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > Subject: Re: [eap] Re: rfc2284bis issue ... > > In many cases, having only a single allowed method in the policy is > > probably the best solution anyway. Should this common case be = treated > > separately in the specs (it might simplify things)? >=20 > I am not sure how this would be done. Do you have a suggestion? We could specify a "recommended subset behavior" (something like=20 the "strict interpretation" proposed by Bernard) that is used when=20 the client or server only allows a single EAP method (and recommend=20 that this should be used, since the method negotiation in EAP is not secure). This would create a very simple state machine (MUCH simpler than the current one, which has to work with multiple methods).=20 The client state machine could look something like this (ignoring=20 retransmissions): Initialize: - request(type=3Didentity): send answer, stay here - request(type=3Dsupported type): go to Method state and use rule there - request(type=3Dother type): send Nak, stay here - timeout: go to Failure - silently discard everything else Method: - request(type=3Dsupported type): pass it to method. The method=20 returns exactly one of the following indications: - continue(answer): send answer, stay here [this is the normal case] - probable_success(answer): send answer, go to ProbableSuccess [this was the last message, and we're happy, but don't know yet if the server will be happy with our answer] - protected_success(answer): send answer, go to Success [the method knows that the server will be happy, too] - failure(optional_answer): send optional_answer, go to Failure [this will be used when the method sees no point in continuing] - discard: silently discard [the message wasn't OK, but the method wants to continue anyway,=20 in case the message was spoofed by an attacker] (note: probably a single method won't actually use all five) - timeout: go to Failure - silently discard everything else - discarding Failures works because even if it wasn't spoofed, we will timeout and fail anyway - discarding Successes works if there aren't any methods which have several possible success points - discarding other method types works, because we won't=20 support them anyway ProbableSuccess: - success: go to Success - failure: go to Failure - "link enabled" indication outside EAP: go to Success? - timeout: go to Success? - silently discard everything else Failure: end state Success: end state Do you think something like this would be worthwhile? If supporting exactly one EAP method is the most common case, it certainly would simplify life for implementors, instead of trying to navigate through all the MAYs and SHOULDs in the spec (the client state machine above does not have any alternatives to choose from, other than the indication received from EAP method). If this looks good, I could try to write something more coherent about this (and also try to figure out the server state machine)... Best regards, Pasi From aboba@internaut.com Fri Mar 7 13:42:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 05:42:13 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: Here is an update to the proposed resolution of Issue 74 to bring it in line with the updated resolution to Issue 83. What do you think? Appendix A - Method Specific Behavior A.1 Message Integrity Checks Today, EAP methods commonly define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP methods such as EAP-TLS [RFC2716] define a MIC covering an extended PDU that could be split into multiple fragments, or that can cover portions of earlier messages (FINISHED message). Where the MIC covers more than one EAP packet, a validation failure is typically considered a fatal error. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC. MIC validation failures SHOULD be logged. Whether a MIC validation failure is considered a fatal error or not is determined by the EAP method specification. Within EAP-TLS [RFC2716] a MIC validation failures is treated as a fatal error, since that is what is specified in TLS [RFC2246]. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet. In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before sending any responses or changing the state of the host which received the packet. From npetroni@cs.umd.edu Fri Mar 7 14:58:43 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 09:58:43 -0500 (EST) Subject: [eap] Proposed resolution to Issue 83 In-Reply-To: Message-ID: This looks good to me. On Fri, 7 Mar 2003, Bernard Aboba wrote: > I've updated the proposed resolution to Issue 83 (which also relates to > Issue 74), to reflect your points. How does this look? > > "2.5 Invalid packets > > A RADIUS server receiving EAP-Message attribute(s) it does not understand > MAY return an Access-Reject. In order for the RADIUS server to > communicate that an invalid EAP packet has been received, but > that the problem is non-fatal, an Access-Challenge containing a > Service-Type=Packet-Reject MAY be sent. In some cases, the EAP method may > make the determination of whether the error is fatal or non-fatal. > > A NAS compliant with this specification, on receiving an > Access-Challenge with a Service-Type=Packet-Reject, > SHOULD discard the current EAP packet, and check whether > it has received additional EAP Response packets with an > Identifier matching that of the last Request. If so, > a new EAP Response packet, if available, MUST be sent to the RADIUS server > within an Access-Request packet. In order to provide protection > against Denial of Service (DoS) attacks, it is advisable for > the authenticator to allocate a finite Response buffer, > and to discard packets according to an appropriate policy once > that buffer has been exceeded. > > Once the RADIUS server responds with a packet containing a > non-null EAP-Message attribute, the NAS updates the > Identifier value, and any pending Responses that do > not match this value can be discarded. If another EAP Response > packet is not available, then the retransmission timer is > reset and the NAS retransmits the outstanding Request to the peer. > > A NAS that does not support Service-Type=Packet-Reject behaves > as specified in [RFC2865], Section 5.6: > > "A NAS is not required to implement all of these service types, > and MUST treat unknown or unsupported Service-Types as though > an Access-Reject had been received instead." > > From npetroni@cs.umd.edu Fri Mar 7 15:07:31 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 10:07:31 -0500 (EST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: Message-ID: I think this works too. I think you have correctly characterized it as a method issue. nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Fri, 7 Mar 2003, Bernard Aboba wrote: > Here is an update to the proposed resolution of Issue 74 to bring it in > line with the updated resolution to Issue 83. What do you think? > > Appendix A - Method Specific Behavior > > A.1 Message Integrity Checks > > Today, EAP methods commonly define message integrity checks (MICs) > that cover more than one EAP packet. For example, > EAP methods such as EAP-TLS [RFC2716] define a MIC > covering an extended PDU that could be split > into multiple fragments, or that can cover portions of earlier > messages (FINISHED message). Where the MIC > covers more than one EAP packet, a validation failure > is typically considered a fatal error. > > If a per-packet MIC is employed within an EAP method, > then peers, authentication servers, and authenticators > not operating in pass-through mode MUST validate the MIC. > MIC validation failures SHOULD be logged. > Whether a MIC validation failure is considered a fatal error > or not is determined by the EAP method specification. > > Within EAP-TLS [RFC2716] a MIC validation failures is treated > as a fatal error, since that is what is specified in TLS [RFC2246]. > However, it is also possible to develop EAP methods > that support per-packet MICs, and > respond to verification failures by silently > discarding the offending packet. > > In this document, descriptions of EAP message handling > assume that per-packet MIC validation, where it occurs, > is effectively performed as though it occurs > before sending any responses or changing the state of the > host which received the packet. > > From jose.p.puthenkulam@intel.com Fri Mar 7 15:16:34 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 7 Mar 2003 07:16:34 -0800 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: >As per IEEE802.11i Std. a 4 way key exchange handshake between AP and STA >not only mutually authenticates one another but also validates the >capabilities and ciphersuites - TKIP , AES etc. in a secure manner. >Supporting mutual authentication with improved privacy algorithms like >TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM >attack. I'm not sure this is true. As the Mitm attack we are talking about is performed before the 802.11i layer gets keys, though it determines what keys it gets. So I don't see how the attack can be prevented by 802.11i. However I do agree that one may not be able to perform a Mitm attack at the link layer due to the reasons you describe. best regards, jose -----Original Message----- From: Preetida.Vinayakray-Jani@nokia.com [mailto:Preetida.Vinayakray-Jani@nokia.com] Sent: Friday, March 07, 2003 2:27 AM To: jari.arkko@piuha.net; Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt see comment inline > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 07 March, 2003 10:16 > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: Re: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt > > > Pasi.Eronen@nokia.com wrote: > > > keys are weak, or MS-CHAPv2 keys are vulnerable to > dictionary attacks, > > if they are used together with the tunnel keys. Even if the > tunneling > > does not perform server authentication, the attacker would have to > > break the "weak" keys in real-time, and also perform > man-in-the-middle > > attack for the EAP conversation. This is much more difficult than > > simply recording some WLAN traffic and attacking it off-line. > > Could you break this down a bit? I see that dictionary attacks > could be a problem. But then again, you don't actually have to > *break* the method in-real time. You just have to act as a mitm > long enough to see what the parties exchange, and *then* you > go off-line to perform the dictionary attack. So what is added > here is the need to be a mitm. But I don't see how this adds > the need to do things in real-time. > > Secondly, isn't there a distinction between weak keys and > dictionary attacks? In the dictionary attack case you acquire > the permanent credentials and can afterwards freely use the > victim's account. This is valuable, even if you'd have to spend > some time off-line first. But the weak key case appears somewhat > different. You still have to do the attack fast if your intention > is to gain access; once the user logs out or re-authenticates > the attack is no longer possible. Of course, if you succeed > in breaking the keys, this might give you an ability to read > the packets that were exchanged. However, it isn't clear to > me if the four-way handshake in 802.11i would prevent these > attacks. Does it do Diffie-Hellman? As per IEEE802.11i Std. a 4 way key exchange handshake between AP and STA not only mutually authenticates one another but also validates the capabilities and ciphersuites - TKIP , AES etc. in a secure manner. Supporting mutual authentication with improved privacy algorithms like TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM attack. Preeti _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From henrik@levkowetz.com Fri Mar 7 15:19:57 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Mar 2003 16:19:57 +0100 Subject: [eap] Re: "MIC" In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612224A@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612224A@esebe023.ntc.nokia.com> Message-ID: <20030307161957.37737a28.henrik@levkowetz.com> On Fri, 7 Mar 2003 10:46:24 +0200 wrote: Yes, I think this would be good. > > Sounds reasonable. Should we add this to terminology section? > > MIC terminoloy > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: March 7th, 2003 > Reference: > Document: RFC2284bis > Comment type: Editorial > Priority: 2 > Section: 1.2 > Rationale/Explanation of issue: > > Add the following to terminology list: > > Message Integrity Code (MIC): A keyed hash function used to protect > integrity of data. This is usually called a Message Authentication > Code (MAC), but IEEE 802 specifications (and this document) use the > acronym MIC to avoid confusion with Medium Access Control. > > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Friday, March 07, 2003 3:02 AM > > To: eap@frascone.com > > Subject: [eap] Re: "MIC" > > > > > > I believe that MAC is the recommended usage. However, EAP is > > often used > > in layer 2 authentication, where the term "MAC" could easily > > be confused > > with terms like "MAC address", "MAC layer", etc. > > > > For this reason, IEEE 802.1X and IEEE 802.11i have adopted > > the term "MIC" > > to refer to a message integrity check, rather than MAC. Since > > it is likely > > that one or more IEEE 802 groups will be referencing RFC 2284bis and > > 2869bis, we are respecting their choice of terms and are also > > using the > > term "MIC" instead of "MAC". > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Natural laws have no pity. From henrik@levkowetz.com Fri Mar 7 15:24:52 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Mar 2003 16:24:52 +0100 Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: References: Message-ID: <20030307162452.3ab39ebe.henrik@levkowetz.com> I agree. Henrik On Fri, 7 Mar 2003 09:15:13 -0500 (EST) Nick Petroni wrote: > This looks good to me. > > nick > > On Fri, 7 Mar 2003, Bernard Aboba wrote: > > > OK. How about this? > > > > Integrity protection > > This refers to providing data origin authentication and protection > > against unauthorized modification of information for EAP packets > > (including EAP Requests and Responses). When making this claim, > > a method specification MUST describe the EAP packets and fields > > within the EAP packet that are protected. > > From henrik@levkowetz.com Fri Mar 7 15:29:26 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Mar 2003 16:29:26 +0100 Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: References: Message-ID: <20030307162926.45f67178.henrik@levkowetz.com> The text reads well to me. Henrik On Fri, 7 Mar 2003 05:42:13 -0800 (PST) Bernard Aboba wrote: > Here is an update to the proposed resolution of Issue 74 to bring it in > line with the updated resolution to Issue 83. What do you think? > > Appendix A - Method Specific Behavior > > A.1 Message Integrity Checks > > Today, EAP methods commonly define message integrity checks (MICs) > that cover more than one EAP packet. For example, > EAP methods such as EAP-TLS [RFC2716] define a MIC > covering an extended PDU that could be split > into multiple fragments, or that can cover portions of earlier > messages (FINISHED message). Where the MIC > covers more than one EAP packet, a validation failure > is typically considered a fatal error. > > If a per-packet MIC is employed within an EAP method, > then peers, authentication servers, and authenticators > not operating in pass-through mode MUST validate the MIC. > MIC validation failures SHOULD be logged. > Whether a MIC validation failure is considered a fatal error > or not is determined by the EAP method specification. > > Within EAP-TLS [RFC2716] a MIC validation failures is treated > as a fatal error, since that is what is specified in TLS [RFC2246]. > However, it is also possible to develop EAP methods > that support per-packet MICs, and > respond to verification failures by silently > discarding the offending packet. > > In this document, descriptions of EAP message handling > assume that per-packet MIC validation, where it occurs, > is effectively performed as though it occurs > before sending any responses or changing the state of the > host which received the packet. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Timing has an awful lot to do with the outcome of a rain dance. From henrik@levkowetz.com Fri Mar 7 15:40:11 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 7 Mar 2003 16:40:11 +0100 Subject: [eap] Re: Issue 90: Simplify introduction In-Reply-To: <3078395.1046985960@[10.0.1.2]> References: <20030306152723.0560e1d9.henrik@levkowetz.com> <3078395.1046985960@[10.0.1.2]> Message-ID: <20030307164011.5bb69b9c.henrik@levkowetz.com> The way I see it, one important function of an introduction is to establish the *context* of the subject matter. Although operation in pass-through or not should be indistinguishable to the peer, it is very much a central part of the internal architecture of EAP implementations (if I've understood it all correctly :), and an awareness of this is essential to easy understanding of the rest of the document. Mentioning this here is a way to 'set the stage' so to speak, for the detailed description that follows. Not mentioning it would be to leave an essential part of the context out, making for a tougher read of the remainder of the document. Henrik. On Thu, 06 Mar 2003 21:26:00 -0500 John Vollbrecht wrote: > I think the discussion of pass thru and non pass thru builds the idea the > two are somehow different. I don't think this is an important distinction > for this document, and therefore think it should not be emphasized. I > continue to think this change should be made. Perhaps we need to have more > discussions on how important the distinction actually is. > > John > > --On Thursday, March 6, 2003 3:27 PM +0100 Henrik Levkowetz > wrote: > > > On Wed, 5 Mar 2003 05:36:10 -0800 (PST) > > Bernard Aboba wrote: > > > > > There had been some confusion about the behavior of authenticators in > > > pass-through mode versus non-pass-through, and the clarification was > > > added to address that. Removing the clarification as requested in this > > > change seems like a bad idea since it would cause the specification to > > > again become ambiguous. > > > > > > Comments? > > > > I would prefer to keep the text as is. I find it clear, it > > reads well, and it makes it easy to continue into the document with > > the understanding that both non-pass-through and pass-through operation > > exist. > > > > Henrik > > > > > > > > --------------------------------------------------------------------- > > > Issue 90: Simplify Introduction > > > Submitter name: John Vollbrecht > > > Submitter email address: jrv@umich.edu > > > Date first submitted: March 3, 2003 > > > Document: EAP-01 > > > Comment type: Technical > > > Priority: S > > > Section: 1 > > > Rationale/Explanation of issue: > > > change wording from middle of 3rd paragraph from: > > > "Rather than requiring the authenticator to be updated to support each > > > new authentication method, EAP permits the use of a backend > > > authentication server which may implement some or all authentication > > > methods, with the authenticator acting as a pass-through for some or > > > all methods and users. > > > > > > Within this document, authenticator requirements apply regardless of > > > whether the authenticator is operating as a pass-through or not. > > > Where the requirement is meant to apply to either the authenticator > > > or backend authentication server, depending on where the EAP > > > authentication" > > > > > > to: > > > "Rather than requiring the authenticator to be updated to support each > > > new authentication method, EAP permits the authenticator to use a > > > backend server to do the actual authentication method." > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > Henrik > > > > -- > > Error message in Haiku form: > > > > Stay the patient course > > Of little worth is your ire > > The network is down > > > > -- David Ansel > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Henrik -- Be wary of strong drink. It can make you shoot at tax collectors -- and miss. From aboba@internaut.com Fri Mar 7 14:42:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 06:42:02 -0800 (PST) Subject: [eap] Re: rfc2284bis issue In-Reply-To: <20030307152502.22089.38747.Mailman@wolverine> Message-ID: > This would create a very simple state machine (MUCH simpler than > the current one, which has to work with multiple methods). > The client state machine could look something like this (ignoring > retransmissions): This sounds interesting. Why don't you go ahead and write it up. Do you want time on the IETF 56 agenda to talk about this? From aboba@internaut.com Fri Mar 7 14:45:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 06:45:18 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <002401c2e45e$e3f4b880$0200000a@amer.cisco.com> Message-ID: On Thu, 6 Mar 2003, Joseph Salowey wrote: > If it is going to break the protocol state machine then SHOULD NOT is > appropriate. I think chaining will happen in some cases. It looks like > it will be required in PEAP and it probably will happen elsewhere. MUST > NOT is too prohibitive in this case. The case where chaining occurs within a tunneled method is also somewhat different in that there is a way of insuring backward compatibility -- an implementation that doesn't support that method also won't support sequences within it, and can Nak. If tunneling is the only application for sequences, then perhaps it really is appropriate to make sequences a MUST NOT, indicating tunneling as the exception, since backward compatibility is possible. As Pasi has been noting, this would potentially simplify the EAP state machine. From jrv@umich.edu Fri Mar 7 16:08:13 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 11:08:13 -0500 Subject: [eap] Proposed resolution to Issue 92 In-Reply-To: References: Message-ID: <510049.1047035293@[10.0.1.2]> good for me --On Friday, March 7, 2003 4:19 AM -0800 Bernard Aboba wrote: > OK. How about this? > > Integrity protection > This refers to providing data origin authentication and protection > against unauthorized modification of information for EAP packets > (including EAP Requests and Responses). When making this claim, > a method specification MUST describe the EAP packets and fields > within the EAP packet that are protected. From jrv@umich.edu Fri Mar 7 16:16:17 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 11:16:17 -0500 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: References: Message-ID: <539006.1047035775@[10.0.1.2]> --On Friday, March 7, 2003 4:40 AM -0800 Bernard Aboba wrote: > > I support this. The protocol is simpler, smaller likelihood of > > interoperability problems, well in line with original RFC 2284, etc. > > > > Is this MAY against the SHOULD NOT? If yes, you could just use a > > "may" and avoid the dueling keywords... > > > > The same may apply in this case as well. > > OK. How about this? I think this is fine except for the parenthetical (Type 4 or greater). I think there may be EAP methods that are not authentication methods that get assigned numbers greater than 4. If we agree that there may me methbods that are not auathentication methods and remove the parenthentical expression I think this would be good. John > > "An EAP conversation MAY utilize a sequence of methods. A common example > of this is an Identity request followed by a single EAP authentication > method such as an MD5-Challenge. However, within or associated with each > EAP server, a particular named peer SHOULD NOT > utilize multiple authentication methods (Type 4 or greater), either by > supporting a choice of methods or by using multiple methods in sequence. > This would make the peer vulnerable to attacks that negotiate the least > secure method from among a set (negotiation attacks, described in > Section 7.8) or man-in-the-middle attacks (described in Section 7.4). > Instead, for each named peer there SHOULD be an indication of exactly > one method used to authenticate that peer name. If a peer needs to make > use of different authentication methods under different circumstances, > then distinct identities SHOULD be employed, each of which identifies > exactly one authentication method. > > If additional authentication methods are required beyond the initial > one, the authenticator may send a Request packet for a subsequent > authentication method, or it MAY send another Identity request. If the > peer does not support additional methods, it SHOULD respond with a Nak, > indicating no acceptable alternative, as described in Section 5.3. > However, peer implementations may not respond, in which case a > timeout will result and authentication will fail. As a result, > use of authentication sequences is likely to result in interoperability > problems. > > The above prescription also applies in the situation where an > authenticator sends a message of a different Type prior to completion of > the final round of a given method. If the peer wishes to continue > authenticating with the method in progress, it SHOULD send a Nak in > response to such a Request, indicating the Type in progress as the > alternative. Otherwise it MAY send a Response with the same Type as the > Request. Since an EAP packet with a different Type may be sent by an > attacker, an authenticator receiving a Nak including a preference for > the Type in progress SHOULD log the event, but otherwise not take any > action. > > Once a peer has sent a Response of the same Type as a Request, some > existing peer implementations may expect the method to run to > completion. These implementations silently discard EAP > Requests of a Type different from the method in progress, despite the > requirement for a Response in section 4.1. For this reason, EAP > authenticators SHOULD NOT switch methods before the final > round of a given method has completed." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From yohba@tari.toshiba.com Fri Mar 7 16:30:33 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 7 Mar 2003 11:30:33 -0500 Subject: [eap] Re: Proposed resolution to Issue 94 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612224B@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612224B@esebe023.ntc.nokia.com> Message-ID: <20030307163033.GD795@catfish> Does the lock-step behavoir also apply to Notification message? And I think the lock-step behavoir does not apply to EAP Success/Failure message. Is this correct? Yoshihiro Ohba On Fri, Mar 07, 2003 at 11:40:26AM +0200, Pasi.Eronen@nokia.com wrote: > > Looks good. To avoid any confusion, should we add "(however, > retransmissions of the current Request are allowed)"? > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Friday, March 07, 2003 2:49 AM > > To: eap@frascone.com > > Subject: [eap] Proposed resolution to Issue 94 > > > > > > In EAP-01, Section 2, change: > > > > " [3] The authenticator sends an additional Request packet, and the > > peer replies with a Response. The sequence of Requests and > > Responses continues as long as needed." > > > > to: > > > > " [3] The authenticator sends an additional Request packet, and the > > peer replies with a Response. The sequence of Requests and > > Responses continues as long as needed. EAP is a 'lock step' > > protocol, so that a new Request cannot be sent prior to > > receiving a valid Response." > > > > In RFC 2869bis, add the following text to Section 2.1: > > > > "EAP is a 'lock step' protocol, so that a new Request cannot > > be sent prior > > to receiving a valid Response." > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jsalowey@cisco.com Thu Mar 6 04:59:10 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 5 Mar 2003 20:59:10 -0800 Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <2435408.1046902455@[10.0.1.2]> Message-ID: <001d01c2e39d$20544740$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of John Vollbrecht > Sent: Wednesday, March 05, 2003 7:14 PM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Re: Issue 92: Integrity Protection > > > > > --On Wednesday, March 5, 2003 3:58 PM -0800 Bernard Aboba > wrote: > > > > I think you are correct. It is impossible to have > integrity check > > > on success and failure messages. My understanding is > that these are > > > claims made for a method, not for eap as a whole. > > > > Right. But since the claims can't be made for Success and Failure > > packets, why change the text to say "all EAP packets" > instead of just > > "EAP Requests and Responses"? > > > I agree. take "all" out - how about changing the text to > > "Integrity protection > This refers to per-packet authentication of EAP Requests and > Responses. > When making this claim, a method specification MUST describe > the messages > in the Method and the fields in the messages that are authenticated." > > [Joe] does this refer to requests and responses that are part of the method? Does it include the identity request and response? I don't think you can protect the initial identity request/response either (although you may be able to protect subsequent ones) > -- John > > > > > > > > > > ------------------------------------------------------------------ > > > > --- > > > > ---- > > > > > > > > > > > > > > > > Issue 92: Integrity Protection > > > > Submitter name: John Vollbrecht > > > > Submitter email address: jrv@umich.edu > > > > Date first submitted: March 3, 2003 > > > > Document: EAP-01 > > > > Comment type: Technical > > > > Priority: 2 > > > > Section: 1.2 > > > > change: > > > > > > > > "Integrity protection > > > > This refers to per-packet authentication and integrity > protection > > > > of EAP packets, including EAP Requests and Responses, and > > > > method-specific success and failure indications. > > > > When making this claim, a method specification > > > > MUST describe the fields within the EAP packet that are > > > > protected." > > > > > > > > > > > > to: > > > > "Integrity protection > > > > This refers to per-packet authentication of all EAP packets, > > > > including EAP Requests and Responses. When making this claim, a > > > > method specification MUST describe the fields within the EAP > > > > packet that are authenticated." > > > > > > > > > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From npetroni@cs.umd.edu Fri Mar 7 17:52:41 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Fri, 7 Mar 2003 12:52:41 -0500 (EST) Subject: [eap] Re: Issue 92: Integrity Protection In-Reply-To: <001d01c2e39d$20544740$0200000a@amer.cisco.com> Message-ID: > [Joe] does this refer to requests and responses that are part of the > method? Does it include the identity request and response? I don't > think you can protect the initial identity request/response either > (although you may be able to protect subsequent ones) Since the text requires the method to describe which packets are protected, and the Identity method makes no such claims, I think this case is adequately covered by the wording. I have no problem with an explicit statement about identity/notification, however. On a related note, Identity messages could be included in mutliple-message MICs by a particular method if an implementation allowed it, although I am not sure I would consider this equivalent to integrity protection on those packets themselves. From aboba@internaut.com Fri Mar 7 17:24:23 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 09:24:23 -0800 (PST) Subject: [eap] Re: Propsed resolution to Issue 94 In-Reply-To: <20030307180002.28352.11775.Mailman@wolverine> Message-ID: On Friday, March 7, 2003, Yoshihiro Ohba wrote: > Does the lock-step behavior apply to Notification messages? I think so. That means, for example, that if a Request is sent and receives an invalid Response or no Response, that the authenticator can't send a Notification Request with an error message. It could send a Failure though (see below). > And I think the lock-step behavior does not apply to EAP Success/Failure > message. Is this correct? Right. If the authenticator sends a Request and it is not answered with a valid Response, an EAP Failure can be sent. From yohba@tari.toshiba.com Fri Mar 7 19:06:45 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 7 Mar 2003 14:06:45 -0500 Subject: [eap] Re: Propsed resolution to Issue 94 In-Reply-To: References: <20030307180002.28352.11775.Mailman@wolverine> Message-ID: <20030307190645.GE795@catfish> Then I'd like to suggest the following change from: "5.2 Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time. The peer MUST respond to a Notification Request with a Notification Response; a Nak Response MUST NOT be sent." to: "5.2 Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request. The peer MUST respond to a Notification Request with a Notification Response; a Nak Response MUST NOT be sent." Yoshihiro Ohba On Fri, Mar 07, 2003 at 09:24:23AM -0800, Bernard Aboba wrote: > On Friday, March 7, 2003, Yoshihiro Ohba wrote: > > > Does the lock-step behavior apply to Notification messages? > > I think so. That means, for example, that if a Request is sent and > receives an invalid Response or no Response, that the authenticator can't > send a Notification Request with an error message. It could send a Failure > though (see below). > > > And I think the lock-step behavior does not apply to EAP Success/Failure > > message. Is this correct? > > Right. If the authenticator sends a Request and it is not answered with a > valid Response, an EAP Failure can be sent. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Fri Mar 7 20:22:07 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 15:22:07 -0500 Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: References: Message-ID: <841032.1047050526@[10.0.1.2]> --On Friday, March 7, 2003 2:19 AM -0500 Nick Petroni wrote: > So, to be clear, the state machine draft is explicitly wrong in this case. > > Methods should return methodState = FAIL instead of going to the discard > state? > > This may be another problem of how to indicated different levels of > requirements in the same state machine, but I am unclear how to resolve > fatal error being preferred, but discard being allowed. Should the check > be more complex such that in the METHOD state the MIC is checked AND a > determination is made whether or not that failure is a fatal error? > Isn't this a case of what is specified for method, not for the state machine? If the method chooses to return a failure or a discard it can, and the state machine can handle it. We may want to ask if the state machine should handle the discard case, but that seems a separate question than whether the method should fail or continue on MIC failure. > As an additional note, I understand the need for backwards compatibility, > but to keep this as a SHOULD seems to imply to me that it's better to > implement it this way in the future. I don't necessarily agree that it is > and in the very least I think it would be nice to explain why failing on > invalid MICs could lead to denial of service. Also, my understanding of > why the Packet-Reject attribute was added in the first place is to be > consistent with how the non-passthrough works (or should work). If that is > the case, then since this appendix applies to both cases perhaps we should > make that distinction? If that is not the case, then I think I am > confused why Packet-Reject was created. > is the question whether there needs to be a distinction between passthru and non passthru given that we have the Packet Reject attribute which makes both work the same? > comments welcome. > > nick > > > On Thu, 6 Mar 2003, Bernard Aboba wrote: > > > > So we are saying that a MIC failure SHOULD end the conversation (isn't > > > that what fatal error means?), but that you COULD discard instead? > > > My current understanding would be that discard should be chosen over > > > failure, but I am open to being convinced otherwise. > > > > RFC 2869 indicates sending a Reject as a SHOULD so I think we have > > to be consistent with that. While some might argue that discard would > > be a more appropriate choice, the main focus of RFC 2284bis and RFC > > 2869bis is to more clearly specify current practice, without breaking > > backward compatibility. > > > > > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Fri Mar 7 20:29:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 07 Mar 2003 22:29:01 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <539006.1047035775@[10.0.1.2]> References: <539006.1047035775@[10.0.1.2]> Message-ID: <3E69010D.3040207@piuha.net> John Vollbrecht wrote: > > > --On Friday, March 7, 2003 4:40 AM -0800 Bernard Aboba > wrote: > >> > I support this. The protocol is simpler, smaller likelihood of >> > interoperability problems, well in line with original RFC 2284, etc. >> > >> > Is this MAY against the SHOULD NOT? If yes, you could just use a >> > "may" and avoid the dueling keywords... >> > >> > The same may apply in this case as well. >> >> OK. How about this? > > > I think this is fine except for the parenthetical (Type 4 or greater). > I think there may be EAP methods that are not authentication methods > that get assigned numbers greater than 4. If we agree that there may me > methbods that are not auathentication methods and remove the > parenthentical expression I think this would be good. What do you mean with non-authentication methods? Would these be (a) A new base EAP method, perhaps defined in bis of 2284bis at some point? Like a new, improved Identity? (b) Methods that don't authenticate but deliver some other information, maybe configuration information? I think (b) is out of scope for EAP. But (a) can certainly happen at some point. But if it does, wouldn't we update the statement in the paranthesis at the same time? Also, if we don't have the number 4 there, how would an implementation know whether a method Type X is "authentication" or "non-authentication"? Jari From jrv@umich.edu Fri Mar 7 21:31:35 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 16:31:35 -0500 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3E69010D.3040207@piuha.net> References: <539006.1047035775@[10.0.1.2]> <3E69010D.3040207@piuha.net> Message-ID: <996921.1047054693@[10.0.1.2]> --On Friday, March 7, 2003 10:29 PM +0200 Jari Arkko wrote: > John Vollbrecht wrote: > > > > > > --On Friday, March 7, 2003 4:40 AM -0800 Bernard Aboba > > wrote: > > > >> > I support this. The protocol is simpler, smaller likelihood of > >> > interoperability problems, well in line with original RFC 2284, etc. > >> > > >> > Is this MAY against the SHOULD NOT? If yes, you could just use a > >> > "may" and avoid the dueling keywords... > >> > > >> > The same may apply in this case as well. > >> > >> OK. How about this? > > > > > > I think this is fine except for the parenthetical (Type 4 or greater). > > I think there may be EAP methods that are not authentication methods > > that get assigned numbers greater than 4. If we agree that there may > > me methbods that are not auathentication methods and remove the > > parenthentical expression I think this would be good. > > What do you mean with non-authentication methods? Would these be > > (a) A new base EAP method, perhaps defined in bis of 2284bis > at some point? Like a new, improved Identity? > > (b) Methods that don't authenticate but deliver some > other information, maybe configuration information? > I am thinking of b. It is out of scope for 2284bis to define such a method, but since there is number space for a lot of new methods, some of them may be non authentication methods. > I think (b) is out of scope for EAP. But (a) can certainly happen > at some point. But if it does, wouldn't we update the statement > in the paranthesis at the same time? Also, if we don't have > the number 4 there, how would an implementation know whether > a method Type X is "authentication" or "non-authentication"? > It would know by configuring its rules/policy. For example, some instances might support only MD5, some might support either MD5 or LEAP, others might support PEAP/MD5 or TTLS/PAP, etc. The configurer would have to know whether the method was an authentication method or not. The method description should include whether it is an authentication method along with other information about the method. does this make sense? From aboba@internaut.com Fri Mar 7 22:43:33 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 14:43:33 -0800 (PST) Subject: [eap] Re: Propsed resolution to Issue 94 In-Reply-To: <20030307190645.GE795@catfish> Message-ID: Filed as Issue 96. On Fri, 7 Mar 2003, Yoshihiro Ohba wrote: > > Then I'd like to suggest the following change from: > > "5.2 Notification > > Description > > The Notification Type is optionally used to convey a displayable > message from the authenticator to the peer. An authenticator MAY > send a Notification Request to the peer at any time. The peer MUST > respond to a Notification Request with a Notification Response; a > Nak Response MUST NOT be sent." > > to: > > "5.2 Notification > > Description > > The Notification Type is optionally used to convey a displayable > message from the authenticator to the peer. An authenticator MAY > send a Notification Request to the peer at any time when there is > no outstanding Request. The peer MUST respond to a Notification > Request with a Notification Response; a Nak Response MUST NOT be > sent." > > Yoshihiro Ohba > > > On Fri, Mar 07, 2003 at 09:24:23AM -0800, Bernard Aboba wrote: > > On Friday, March 7, 2003, Yoshihiro Ohba wrote: > > > > > Does the lock-step behavior apply to Notification messages? > > > > I think so. That means, for example, that if a Request is sent and > > receives an invalid Response or no Response, that the authenticator can't > > send a Notification Request with an error message. It could send a Failure > > though (see below). > > > > > And I think the lock-step behavior does not apply to EAP Success/Failure > > > message. Is this correct? > > > > Right. If the authenticator sends a Request and it is not answered with a > > valid Response, an EAP Failure can be sent. > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From aboba@internaut.com Fri Mar 7 22:56:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 14:56:43 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 96 Message-ID: I would like to propose that we accept this proposed change. Any objections? ================================================================ Issue 96: Notification clarification Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: March 7, 2003 Reference: Document: EAP-02 Comment type: Technical Priority: S Section: 5.2 Rationale/Explanation of issue: I'd like to suggest the following change from: "5.2 Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time. The peer MUST respond to a Notification Request with a Notification Response; a Nak Response MUST NOT be sent." to: "5.2 Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request. The peer MUST respond to a Notification Request with a Notification Response; a Nak Response MUST NOT be sent." From aboba@internaut.com Fri Mar 7 23:03:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 15:03:21 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3E69010D.3040207@piuha.net> Message-ID: > I think (b) is out of scope for EAP. But (a) can certainly happen > at some point. But if it does, wouldn't we update the statement > in the paranthesis at the same time? Also, if we don't have > the number 4 there, how would an implementation know whether > a method Type X is "authentication" or "non-authentication"? The major reason that "authentication" and Type >4 was put in as a modifier was to allow a sequence involving Identity Request/Response and an authentication method, or even Identity Request/Response, auth method Request/Response and Notification Request/Response. If an implementation can't at least handle an Identity Request/Response and an auth method, it's pretty broken. I'm not sure about the last case though. If Notification can be sent at any time, or Identity can be requeried, then implementations need to be prepared to handle that. I'm not sure that the proposed language is very clear about these cases. From aboba@internaut.com Fri Mar 7 23:00:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 15:00:38 -0800 (PST) Subject: [eap] Proposed resolution to Issue 74 In-Reply-To: <841032.1047050526@[10.0.1.2]> Message-ID: > Isn't this a case of what is specified for method, not for the state > machine? If the method chooses to return a failure or a discard it can, > and the state machine can handle it. We may want to ask if the state > machine should handle the discard case, but that seems a separate question > than whether the method should fail or continue on MIC failure. Yes, that's right. It's not a decision for the authenticator or authentication server to make -- it's specified by the method. The new proposed resolutions for Issue 74 and 83 now reflect that. From aboba@internaut.com Fri Mar 7 23:10:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 15:10:38 -0800 (PST) Subject: [eap] Proposed resolution to Issue 80 In-Reply-To: <3E69010D.3040207@piuha.net> Message-ID: And while we're on the subject of issue 80, I have a basic question: Are Notifications used with any of the EAP methods defined in RFC 2284? I'm talking about EAP MD5-Challenge, OTP and GTC. RFC 2284 doesn't mention use of Notifications in any of those protocols, but doesn't preclude it either. The question came to mind because the concept of "strict interpretation" described in Issue 80 is method-specific. So naturally the question arose "Are the methods defined in RFC 2284 to be strictly interpreted? If so, what does completion mean?" Each of the RFC 2284-defined EAP methods is a Challenge/Response protocol, so there is only one Request and one Response within the method. Since the peer doesn't authenticate the authenticator, from it's point of view it is "done" once it sends the Response, but it has no idea whether to expect Success or Failure, so it will use either one. The question is: what do these methods do if they receive a packet other than a retransmission or Success or Failure after sending the Response? Note that one must be careful not to interpret the filter concept as prohibiting a response to a retransmitted Request. While it is possible to install the filter on the authenticator after receiving the first Response, I don't think that the filter can be installed on the peer after sending the first Response. After all, it might not get to the authenticator. So I think that there is a timing issue here -- installation on the peer probably has to wait until receipt of the Request that is liberated by the first Response. Of course this can be spoofed, sooo..... Hmmm. This is not as simple as we thought, is it? From jrv@umich.edu Sat Mar 8 00:37:24 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 07 Mar 2003 19:37:24 -0500 Subject: [eap] Proposed resolution to Issue 80 In-Reply-To: References: Message-ID: <1613482.1047065843@[10.0.1.2]> --On Friday, March 7, 2003 3:10 PM -0800 Bernard Aboba wrote: > And while we're on the subject of issue 80, I have a basic question: > > Are Notifications used with any of the EAP methods defined in RFC 2284? > I'm talking about EAP MD5-Challenge, OTP and GTC. RFC 2284 doesn't mention > use of Notifications in any of those protocols, but doesn't preclude it > either. The question came to mind because the concept of "strict > interpretation" described in Issue 80 is method-specific. So naturally the > question arose "Are the methods defined in RFC 2284 to be strictly > interpreted? If so, what does completion mean?" > > Each of the RFC 2284-defined EAP methods is a Challenge/Response protocol, > so there is only one Request and one Response within the method. Since the > peer doesn't authenticate the authenticator, from it's point of view it is > "done" once it sends the Response, but it has no idea whether to expect > Success or Failure, so it will use either one. > > The question is: what do these methods do if they receive a packet other > than a retransmission or Success or Failure after sending the Response? my suggestion is that strict interpretation only be set for the duration of the method. So, if the method is "done" after one response, there would be no point in setting the "strict interpretation" indicator. > Note that one must be careful not to interpret the filter concept as > prohibiting a response to a retransmitted Request. While it is possible to > install the filter on the authenticator after receiving the first > Response, I don't think that the filter can be installed on the peer after > sending the first Response. After all, it might not get to the > authenticator. presumable the retransmission rules are not affected by this since they are outside the method. If it sends a message and then gets a Req for the same id it just resends the message it send before. So I think that there is a timing issue here -- > installation on the peer probably has to wait until receipt of the Request > that is liberated by the first Response. Of course this can be spoofed, > sooo..... > > Hmmm. This is not as simple as we thought, is it? > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From paul@funk.com Sat Mar 8 00:46:06 2003 From: paul@funk.com (Paul Funk) Date: Fri, 07 Mar 2003 19:46:06 -0500 Subject: [eap] draft-funk-eap-md5-tunneled-00.txt Message-ID: <5.2.0.9.0.20030307194506.02cd3ad8@mail.funk.com> At the upcoming meeting, I'll be presenting a new EAP protocol which gets around the Man-in-the-Middle attack on tunneled protocols for CHAP and EAP-MD5-Challenge. The protocol, called EAP-MD5-Tunneled, allows a CHAP-equivalent authentication to occur inside a tunnel that is not vulnerable to MitM, but that is convertible to CHAP or EAP-MD5-Challenge for proxy purposes. The basic idea is that the MD5 digest is only partially performed by the client, and completed by the server. Normal CHAP that is intercepted by an attacker cannot be converted into credentials usable within this protocol. This draft won't be on the IETF site prior to the meeting due to the I-D blackout period. Here's a link to use in the meantime: http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt Paul From aboba@internaut.com Fri Mar 7 23:34:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 7 Mar 2003 15:34:34 -0800 (PST) Subject: [eap] Proposed resolution to Issue 80 In-Reply-To: <1613482.1047065843@[10.0.1.2]> Message-ID: > my suggestion is that strict interpretation only be set for the duration of > the method. So, if the method is "done" after one response, there would be > no point in setting the "strict interpretation" indicator. OK. So none of the methods defined in RFC 2284 support strict interpretation, right? From jari.arkko@piuha.net Sat Mar 8 07:53:33 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat, 08 Mar 2003 09:53:33 +0200 Subject: [eap] Re: Propsed resolution to Issue 94 In-Reply-To: References: Message-ID: <3E69A17D.6040808@piuha.net> On Fri, 7 Mar 2003, Yoshihiro Ohba wrote: >>"5.2 Notification >> >> Description >> >> The Notification Type is optionally used to convey a displayable >> message from the authenticator to the peer. An authenticator MAY >> send a Notification Request to the peer at any time when there is >> no outstanding Request. The peer MUST respond to a Notification >> Request with a Notification Response; a Nak Response MUST NOT be >> sent." Works for me. Jari From jari.arkko@piuha.net Sun Mar 9 10:27:23 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 09 Mar 2003 12:27:23 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <996921.1047054693@[10.0.1.2]> References: <539006.1047035775@[10.0.1.2]> <3E69010D.3040207@piuha.net> <996921.1047054693@[10.0.1.2]> Message-ID: <3E6B170B.8080601@piuha.net> John Vollbrecht wrote: >> What do you mean with non-authentication methods? Would these be >> >> (a) A new base EAP method, perhaps defined in bis of 2284bis >> at some point? Like a new, improved Identity? >> >> (b) Methods that don't authenticate but deliver some >> other information, maybe configuration information? >> > I am thinking of b. It is out of scope for 2284bis to define such a > method, but since there is number space for a lot of new methods, some > of them may be non authentication methods. > > >> I think (b) is out of scope for EAP. But (a) can certainly happen >> at some point. But if it does, wouldn't we update the statement >> in the paranthesis at the same time? Also, if we don't have >> the number 4 there, how would an implementation know whether >> a method Type X is "authentication" or "non-authentication"? >> > It would know by configuring its rules/policy. For example, some > instances might support only MD5, some might support either MD5 or LEAP, > others might support PEAP/MD5 or TTLS/PAP, etc. The configurer would > have to know whether the method was an authentication method or not. > The method description should include whether it is an authentication > method along with other information about the method. Yes. But regardless of the purpose of the methods, they suffer from the same interoperability problems, right? What you are suggesting above is a possible fix to the problem, but I worry about that fix because it appears to depend on configuration. Furthermore, if I plug in a non-authentication method to an EAP mux implementation using an API, I have no control over the capabilities of the MUX; I suspect current APIs would not have a flag telling the mux that the method is a "non-authentication method", nor would current implementations necessarily have support for dealing with the sequencing. Perhaps we will have non-authentication methods some day. I'm not fundamentally against them. I'm just saying that if we adopted non-authentication methods we should carefully discuss how to do them, in EAP or elsewhere, and if within EAP whether they should be some sort of attributes within authentication methods or individual methods. And, in the interest of getting RFC 2284 bis out of the door as soon as possible, let's not add new things, and let's try to keep the protocol as "tight" as possible so that we will get better interoperability. Jari From jari.arkko@piuha.net Sun Mar 9 10:27:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 09 Mar 2003 12:27:40 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: References: Message-ID: <3E6B171C.9010709@piuha.net> Bernard Aboba wrote: > The major reason that "authentication" and Type >4 was put in as a > modifier was to allow a sequence involving Identity Request/Response and > an authentication method, or even Identity Request/Response, auth method > Request/Response and Notification Request/Response. > > If an implementation can't at least handle an Identity Request/Response > and an auth method, it's pretty broken. I'm not sure about the last case > though. If Notification can be sent at any time, or Identity can be > requeried, then implementations need to be prepared to handle that. > > I'm not sure that the proposed language is very clear about these cases. You may be right about the text. How about changing An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, ... to An EAP conversation MAY utilize a sequence of methods. In addition to a single authentication method (Type 4 or greater), Identity requests and Notifications can be appear as discussed in Sections N.N and M.M. However, ... Jari From jrv@umich.edu Mon Mar 10 01:51:52 2003 From: jrv@umich.edu (John Vollbrecht) Date: Sun, 09 Mar 2003 20:51:52 -0500 Subject: [eap] RE: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA49@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA49@esebe023.ntc.nokia.com> Message-ID: <565392.1047243111@[10.0.1.2]> Pasi - I think the sequence you describe is close to what the state machine document is proposing. I would be interested in trying to demonstrate whether the scenario you suggest is possible with our state machine. I think what is required is to define the Policy functions (Policy.isSatisfied, Policy.allow, Policy.getNextMethod) and how they are initiated. let me know if you would like to pursue this John --On Friday, March 7, 2003 4:46 PM +0200 Pasi.Eronen@nokia.com wrote: > > > -----Original Message----- > > From: ext John Vollbrecht [mailto:jrv@umich.edu] > > Sent: Friday, March 07, 2003 3:27 PM > > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > > Subject: Re: [eap] Re: rfc2284bis issue > ... > > > In many cases, having only a single allowed method in the policy is > > > probably the best solution anyway. Should this common case be treated > > > separately in the specs (it might simplify things)? > > > > I am not sure how this would be done. Do you have a suggestion? > > We could specify a "recommended subset behavior" (something like > the "strict interpretation" proposed by Bernard) that is used when > the client or server only allows a single EAP method (and recommend > that this should be used, since the method negotiation in EAP is not > secure). > > This would create a very simple state machine (MUCH simpler than > the current one, which has to work with multiple methods). > The client state machine could look something like this (ignoring > retransmissions): > > Initialize: > - request(type=identity): send answer, stay here > - request(type=supported type): go to Method state and use rule there > - request(type=other type): send Nak, stay here > - timeout: go to Failure > - silently discard everything else > > Method: > - request(type=supported type): pass it to method. The method > returns exactly one of the following indications: > - continue(answer): send answer, stay here > [this is the normal case] > - probable_success(answer): send answer, go to ProbableSuccess > [this was the last message, and we're happy, but don't know yet > if the server will be happy with our answer] > - protected_success(answer): send answer, go to Success > [the method knows that the server will be happy, too] > - failure(optional_answer): send optional_answer, go to Failure > [this will be used when the method sees no point in continuing] > - discard: silently discard > [the message wasn't OK, but the method wants to continue anyway, > in case the message was spoofed by an attacker] > (note: probably a single method won't actually use all five) > - timeout: go to Failure > - silently discard everything else > - discarding Failures works because even if it wasn't spoofed, > we will timeout and fail anyway > - discarding Successes works if there aren't any methods which > have several possible success points > - discarding other method types works, because we won't > support them anyway > > ProbableSuccess: > - success: go to Success > - failure: go to Failure > - "link enabled" indication outside EAP: go to Success? > - timeout: go to Success? > - silently discard everything else > > Failure: end state > Success: end state > > > Do you think something like this would be worthwhile? If > supporting exactly one EAP method is the most common case, it > certainly would simplify life for implementors, instead of > trying to navigate through all the MAYs and SHOULDs in the spec > (the client state machine above does not have any alternatives > to choose from, other than the indication received from EAP > method). > > If this looks good, I could try to write something more > coherent about this (and also try to figure out the server > state machine)... > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Mon Mar 10 02:28:37 2003 From: jrv@umich.edu (John Vollbrecht) Date: Sun, 09 Mar 2003 21:28:37 -0500 Subject: [eap] Proposed resolution to Issue 80 In-Reply-To: References: Message-ID: <694721.1047245316@[10.0.1.2]> --On Friday, March 7, 2003 3:34 PM -0800 Bernard Aboba wrote: > > my suggestion is that strict interpretation only be set for the > > duration of the method. So, if the method is "done" after one > > response, there would be no point in setting the "strict > > interpretation" indicator. > > OK. So none of the methods defined in RFC 2284 support strict > interpretation, right? yes - that is my take as well From Pasi.Eronen@nokia.com Mon Mar 10 09:55:12 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 10 Mar 2003 11:55:12 +0200 Subject: [eap] Re: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA4C@esebe023.ntc.nokia.com> Hi John, Whether this can be implemented using the policy functions depends on whether we want to silently discard some messages or not. For example, Bernard's "strict interpretation" (and the "quick hack" state machine in my last e-mail) says that the client should - silently discard Success and Failure if we're in the=20 middle of a method and it shouldn't have happened - silently discard Requests for other types The current state machine in vollbrecht-eap-state-01 doesn't allow this (Failure messages can't be ignored, and requests for other methods are Nak'ed if we don't support that method). So, the question is, do we want to silently discard some messages or not? From the client's perspective, 1) Messages which could not have been sent by any sane=20 server can always be discarded. 2) If the message could have been sent by the real server,=20 we can (but not necessarily should; see below) silently=20 discard a message only if the end result will be=20 failure anyway (no matter if we discard it or process it). 3) If the message could have been sent by the real server,=20 and processing it could lead to success, then we can't=20 really discard it. Strictly from a protocol perspective, I think we should discard only messages in the first category (that shouldn't exist anyway). If silently discarding messages in the second category does actually prevent a DoS attack that would otherwise possible (or makes it more difficult by non-insignificant amount), then we maybe should discard them. But does discarding those messages actually change the DoS situation? In PPP or plain 802.1X, it seems the answer is "no" (a DoS is possible by sending non-EAP packets anyway). I'm not sure about 802.11i; it might, with certain EAP methods? (does anyone have more information about this?) If the answer to this question is "yes", then a separate state machine for clients and servers supporting only a single method might make sense, because such a state machine can better distinguish between messages in categories 2 (can be safely ignored) and 3 (cannot be ignored). This would be something like the "strict interpretation" proposed by Bernard, but it would not be specific to an EAP method. If the answer to the DoS question is "no, EAP can't do anything that significantly changes this; or any feasible EAP method can't distinguish 100% reliably between categories 2 and 3 anyway", then the situation is simplified considerably. We could forget the "strict interpretation" and the state machine in your I-D is basically OK.. BTW, there was a problem in the "quick hack" state machine in my last e-mail: some methods have points where they can either continue or succeed (e.g. generic token card), and the client doesn't know which. This required a small change (an additional method indication and a new state). I've also drawn a picture of it: http://www.cs.hut.fi/~peronen/simple_eap_statemachine.gif. Best regards, Pasi > -----Original Message----- > From: ext John Vollbrecht [mailto:jrv@umich.edu] > Sent: Monday, March 10, 2003 3:52 AM > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > Subject: Re: [eap] RE: rfc2284bis issue >=20 > Pasi - >=20 > I think the sequence you describe is close to what the state machine=20 > document is proposing. I would be interested in trying to=20 > demonstrate whether the scenario you suggest is possible with our=20 > state macchine. I think what is required is to define the Policy=20 > functions (Policy.isSatisfied, Policy.allow, Policy.getNextMethod) > and how they are initiated. >=20 > let me know if you would like to pursue this >=20 > John From jarkko@piuha.net Sun Mar 9 09:58:05 2003 From: jarkko@piuha.net (Jari Arkko) Date: Sun, 09 Mar 2003 11:58:05 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <996921.1047054693@[10.0.1.2]> References: <539006.1047035775@[10.0.1.2]> <3E69010D.3040207@piuha.net> <996921.1047054693@[10.0.1.2]> Message-ID: <3E6B102D.5080707@piuha.net> John Vollbrecht wrote: >> What do you mean with non-authentication methods? Would these be >> >> (a) A new base EAP method, perhaps defined in bis of 2284bis >> at some point? Like a new, improved Identity? >> >> (b) Methods that don't authenticate but deliver some >> other information, maybe configuration information? >> > I am thinking of b. It is out of scope for 2284bis to define such a > method, but since there is number space for a lot of new methods, some > of them may be non authentication methods. > > >> I think (b) is out of scope for EAP. But (a) can certainly happen >> at some point. But if it does, wouldn't we update the statement >> in the paranthesis at the same time? Also, if we don't have >> the number 4 there, how would an implementation know whether >> a method Type X is "authentication" or "non-authentication"? >> > It would know by configuring its rules/policy. For example, some > instances might support only MD5, some might support either MD5 or LEAP, > others might support PEAP/MD5 or TTLS/PAP, etc. The configurer would > have to know whether the method was an authentication method or not. > The method description should include whether it is an authentication > method along with other information about the method. Yes. But regardless of the purpose of the methods, they suffer from the same interoperability problems, right? What you are suggesting above is a possible fix to the problem, but I worry about that fix because it appears to depend on configuration. Furthermore, if I plug in a non-authentication method to an EAP mux implementation using an API, I have no control over the capabilities of the MUX; I suspect current APIs would not have a flag telling the mux that the method is a "non-authentication method", nor would current implementations necessarily have support for dealing with the sequencing. Perhaps we will have non-authentication methods some day. I'm not fundamentally against them. I'm just saying that if we adopted non-authentication methods we should carefully discuss how to do them, in EAP or elsewhere, and if within EAP whether they should be some sort of attributes within authentication methods or individual methods. And, in the interest of getting RFC 2284 bis out of the door as soon as possible, let's not add new things, and let's try to keep the protocol as "tight" as possible so that we will get better interoperability. Jari From jarkko@piuha.net Sun Mar 9 10:11:11 2003 From: jarkko@piuha.net (Jari Arkko) Date: Sun, 09 Mar 2003 12:11:11 +0200 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: References: Message-ID: <3E6B133F.4040308@piuha.net> Bernard Aboba wrote: > The major reason that "authentication" and Type >4 was put in as a > modifier was to allow a sequence involving Identity Request/Response and > an authentication method, or even Identity Request/Response, auth method > Request/Response and Notification Request/Response. > > If an implementation can't at least handle an Identity Request/Response > and an auth method, it's pretty broken. I'm not sure about the last case > though. If Notification can be sent at any time, or Identity can be > requeried, then implementations need to be prepared to handle that. > > I'm not sure that the proposed language is very clear about these cases. You may be right about the text. How about changing An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, ... to An EAP conversation MAY utilize a sequence of methods. In addition to a single authentication method (Type 4 or greater), Identity requests and Notifications can be appear as discussed in Sections N.N and M.M. However, ... Jari From jsalowey@cisco.com Mon Mar 10 17:50:48 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 10 Mar 2003 09:50:48 -0800 Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <3E68396E.5010900@piuha.net> Message-ID: <004d01c2e72d$95ca1a70$0200000a@amer.cisco.com> > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, March 06, 2003 10:17 PM > To: Joseph Salowey > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Proposed resolution to Issue 87 > > > Joseph Salowey wrote: > > >>Why would this be required in PEAP? From the perspective of > >>the EAP state machine, PEAP is a single EAP method.\] > > > > > > Yes, but EAP also runs within PEAP. > > EAP runs both inside and outside PEAP. But I would > expect these runs to be "independent" instantiations > of the EAP state machine. Or do you actually perform > one EAP run on the outside for PEAP, and then *multiple* > methods inside, one after another? > I would expect the runs inside and outside to be independent of one another, but inside PEAP you may have multiple mechanisms. For example PEAP(EAP-Identity --> EAP-MSCHAPv2 --> EAP-TLV(results, key binding,... ) ) > Jari > From aboba@internaut.com Mon Mar 10 17:42:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 10 Mar 2003 09:42:21 -0800 (PST) Subject: [eap] Proposed resolution to Issue 87 In-Reply-To: <004d01c2e72d$95ca1a70$0200000a@amer.cisco.com> Message-ID: > I would expect the runs inside and outside to be independent of one > another, but inside PEAP you may have multiple mechanisms. For example > > PEAP(EAP-Identity --> EAP-MSCHAPv2 --> EAP-TLV(results, key binding,... > ) ) Sure. This case is a bit different than general support for sequences, because: a. Sequences are enabled *only* within a specific method -- so that backward compatibility can be maintained. If a peer implementation doesn't support the method (and sequences) it can Nak. b. Presumably a solution will be offered to the man-in-the-middle problem in this context. It's not clear to me yet whether such a solution is possible in the general case. Without that, general support for sequences would create security vulnerabilities with no known fix. From Preetida.Vinayakray-Jani@nokia.com Tue Mar 11 09:13:59 2003 From: Preetida.Vinayakray-Jani@nokia.com (Preetida.Vinayakray-Jani@nokia.com) Date: Tue, 11 Mar 2003 11:13:59 +0200 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: > I'm not sure this is true. As the Mitm attack we are talking about is > performed before the 802.11i layer gets keys, though it=20 > determines what keys > it gets. So I don't see how the attack can be prevented by=20 > 802.11i. However > I do agree that one may not be able to perform a Mitm attack=20 > at the link > layer due to the reasons you describe. In my understanding - EAP usage within 802.11i does not show any strong = notion of STA-AS binding. And perhaps in order do so binding as well as = authentication must have some well established method. The reason I responded in previous message beca's discussion was = referring to 4 way handshake. 4 way handshake takes place between STA = and AP where messages 2 and 3 responds with PTK as well as indicates = that there is no man in the middle. However during 4 way handshake one = has to assume that AS is trusted 3rd party. So have I missed something or overlooked. If so then pl. let me know.=20 Regds, Preeti =20 > -----Original Message----- > From: ext Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: 07 March, 2003 17:17 > To: Vinayakray-Jani Preetida (NRC/Helsinki); 'jari.arkko@piuha.net'; > Eronen Pasi (NRC/Helsinki) > Cc: 'eap@frascone.com' > Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt >=20 >=20 > >As per IEEE802.11i Std. a 4 way key exchange handshake=20 > between AP and STA > >not only mutually authenticates one another but also validates the=20 > >capabilities and ciphersuites - TKIP , AES etc. in a secure manner.=20 > >Supporting mutual authentication with improved privacy=20 > algorithms like=20 > >TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM=20 > >attack. > I'm not sure this is true. As the Mitm attack we are talking about is > performed before the 802.11i layer gets keys, though it=20 > determines what keys > it gets. So I don't see how the attack can be prevented by=20 > 802.11i. However > I do agree that one may not be able to perform a Mitm attack=20 > at the link > layer due to the reasons you describe. >=20 > best regards, > jose >=20 >=20 > -----Original Message----- > From: Preetida.Vinayakray-Jani@nokia.com > [mailto:Preetida.Vinayakray-Jani@nokia.com]=20 > Sent: Friday, March 07, 2003 2:27 AM > To: jari.arkko@piuha.net; Pasi.Eronen@nokia.com > Cc: eap@frascone.com > Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt >=20 >=20 > see comment inline >=20 > > -----Original Message----- > > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > > Sent: 07 March, 2003 10:16 > > To: Eronen Pasi (NRC/Helsinki) > > Cc: eap@frascone.com > > Subject: Re: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt > >=20 > >=20 > > Pasi.Eronen@nokia.com wrote: > >=20 > > > keys are weak, or MS-CHAPv2 keys are vulnerable to=20 > > dictionary attacks, > > > if they are used together with the tunnel keys. Even if the=20 > > tunneling > > > does not perform server authentication, the attacker would have to > > > break the "weak" keys in real-time, and also perform=20 > > man-in-the-middle > > > attack for the EAP conversation. This is much more difficult than > > > simply recording some WLAN traffic and attacking it off-line. > >=20 > > Could you break this down a bit? I see that dictionary attacks > > could be a problem. But then again, you don't actually have to > > *break* the method in-real time. You just have to act as a mitm > > long enough to see what the parties exchange, and *then* you > > go off-line to perform the dictionary attack. So what is added > > here is the need to be a mitm. But I don't see how this adds > > the need to do things in real-time. > >=20 > > Secondly, isn't there a distinction between weak keys and > > dictionary attacks? In the dictionary attack case you acquire > > the permanent credentials and can afterwards freely use the > > victim's account. This is valuable, even if you'd have to spend > > some time off-line first. But the weak key case appears somewhat > > different. You still have to do the attack fast if your intention > > is to gain access; once the user logs out or re-authenticates > > the attack is no longer possible. Of course, if you succeed > > in breaking the keys, this might give you an ability to read > > the packets that were exchanged. However, it isn't clear to > > me if the four-way handshake in 802.11i would prevent these > > attacks. Does it do Diffie-Hellman? >=20 > As per IEEE802.11i Std. a 4 way key exchange handshake=20 > between AP and STA > not only mutually authenticates one another but also validates the > capabilities and ciphersuites - TKIP , AES etc. in a secure manner. > Supporting mutual authentication with improved privacy=20 > algorithms like TKIP > (IV with 48bit to reduce rekeying) AES in AP can prevent MitM attack. > =20 > Preeti > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jose.p.puthenkulam@intel.com Tue Mar 11 14:22:41 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Tue, 11 Mar 2003 06:22:41 -0800 Subject: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt Message-ID: >In my understanding - EAP usage within 802.11i does not show any strong notion of STA-AS binding. And perhaps in order do >so binding as well as authentication must have some well established method. I guess you may want to look at the IEEE 802.1X spec that defines usage of EAP for 802.11. EAP only provides STA-AS binding by virtue of authentication thru an EAP method. Hope this helps, best regards, jose > -----Original Message----- > From: Preetida.Vinayakray-Jani@nokia.com > [mailto:Preetida.Vinayakray-Jani@nokia.com] > Sent: Tuesday, March 11, 2003 1:14 AM > To: jose.p.puthenkulam@intel.com; jari.arkko@piuha.net; > Pasi.Eronen@nokia.com > Cc: eap@frascone.com > Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt > > > > I'm not sure this is true. As the Mitm attack we are > talking about is > > performed before the 802.11i layer gets keys, though it > > determines what keys > > it gets. So I don't see how the attack can be prevented by > > 802.11i. However > > I do agree that one may not be able to perform a Mitm attack > > at the link > > layer due to the reasons you describe. > > > In my understanding - EAP usage within 802.11i does not show > any strong notion of STA-AS binding. And perhaps in order do > so binding as well as authentication must have some well > established method. > > The reason I responded in previous message beca's discussion > was referring to 4 way handshake. 4 way handshake takes place > between STA and AP where messages 2 and 3 responds with PTK > as well as indicates that there is no man in the middle. > However during 4 way handshake one has to assume that AS is > trusted 3rd party. > > So have I missed something or overlooked. If so then pl. let me know. > > Regds, > Preeti > > > > > -----Original Message----- > > From: ext Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > > Sent: 07 March, 2003 17:17 > > To: Vinayakray-Jani Preetida (NRC/Helsinki); 'jari.arkko@piuha.net'; > > Eronen Pasi (NRC/Helsinki) > > Cc: 'eap@frascone.com' > > Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt > > > > > > >As per IEEE802.11i Std. a 4 way key exchange handshake > > between AP and STA > > >not only mutually authenticates one another but also validates the > > >capabilities and ciphersuites - TKIP , AES etc. in a > secure manner. > > >Supporting mutual authentication with improved privacy > > algorithms like > > >TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM > > >attack. > > I'm not sure this is true. As the Mitm attack we are > talking about is > > performed before the 802.11i layer gets keys, though it > > determines what keys > > it gets. So I don't see how the attack can be prevented by > > 802.11i. However > > I do agree that one may not be able to perform a Mitm attack > > at the link > > layer due to the reasons you describe. > > > > best regards, > > jose > > > > > > -----Original Message----- > > From: Preetida.Vinayakray-Jani@nokia.com > > [mailto:Preetida.Vinayakray-Jani@nokia.com] > > Sent: Friday, March 07, 2003 2:27 AM > > To: jari.arkko@piuha.net; Pasi.Eronen@nokia.com > > Cc: eap@frascone.com > > Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt > > > > > > see comment inline > > > > > -----Original Message----- > > > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > > > Sent: 07 March, 2003 10:16 > > > To: Eronen Pasi (NRC/Helsinki) > > > Cc: eap@frascone.com > > > Subject: Re: [eap] RE: Review: > draft-puthenkulam-eap-binding-01.txt > > > > > > > > > Pasi.Eronen@nokia.com wrote: > > > > > > > keys are weak, or MS-CHAPv2 keys are vulnerable to > > > dictionary attacks, > > > > if they are used together with the tunnel keys. Even if the > > > tunneling > > > > does not perform server authentication, the attacker > would have to > > > > break the "weak" keys in real-time, and also perform > > > man-in-the-middle > > > > attack for the EAP conversation. This is much more > difficult than > > > > simply recording some WLAN traffic and attacking it off-line. > > > > > > Could you break this down a bit? I see that dictionary attacks > > > could be a problem. But then again, you don't actually have to > > > *break* the method in-real time. You just have to act as a mitm > > > long enough to see what the parties exchange, and *then* you > > > go off-line to perform the dictionary attack. So what is added > > > here is the need to be a mitm. But I don't see how this adds > > > the need to do things in real-time. > > > > > > Secondly, isn't there a distinction between weak keys and > > > dictionary attacks? In the dictionary attack case you acquire > > > the permanent credentials and can afterwards freely use the > > > victim's account. This is valuable, even if you'd have to spend > > > some time off-line first. But the weak key case appears somewhat > > > different. You still have to do the attack fast if your intention > > > is to gain access; once the user logs out or re-authenticates > > > the attack is no longer possible. Of course, if you succeed > > > in breaking the keys, this might give you an ability to read > > > the packets that were exchanged. However, it isn't clear to > > > me if the four-way handshake in 802.11i would prevent these > > > attacks. Does it do Diffie-Hellman? > > > > As per IEEE802.11i Std. a 4 way key exchange handshake > > between AP and STA > > not only mutually authenticates one another but also validates the > > capabilities and ciphersuites - TKIP , AES etc. in a secure manner. > > Supporting mutual authentication with improved privacy > > algorithms like TKIP > > (IV with 48bit to reduce rekeying) AES in AP can prevent > MitM attack. > > > > Preeti > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From jose.p.puthenkulam@intel.com Tue Mar 11 14:48:44 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Tue, 11 Mar 2003 06:48:44 -0800 Subject: [eap] EAP support in smartcard version 01 Message-ID: Hi Pascal, I just happened to read your recent submittal. Your draft seems to define a solution for putting EAP in the smart card. But I guess its not clear what problem you are trying to solve? At least it was very difficult to understand from the draft. Somewhere in your Security Considerations section you mention "The nature of the Internet network does no longer require getting physical access to the smart card. Worms, Trojan horses or viruses can move to the computing platforms and performs the jobs. It is important for a reference implementation to provide the relevant level of protection for the new applications but not to create other flaws." If the smart card generates keys that can be picked up by viruses, what protection did you achieve by terminating EAP in the smart card. If the virus knows the keys for one session, what prevents it from knwoing the keys from subsequent sessions. best regards, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: Pascal Urien [mailto:urienp@libertysurf.fr] > Sent: Saturday, March 01, 2003 2:31 PM > To: eap@frascone.com > Subject: [eap] EAP support in smartcard version 01 > > > > Hi Every body, > > New version of the internet draft > > draft-urien-EAP-smartcard-01.txt - EAP support in smartcard > > has been dowloaded to the IETF web site. > > I hope to meet you again during the next IETF meetinf in SF > > Regards > > Pascal Urien > From henrik@levkowetz.com Tue Mar 11 15:12:29 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 11 Mar 2003 16:12:29 +0100 Subject: [eap] New intermediate Message-ID: <20030311161229.269144de.henrik@levkowetz.com> Hi, A new intermediate rfc2284bis draft is available at http://www.levkowetz.com/pub/ietf/drafts/eap/ , numbered -02.a . I've: Changed text in some definitions [Issue 91][Issue 92]. Added clarification that EAP is a 'lock step' protocol [Issue 94]. Added a new Appendix on Message Integrity Checks [Issue 74]. Regards, Henrik -- Man is not a rational animal, he is a rationalizing animal. From jrv@umich.edu Tue Mar 11 18:00:59 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Mar 2003 13:00:59 -0500 Subject: [eap] Re: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BA4C@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BA4C@esebe023.ntc.nokia.com> Message-ID: <524421.1047387630@[10.0.9.89]> Hello Pasi - Thanks for the response and the diagram. I think we are actually quite close and perhaps we should try to come up with a common state machine. There are differences to be talked through however. If you are interested we might want to try to have a conversation this week before ietf, or certainly at ietf. Our diagrams are in somewhat different styles. Ours is in 802 style, in which the actions are all in States, yours is more what i would expect, with actions associated with events on transitions between states. While I like yours better, I think the group wants to use the 8u2 style. It certainly helps with coordination with 802.1x an 802.11i state machines. So much for the formatting - more comments inline and at the end. ----------------------- --On Monday, March 10, 2003 11:55 AM +0200 Pasi.Eronen@nokia.com wrote: > > Hi John, > > Whether this can be implemented using the policy functions > depends on whether we want to silently discard some messages or > not. For example, Bernard's "strict interpretation" (and the > "quick hack" state machine in my last e-mail) says that the > client should > > - silently discard Success and Failure if we're in the > middle of a method and it shouldn't have happened > - silently discard Requests for other types > > The current state machine in vollbrecht-eap-state-01 doesn't > allow this (Failure messages can't be ignored, and requests for > other methods are Nak'ed if we don't support that method). > Failure is ignored if methodState is CON-SUCC. You are righat that the STRICT feature is not supported. My understanding of The proposal at the last conf call was to add an additional state or variable indicating strict-interpretation. Also at the DIALOG state add (if STRICT && currenttype!=prevtype) and transition to an new state NAK-CURRENT to send a NAK with current-type. Also change the failure condition to (if rxFailure && !(methodState==CON_SUCC !! methodState==STRICT). We will make a change and resend the diagram. > So, the question is, do we want to silently discard some > messages or not? From the client's perspective, > > 1) Messages which could not have been sent by any sane > server can always be discarded. > 2) If the message could have been sent by the real server, > we can (but not necessarily should; see below) silently > discard a message only if the end result will be > failure anyway (no matter if we discard it or process it). > 3) If the message could have been sent by the real server, > and processing it could lead to success, then we can't > really discard it. > > Strictly from a protocol perspective, I think we should discard > only messages in the first category (that shouldn't exist > anyway). If silently discarding messages in the second category > does actually prevent a DoS attack that would otherwise possible > (or makes it more difficult by non-insignificant amount), then > we maybe should discard them. I think these are good categories, and I agree with your conclusions. > > But does discarding those messages actually change the DoS > situation? In PPP or plain 802.1X, it seems the answer is "no" > (a DoS is possible by sending non-EAP packets anyway). I'm not > sure about 802.11i; it might, with certain EAP methods? (does > anyone have more information about this?) > I am not certain, but it seems the number of DOS attacks possible is large and this will not get rid of all of them. However one of the simplest is sending an EAP Failure. > If the answer to this question is "yes", then a separate state > machine for clients and servers supporting only a single method > might make sense, because such a state machine can better > distinguish between messages in categories 2 (can be safely > ignored) and 3 (cannot be ignored). This would be something like > the "strict interpretation" proposed by Bernard, but it would > not be specific to an EAP method. > > If the answer to the DoS question is "no, EAP can't do anything > that significantly changes this; or any feasible EAP method > can't distinguish 100% reliably between categories 2 and 3 > anyway", then the situation is simplified considerably. We could > forget the "strict interpretation" and the state machine in your > I-D is basically OK.. > > BTW, there was a problem in the "quick hack" state machine in my > last e-mail: some methods have points where they can either > continue or succeed (e.g. generic token card), and the client > doesn't know which. This required a small change (an additional > method indication and a new state). I've also drawn a picture > of it: http://www.cs.hut.fi/~peronen/simple_eap_statemachine.gif. > Yes - there may well be a need for the extra state. I think the same effect can be had in our state machine by assuming the method has two parts, and allowing the same method to continue using the policy.Allow function to describe what is allowed. Some overall comments 1. the diagram you present seems to deal only with strict interpretation. Is that your intent or am i missing something? 2. I am not clear how Requests and other messages that don't match policy.type are handled - are they silently discarded? I thought Requests would be NAK'd? 3. Are you using link-enabled and link-disabled as two separate signals. I assume these are meant to be "alternate indications"? 4. I think your "PROBABLE SUCCESS" and our "IDLE" states are pretty close, except that we allow another method to start if allowed by policy rather than only allowing success or failure. -- thanks again for the input. working this out would be much easier face to face, but this is good conversation. John > Best regards, > Pasi > > > -----Original Message----- > > From: ext John Vollbrecht [mailto:jrv@umich.edu] > > Sent: Monday, March 10, 2003 3:52 AM > > To: Eronen Pasi (NRC/Helsinki); eap@frascone.com > > Subject: Re: [eap] RE: rfc2284bis issue > > > > Pasi - > > > > I think the sequence you describe is close to what the state machine > > document is proposing. I would be interested in trying to > > demonstrate whether the scenario you suggest is possible with our > > state macchine. I think what is required is to define the Policy > > functions (Policy.isSatisfied, Policy.allow, Policy.getNextMethod) > > and how they are initiated. > > > > let me know if you would like to pursue this > > > > John > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jrv@umich.edu Wed Mar 12 03:27:18 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 11 Mar 2003 22:27:18 -0500 Subject: [eap] design-paper : policy functions and method selection Message-ID: <1988943.1047421638@[10.0.9.89]> The state machine presented by Nick Petroni and I included a set of "policy" functions which control how what the peer and authenticator/EAP server interact to select methods and determine if a dialog is successful. The following is a description of some possible "policy" functions and how the interoperate. Please comment or question. -- John Controlling EAP dialogs. The following describes possible scenarios for Authenticator (EAP server) and Peer. In the state machine these are driven by "Policy" functions in the Peer and Authenticator/EAP server. The intent of this is to show how different implementations of these functions on Peer and Authenticator/EAP server can interoperate. It also shows how the state machine is affected by this "policy" only at these function interfaces. ---------- Scenario 1 - single EAP method(m1)+ Identity on Peer and EAP server Peer Accepts request for Identity and for m1. It NAKS requests for any other methods. Does not require any authentication, but if any method fails in the Peer it will go to a local failure state and refuse to bring up the link. In this scenario the peer state machine "policy" functions will do the following Policy.allow checks the requested method against Identity and m1. If it is either, then the result is true, else false. Policy.isSatisfied is true if no method has failed, false if any method fails locally. EAP server Drives EAP dialog. Initiates Identity and then m1. Both must succeed for the dialog to succeed. The state machine "policy" functions for the authenticator will do the following Policy.getNextMetod returns Identity on first call, m1 on second call, NONE on third and subsequent calls. Policy.isSatisfied returns false until m1 succeeds. In this scenario a successful dialog will do 1. Identity 2. m1 - succeed 3. EAP Success ------------------ Scenario 2 - same as Scenario 1, except the EAP server has an additional method (m2) which it proposes before m1. If m2 is accepted it does not do m1. One method must be done and succeed for the dialog to succeed. Peer - same as Scenario 1 EAP server Drives EAP dialog. Initiates Identity and then m2. If m2 is NAK'd then it does m1. Identity and either m1 or m2 must succeed for the dialog to succeed. The state machine "policy" functions for the authenticator will do the following Policy.getNextMetod returns Identity on first call, m2 on second call. If m2 is NAK'd it returns m1 on the third call, else None. NONE on fourth and subsequent calls. Policy.isSatisfied returns false until m1 or m2 succeeds. In this scenario a successful dialog will 1. Identity 2. m2 - NAK 3. m1 - succeed 4.EAP Success ------- Scenario 3 - Same as Scenario 2 except Peer requires m1 to succeed on the peer to be successful Peer Accepts request for Identity and for m1. It NAKS requests for any other methods. Requires m1 to succeed to bring up its end of the link In this scenario the peer state machine "policy" functions will do the following Policy.allow checks the requested method against Identity and m1. If it is either, then the result is true, else false. Policy.isSatisfied is false until m1 succeeds In this scenario a successful dialog is the same as in scenario 2. However the peer now has a policy requiring a particular method (m1) to succeed before bringing up the link. This is a "simple" policy for a peer that requires a "mutual authentication" method. ---------- Scenario 4 - EAP server has a required and two optional methods in addition to the Identity. (Optional methods might be vendor specific configuration/provisioning support methods). Required method is m1. Optional methods are opt1 and opt2. Peer acts as in Scenario 3. EAP server Drives EAP dialog. Initiates Identity and then m1. Both must succeed for the dialog to succeed. The state machine "policy" functions for the authenticator will do the following Policy.getNextMetod returns Identity on first call, m1 on second call, opt1 on third, opt2 on fourth, None on fifth and subsequent calls. Policy.isSatisfied returns false until m1 succeeds and both opt1 and opt2 are proposed and do not fail(could be NAK'd). In this scenario a successful dialog is 1. Identity 2. m1 -succeeds 3. opt1 - NAK 4. opt2 - NAK 5. EAP Success ---------- More scenarios are possible, but the above are a beginning to show how different policies on authenticator and peer will work together. From Pasi.Eronen@nokia.com Wed Mar 12 14:35:02 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 12 Mar 2003 16:35:02 +0200 Subject: [eap] Re: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612224E@esebe023.ntc.nokia.com> Hello John, and thanks for a thoughtful message!=20 > Thanks for the response and the diagram. I think we are > actually quite close and perhaps we should try to come up with > a common state machine. There are differences to be talked > through however. If you are interested we might want to try > to have a conversation this week before ietf, or certainly at > ietf. Unfortunately, I'm not able to make it to IETF meeting next week, but let's continue this by e-mail. I think having a good state machine aligned with 2284bis is quite important, as aligning it might reveal some problems in 2284bis. E.g. do the new changes on sequences and "strict interpretation" really work? And what is really meant when the spec says MAY or SHOULD? (Hopefully the state machine will unambiguously specify what must be done in what circumstances, and the choice the implementor has to make is to simply initialize some policy variables according to circumstances). I ended up doing some reading on state machines (hmm, I didn't realize that somebody had actually written about them so much), so please bear with my rather lengthy comment about them :-) > Our diagrams are in somewhat different styles. Ours is in 802 > style, in which the actions are all in States, yours is more > what i would expect, with actions associated with events on > transitions between states. While I like yours better, I > think the group wants to use the 8u2 style. It certainly > helps with coordination with 802.1x an 802.11i state machines. I used the UML notation since I'm more familiar with it, but coordination with 802.* might be easier if we use the same notation, so it's OK to me (they are "equivalent enough" for our purposes, I guess). There are two differences, though.=20 The first is a minor semantic issue and probably won't matter. The second is more of "style issue", but might be=20 more important? The semantic issue is the following: In UML you can put procedures inside states or in transitions (I used only the latter), but they have different semantics. Procedures in transitions are called "actions", and they are completed before the transition has completely happened and next event is processed. Procedures inside states are called "activities": they start executing when the state is entered, but it is possible that new events arrive while the activity is running. If this results in leaving the state, the activity=20 is aborted. Quite obviously, the state machine will be much simpler to understand if we use only actions, and indeed, the procedures in 802 notation are actions in this sense. (The only possible candidate for an activity is the processing of EAP request for method; it might require user interaction.) The possibly more important issue is related to style.=20 Although the notations are both easy to understand, I had=20 some difficulties in comparing our state diagrams, and I kept wondering why this was so. Then, it occurred to me (I'm not an expert in this, so this might be obvious to you): In both notations, the state of the system is stored by a combination of the "box we're in" and specific named variables, and they can be combined in different ways without changing the semantics of the whole. It seems that the UML notation prefers boxes to named variables, and 802 notation does the opposite (though both notations allow both styles). I feel that we should prefer the boxes, since changes from one box to another are clearly shown (as arrows), but the named variables are more like global variables in=20 programming languages: difficult to follow. To take a concrete example, in my "quick hack" state machine picture, the two states "MethodCanContinue" and "MethodContinues" could be replaced by a single state "Method" and a named variable "canSucceed". Then the transition from Method->Success would have label "success && canSucceed" instead of just "success". Using a similar procedure, we could actually combine all the state boxes to one (except final states), with a spaghetti of variables. You can convert a 802 state diagram to UML notation by moving the procedures to the transitions (and then removing empty "transition states"). Consider what happens when you do this to the peer state machine in vollbrech-eap-state-01. All the state boxes except IDLE (and final states) disappear. (This is as expected; when the system is not running some procedure or moving along an arrow, it is always in IDLE state.) I think the diagram should be refactored into several different boxes (representing what the system expects or allows to happen next), removing some of the named variables in the process. This might lead to a clearer picture of the implications of "strict interpretation" and other suggested changes (e.g. what specific transitions are changed). Especially hiding important information into a "filter" or "policy" variables doesn't=20 sound like a good idea to me... This refactoring might be easier to do with the UML style,=20 since the style is more aligned with the "common ways of thinking" about the issue (and it does not generate=20 extra "transition states", and the "real states" and=20 transitions between them are more clearly shown).=20 When it's finished, we can convert it back to 802 notation without loss of information.=20 What do you think? Is refactoring the diagram a good idea? Then to other issues: >> But does discarding those messages actually change the DoS >> situation? In PPP or plain 802.1X, it seems the answer is >> "no" (a DoS is possible by sending non-EAP packets >> anyway). I'm not sure about 802.11i; it might, with certain >> EAP methods? (does anyone have more information about this?) > > I am not certain, but it seems the number of DOS attacks > possible is large and this will not get rid of all of them. > However one of the simplest is sending an EAP Failure. Hopefully there will be some discussion at IETF about this question (does silently discarding some messages give *non-insignificant* protection against DoS? And even if it's non-insignificant, is it worth the certainly=20 non-insignificant extra complexity?). > 1. the diagram you present seems to deal only with strict > interpretation. Is that your intent or am i missing something? > > 2. I am not clear how Requests and other messages that don't > match policy.type are handled - are they silently discarded? > I thought Requests would be NAK'd? No, the diagram is intended to work with all EAP methods, not just ones using "strict interpretation". It just takes the approach "silently discard whenever possible; i.e. discarding won't change the outcome". This applies to e.g. requests for other types once the supported type has been started. (Though since it was just a "quick hack", I haven't checked carefully that messages which could lead to success are never discarded.) The method-specific part of "strict interpretation" is embedded the indications: continues/can_continue, and probably_succeeded/ succeeded. For instance, the methods specified in RFC2284 don't support the strict interpretation, so they never send the "continues" indication. This means the state machine never ends up in the MethodContinues state, where Success packets are silently discarded. Ok, I'm not sure if this is the best way to handle this, but at least it makes the differences between methods visible in the state machine. Each method has to choose only when to send which indication. In a state machine supporting sequences, we might need even more different indications, like most_definitely_continues,=20 can_continue_or_succeed, can_continue_or_fail, and can_continue_or_succeed_or_fail. (All this is relevant,=20 of course, only if we see that silently discarding some=20 messages is worth the extra complexity). > 3. Are you using link-enabled and link-disabled as two > separate signals. I assume these are meant to be "alternate > indications"? Yes (and I should have called them that, instead of link-enabled/disabled). > 4. I think your "PROBABLE SUCCESS" and our "IDLE" states are > pretty close, except that we allow another method to start if > allowed by policy rather than only allowing success or > failure. Not really, since the "IDLE" state is the only "real" state box there is (see the comment about refactoring them earlier). But some refactoring might bring them to alignment. I hope you have some good discussions next week at IETF (I'm sorry I won't be there)! But let's continue this via e-mail.. Best regards,=20 Pasi From aboba@internaut.com Wed Mar 12 15:55:00 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Mar 2003 07:55:00 -0800 (PST) Subject: [eap] Updated draft URLS (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 12 Mar 2003 08:49:27 -0800 From: Joseph Salowey To: aboba@internaut.com Subject: Updated draft URLS Here are the URLs for updated drafts for the agenda: EAP Authorization http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-01.t xt Protected EAP TLV http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.tx t EAP Key Derivation for Multiple Applications http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt EAP SIM Authentication (not too much to say) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.tx t Joe From npetroni@cs.umd.edu Wed Mar 12 17:35:31 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Wed, 12 Mar 2003 12:35:31 -0500 (EST) Subject: [eap] Updated draft URLS (fwd) In-Reply-To: Message-ID: Here are the latest state machine URLS: http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt (without diagrams) and http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.ps (with diagrams) nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 12 Mar 2003, Bernard Aboba wrote: > > > ---------- Forwarded message ---------- > Date: Wed, 12 Mar 2003 08:49:27 -0800 > From: Joseph Salowey > To: aboba@internaut.com > Subject: Updated draft URLS > > Here are the URLs for updated drafts for the agenda: > > EAP Authorization > http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-01.t > xt > > Protected EAP TLV > http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.tx > t > > EAP Key Derivation for Multiple Applications > http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt > > EAP SIM Authentication (not too much to say) > http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.tx > t > > Joe > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Mar 12 16:58:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Mar 2003 08:58:32 -0800 (PST) Subject: [eap] EAP WG Agenda, IETF 56 Message-ID: EAP WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba Jari Arkko Monday, March 17, 2003 1530 - 1730 Afternoon Session II Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status RFC 2284bis, Henrik Levkowetz and Jari Arkko, 30 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt RFC 2869bis, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt Keying Framework (25 minutes) EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt EAP Key Derivation for Multiple Applications, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt Man-in-the-Middle Attacks (10 minutes) Compound Binding, Jose Puthekulam, 10 minutes http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt EAP Methods (Part 1), 20 minutes EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.txt Tunneled MD5, Paul Funk, 5 minutes http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt ====================================================================== Thursday, March 20, 2003 1530-1730 Afternoon Sessions II State Machine Issues (25 minutes) EAP State Machine, John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 minutes EAP Methods (Part 2) EAP SIM, Henry Haverinen, 10 minutes http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt EAP AKA, Jari Arkko, 10 minutes http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt EAP over CDMA2000, P. Agashe, 10 minutes http://www.ietf.org/internet-drafts/draft-pagashe-eapcdma2000-00.txt EAP GPRS, A. Salkintzis, 10 minutes http://www.ietf.org/internet-drafts/draft-salki-pppext-eap-gprs-00.txt EAP Authorization, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-01.txt Roadmap (20 minutes) IEEE 802.11 Liason Letter, Dorothy Stanley (if available), 10 minutes EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes From Pasi.Eronen@nokia.com Wed Mar 12 19:06:52 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 12 Mar 2003 21:06:52 +0200 Subject: [eap] Re: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122250@esebe023.ntc.nokia.com> (Yes, I know that replying to my own message is not=20 a good habit :-) Pasi Eronen wrote: > The semantic issue is the following: In UML you can put > procedures inside states or in transitions (I used only the > latter), but they have different semantics. Procedures in > transitions are called "actions", and they are completed before > the transition has completely happened and next event is > processed. Procedures inside states are called "activities": > they start executing when the state is entered, but it is > possible that new events arrive while the activity is > running. If this results in leaving the state, the activity=20 > is aborted. >=20 > Quite obviously, the state machine will be much simpler to > understand if we use only actions, and indeed, the procedures > in 802 notation are actions in this sense. (The only possible > candidate for an activity is the processing of EAP request for > method; it might require user interaction.) I just remembered, there is some text in 2284bis that sort of assumes that the processing of EAP request by method (or at least a part of it) is an "activity", not an "action": "If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response. If a peer receives a duplicate Request before it has sent a Response, but after it has determined the initial Request to be valid (i.e. it is waiting for user input), it MUST silently discard the duplicate Request. An EAP message may be found invalid for a variety of reasons: failed lower layer CRC or checksum, malformed EAP packet, EAP method MIC failure, etc." The good thing is that the activity is not actually interrupted, so we can work around it even in an 802-style state diagram=20 (e.g. check if any duplicates were received after the EAP method has finished processing the request, but before the response is sent). The current state machine doesn't do this, though. Best regards,=20 Pasi From aboba@internaut.com Wed Mar 12 21:04:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 12 Mar 2003 13:04:53 -0800 (PST) Subject: [eap] Issue 97: Strict interpretation Message-ID: This was originally part of Issue 80, but it is now separated out into its own issue to make discussion more manageable. ------------------------------------------------------------------- Issue 97: Strict interpretation Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 7, 2003 Reference: Document: EAP-01 Comment type: Technical Priority: S Section: 4.2.1 Rationale/Explanation of issue: John Vollbrecht has proposed tightening of the EAP state machine so as to preclude a number of possibilities, including changing Type in the middle of a method, and sending an EAP Success or Failure before a message is complete. As an alternative to that approach, a method-specific notion of "strict interpretation" is offered here. Proposed resolution (rewrite of Section 4.2.1): "4.2.1 Strict Interpretation In order to decrease vulnerability to spoofing of EAP packets, including Success packets, EAP methods MAY indicate within their specification that they follow a "strict interpretation" of EAP. When requested by a method, "strict interpretation" causes the EAP implementation to impose inbound filter rules from the point where an initial Request is answered with a Response of the same Type, until the method completes. "Strict interpretation" also implies that on completion the peer method will indicate whether it succeeded (was able to authenticate the authenticator) or failed (did not succeed in authenticating the authenticator). Unsuccessful method completion results in termination of EAP authentication and silent discard of EAP Success packets. An EAP method making use of "strict interpretation" MUST include a definition of completion for both the peer and authenticator, and also MUST indicate the conditions under which successful completion will be indicated. The filter rules are as follows: [a] On the peer, all EAP packets are silently discarded, except for those with Code=1 (Request) and Type=EAP-Method-Type. Therefore when "strict interpretation" is in effect, Identity requery or Notification cannot be supported. [b] On the authentication server (pass-through) or authenticator (non-pass-through), all EAP packets are silently discarded, except those with Code=2 (Response) and Type=EAP-Method-Type. [c] When "strict interpretation" is in effect, a peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Implementation note: None of the methods defined in this document support strict interpretation. Authenticators operating in pass-through mode cannot support "strict interpretation", since this would require that the authenticator be upgraded to support new methods." From aboba@internaut.com Thu Mar 13 13:07:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Mar 2003 05:07:07 -0800 (PST) Subject: [eap] EAP WG Agenda, IETF 56, Take 2 Message-ID: EAP WG Agenda, IETF 56, San Francisco Chairs: Bernard Aboba Jari Arkko Monday, March 17, 2003 1530 - 1730 Afternoon Session II Preliminaries (10 minutes) Bluesheets Minute Takers Agenda Bashing Document status IEEE 802.11 Liason Letter, Dorothy Stanley, 10 minutes RFC 2284bis, Henrik Levkowetz and Jari Arkko, 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt RFC 2869bis, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt Keying Framework (25 minutes) EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt EAP Key Derivation for Multiple Applications, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt Man-in-the-Middle Attacks (10 minutes) Compound Binding, Jose Puthenkulam, 10 minutes http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt EAP Methods (Part 1), 20 minutes EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.txt Tunneled MD5, Paul Funk, 5 minutes http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt ====================================================================== Thursday, March 20, 2003 1530-1730 Afternoon Sessions II State Machine Issues (25 minutes) EAP State Machine, John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 minutes EAP Methods (Part 2) EAP SIM, Henry Haverinen, 10 minutes http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt EAP AKA, Jari Arkko, 10 minutes http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt EAP over CDMA2000, P. Agashe, 10 minutes http://www.ietf.org/internet-drafts/draft-pagashe-eapcdma2000-00.txt EAP GPRS, A. Salkintzis, 10 minutes http://www.ietf.org/internet-drafts/draft-salki-pppext-eap-gprs-00.txt EAP Authorization, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-01.txt Roadmap (10 minutes) EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes From johan.rh.hermans@alcatel.be Thu Mar 13 15:09:25 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Thu, 13 Mar 2003 16:09:25 +0100 Subject: [eap] RFC2869bis-10 : is UserName required in an Access-Reject or not ? Message-ID: <3E709F25.4020007@alcatel.be> I found a type in draft10 : in section 2.1 (Protocol Overview), the draft mentions that a UserName attribute *must* be included in Access-Challenge, Access-Accept or Access-Reject packets, to help forwarding for EAP-unaware proxies. But in section 3.3. (Table of Attributes), username isn't allowed in an Access-Reject packet. Typo in the table ? -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From aboba@internaut.com Thu Mar 13 17:09:06 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 13 Mar 2003 09:09:06 -0800 (PST) Subject: [eap] Re: is UserName required in an Access-Reject or not? In-Reply-To: <20030313180002.13781.6324.Mailman@wolverine> Message-ID: Here's the text from RFC 2869: " In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name attribute and MUST include the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. NAS-Port or NAS-Port-Id SHOULD be included in the attributes issued by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP- Address MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes very difficult to manage." In RFC 2865, it indicates that User-Name is not permitted in the Access-Challenge or Access-Reject. So I think the answer is that the table is correct, and the text should be corrected to reflect the original RFC 2869 text. Does this make sense? > Message: 5 > Date: Thu, 13 Mar 2003 16:09:25 +0100 > From: Jo Hermans > To: eap@frascone.com > Subject: [eap] RFC2869bis-10 : is UserName required in an Access-Reject or not ? > > I found a type in draft10 : in section 2.1 (Protocol Overview), the > draft mentions that a UserName attribute *must* be included in > Access-Challenge, Access-Accept or Access-Reject packets, to help > forwarding for EAP-unaware proxies. But in section 3.3. (Table of > Attributes), username isn't allowed in an Access-Reject packet. Typo in > the table ? > > -- > Jo Hermans > > There are 10 types of people in this world, those who can count in binary and those who can't. > > > > > --__--__-- > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > > End of eap Digest > From jrv@umich.edu Thu Mar 13 23:19:19 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 13 Mar 2003 18:19:19 -0500 Subject: [eap] Issue 97: Strict interpretation In-Reply-To: References: Message-ID: <1869253.1047579558@[10.0.9.89]> I I like this except I suggest the following change to your implementation note >> > Implementation note: None of the methods defined in > this document support strict interpretation. > Authenticators operating in pass-through mode > cannot support "strict interpretation", > change the last phrase from since this would require that the authenticator be > upgraded to support new methods. to since this would require the RADIUS or other backend protocol support that is not currently defined. From johan.rh.hermans@alcatel.be Fri Mar 14 16:13:26 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Fri, 14 Mar 2003 17:13:26 +0100 Subject: [eap] Re: is UserName required in an Access-Reject or not? In-Reply-To: References: Message-ID: <3E71FFA6.6090607@alcatel.be> Bernard Aboba wrote: >Here's the text from RFC 2869: > >" In order to permit non-EAP aware RADIUS proxies to forward the > Access-Request packet, if the NAS sends the EAP-Request/Identity, the > NAS MUST copy the contents of the EAP-Response/Identity into the > User-Name attribute and MUST include the EAP-Response/Identity in the > User-Name attribute in every subsequent Access-Request. NAS-Port or > NAS-Port-Id SHOULD be included in the attributes issued by the NAS in > the Access-Request packet, and either NAS-Identifier or NAS-IP- > Address MUST be included. In order to permit forwarding of the > Access-Reply by EAP-unaware proxies, if a User-Name attribute was > included in an Access-Request, the RADIUS Server MUST include the > User-Name attribute in subsequent Access-Accept packets. Without the > User-Name attribute, accounting and billing becomes very difficult to > manage." > >In RFC 2865, it indicates that User-Name is not permitted in the >Access-Challenge or Access-Reject. > >So I think the answer is that the table is correct, and the text should be >corrected to reflect the original RFC 2869 text. > >Does this make sense? > > > > I've never really understood by a proxy needed to have the UserName in a response (Access-Challenge, Access-Accept or Access-Reject). A UserName can't be used to route the response back to where the request came from, because it's not unique. And RADIUS-proxies have handled those responses for years without any help. So, yes, I think that the table is correct, and User-Names shouldn't be copied in responses. -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From aboba@internaut.com Fri Mar 14 19:16:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Mar 2003 11:16:25 -0800 (PST) Subject: [eap] [802.1] P802.1aa/D5 (fwd) Message-ID: -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Thursday, February 27, 2003 3:14 AM To: stds-802-1@ieee.org Subject: [802.1] P802.1aa/D5 I have revised P802.1aa according to the ballot resolutions agreed in January, with the exception of Comment 28, which involved revision to the state machines in order to properly interface them with the EAP layer. Paul reports that considerable progress has been made on this front between the Interim meeting and the recent 11i ad-hoc meeting; however, in view of the short time now until the Dallas meeting, I have decided not to attempt to incorporate the revised state machines into the draft until we have had a chance to review the changes in Dallas. We can then decide what the next step should be - a confirmation ballot or a full re-ballot - as appropriate, and run that ballot in time for resolution in our June interim. The document can be found at: http://www.ieee802.org/1/files/private/aa-drafts/d5/802-1aa-d5.pdf username: p8021 password: go_wildcats Regards, Tony From aboba@internaut.com Fri Mar 14 19:19:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Mar 2003 11:19:43 -0800 (PST) Subject: [eap] EAP over IEEE 802 test event Message-ID: http://www.ieee802.org/1/files/public/docs2003/802-1X-test-event-info.pdf From aboba@internaut.com Fri Mar 14 19:20:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 14 Mar 2003 11:20:42 -0800 (PST) Subject: [eap] Updated IEEE802.1X/EAP state machine presentation Message-ID: http://www.ieee802.org/1/files/public/docs2003/EAP-1X-Machines-0312.pdf From jarkko@piuha.net Sun Mar 16 18:40:22 2003 From: jarkko@piuha.net (Jari Arkko) Date: Sun, 16 Mar 2003 20:40:22 +0200 Subject: [eap] comments on draft-vollbrecht-eap-state-01.{ps,txt} Message-ID: <3E74C516.6020005@piuha.net> John, Nick, Thanks for taking the effort to produce the new state machine document. I have a few comments and a number of questions, embedded inline in the URL below: http://www.piuha.net/~jarkko/publications/eap/sm01_review.txt Jari From aboba@internaut.com Mon Mar 17 18:15:00 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 17 Mar 2003 10:15:00 -0800 (PST) Subject: [eap] Alcatel patent (fwd) Message-ID: FYI. The IETF Secretariat has been notified of this potential claim, and has sent a request for further clarification. -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Mon 2/3/2003 12:27 PM To: stds-802-1@ieee.org Subject: [802.1] Alcatel patent =A0 I have received a response from Alcatel to my request that they file a Letter of Assurance with the IEEE. A copy of their letter is now held on file by the IEEE Patents Committee. I have posted a PDF of their letter at: http://www.ieee802.org/1/files/public/docs2003/alcatel-letter.pdf Regards, Tony From aboba@internaut.com Tue Mar 18 04:48:40 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 17 Mar 2003 20:48:40 -0800 (PST) Subject: [eap] IETF 56 presentations Message-ID: The presentations from today (and tommorrow's) EAP WG session are available at: http://www.drizzle.com/~aboba/IETF56/EAP/ From jrv@umich.edu Wed Mar 19 17:11:15 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 19 Mar 2003 12:11:15 -0500 Subject: [eap] Re: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612224E@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612224E@esebe023.ntc.nokia.com> Message-ID: <1332799.1048075875@wl-129-88.wireless.ietf56.ietf.org> Pasi -- I apologize for taking so long to reply. I have been thinking about your note, and there is much for me to try to put together. I would like to pursue this, and will have more time next week. A couple notes inline, more next week. -- John --On Wednesday, March 12, 2003 4:35 PM +0200 Pasi.Eronen@nokia.com wrote: > Hello John, and thanks for a thoughtful message! > > > Thanks for the response and the diagram. I think we are > > actually quite close and perhaps we should try to come up with > > a common state machine. There are differences to be talked > > through however. If you are interested we might want to try > > to have a conversation this week before ietf, or certainly at > > ietf. > > Unfortunately, I'm not able to make it to IETF meeting next > week, but let's continue this by e-mail. > yes- for sure > I think having a good state machine aligned with 2284bis is > quite important, as aligning it might reveal some problems in > 2284bis. E.g. do the new changes on sequences and "strict > interpretation" really work? And what is really meant when the > spec says MAY or SHOULD? (Hopefully the state machine will > unambiguously specify what must be done in what circumstances, > and the choice the implementor has to make is to simply > initialize some policy variables according to circumstances). > > I ended up doing some reading on state machines (hmm, I didn't > realize that somebody had actually written about them so much), > so please bear with my rather lengthy comment about them :-) > > > Our diagrams are in somewhat different styles. Ours is in 802 > > style, in which the actions are all in States, yours is more > > what i would expect, with actions associated with events on > > transitions between states. While I like yours better, I > > think the group wants to use the 8u2 style. It certainly > > helps with coordination with 802.1x an 802.11i state machines. > > I used the UML notation since I'm more familiar with it, but > coordination with 802.* might be easier if we use the same > notation, so it's OK to me (they are "equivalent enough" for > our purposes, I guess). There are two differences, though. > The first is a minor semantic issue and probably won't > matter. The second is more of "style issue", but might be > more important? > > The semantic issue is the following: In UML you can put > procedures inside states or in transitions (I used only the > latter), but they have different semantics. Procedures in > transitions are called "actions", and they are completed before > the transition has completely happened and next event is > processed. Procedures inside states are called "activities": > they start executing when the state is entered, but it is > possible that new events arrive while the activity is > running. If this results in leaving the state, the activity > is aborted. > thanks for the tutorial. this is helpful for me - I didn't know this, so it is helpful > Quite obviously, the state machine will be much simpler to > understand if we use only actions, and indeed, the procedures > in 802 notation are actions in this sense. (The only possible > candidate for an activity is the processing of EAP request for > method; it might require user interaction.) > ok - > The possibly more important issue is related to style. > Although the notations are both easy to understand, I had > some difficulties in comparing our state diagrams, and I kept > wondering why this was so. Then, it occurred to me (I'm not an > expert in this, so this might be obvious to you): In both > notations, the state of the system is stored by a combination of > the "box we're in" and specific named variables, and they can be > combined in different ways without changing the semantics of the > whole. > this has occurred to me, but I haven't done the analysis you have. > It seems that the UML notation prefers boxes to named variables, > and 802 notation does the opposite (though both notations allow > both styles). I feel that we should prefer the boxes, since > changes from one box to another are clearly shown (as arrows), > but the named variables are more like global variables in > programming languages: difficult to follow. > this is true - there are global variables, and they imply interactions between states and state machines. this seems to be true throughout 802.1 state machines > To take a concrete example, in my "quick hack" state machine > picture, the two states "MethodCanContinue" and > "MethodContinues" could be replaced by a single state "Method" > and a named variable "canSucceed". Then the transition from > Method->Success would have label "success && canSucceed" instead > of just "success". Using a similar procedure, we could actually > combine all the state boxes to one (except final states), with a > spaghetti of variables. > I am thinking this thru and am not yet convinced. It seems that the setting of an internal variable can cause a transition to a state, but the state is something else because in the state I do activities (and actions in 802 sense). I see where you are going - I can have a state that has lots of transitions with actions that goes back to itself. I am not sure why this doesn't work, so it is too bad we don't have a whiteboard and a meeting to talk it through. > You can convert a 802 state diagram to UML notation by moving > the procedures to the transitions (and then removing empty > "transition states"). Consider what happens when you do this to > the peer state machine in vollbrech-eap-state-01. All the state > boxes except IDLE (and final states) disappear. (This is as > expected; when the system is not running some procedure or > moving along an arrow, it is always in IDLE state.) > > I think the diagram should be refactored into several different > boxes (representing what the system expects or allows to happen > next), removing some of the named variables in the process. This > might lead to a clearer picture of the implications of "strict > interpretation" and other suggested changes (e.g. what specific > transitions are changed). Especially hiding important > information into a "filter" or "policy" variables doesn't > sound like a good idea to me... > I would be interested in seeing what you have in mind. > This refactoring might be easier to do with the UML style, > since the style is more aligned with the "common ways > of thinking" about the issue (and it does not generate > extra "transition states", and the "real states" and > transitions between them are more clearly shown). > When it's finished, we can convert it back to 802 > notation without loss of information. > > What do you think? Is refactoring the diagram a good idea? > It is an interesting idea. I do think it is important to keep the diagram in a form usable by 802.1aa, as they are hoping to include it as an addendum to their document. > Then to other issues: > > >> But does discarding those messages actually change the DoS > >> situation? In PPP or plain 802.1X, it seems the answer is > >> "no" (a DoS is possible by sending non-EAP packets > >> anyway). I'm not sure about 802.11i; it might, with certain > >> EAP methods? (does anyone have more information about this?) > > > > I am not certain, but it seems the number of DOS attacks > > possible is large and this will not get rid of all of them. > > However one of the simplest is sending an EAP Failure. > > Hopefully there will be some discussion at IETF about this > question (does silently discarding some messages give > *non-insignificant* protection against DoS? And even if > it's non-insignificant, is it worth the certainly > non-insignificant extra complexity?). > We had some discussion yesterday. I think the issue was that we should do what is logical in the flow. I am still thinking this through and hope to address it tomorrow when I present the state machine doc. > > 1. the diagram you present seems to deal only with strict > > interpretation. Is that your intent or am i missing something? > > > > 2. I am not clear how Requests and other messages that don't > > match policy.type are handled - are they silently discarded? > > I thought Requests would be NAK'd? > > No, the diagram is intended to work with all EAP methods, not > just ones using "strict interpretation". It just takes the > approach "silently discard whenever possible; i.e. discarding > won't change the outcome". This applies to e.g. requests for > other types once the supported type has been started. (Though > since it was just a "quick hack", I haven't checked carefully > that messages which could lead to success are never discarded.) > this is the approach more or less approved yesterday > The method-specific part of "strict interpretation" is embedded > the indications: continues/can_continue, and probably_succeeded/ > succeeded. For instance, the methods specified in RFC2284 don't > support the strict interpretation, so they never send the > "continues" indication. This means the state machine never ends > up in the MethodContinues state, where Success packets are > silently discarded. > > Ok, I'm not sure if this is the best way to handle this, but at > least it makes the differences between methods visible in the > state machine. Each method has to choose only when to send which > indication. In a state machine supporting sequences, we might > need even more different indications, like most_definitely_continues, > can_continue_or_succeed, can_continue_or_fail, and > can_continue_or_succeed_or_fail. (All this is relevant, > of course, only if we see that silently discarding some > messages is worth the extra complexity). > > > 3. Are you using link-enabled and link-disabled as two > > separate signals. I assume these are meant to be "alternate > > indications"? > > Yes (and I should have called them that, instead of > link-enabled/disabled). > > > 4. I think your "PROBABLE SUCCESS" and our "IDLE" states are > > pretty close, except that we allow another method to start if > > allowed by policy rather than only allowing success or > > failure. > > Not really, since the "IDLE" state is the only "real" state box > there is (see the comment about refactoring them earlier). But > some refactoring might bring them to alignment. > you're right - they aren't that close when I think about it. the refactoring is definitely interesting. > > I hope you have some good discussions next week at IETF (I'm > sorry I won't be there)! But let's continue this via e-mail.. > yes - I am very interested in seeeing how the refactoring would look. - John From aboba@internaut.com Wed Mar 19 16:42:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 19 Mar 2003 08:42:24 -0800 (PST) Subject: [eap] Comments on draft-jwalker-eap-archie-00.txt Message-ID: Section 2.1 The Archie Start message contains a SessionId value which is randomly selected. As you may know, IEEE 802.1aaD5 makes it possible for an authenticator to initiate with a message other than an EAP-Request/Identity. As I read the draft, EAP Archie does not require an EAP-Request/Identity to be sent, and since it is intended as a default builtin authentication method, might make use of this facility. However as I understand it, the IEEE 802.1aa MIB is adding a variable to supply the entire first packet -- this it is not clear whether they have left room for variation in the SessionId as required in EAP Archie. I suggest reviewing D5 so as to recommend changes to allow Archie-Like protocols to function better. Section 4.1 I think the protocol needs a Message Type (single octet) field. As it is, it's no clear how the peers can be clear what message type (Archie Request1, Archie Response1, Archie Request2, Archie Response2) is being sent, other than by checking the Identifier field. BType I don't recommend inventing your own address family registry. Please reuse the existing registry (a two octet field) defined by: http://www.iana.org/assignments/address-family-numbers Transport address types Not sure what these are used for. Can you explain? MAC1, MAC2, MAC3 Maybe this is obvious, but I don't see instructions on what the peer or EAP server should do if MAC validation fails. Is this a fatal error, or is silent discard the correct behavior? From jesse.walker@intel.com Wed Mar 19 19:48:20 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 19 Mar 2003 11:48:20 -0800 Subject: [eap] RE: Comments on draft-jwalker-eap-archie-00.txt Message-ID: Bernard, Thanks for the comments! Responses below. > Section 2.1 > > The Archie Start message contains a SessionId value which is randomly > selected. As you may know, IEEE 802.1aaD5 makes it possible for an > authenticator to initiate with a message other than an > EAP-Request/Identity. As I read the draft, EAP Archie does > not require an > EAP-Request/Identity to be sent, and since it is intended as a > default builtin authentication method, might make use of this > facility. > > However as I understand it, the IEEE 802.1aa MIB is adding a > variable to > supply the entire first packet -- this it is not clear > whether they have > left room for variation in the SessionId as required in EAP > Archie. I suggest > reviewing D5 so as to recommend changes to allow Archie-Like > protocols to > function better. If I understand, you are not suggesting a change in Archie. > Section 4.1 > > I think the protocol needs a Message Type (single octet) > field. As it is, > it's no clear how the peers can be clear what message type (Archie > Request1, Archie Response1, Archie Request2, Archie > Response2) is being > sent, other than by checking the Identifier field. Fair enough. We will add this in the next version. > BType > > I don't recommend inventing your own address family registry. > Please reuse > the existing registry (a two octet field) defined by: > > http://www.iana.org/assignments/address-family-numbers Excellent observation. We will look at this and figure out how to use the existing registry. > Transport address types This was meant to be a triplet. This was so Archie could be used for other things for applications. > Not sure what these are used for. Can you explain? > > MAC1, MAC2, MAC3 > > Maybe this is obvious, but I don't see instructions on what > the peer or > EAP server should do if MAC validation fails. Is this a fatal > error, or is > silent discard the correct behavior? Yes, I realized this after sending out the draft. I think we need to silently discard. I have not discussed this with Russ. -- Jesse From aboba@internaut.com Thu Mar 20 03:41:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 19 Mar 2003 19:41:09 -0800 (PST) Subject: [eap] RE: Comments on draft-jwalker-eap-archie-00.txt In-Reply-To: Message-ID: > If I understand, you are not suggesting a change in Archie. Right. Not an Archie issue -- but may be an IEEE 802.1aa issue. > This was meant to be a triplet. > This was so Archie could be used for other things for applications. Ah. But the introduction says that Archie is only defined for use with EAP. So you might describe when the various address families are used. For example, presumably the IP address family might be used with PANA (where an IP address is available), but not with 802.11 (where the MAC address is probably relevant). In PPP, I'd assume that the phone number might be the correct thing. Laying this out would be helpful -- as well as stating what the intended use is (such as requiring the AAA server to check the "bound" client address against the Calling-Station-Id attribute). Presumably if this check were to fail, some action should be taken (logging, refusing to bring the link up, etc). It would also be nice to include a section on "Binding" to describe why this is important and what attacks it prevents, particularly in roaming systems. And a similar section on "naming" and why that is important, too. BTW, I didn't see support for naming in Archie. For example, there has been speculation that the combination of Acct-Session-Id/Acct-Multi-Session-Id might be an appropriate key name. From jesse.walker@intel.com Thu Mar 20 05:03:18 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 19 Mar 2003 21:03:18 -0800 Subject: [eap] RE: Comments on draft-jwalker-eap-archie-00.txt Message-ID: Bernard, > > This was meant to be a number> triplet. > > This was so Archie could be used for other things for applications. > > Ah. But the introduction says that Archie is only defined for use with > EAP. So you might describe when the various address families > are used. For > example, presumably the IP address family might be used with > PANA (where > an IP address is available), but not with 802.11 (where the > MAC address is > probably relevant). In PPP, I'd assume that the phone number > might be the > correct thing. Laying this out would be helpful -- as well as > stating what > the intended use is (such as requiring the AAA server to > check the "bound" > client address against the Calling-Station-Id attribute). > Presumably if > this check were to fail, some action should be taken > (logging, refusing to > bring the link up, etc). Good observations. One of the things I am not clear on is what needs to be done to make Archie effective with PPP. Your suggestions here look like a good starting point in sorting that out. Thanks. > It would also be nice to include a section on "Binding" to > describe why > this is important and what attacks it prevents, particularly > in roaming > systems. And a similar section on "naming" and why that is > important, too. > BTW, I didn't see support for naming in Archie. For example, there has > been speculation that the combination of > Acct-Session-Id/Acct-Multi-Session-Id might be an appropriate > key name. Sounds like another good suggestion, so plan to do something in the next revision. If you have other suggestions here, please let us know. -- Jesse From clenahan@fortresstech.com Thu Mar 20 23:17:43 2003 From: clenahan@fortresstech.com (clenahan@fortresstech.com) Date: Thu, 20 Mar 2003 18:17:43 -0500 Subject: [eap] Question about proper incrementing of eap-id. Message-ID: <5.2.0.9.0.20030320153445.00b96c08@172.27.1.17> --=======AEB1997======= Content-Type: text/plain; x-avg-checked=avg-ok-58FA54BE; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit I am having a situation with some EAP/RADIUS servers that are rejecting, when several simultaneous connections are being made and the request/responses are being intermingled and the eap/radius server is kicking out a client because a mismatching of the eap-ids. Below is the flow of the messages to three clients trying to connect. Client #3 is getting rejected because his eap-id is 48, the same as a challenge to client#2. Clients NAS RADIUS <== REQ/IDENT id:46 Client#1 <== REQ/IDENT id:47 Client#2 <== REQ/IDENT id:48 Client#3 Client#2 id:47 RESP/IDENT ==> id:47 RESP/IDENT ==> <== REQ/MD5-CHALLENGE id:48 <== REQ/MD5-CHALLENGE id:48 Client#2 Client#1 id:46 RESP/IDENT ==> id:46 RESP/IDENT ==> <== REQ/MD5-CHALLENGE id:47 <== REQ/MD5-CHALLENGE id:47 Client#1 Client#3 id:48 RESP/IDENT ==> id:48 RESP/IDENT ==> <== REJECT Client#3 Its happend w/ two vendors radius servers, and I able to track down the problem by getting one of them to do a more verbose dump, and it was saying that "User A" failed challenge sequence, even though the Radius User-Name attribute was "B" . My questions are: Is the NAS and RADIUS server generating REQ/RESOP w/ proper incrementing of the eap-id? In 2284bis-01m , it says the Identifier space unique to each "session". What determines a "session". How is this applyed over to EAP-over-RADIUS? Where is this defined? The radius attributes that are set User-Name, EAP-Message,Message-Auth NAS-IP-Address, Calling-Station-Id, and two vendor attributes. --=======AEB1997======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-58FA54BE Content-Disposition: inline --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.463 / Virus Database: 262 - Release Date: 3/17/2003 --=======AEB1997=======-- From CLenahan@fortresstech.com Thu Mar 20 23:32:12 2003 From: CLenahan@fortresstech.com (Charlie Lenahan) Date: Thu, 20 Mar 2003 18:32:12 -0500 Subject: [eap] Question about proper incrementing of eap-id. Message-ID: <60C9D8B49C2C71459874A1F4F5DEE8072027B2@alfalfa.fortresstech.com> SSBhbSBoYXZpbmcgYSBzaXR1YXRpb24gd2l0aCBzb21lIEVBUC9SQURJVVMgc2VydmVycyB0aGF0 IGFyZSByZWplY3RpbmcsIHdoZW4gc2V2ZXJhbCANCnNpbXVsdGFuZW91cyBjb25uZWN0aW9ucyBh cmUgYmVpbmcgbWFkZSBhbmQgdGhlIHJlcXVlc3QvcmVzcG9uc2VzIGFyZSBiZWluZyBpbnRlcm1p bmdsZWQgYW5kIA0KdGhlIGVhcC9yYWRpdXMgc2VydmVyIGlzIGtpY2tpbmcgb3V0IGEgY2xpZW50 IGJlY2F1c2UgYSBtaXNtYXRjaGluZyBvZiB0aGUgZWFwLWlkcy4NCg0KQmVsb3cgaXMgdGhlIGZs b3cgb2YgdGhlIG1lc3NhZ2VzIHRvIHRocmVlIGNsaWVudHMgdHJ5aW5nIHRvIGNvbm5lY3QuIENs aWVudCAjMyANCmlzIGdldHRpbmcgcmVqZWN0ZWQgYmVjYXVzZSBoaXMgZWFwLWlkIGlzIDQ4LCB0 aGUgc2FtZSBhcyBhIGNoYWxsZW5nZSANCnRvIGNsaWVudCMyLiANCg0KDQpDbGllbnRzICAgICAg ICAgICAgICAgICAgICAgICAgICAgTkFTICAgICAgICAgICAgICAgICAgICAgICAgICBSQURJVVMN Cg0KICAgICA8PT0gUkVRL0lERU5UICBpZDo0NiAgQ2xpZW50IzENCiAgICAgPD09IFJFUS9JREVO VCAgaWQ6NDcgIENsaWVudCMyDQogICAgIDw9PSBSRVEvSURFTlQgIGlkOjQ4ICBDbGllbnQjMw0K ICAgICBDbGllbnQjMiBpZDo0NyAgUkVTUC9JREVOVCA9PT4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpZDo0NyAgUkVTUC9JREVOVCA9PT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDw9PSBSRVEvTUQ1LUNIQUxMRU5HRSBpZDo0OA0KICAg ICA8PT0gUkVRL01ENS1DSEFMTEVOR0UgaWQ6NDggQ2xpZW50IzINCiAgICAgQ2xpZW50IzEgaWQ6 NDYgIFJFU1AvSURFTlQgPT0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaWQ6NDYgIFJFU1AvSURFTlQgPT0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8PT0gUkVRL01ENS1DSEFMTEVOR0UgaWQ6NDcNCiAgICAgPD09IFJFUS9NRDUtQ0hB TExFTkdFIGlkOjQ3IENsaWVudCMxDQogICAgIENsaWVudCMzIGlkOjQ4ICBSRVNQL0lERU5UID09 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlkOjQ4ICBSRVNQL0lE RU5UID09Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8PT0gUkVKRUNU IENsaWVudCMzDQoNCg0KSXRzIGhhcHBlbmQgdy8gdHdvIHZlbmRvcnMgcmFkaXVzIHNlcnZlcnMs IGFuZCBJIGFibGUgdG8gdHJhY2sgZG93biB0aGUgcHJvYmxlbSBieSANCmdldHRpbmcgb25lIG9m IHRoZW0gdG8gZG8gYSBtb3JlIHZlcmJvc2UgZHVtcCwgYW5kIGl0IHdhcyBzYXlpbmcgdGhhdCAi VXNlciBBIiBmYWlsZWQgDQpjaGFsbGVuZ2Ugc2VxdWVuY2UsIGV2ZW4gdGhvdWdoIHRoZSBSYWRp dXMgVXNlci1OYW1lIGF0dHJpYnV0ZSB3YXMgIkIiIC4NCg0KTXkgcXVlc3Rpb25zIGFyZToNCg0K SXMgdGhlIE5BUyBhbmQgUkFESVVTIHNlcnZlciBnZW5lcmF0aW5nIFJFUS9SRVNPUCB3LyBwcm9w ZXIgaW5jcmVtZW50aW5nIA0Kb2YgdGhlIGVhcC1pZD8NCg0KSW4gMjI4NGJpcy0wMW0gLCBpdCBz YXlzIHRoZSBJZGVudGlmaWVyIHNwYWNlIHVuaXF1ZSB0byBlYWNoICJzZXNzaW9uIi4gV2hhdCBk ZXRlcm1pbmVzIA0KYSAic2Vzc2lvbiIuIEhvdyBpcyB0aGlzIGFwcGx5ZWQgb3ZlciB0byBFQVAt b3Zlci1SQURJVVM/IFdoZXJlIGlzIHRoaXMgZGVmaW5lZD8NCg0KVGhlIHJhZGl1cyBhdHRyaWJ1 dGVzIHRoYXQgYXJlIHNldCBVc2VyLU5hbWUsIEVBUC1NZXNzYWdlLE1lc3NhZ2UtQXV0aCBOQVMt SVAtQWRkcmVzcywNCkNhbGxpbmctU3RhdGlvbi1JZCwgYW5kIHR3byB2ZW5kb3IgYXR0cmlidXRl cy4NCg0KIA0K From alper@docomolabs-usa.com Fri Mar 21 06:16:12 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 20 Mar 2003 22:16:12 -0800 Subject: [eap] IETF 56 presentations In-Reply-To: Message-ID: > The presentations from today (and tommorrow's) EAP WG session are > available at: > > http://www.drizzle.com/~aboba/IETF56/EAP/ >From the EAP WG agenda: EAP over CDMA2000, P. Agashe, 10 minutes http://www.ietf.org/internet-drafts/draft-pagashe-eapcdma2000-00.txt EAP GPRS, A. Salkintzis, 10 minutes http://www.ietf.org/internet-drafts/draft-salki-pppext-eap-gprs-00.txt These two drafts were not presented at the meeting, but nevertheless I have some comments. The first draft is about a new EAP transport, not a EAP method. It is defining a UDP based transport for EAP. This is not a material for the EAP WG, but for the PANA WG. For those who doesn't already know, IETF PANA WG is developing a link-layer agnostic transport for EAP. Please see http://www.ietf.org/html.charters/pana-charter.html Second draft, I'm a bit confused. Is it a new EAP method, or a new EAP protocol, like EAPv2, or a new EAP transport, or some combination of all? I hope we can get some explanation from the authors... Regards, alper From antonio.forzieri@cefriel.it Fri Mar 21 10:04:44 2003 From: antonio.forzieri@cefriel.it (Antonio Forzieri) Date: Fri, 21 Mar 2003 11:04:44 +0100 Subject: [eap] EAP(Request, Identity) Message-ID: <3E7AE3BC.7000704@cefriel.it> Hi to all, I'm a people of the IPsec WG. In these days we are discussing about some issues about EAP, which is going to be including in IKEv2. The main problem we have is this: Does the autheticator need to know the peer's identity before sending an EAP(Request,MD5)? Or we can send that EAP message without knowing the initiator identity? Is it possible a scenario like this? Peer Authenticator ------ --------------- <-- EAP(Request,MD5) IDi, EAP(Response,MD5) --> <-- EAP(Success/Failure) EAP messages are encapsulated in IKEv2, and IDi is carried by a special IKEv2 payload type (Identity). Will this solution work? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From johan.rh.hermans@alcatel.be Fri Mar 21 10:07:03 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Fri, 21 Mar 2003 11:07:03 +0100 Subject: [eap] Question about proper incrementing of eap-id. In-Reply-To: <5.2.0.9.0.20030320153445.00b96c08@172.27.1.17> References: <5.2.0.9.0.20030320153445.00b96c08@172.27.1.17> Message-ID: <3E7AE447.6@alcatel.be> clenahan@fortresstech.com wrote: > I am having a situation with some EAP/RADIUS servers that are > rejecting, when several > simultaneous connections are being made and the request/responses are > being intermingled and > the eap/radius server is kicking out a client because a mismatching of > the eap-ids. [snip] > My questions are: > > Is the NAS and RADIUS server generating REQ/RESOP w/ proper incrementing > of the eap-id? > > In 2284bis-01m , it says the Identifier space unique to each > "session". What determines > a "session". How is this applyed over to EAP-over-RADIUS? Where is > this defined? > > The radius attributes that are set User-Name, EAP-Message,Message-Auth > NAS-IP-Address, > Calling-Station-Id, and two vendor attributes. > The nas has started 3 different "sessions" with the client, for 3 different clients. The identifier-space is unique for each session, which is pretty easy for the NAS to do. The RADIUS server should be able to separate the sessions on nas-ipaddress (or nas-identifier), and the username or caller-id, according to RFC2869bis-draft10. Since this is not not enough (username isn't unique), you can use the nas-port or nas-port-id too. Unfortunately, the nas-port isn't unique either (a huge mistake in RADIUS if you ask me). Neither is the caller-id. In my own software, I'm using nas-ipaddress, nas-port, username and caller-id, which combination seems to work in all cases so far. But what we would really need is a /real/ session-identifier, especially one that is globally and temporarily unique. But attribute #44 isn't allowed in RADIUS access-requests, although a lot of RANs can be configured to send one. Your RADIUS-server should be able to use username and/or caller-id, but clearly doesn't use them. -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From antonio.forzieri@cefriel.it Fri Mar 21 10:51:27 2003 From: antonio.forzieri@cefriel.it (Antonio Forzieri) Date: Fri, 21 Mar 2003 11:51:27 +0100 Subject: [eap] EAP(Request, Identity) In-Reply-To: <3E7AEABC.1020604@alcatel.be> References: <3E7AE3BC.7000704@cefriel.it> <3E7AEABC.1020604@alcatel.be> Message-ID: <3E7AEEAF.4050409@cefriel.it> Jo Hermans wrote: First of all thanks a lot for your answer. > For MD5-challenge, it's possible if the identity is passed together with > the response/md5 (inside the encapsulating RADIUS message for instance) > or is determined from the response-message itself (source-ip-address, > caller-id, whatever, ...). Or if you would use always the same identity > somehow. Ok! It sounds fine for me. So the Authenticator can send EAP(Request,MD5) without knowing the peer's ID (right?). Is it possible only for MD5 AUTH? Or is it possible for a generic method which uses EAP? (OTP, GTC) I guess that with OTP the authenticator should know the peer's identity before sending the "challenge", is it right? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From aboba@internaut.com Fri Mar 21 15:41:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 21 Mar 2003 07:41:16 -0800 (PST) Subject: [eap] EAP WG minutes and presentations Message-ID: If you took minutes at the IETF 56 EAP WG meetings, please send them to the chairs. Presentations are available at: http://www.drizzle.com/~aboba/IETF56/EAP/ If your presentation isn't available there, please email it to the chairs. From aboba@internaut.com Sat Mar 22 05:15:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 21 Mar 2003 21:15:51 -0800 (PST) Subject: [eap] Re: Question about proiper incrementing of EAP-Id In-Reply-To: <20030321180002.26299.2743.Mailman@wolverine> Message-ID: > Clients NAS RADIUS > > <== REQ/IDENT id:46 Client#1 > <== REQ/IDENT id:47 Client#2 > <== REQ/IDENT id:48 Client#3 > Client#2 id:47 RESP/IDENT ==> > id:47 RESP/IDENT ==> > <== REQ/MD5-CHALLENGE id:48 > <== REQ/MD5-CHALLENGE id:48 Client#2 > Client#1 id:46 RESP/IDENT ==> > id:46 RESP/IDENT ==> > <== REQ/MD5-CHALLENGE id:47 > <== REQ/MD5-CHALLENGE id:47 Client#1 > Client#3 id:48 RESP/IDENT ==> > id:48 RESP/IDENT ==> > <== REJECT Client#3 It looks to me like the NAS behavior is perfectly legal -- it can choose any Identifier that it wants at the beginning of a session, since the Identifier space isn't shared between sessions. The problem is that the RADIUS server isn't providing a unique Identifier space between sessions, so it is broken. We probably need to add text to RFC 2869bis to make it clear that the RADIUS server is behaving inappropriately. How about this: "In EAP, each session (as defined by combination of NAS-Port and NAS identification attributes such as NAS-Identifier, NAS-IPv6-Address or NAS-IPv4-Address) has its own unique EAP Identifier space. RADIUS server implementations MUST be able to distinguish between EAP Responses with the same Identifier but existing with distinct sessions." > Is the NAS and RADIUS server generating REQ/RESOP w/ proper incrementing > of the eap-id? Yes, I believe both the NAS and RADIUS server are behaving legally. > In 2284bis-01m , it says the Identifier space unique to each "session". > What determines > a "session". How is this applyed over to EAP-over-RADIUS? Where is this > defined? At any given point in time, an authentication session can be identified by the combination of NAS-Port and NAS-Identifier/NAS-IPv6-Address/NAS-IPv4-Address. Over time, sessions are uniquely identified by NAS identification attributes and the Acct-Session-Id. From aboba@internaut.com Sat Mar 22 05:22:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 21 Mar 2003 21:22:54 -0800 (PST) Subject: [eap] Re: EAP within IKE In-Reply-To: <20030321180002.26299.2743.Mailman@wolverine> Message-ID: > Hi to all, > I'm a people of the IPsec WG. In these days we are discussing about some > issues about EAP, which is going to be including in IKEv2. The main > problem we have is this: > > Does the autheticator need to know the peer's identity before sending an > EAP(Request,MD5)? Or we can send that EAP message without knowing the > initiator identity? Is it possible a scenario like this? In the flow below you are ommitting the EAP-Request/Identity, and always sending an EAP MD5-Challenge. This implies that you know that MD5 is the appropriate method for all users. Given that the MD5-Challenge method cannot be cryptographically bound to IKEv2, this may not be a wise choice. Also, the EAP-Request/Identity can contain a hint as to what the EAP-Response/Identity should be. Since the client might select its credential based on that hint, it is possible that the client may not be able to respond correctly. Also, is it always clear that the IKE IDi and the EAP Response/Identity are necessarily the same? It seems like you are assuming this. > > Peer Authenticator > ------ --------------- > <-- EAP(Request,MD5) > IDi, EAP(Response,MD5) --> > <-- EAP(Success/Failure) > > EAP messages are encapsulated in IKEv2, and IDi is carried by a special > IKEv2 payload type (Identity). > Will this solution work? I don't think so. What do other people think? From johan.rh.hermans@alcatel.be Mon Mar 24 09:58:24 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Mon, 24 Mar 2003 10:58:24 +0100 Subject: [eap] Re: Question about proiper incrementing of EAP-Id In-Reply-To: References: Message-ID: <3E7ED6C0.80506@alcatel.be> Bernard Aboba wrote: >>In 2284bis-01m , it says the Identifier space unique to each "session". >>What determines >>a "session". How is this applyed over to EAP-over-RADIUS? Where is this >>defined? >> >> > >At any given point in time, an authentication session can be identified by >the combination of NAS-Port and NAS-Identifier/NAS-IPv6-Address/NAS-IPv4-Address. >Over time, sessions are uniquely identified by NAS identification >attributes and the Acct-Session-Id. > > > I agree. But keep in mind that Nas-Port (or Nas-Port-Id) isn't unique ! Several RADIUS RAN's are using NAS-port's that are shared between different sessions, which creates serious problems in stateful proxy servers. RFC2865 never mentioned what a "port" really is, just that it's "in its sense of a physical connection". Some RAN's take that quite literally, and return the ATM-VCI or even the number of the E1 board. As Bernard said, we really need to use acct-session-id (combined with the nas-ipaddress/nas-identifier to make it globally unique) to identify a session. But since that attribute isn't present in access-requests ... Luckily, several RAN's can be configured to return them anyway. In my application, I'm using [nas-ipaddress + nas-port + username + callerid] as the identifier for the session. This works so far, even when the nas-ipaddress was bogus (as we've experienced in some networks). -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From aboba@internaut.com Mon Mar 24 14:58:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 24 Mar 2003 06:58:59 -0800 (PST) Subject: [eap] Presentations from IETF56 Message-ID: The presentations made to the EAP WG at IETF56 are available at: http://www.drizzle.com/~aboba/IETF56/ietf56-eap.zip From jsalowey@cisco.com Mon Mar 24 20:27:26 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 24 Mar 2003 12:27:26 -0800 Subject: [eap] Compound Authentication Draft Message-ID: <000301c2f243$c912ac50$0200000a@amer.cisco.com> A similar problem exists with compound authentication even when a mechanism is used only within secure tunnels. A appropriate use of policy can be used to reduce the vulnerability and I think it should be noted in the document. Take a mechanism such as MSCHAPv2 which is secure against a man it the middle and generates session keys which can be used to protect additional data and further prevent a man in the middle. This method can be used securely by itself. Take an example using MSCHAPv2 inside of a mechanism such as PEAP. Party A can establish a secure connection to party B by establishing PEAP and verifying B's identity. B can then request that A authenticate with MSCHAPv2. A will perform MSCHAPv2 authentication with B. B can open up another PEAP session to C. B can proxy the MSCHAPv2 authentication to C and authenticate as A. B can now carry on a conversation with C as if he were A. This attack can be avoided if A has an appropriate policy configuration or if A can detect that the identity authenticated as B during PEAP is not equivalent to the identity authenticated as B in the MSCHAPv2 conversation and abort the authentication before it completes. In practice it may be difficult to verify that one identity is or is not equivalent because of different identity formats used in different credential types. This is a result of a faulty trust relationship. In a sense if B is a malevolent entity A should not allow the connection since it should know there is no way that B should not have access to the credentials used by the inner method (MSCHAPv2 in this case). This sort of determination may be difficult in practice. It also means that any entity that you trust to participate with in an inner authentication mechanism you must also trust to be able to impersonate you. More investigation is needed to see if this is really a problem (intuitively I think it is a problem, but I haven't had a chance to think it through). A solution to this problem is for the client to have a policy that limits which inner authentication methods and credentials can be used based on the identity authenticated in the outer tunnel (it seems that this should exist in implementations already). The client mechanism may also have a policy that aborts the authentication if it is determined that the identity validated in the inner mechanism is not the same as the identity validated in the outer mechanism (with some mechanism this may be impossible as the server identity may not be known until the authentication completes). Cryptographic binding may also help in this case. Joe From jose.p.puthenkulam@intel.com Mon Mar 24 22:36:05 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Mon, 24 Mar 2003 14:36:05 -0800 Subject: [eap] Issue 64: Problem statement issues Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F255.C16FD970 Content-Type: text/plain Some comments/proposed resolution to this issue marked ... Issue 64: Problem statement issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 8, 2003 Document: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt Reference: http://mail.frascone.com/pipermail/eap/2002-December/000413.html Comment type: T Priority: S Section: Various Rationale/Explanation of issue: This draft describes aspects of MiTM attacks that can be mounted against compound EAP methods. At IETF 55, there was consensus that this was a problem that needed more work. The first step in that direction is to complete the problem statement. This is the core of what this draft is trying to do, I think. However, in reading through it, I think it doesn't do a very good job in several aspects: a. Motivation for compound methods. One obvious solution to the problem of compound method security is to say "don't use compound methods, use strong simple methods instead." So some justification for the use of compound methods needs to be included in the draft. version 2 draft addresses this in sec 1.2 b. Discussing vulnerabilities of EAP method sequences. Are the same attacks launchable against sequences? In what scenarios? The discussion is mostly focussed on tunneling. Currently we didn't study sequences in great detail. However the reasons we did so are the following and hopefully will add some text in the version 3 draft on this -Sequences are open-ended, unless they follow some well defined method that describes the order and content of the sequence, it is hard to make them interoperable and meaningful to study. -For sequences, there has to be an umbrella method that defines the security of the sequence in totality, before we can be sure what solutions for mitm attacks can be provided. -No well defined sequenced EAP protocol methods are available. (correct me if I'm wrong here....). c. Discussing the circumstances in which the attack can occur. For example, can the attack occur when the tunnel authentication is mutual? If there is no credential reuse? What role can policy play? Plan to add some text on the mutual authenticated tunnel situation. The attack that is possible in that case is due to a violation of trust by a trusted man-in-the-middle. Policy has already been considered in the version 2 draft as a possible solution. However the bias is towards to automated solutions using cryptographic binding. d. Discussing the *incremental* vulnerabilities created by compound methods. This is very important in understand what problems are *created* by compound methods, and which problems are inherent in the scenarios being discussed. For example, when dealing with "legacy" methods (e.g. methods which do one-way auth and don't derive keys) and wired networks (e.g. PPP and IEEE 802) there is an inherent vulnerability to hijacking. Therefore the scenario is inherently insecure from the start -- and so the question is not whether security is present (it isn't) -- but how compound methods make the situation *worse*. Section 1.2 provides the motivations for compound methods and the reality of protocol adaptation for new environments due to several reasons. Not sure whether compound methods make it worse though, because there are trade-offs which are implementation feature dependent and its difficult to have a solution that meets all criteria. Will add some text in the version 3 update about trade-off between chosing a single method vs a compound method. e. Discussing the requirements for a solution. What would a "solution" to the "problem" being defined look like? Hopefully section 3.2 addresses this What should we expect from a "solution"? For example, would a solution prevent offline attacks against weak tunneled methods? Section 3.1 defines criteria for a solution. However, we do not call out additional expectations explicitly. The implicit expectation is that the solution doesn't bring in additional vulnerabilities. However offline attacks that could be performed by an Mitm need mention and will propose the following text for it to be added to the solution criteria. "Man-in-the-middle Offline Attacks The solution should not allow the man-in-the-middle from being able to perform offline attacks on the weak inner method protocols used within a tunnel. " Would it apply to all EAP methods, or just some subset? If it only applies to a subset, why does this subset benefit from tunneling? Section 3.2, 3.3 and 3.6 of the version2 draft partially cover this. Policy based solutions apply to all methods. However for key deriving methods, cryptographic binding is possible. Now from section 1.2 we already explained why tunnels have been in use and what the resulting benefits are for both legacy and new methods Is this resolution acceptable? best regards, jose ------_=_NextPart_001_01C2F255.C16FD970 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [eap] Issue 64: Problem statement issues

Some comments/proposed resolution to = this issue marked <jp>..</jp>.
Issue 64: Problem statement = issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: January 8, 2003
Document: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding= -01.txt
Reference: http://mail.frascone.com/pipermail/eap/2002-December/000413.html<= /FONT>
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

This draft describes aspects of MiTM attacks that can be mounted = against
compound EAP methods. At IETF 55, there was consensus that this was = a
problem that needed more work. The first step in that direction is = to
complete the problem statement. This is the core of what this draft = is
trying to do, I think.

However, in reading through it, I think it doesn't do a very good job = in
several aspects:

a. Motivation for compound methods. One obvious solution to the problem = of
compound method security is to say "don't use compound methods, = use strong
simple methods instead." So some justification for the use of = compound
methods needs to be included in the draft.
<jp>version 2 draft addresses = this in sec 1.2 </jp>

b. Discussing vulnerabilities of EAP method sequences. Are the same
attacks launchable against sequences? In what scenarios? The discussion = is
mostly focussed on tunneling.
<jp>
Currently we didn't study sequences = in great detail. However the reasons we did so are the following and = hopefully will add some text in the version 3 draft on this

-Sequences are open-ended, unless = they follow some well defined method that describes the order and = content of the sequence, it is hard to make them interoperable and = meaningful to study.

-For sequences, there has to be an = umbrella method that defines the security of the sequence in totality, = before we can be sure what solutions for mitm attacks can be = provided.

-No well defined sequenced EAP = protocol methods are available. (correct me if I'm wrong = here....).
</jp>

c. Discussing the circumstances in which the attack can occur. For
example, can the attack occur when the tunnel authentication is mutual? = If
there is no credential reuse? What role can policy play?
<jp>
Plan to add some text on the mutual = authenticated tunnel situation. The attack that is possible in that = case is due to a violation of trust by a trusted = man-in-the-middle.

Policy has already been considered in = the version 2 draft as a possible solution. However the bias is towards = to automated solutions using cryptographic binding.

</jp>

d. Discussing the *incremental* vulnerabilities created by compound
methods. This is very important in understand what problems are = *created*
by compound methods, and which problems are inherent in the = scenarios
being discussed. For example, when dealing with "legacy" = methods (e.g.
methods which do one-way auth and don't derive keys) and wired = networks
(e.g. PPP and IEEE 802) there is an inherent vulnerability to = hijacking.
Therefore the scenario is inherently insecure from the start -- and so = the
question is not whether security is present (it isn't) -- but how = compound
methods make the situation *worse*.
<jp>
Section 1.2 provides the motivations = for compound methods and the reality of protocol adaptation for new = environments due to several reasons. Not sure whether compound methods = make it worse though, because there are trade-offs which are = implementation feature dependent and its difficult to have a solution = that meets all criteria.

Will add some text in the version 3 = update about trade-off between chosing a single method vs a compound = method.
</jp>

e. Discussing the requirements for a solution. What would a = "solution" to
the "problem" being defined look like?
<jp> Hopefully section 3.2 = addresses this </jp>
What should we expect from a = "solution"? For example, would a solution prevent offline = attacks against
weak tunneled methods?
<jp> Section 3.1 defines = criteria for a solution. However, we do not call out additional = expectations explicitly. The implicit expectation is that the solution = doesn't bring in additional vulnerabilities. However offline attacks = that could be performed by an Mitm need mention and will propose the = following text for it to be added to the solution criteria.

"Man-in-the-middle Offline = Attacks
           = ;      The solution should not allow the = man-in-the-middle from being able to perform offline attacks on the = weak inner method protocols used within a tunnel.

"
Would it apply to all EAP methods, = or just some
subset? If it only applies to a subset, why does this subset benefit = from
tunneling?
<jp>
Section 3.2, 3.3 and 3.6 of the = version2 draft partially cover this.  Policy based solutions apply = to all methods. However for key deriving methods, cryptographic binding = is possible. Now from section 1.2 we already explained why tunnels have = been in use and what the resulting benefits are for both legacy and new = methods

</jp>
Is this resolution = acceptable?
best regards,
jose

------_=_NextPart_001_01C2F255.C16FD970-- From jose.p.puthenkulam@intel.com Mon Mar 24 22:36:22 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Mon, 24 Mar 2003 14:36:22 -0800 Subject: [eap] Issue 65: Downgrade attacks Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F255.CBC3E470 Content-Type: text/plain Some comments/proposed resolution to this issue marked ... Issue 65: Downgrade attacks Submitter name: Dan Simon Submitter email address: dansimon@microsoft.com Date first submitted: January 8, 2003 Document: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt Reference: http://mail.frascone.com/pipermail/eap/2003-January/000485.html Comment type: T Priority: S Section: Various Rationale/Explanation of issue: My main concern with the document is that it doesn't seem to say anything about the legacy/rollback issue. If both fixed and legacy "clients (authenticators) and "servers" (verifiers) have to interoperate with each other, then a signaling mechanism *incorporated into, and detectable in, legacy instances* is necessary to allow fixed clients and servers to recognize each other and avoid a rollback. Moreover, this signaling mechanism has the additional advantage of solving the MITM problem completely, all by itself, since it can be used to distinguish tunnelled from untunnelled authentications. version 2 draft text that addresses this to some degree: "For non-key deriving methods, if they are modifiable, then using a signal to indicate when they are running inside a tunnel would also prevent the attack. This works because the server is able to distinguish between an attacker diverting a method into a tunnel versus a client method intentionally initiated inside a tunnel. However such signals need protection from spoofing." We treat it as not just as legacy/rollback issue but for all non-key deriving methods that can be modified. On the same note one of our solution requirements is that we do not require changes to existing EAP authentication methods (not tunneled ones). Now, if one side of the authentication can be assumed not to include legacy instances (e.g., all servers being upgraded simultaneously), then a carefully designed fixed protocol may suffice, without any signaling (e.g., an extra MAC is thrown into the protocol in both directions, and the fixed client will detect an attempted rollback attack when it doesn't receive the expected returned MAC from the fixed server). But if both sides must interoperate with both fixed and legacy counterparts, then signaling within the legacy protocol must be used if rollback is to be prevented. Rollback attacks cannot be completely avoided. Usage of policies to prevent rollbacks from being requested by unknown clients is one-way to approach this problem. For clients that are known, then some amount of out of band trust will have to be established to guarantee that such an attack does not occur. For example, if, say, a compound key derivation solution is used, then in the presence of both fixed and legacy clients and servers, some mechanism has to be found to negotiate whether to use the "pure" tunnel keys or compound keys. That mechanism needs to be such that, say, fixed clients' messages can't be fiddled with to make them look like legacy clients' messages, or the MITM can do the conversion and force the server to roll back to the legacy protocol. On the other hand, the fixed clients' messages must look enough like legacy clients' messages that legacy servers can accept and respond to them according to the legacy protocol. Hence the fixed clients' messages have to be legacy-compatible messages with an indelible "signal" in them that a fixed server will recognize as indicating a fixed client. In the version 2 draft, there is 'version' information included in the binding phase exchange to prevent a fixed client from masquerading and performing an attack. But the presence of this signal also obviates the need for the compound key negotiation altogether; if fixed clients simply use the signal whenever not tunnelling, then a tunnelling protocol server can reject all tunnelled authentications containing the signal, thus protecting the fixed client from MITM attacks even without any other protocol change. Proposed points to capture in version 3 draft update: - Call out downgrade attacks more succinctly - Call out the two options to prevent it 1) If legacy methods are modifiable, then use signals 2) If binding phase exchange is supported by the tunnel client and server, then prevent any downgrade negotiation using policy For complete prevention 1 or 2 must be supported. Is this acceptable? best regards, jose ------_=_NextPart_001_01C2F255.CBC3E470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [eap] Issue 65: Downgrade attacks

Some comments/proposed resolution to = this issue marked <jp>..</jp>.
Issue 65: Downgrade = attacks
Submitter name: Dan Simon
Submitter email address: dansimon@microsoft.com
Date first submitted: January 8, 2003
Document: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding= -01.txt
Reference: http://mail.frascone.com/pipermail/eap/2003-January/000485.html
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

My main concern with the document is that it doesn't seem to say
anything about the legacy/rollback issue. If both fixed and legacy
"clients (authenticators) and "servers" (verifiers)
have to interoperate with each other, then a
signaling mechanism *incorporated into, and detectable in, legacy
instances* is necessary to allow fixed clients and servers to = recognize
each other and avoid a rollback. Moreover, this signaling mechanism = has
the additional advantage of solving the MITM problem completely, all = by
itself, since it can be used to distinguish tunnelled from = untunnelled
authentications.
<jp>
version 2 draft text that addresses = this to some degree:
"For non-key deriving methods, = if they are modifiable, then using a signal to indicate when they are = running inside a tunnel would also prevent the attack. This works = because the server is able to distinguish between an attacker diverting = a method into a tunnel versus a client method intentionally initiated = inside a tunnel. However such signals need protection from = spoofing."

We treat it as not just as = legacy/rollback issue but for all non-key deriving methods that can be = modified. On the same note one of our solution requirements is that we = do not require changes to existing EAP authentication methods (not = tunneled ones).

</jp>

Now, if one side of the authentication can be assumed not to = include
legacy instances (e.g., all servers being upgraded simultaneously), = then
a carefully designed fixed protocol may suffice, without any = signaling
(e.g., an extra MAC is thrown into the protocol in both directions, = and
the fixed client will detect an attempted rollback attack when it
doesn't receive the expected returned MAC from the fixed server). = But
if both sides must interoperate with both fixed and legacy = counterparts,
then signaling within the legacy protocol must be used if rollback is = to
be prevented.
<jp>
Rollback attacks cannot be = completely avoided. Usage of policies to prevent rollbacks from being = requested by unknown clients is one-way to approach this problem. For = clients that are known, then some amount of out of band trust will have = to be established to guarantee that such an attack does not occur.

</jp>

For example, if, say, a compound key derivation solution is
used, then in the presence of both fixed and legacy clients and = servers,
some mechanism has to be found to negotiate whether to use the = "pure"
tunnel keys or compound keys. That mechanism needs to be such that,
say, fixed clients' messages can't be fiddled with to make them = look
like legacy clients' messages, or the MITM can do the conversion = and
force the server to roll back to the legacy protocol. On the other
hand, the fixed clients' messages must look enough like legacy = clients'
messages that legacy servers can accept and respond to them according = to
the legacy protocol. Hence the fixed clients' messages have to be
legacy-compatible messages with an indelible "signal" in them = that a
fixed server will recognize as indicating a fixed client.
<jp>
In the version 2 draft, there is = 'version' information included in the binding phase exchange to prevent = a fixed client from masquerading and performing an attack.

</jp>

But the presence of this signal also obviates the need for the = compound
key negotiation altogether; if fixed clients simply use the signal
whenever not tunnelling, then a tunnelling protocol server can = reject
all tunnelled authentications containing the signal, thus protecting = the
fixed client from MITM attacks even without any other protocol = change.
<jp>
Proposed points to capture in = version 3 draft update:
- Call out downgrade attacks more = succinctly
- Call out the two options to = prevent it
   1) If legacy methods = are modifiable, then use signals
   2) If binding phase = exchange is supported by the tunnel client and server, then prevent any = downgrade negotiation using policy

   For complete prevention = 1 or 2 must be supported.
</jp>
Is this acceptable?
best regards,
jose

------_=_NextPart_001_01C2F255.CBC3E470-- From johan.rh.hermans@alcatel.be Wed Mar 26 11:03:44 2003 From: johan.rh.hermans@alcatel.be (Jo Hermans) Date: Wed, 26 Mar 2003 12:03:44 +0100 Subject: [eap] Issue 100: User-Name in Access-Challenge and Access-Reject Message-ID: <3E818910.7020700@alcatel.be> See my original mail at http://mail.frascone.com/pipermail/public/eap/2003-March/000953.html and Bernard's reply at http://mail.frascone.com/pipermail/public/eap/2003-March/000954.html --------------------------------------------------------------- Issue 100: User-Name in Access-Challenge and Access-Reject Submitter name: Jo Hermans Submitter email address: johan.rh.hermans@alcatel.be Date first submitted: March 26, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-March/000954.html Document: Document Requiring change RFC 2869bis Comment type: Technical Priority: S Section: 2.1 Rationale/Explanation of issue: Paragraph 2.1 (Protocol Overview) mentions the attributes that should be present in acces-challenges and access-rejects : >The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in >the Access-Request packet, and either NAS-Identifier or NAS-IP-Address >attributes MUST be included. In order to permit forwarding of the >Access-Reply by EAP-unaware proxies, if a User-Name attribute was >included in an Access-Request, the RADIUS server MUST include the User- >Name attribute in subsequent Access-Challenge, Access-Accept or Access- >Reject packets. Without the User-Name attribute, accounting and billing >becomes difficult to manage. If the identity is determined by another >means, such as the Calling-Station-Id, the NAS MUST include these >identifying attributes in every Access-Request, and the RADIUS server >MUST copy these identifying attributes into subsequent Access-Challenge, >Access-Accept or Access-Reject packets. > But table 3.3 doesn't allow User-Name in access-challenges and access-rejects. That would be in violation of RFC2865 too. >Request Accept Reject Challenge # Attribute >0-1 0-1 0 0 1 User-Name > > Requested change: Either change paragraph 2.1 to : The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes very difficult to manage. If the identity is determined by another means, such as the Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request, and the RADIUS server MUST copy these identifying attributes into subsequent Access-Accept packets. or change table 3.3 to : Request Accept Reject Challenge # Attribute 0-1 0-1 0-1 0-1 1 User-Name -- Jo Hermans There are 10 types of people in this world, those who can count in binary and those who can't. From Pasi.Eronen@nokia.com Wed Mar 26 13:44:18 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 26 Mar 2003 15:44:18 +0200 Subject: [eap] Re: rfc2284bis issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122258@esebe023.ntc.nokia.com> Hi, I took a look at the latest (V7) peer state diagram, and it actually looks much better. The way the "strict interpretation" is handled actually seems to work reasonably well. I'm still wondering if we could "promote" some of methodState to a box of its own (splitting the IDLE state), but I guess it's not absolutely necessary. Some comments about the current version: - The methodState descriptions in -01 draft are not in sync with the diagram. For instance, SUCC is really "succeeds or continues or fails", because methods like GTC are always in SUCC state (because the client doesn't know if the conversation=20 will continue or not). - The FAIL and CONT methodStates are equivalent (same transitions occur for both), which probably means that either there's a problem in the diagram, or they need to be renamed (I can't find any serious problem there, so maybe it's the latter?). - How and where are Identity requests handled? Is Policy.allow(Identity) always true? (If necessary, this could be put to a box of its own, like Notifications) - How does the "handshake procedure" between EAP and lower layer actually work? More specifically, what happens if another request (or response on server side) arrives while processing the previous one? I guess it's either discarded, or put into a queue. =20 A straight-forward event-loop implementation (e.g. with select() and recvmsg() system calls) would queue it. But then we can't model the requirement "If a peer receives a duplicate Request before it has sent a Response, but after it has determined the initial Request to be valid (i.e. it is waiting for user input), it MUST silently discard the duplicate Request." (2284bis-01, section 4.1) =20 Some suggestions what refactoring could be done to make the diagram more understandable and precise: - Another problem with the current handshake procedure is that it won't work if the lower layer is also specified using a similar state machine. This is because e.g. eapResp is set to FALSE immediately after it's set to TRUE. If the lower layer state machine is doing something else (than sitting in "idle" state), this trigger will be lost. So, perhaps these variables should be replaced with procedures (e.g. change "eapResp=3DTRUE" to "sendResponse()", and "eapIgnore=3DTRUE" to "ignore()"). - I think we should make some of the data changes more visible. For example, currently lastId is never set anywhere. Also, the response packet data is somehow handled "behind the scenes". Proposal how this could be done: =20 - Create a SEND_RESPONSE box with contents "lastRespData=3DrespData;=20 lastId=3DcurrentId; send(respData)".=20 - Rename ACTIVE to RETRANSMIT, and change contents to=20 "respData=3DlastRespData;" - Change UCT transitions from NAK/NOTIFY/ACTIVE(RETRANSMIT) to IDLE to go via this box. - in METHOD state, set respData=3DbuildMethodResp(). I think this=20 is the logical place, instead of making the response in a separate=20 step. (change intCheck transition directly to SEND_RESPONSE state). Also, add "if (intCheck) {" after the first line, and "}" to end. - Minor adjustments in other states: in NOTIFY do=20 "eapRespData=3DbuildNotify()"; in NAK "respData=3DbuildNak(..)"; and also remove "eapResp=3DTRUE" from NAK/NOTIFY/ACTIVE(RETRANSMIT). - in DIALOG state, explicitly state which variables are set. =20 E.g. (rxMethodReq, rxSuccess, rxFailure, rxNotify, currentId,=20 currentMethod)=3DparseReceivedMessage()" - I think the discCount variable is unnecessary. It's not used anywhere, and there are many other statistics an implementation might want to collect, and events it might want to put in a log; we don't include those either. - Timeout is handled differently than in 802.1X (which has explicit=20 timer variables which are set and decremented; the "timeout=3DFALSE" = in=20 IDLE state =EDs quite different). Here's a version that incorporates some/most of these refactoring ideas: http://www.cs.hut.fi/~peronen/eap_state_machine_26032003.gif (No behavior changes were intended, so this does not address the issues at the beginning of the message) Best regards, Pasi From jrv@umich.edu Wed Mar 26 16:05:27 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 26 Mar 2003 11:05:27 -0500 Subject: [eap] Re: rfc2284bis issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122258@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122258@esebe023.ntc.nokia.com> Message-ID: <523207.1048676723@[10.0.1.2]> I haven't been able to go over this completely, but here are some quick=20 reactions. we should talk during the conf call or later. Thanks for the=20 thoughtful comments. --On Wednesday, March 26, 2003 3:44 PM +0200 Pasi.Eronen@nokia.com wrote: > Hi, > > I took a look at the latest (V7) peer state diagram, and it > actually looks much better. The way the "strict interpretation" > is handled actually seems to work reasonably well. I'm still > wondering if we could "promote" some of methodState to a box of > its own (splitting the IDLE state), but I guess it's not > absolutely necessary. > > Some comments about the current version: > > - The methodState descriptions in -01 draft are not in sync > with the diagram. For instance, SUCC is really "succeeds or > continues or fails", because methods like GTC are always in > SUCC state (because the client doesn't know if the conversation > will continue or not). true > > - The FAIL and CONT methodStates are equivalent (same > transitions occur for both), which probably means that either > there's a problem in the diagram, or they need to be renamed > (I can't find any serious problem there, so maybe it's the > latter?). > good point. I think that what is now STRICT was CONT. We need to decide how to deal with this. My suggestion is to rename = STRICT to CONT. > - How and where are Identity requests handled? Is > Policy.allow(Identity) always true? (If necessary, this could > be put to a box of its own, like Notifications) > Identity requests are treated as any other req. Identity is not allowed=20 within STRICT methods. > - How does the "handshake procedure" between EAP and lower > layer actually work? More specifically, what happens if > another request (or response on server side) arrives while > processing the previous one? I guess it's either discarded, or > put into a queue. > there is a 802.1x diagram that shows how 802.1x state machine deals with=20 this. see http://www-personal.umich.edu/~jrv/eap.htm and look at 802.1x=20 update at IEEE in Dallas. > A straight-forward event-loop implementation (e.g. with > select() and recvmsg() system calls) would queue it. But then > we can't model the requirement "If a peer receives a duplicate > Request before it has sent a Response, but after it has > determined the initial Request to be valid (i.e. it is waiting > for user input), it MUST silently discard the duplicate > Request." (2284bis-01, section 4.1) > > Some suggestions what refactoring could be done to make > the diagram more understandable and precise: > > - Another problem with the current handshake procedure is that > it won't work if the lower layer is also specified using a > similar state machine. This is because e.g. eapResp is set to > FALSE immediately after it's set to TRUE. If the lower layer > state machine is doing something else (than sitting in "idle" > state), this trigger will be lost. So, perhaps these variables > should be replaced with procedures (e.g. change "eapResp=3DTRUE" > to "sendResponse()", and "eapIgnore=3DTRUE" to "ignore()"). > I have to look at this - eapResp and eapIgnore are signals to the lower=20 layer. we may be wrong to reset them. > - I think we should make some of the data changes more > visible. For example, currently lastId is never set > anywhere. Also, the response packet data is somehow handled > "behind the scenes". Proposal how this could be done: > lastid should be fixed. I am not sure I understand the rest of this. I=20 think it would be useful to show where the response data is created and=20 have a variable that holds it. We should talk this through. > - Create a SEND_RESPONSE box with contents "lastRespData=3DrespData; > lastId=3DcurrentId; send(respData)". > - Rename ACTIVE to RETRANSMIT, and change contents to > "respData=3DlastRespData;" > - Change UCT transitions from NAK/NOTIFY/ACTIVE(RETRANSMIT) to IDLE > to go via this box. > - in METHOD state, set respData=3DbuildMethodResp(). I think this > is the logical place, instead of making the response in a separate > step. (change intCheck transition directly to SEND_RESPONSE state). > Also, add "if (intCheck) {" after the first line, and "}" to end. > - Minor adjustments in other states: in NOTIFY do > "eapRespData=3DbuildNotify()"; in NAK "respData=3DbuildNak(..)"; > and also remove "eapResp=3DTRUE" from NAK/NOTIFY/ACTIVE(RETRANSMIT). > - in DIALOG state, explicitly state which variables are set. > E.g. (rxMethodReq, rxSuccess, rxFailure, rxNotify, currentId, > currentMethod)=3DparseReceivedMessage()" > > - I think the discCount variable is unnecessary. It's not used > anywhere, and there are many other statistics an implementation > might want to collect, and events it might want to put in a log; we > don't include those either. > > - Timeout is handled differently than in 802.1X (which has explicit > timer variables which are set and decremented; the "timeout=3DFALSE" in > IDLE state =EDs quite different). > > Here's a version that incorporates some/most of these refactoring ideas: > http://www.cs.hut.fi/~peronen/eap_state_machine_26032003.gif > > (No behavior changes were intended, so this does not address the > issues at the beginning of the message) > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Mar 26 17:27:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 26 Mar 2003 09:27:36 -0800 (PST) Subject: [eap] Re: Issue 100 Message-ID: I've made the requested change in RFC 2869bis-11. Take a look at the text and see if it looks ok: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-11.txt From jari.arkko@piuha.net Fri Mar 28 15:57:19 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 28 Mar 2003 17:57:19 +0200 Subject: [eap] ietf-56 eap meeting notes Message-ID: <3E8470DF.6010407@piuha.net> This is a preliminary version of the meeting minutes. Please e-mail the chairs if we missed something or if you took additional minutes that aren't already described here. Thank you Henrik and Paul for taking notes. And Paul: did you have a measurement tool for the decibel numbers that you documented as a result of the hums? ;-) ---- Minutes from the IETF-56 Extensible Authentication Protocol WG (eap) meeting CHAIRS: Bernard Aboba Jari Arkko PRESENTATIONS: http://www.drizzle.com/~aboba/IETF56/EAP MINUTES: Henrik Levkowetz and Paul Funk (edited by Jari Arkko) SESSION 1: Monday, March 17 at 1530-1730 1. Preliminaries (10 minutes) - Bluesheets - Minute Takers - Agenda Bashing Jari summarized the agenda for today and thursday, and asked for comments - none. 2. Networld+Interop (Karen O'Donoghue) N+I (in three short weeks) will have MPLSI 802.1x demo and a 3-day interoperability test session for EAP methods. Methods to be tested include EAP-TLS, EAP-TTLS, and EAP-PEAP, as well as a variety of inner methods. Please come, and bring your EAP method (better tell her first, though). 3. IEEE 802.11 Request (Dorothy Stanley) Dorothy represents the IEEE 802.11 group and is responsible for liaison with the IETF. The IEEE, as a user of IETF protocols, in particular EAP and RADIUS, has formally requested guidance in selection of EAP methods to meet their security goals, in the following categories: methods of authentication via certificate, user-password and GSM/UMTS secrets; key strength and key material; mutual authentication; resistance to dictionary attack; thwarting of MitM attack; replacement for EAP-MD5-Challenge (which is subject to MitM attack). In addition to the 802.11i work, another group is working on inter-access-point protocols, which will utilize RADIUS. 4. Document status Jari summarized the document status: - 2284bis - a lot of issues handled, plan a WG last call when all issues closed. Pointed out that the background for 2284bis is unclear parts of 2284, and having interoperability problems. The goal for 2284bis is to clarify unclear points and ensure interoperability, and *not* add new features. - There's documents for EAP state machine, keying framework, and others. Mentioned the requirements for adopting new documents as working group items. Drafts adopted as working group items must have a level of maturity; there should have been significant review already performed and all major issues should already have been resolved. Bernard added timeframe: June for Keying document. Things may be dropped rather than let them slide. 5. RFC 2284bis, Henrik Levkowetz and Jari Arkko http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt Three major outstanding issues were presented, and a vigorous discussion ensued. Issue 80 - Is EAP-Success required? - There was some discussion of whether the new draft should allow the client to acknowledge success, whether particular EAP types should provide alternative means to acknowledge success, whether all methods that don't perform mutual authentication should be abolished. - Henrik made clear that this issue does not pertain to the authenticator, which always must issue Success if the authentication was successful. However, there are several choices for client behavior: (a) Client does not require Success. (b) Client requires Success, or it must refuse to proceed with connection. (c) Client normally requires Success, but if there is an alternative indication that implies Success client may proceed with connection. - Hum results: (a) inaudible (b) -70 dB (c) -43 dB Loudest: (c) Issue 97 - May packets of another type interrupt an authentication sequence (strict mode) - Some confusion was expressed by commentators as to whether this relates to serial authentications or interruptions of a sequence which may not have completed (e.g. DoS). Also the question was brought up as to whether the authenticator should be allowed to switch to a different method before the first completed; for example, if the authenticator determines that the original method cannot complete and wishes to try an alternative without failing the user. - In the interest of assessing how this decision would affect existing deployments, various implementors rose to describe how badly their code would react to receiving packets of unexpected type, though nobody actually shared source code. - Choices were: (a) Yes, they may (no strict mode). (b) No, and this is enforced by the state machine discarding packets of unexpected type (strict mode). (c) Not really, but this is enforced by state machine in consultation with currently running type, so exceptions may be made (limited strict mode). - Hum results: (a) -10 dB (disqualified because it originated from a single point source) (b) -50 dB (c) -49 dB Loudest: (c) Issue 87 - Type change during method - This issue was admittedly closely related to the previous (97). The issue pertains both to the authenticator switching to a new type before the first is complete and starting a new type after the first is complete (serial authentication). - Jesse Walker pointed out a use case for serial authentication that someone may actually want to do: authenticating first the machine, and then the user of the machine. - John Vollbrecht argued that a type change in the middle of a sequence can be distinguished by the client from serial authentication after the first type is complete, and therefore type change should not be outlawed. He also felt that behavior in this regard is a security choice, but should not constrain the protocol. - There was discussion as to whether the client can know that a method has completed. For example, it will know when it has successfully authenticated the server, but may not know whether the server has completed its authentication of the client. - Bernard Aboba felt that allowing type change would pose a challenge to existing implementations. Also, sentiments were expressed that serial authentication would pose problems to the state machine. Jose Puthenkulam argued that the key binding problem, absent a single EAP method that embraces the serial methods, is an open-ended one whose solution is not yet known. - The choices were how strongly to discourage type change: (a) The authenticator SHOULD NOT perform a type change. (b) The authenticator MUST NOT perform a type change. - Hum results: (a) -60 dB (b) -47 dB Loudest: (b) But with the following provision: There may be only a single outer EAP type. However, that type itself may tunnel EAP types, of which there may be multiple. The outer protocol is responsible for defining how that is done and how the results of the inner types are combined to produce a unified session key. 6. EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt Presentation from Pascal about the capabilities of smartcards and the interface to EAP proposed for smartcards. Pascal described an API that would allow EAP to be embedded in a SmartCard. The SmartCard would receive EAP packets from and send them to the network, and perform all cryptographic processing internally as a closed system. A management interface would allow client software to provision the SmartCard with identities, policies, etc. Such a SmartCard could handle protocols such as EAP-SIM, EAP-TLS, etc. No questions 7. Compound Binding, Jose Puthekulam, 10 minutes http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt Presentation from José on compound methods. Turns out that there are man-in-the-middle attacks possible on tunnelled compound methods. Compound tunnelled methods may be used in order to - Secure legacy methods in new environments - Ease of deployment for securing legacy methods - Providing consistent security properties and other features for different methods - Securing multiple credentials in sequences. Non-tunnelled compound sequences are also potentially vulnerable but not addressed by this draft. Requirements for the attack: - The MITM is able to run dual roles - rogue authenticator and rogue supplicant - Creds and method re-used with and without tunnel - Tunnel is one-way server authenticed - Use of tunnel session keys alone and no inner method session keys Yoshi: I believe that #3 is not necessary - it's possible also for mutually authenticated tunnells. Jose: Yes, but that's a *trusted* MitM - in which case all bets are off. Jose then laid out a general framework for providing solutions to the problem. Some of the solutions are policy-based (e.g. don't do that); others are cryptographic. Possible solutions: - for non-key deriving methods * Use of separate credentials inside and outside tunnels breaks the attack. * Always use methods inside tunnels?? - for key-deriving methods * Use cryptogrphic bindings: + Compound Keyed MACs + Compound Session keys The attack may be foiled either at the point of authentication or at the point of use. That is, there may be an additional authentication step to assure both parties of the absence of an MitM, or the validity of session keys generated for the connection may be made to depend on absence of MitM. Jose favors the former, as it nips the problem in the bud and precludes a connection from even being set up. Allowing the connection to be set up (only to fail to operate) is expensive and therefore encourages DoS attacks. Jose presented the notion of a "binding phase", which uses single round-trip cryptographic algorithm to perform the compound authentication at the conclusion of the EAP sequence. Bernard asked (a) which PRF is used in the binding phase, and (b) whether this is compatible with IKE v2. Jose replied that (a) each tunneling protocol selects its PRF, and (b) each tunneling protocol defines and exports its own session keys, so the tunneling protocol is independent of the context in which it is carried and is therefore compatible with IKE v2. SESSION 2: Thursday, March 17 at 1530-1730 8. RFC 2869bis, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt Bernard summarised the status of RFC2869bis, there's one open issue currently. A lot of little nits have been fixed. The open issue is "The lying NAS problem", described in the slides (RFC2869bis) Bernard then described some other issues which has come up: Issue 83, where an AAA server can receive an invalid EAP packet from an authenticator in passtrough mode. The message cannot be just dropped, as the authenticator will retransmit. Details of the proposed resolution in the slides. 9. EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt Jesse Walker talked about EAP Archie, a proposed solution to the problem that none of the current mandatory 2284 methods are suitable to 802.11. Archie would if accepted be a new mandatory EAP method. The Archie exchange consists of the following message exchanges (see slides [Archie] for details <-- Random Session ID (Request) Hash of Session ID, Random Nonce, Binding (MAC addresses), MIC --> <-- Hash of prev Msg, Encrypted Nonce, Binding(MAC addresses), MIC Finish: Hash, MIC --> Can the EAP MD5 Challenge method be deprecated? Can EAP-Archie be adapted to be suitable for PPP? Is there interest in taking on this work? Simon Misikowski: What kind of hashes? Jesse: The hashes are SHA hashes. Bob Moskowitz: How would this work with a Proxy RADIUS? Not sure that EAP-AKA doesn't also meet the 802.11 requirements? Alper Yegin: Why should the method be made more suitable for it's transport (PPP) Jesse: I'm asking for input, ... Alper Yegin: WLAN is primary transport? We may need to change it to adapt to other protocols? Jesse: We'd have to look at whatever is needed to adapt it. ?: Looking at the differences between this and AKA. There's also the ESE, which should be compared Joe Salowey: I liked the binding aspect, we may need to look at introducing this other places or in a generic fashion? 10. EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt Bernard presented Goals and Objectives for EAP Keying. Slides [Keying]. This is a framework for evaluate keying methods, rather than a proposal of methods. Further: EAP Invariants for keying methods, Terms for Master Key Types, ... Paul Congdon: Should you define the length of these keys if you are trying to be ciphersuite independent? Bernard Aboba: You might get suites deriving keys with different length, maybe quite short keys. The answer could be to require ridiculously large keys, or to settle on lengths which are currently sufficient. Simon (?): The MSK could be derived from the EMSK (or MK)? Bernard Aboba: No, but the EMSK should be cryptographically independent from the MSK Simon: What is the purpose? Bernard Aboba: Purpose not defined yet, but its essence is that it is known by Peer and Server, and *not* by NAS. The MK is never exported. So Bob Moskowitz: The MSK is known by at least 3 parties, and the 64 bytes keying material - it is distinct from the entroyp. This defines the key lenght, not the key strength. Bernard Aboba: Yes. Bernard, continuing presentation, covering: EAP Key Hierarchy, EAP (Key) Exchanges (two-way exchange, three-way-exchanges), The EAP (Bermuda) Triangle, Security Requirements, Open Issues. The Open Issues were: Issue 15, missing sequirty requirements Issue 47, key requirements unspecified (why 64 bits) what about specifying key strength? Issue 99, Double expansion, is this acceptable T.J. Kniveton: You said you couldn't get a MK out of a SIM card, but section 17 of the draft describes certain derivations Bernard Aboba: There were papers written which assumed you could get the MK out of the SIM, but we needed to clarify that the MK cannot and need not leave the SIM card or the MK box in the Key Hierarchy. Joe Salowey: There are implementations of EAP SIM where the entire calculation takes place on a SIM card. Bob Moskowitz: FIPS has a document which has a key derivation proces which which we maybe we should look at, to make sure it is compatible. May need this in order to be FIPS compliant. Bernard Aboba: The document won't recommend a KDF, but it will pose requirements on KDFs. John Vollbrecht: Wanted a clarification on which keys are carried where. Bernard Aboba: (Clarification given.) John Vollbrecht: Is it likely that these things will change in the future? Bernard Aboba: If we've done a good job, this should be future proof. John Vollbrecht: Can these keys be taken out of the method? Bernard Aboba: Only the MSK leaves the method. Simon: Client is roaming; while in a session, which key is transported to the new (target) NAS? Bernard Aboba: None - you don't transport keys between NAS'es. Some proposals derive different keys from one EMSK to multiple NAS keys, but it is not wise to pass keys between NASes. Simon: But there has to be a coupling between EMSK and TSK, so... Bernard Aboba: There are example formulas and methods in the Appendix (Further explanation). Glenn Zorn: -- Long silence, looking at EAP key hierarchy. Is it true you're treating these entities equally - including a proxy? Bernard Aboba: Yes, although it gets complicated when you have a proxy. Glenn Zorn: It could be handy to have a key known to all, but only useful for a certain purpose, such as AAA interchanges? Bernard Aboba: Yes, but there's a question here from where you derived such a key - and depending on where you derived it from, would it be secret to the people it needed to be secret from? I.e. which key tree should you John Vollbrecht: Are there 1 quantity exported from AAA server? Bernard Aboba: There are 3 entities derived, and 1 exported. Dan Forsberg: Do you specify or recommend any lifetimes for these keys, and if some time out, how do they get renewed, and can ESMK be used for session resumptions? Bernard Aboba: The EMSK is *not* used to resume sessions, because it is known by more than 2 parties. We have talked about including a key lifetime parameter, but currently the key lifetime is equal to the session lifetime, but there's a question if that's sufficient or not. 11. EAP Key Derivation for Multiple Applications, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt Joe Salowey made a presentation on EAP Key Derivation For Multiple Applications. See slides. Highlights: Motivation, Applications (WEP, 802.11i, MPPE, Fast Roaming, ...) Requirements, Key Derivation, and currently open issues. Bernard Aboba: How do we figure out how much material should be derived? Joe: 64 bytes are a lot of material. We need to get input from security experts. Simon: Lucent put out some papers, for 3GPP and 3GPP, requrements on keys for them to be acceptable in 20 years. The resulting key strength (entropy) of 84 bits. Joe Salowey: Yes, 64 bytes are much. Alper Yegin: Any constraints on which applications may use this? Joe: I'd rather make keying materials available to application that needs it, rather than making restrictions. Alper Yegin: There may be security considerations with making keying material available to random applications. Bernard Aboba: Did you choose TLS for some particular purpose, or as just an example? Joe Salowey: No particular significance. Simon: (Examples of other possible KDF). Bob Moskowitz: (Pointed out which documents in the references needed to be looked at in relation to this). 12. EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes Erik Nordmark made a presentation about Methods, Methods, Methods, Or When can we start talking about methods? (See Slides). Highlights: Requirements, Simon: 3GGP2 Requirements should also be considered. Bernard Aboba: We don't have a liaison with 3GPP2 yet? In the case of IEEE and 3GPP, they have to us and told their requirements. Simon: Interoperation between 802.11 and CDMA is an active work item within 3GPP2. You're welcome to get all requirement from the 3GPP2 web site. Erik continued: Selecting methods?, Strawman proposal: Methods can be submitted as individual submission RFCs, need Expert Review but that can start now. Method RFCs must depend on the new versions of RFC 2284 etc, however. Keep MD5 as mandatory, Capture requirements from different scenarios in an informational RFC, start work on a BCP which captures mapping from environments to appropriate methods, and possibly later pick new mandatory methods. Not select methods for other SDOs. John Vollbrecht: We need to test interoperability, so we need some mandatory methods that exercise the features we have in our protocols. Bernard : The reason 802.11 have asked for a new mandatory method is that they are not sure they could do it themselves, so this might leave them in a bit of a quandary. Bob Moskowitz: IEEE ... They have tradentionally have been reluctant to mess with other organizations babies. EAP is your method, so please make it acceptable to our needs. We should make sure that within a year we can provide what they need, a specification of what should be used. A BCP might be good enough, it mustn't necessary be a Standard. Alper: Agree with the strawman approach, it seems a way to go forward without specifying a new mandatory method for each new interested party - IEEE, 3GPP, 3GPP2, ... Simon: The original requirements originally came from 802.11? So whatever we present to them, it will be up to them to select from whatever smorgasbord we present to them. 64 bits, is that their req? Bob Moskowitz: Yes. Simon: and mutual authentication came from them? Bob Moskowitz: Yes. Dave (?): We need to have a recommendation of a mandatory method for use with 802.1i, and this is really out of our scope, this belongs to IETF. We need a published document we can reference in our documents, pointing out a method we can use. Erik Nordmark: So a BCP would be enough, a PS is not needed? John Vollbrecht: We need a specified method in order to measure interoperability Bob Moskowitz: Any methods we can get out quicker rather than later, in the form of an RFC rather than just a draft, makes it possible for them (802.xx) to reference it, and say to vendors "these are the methods to use, go out and implement them" 13. IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 minutes Paul Congdon made a presentation on alignment of different 802.xx and EAP RFCs. (See slides) Highlights: Current status, Document List, Proposed and Agreed Changes to 802.1aa/D5, EAP/802.1X Interface, Key Interface with EAP, 802.1X, 802.11, LinkSec Task Group Formation in 802.1 14. EAP State Machine, John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt John Vollbrecht made a presentation on EAP State Machines. (See Slides). Highlights: URL's, State Machine Style, EAP Mux Model, Peer State Diagram (802.xx style state machine), Pass through, Policy Functions, State Machine next steps, 15. EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.txt Joe Salowey, presentation on Protected EAP-TLV, a way to protect a (tunnelled) series of TLV's. (See Slides), and continued with EAP-Authorization, a method to request authorization for services and session attributes (See Slides) Dave (?): Which endpoints would exchange these TLVs? Joe Salowey: Supplicant and Auth. Server. John Vollbrecht: Is this going to be a method? Joe Salowey: Right now it's just a TLV, and maybe it makes sense to make it a method, but I don't know if it must be. John Vollbrecht: So it could be tagged into other methods? Joe Salowey: Essentially a method, could come at the end of other methods. Could happen inside an EAP message. John Vollbrecht: So I could run EAP within EAP within EAP... 16. EAP SIM and AKA, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt Joe went on with a presentation on EAP-SIM drafts (multiple). (See Slides). Bob Moskowitz: I'd like to see a change in the AKA draft, to talk about a shared secret method, and then a particular GSM application in an Appendix Jari Arkko: So this is only a question of a change in terminology? Bob Moskowitz: Yes, and mapping to GSM terminology as a separate part. Jari Arkko: I think we can do this. Simon: How does SIM fill the 128 bits requirement? Joe: You use multiple triplets. Simon: These triplets doesn't provide mutual auth? Joe: No, but EAP-SIM does provide mutual auth based on these. Bernard suggested that even if this is not yet a WG document, the authors should already now get security reviewers, to speed up the process. 17. Tunneled MD5, Paul Funk, 5 minutes http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt Paul Funk made a presentation on The EAP MD5 Tunneled Authentication Protocol. (See Slides). This is an attempt to cure the MITM problem for tunnelled operation, (the Puthenkulam draft) 18. Meeting ended. From jose.p.puthenkulam@intel.com Fri Mar 28 19:28:44 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 28 Mar 2003 11:28:44 -0800 Subject: [eap] Compound Authentication Draft Message-ID: Hi Joe, Thanks for your scenario. Some comments below > -----Original Message----- > From: Joseph Salowey [mailto:jsalowey@cisco.com] > Sent: Monday, March 24, 2003 12:27 PM > To: eap@frascone.com > Subject: [eap] Compound Authentication Draft > > > A similar problem exists with compound authentication even when a > mechanism is used only within secure tunnels. A appropriate use of > policy can be used to reduce the vulnerability and I think it > should be noted in the document. Surely, can consider if the attack is really a genuine worthwhile case. > > Take a mechanism such as MSCHAPv2 which is secure against a man it the > middle and generates session keys which can be used to protect > additional data and further prevent a man in the middle. This method > can be used securely by itself. > > Take an example using MSCHAPv2 inside of a mechanism such as PEAP. > Party A can establish a secure connection to party B by establishing > PEAP and verifying B's identity. B can then request that A > authenticate > with MSCHAPv2. A will perform MSCHAPv2 authentication with B. So B is the final authentication server. Also PEAP stage 1 helped A validate B's identity and expects B to be a good trustworthy server. > B can open up another PEAP session to C. B can proxy the MSCHAPv2 > authentication to C and authenticate as A. B can now carry on a > conversation with C as if he were A. So here B the final authentication server that A trusted, proxies A's authentication to another server C. So basically B has violated A's trust in totality. Now what did A trust B for? The PEAP stage 1 between A and B seems to have no meaning? I guess all bets are off at this point. > This attack can be avoided if A > has an appropriate policy configuration or if A can detect that the > identity authenticated as B during PEAP is not equivalent to the > identity authenticated as B in the MSCHAPv2 conversation and abort the > authentication before it completes. But this doesn't help even if B has one single identity on ten identities which you are trying to prove, because B is inherently not trust worthy. What prevents B from shipping the shared secret to C? > In practice it may be difficult to verify that one identity is or is not equivalent > because of different identity formats used in different credential types. Are you suggesting PEAP stage 1 certificate validation is not meaningful? > > This is a result of a faulty trust relationship. In a sense if B is a > malevolent entity A should not allow the connection since it > should know there is no way that B should not have access to the > credentials used by the inner method (MSCHAPv2 in this case). This sort of > determination > may be difficult in practice. What you are challenging here is basic trust for transactions? Its an unsolvable problem except through detection and appropriate post-event action. >It also means that any entity that you > trust to participate with in an inner authentication > mechanism you must > also trust to be able to impersonate you. In your description B actually was trusted by A not to impersonate it. > More investigation > is needed > to see if this is really a problem (intuitively I think it is > a problem, > but I haven't had a chance to think it through). > > A solution to this problem is for the client to have a policy that > limits which inner authentication methods and credentials can be used > based on the identity authenticated in the outer tunnel (it seems that > this should exist in implementations already). The client > mechanism may > also have a policy that aborts the authentication if it is determined > that the identity validated in the inner mechanism is not the same as > the identity validated in the outer mechanism (with some > mechanism this > may be impossible as the server identity may not be known until the > authentication completes). Cryptographic binding may also > help in this > case. Cryptographic binding is not a cure-all. Fundamentally it is just trying to provide mutual authenitcation where it didn't exist. But if entities violate trust then it won't help anways. best regards, jose From jsalowey@cisco.com Fri Mar 28 20:32:00 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 28 Mar 2003 12:32:00 -0800 Subject: [eap] Compound Authentication Draft In-Reply-To: Message-ID: <00cd01c2f569$16988260$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Puthenkulam, Jose P > Sent: Friday, March 28, 2003 11:29 AM > To: 'Joseph Salowey'; eap@frascone.com > Subject: RE: [eap] Compound Authentication Draft > > > Hi Joe, > > Thanks for your scenario. Some comments below > > > -----Original Message----- > > From: Joseph Salowey [mailto:jsalowey@cisco.com] > > Sent: Monday, March 24, 2003 12:27 PM > > To: eap@frascone.com > > Subject: [eap] Compound Authentication Draft > > > > > > A similar problem exists with compound authentication even when a > > mechanism is used only within secure tunnels. A appropriate use of > > policy can be used to reduce the vulnerability and I think > it should > > be noted in the document. > > Surely, can consider if the attack is really a genuine > worthwhile case. > > > > Take a mechanism such as MSCHAPv2 which is secure against a > man it the > > middle and generates session keys which can be used to protect > > additional data and further prevent a man in the middle. > This method > > can be used securely by itself. > > > > Take an example using MSCHAPv2 inside of a mechanism such as PEAP. > > Party A can establish a secure connection to party B by > establishing > > PEAP and verifying B's identity. B can then request that A > > authenticate > > with MSCHAPv2. A will perform MSCHAPv2 authentication with B. > > So B is the final authentication server. Also PEAP stage 1 > helped A validate B's identity and expects B to be a good > trustworthy server. > [Joe] What does trustworthy mean? Just because I "trust" B for some things does not mean that he should be able to impersonate me. This is all or nothing "trust" which is not so good. > > B can open up another PEAP session to C. B can proxy the MSCHAPv2 > > authentication to C and authenticate as A. B can now carry on a > > conversation with C as if he were A. > > So here B the final authentication server that A trusted, > proxies A's authentication to another server C. So basically > B has violated A's trust in totality. Now what did A trust B > for? The PEAP stage 1 between A and B seems to have no > meaning? I guess all bets are off at this point. > [Joe] Here the problem is that if the inner protocol is not run inside of PEAP then B could not send data to C as A. A may trust B to do somethings for him and not others. For example A may want sotck quites from B, probably he does not want B to impersonate him. > > This attack can be avoided if A > > has an appropriate policy configuration or if A can detect that the > > identity authenticated as B during PEAP is not equivalent to the > > identity authenticated as B in the MSCHAPv2 conversation > and abort the > > authentication before it completes. > > But this doesn't help even if B has one single identity on > ten identities which you are trying to prove, because B is > inherently not trust worthy. What prevents B from shipping > the shared secret to C? > [Joe] Again I am not sure what you mean by trustworthy. B can be trusted for some things, but he should not be able to impersonate A. If B has access to the shared secret then all bets are off, however it is not required for B to have access to a shared secret. B only needs to have access to the authentication messages. > > In practice it may be difficult to verify that one identity > is or is > > not > equivalent > > because of different identity formats used in different credential > > types. > > Are you suggesting PEAP stage 1 certificate validation is not > meaningful? > [Joe] Not at all. I am saying it is not just sufficient to validate a certificate. You must make sure that the stage two credentials you use inside the tunnel can only be used with B or you must accept the fact that B can use to credentials to authenticate as you to another service that uses the same credentials. Note that in a AAA or public key models the authenticating parties do not have access to shared secrets. > > > > This is a result of a faulty trust relationship. In a > sense if B is a > > malevolent entity A should not allow the connection since it should > > know there is no way that B should not have access to the > credentials > > used by the inner method (MSCHAPv2 in this case). This sort > of > > determination > > may be difficult in practice. > > What you are challenging here is basic trust for > transactions? Its an unsolvable problem except through > detection and appropriate post-event action. > [Joe] No, again you must be careful with the word trust. The basic principal is that I trust B for somethings, but A really doesn't want him to be able to athenticate to another party as A. > >It also means that any entity that you > > trust to participate with in an inner authentication > > mechanism you must > > also trust to be able to impersonate you. > > In your description B actually was trusted by A not to > impersonate it. > [Joe] No, B is "trusted" for certain services". B should not be able to impersonate A if a reasonable authentication mechanism is used. The inner protocol by itself is not subject to impersonation by a man in the middle, only when it is used in PEAP is it subject to this attack. > > More investigation > > is needed > > to see if this is really a problem (intuitively I think it is > > a problem, > > but I haven't had a chance to think it through). > > > > A solution to this problem is for the client to have a policy that > > limits which inner authentication methods and credentials > can be used > > based on the identity authenticated in the outer tunnel (it > seems that > > this should exist in implementations already). The client > mechanism > > may also have a policy that aborts the authentication if it is > > determined that the identity validated in the inner > mechanism is not > > the same as the identity validated in the outer mechanism (with some > > mechanism this > > may be impossible as the server identity may not be known until the > > authentication completes). Cryptographic binding may also > > help in this > > case. > > Cryptographic binding is not a cure-all. Fundamentally it is > just trying to provide mutual authenitcation where it didn't > exist. But if entities violate trust then it won't help anways. > [Joe] Actually in this case it will. > best regards, > jose > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jose.p.puthenkulam@intel.com Fri Mar 28 23:43:21 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 28 Mar 2003 15:43:21 -0800 Subject: [eap] Compound Authentication Draft Message-ID: Some more comments. Also I've only taken the pertinent parts of the last email that refers to the attack. > > > Take an example using MSCHAPv2 inside of a mechanism such > > > as PEAP. > > > Party A can establish a secure connection to party B by > > > establishing > > > PEAP and verifying B's identity. B can then request that A > > > authenticate > > > with MSCHAPv2. A will perform MSCHAPv2 authentication with B. > > > B can open up another PEAP session to C. B can proxy the > > > MSCHAPv2 > > > authentication to C and authenticate as A. B can now carry on a > > > conversation with C as if he were A. > > > > So here B the final authentication server that A trusted, > > proxies A's authentication to another server C. So basically > > B has violated A's trust in totality. Now what did A trust B > > for? The PEAP stage 1 between A and B seems to have no > > meaning? I guess all bets are off at this point. > > > > [Joe] Here the problem is that if the inner protocol is not run inside > of PEAP then B could not send data to C as A. A may trust B to do > somethings for him and not others. For example A may want > sotck quites > from B, probably he does not want B to impersonate him. > Looks like I'm not comprehending the attack you describe. So here's an attempt to clarify... Tell me if your case is as follows: So A wants some service from B we call S1 and it uses identity IA1 for it. The MS-CHAPv2 credentials used were intended to get access for this service S1 from B. So this was in context of PEAP session BA (B authenticated by A). Now C offers service S2 to A and B and the identities for access are IA2 and IB2 and MSCHAPv2 is the method used. So B after setting up PEAP session with A now has a separate PEAP session CB with B (C authenticated by B). So when A authenticates with B for S1 it uses identity IA1. If A authenticates with C for S2 it would use IA2 right? How would A ever disclose IA2 to B when B doesn't provide the service S2? I agree the attack you describe is possible if A uses identity IA2 to access service from C but thru B. Why would this happen? Can you give an example. Is your case when A has the same identity IA1=IA2 for both services S1 and S2? best regards, jose From jsalowey@cisco.com Sat Mar 29 00:04:24 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 28 Mar 2003 16:04:24 -0800 Subject: [eap] Compound Authentication Draft In-Reply-To: Message-ID: <010c01c2f586$c2a76bd0$0200000a@amer.cisco.com> Hi Jose, I think we are getting close. > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Friday, March 28, 2003 3:43 PM > To: 'Joseph Salowey'; eap@frascone.com > Subject: RE: [eap] Compound Authentication Draft > > > Some more comments. Also I've only taken the pertinent parts > of the last email that refers to the attack. > > > > > Take an example using MSCHAPv2 inside of a mechanism such > > > > as PEAP. > > > > Party A can establish a secure connection to party B by > > > > establishing > > > > PEAP and verifying B's identity. B can then request that A > > > > authenticate > > > > with MSCHAPv2. A will perform MSCHAPv2 authentication with B. > > > > B can open up another PEAP session to C. B can proxy the > > > > MSCHAPv2 > > > > authentication to C and authenticate as A. B can now > carry on a > > > > conversation with C as if he were A. > > > > > > So here B the final authentication server that A trusted, > > > proxies A's authentication to another server C. So basically > > > B has violated A's trust in totality. Now what did A trust B > > > for? The PEAP stage 1 between A and B seems to have no > > > meaning? I guess all bets are off at this point. > > > > > > > [Joe] Here the problem is that if the inner protocol is not > run inside > > of PEAP then B could not send data to C as A. A may trust B to do > > somethings for him and not others. For example A may want sotck > > quites from B, probably he does not want B to impersonate him. > > > > Looks like I'm not comprehending the attack you describe. So > here's an attempt to clarify... Tell me if your case is as follows: > > So A wants some service from B we call S1 and it uses > identity IA1 for it. The MS-CHAPv2 credentials used were > intended to get access for this service S1 from B. So this > was in context of PEAP session BA (B authenticated by A). > [Joe] So far so good > Now C offers service S2 to A and B and the identities for > access are IA2 and IB2 and MSCHAPv2 is the method used. So B > after setting up PEAP session with A now has a separate PEAP > session CB with B (C authenticated by B). > [Joe] The identity for A is the same IA1. Service is not offered to B and IB2 does not exist > So when A authenticates with B for S1 it uses identity IA1. [Joe] OK > If A authenticates with C for S2 it would use IA2 right? [Joe] It uses IA1 (same identity for both services) How > would A ever disclose IA2 to B when B doesn't provide the service S2? > [Joe] Same identity both services. > I agree the attack you describe is possible if A uses > identity IA2 to access service from C but thru B. Why would > this happen? Can you give an example. > [Joe] This is not the case I was thinking about, but in this case it would have had to use the incorrect credential based on the identity B. This could be done thrugh incorrect configuration or perhaps some clever manipulation by B to make things appear to be C (except for the server side auth). > Is your case when A has the same identity IA1=IA2 for both > services S1 and S2? > [Joe] Yes. > best regards, > jose > From jose.p.puthenkulam@intel.com Sat Mar 29 01:12:30 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 28 Mar 2003 17:12:30 -0800 Subject: [eap] Compound Authentication Draft Message-ID: Hi Joe, Some more comments. Again keeping relevant parts only... > > > > > > > Take an example using MSCHAPv2 inside of a mechanism such as PEAP. > > > > > Party A can establish a secure connection to party B by > > > > > establishing PEAP and verifying B's identity. B can then request that A > > > > > authenticate with MSCHAPv2. A will perform MSCHAPv2 authentication with B. > > > > > B can open up another PEAP session to C. B can proxy the > > > > > MSCHAPv2 authentication to C and authenticate as A. B can now carry on a > > > > > conversation with C as if he were A. > > > > Looks like I'm not comprehending the attack you describe. So > > here's an attempt to clarify... Tell me if your case is as follows: > > > > So A wants some service from B we call S1 and it uses > > identity IA1 for it. The MS-CHAPv2 credentials used were > > intended to get access for this service S1 from B. So this > > was in context of PEAP session BA (B authenticated by A). > > > [Joe] So far so good > > > Now C offers service S2 to A and B and the identities for > > access are IA2 and IB2 and MSCHAPv2 is the method used. So B > > after setting up PEAP session with A now has a separate PEAP > > session CB with B (C authenticated by B). > > > [Joe] The identity for A is the same IA1. Service is not offered to B > and IB2 does not exist [JP] So A is sending IA1 to B for access to S1 or S2? > > > So when A authenticates with B for S1 it uses identity IA1. > > [Joe] OK > > > If A authenticates with C for S2 it would use IA2 right? > > [Joe] It uses IA1 (same identity for both services) > > How would A ever disclose IA2 to B when B doesn't provide the > service S2? > > [Joe] Same identity both services. > > > I agree the attack you describe is possible if A uses > > identity IA2 to access service from C but thru B. Why would > > this happen? Can you give an example. > > > [Joe] This is not the case I was thinking about, but in this case it > would have had to use the incorrect credential based on the > identity B. > This could be done thrugh incorrect configuration or perhaps > some clever > manipulation by B to make things appear to be C (except for the server > side auth). [JP] So A attempts to get service S1 from B, but knowing that A has service S2 from C is pretending to provide A with service S1, but obtains S2 from C instead with A's identity IA1. Now can you explain how this clever manipulation is done? Also, so far this attack is being performed by a trusted server entity, which I'm not convinced is solvable? Our draft talks about attacks performed by un-authenticated NASes. > > > Is your case when A has the same identity IA1=IA2 for both > > services S1 and S2? > > > [Joe] Yes. > best regards, jose From jsalowey@cisco.com Sat Mar 29 01:34:58 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 28 Mar 2003 17:34:58 -0800 Subject: [eap] Compound Authentication Draft In-Reply-To: Message-ID: <013b01c2f593$6901abb0$0200000a@amer.cisco.com> > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Friday, March 28, 2003 5:13 PM > To: 'Joseph Salowey'; eap@frascone.com > Subject: RE: [eap] Compound Authentication Draft > > > Hi Joe, > > Some more comments. Again keeping relevant parts only... > > > > > > > > > > Take an example using MSCHAPv2 inside of a > mechanism such as > > > > > > PEAP. > > > > > > > Party A can establish a secure connection to party B by > > > > > > establishing PEAP and verifying B's identity. B > can then request > that A > > > > > > authenticate with MSCHAPv2. A will perform MSCHAPv2 > > > > > > authentication > with B. > > > > > > B can open up another PEAP session to C. B can proxy the > > > > > > MSCHAPv2 authentication to C and authenticate as > A. B can now > carry on a > > > > > > conversation with C as if he were A. > > > > > > Looks like I'm not comprehending the attack you describe. So > > > here's an attempt to clarify... Tell me if your case is > as follows: > > > > > > So A wants some service from B we call S1 and it uses > > > identity IA1 for it. The MS-CHAPv2 credentials used were > > > intended to get access for this service S1 from B. So this > > > was in context of PEAP session BA (B authenticated by A). > > > > > [Joe] So far so good > > > > > Now C offers service S2 to A and B and the identities for > > > access are IA2 and IB2 and MSCHAPv2 is the method used. So B > > > after setting up PEAP session with A now has a separate PEAP > > > session CB with B (C authenticated by B). > > > > > [Joe] The identity for A is the same IA1. Service is not > offered to B > > and IB2 does not exist > > [JP] So A is sending IA1 to B for access to S1 or S2? > [Joe] No A is sending IA1 to be for access to service S1. B uses the authentication to get access to S2 as A1. > > > > > So when A authenticates with B for S1 it uses identity IA1. > > > > [Joe] OK > > > > > If A authenticates with C for S2 it would use IA2 right? > > > > [Joe] It uses IA1 (same identity for both services) > > > > How would A ever disclose IA2 to B when B doesn't provide the > > service S2? > > > > [Joe] Same identity both services. > > > > > I agree the attack you describe is possible if A uses > > > identity IA2 to access service from C but thru B. Why would > > > this happen? Can you give an example. > > > > > [Joe] This is not the case I was thinking about, but in > this case it > > would have had to use the incorrect credential based on the > identity > > B. This could be done thrugh incorrect configuration or perhaps > > some clever > > manipulation by B to make things appear to be C (except for > the server > > side auth). > > [JP] So A attempts to get service S1 from B, but knowing that > A has service S2 from C is pretending to provide A with > service S1, but obtains S2 from C instead with A's identity > IA1. Now can you explain how this clever manipulation is done? > [Joe] Yes, There is a server side authenticated tunnel between A and B and B and C. B may actually provide service S1 to A, this is irrelevant. When A sends his authentication data to B, B turns around and sends it to C. When C sends authentication data to B then B turns around and sends it to A. This contiues until the authentication between A and C is completed. C now thinks there is a secure connection with A, but in reality it is a secure connection to B. > Also, so far this attack is being performed by a trusted > server entity, which I'm not convinced is solvable? Our draft > talks about attacks performed by un-authenticated NASes. > [Joe] I'm not sure what you mean. This problem is based on the same principal as the compound authentication problem. If A uses different credentials with B and C there is no problem. Also If there is binding between the inner and outer methods then B can't send data and pretend to be A. > > > > > Is your case when A has the same identity IA1=IA2 for both > > > services S1 and S2? > > > > > [Joe] Yes. > > > > best regards, > jose > From jose.p.puthenkulam@intel.com Sat Mar 29 02:14:31 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 28 Mar 2003 18:14:31 -0800 Subject: [eap] Compound Authentication Draft Message-ID: At this point I think we maybe crossing into philosohical arguments... > > [Joe] Yes, There is a server side authenticated tunnel > between A and B > and B and C. B may actually provide service S1 to A, this is > irrelevant. When A sends his authentication data to B, B turns around > and sends it to C. When C sends authentication data to B then B turns > around and sends it to A. This contiues until the authentication > between A and C is completed. C now thinks there is a secure > connection > with A, but in reality it is a secure connection to B. > When A did a PEAP stage 1 server authentication with B, that implied B would meet certain expectations of A. So B does not seem to be meeting it. The server certificate that B provided to A has some limited scope and meaning. If B does not honor it, then what's the use of the tunnel between A and B? It is understandable that B can violate its trust with C, as C is not authenticating B. But B cannot violate its trust with A. If it does, then certificates, tunnels etc. are all useless. best regards, jose From jsalowey@cisco.com Sat Mar 29 02:59:59 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 28 Mar 2003 18:59:59 -0800 Subject: [eap] Compound Authentication Draft In-Reply-To: Message-ID: <014701c2f59f$49594eb0$0200000a@amer.cisco.com> [Joe] Yes I think perhaps we are. We should probably take this off line. I still think there is a problem, but it is either a configuration problem or a problem with different tunnel endpoints on the backend (which makes proper configuration impossible). A few comments below that should clarify. I disagree with the assertion that this is a "trust" problem. > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Friday, March 28, 2003 6:15 PM > To: 'Joseph Salowey'; Puthenkulam, Jose P; eap@frascone.com > Subject: RE: [eap] Compound Authentication Draft > > > At this point I think we maybe crossing into philosohical arguments... > > > > > [Joe] Yes, There is a server side authenticated tunnel > > between A and B > > and B and C. B may actually provide service S1 to A, this is > > irrelevant. When A sends his authentication data to B, B > turns around > > and sends it to C. When C sends authentication data to B > then B turns > > around and sends it to A. This contiues until the authentication > > between A and C is completed. C now thinks there is a secure > > connection > > with A, but in reality it is a secure connection to B. > > > > When A did a PEAP stage 1 server authentication with B, that > implied B would > meet certain expectations of A. So B does not seem to be > meeting it. [Joe] Not necessarily. B should not be able to authenticate to someone else as A. This problem comes from one of the following: 1. A is unable to determine that it should not use a particular credential with B or A cannot validate that the server identity authenticated in the inner mechanism (C) is not the same as B during the authentication. This is a configuration problem (perhaps an inner protocol problem as well). 2. In another case B and C are referring to the same back end authentication service (R) and the tunnel is expected to be terminated on B or C. This is perhaps more of a realistic problem. In this case A cannot match the inner mechanism authentication (R) with the tunnel authentication (B or C). It is possible for B and C to be in two different security domains and R to be a third domain (like roaming case). B can then impersonate A to C. Now the problem here is the reverse of the case you have described. It results from a difference of tunnel endpoints on the backed end. This sort of thing is already discouraged and known to be a problem. The > server certificate that B provided to A has some limited > scope and meaning. > If B does not honor it, then what's the use of the tunnel > between A and B? > [Joe] I disgree. If B can authenticate as A to another party there is a problem with the system. > It is understandable that B can violate its trust with C, as C is not > authenticating B. But B cannot violate its trust with A. If > it does, then > certificates, tunnels etc. are all useless. [Joe] Again I don't think that trust is the issue. An authentication mechanism is not much good if it allows one party to impersonate another without consent. Have a good weekend, Joe > > best regards, > jose > > > > > > > From Pasi.Eronen@nokia.com Mon Mar 31 08:12:03 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 31 Mar 2003 11:12:03 +0300 Subject: [eap] EAP Success/Failure: authentication or access control result? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA76@esebe023.ntc.nokia.com> Hi, We had a conference call with John Vollbrecht and Nick Petroni on Friday, and a couple of issues needing clarification came up. Here's one of them (which seems to be related to several other issues that came up, so let's deal with this one first). Does EAP Success (Failure) message mean that "I've (not) succesfully authenticated you" or "I'm allowing (denying) access"? That is, is it the authentication result or access control result? In both 2284bis and 2869bis, it's always called authentication result (e.g. 2284bis: "authentication conversation can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator MUST transmit an EAP Success"). 2284bis also mentions the possibility of allowing access even though authentication=20 failed (in 7.9, "Implementation idiosyncrasies"). However, there are some parts in both documents that are not so clear, and make more sense if you assume that it really should be called access control result (or that the server has a policy where the two are always the same). Note that RADIUS, for instance, is quite clear about this: Access-Accept and Reject are access control decisions, not authentication (and the two don't have to be the same). =20 What do others think, which should it be? (Although the "authentication result" seems more obvious, it has some interesting consequences: for instance, the client should then probably treat both EAP Success and Failure packets as simply "EAP conversation ended" indication, and decide whether to continue the link solely based on its local policy, even if Failure was received). Best regards, Pasi From aboba@internaut.com Mon Mar 31 16:14:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 31 Mar 2003 08:14:24 -0800 (PST) Subject: [eap] I-D ACTION: RFC 2869bis-11 (fwd) Message-ID: -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-aboba-radius-rfc2869bis-11.txt From: Internet-Drafts@ietf.org Date: Mon, 31 Mar 2003 06:44:35 -0500 Reply-to: Internet-Drafts@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RADIUS Support For Extensible Authentication Protocol (EAP) Author(s) : B. Aboba, P. Calhoun Filename : draft-aboba-radius-rfc2869bis-11.txt Pages : 41 Date : 2003-3-28 This document defines RADIUS support for the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document updates RFC 2869. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-11.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-aboba-radius-rfc2869bis-11.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-aboba-radius-rfc2869bis-11.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.