From Pasi.Eronen@nokia.com Fri May 2 15:55:53 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 2 May 2003 17:55:53 +0300 Subject: [eap] Re: passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> Hi, Hmm, good point; we already specify that displayable messages use UTF-8, but the same problem also applies to input data. While I'm not so sure that we should try to force all existing EAP methods to use UTF-8, we probably should at least recommend something for methods specified in 2284bis. Here's suggested text (written as MAY/SHOULD, not MUST). Add to end of section 5.1: "EAP does not place any other requirements on the contents of the Identity Response, as different representations may be appropriate in different contexts.=20 =20 In the absence of other guidance, the Identity MAY be a=20 Network Access Identifier (NAI) conforming to [RFC2486],=20 with the following exceptions allowed: - The username portion MAY be empty. This can be useful with EAP methods that have their own identity protection mechanism, but use the realm portion to route messages to the correct backend server. - The username portion MAY contain Unicode characters greater=20 than U+007F encoded using UTF-8 [RFC2279]." Add to 5.4 (MD5-Challenge), before Type: "Note: [RFC1994] treats the shared secret as a byte string, and does not specify how it is entered into the system (or if it is handled by the user at all). For EAP MD5-Challenge method, if the shared secret is a passphrase entered by =20 the user, it SHOULD be converted into bytes using UTF-8=20 encoding [RFC2279]." Add to 5.5 (OTP), before Security Claims: "Note: [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. For EAP OTP method, the pass-phrase SHOULD be encoded using UTF-8 [RFC2279]." Add to 5.6 (GTC), before Security Claims: "If the data entered by the user contains non-ASCII characters, it SHOULD be encoded using UTF-8 [RFC2279]." Best regards, Pasi > -----Original Message----- > From: ext Lauri Tarkkala [mailto:ltarkkal@ssh.com] > Sent: Wednesday, April 30, 2003 2:36 PM > To: eap@frascone.com > Subject: [eap] passphrases in EAP >=20 >=20 >=20 > I have unfortunately not had time to follow the WG work > actively all the time, so my apologies if this item > has already been discussed. >=20 > Lauri >=20 >=20 > Interoperability problems in passphrase authentication protocols. >=20 > Submitter name: Lauri Tarkkala > Submitter email address: ltarkkal@ssh.com > Date first submitted: April 30, 2003 > Document: draft-ietf-eap-rfc2284bis-02.txt > Comment type: general > Rationale/Explanation of Issue: >=20 > Several of the PPP/EAP authentication protocols > are in essence "password authentication protocols" > (PAP, CHAP, EAP-MD5). This means that the shared > secret is in essence a string in some alphabet > (most often US-ASCII), as opposed to the more > low-level view of a bitstring.=20 >=20 > Currently the specifications of these protocols > define the shared secret as an arbitrary string > of octets. This has caused in practice a serious > interoperability problem, leaving implementations > free to define the following: >=20 > - Alphabet the password is defined in. >=20 > - Derivation of shared secret from password. >=20 > As an example some implementations assume CHAP to > encode the password as US-ASCII (or Latin-1 or > some other 8-bit alphabet) and MS-CHAPv2 to > encode the password as UCS-2.=20 >=20 > This leads to obvious problems. If the user=20 > actually has characters in his/her password not expressible > in US-ASCII. He/she/it should have sufficient know-how > to be able to disable CHAP when negotiating an authentication > protocol. An implementation also might have to guess > the alphabet to use. These settings might also > differ from system to system. In some cases one could > try to deduce an intelligent guess based on some=20 > (e.g. out-of-band) vendor identification for the peer. >=20 > These pitfalls should be avoided in the future. > I propose that the working group standardize the=20 > following functions: >=20 > a) If an authentication protocol is keyed by a "passphrase", > then the algorithm used to derive a representation > of a shared secret. If any cryptography is involved, > the protection of the shared secret (if performed) > should still be left to the individual EAP method. >=20 > b) The alphabet to be used for this (assuming the WG feels > that a superset alphabet exists), or if the WG feels > that it is not prudent to specify a superset alphabet > at this point in time, a tagging mechanism in the protocol > to denote the alphabet used in mapping a passphrase to a > bitstring. The current draft specifies that the UTF-8 > is used to represent all human-readable data. >=20 > An acceptable solution would be to state, that ALL > human readable data in ALL EAP methods (except methods > specified before xx.yy.zzzz) must be represented using > UTF-8. This would include passphrases. Also the > alphabsets used in methods before xx.yy.zzzz should > be defined, by a poll checking current implementations. >=20 > This would require introduction of two EAP-MD5 methods. >=20 > --=20 > Lauri Tarkkala > SSH Communications Security Corp From jrv@umich.edu Fri May 2 16:45:16 2003 From: jrv@umich.edu (John Vollbrecht) Date: Fri, 02 May 2003 11:45:16 -0400 Subject: [eap] FW: peer-to-peer mutual authentication In-Reply-To: <3EACCD97.1040806@piuha.net> References: <3EACCD97.1040806@piuha.net> Message-ID: <244236.1051875915@[10.0.1.2]> This is very interesting, but probably out of scope for current EAP charter. However, I have a couple comments below. --On Monday, April 28, 2003 9:43 AM +0300 Jari Arkko wrote: > Dror Caspi wrote: > > 802.1aa/D5 (section 6.7) talks about this issue, but unless I > > misunderstood some of the text it is still problematic. > > > > - The suggested method in the text for peers (e.g., two bridges) is to > > play both Authenticatior and Supplicant. Such systems should be > > prepared for role reversal. > > - However the text clearly notes that from the two one-way > > authentication exchanges in each direction are not equivalent to a > > single mutual authentication exchange. > > Right. One mutual auth is good enough, however, in theory. But there > may still be protocol problems (see below). > > > - The text also notes that EAP methods that perform mutual > > authentication can be used - and that the Supplicant action at the end > > of such exchange is currently undefined. > > This is being modified to indicate that the Supplicant will go to "Unauthenticated" state and its link should not go active. > > So based on the above, what I would really like to do is use a single > > exchange with a mutual authentication method (e.g., EAP-Archie). But > > then how do you decide on who plays the Authenticator and who plays the > > Supplicant? - both sides are equal peers. One way we thought of was > > for both peers start as Authenticator and do some pseudo-random > > decision - say based on the highest MAC address or highest > > pseudo-random NONCE value sent as part of the initial EAP request. > > Yes. > > > However I am not sure that the above is still within the standard - > > i.e., if we implement this (say as a proprietary EAP method) it would > > still fit within the 802.1aa/D5 and RFC2284bis framework. > I am a bit confused as to what the proprietary EAP method would do. One side or the other would have to send the Request, so that side would be the initiator. The other side could NAK if it wanted to be initiator and propose something else. Possibly they could agree on a method that allows one or the other to "drive" within the method. Still, in EAP one or the other end is the initiator. To change which is the initiator it would seem the choice must be made at the lower layer. In PPP either side can request the other authenticate and use EAP. It is then the initiator. In 802.1X it is hard wired for now. > This would be easier to determine if we had details available on exactly > how the two peers go about doing the mutual authentication. > > As I see it, there are two fundamental issues: > > - Who acts as the initiator (FCFS, highest > identity/addrs/nonce/whatever, ...) > > - How to identify the initiator. As a responder, I can send my identity > in the Identity Response, but what if we are running a shared secret > method and I have different shared secrets for you and someone else? > I would need to know your identity before I can proceed with the > execution of the method. I don't know of a way how to do this in > EAP. OTOH, this is a similar issue as exists in the case of > multiple providers and credentials even in e.g. regular WLAN access > from a client, which I believe is solved with information from the > link layer (SSID). > Is knowing identity required to decide who is initiator? It seems to me that once one know who is the initiator then one can take steps to find identity. > Secondly, I see two approaches to solving these issues. One, we could > do it at the EAP level. Two, we could do it at the link-layer level. > For instance, the initiator could be chosen to be the peer with the > smallest MAC address, and if the link-layer identity and other published > information suffices to identify the initiator, I believe 2284bis would > work fine in this case. But you wouldn't see this at the EAP layer; > all the decisions take place at the link layer and then magically > the EAP protocol is run in one direction between the two parties. > I think that perhaps a more aggressive method negotiating sequence could also solve this. If the two parties agree on a "mutual" method, then it seems this could work. With an appropriate method both are satisfied with the other's authentication. Each side then goes to an authenticated state. In 802.1aa this does work. The authenticator (initiator) sets the controlled port ON, and the peer goes to the Authenticated State. The link won't work unless both sides have succeeded. > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From ltarkkal@ssh.com Fri May 2 15:43:59 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Fri, 2 May 2003 17:43:59 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> Message-ID: <20030502144359.GA4739@tehdas> On Fri, May 02, 2003 at 05:55:53PM +0300, Pasi.Eronen@nokia.com wrote: > > Hi, > > Hmm, good point; we already specify that displayable messages > use UTF-8, but the same problem also applies to input data. > While I'm not so sure that we should try to force all existing > EAP methods to use UTF-8, we probably should at least recommend > something for methods specified in 2284bis. Your proposed solution is IMHO not satisfactory, for the simple reason that the alphabet used to represent the passphrase is a parameter in selecting the acceptable authentication method (or the used authentication method is a parameter in choosing the passphrase). A simple example: - Client wishes to authenticate with EAP using a shared-secret scheme to Server, where server assumes alphabet Y for on-the-wire representation. - Client holds passphrase expressible in alphabet X, but not alphabet Y. - Authentication will not succeed. Interoperability would require that the user know the EAP methods used before he/she chooses his/her password! A requirement for an acceptable solution IMHO is that the character set used for the passphrase SHOULD NOT be related to an EAP method (with the possible exception of some legacy methods). A user should not need to know that "if my password contains the Japanese Kanji I can only authenticate using the EAP method xyzzy". I do agree with you, that forcing all EAP methods into the same alphabet is not wise. I also think that interoperability with existing EAP-MD5/etc implementations is important (otherwise implementors would still have to sniff out, based on some indidcators about the peer vendor, what encoding to use). I feel that a better solution would be to classify EAP methods according to the key-type used into "passphrase-keyed methods" and "binary-keyed methods". Ideally, each method would have an instance in both classifications. This could be achieved by reserving a bit in the type field of a method (with the obvious consequence of halving the namespace), e.g. assuming "passphrase-keying" is indicated by bit 6: - EAP-MD5 keyed by a binary string would be method 0x05. - EAP-MD5 keyed by a passphrase in UTF-8 would be method 0x45. The bit would have the following semantics: - If the passphrase-keying bit is set by the authenticator, then it means "authenticator supports passphrase-keying". - If the passphrase-keying bit is set by the authenticatee, then it means "that key used is a passphrase in UTF-8 encoding". Any opinions? Any ideas on some better place to find bits for this indication? Lauri -- Lauri Tarkkala SSH Communications Security Corp From Pasi.Eronen@nokia.com Fri May 2 17:06:39 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 2 May 2003 19:06:39 +0300 Subject: [eap] Issue: Document meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612227A@esebe023.ntc.nokia.com> Document meaning of successful authentication Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 2, 2003 Reference: - Document: RFC2284bis Comment type: both? Priority: 1 Section: 1.2 (and possibly others) Rationale/Explanation of issue: It seems that in EAP we're using the word "authentication"=20 in somewhat non-standard sense, and I feel we should document=20 it.=20 Here's a first draft of text for section 1.2 (terminology): "Successful authentication =20 In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access. This definition differs from the usual definitions of authentication (e.g. "verification of claimed identity"), since the authenticator may decide to deny access even when the identity of the peer is known and verified, or vice versa (allow access when the identity of the peer is not verified). Furthermore, even if the authenticator decides to allow access, the peer may consider the exchange a failure if it has not successfully verified that it is talking to the intended authenticator." Do you think this captures the meaning accurately?=20 (It might require some small changes somewhere else=20 in the document, I can try to find them...) Best regards, Pasi From Pasi.Eronen@nokia.com Fri May 2 17:36:31 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 2 May 2003 19:36:31 +0300 Subject: [eap] RE: passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612227B@esebe023.ntc.nokia.com> Hi, Lauri Tarkkala wrote: > Your proposed solution is IMHO not satisfactory, for the > simple reason that the alphabet used to represent the passphrase > is a parameter in selecting the acceptable authentication method > (or the used authentication method is a parameter in choosing the > passphrase). >=20 > A simple example: >=20 > - Client wishes to authenticate with EAP using a shared-secret=20 > scheme to Server, where server assumes alphabet Y for=20 > on-the-wire representation. >=20 > - Client holds passphrase expressible in alphabet X, but not=20 > alphabet Y. >=20 > - Authentication will not succeed. Interoperability would require > that the user know the EAP methods used before he/she chooses > his/her password!=20 > > A requirement for an acceptable solution IMHO is that the > character set used for the passphrase SHOULD NOT be related > to an EAP method (with the possible exception of some legacy > methods). >=20 > A user should not need to know that > "if my password contains the Japanese Kanji I can > only authenticate using the EAP method xyzzy". Well, most EAP methods seem to treat the shared secret internally as a string of raw octets, with no assumptions about alphabets=20 at all. A user interface for entering passwords obviously has to choose some method of converting the user input into octets. In the example above, the EAP server doesn't probably even know what character set or conversion was used by the UI (the password database contains just the octets), so it can't=20 "negotiate" this with the client.=20 So, I don't quite see what would be achieved by defining two separate methods, one for "binary" secrets and one for "text" secrets. It would provide a hint to the UI how to ask for the password (maybe "binary secrets" would be entered in hexadecimal format?), but=20 presumably the user already knows which one should=20 be used, since he knows what the password is and=20 already has entered it somewhere (when it was=20 stored in the password database). Best regards, Pasi From ltarkkal@ssh.com Fri May 2 16:55:58 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Fri, 2 May 2003 18:55:58 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612227B@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612227B@esebe023.ntc.nokia.com> Message-ID: <20030502155558.GA4927@tehdas> On Fri, May 02, 2003 at 07:36:31PM +0300, Pasi.Eronen@nokia.com wrote: > In the example above, the EAP server doesn't probably even > know what character set or conversion was used by the UI (the > password database contains just the octets), so it can't > "negotiate" this with the client. > > So, I don't quite see what would be achieved by defining > two separate methods, one for "binary" secrets and one > for "text" secrets. It would provide a hint to the UI > how to ask for the password (maybe "binary secrets" > would be entered in hexadecimal format?), but > presumably the user already knows which one should > be used, since he knows what the password is and > already has entered it somewhere (when it was > stored in the password database). I probably communicated this badly, sorry about that. When the server sends the "passphrase-derived key"-bit to the client, the client knows that it can ask the user for the passphrase, and transform it into UTF-8 and use this as the shared secret. It would indicate that it had done so, by setting the "passphrase-derived key" bit in it's responses. The absence of the "passphrase-derived key"-bit, would indicate, that a bitstring _IS_ the secret input into the EAP method by the client (e.g. the current behaviour for most current EAP methods), instead of some secret derived from a passphrase (normally as an encoding using some character set). The hint, as you call it, would not be to the UI, but to the implementation of the authentication method in the client and server. Some representation must ALWAYS be used for the passphrase, in any authentication method. The hint would be directed to implementations, and they would use it to select the encoding used for generating these representations. Example: - I try to authenticate to some server, with my neat unicode passphrase. The server, being EAP-bis compliant, sends me an EAP-MD5 message with the "I support the hint-bit"-bit set. - My client, noticing this encodes my passphrase using UTF-8, and uses this as input to the MD5 hash, and keeps the hint bit set. - If the hint bit were not set. Then my implementation would have to arbitrarily choose an encoding, and use this. I could only hope that, this was the same encoding used by the server side implementation. Recall the example about CHAP and MS-CHAPv2, which use different representation of the same passphrase, with MS-CHAPv2 being able to represent passphrases that most CHAP implementations do not support. There is the usability aspect (I would strongly question some users capability to understand that there are several character sets in which to represent passpharses ;) and the interoperability/implementation aspect. Lauri -- Lauri Tarkkala SSH Communications Security Corp From Pasi.Eronen@nokia.com Fri May 2 21:48:08 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 2 May 2003 23:48:08 +0300 Subject: [eap] RE: passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612227C@esebe023.ntc.nokia.com> Lauri Tarkkala wrote: > Example: >=20 > - I try to authenticate to some server, with my neat unicode > passphrase. The server, being EAP-bis compliant, sends me > an EAP-MD5 message with the "I support the hint-bit"-bit set. >=20 > - My client, noticing this encodes my passphrase using UTF-8, > and uses this as input to the MD5 hash, and keeps the hint > bit set. >=20 > - If the hint bit were not set. Then my implementation would > have to arbitrarily choose an encoding, and use this. I could > only hope that, this was the same encoding used by the server > side implementation.=20 Yes, but what encoding would the implementation choose in this=20 case (since it has to choose something)? If it would always=20 choose UTF-8 anyway, then we don't need the "hint bit". Specifying a new method (with different type code) is easy in=20 theory (but getting it deployed certainly would not be :-). =20 The more difficult aspect is what to do with existing methods=20 (and implementations of them). I guess the important question here is that do existing implementations of MD5-Challenge and OTP (this problem=20 doesn't exist in MS-CHAPv2 or LEAP) support non-ASCII=20 passphrases "well enough" (with good interoperability),=20 with some other encoding than UTF-8, so that mandating=20 UTF-8 would seriously break things? (Does someone have more information or actual=20 experiences about this?) Best regards, Pasi From henrik@levkowetz.com Fri May 2 22:03:32 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 2 May 2003 23:03:32 +0200 Subject: [eap] Re: passphrases in EAP In-Reply-To: <20030502144359.GA4739@tehdas> References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> <20030502144359.GA4739@tehdas> Message-ID: <20030502230332.12c9a319.henrik@levkowetz.com> Lauri, There's something I don't quite understand here. The proposed encoding is UTF-8, which is unicode(16) characters encoded as an octet sequence. Now, while it is true that there exists enough variations on chinese ideographs used in classical literature that not all can be represented in unicode(16), I'm not aware of any existing set of computer character codes which cannot be represented in unicode. Maybe I'm mistaken here? But if I'm not mistaken, wherein lies the problem in specifying UTF-8 encoding? It seems to me that UTF-8 would provide a normalization which would work with all current input locales, with no possibilities of mismatch between server representation and client representation of passphrase? Henrik On Fri, 2 May 2003 17:43:59 +0300, Lauri Tarkkala wrote: > On Fri, May 02, 2003 at 05:55:53PM +0300, Pasi.Eronen@nokia.com wrote: > > > > Hi, > > > > Hmm, good point; we already specify that displayable messages > > use UTF-8, but the same problem also applies to input data. > > While I'm not so sure that we should try to force all existing > > EAP methods to use UTF-8, we probably should at least recommend > > something for methods specified in 2284bis. > > Your proposed solution is IMHO not satisfactory, for the > simple reason that the alphabet used to represent the passphrase > is a parameter in selecting the acceptable authentication method > (or the used authentication method is a parameter in choosing the > passphrase). > > A simple example: > > - Client wishes to authenticate with EAP using a shared-secret scheme > to Server, where server assumes alphabet Y for on-the-wire > representation. > > - Client holds passphrase expressible in alphabet X, but not alphabet Y. > > - Authentication will not succeed. Interoperability would require > that the user know the EAP methods used before he/she chooses > his/her password! > > A requirement for an acceptable solution IMHO is that the > character set used for the passphrase SHOULD NOT be related > to an EAP method (with the possible exception of some legacy > methods). Henrik -- Error message in Haiku form: Having been erased, The document you're seeking Must now be retyped. -- Judy Birmingham From jsalowey@cisco.com Fri May 2 22:58:04 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 2 May 2003 14:58:04 -0700 Subject: [eap] Re: passphrases in EAP In-Reply-To: <20030502230332.12c9a319.henrik@levkowetz.com> Message-ID: <009401c310f5$e8255ae0$65a86b80@amer.cisco.com> I think the stringprep RFc may provide some guidence in this area. http://www.ietf.org/rfc/rfc3454.txt SASL is working string preparation procedure for usernames and passwords. Kerberos is looking at defining something similar (or perhaps will use the same spec). http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Henrik Levkowetz > Sent: Friday, May 02, 2003 2:04 PM > To: Lauri Tarkkala > Cc: eap@frascone.com; pasi.eronen@nokia.com > Subject: Re: [eap] Re: passphrases in EAP > > > Lauri, > > There's something I don't quite understand here. > > The proposed encoding is UTF-8, which is unicode(16) > characters encoded as an octet sequence. Now, while it is > true that there exists enough variations on chinese > ideographs used in classical literature that not all can be > represented in unicode(16), I'm not aware of any existing set > of computer character codes which cannot be represented in > unicode. Maybe I'm mistaken here? > > But if I'm not mistaken, wherein lies the problem in > specifying UTF-8 encoding? It seems to me that UTF-8 would > provide a normalization which would work with all current > input locales, with no possibilities of mismatch between > server representation and client representation of passphrase? > > Henrik > > On Fri, 2 May 2003 17:43:59 +0300, Lauri Tarkkala > wrote: > > On Fri, May 02, 2003 at 05:55:53PM +0300, > Pasi.Eronen@nokia.com wrote: > > > > > > Hi, > > > > > > Hmm, good point; we already specify that displayable messages use > > > UTF-8, but the same problem also applies to input data. While I'm > > > not so sure that we should try to force all existing EAP > methods to > > > use UTF-8, we probably should at least recommend something for > > > methods specified in 2284bis. > > > > Your proposed solution is IMHO not satisfactory, for the > simple reason > > that the alphabet used to represent the passphrase is a > parameter in > > selecting the acceptable authentication method (or the used > > authentication method is a parameter in choosing the passphrase). > > > > A simple example: > > > > - Client wishes to authenticate with EAP using a > shared-secret scheme > > to Server, where server assumes alphabet Y for on-the-wire > > representation. > > > > - Client holds passphrase expressible in alphabet X, but > not alphabet > > Y. > > > > - Authentication will not succeed. Interoperability would require > > that the user know the EAP methods used before he/she chooses > > his/her password! > > > > A requirement for an acceptable solution IMHO is that the character > > set used for the passphrase SHOULD NOT be related to an EAP method > > (with the possible exception of some legacy methods). > > > Henrik > > -- > Error message in Haiku form: > > Having been erased, > The document you're seeking > Must now be retyped. > > -- Judy Birmingham > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From mohanp@tahoenetworks.com Sat May 3 01:57:42 2003 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Fri, 2 May 2003 17:57:42 -0700 Subject: [eap] clarification in rfc2284-bis-02.txt Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A44E@TNEXVS02.tahoenetworks.com> Hello, In section 3.1, Lower layer requirements, As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g. wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided. Where keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus it may only be possible to use the lower layer ciphersuite to protect a portion of the EAP conversation, such as the EAP Success or Failure packet. I have couple of questions.=20 1) How do you delay the EAP success packet so that it can be protected ? For example, if you are using ECP, you should have reached the IPCP negotiation phase. But IPCP has not begun until EAP success packet is transmitted. right ? what am I missing ? 2) Under what conditions the EAP failure packet can be protected ? Doesn't failure imply that key has not been derived ? thanks mohan =20 From ltarkkal@ssh.com Mon May 5 09:46:33 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Mon, 5 May 2003 11:46:33 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <20030502230332.12c9a319.henrik@levkowetz.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> <20030502144359.GA4739@tehdas> <20030502230332.12c9a319.henrik@levkowetz.com> Message-ID: <20030505084633.GA2525@tehdas> On Fri, May 02, 2003 at 11:03:32PM +0200, Henrik Levkowetz wrote: > Lauri, > > There's something I don't quite understand here. > > The proposed encoding is UTF-8, which is unicode(16) characters > encoded as an octet sequence. Now, while it is true that there exists > enough variations on chinese ideographs used in classical literature > that not all can be represented in unicode(16), I'm not aware of any > existing set of computer character codes which cannot be represented in > unicode. Maybe I'm mistaken here? No you are not. I agree fully, that if all implementations were to use UTF-8, there would be no problem, but OTOH I do not find it desirable to break interoperability between existing EAP MD5-Challenge implementations (which do not seem to use UTF-8). This is why I proposed a tagging mechansim (one, which could be improved in many ways, I admit) to overcome the backward compatibility problem. Lauri -- Lauri Tarkkala SSH Communications Security Corp From ltarkkal@ssh.com Mon May 5 10:12:45 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Mon, 5 May 2003 12:12:45 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <009401c310f5$e8255ae0$65a86b80@amer.cisco.com> References: <20030502230332.12c9a319.henrik@levkowetz.com> <009401c310f5$e8255ae0$65a86b80@amer.cisco.com> Message-ID: <20030505091245.GB2525@tehdas> On Fri, May 02, 2003 at 02:58:04PM -0700, Joseph Salowey wrote: > http://www.ietf.org/rfc/rfc3454.txt > > SASL is working string preparation procedure for usernames and > passwords. Kerberos is looking at defining something similar (or > perhaps will use the same spec). > > http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt Thank you for these references. They shed some light on previous work in this area, and they seem quite applicable here. The backwards compatibility problem still persists. Noting that the EAP WG is chartered to "improve the interoperability of the existing EAP protocol", and with the experience of having developed EAP/PPP/RADIUS implementations in the past I would not like to break backwards compatibility with existing implementations. The whole jungle that is PPP/RADIUS and associated technologies tends to evolve somewhat unpredictably. Even if that interoperability is currently a result of de-facto conventions and not standardization. Might then the following approach be more to the WG's liking ? 1. Leave current EAP-MD5/OTP/GenericTokenCard as is (e.g. they use no map, implementor must guess that US-ASCII is correct choice). 2. Specify that in all methods UTF-8 SHOULD be the preferred representation of readable strings. 3. Reference a stringprep profile for usernames and passwords for preparsing unicode strings, which MUST be used, if unicode is used. 4. Implementors/method developers SHOULD NOT use other representations for readable strings. 5. Define new type code for EAP-MD5/OTP/GenericTokencard that use Unicode for representing passphrases ? This is ofcourse conditional on the existence of such a stringprep profile. Indeed, it would probably be desirable to have one such draft for the whole security area of IETF, although that is pretty much out of scope for EAP. These guidelines however, should guarantee interoperability (of both implementations and passphrases) in most passphrase-based methods. Lauri -- Lauri Tarkkala SSH Communications Security Corp From Pasi.Eronen@nokia.com Mon May 5 11:39:32 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 5 May 2003 13:39:32 +0300 Subject: [eap] Re: clarification in rfc2284-bis-02.txt Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612227F@esebe023.ntc.nokia.com> On May 3, Mohan Parthasarathy wrote: > Hello, >=20 > In section 3.1, Lower layer requirements, >=20 > As a result of these considerations, EAP SHOULD be used only when > lower layers provide physical security for data (e.g. wired PPP > or IEEE 802 links), or for insecure links, where per-packet > authentication, integrity and replay protection is provided. > Where keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite cannot be > enabled until late in the EAP conversation, after key derivation > has completed. Thus it may only be possible to use the lower > layer ciphersuite to protect a portion of the EAP conversation, > such as the EAP Success or Failure packet. >=20 > I have couple of questions.=20 >=20 > 1) How do you delay the EAP success packet so that it can be > protected ? For example, if you are using ECP, you should have > reached the IPCP negotiation phase. But IPCP has not begun until=20 > EAP success packet is transmitted. right ? what am I missing ? >=20 > 2) Under what conditions the EAP failure packet can be protected ? > Doesn't failure imply that key has not been derived ? I think the draft is misleading here: as far as I know (please correct me if I'm wrong :), existing lower layers that use EAP transmit the EAP success packet unprotected, and enable the ciphersuite only after that. If this is indeed the case, I suggest we the text to: "... When keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite is enabled=20 only after the EAP conversion has concluded. Thus, the EAP = conversation=20 itself is usually not protected." Best regards, Pasi From jari.arkko@piuha.net Mon May 5 12:49:33 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 05 May 2003 14:49:33 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <20030505084633.GA2525@tehdas> References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> <20030502144359.GA4739@tehdas> <20030502230332.12c9a319.henrik@levkowetz.com> <20030505084633.GA2525@tehdas> Message-ID: <3EB64FCD.8080800@piuha.net> Lauri Tarkkala wrote: > On Fri, May 02, 2003 at 11:03:32PM +0200, Henrik Levkowetz wrote: > >>Lauri, >> >> There's something I don't quite understand here. >> >> The proposed encoding is UTF-8, which is unicode(16) characters >>encoded as an octet sequence. Now, while it is true that there exists >>enough variations on chinese ideographs used in classical literature >>that not all can be represented in unicode(16), I'm not aware of any >>existing set of computer character codes which cannot be represented in >>unicode. Maybe I'm mistaken here? > > > No you are not. I agree fully, that if all implementations were to > use UTF-8, there would be no problem, but OTOH I do not find it > desirable to break interoperability between existing EAP MD5-Challenge > implementations (which do not seem to use UTF-8). This is why > I proposed a tagging mechansim (one, which could be improved > in many ways, I admit) to overcome the backward compatibility problem. Isn't UTF-8 encoding for plain ASCII characters the same as in ASCII? (I didn't bother to actually go and read the UTF-8 spec so I might be wrong here but that's what I have assumed.) If so, making RFC2284bis use UTF-8 would *not* break interoperability as far as plain ASCII characters are concerned. However, extensions such as scandinavian characters are encoded with different bit patterns, and if a password contained them interoperability would be broken. Then again, I'm not quite sure what interoperability we have right now for those things since 2284 did say ASCII. --Jari From porcher@funk.com Mon May 5 13:32:27 2003 From: porcher@funk.com (Tom Porcher) Date: Mon, 05 May 2003 08:32:27 -0400 Subject: [eap] Re: passphrases in EAP References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> <20030502144359.GA4739@tehdas> <20030502230332.12c9a319.henrik@levkowetz.com> <20030505084633.GA2525@tehdas> <3EB64FCD.8080800@piuha.net> Message-ID: <3EB659DB.4060701@funk.com> UTF-8 is an encoding of up to 32-bit wide characters, so the "Unicode" (16-bit) restriction does not apply. The characters below 128 (i.e. ASCII) are represented exactly as ASCII in UTF-8, so strings of ASCII characters are also strings of UTF-8 characters. UTF-8 is defined in International Standard ISO/IEC 10646-1:1993/Amd.2:1996: Information Technology - Universal Multiple-Octet Coded Character Set (UCS): Architecture and Basic Multilingual Plane. Amendment 2: UCS Transformation Format 8 (UTF-8) (phew!) FWIW, both the EAP SIM and EAP AKA drafts require usernames to conform to RFC 2486 "The Network Access Identifier". This RFC limits the username character set to 82 characters unless quoted in hexidecimal. --Tom Porcher -- Tom Porcher | porcher@funk.com voice: 978.371.3980 x108 Consulting Engineer | http://www.funk.com fax: 978.371.3990 Funk Software, Inc. | Concord, Massachusetts, USA, Earth Jari Arkko wrote: > Lauri Tarkkala wrote: > >> On Fri, May 02, 2003 at 11:03:32PM +0200, Henrik Levkowetz wrote: >> >>> Lauri, >>> >>> There's something I don't quite understand here. >>> >>> The proposed encoding is UTF-8, which is unicode(16) characters >>> encoded as an octet sequence. Now, while it is true that there exists >>> enough variations on chinese ideographs used in classical literature >>> that not all can be represented in unicode(16), I'm not aware of any >>> existing set of computer character codes which cannot be represented in >>> unicode. Maybe I'm mistaken here? >> >> >> >> No you are not. I agree fully, that if all implementations were to >> use UTF-8, there would be no problem, but OTOH I do not find it >> desirable to break interoperability between existing EAP MD5-Challenge >> implementations (which do not seem to use UTF-8). This is why >> I proposed a tagging mechansim (one, which could be improved >> in many ways, I admit) to overcome the backward compatibility problem. > > > Isn't UTF-8 encoding for plain ASCII characters the same as in ASCII? (I > didn't bother to actually go and read the UTF-8 spec so I might > be wrong here but that's what I have assumed.) > > If so, making RFC2284bis use UTF-8 would *not* break interoperability > as far as plain ASCII characters are concerned. However, extensions > such as scandinavian characters are encoded with different bit > patterns, and if a password contained them interoperability would > be broken. Then again, I'm not quite sure what interoperability > we have right now for those things since 2284 did say ASCII. > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Mon May 5 15:15:10 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 05 May 2003 17:15:10 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <3EB659DB.4060701@funk.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122279@esebe023.ntc.nokia.com> <20030502144359.GA4739@tehdas> <20030502230332.12c9a319.henrik@levkowetz.com> <20030505084633.GA2525@tehdas> <3EB64FCD.8080800@piuha.net> <3EB659DB.4060701@funk.com> Message-ID: <3EB671EE.5010403@piuha.net> Tom Porcher wrote: > UTF-8 is an encoding of up to 32-bit wide characters, so the "Unicode" > (16-bit) restriction does not apply. The characters below 128 (i.e. > ASCII) are represented exactly as ASCII in UTF-8, so strings of ASCII > characters are also strings of UTF-8 characters. If so, maybe we should mandate UTF-8? (But see bottom of the e-mail for a special case about Identity Response.) Whose implementation would break if we were to do that? > UTF-8 is defined in International Standard ISO/IEC > 10646-1:1993/Amd.2:1996: Information Technology - Universal > Multiple-Octet Coded Character Set (UCS): Architecture and Basic > Multilingual Plane. Amendment 2: UCS Transformation Format 8 (UTF-8) > (phew!) > > FWIW, both the EAP SIM and EAP AKA drafts require usernames to conform > to RFC 2486 "The Network Access Identifier". This RFC limits the > username character set to 82 characters unless quoted in hexidecimal. Hmm... good point. I can see that we don't actually say *anything* about the format in the Identity Response packet in 2284bis. If we can mandate anything there, my guess is that NAI would be a more logical choice here than UTF-8. The question is if we can mandate this -- any reasons not to? --Jari From Pasi.Eronen@nokia.com Mon May 5 15:29:15 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 5 May 2003 17:29:15 +0300 Subject: [eap] Re: passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122281@esebe023.ntc.nokia.com> Jari Arkko wrote: >> FWIW, both the EAP SIM and EAP AKA drafts require usernames to >> conform to RFC 2486 "The Network Access Identifier". This RFC limits = >> the username character set to 82 characters unless quoted in=20 >> hexidecimal. >=20 > Hmm... good point. I can see that we don't actually say *anything* > about the format in the Identity Response packet in 2284bis. If we > can mandate anything there, my guess is that NAI would be a=20 > more logical choice here than UTF-8. The question is if we can=20 > mandate this -- any reasons not to? Well, I proposed this in my message on Friday: "EAP does not place any other requirements on the contents of the Identity Response, as different representations may be appropriate in different contexts.=20 =20 In the absence of other guidance, the Identity MAY be a=20 Network Access Identifier (NAI) conforming to [RFC2486],=20 with the following exceptions allowed: - The username portion MAY be empty. This can be useful with EAP methods that have their own identity protection mechanism, but use the realm portion to route messages to the correct backend server. - The username portion MAY contain Unicode characters greater=20 than U+007F encoded using UTF-8 [RFC2279]." (NAI RFC was written a long time ago when i18n wasn't a big issue. I guess nowadays we should allow non-ASCII characters=20 in usernames) Best regards, Pasi From jari.arkko@piuha.net Mon May 5 15:33:16 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 05 May 2003 17:33:16 +0300 Subject: [eap] Re: passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122281@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122281@esebe023.ntc.nokia.com> Message-ID: <3EB6762C.3070403@piuha.net> Pasi.Eronen@nokia.com wrote: > (NAI RFC was written a long time ago when i18n wasn't a big > issue. I guess nowadays we should allow non-ASCII characters > in usernames) That is reasonable, but I would still rather reference the old NAI RFC and have someone update that separately... NAI appears in strange places and it wouldn't do good for overall systems interoperability if we changed NAI only in one place. Or? --Jari From Pasi.Eronen@nokia.com Tue May 6 09:44:11 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 6 May 2003 11:44:11 +0300 Subject: [eap] Re: passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122282@esebe023.ntc.nokia.com> Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: >=20 >> (NAI RFC was written a long time ago when i18n wasn't a big >> issue. I guess nowadays we should allow non-ASCII characters=20 >> in usernames) >=20 > That is reasonable, but I would still rather reference the > old NAI RFC and have someone update that separately... NAI > appears in strange places and it wouldn't do good for > overall systems interoperability if we changed NAI only > in one place. Or? Yes, I agree, updating the NAI RFC would be a much better idea=20 than specifying exceptions in 2284bis. Indeed, updating it=20 should be quite simple, since the document is quite short, the modifications quite small, and the changes are unlikely=20 to cause any problems for current implementations. However, RFC 2486 is a standards track document (proposed standard). Which working group should update it? (It was done in roamops, which concluded in January 2001).=20 Bernard, as the author of RFC 2486, what do you think about updating 2486 to allow UTF-8 encoded characters (octets 80-FD) in the username=20 part? Is it a good idea? If so, how should it be done? (If we decide=20 to do this, I can volunteer to do the actual editing work). Best regards, Pasi From jari.arkko@piuha.net Tue May 6 11:29:38 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 06 May 2003 13:29:38 +0300 Subject: [eap] Issue 112: Rewrite of IANA Considerations In-Reply-To: References: Message-ID: <3EB78E92.8070509@piuha.net> Sounds reasonable. But some questions below: Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 25th, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 6.2 > Rationale/Explanation of issue: > > It is desirable to require a published RFC for EAP methods, > if possible. Rewrite Section 6.2 to the following: > > "For registration requests where a Designated Expert should be consulted, > the responsible IESG area director should appoint the Designated Expert. > The intention is that any allocation will be accompanied by a published > RFC. But in order to allow for the allocation of values prior to the > RFC being approved for publication, the Designated Expert can approve > allocations once it seems clear that an RFC will be published. The "Seems clear" does not seem clear to me ;-) That is, I'm not sure how the DE evaluates this condition. Can we be more specific? An allocation is approved if the DE approves the method, and the method description has been submitted as an Internet Draft? Or has been submitted to the RFC Editor / IESG for publication? Or WG / IETF LC started / finished? (Specification Required might fit our requirements otherwise well, but I think we wanted to get allocations slightly earlier than it would mean. Then again RFC 2434 doesn't explicitly say in which order things will happen.) --Jari From aboba@internaut.com Tue May 6 13:29:44 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 05:29:44 -0700 (PDT) Subject: [eap] Re: passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122282@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122282@esebe023.ntc.nokia.com> Message-ID: > Bernard, as the author of RFC 2486, what do you think about updating > 2486 to allow UTF-8 encoded characters (octets 80-FD) in the username > part? Is it a good idea? If so, how should it be done? (If we decide > to do this, I can volunteer to do the actual editing work). Bring the idea up with Patrik Falstrom and/or Harald. If they think it is ok, then it's fine by me. There is an errata in RFC 2486 anyway (a problem in the grammar), so an update is needed. From henrik@levkowetz.com Tue May 6 13:58:59 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 6 May 2003 14:58:59 +0200 Subject: [eap] Comments after eap-03 edits Message-ID: <20030506145859.0fb210bb.henrik@levkowetz.com> Hi, I've now done the edits for issues 104 & 108-117. I came across a few inconsistencies and question marks, listed below: * In the new definition of authenticator (Issue 114), the word authenticator is capitalized, while Issue 110 requests it to be all lowercase. The same issue crops up in section 7.9, the rewritten security considerations section, which says "... the Authenticator or Supplicant can re-authenticate at ..." If "Authenticator" should be changed to "authenticator" throughout, how do we handle "Supplicant"? * The new text for Section 2.2 (Issue 115) says in one place: "The Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purpose of method negotiation" which reads a bit awkward to me. I'd propose "Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purpose of method negotiation" * In section 3.1, the rewritten item 3 (Issue 111) has the following slightly awkward text: "...where subsequently protected data is not protected by per-packet authentication, integrity and replay protection." I'd propose s/protected data/sensitive data/: "...where subsequently sensitive data is not protected by per-packet authentication, integrity and replay protection." Further on in 3.1, the last paragraph starts "Lower lower transports..." which I guess should be "Lower level transports..." * In the rewritten section 7 (Issue 113) there's one dangling "adversary" left, which I assume should be attacker. Henrik -- "If we don't succeed, we run the risk of failure." -- J. Danforth Quayle From aboba@internaut.com Tue May 6 14:15:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 06:15:48 -0700 (PDT) Subject: [eap] Re: Comments after eap-03 edits In-Reply-To: <20030506145859.0fb210bb.henrik@levkowetz.com> References: <20030506145859.0fb210bb.henrik@levkowetz.com> Message-ID: > * In the new definition of authenticator (Issue 114), the word authenticator > is capitalized, while Issue 110 requests it to be all lowercase. The same > issue crops up in section 7.9, the rewritten security considerations section, > which says > "... the Authenticator or Supplicant can re-authenticate at ..." > > If "Authenticator" should be changed to "authenticator" throughout, how do we > handle "Supplicant"? "Authenticator" and "Supplicant" are terms from IEEE 802.1X -- and that means we cannot include our own definitions for them, since they're already defined. My understanding was that "authenticator" was to be used to refer to an EAP authenticator. So I think that in the terminology section, that we need to use "authenticator" instead of "Authenticator". > * The new text for Section 2.2 (Issue 115) says in one place: > "The Nak (Type 3) or Expanded Nak (Type 254) are utilized for the > purpose of method negotiation" > which reads a bit awkward to me. I'd propose > "Nak (Type 3) or Expanded Nak (Type 254) are utilized for the > purpose of method negotiation" That seems fine, but it should be done consistently. > * In section 3.1, the rewritten item 3 (Issue 111) has the following > slightly awkward text: > "...where subsequently protected data is not protected by > per-packet authentication, integrity and replay protection." > I'd propose s/protected data/sensitive data/: > "...where subsequently sensitive data is not protected by > per-packet authentication, integrity and replay protection." how about "where subsequent data is not protected by..." > Further on in 3.1, the last paragraph starts > "Lower lower transports..." > which I guess should be > "Lower level transports..." I think it is "Lower layer transports" > * In the rewritten section 7 (Issue 113) there's one dangling "adversary" left, > which I assume should be attacker. Yes. From henrik@levkowetz.com Tue May 6 14:50:28 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 6 May 2003 15:50:28 +0200 Subject: [eap] Re: Comments after eap-03 edits In-Reply-To: References: <20030506145859.0fb210bb.henrik@levkowetz.com> Message-ID: <20030506155028.661e2db5.henrik@levkowetz.com> On Tue, 6 May 2003 06:15:48 -0700 (PDT) Bernard Aboba wrote: > > * In the new definition of authenticator (Issue 114), the word authenticator > > is capitalized, while Issue 110 requests it to be all lowercase. The same > > issue crops up in section 7.9, the rewritten security considerations section, > > which says > > "... the Authenticator or Supplicant can re-authenticate at ..." > > > > If "Authenticator" should be changed to "authenticator" throughout, how do we > > handle "Supplicant"? > > "Authenticator" and "Supplicant" are terms from IEEE 802.1X -- and that > means we cannot include our own definitions for them, since they're > already defined. My understanding was that "authenticator" was to be used > to refer to an EAP authenticator. So I think that in the terminology > section, that we need to use "authenticator" instead of "Authenticator". Ok. > > * The new text for Section 2.2 (Issue 115) says in one place: > > "The Nak (Type 3) or Expanded Nak (Type 254) are utilized for the > > purpose of method negotiation" > > which reads a bit awkward to me. I'd propose > > "Nak (Type 3) or Expanded Nak (Type 254) are utilized for the > > purpose of method negotiation" > > That seems fine, but it should be done consistently. Ok. > > * In section 3.1, the rewritten item 3 (Issue 111) has the following > > slightly awkward text: > > "...where subsequently protected data is not protected by > > per-packet authentication, integrity and replay protection." > > I'd propose s/protected data/sensitive data/: > > "...where subsequently sensitive data is not protected by > > per-packet authentication, integrity and replay protection." > > how about "where subsequent data is not protected by..." Yes, that's fine. > > Further on in 3.1, the last paragraph starts > > "Lower lower transports..." > > which I guess should be > > "Lower level transports..." > > I think it is "Lower layer transports" Ok. > > * In the rewritten section 7 (Issue 113) there's one dangling "adversary" left, > > which I assume should be attacker. > > Yes. Good. Fixes going in. Henrik -- Does the name Pavlov ring a bell? From mohanp@tahoenetworks.com Tue May 6 18:09:49 2003 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Tue, 6 May 2003 10:09:49 -0700 Subject: [eap] RE: clarification in rfc2284-bis-02.txt Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C13B8@TNEXVS02.tahoenetworks.com> Pasi, >=20 > On May 3, Mohan Parthasarathy wrote: >=20 > > Hello, > >=20 > > In section 3.1, Lower layer requirements, > >=20 > > As a result of these considerations, EAP SHOULD be=20 > used only when > > lower layers provide physical security for data (e.g. wired PPP > > or IEEE 802 links), or for insecure links, where per-packet > > authentication, integrity and replay protection is provided. > > Where keying material for the lower layer ciphersuite is itself > > provided by EAP, typically the lower layer ciphersuite=20 > cannot be > > enabled until late in the EAP conversation, after key=20 > derivation > > has completed. Thus it may only be possible to use the lower > > layer ciphersuite to protect a portion of the EAP conversation, > > such as the EAP Success or Failure packet. > >=20 > > I have couple of questions.=20 > >=20 > > 1) How do you delay the EAP success packet so that it can be > > protected ? For example, if you are using ECP, you should have > > reached the IPCP negotiation phase. But IPCP has not begun until=20 > > EAP success packet is transmitted. right ? what am I missing ? > >=20 > > 2) Under what conditions the EAP failure packet can be protected ? > > Doesn't failure imply that key has not been derived ? >=20 > I think the draft is misleading here: as far as I know (please correct > me if I'm wrong :), existing lower layers that use EAP transmit the > EAP success packet unprotected, and enable the ciphersuite only after > that. >=20 > If this is indeed the case, I suggest we the text to: >=20 > "... When keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite is enabled=20 > only after the EAP conversion has concluded. Thus, the EAP=20 > conversation=20 > itself is usually not protected." >=20 This sounds reasonable to me. Is that acceptable to everyone ? -thanks mohan > Best regards, > Pasi >=20 From aboba@internaut.com Tue May 6 18:58:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 10:58:18 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 122: Clarification of LL requirements Message-ID: The text of Issue 122 is given below. The proposed resolution is to change a paragraph within Section 3.1 from: "As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g. wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided. Where keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus it may only be possible to use the lower layer ciphersuite to protect a portion of the EAP conversation, such as the EAP Success or Failure packet." To: "As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g. wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided. Where keying material for the lower layer ciphersuite is itself provided by EAP, ciphersuite negotiation and key activation is controlled by the lower layer. In PPP, ciphersuites are negotiated within ECP so that it is not possible to use keys derived from EAP authentication until the completion of ECP. Therefore an initial EAP exchange cannot protected by a PPP ciphersuite, although EAP re-authentication can be protected. In IEEE 802 media, key activation also typically occurs after completion of EAP authentication, so that while an EAP re-authentication or pre-authentication exchange can be protected by a lower layer ciphersuite, an initial EAP exchange typically cannot be." Comments? --------------------------------------------------- Issue 122: Clarification of LL requirements Submitter name: Mohan Parthasarathy Submitter email address: mohanp@tahoenetworks.com Date first submitted: May 2, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-May/001121.html Document: EAP-02 Comment type: T Priority: S Section: 3.1 Rationale/Explanation of issue: In section 3.1, Lower layer requirements, As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g. wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided. Where keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus it may only be possible to use the lower layer ciphersuite to protect a portion of the EAP conversation, such as the EAP Success or Failure packet. I have couple of questions. 1) How do you delay the EAP success packet so that it can be protected ? For example, if you are using ECP, you should have reached the IPCP negotiation phase. But IPCP has not begun until EAP success packet is transmitted. right ? what am I missing ? 2) Under what conditions the EAP failure packet can be protected ? Doesn't failure imply that key has not been derived ? [Pasi Eronen] I think the draft is misleading here: as far as I know (please correct me if I'm wrong :), existing lower layers that use EAP transmit the EAP success packet unprotected, and enable the ciphersuite only after that. If this is indeed the case, I suggest we the text to: "... When keying material for the lower layer ciphersuite is itself provided by EAP, typically the lower layer ciphersuite is enabled only after the EAP conversion has concluded. Thus, the EAP conversation itself is usually not protected." [BA] Mohan is correct that not all link layers can permit protection of EAP packets within an initial authentication. In PPP, ECP can only begin after authentication has completed so protection of EAP packets is only possible for re-authentication. It would be possible for an EAP Failure to be protected in re-authentication, or pre-authentication, where lower layer protection is already in place. However, for an initial authentication, given the changes made in Issue 116, it is now expected that the Success/Failure packet will match the outcome of the single authentication method that is run. As a result, a Failure could only be protected if a key were derived *and* somehow the peer failed to authenticate to the authenticator. This could happen in a protocol such as PEAP. From aboba@internaut.com Tue May 6 19:12:41 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 11:12:41 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication Message-ID: I do think that the suggested change is close to the correct meaning, though some issues arise with the following paragraph: "This definition differs from the usual definitions of authentication (e.g. "verification of claimed identity"), since the authenticator may decide to deny access even when the identity of the peer is known and verified, or vice versa (allow access when the identity of the peer is not verified)." Even with the changes made in Issue 116, I think it is possible for an authenticator to allow access to a peer which has failed to authenticate to it. Presumably this would occur with restricted access, so that the peer might have a chance to correct the deficiency (e.g. signup for an account, send an email to get help, etc.). I think that would need to be done with a method that either was one-way, or where the peer successfully authenticated the authenticator. Might want to double check whether there are any other "gotchas" in the draft bearing on this. I do agree that the authenticator may decide to deny access even when the identity of the peer is known and verified. However, I think that given the changes we've made in Issue 116, it would be necessary for the EAP method to indicate that an authentication failure has occurred for this to work, and depending on the protocol this might or might not be supported. For example, let's say that I am only allowed access from 8 AM to 5 PM under my plan. I attempt to connect at 6 PM, and correctly input my credentials. After examining the access policy, the AAA server will send an Access Reject to the NAS. If it is not careful it could also send an EAP Success encapsulated within that Access Accept. To avoid this, we introduced language in RFC 2869bis to discourage such a contradictory message. So the AAA server presumably now encapsulates an EAP Failure within the Access Reject. However, if the AAA server didn't examine the policy until after the EAP method was complete, there can be trouble because the method presumably completed successfully. As a result, the changes indicated in Issue 116 would cause the EAP Failure to be silently discarded since it doesn't agree with the result of the EAP method authentication which was successful. One response to this problem is that the AAA server should examine the policy early on and appropriately terminate the method, so that it's not a protocol issue, but an implementation issue. I'm not sure I find this 100% convincing however, because in some methods (EAP TLS, for example), there may not be a method-specific error message that appropriately conveys an "authenticated but not authorized" error. So if we're going to go down this road, we probably need to add some advice in the method Appendix to make sure that those messages are available. ---------------------------------------------------------- Issue 121: Document meaning of successful authentication Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 2, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-May/001115.html Document: EAP-02 Comment type: T Priority: 1 Section: 1.2 (and possibly others) Rationale/Explanation of issue: It seems that in EAP we're using the word "authentication" in somewhat non-standard sense, and I feel we should document it. Here's a first draft of text for section 1.2 (terminology): "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access. This definition differs from the usual definitions of authentication (e.g. "verification of claimed identity"), since the authenticator may decide to deny access even when the identity of the peer is known and verified, or vice versa (allow access when the identity of the peer is not verified). Furthermore, even if the authenticator decides to allow access, the peer may consider the exchange a failure if it has not successfully verified that it is talking to the intended authenticator." Do you think this captures the meaning accurately? (It might require some small changes somewhere else in the document, I can try to find them...) From aboba@internaut.com Tue May 6 19:25:19 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 11:25:19 -0700 (PDT) Subject: [eap] Re: Issue 120: Passphrases in EAP Message-ID: With respect to UTF-8, we have added the following to the terminology section in RFC 2284bis: Displayable Message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Also, Section 5.1 states that the EAP-Request/Identity is encoded as UTF-8 if it contains a displayable message. Section 5.2 says that Notification Requests are encoded as UTF-8. Given all of this, it strikes me that encoding passphrases as UTF-8 is in keeping with the general direction of RFC 2284bis, and so Pasi's suggestions (see below) seem reasonable to me. If there are EAP implementations that would be broken by the proposed fixes, now would be a good time to step forward. ------------------------------------------------------------------- Issue 120: Passphrases in EAP Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Date first submitted: April 30, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-April/001107.html Document: EAP-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: Several of the PPP/EAP authentication protocols are in essence "password authentication protocols" (PAP, CHAP, EAP-MD5). This means that the shared secret is in essence a string in some alphabet (most often US-ASCII), as opposed to the more low-level view of a bitstring. Currently the specifications of these protocols define the shared secret as an arbitrary string of octets. This has caused in practice a serious interoperability problem, leaving implementations free to define the following: - Alphabet the password is defined in. - Derivation of shared secret from password. As an example some implementations assume CHAP to encode the password as US-ASCII (or Latin-1 or some other 8-bit alphabet) and MS-CHAPv2 to encode the password as UCS-2. This leads to obvious problems. If the user actually has characters in his/her password not expressible in US-ASCII. He/she/it should have sufficient know-how to be able to disable CHAP when negotiating an authentication protocol. An implementation also might have to guess the alphabet to use. These settings might also differ from system to system. In some cases one could try to deduce an intelligent guess based on some (e.g. out-of-band) vendor identification for the peer. These pitfalls should be avoided in the future. I propose that the working group standardize the following functions: a) If an authentication protocol is keyed by a "passphrase", then the algorithm used to derive a representation of a shared secret. If any cryptography is involved, the protection of the shared secret (if performed) should still be left to the individual EAP method. b) The alphabet to be used for this (assuming the WG feels that a superset alphabet exists), or if the WG feels that it is not prudent to specify a superset alphabet at this point in time, a tagging mechanism in the protocol to denote the alphabet used in mapping a passphrase to a bitstring. The current draft specifies that the UTF-8 is used to represent all human-readable data. An acceptable solution would be to state, that ALL human readable data in ALL EAP methods (except methods specified before xx.yy.zzzz) must be represented using UTF-8. This would include passphrases. Also the alphabsets used in methods before xx.yy.zzzz should be defined, by a poll checking current implementations. This would require introduction of two EAP-MD5 methods. [Pasi Eronen]: Hmm, good point; we already specify that displayable messages use UTF-8, but the same problem also applies to input data. While I'm not so sure that we should try to force all existing EAP methods to use UTF-8, we probably should at least recommend something for methods specified in 2284bis. Here's suggested text (written as MAY/SHOULD, not MUST). Add to end of section 5.1: "EAP does not place any other requirements on the contents of the Identity Response, as different representations may be appropriate in different contexts. In the absence of other guidance, the Identity MAY be a Network Access Identifier (NAI) conforming to [RFC2486], with the following exceptions allowed: - The username portion MAY be empty. This can be useful with EAP methods that have their own identity protection mechanism, but use the realm portion to route messages to the correct backend server. - The username portion MAY contain Unicode characters greater than U+007F encoded using UTF-8 [RFC2279]." Add to 5.4 (MD5-Challenge), before Type: "Note: [RFC1994] treats the shared secret as a byte string, and does not specify how it is entered into the system (or if it is handled by the user at all). For EAP MD5-Challenge method, if the shared secret is a passphrase entered by the user, it SHOULD be converted into bytes using UTF-8 encoding [RFC2279]." Add to 5.5 (OTP), before Security Claims: "Note: [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. For EAP OTP method, the pass-phrase SHOULD be encoded using UTF-8 [RFC2279]." Add to 5.6 (GTC), before Security Claims: "If the data entered by the user contains non-ASCII characters, it SHOULD be encoded using UTF-8 [RFC2279]." [Lauri Tarkkala]: Your proposed solution is IMHO not satisfactory, for the simple reason that the alphabet used to represent the passphrase is a parameter in selecting the acceptable authentication method (or the used authentication method is a parameter in choosing the passphrase). A simple example: - Client wishes to authenticate with EAP using a shared-secret scheme to Server, where server assumes alphabet Y for on-the-wire representation. - Client holds passphrase expressible in alphabet X, but not alphabet Y. - Authentication will not succeed. Interoperability would require that the user know the EAP methods used before he/she chooses his/her password! A requirement for an acceptable solution IMHO is that the character set used for the passphrase SHOULD NOT be related to an EAP method (with the possible exception of some legacy methods). A user should not need to know that "if my password contains the Japanese Kanji I can only authenticate using the EAP method xyzzy". I do agree with you, that forcing all EAP methods into the same alphabet is not wise. I also think that interoperability with existing EAP-MD5/etc implementations is important (otherwise implementors would still have to sniff out, based on some indidcators about the peer vendor, what encoding to use). I feel that a better solution would be to classify EAP methods according to the key-type used into "passphrase-keyed methods" and "binary-keyed methods". Ideally, each method would have an instance in both classifications. This could be achieved by reserving a bit in the type field of a method (with the obvious consequence of halving the namespace), e.g. assuming "passphrase-keying" is indicated by bit 6: - EAP-MD5 keyed by a binary string would be method 0x05. - EAP-MD5 keyed by a passphrase in UTF-8 would be method 0x45. The bit would have the following semantics: - If the passphrase-keying bit is set by the authenticator, then it means "authenticator supports passphrase-keying". - If the passphrase-keying bit is set by the authenticatee, then it means "that key used is a passphrase in UTF-8 encoding". Any opinions? Any ideas on some better place to find bits for this indication? From mohanp@tahoenetworks.com Tue May 6 21:23:11 2003 From: mohanp@tahoenetworks.com (Mohan Parthasarathy) Date: Tue, 6 May 2003 13:23:11 -0700 Subject: [eap] Proposed resolution to Issue 122: Clarification of LL requirements Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C13BC@TNEXVS02.tahoenetworks.com> Bernard, >=20 > The text of Issue 122 is given below. The proposed resolution=20 > is to change > a paragraph within Section 3.1 from: >=20 > "As a result of these considerations, EAP SHOULD be used only when > lower layers provide physical security for data (e.g. wired PPP > or IEEE 802 links), or for insecure links, where per-packet > authentication, integrity and replay protection is provided. > Where keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite cannot be > enabled until late in the EAP conversation, after key derivation > has completed. Thus it may only be possible to use the lower > layer ciphersuite to protect a portion of the EAP conversation, > such as the EAP Success or Failure packet." >=20 > To: >=20 > "As a result of these considerations, EAP SHOULD be used only when > lower layers provide physical security for data (e.g. wired PPP > or IEEE 802 links), or for insecure links, where per-packet > authentication, integrity and replay protection is provided. >=20 > Where keying material for the lower layer ciphersuite is itself > provided by EAP, ciphersuite negotiation and key activation is > controlled by the lower layer. In PPP, ciphersuites are negotiated > within ECP so that it is not possible to use keys derived from > EAP authentication until the completion of ECP. Therefore an > initial EAP exchange cannot protected by a PPP ciphersuite, ^ be > although EAP re-authentication can be protected. >=20 > In IEEE 802 media, key activation also typically occurs after > completion of EAP authentication, so that while an EAP > re-authentication or pre-authentication exchange can be > protected by a lower layer ciphersuite, an initial EAP > exchange typically cannot be." >=20 One possible rephrasing to match the one above.. In IEEE 802 media, key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange=20 cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected. Re-authetnication and pre-authentication are not defined ? Does it matter ? -mohan =20 >=20 > Comments? >=20 > --------------------------------------------------- > Issue 122: Clarification of LL requirements > Submitter name: Mohan Parthasarathy > Submitter email address: mohanp@tahoenetworks.com > Date first submitted: May 2, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-May/001121.html > Document: EAP-02 > Comment type: T > Priority: S > Section: 3.1 > Rationale/Explanation of issue: >=20 > In section 3.1, Lower layer requirements, >=20 > As a result of these considerations, EAP SHOULD be used only when > lower layers provide physical security for data (e.g. wired PPP > or IEEE 802 links), or for insecure links, where per-packet > authentication, integrity and replay protection is provided. > Where keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite cannot be > enabled until late in the EAP conversation, after key derivation > has completed. Thus it may only be possible to use the lower > layer ciphersuite to protect a portion of the EAP conversation, > such as the EAP Success or Failure packet. >=20 > I have couple of questions. >=20 > 1) How do you delay the EAP success packet so that it can be > protected ? For example, if you are using ECP, you should have > reached the IPCP negotiation phase. But IPCP has not begun until EAP > success packet is transmitted. right ? what am I missing ? >=20 > 2) Under what conditions the EAP failure packet can be protected ? > Doesn't failure imply that key has not been derived ? >=20 > [Pasi Eronen] >=20 > I think the draft is misleading here: as far as I know (please correct > me if I'm wrong :), existing lower layers that use EAP transmit the > EAP success packet unprotected, and enable the ciphersuite only after > that. >=20 > If this is indeed the case, I suggest we the text to: >=20 > "... When keying material for the lower layer ciphersuite is itself > provided by EAP, typically the lower layer ciphersuite is enabled > only after the EAP conversion has concluded. Thus, the EAP=20 > conversation > itself is usually not protected." >=20 > [BA] >=20 > Mohan is correct that not all link layers can > permit protection of EAP packets within an > initial authentication. In PPP, ECP > can only begin after authentication has completed > so protection of EAP packets is only possible for > re-authentication. >=20 > It would be possible for an EAP Failure to be > protected in re-authentication, or pre-authentication, > where lower layer protection is already in place. > However, for an initial authentication, > given the changes made in Issue 116, > it is now expected that the Success/Failure > packet will match the outcome of the single > authentication method that is run. As a result, > a Failure could only be protected if a key were > derived *and* somehow the peer failed to > authenticate to the authenticator. This could > happen in a protocol such as PEAP. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From aboba@internaut.com Wed May 7 07:55:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 6 May 2003 23:55:11 -0700 (PDT) Subject: [eap] Re: Issue 112: Rewrite of IANA Considerations Message-ID: Jari Arkko wrote: ""Seems clear" does not seem clear to me ;-) That is, I'm not sure how the DE evaluates this condition. Can we be more specific? An allocation is approved if the DE approves the method, and the method description has been submitted as an Internet Draft? Or has been submitted to the RFC Editor / IESG for publication? Or WG / IETF LC started / finished? (Specification Required might fit our requirements otherwise well, but I think we wanted to get allocations slightly earlier than it would mean. Then again RFC 2434 doesn't explicitly say in which order things will happen.)" There are a number of issues that this paragraph is attempting to address. One is the need for a permanent published specification (an RFC). "Specification Required" doesn't do this -- someone could post a spec at a URL, or as an Internet-Draft, and it could expire or the URL could become invalid at some future time. At the same time, you don't necessarily want to wait for publication of an RFC before providing an allocation. I do agree that "seems clear that an RFC will be published" is somewhat vague, especially since the document could have a reference hold and therefore not be published until some other document is completed. To my mind I think that "enters the RFC Editor queue" is sufficient. We could add this as an example. From Pasi.Eronen@nokia.com Wed May 7 11:46:01 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 7 May 2003 13:46:01 +0300 Subject: [eap] Re: Issue 121: Document meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> Bernard Aboba wrote: > However, if the AAA server didn't examine the policy until > after the EAP method was complete, there can be trouble > because the method presumably completed successfully. As a > result, the changes indicated in Issue 116 would cause the EAP > Failure to be silently discarded since it doesn't agree with > the result of the EAP method authentication which was > successful. > > One response to this problem is that the AAA server should > examine the policy early on and appropriately terminate the > method, so that it's not a protocol issue, but an implementation > issue. I'm not sure I find this 100% convincing however, because > in some methods (EAP TLS, for example), there may not be a > method-specific error message that appropriately conveys an > "authenticated but not authorized" error. So if we're going to > go down this road, we probably need to add some advice in the > method Appendix to make sure that those messages are available. I think this problem appears only if we assume that the client and the server have to have the same opinion about if the EAP method succeeded or not (success being defined as "will allow access to the other party"). I don't think this is the case with most EAP methods. The current approach taken in the EAP state machine draft (-02) is that some methods may have an internal mechanism for=20 communicating an "access allowed/denied" message=20 ("confirmed success/failure") from the server to the client. =20 If the client gets an "access allowed" message (methodState=20 CON_ACC), then a Failure packet will be silently discarded=20 (and for methodState CON_REJ, Success packet will be discarded). The end result (of the client) is an AND of the server's=20 decision and the client's own decision ("do I want to talk=20 to this server"). However, most methods do not have such a message, and they will simply report "ordinary success" (their own decision, not the server's). The server's decision is communicated using a=20 Success or Failure packet (both are allowed), and the end=20 result is again an AND of client's and server's decision. I know this is a bit complicated, but it seems to capture a reasonable set of behavior that applies to all EAP methods? If it's actually what we want to happen, I think we should include a discussion explaining it in 2284bis (perhaps somewhere near where success and failure are explained). (I can try to write something if you think this is what we want to say) Best regards, Pasi From Pasi.Eronen@nokia.com Wed May 7 12:23:07 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 7 May 2003 14:23:07 +0300 Subject: [eap] Re: Issue 120: Passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BAE4@esebe023.ntc.nokia.com> Bernard Aboba wrote: > Given all of this, it strikes me that encoding passphrases as=20 > UTF-8 is in keeping with the general direction of RFC 2284bis,=20 > and so Pasi's suggestions (see below) seem reasonable to me. >=20 > If there are EAP implementations that would be broken by the proposed > fixes, now would be a good time to step forward. I had a discussion with Patrik F=E4ltstr=F6m about UTF-8 in NAIs, and he pointed out that just specifying an encoding method (UTF-8) is not enough. For instance, the character in Patrik's=20 name can be represented in Unicode as "U+E4" (latin small=20 letter a with diaeresis) or "U+41 U+308" (latin small letter a +=20 combining diaeresis). Both are equally valid, but obviously=20 implementations have to use the same form for a password or=20 they won't interoperate. Fortunately (phwww....), we don't have to know more about this, and can simply cite an appropriate RFC. Here's an updated text: Add to 5.4 (MD5-Challenge), before Type: "Note: [RFC1994] treats the shared secret as an octet string, and does not specify how it is entered into the system (or if it is handled by the user at all). For EAP MD5-Challenge method, if the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input SHOULD be processed using an appropriate stringprep [RFC3454] profile, and encoded into octets using UTF-8 encoding [RFC2279]. At this writing, no suitable registered stringprep profile exists, but one is being worked on [SASLPREP]." Add to 5.5 (OTP), before Security Claims: "Note: [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. For EAP OTP method, implementations MAY support entering passphrases with non-ASCII characters. See Section 5.4 for instructions how the input should be processed and encoded=20 into octets." Add to 5.6 (GTC), before Security Claims: "Implementations MAY support entering a response with non-ASCII characters. See Section 5.4 for instructions how the input should=20 be processed and encoded into octets." Add to informative (?) references: [RFC3454]=20 Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002. [SASLPREP]=20 Zeilenga, K.D., "SASLprep: Stringprep profile for user names and=20 passwords", draft-ietf-sasl-saslprep-01 (work in progress), May 2003. Best regards, Pasi From ltarkkal@ssh.com Wed May 7 13:00:30 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Wed, 7 May 2003 15:00:30 +0300 Subject: [eap] Re: Issue 120: Passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BAE4@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BAE4@esebe023.ntc.nokia.com> Message-ID: <20030507120030.GA1598@tehdas> Sorry about all the posts on this issue, but I promise this will be (one of) the last (ones). Please bear with me... ;-) On Wed, May 07, 2003 at 02:23:07PM +0300, Pasi.Eronen@nokia.com wrote: > [SASLPREP] > Zeilenga, K.D., "SASLprep: Stringprep profile for user names and > passwords", draft-ietf-sasl-saslprep-01 (work in progress), May 2003. We must make the following decision: D1) Specify our own stringprep profile. D2) Wait till the SASLprep one makes RFC status, and then cite it. D3) Leave the issue to be resolved later. Pasi's wording above seems to imply decision "D2" (an RFC will probably not get accepted by the IESG if it references an I-D, as all probably know). And on a more general note: The WG seems to be uninterested in introducing separate EAP-MD5 method, which would be strictly unicode compliant (e.g. there would be no ambiguity about what character set is used to encode the passphrase and how to do it). This means, that in the short term, even with a published and matured EAP specification, the following order of preference would be the most sensible to use in negotiating an authentication method in a widely-used PPP implementation: 1. MS-CHAPv2 2. MS-CHAPv1 3. EAP -> Then try methods which define passphrase encoding strictly -> Then methods which do not. This will not change, untill a better order of preference exists for achieving interoperability, even if the first two methods are only published as Informational RFC's. Some of you may have the luxury of being able to operate in a pure US-ASCII environment, or in an environment with a single 8-bit character set (e.g. Latin1), others are not so lucky and neither do they have the technical understanding to configure these features. Note that MS-CHAP has been the ONLY workable solution as a passphrase protocol that can be used all over the globe, and which can handle pretty much any passphrases present in the password database. I hate to trumpet a proprietary protocol, but this is the way it is. No WG member has made explicit statements regarding the following: A. Is it OK, that passphraseses MAY NOT be inter-operable between passphrase-keyed EAP methods? B. Is it OK, that the only mandatory EAP method, does not exactly specify how it should be used in Unicode environments? If the WG feels that the answer to question "A" is NO (as I do), then I would recommend adding the following note to the draft: Add to section "2" after point [4]. "[5] If the EAP method is keyed by a human-readable passphrase, then it MUST be possible to provide that passphrase in Unicode, which is transformed using stringprep [RFC3454] profile XXX [RFCXXX] before it is input into the EAP authentication method. This SHOULD be the default mode of operation." This leaves the implementations to use a different mode of operation if they choose, but should hopefully steer all implementations of methods toward interoperabiity, without impacting individual method specifications. Furthermore, after the discussion on this list, I feel that it is better to tackle this as an "implementation issue" in the specification, than as a "method specification issue". I personally feel that the answer to question "B" should be NO, and suggest a slight rewording of Pasi's suggestion (change of priorities). Add to 5.4 (MD5-Challenge), before Type: "For EAP MD5-Challenge method, if the shared secret is a passphrase entered by the user, implementations MUST support entering passphrases with non-ASCII characters. In this case, the input MUST be processed using the stringprep [RFC3454] profile XXX [RFCXXXX] and encoded into octets using UTF-8 encoding [RFC2279]. This is in accordance with item [5] in section 2." Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From aboba@internaut.com Wed May 7 14:23:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 06:23:53 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> Message-ID: > I think this problem appears only if we assume that the client > and the server have to have the same opinion about if the EAP > method succeeded or not (success being defined as "will allow > access to the other party"). It might be ok for the authenticator to be willing to grant access, and the peer to be unwilling to use the link, because the peer would then disconnect, which the authenticator could detect. However, I do not think it is ok for the authenticator to refuse to grant access and the peer to be unaware of this, because the peer will continue to attempt to use the link, with no success, unaware of what it needs to do in order to authenticate. For example, the peer will attempt to obtain an IP address via DHCPv4, which will fail and as a result it will then obtain an IPv4 linklocal address. Under draft-ietf-zeroconf-ipv4-linklocal, the host might not check for the presence of a DHCP server for another 5 minutes. The result is a very long period of frustration for the user, support calls, etc. This problem was encountered in IEEE 802.1X-2001 and resulted in a frustrating user experience. As a result, we had to clarify RFC 2869bis so as to require consistency between AAA messages and the embedded EAP messages. > I don't think this is the case with most EAP methods. It's not really an EAP method issue -- it's a basic protocol operation issue. > The end result (of the client) is an AND of the server's > decision and the client's own decision ("do I want to talk > to this server"). The problem with this is that both sides need to eventually become aware of each other's state and in the authenticator failure/peer success case this could take a considerable period of time and create an administrative burden along the way. > The server's decision is communicated using a > Success or Failure packet (both are allowed) The problem is that you previously indicated that this message was silently discarded by the peer -- so how is it "communicated"? > I know this is a bit complicated, but it seems to capture a > reasonable set of behavior that applies to all EAP methods? Actually, I don't think that the behavior is all that reasonable -- it appears to result in multi-minute timeouts, user frustration and an expensive support burden. From jrv@umich.edu Wed May 7 14:51:06 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 07 May 2003 09:51:06 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication Message-ID: <313302.1052301066@[10.0.1.2]> --On Tuesday, May 6, 2003 11:12 AM -0700 Bernard Aboba wrote: > I do think that the suggested change is close to the correct meaning, > though some issues arise with the following paragraph: > > "This definition differs from the usual definitions of > authentication (e.g. "verification of claimed identity"), > since the authenticator may decide to deny access even when > the identity of the peer is known and verified, or vice versa > (allow access when the identity of the peer is not verified)." > > Even with the changes made in Issue 116, I think it is possible for an > authenticator to allow access to a peer which has failed to authenticate > to it. Presumably this would occur with restricted access, so that the > peer might have a chance to correct the deficiency (e.g. signup for an > account, send an email to get help, etc.). I think that would need to be > done with a method that either was one-way, or where the peer successfully > authenticated the authenticator. Might want to double check whether > there are any other "gotchas" in the draft bearing on this. > > I do agree that the authenticator may decide to deny access even when the > identity of the peer is known and verified. However, I think that given > the changes we've made in Issue 116, it would be necessary for the EAP > method to indicate that an authentication failure has occurred for this to > work, and depending on the protocol this might or might not be supported. > > For example, let's say that I am only allowed access from 8 AM to 5 PM > under my plan. I attempt to connect at 6 PM, and correctly input my > credentials. After examining the access policy, the AAA server will send > an Access Reject to the NAS. If it is not careful it could also send an > EAP Success encapsulated within that Access Accept. To avoid this, we > introduced language in RFC 2869bis to discourage such a contradictory > message. So the AAA server presumably now encapsulates an EAP Failure > within the Access Reject. > > However, if the AAA server didn't examine the policy until after the EAP > method was complete, there can be trouble because the method presumably > completed successfully. As a result, the changes indicated in Issue 116 > would cause the EAP Failure to be silently discarded since it doesn't > agree with the result of the EAP method authentication which was > successful. > > One response to this problem is that the AAA server should examine the > policy early on and appropriately terminate the method, so that it's not > a protocol issue, but an implementation issue. I'm not sure I find this > 100% convincing however, because in some methods (EAP TLS, for example), > there may not be a method-specific error message that appropriately > conveys an "authenticated but not authorized" error. So if we're going to > go down this road, we probably need to add some advice in the method > Appendix to make sure that those messages are available. > > I think there are two points here. First, a RADIUS Access Accept message may contain any EAP message, including and EAP-Failure. This is confusing and SHOULD not happen. We have allowed this because RADIUS is acting as a carrier of EAP, and it seemed inappropriate to limit what EAP can within RADIUS. Perhaps this is a mistake, and we should make it a MUST NOT for RADIUS Access Accept to contain an EAP-Failure? Second, EAP conversations consist of a sequence of methods and policy c0nnecting them. The allowed non tunnelled sequences are quite simple, usually consisting of Identity followed by a selected authentication method. The selection/negotiation of the method may depend on policy. In addition EAP itself want to include a policy which says that a user is allowed access only between 9 and 5. While this could be included in every EAP method somehow, that seems unwieldy, requiring every method to support every type of policy. More likely it will be enforced independently by "EAP-policy". A policy rule could be enforced before or after a method is run. The 9-5 rule, for example, could be checked before or after the authentication method. If it is checked before, the authentication method does not have to run if the policy fails. If it runs after, the EAP conversation may fail even if the method succeeded. In most cases this can be avoided, but there may be policy that depends on the output of a method as input to the policy. If the output is binary (success/failure) only, it is hard to imagine a policy that could not be run before the method, allowing the method to execute only if method success means dialog success. I a method can create other output [for example group membership] that can be checked, the issue is not as easy. My suggestion is that we indicate strongly that the CON_ACC output of a method MUST be followed by an EAP-Success, and that it SHOULD only be used with protected Tunnelled methods, such as PEAP. > > > > > > > > > > > > ---------------------------------------------------------- > Issue 121: Document meaning of successful authentication > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: May 2, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-May/001115.html > Document: EAP-02 > Comment type: T > Priority: 1 > Section: 1.2 (and possibly others) > Rationale/Explanation of issue: > > It seems that in EAP we're using the word "authentication" > in somewhat non-standard sense, and I feel we should document > it. > > Here's a first draft of text for section 1.2 (terminology): > > "Successful authentication > > In the context of this document, "successful authentication" > is an exchange of EAP messages, as a result of which the > authenticator decides to allow access for the peer, and the > peer decides to use this access. > > This definition differs from the usual definitions of > authentication (e.g. "verification of claimed identity"), > since the authenticator may decide to deny access even when > the identity of the peer is known and verified, or vice versa > (allow access when the identity of the peer is not verified). > > Furthermore, even if the authenticator decides to allow access, > the peer may consider the exchange a failure if it has not > successfully verified that it is talking to the intended > authenticator." > > Do you think this captures the meaning accurately? > (It might require some small changes somewhere else > in the document, I can try to find them...) > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed May 7 14:34:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 06:34:49 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> Message-ID: > It might be ok for the authenticator to be willing to grant access, > and the peer to be unwilling to use the link, because the peer would then > disconnect, which the authenticator could detect. However, I do not think > it is ok for the authenticator to refuse to grant access and the peer to > be unaware of this, because the peer will continue to attempt to use the > link, with no success, unaware of what it needs to do in order to > authenticate. For example, the peer will attempt to obtain an IP > address via DHCPv4, which will fail and as a result it will then obtain an > IPv4 linklocal address. Under draft-ietf-zeroconf-ipv4-linklocal, the host > might not check for the presence of a DHCP server for another 5 minutes. > The result is a very long period of frustration for the user, support > calls, etc. BTW, one way to deal with this is to assume that the authenticator will inform the peer of the state of authentication via a lower layer mechanism. For example, if an Access Reject is received from the AAA server, the authenticator will decapsulate the embedded EAP packet (EAP Faliure) and send it to the peer. The peer might silently discard the EAP Failure packet because the authenticator successfully authenticated to it so that the method succeeded. However, we do say that the peer MUST act on lower layer failure indications. So in PPP, the authenticator can send an LCP terminate, and in IEEE 802.11 it can send a Disassociate or Deauthenticate. The problem is that in IEEE 802.11i they are now talking about silently discarding the Disassociate or Deauthenticate messages too :( My suggestion would be to add some additional discussion about this so as to make clear what the authenticator needs to do in order to ensure consistency. From jrv@umich.edu Wed May 7 15:25:31 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 07 May 2003 10:25:31 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> Message-ID: <437189.1052303131@[10.0.1.2]> --On Wednesday, May 7, 2003 6:23 AM -0700 Bernard Aboba wrote: > > I think this problem appears only if we assume that the client > > and the server have to have the same opinion about if the EAP > > method succeeded or not (success being defined as "will allow > > access to the other party"). > > It might be ok for the authenticator to be willing to grant access, > and the peer to be unwilling to use the link, because the peer would then > disconnect, which the authenticator could detect. However, I do not think If the authenticator can detect it I would think the peer could as well. Is this not the case? >it is ok for the authenticator to refuse to grant access and the peer to > be unaware of this, because the peer will continue to attempt to use the > link, with no success, unaware of what it needs to do in order to > authenticate. For example, the peer will attempt to obtain an IP > address via DHCPv4, which will fail and as a result it will then obtain an > IPv4 linklocal address. Under draft-ietf-zeroconf-ipv4-linklocal, the host > might not check for the presence of a DHCP server for another 5 minutes. > The result is a very long period of frustration for the user, support > calls, etc. > > This problem was encountered in IEEE 802.1X-2001 and resulted in a > frustrating user experience. As a result, we had to clarify RFC 2869bis > so as to require consistency between AAA messages and the embedded EAP > messages. > > > I don't think this is the case with most EAP methods. > > It's not really an EAP method issue -- it's a basic protocol operation > issue. > I agree it is a protocol not method issue. if the Success/Failure message was acknowledged would this solve the protocol problem? > > The end result (of the client) is an AND of the server's > > decision and the client's own decision ("do I want to talk > > to this server"). > > The problem with this is that both sides need to eventually become aware > of each other's state and in the authenticator failure/peer success case > this could take a considerable period of time and create an administrative > burden along the way. > > > The server's decision is communicated using a > > Success or Failure packet (both are allowed) > > The problem is that you previously indicated that this message was > silently discarded by the peer -- so how is it "communicated"? > > > I know this is a bit complicated, but it seems to capture a > > reasonable set of behavior that applies to all EAP methods? > > Actually, I don't think that the behavior is all that reasonable -- it > appears to result in multi-minute timeouts, user frustration and > an expensive support burden. > I think Pasi's description is quite good. Seems to me the options actually open to us, without adding acknowledged ACK for success/Failure messages are 1. always accept success and failure messages and accept the consequences of possible DOS attacks using them 2. use method indication of where there is a confirmed success and not allow Failure. This leave the possiblity a Failure sent would be ignored and the peer would hang thinking it had succeeded. I think the second scenario allows the use of protected methods like PEAP and avoid DOS attacks. [ PEAP might want to define a protected Success/Failure that IS acknowledged within it self - might be worth looking at how to do that.] The risk with the second method seems low if only used with protected methods. From Pasi.Eronen@nokia.com Wed May 7 15:26:25 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 7 May 2003 17:26:25 +0300 Subject: [eap] Re: Issue 120: Passphrases in EAP Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122288@esebe023.ntc.nokia.com> Lauri Tarkkala wrote: > We must make the following decision: >=20 > D1) Specify our own stringprep profile. > D2) Wait till the SASLprep one makes RFC status, and then cite it. > D3) Leave the issue to be resolved later. >=20 > Pasi's wording above seems to imply decision "D2" (an RFC will > probably not get accepted by the IESG if it references an I-D, > as all probably know). A standards-track RFC can't contain a normative reference to an I-D, but informative references are OK. I think we could write this so that the reference to SASLPREP would be considered informative (see below).=20 I don't think D1 is an option. > No WG member has made explicit statements regarding the following: >=20 > A. Is it OK, that passphraseses MAY NOT be inter-operable between > passphrase-keyed EAP methods? Depends. Certainly we should try to minimize any interoperability problems, but 2284bis may not be the appropriate place to do it. > B. Is it OK, that the only mandatory EAP method, does not=20 > exactly specify how it should be used in Unicode environments? Yes, for some levels of "exactness" :-) We can't exactly define the behavior without a stringprep profile, and we certainly don't want to wait for SASLPREP to become RFC.=20 I think we could say something like "Behavior for non-ASCII=20 characters is undefined, and will be clarified in a future=20 revision of this document. Our guess is that it will resemble=20 SASLPREP followed by UTF-8.". Something like that would provide enough information to build=20 interoperable implementations, yet make the reference=20 informative. (Though I'm not sure if IESG will allow leaving the behavior undefined in standards-track RFC?) > If the WG feels that the answer to question "A" is NO (as I do), > then I would recommend adding the following note to the draft: >=20 > Add to section "2" after point [4]. >=20 > "[5] If the EAP method is keyed by a human-readable passphrase, > then it MUST be possible to provide that passphrase in Unicode, > which is transformed using stringprep [RFC3454] profile XXX > [RFCXXX] before it is input into the EAP authentication method. > This SHOULD be the default mode of operation." I don't think we should add such a requirement here. Certainly an EAP method should be able to define that it uses a shared secret that MUST contain only ASCII characters (or only characters A-Z except Q, or whatever). Also, no implementation will ever support entering ALL characters defined in Unicode. Implementations will support entering some subset of Unicode characters, and I don't think=20 2284bis is an appropriate place to specify what that subset should be. Best regards, Pasi =20 From Pasi.Eronen@nokia.com Wed May 7 15:45:04 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 7 May 2003 17:45:04 +0300 Subject: [eap] RE: Issue 121: Document meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122289@esebe023.ntc.nokia.com> Bernard Aboba wrote: > It might be ok for the authenticator to be willing to grant > access, and the peer to be unwilling to use the link, because > the peer would then disconnect, which the authenticator could > detect. However, I do not think it is ok for the authenticator > to refuse to grant access and the peer to be unaware of this, > because the peer will continue to attempt to use the link, > with no success, unaware of what it needs to do in order to > authenticate. Sorry, I guess my explanation was a bit misleading in this case. Yes, clearly the situation described above is undesirable, but it should not happen. >> The server's decision is communicated using a >> Success or Failure packet (both are allowed) >=20 > The problem is that you previously indicated that this message was > silently discarded by the peer -- so how is it "communicated"? I intended to say that in the current state machine draft, there are two different ways for the server to communicate its decision to the client. In some EAP methods, the server's decision is communicated inside the method using some method-specific messages (e.g. Success/Failure inside PEAP tunnel). For these methods,=20 if the client has received a "confirmed success" from the=20 method, it will silently discard any Failure packets. In other EAP methods, the same information (yes/no) is communicated using EAP Success and Failure packets (and=20 thus neither of them can be discarded). In both cases, the client will know what the server's decision is, and can make its own decision ("is this the server I want to talk to"). These are then combined with "AND" (meaning that the end result will be "yes" only if both decisions were "yes"). Thus, if the server says "no" (using "confirmed failure" or ordinary Failure message), the end result will be "no", and the client won't have to wait for any timeout to discover this. Best regards, Pasi From aboba@internaut.com Wed May 7 15:32:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 07:32:48 -0700 (PDT) Subject: [eap] Re: Issue 121: Documenting meaning of successful authentication Message-ID: John Vollbrecht wrote: "My suggestion is that we indicate strongly that the CON_ACC output of a method MUST be followed by an EAP-Success, and that it SHOULD only be used with protected Tunnelled methods, such as PEAP." Assuming that the method completes successfully, the peer will be expecting an EAP Success and will silently discard an EAP Failure. So it does seem reasonable for the authenticator to send an EAP Success at that point. We said "SHOULD" in RFC 2869bis because there might be some cases where it could be acceptable for this not to happen. For example, if the AAA server sent an Access-Reject/EAP Failure instead, the peer might silently discard the EAP Failure, but perhaps the NAS could send a lower layer failure indication (PPP LCP-Terminate, 802.11 Deauthenticate/Disassociate) to make sure that the peer understands that access is not being provided. From aboba@internaut.com Wed May 7 15:37:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 07:37:30 -0700 (PDT) Subject: [eap] Re: Issue 120: Passphrases in EAP Message-ID: Lauri Tarkkala wrote: "Pasi's wording above seems to imply decision "D2" (an RFC will probably not get accepted by the IESG if it references an I-D, as all probably know)." In this particular case, the reference applies to a SHOULD so it is hard to argue that it is non-normative. This would result in a Reference Hold in the RFC Editor queue until the normative reference is resolved. We're trying to avoid this fate for RFC 2284bis if at all possible. The possible options are either to remove the SHOULD (such as demoting it to a should or may), or to make it clear that the SASLprep document is only one possible solution and that there might be others. From ltarkkal@ssh.com Wed May 7 15:14:05 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Wed, 7 May 2003 17:14:05 +0300 Subject: [eap] Re: Issue 120: Passphrases in EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122288@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122288@esebe023.ntc.nokia.com> Message-ID: <20030507141405.GA2088@tehdas> On Wed, May 07, 2003 at 05:26:25PM +0300, Pasi.Eronen@nokia.com wrote: > Depends. Certainly we should try to minimize any > interoperability problems, but 2284bis may not be the > appropriate place to do it. I feel that if it is not done in RFC 2284bis, then I fear that it will not be done at all. > I don't think we should add such a requirement here. Certainly > an EAP method should be able to define that it uses a shared > secret that MUST contain only ASCII characters (or only > characters A-Z except Q, or whatever). I feel that our opinions could be unified slightly, by classifying passphrase methods further than in my first post: 1. EAP methods keyed by an arbitrary bitstring. 1a) Shared secret is ALWAYS generated by a RNG. 1b) Shared secret is derived from a passphrase. 2. EAP methods keyed by strings over some other alphabet. Now my interest is defining the behaviour in case 1b, the intent being to have standardized "how to derive the shared secret from a passphrase" in the case the "shared secret is an arbitrary bitstring" (this may have gotten lost in the discussion, but this was the point in my frist post on the topic also, although there I did not explicitly mention the second category). EAP methods with limited alphabets certainly will have limited needs to be interchangeable with other EAP methods, so these are IMHO not really the current concern. As such I still feel my proposal is relevant, although the wording (and place in the specification) may require improvement. Note that I phrased my proposal as an implementation option. The implementation was left free to provide the shared secret in ANY form to the EAP method, as long as it supported one standard way of doing it. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From aboba@internaut.com Wed May 7 16:55:04 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 08:55:04 -0700 (PDT) Subject: [eap] Potential Resolution to Issue 121: Potential meaning of successful authentication Message-ID: The text of Issue 121 is given below. It is also available on the EAP Issues web page (http://www.drizzle.com/~aboba/EAP/eapissues.html). Discussion of this issue has disclosed some inconsistencies between the EAP state machine document and RFC 2284bis. I'd like to propose that we fix this by editing the text of Section 4.2 of RFC 2284bis, rather than attempting to mandate behavior via changes to the terminology section. In going over this issue, I noticed that RFC 2284bis did not mandate silent discard of Success/Failure packets when they are inconsistent with the result of the EAP method, except in the case where the method supports "strict interpretation." Mandating this has some drawbacks because it can result in long timeouts on the peer, unless the authenticator utilizes lower layer indications. Here are some proposed fixes. Comments welcome. Add to the terminology section: "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access." Change the following text in Section 4.2 from: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, the authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the authenticator. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." To: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. On the peer, once the method completes unsuccessfully, the EAP conversation is terminated, and the link is disabled. As a result, loss of a Failure packet need not result in a timeout, and a Success packet MUST be silently discarded by the peer. Since only a single EAP authentication method is allowed within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. Failure packets MUST be silently discarded by the peer. Where the authenticator wishes to deny access even where the peer authenticated successfully (e.g. where the peer may not be authorized for reasons of policy), this can result in lengthy timeouts unless a lower layer failure indication is provided. Section 3.4 provides guidance on the processing of lower layer success and failure indications." ----------------------------------------------------- Issue 121: Document meaning of successful authentication Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 2, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-May/001115.html Document: EAP-02 Comment type: T Priority: 1 Section: 1.2 (and possibly others) Rationale/Explanation of issue: It seems that in EAP we're using the word "authentication" in somewhat non-standard sense, and I feel we should document it. Here's a first draft of text for section 1.2 (terminology): "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access. This definition differs from the usual definitions of authentication (e.g. "verification of claimed identity"), since the authenticator may decide to deny access even when the identity of the peer is known and verified, or vice versa (allow access when the identity of the peer is not verified). Furthermore, even if the authenticator decides to allow access, the peer may consider the exchange a failure if it has not successfully verified that it is talking to the intended authenticator." Do you think this captures the meaning accurately? (It might require some small changes somewhere else in the document, I can try to find them...) From aboba@internaut.com Wed May 7 17:03:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 09:03:15 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <437189.1052303131@[10.0.1.2]> References: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> <437189.1052303131@[10.0.1.2]> Message-ID: > If the authenticator can detect it I would think the peer could as well. Is > this not the case? It depends on whether lower layer indications are sent. For example, in PPP the peer may send an LCP-Terminate if it wants to disconnect, but in my experience that doesn't always happen. Similarly in IEEE 802.11 the peer can wander off without sending a Disassociate. In both cases the authenticator will typically time out the authentication state. That just results in excess resource consumption but on the peer there may be a human user who gets frustrated and makes support calls if she can't authenticate. So the impact of an authenticator not sending a lower layer indication is somewhat greater. > I agree it is a protocol not method issue. if the Success/Failure message > was acknowledged would this solve the protocol problem? I don't think so, becaue if we're going to silently discard the Success/Failure indication on the peer, then the authenticator will just retransmit it until it times out. > I think Pasi's description is quite good. Seems to me the options actually > open to us, without adding acknowledged ACK for success/Failure messages are > > 1. always accept success and failure messages and accept the consequences > of possible DOS attacks using them > 2. use method indication of where there is a confirmed success and not > allow Failure. This leave the possiblity a Failure sent would be ignored > and the peer would hang thinking it had succeeded. > > I think the second scenario allows the use of protected methods like PEAP > and avoid DOS attacks. [ PEAP might want to define a protected > Success/Failure that IS acknowledged within it self - might be worth > looking at how to do that.] The risk with the second method seems low if > only used with protected methods. I'd suggest that a lower layer failure indication be recommended if we go with #2. From jari.arkko@piuha.net Wed May 7 18:17:22 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 07 May 2003 20:17:22 +0300 Subject: [eap] Re: Issue 112: Rewrite of IANA Considerations In-Reply-To: References: Message-ID: <3EB93FA2.2080508@piuha.net> Bernard Aboba wrote: > To my mind I think that "enters the RFC Editor queue" is sufficient. We > could add this as an example. Ok. --Jari From jrv@umich.edu Thu May 8 00:55:33 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 07 May 2003 19:55:33 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A6122287@esebe023.ntc.nokia.com> <437189.1052303131@[10.0.1.2]> Message-ID: <1523397.1052337333@[10.0.1.2]> --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba wrote: > > If the authenticator can detect it I would think the peer could as > > well. Is this not the case? > > It depends on whether lower layer indications are sent. For example, in > PPP the peer may send an LCP-Terminate if it wants to disconnect, but in > my experience that doesn't always happen. Similarly in IEEE 802.11 the > peer can wander off without sending a Disassociate. In both cases the > authenticator will typically time out the authentication state. > > That just results in excess resource consumption but on the peer there may > be a human user who gets frustrated and makes support calls if she can't > authenticate. So the impact of an authenticator not sending a lower > layer indication is somewhat greater. > > > I agree it is a protocol not method issue. if the Success/Failure > > message was acknowledged would this solve the protocol problem? > > I don't think so, becaue if we're going to silently discard the > Success/Failure indication on the peer, then the authenticator will just > retransmit it until it times out. true - > > > I think Pasi's description is quite good. Seems to me the options > > actually open to us, without adding acknowledged ACK for > > success/Failure messages are > > > > 1. always accept success and failure messages and accept the > > consequences of possible DOS attacks using them > > 2. use method indication of where there is a confirmed success and not > > allow Failure. This leave the possiblity a Failure sent would be > > ignored and the peer would hang thinking it had succeeded. > > > > I think the second scenario allows the use of protected methods like > > PEAP and avoid DOS attacks. [ PEAP might want to define a protected > > Success/Failure that IS acknowledged within it self - might be worth > > looking at how to do that.] The risk with the second method seems low > > if only used with protected methods. > > I'd suggest that a lower layer failure indication be recommended if we go > with #2. I agree - sounds right to me. From alper@docomolabs-usa.com Thu May 8 02:06:21 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 07 May 2003 18:06:21 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <1523397.1052337333@[10.0.1.2]> Message-ID: How about relying on the EAP transport to signal the result of the "authorization" and EAP and EAP method signal the result of "authentication"? This way EAP result can always be same as the EAP method result because it does not have to convey a different value (auth vs. authz). What is the problem with this approach? Alper > > > --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba > wrote: > >>> If the authenticator can detect it I would think the peer could as >>> well. Is this not the case? >> >> It depends on whether lower layer indications are sent. For example, in >> PPP the peer may send an LCP-Terminate if it wants to disconnect, but in >> my experience that doesn't always happen. Similarly in IEEE 802.11 the >> peer can wander off without sending a Disassociate. In both cases the >> authenticator will typically time out the authentication state. >> >> That just results in excess resource consumption but on the peer there may >> be a human user who gets frustrated and makes support calls if she can't >> authenticate. So the impact of an authenticator not sending a lower >> layer indication is somewhat greater. >> >>> I agree it is a protocol not method issue. if the Success/Failure >>> message was acknowledged would this solve the protocol problem? >> >> I don't think so, becaue if we're going to silently discard the >> Success/Failure indication on the peer, then the authenticator will just >> retransmit it until it times out. > > true - >> >>> I think Pasi's description is quite good. Seems to me the options >>> actually open to us, without adding acknowledged ACK for >>> success/Failure messages are >>> >>> 1. always accept success and failure messages and accept the >>> consequences of possible DOS attacks using them >>> 2. use method indication of where there is a confirmed success and not >>> allow Failure. This leave the possiblity a Failure sent would be >>> ignored and the peer would hang thinking it had succeeded. >>> >>> I think the second scenario allows the use of protected methods like >>> PEAP and avoid DOS attacks. [ PEAP might want to define a protected >>> Success/Failure that IS acknowledged within it self - might be worth >>> looking at how to do that.] The risk with the second method seems low >>> if only used with protected methods. >> >> I'd suggest that a lower layer failure indication be recommended if we go >> with #2. > I agree - sounds right to me. > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Thu May 8 02:17:24 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 07 May 2003 21:17:24 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: <1760945.1052342244@[10.0.1.2]> --On Wednesday, May 7, 2003 6:06 PM -0700 Alper Yegin wrote: > > How about relying on the EAP transport to signal the result of the > "authorization" and EAP and EAP method signal the result of > "authentication"? This way EAP result can always be same as the EAP method > result because it does not have to convey a different value (auth vs. > authz). > > What is the problem with this approach? > > Alper > > I think this is what Bernard is suggesting. Am I missing something? -- John > > > > > > > > --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba > > wrote: > > > >>> If the authenticator can detect it I would think the peer could as > >>> well. Is this not the case? > >> > >> It depends on whether lower layer indications are sent. For example, in > >> PPP the peer may send an LCP-Terminate if it wants to disconnect, but > >> in my experience that doesn't always happen. Similarly in IEEE 802.11 > >> the peer can wander off without sending a Disassociate. In both cases > >> the authenticator will typically time out the authentication state. > >> > >> That just results in excess resource consumption but on the peer there > >> may be a human user who gets frustrated and makes support calls if she > >> can't authenticate. So the impact of an authenticator not sending a > >> lower layer indication is somewhat greater. > >> > >>> I agree it is a protocol not method issue. if the Success/Failure > >>> message was acknowledged would this solve the protocol problem? > >> > >> I don't think so, becaue if we're going to silently discard the > >> Success/Failure indication on the peer, then the authenticator will > >> just retransmit it until it times out. > > > > true - > >> > >>> I think Pasi's description is quite good. Seems to me the options > >>> actually open to us, without adding acknowledged ACK for > >>> success/Failure messages are > >>> > >>> 1. always accept success and failure messages and accept the > >>> consequences of possible DOS attacks using them > >>> 2. use method indication of where there is a confirmed success and > >>> not allow Failure. This leave the possiblity a Failure sent would be > >>> ignored and the peer would hang thinking it had succeeded. > >>> > >>> I think the second scenario allows the use of protected methods like > >>> PEAP and avoid DOS attacks. [ PEAP might want to define a protected > >>> Success/Failure that IS acknowledged within it self - might be worth > >>> looking at how to do that.] The risk with the second method seems low > >>> if only used with protected methods. > >> > >> I'd suggest that a lower layer failure indication be recommended if we > >> go with #2. > > I agree - sounds right to me. > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From yohba@tari.toshiba.com Thu May 8 03:35:19 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 7 May 2003 19:35:19 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <1760945.1052342244@[10.0.1.2]> References: <1760945.1052342244@[10.0.1.2]> Message-ID: <20030508023519.GB2388@steelhead> I think what the text suggested by Bernard means is: o EAP Success/Failre indicates an authorization result (i.e., access accepted or denied). o Similar indication can also be carried in an authentication method perhaps with acknowledged, but the indication must be consistent with the result indicated by EAP Success/Failure. This means that method indication actually indicates an authorization result, too. (For example, in PEAP, EAP-TLS, EAP-TTLS, it is possible to use TLS's error alert "access_denied" to indicate a failure of authorization even when authentication succeeds. Or in PEAP, it is also possible to use Success/Failure EAP-TLV inside the PEAP method to indicate an authorization result. In PEAP, it might be also possible to return a Success/Failre EAP-TLV and return a EAP-Success outside PEAP, even when PEAP "authentication" fails, to be able to provide restricted access for unauthenticated clients.) o There is another indication, which is from link-layer. When the link-layer indication is used, it is assumed to be consistent with the other indications. This means that link-layer indication is an authorization result, too. Link-layer indication is not secure in 802.11, on the other hand, if link-layer indication is not used there is some delay that might frustrate users. (So there is a pros-and-cons on using link-layer indications over 802.11.) Yoshihiro Ohba On Wed, May 07, 2003 at 09:17:24PM -0400, John Vollbrecht wrote: > > > --On Wednesday, May 7, 2003 6:06 PM -0700 Alper Yegin > wrote: > > > > >How about relying on the EAP transport to signal the result of the > >"authorization" and EAP and EAP method signal the result of > >"authentication"? This way EAP result can always be same as the EAP method > >result because it does not have to convey a different value (auth vs. > >authz). > > > >What is the problem with this approach? > > > >Alper > > > > > I think this is what Bernard is suggesting. Am I missing something? > -- John > > > > > > >> > >> > >> --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba > >> wrote: > >> > >>>> If the authenticator can detect it I would think the peer could as > >>>> well. Is this not the case? > >>> > >>> It depends on whether lower layer indications are sent. For example, in > >>> PPP the peer may send an LCP-Terminate if it wants to disconnect, but > >>> in my experience that doesn't always happen. Similarly in IEEE 802.11 > >>> the peer can wander off without sending a Disassociate. In both cases > >>> the authenticator will typically time out the authentication state. > >>> > >>> That just results in excess resource consumption but on the peer there > >>> may be a human user who gets frustrated and makes support calls if she > >>> can't authenticate. So the impact of an authenticator not sending a > >>> lower layer indication is somewhat greater. > >>> > >>>> I agree it is a protocol not method issue. if the Success/Failure > >>>> message was acknowledged would this solve the protocol problem? > >>> > >>> I don't think so, becaue if we're going to silently discard the > >>> Success/Failure indication on the peer, then the authenticator will > >>> just retransmit it until it times out. > >> > >> true - > >>> > >>>> I think Pasi's description is quite good. Seems to me the options > >>>> actually open to us, without adding acknowledged ACK for > >>>> success/Failure messages are > >>>> > >>>> 1. always accept success and failure messages and accept the > >>>> consequences of possible DOS attacks using them > >>>> 2. use method indication of where there is a confirmed success and > >>>> not allow Failure. This leave the possiblity a Failure sent would be > >>>> ignored and the peer would hang thinking it had succeeded. > >>>> > >>>> I think the second scenario allows the use of protected methods like > >>>> PEAP and avoid DOS attacks. [ PEAP might want to define a protected > >>>> Success/Failure that IS acknowledged within it self - might be worth > >>>> looking at how to do that.] The risk with the second method seems low > >>>> if only used with protected methods. > >>> > >>> I'd suggest that a lower layer failure indication be recommended if we > >>> go with #2. > >> I agree - sounds right to me. > >> > >> > >> > >> _______________________________________________ > >> 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 May 8 04:47:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 7 May 2003 20:47:35 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > What is the problem with this approach? The problem is that it creates numerous corner conditions. We have already encountered this in AAA where if the AAA indication (Access/Reject) is not consistent with the encapsulated EAP packet (Success/Failure) we can get extended timeouts. We have addressed this in RFC 2869bis by strongly discouraging contradictory indications. We are encountering it again with the distinction between method result indications and EAP Failure/Success. And here again the solution appears to be restricting (or prohibiting) contradictory indications. That's also why Section 3 of RFC 2284bis restricts the use of lower layer indications substantially -- basically these can only be used to deny access (e.g. PPP LCP-Terminate, 802.11 Disassociate/Deauthenticate), not as success indications. From Pasi.Eronen@nokia.com Thu May 8 09:59:21 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 8 May 2003 11:59:21 +0300 Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BAE8@esebe023.ntc.nokia.com> Bernard Aboba wrote: > Since only a single EAP authentication method is allowed within > an EAP conversation, a peer that successfully authenticates the > authenticator MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost and > enable the link. Failure packets MUST be silently discarded by > the peer. I think it would be clearer to document that EAP methods on the peer can actually have three different end results, not just two (success and failure). This would also explain why in some=20 circumstances the peer should discard Success or Failure packets,=20 or enable the link in case of timeout or link-layer indication. How about this? "Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. On the peer, an EAP method can conclude with three different end results. [1] Failure: Either the authenticator has indicated that it will not allow access to the peer, or the peer does not wish to use this access (for instance, the peer has not successfully verified the server's identity, but its security policy requires this). In this case, the EAP conversation is terminated, and the link is disabled. As a result, loss of a Failure packet need not result in a timeout, and a Success packet MUST be silently discarded by the peer. [2] Unconditional success: The authenticator has indicated that it will allow access to the peer, and the peer wishes to use this access. The peer SHOULD, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. Failure packets MUST be silently discarded by the peer. [3] Conditional success: The peer wishes to use the access, but it does not know if the authenticator will allow access=20 or not. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. Failure packets MAY be silently discarded, but this can result in lengthy timeouts unless a lower layer failure indication is provided." Best regards, Pasi From aboba@internaut.com Thu May 8 13:19:37 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 05:19:37 -0700 (PDT) Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BAE8@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BAE8@esebe023.ntc.nokia.com> Message-ID: > [2] Unconditional success: The authenticator has indicated that > it will allow access to the peer, and the peer wishes > to use this access. > > The peer SHOULD, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost > and enable the link. Failure packets MUST be silently > discarded by the peer. > > [3] Conditional success: The peer wishes to use the access, > but it does not know if the authenticator will allow access > or not. > > The peer MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost > and enable the link. Failure packets MAY be silently > discarded, but this can result in lengthy timeouts unless > a lower layer failure indication is provided." In the event that an EAP Success is not received, what is the difference between 2 and 3? Doesn't the peer *always* enable its link based on whether it authenticated the authenticator within the method? If so, then it would seem like the last sentence would apply to #2 as well, no? From jrv@umich.edu Thu May 8 18:03:48 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 08 May 2003 13:03:48 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: <507223.1052399028@[10.0.1.2]> --On Wednesday, May 7, 2003 6:06 PM -0700 Alper Yegin wrote: > > How about relying on the EAP transport to signal the result of the > "authorization" and EAP and EAP method signal the result of > "authentication"? This way EAP result can always be same as the EAP method > result because it does not have to convey a different value (auth vs. > authz). > > What is the problem with this approach? > > Alper > > I think I may have misinterpreted your suggestion on first reading. I think I may understand what you are suggesting better now. to check if I do understand what you are suggesting, here is what I think you are saying, a bit expanded - - have two results 1. [auth] authentication done by EAP methods 2. [authz] done by EAP policy 1. would be signalled from the EAP method to the EAP mux and presumably signalled from authenticator to peer by the EAP Success/Failure message 2. would be determined by EAP policy and signalled to the supplicant with a level 2 signal. ---- If this is what you are saying, I think it is a very interesting idea, and one to talk about for futures. It doesn't work for current version because a) There is no positive way to signal an [auth] with EAP Success/Failure because they aren't ack'd b) The intent of EAP as described now is to have the EAP dialog result be both authentication and authorization [separating them is the interesting idea] c) There are positive ways to in existing lower layers to indicate failure, but not success. That is one can do and 802.11 disassociate or EAPoL logoff to drop a link, but there is no indicator outside EAP to indicate success. > > > > > > > > --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba > > wrote: > > > >>> If the authenticator can detect it I would think the peer could as > >>> well. Is this not the case? > >> > >> It depends on whether lower layer indications are sent. For example, in > >> PPP the peer may send an LCP-Terminate if it wants to disconnect, but > >> in my experience that doesn't always happen. Similarly in IEEE 802.11 > >> the peer can wander off without sending a Disassociate. In both cases > >> the authenticator will typically time out the authentication state. > >> > >> That just results in excess resource consumption but on the peer there > >> may be a human user who gets frustrated and makes support calls if she > >> can't authenticate. So the impact of an authenticator not sending a > >> lower layer indication is somewhat greater. > >> > >>> I agree it is a protocol not method issue. if the Success/Failure > >>> message was acknowledged would this solve the protocol problem? > >> > >> I don't think so, becaue if we're going to silently discard the > >> Success/Failure indication on the peer, then the authenticator will > >> just retransmit it until it times out. > > > > true - > >> > >>> I think Pasi's description is quite good. Seems to me the options > >>> actually open to us, without adding acknowledged ACK for > >>> success/Failure messages are > >>> > >>> 1. always accept success and failure messages and accept the > >>> consequences of possible DOS attacks using them > >>> 2. use method indication of where there is a confirmed success and > >>> not allow Failure. This leave the possiblity a Failure sent would be > >>> ignored and the peer would hang thinking it had succeeded. > >>> > >>> I think the second scenario allows the use of protected methods like > >>> PEAP and avoid DOS attacks. [ PEAP might want to define a protected > >>> Success/Failure that IS acknowledged within it self - might be worth > >>> looking at how to do that.] The risk with the second method seems low > >>> if only used with protected methods. > >> > >> I'd suggest that a lower layer failure indication be recommended if we > >> go with #2. > > I agree - sounds right to me. > > > > > > > > _______________________________________________ > > 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 alper@docomolabs-usa.com Thu May 8 21:53:22 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 08 May 2003 13:53:22 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <507223.1052399028@[10.0.1.2]> Message-ID: >> How about relying on the EAP transport to signal the result of the >> "authorization" and EAP and EAP method signal the result of >> "authentication"? This way EAP result can always be same as the EAP method >> result because it does not have to convey a different value (auth vs. >> authz). >> >> What is the problem with this approach? >> >> Alper >> >> > I think I may have misinterpreted your suggestion on first reading. I > think I may understand what you are suggesting better now. > > to check if I do understand what you are suggesting, here is what I think > you are saying, a bit expanded - > > - have two results 1. [auth] authentication done by EAP methods > 2. [authz] done by EAP policy > > 1. would be signalled from the EAP method to the EAP mux and presumably > signalled from authenticator to peer by the EAP Success/Failure message Yes. So that EAP method result and EAP result are the same. And they only mean authentication. > > 2. would be determined by EAP policy and signalled to the supplicant with a > level 2 signal. Not necessarily "level 2 signal" if you mean "link-layer" here. Between the authenticator and the authentication server, if you are running Radius, access accept/reject can indicate the result of authorization. On the last hop, this value is translated to, for example, PANA success/failure. That way, authentication and authorization results can be kept separate all the way to the peer. > > ---- > If this is what you are saying, I think it is a very interesting idea, and > one to talk about for futures. It doesn't work for current version because > > a) There is no positive way to signal an [auth] with EAP Success/Failure > because they aren't ack'd Sorry, I'm missing why this matters here...If we had EAP results ack'ed, would we not have the problems we are facing when we want to separate auth from authz? > b) The intent of EAP as described now is to have the EAP dialog result be > both authentication and authorization [separating them is the interesting > idea] I thought the starting point of this thread was that people want to separate and differentiate between two results. If they are always the same, how does the peer know when it fails if it is due to authentication or authorization? The result should not tell me I am not Alper@docomo just because I tried to access a service before 5pm (too early). > c) There are positive ways to in existing lower layers to indicate failure, > but not success. That is one can do and 802.11 disassociate or EAPoL > logoff to drop a link, but there is no indicator outside EAP to indicate > success. I guess this is a EAP lower layer problem, or limitation of existing ones. If you look at PANA, we have both success and failure. Alper > >> >> >>> >>> >>> --On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba >>> wrote: >>> >>>>> If the authenticator can detect it I would think the peer could as >>>>> well. Is this not the case? >>>> >>>> It depends on whether lower layer indications are sent. For example, in >>>> PPP the peer may send an LCP-Terminate if it wants to disconnect, but >>>> in my experience that doesn't always happen. Similarly in IEEE 802.11 >>>> the peer can wander off without sending a Disassociate. In both cases >>>> the authenticator will typically time out the authentication state. >>>> >>>> That just results in excess resource consumption but on the peer there >>>> may be a human user who gets frustrated and makes support calls if she >>>> can't authenticate. So the impact of an authenticator not sending a >>>> lower layer indication is somewhat greater. >>>> >>>>> I agree it is a protocol not method issue. if the Success/Failure >>>>> message was acknowledged would this solve the protocol problem? >>>> >>>> I don't think so, becaue if we're going to silently discard the >>>> Success/Failure indication on the peer, then the authenticator will >>>> just retransmit it until it times out. >>> >>> true - >>>> >>>>> I think Pasi's description is quite good. Seems to me the options >>>>> actually open to us, without adding acknowledged ACK for >>>>> success/Failure messages are >>>>> >>>>> 1. always accept success and failure messages and accept the >>>>> consequences of possible DOS attacks using them >>>>> 2. use method indication of where there is a confirmed success and >>>>> not allow Failure. This leave the possiblity a Failure sent would be >>>>> ignored and the peer would hang thinking it had succeeded. >>>>> >>>>> I think the second scenario allows the use of protected methods like >>>>> PEAP and avoid DOS attacks. [ PEAP might want to define a protected >>>>> Success/Failure that IS acknowledged within it self - might be worth >>>>> looking at how to do that.] The risk with the second method seems low >>>>> if only used with protected methods. >>>> >>>> I'd suggest that a lower layer failure indication be recommended if we >>>> go with #2. >>> I agree - sounds right to me. >>> >>> >>> >>> _______________________________________________ >>> 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 alper@docomolabs-usa.com Thu May 8 22:26:09 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 08 May 2003 14:26:09 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: Message-ID: >> What is the problem with this approach? > > The problem is that it creates numerous corner conditions. We have already > encountered this in AAA where if the AAA indication (Access/Reject) is not > consistent with the encapsulated EAP packet (Success/Failure) we can get > extended timeouts. We have addressed this in RFC 2869bis by strongly > discouraging contradictory indications. I think the problem is not with EAP, or AAA. The problem is with the EAP lower layers, such as PPP and 802.1X. If they had a way to carry authorization results, this problem wouldn't exist. In PANA, we carry PANA result so this wouldn't be a problem. > > We are encountering it again with the distinction between method result > indications and EAP Failure/Success. And here again the solution appears > to be restricting (or prohibiting) contradictory indications. > Does this work? There are three pieces here: 1- (potentially) EAP authentication method result 2- EAP result 3- Radius result I see rfc2869bis says (2) and (3) must agree. On the other hand, now we are discovering that (1) and (2) must agree too. So, when an authentication method succeeds, but authorization fails, should the authenticatin server go back and flip the authentication method to "failed" so that the results are all aligned? We could make (1) and (2) the same, and keep (3) independent. But the problem is there is no equivalent of (3) for the last hop when PPP or 802.1X is used. > That's also why Section 3 of RFC 2284bis restricts the use of lower layer > indications substantially -- basically these can only be used to deny > access (e.g. PPP LCP-Terminate, 802.11 Disassociate/Deauthenticate), not > as success indications. > Alper From aboba@internaut.com Thu May 8 22:22:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 14:22:14 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > Between the authenticator and the authentication server, if you are running > Radius, access accept/reject can indicate the result of authorization. On > the last hop, this value is translated to, for example, PANA > success/failure. That way, authentication and authorization results can be > kept separate all the way to the peer. If the AAA Access/Reject agrees with the EAP Success/Failure as recommended in RFC 2869bis, what is the value of a PANA Success/Failure? Seems like this means that PANA is much more than an EAP transport -- it actually changes the EAP state machine, which is problematic. From aboba@internaut.com Thu May 8 22:29:01 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 14:29:01 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > I think the problem is not with EAP, or AAA. The problem is with the EAP > lower layers, such as PPP and 802.1X. If they had a way to carry > authorization results, this problem wouldn't exist. In PANA, we carry PANA > result so this wouldn't be a problem. 802.1X considered, and rejected the carriage of authorization results. It was simpler to just recommend that the AAA result and EAP results agree. > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we are > discovering that (1) and (2) must agree too. This is not a "discovery" -- it is an implication of the proposed state machine. > So, when an authentication > method succeeds, but authorization fails, should the authenticatin server go > back and flip the authentication method to "failed" so that the results are > all aligned? If the authentication method supports an authorization failure error message, it can send that and there is no problem. Alternatively, the AAA server can send a Reject/EAP Failure. If this does not agree with the EAP method, which completed successfully, then the peer may silently discard the EAP Failure. Again there is no issue, as long as the NAS sends a lower layer failure indication such as an LCP-Terminate or 802.11 Deauthenticate/Disassociate. Why doesn't this address the problem? > We could make (1) and (2) the same, and keep (3) independent. But the > problem is there is no equivalent of (3) for the last hop when PPP or 802.1X > is used. That seems needlessly complex -- given that our goal is to improve interoperability. From alper@docomolabs-usa.com Fri May 9 00:50:43 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 08 May 2003 16:50:43 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: Message-ID: >> Between the authenticator and the authentication server, if you are running >> Radius, access accept/reject can indicate the result of authorization. On >> the last hop, this value is translated to, for example, PANA >> success/failure. That way, authentication and authorization results can be >> kept separate all the way to the peer. > > If the AAA Access/Reject agrees with the EAP Success/Failure as > recommended in RFC 2869bis, what is the value of a PANA Success/Failure? If the decision is to align the result codes across Radius, EAP and EAP method, then you are right, PANA result code does not add much value when the backend is Radius. I have some questions regarding the aforementined condition (I'll respond to your other message), and Radius is not the only backend for PANA. People can use any proprietary solution, there is no reason to take away this flexibility because Radius does it one way, imo. > Seems like this means that PANA is much more than an EAP transport -- it > actually changes the EAP state machine, which is problematic. Could you please elaborate how does this change the EAP state machine? PANA does not touch EAP session, and EAP is only for authentication. PANA result can change based on the EAP result, but not vice versa. Alper From aboba@internaut.com Fri May 9 00:50:31 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 16:50:31 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > I have some questions regarding the aforementined condition (I'll respond to > your other message), and Radius is not the only backend for PANA. People can > use any proprietary solution, there is no reason to take away this > flexibility because Radius does it one way, imo. This isn't a RADIUS issue -- the problem can also occur in any AAA protocol, including Diameter. Typically the problem occurs because the implementation applies policy after the authentication/authorization decision is made, and therefore the result of the EAP method/EAP Success or Failure message/AAA result may not agree. The question is whether this is just an implementation issue -- and therefore whether the implementations should be fixed so that it doesn't occur. That was the judgement of IEEE 802.1aa, and that is what is reflected in RFC 2869bis. Basically, this is a case of "Doctor, it hurts when I do this!" Since the protocol messages in question don't appear to add much in the way of new capabilities, the resolution was "don't do that!" > Could you please elaborate how does this change the EAP state machine? > PANA does not touch EAP session, and EAP is only for authentication. PANA > result can change based on the EAP result, but not vice versa. The problem is that the EAP result *isn't* just about authentication -- it's about whether the peer and authenticator enable their side of the link. As noted earlier, if the authenticator fails to authenticate to the peer, then the peer MUST NOT enable the link -- no matter what the lower layer indications say. As a result, the lower layer can only offer failure indications so as to indicate that the link is disabled. It can't authorize access in situations when EAP authentication has failed. From alper@docomolabs-usa.com Fri May 9 01:43:05 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 08 May 2003 17:43:05 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: Message-ID: >> I have some questions regarding the aforementined condition (I'll respond to >> your other message), and Radius is not the only backend for PANA. People can >> use any proprietary solution, there is no reason to take away this >> flexibility because Radius does it one way, imo. > > This isn't a RADIUS issue -- the problem can also occur in any AAA > protocol, including Diameter. > > Typically the problem occurs because the implementation applies policy > after the authentication/authorization decision is made, and therefore the > result of the EAP method/EAP Success or Failure message/AAA result may not > agree. > > The question is whether this is just an implementation issue -- and > therefore whether the implementations should be fixed so that it doesn't > occur. That was the judgement of IEEE 802.1aa, and that is what is > reflected in RFC 2869bis. > > Basically, this is a case of "Doctor, it hurts when I do this!" Since the > protocol messages in question don't appear to add much in the way of > new capabilities, the resolution was "don't do that!" > >> Could you please elaborate how does this change the EAP state machine? >> PANA does not touch EAP session, and EAP is only for authentication. PANA >> result can change based on the EAP result, but not vice versa. > > The problem is that the EAP result *isn't* just about authentication -- > it's about whether the peer and authenticator enable their side of the > link. As noted earlier, if the authenticator fails to authenticate to > the peer, then the peer MUST NOT enable the link -- no matter what the > lower layer indications say. > > As a result, the lower layer can only offer failure indications so as to > indicate that the link is disabled. It can't authorize access in > situations when EAP authentication has failed. This sounds more like you are talking about a specific usage of EAP, such as EAP over PPP or EAP over IEEE 802. rfc2284bis talks all about authentication but not authorization, and what you imply above is authorization. Does the spec say access service cannot be granted if EAP fails? I hope it does not. For example, even if a visitor fails to authenticate himself, I might choose to provide limited access service to him just because he is in the shopping mall. > Alper From alper@docomolabs-usa.com Fri May 9 01:45:22 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 08 May 2003 17:45:22 -0700 Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: Message-ID: >> I think the problem is not with EAP, or AAA. The problem is with the EAP >> lower layers, such as PPP and 802.1X. If they had a way to carry >> authorization results, this problem wouldn't exist. In PANA, we carry PANA >> result so this wouldn't be a problem. > > 802.1X considered, and rejected the carriage of authorization results. It > was simpler to just recommend that the AAA result and EAP results agree. But is this a better approach? Now, since AAA rules, if AAA disagrees with EAP and the authentication method, the authentication server has to forcefully change the EAP and authentication methods results. They were meant to be for "authentication", but now they are overwritten by "authorization" results. Is this allowed from EAP perspective, and practical? > >> I see rfc2869bis says (2) and (3) must agree. On the other hand, now we are >> discovering that (1) and (2) must agree too. > > This is not a "discovery" -- it is an implication of the proposed state > machine. > >> So, when an authentication >> method succeeds, but authorization fails, should the authenticatin server go >> back and flip the authentication method to "failed" so that the results are >> all aligned? > > If the authentication method supports an authorization failure error > message, it can send that and there is no problem. If the authentication method has its own result, wouldn't that be "authentication failure/success"? I'd say it should not be "authorization f/s". > Alternatively, the AAA > server can send a Reject/EAP Failure. If this does not agree with the EAP > method, which completed successfully, then the peer may silently discard > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > layer failure indication such as an LCP-Terminate or 802.11 > Deauthenticate/Disassociate. > > Why doesn't this address the problem? This is meant to be an alternative to aligning all results same as AAA result, right? - this delivers authorization result in EAP result which is meant to be authentication result. - does this not open up a DoS attack? Those link-layer failures are not protected. [you were asking what is the use of PANA results. Here it can replace the lower-layer hints.. it can even be protected if method are available] - How about the opposite case: method fails but the peer is authorized to have limited access to the network. > >> We could make (1) and (2) the same, and keep (3) independent. But the >> problem is there is no equivalent of (3) for the last hop when PPP or 802.1X >> is used. > > That seems needlessly complex -- given that our goal is to improve > interoperability. If you are referring to the required change on PPP and 802.1X, yes, this is hard. Alper From aboba@internaut.com Fri May 9 03:13:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 19:13:18 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > Does the spec say access service cannot be granted if EAP fails? I hope it > does not. For example, even if a visitor fails to authenticate himself, I > might choose to provide limited access service to him just because he is in > the shopping mall. Access can't be granted if an EAP Failure is sent. This is more than an EAP issue -- RADIUS [RFC2865] says that an Access Reject means to deny access. Since the EAP result and AAA result need to be aligned, that means you shouldn't send an EAP Success inside a RADIUS Access Accept or an EAP Failure inside a RADIUS Access Reject. These cases are a SHOULD NOT within RFC 2869bis. Now that we only have a single EAP authentication mechanism, the current discussion is over whether the EAP method result and EAP result have to be the same. The big advantage to aligning them is that spoofing of EAP Success and Failure is made much more difficult. If AAA authorization for access is only provided when an EAP Success is sent, and if an EAP Success is only sent after EAP authentication succeeds, then access service can't be granted if EAP fails. From aboba@internaut.com Fri May 9 03:16:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 19:16:51 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: Oops. I meant an EAP Failure shouldn't be sent inside an Access Accept or an EAP Success inside an Access Reject. On Thu, 8 May 2003, Bernard Aboba wrote: > > Does the spec say access service cannot be granted if EAP fails? I hope it > > does not. For example, even if a visitor fails to authenticate himself, I > > might choose to provide limited access service to him just because he is in > > the shopping mall. > > Access can't be granted if an EAP Failure is sent. This is more than an > EAP issue -- RADIUS [RFC2865] says that an Access Reject means to deny access. > Since the EAP result and AAA result need to be aligned, that means you shouldn't > send an EAP Success inside a RADIUS Access Accept or an EAP Failure inside > a RADIUS Access Reject. These cases are a SHOULD NOT within RFC > 2869bis. > > Now that we only have a single EAP authentication mechanism, the current > discussion is over whether the EAP method result and EAP result have to be > the same. The big advantage to aligning them is that spoofing of EAP > Success and Failure is made much more difficult. > > If AAA authorization for access is only provided when an EAP Success is > sent, and if an EAP Success is only sent after EAP authentication > succeeds, then access service can't be granted if EAP fails. > From aboba@internaut.com Fri May 9 03:28:17 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 8 May 2003 19:28:17 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: References: Message-ID: > But is this a better approach? > Now, since AAA rules, if AAA disagrees with EAP and the authentication > method, the authentication server has to forcefully change the EAP and > authentication methods results. They were meant to be for "authentication", > but now they are overwritten by "authorization" results. Is this allowed > from EAP perspective, and practical? I think this is an implementation issue. Typically, EAP methods provide an indication of success or failure on completion, and so the EAP Failure or Success packet can be generated by the AAA server, which can make sure that it is aligned with the AAA indication. So overall, alignment of the AAA indication and EAP Success/Failure is not much of an issue in practice. That's why RFC 2869bis is recommending consistency. Consistency between the EAP method and the Success/Failure indication is a bit trickier. If the method provides its own result indications, then the AAA server will only learn of the EAP method result *after* those indications are sent. At that point, it may be too late to change the result indication if policy indicates that another result should occur. The solution to this is for the policy to be checked earlier on, so that a method-specific authorization error message can be sent. As has been noted, such messages exist within EAP methods such as EAP-TLS [RFC2716]. If this is done then the EAP method result can be made consistent with the Success/Failure indication and the AAA result. The other way to do this is to use a method that doesn't do mutual authentication. On the peer, such "one way" methods always conclude successfully from the peer's perspective. Since the peer doesn't authenticate the authenticator it is always ready to enable the link, no matter what happens. Or at least, this is what I gather from the state machine discussions. > > > > >> I see rfc2869bis says (2) and (3) must agree. On the other hand, now we are > >> discovering that (1) and (2) must agree too. > > > > This is not a "discovery" -- it is an implication of the proposed state > > machine. > > > >> So, when an authentication > >> method succeeds, but authorization fails, should the authenticatin server go > >> back and flip the authentication method to "failed" so that the results are > >> all aligned? > > > > If the authentication method supports an authorization failure error > > message, it can send that and there is no problem. > > If the authentication method has its own result, wouldn't that be > "authentication failure/success"? I'd say it should not be "authorization > f/s". > > > Alternatively, the AAA > > server can send a Reject/EAP Failure. If this does not agree with the EAP > > method, which completed successfully, then the peer may silently discard > > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > > layer failure indication such as an LCP-Terminate or 802.11 > > Deauthenticate/Disassociate. > > > > Why doesn't this address the problem? > > This is meant to be an alternative to aligning all results same as AAA > result, right? > > - this delivers authorization result in EAP result which is meant to be > authentication result. > - does this not open up a DoS attack? Those link-layer failures are not > protected. [you were asking what is the use of PANA results. Here it can > replace the lower-layer hints.. it can even be protected if method are > available] > - How about the opposite case: method fails but the peer is authorized to > have limited access to the network. > > > > > >> We could make (1) and (2) the same, and keep (3) independent. But the > >> problem is there is no equivalent of (3) for the last hop when PPP or 802.1X > >> is used. > > > > That seems needlessly complex -- given that our goal is to improve > > interoperability. > > If you are referring to the required change on PPP and 802.1X, yes, this is > hard. > > Alper > From Pasi.Eronen@nokia.com Fri May 9 09:31:56 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 9 May 2003 11:31:56 +0300 Subject: [eap] Re: Issue 121: Document meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BAE9@esebe023.ntc.nokia.com> Bernard Aboba wrote: > This isn't a RADIUS issue -- the problem can also occur in any AAA > protocol, including Diameter. >=20 > Typically the problem occurs because the implementation applies policy > after the authentication/authorization decision is made, and=20 > therefore the result of the EAP method/EAP Success or Failure=20 > message/AAA result may not agree. >=20 > The question is whether this is just an implementation issue --=20 > and therefore whether the implementations should be fixed so that=20 > it doesn't occur. That was the judgement of IEEE 802.1aa, and=20 > that is what is reflected in RFC 2869bis. I very much agree with you on this. Making the authorization=20 decision *is* IMHO same as applying policy, and an=20 implementation should behave consistently in this. If=20 the implementation signals (using some EAP method internal=20 mechanism) that "yes, I give you access", then it must not change that decision later and send an EAP Failure. (From implementation point of view, if the policy is stored in some "RADIUS server or EAP mux module", then the "EAP method=20 module" has to communicate with this module. But this is purely=20 an implementation issue; the behavior observable to outside has to be consistent). However, this should not be confused with the peer knowing that "yes, the authenticator has verified who I am" message. In this case, either authorization decision is consistent behavior for the server, and I think that it is reasonable=20 to make the authorization decision (apply the policy)=20 after verifying who the peer is (which may be before an EAP method has concluded, or after!). It seems that EAP methods that can signal the authorization=20 decision have one "extra round" in them: before sending the last Request, the server has already made its decision whether to allow access or not. In many methods, the server won't make the final decision until it has received the last Response from the peer; and in those methods, the only way to signal the authorizion decision is an EAP Success/Failure message (and thus the server can freely choose either of them). Best regards, Pasi From Pasi.Eronen@nokia.com Fri May 9 09:39:53 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 9 May 2003 11:39:53 +0300 Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612228A@esebe023.ntc.nokia.com> Bernard Aboba wrote: > > [2] Unconditional success: The authenticator has indicated that > > it will allow access to the peer, and the peer wishes > > to use this access. > > > > The peer SHOULD, in the event that an EAP Success is not > > received, conclude that the EAP Success packet was lost > > and enable the link. Failure packets MUST be silently > > discarded by the peer. > > > > [3] Conditional success: The peer wishes to use the access, > > but it does not know if the authenticator will allow access > > or not. > > > > The peer MAY, in the event that an EAP Success is not > > received, conclude that the EAP Success packet was lost > > and enable the link. Failure packets MAY be silently > > discarded, but this can result in lengthy timeouts unless > > a lower layer failure indication is provided." >=20 > In the event that an EAP Success is not received, what is the=20 > difference between 2 and 3? Doesn't the peer *always* enable=20 > its link based on whether it authenticated the authenticator=20 > within the method? If so, then it would seem like the last=20 > sentence would apply to #2 as well, no? In case of timeout or Success packet, there's no difference=20 between 2 and 3 (the peer should enable the link).=20 The difference is that in 2, the server won't ever send a=20 Failure packet, and thus if we receive one, it was sent by=20 someone else (and can be discarded).=20 In case 3, the peer can make a trade-off if it receives a Failure: either it can process it (disable the link and=20 end the conversation immediately), or silently discard it=20 (in which case it will have to wait for a timeout, then enable the link, and timeout again to find out that the link doesn't work). The latter approach could offer some protection against an attacker who spoofs=20 a Failure message. Do you mean that the peer should always enable the link=20 when it is authenticated the authenticator, even when=20 the authenticator signals it won't give access? Best regards, Pasi From aboba@internaut.com Fri May 9 13:39:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 9 May 2003 05:39:43 -0700 (PDT) Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612228A@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612228A@esebe023.ntc.nokia.com> Message-ID: > Do you mean that the peer should always enable the link > when it is authenticated the authenticator, even when > the authenticator signals it won't give access? I'm asking what the state machine does in this circumstance. From the point of view of the peer, it is satisfied in a mutually authenticating method where it successfully authenticates the authenticator. It is also satisfied in a one-way method, since in that case the authenticator is only authenticating the peer; the peer assumes that the authenticator is authentic. I had thought that the state machine model was that each side makes its own decision. Of course where the peer is satisfied, but the authenticator is not, there are drawbacks to having the peer enable the link. The peer will attempt DHCP, and if the authenticator has disabled its side of the link, no response will be received and the peer will then assign a linklocal address instead, and might not check again for 5 minutes. So I'm asking what happens in each case, and what the decision is based on: a. One-way method. Peer fails to authenticate to the authenticator and the authenticator sends an EAP failure. Does the Peer process the EAP Failure and disable its side of the link? Why or why not? b. Mutually authenticating method. Peer successfully authenticates the authenticator. Does the peer accept a subsequent EAP Failure? Why or why not? c. Mutually authenticating method. Peer unsuccessfully authenticates the authenticator. Does it accept a subsequent EAP Success? Why or why not? From aboba@internaut.com Fri May 9 14:03:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 9 May 2003 06:03:43 -0700 (PDT) Subject: [eap] Re: Issue 121: Document meaning of successful authentication In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BAE9@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BAE9@esebe023.ntc.nokia.com> Message-ID: > It seems that EAP methods that can signal the authorization > decision have one "extra round" in them: before sending > the last Request, the server has already made its decision > whether to allow access or not. In a mutually authenticating method, the peer authenticates the authenticator. In addition, the authenticator may indicate to the peer whether the peer has successfully authenticated to it, and the peer may provide a similar indication to the authenticator of whether the authenticator has successfully authenticated to it. The question is when the peer enables its side of the link. Is this purely based on whether it authenticates the authenticator? Or in a method that provides for protected result indications, does this occur only when it authenticates the authenticator *and* the authenticator provides a positive result indication? If there is no explicit positive result from the authenticator, only say, the absence of an error message or alert, is this sufficient for the peer to enable its side of the link? Once the peer enables its side of the link, is an EAP Failure accepted? And once the link is enabled, does the peer wait for an EAP Success or can it conclude that the Success has been lost if it is not received? In a one-way method, the authenticator authenticates the peer, but the peer doesn't authenticate the authenticator, and there is no method-specific result indication in either direction. Here, does the peer always enable its side of the link? Or does this occur only when it receives an EAP Success from the authenticator? If the latter, then it would seem that a timeout will occur if an EAP Success is not received. > In many methods, the server won't make the final decision until > it has received the last Response from the peer; and in those > methods, the only way to signal the authorizion decision > is an EAP Success/Failure message (and thus the server > can freely choose either of them). The question is whether the peer will accept either one of these messages in the case where it has authenticated the peer. Do you agree that if the peer cannot successfully authenticate the peer, then it should disable the link so the Success/Failure message is irrelevant to it and it need not wait to receive it? From Pasi.Eronen@nokia.com Fri May 9 15:54:59 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 9 May 2003 17:54:59 +0300 Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612228B@esebe023.ntc.nokia.com> Hi, The current thinking in state machine is that=20 - The peer never sends any EAP Responses after "enabling" the link (or equivalently, the peer "enables" the link only after=20 the state machine has ended). - If the authenticator times out (after retransmissions),=20 it does not allow access (even when it in principle would be satisfied with the peer).=20 These two limit the choices an EAP method on the peer has (especially the latter). Thus, when an EAP method has concluded: - If the peer doesn't want to talk to this authenticator, it disables the link and ends the conversation. It doesn't matter what the authenticator's decision is. (The current state machine (-02) does wait for success, failure, or timeout to occur, but at the end, the link is always disabled. I guess this should be changed to just disable the link immediately.) - If the peer would be willing to talk to this authenticator, but the authenticator has signalled that it won't allow access (using some method-specific message), the peer disables the link and ends the conversation (it doesn't wait for EAP Failure packet or anything). =20 - If the peer is willing to talk to this authenticator, and the authenticator has signalled it will allow access (using some method-specific message), the peer doesn't enable the link immediately. =20 This is because it might have to retransmit the last response message. Instead, it waits until it receives a Success packet, timeout, or "lower-layer success indication", and then enables the link. (If it gets a Failure, it is silently discarded and the peer continues waiting.) - If the peer is willing to talk to this authenticator, but is unsure about if the authenticator will allow access (note: "allow access", not "has authenticated the peer"), it doesn't enable the link but waits. (Again, this is necessary for retransmissions.) If it receives a Success packet, timeout, or "lower-layer success indication", it enables the link. If it gets a Failure, it disables the link. Thus, answering your questions (combined from both recently sent messages): > Do you agree that if the peer cannot successfully authenticate > the peer, then it should disable the link so the > Success/Failure message is irrelevant to it and it need=20 > not wait to receive it? I assume that "cannot successfully authenticate" means "I don't want to talk to the authenticator, even though I might, or might not, have verified who it is"). Yes, I agree; in this case, the authenticator's decision does not matter, and the peer can disable the link immediately.=20 > So I'm asking what happens in each case, and what the decision is > based on: > > a. One-way method. Peer fails to authenticate to the > authenticator and the authenticator sends an EAP failure. Does > the Peer process the EAP Failure and disable its side of the > link? Why or why not? Yes, the peer disables the link and ends the EAP conversation. The assumption is that when EAP is used without mutual authentication, we assume the link is secure anyway=20 (and if it isn't, a DoS attack is the least of our concerns).=20 Besides, it's more user-friendly to inform the user immediately=20 instead of waiting for long timeout. > b. Mutually authenticating method. Peer successfully > authenticates the authenticator. Does the peer accept a > subsequent EAP Failure? Why or why not? The EAP Failure is accepted (and link disabled) UNLESS the method in question has an internal "access allowed" message=20 (not the same as internal "I've authenticated you" message),=20 and we have received such a message. I don't think any other behavior would increase resistance to DoS attacks in any significant amount, and the user-friendliness aspect is outweighs that. If DoS attacks would be a concern, we should use a method that has internal "access allowed" message (such as PEAP). > c. Mutually authenticating method. Peer unsuccessfully > authenticates the authenticator. Does it accept a subsequent > EAP Success? Why or why not? I assume "unsuccessfully" means "we have decided that we don't want to talk to this authenticator". Obviously, then we don't talk to it. Do you think the reasoning above would cover all cases, and is ok?=20 Best regards, Pasi=20 From alper@docomolabs-usa.com Fri May 9 19:32:11 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Fri, 09 May 2003 11:32:11 -0700 Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication In-Reply-To: Message-ID: I think the answer to your below questions depend on this: - Does EAP success mean peer is authorized for network access or just authenticated? I understand EAP methods may signal their own authentication result or authorization result. But what should EAP result mean? Alper >> Do you mean that the peer should always enable the link >> when it is authenticated the authenticator, even when >> the authenticator signals it won't give access? > > I'm asking what the state machine does in this circumstance. From the > point of view of the peer, it is satisfied in a mutually authenticating > method where it successfully authenticates the authenticator. It is also > satisfied in a one-way method, since in that case the authenticator is > only authenticating the peer; the peer assumes that the authenticator is > authentic. > > I had thought that the state machine model was that each side makes > its own decision. Of course where the peer is satisfied, but the > authenticator is not, there are drawbacks to having the peer enable the > link. The peer will attempt DHCP, and if the authenticator has disabled > its side of the link, no response will be received and the peer will > then assign a linklocal address instead, and might not check again for > 5 minutes. > > So I'm asking what happens in each case, and what the decision is based > on: > > a. One-way method. Peer fails to authenticate to the authenticator and the > authenticator sends an EAP failure. Does the Peer process the EAP Failure > and disable its side of the link? Why or why not? > > b. Mutually authenticating method. Peer successfully authenticates the > authenticator. Does the peer accept a subsequent EAP Failure? Why or why > not? > > c. Mutually authenticating method. Peer unsuccessfully authenticates the > authenticator. Does it accept a subsequent EAP Success? Why or why not? > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri May 9 19:21:50 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 9 May 2003 11:21:50 -0700 (PDT) Subject: [eap] Re: Issue 121: Potential meaning of successful authentication Message-ID: >Do you think the reasoning above would cover all cases, >and is ok? Yes, I think the reasoning covers all cases, and makes some sense. The question is how to reflect this unambiguously in the language of the draft. Basically, you are saying that an EAP Failure is accepted unless the method includes a protected result indication and that indication contradicts the EAP Failure. So the Failure is accepted after one-way authentication or even mutual authentication if no protected result indication is provided by the method. Success is only accepted in the case of a one-way authentication method, or a mutual authentication method where the peer successfully authenticates the authenticator. If a protected result indication is provided, then the indication needs to indicate success in order for the Success packet to be processed. I'm not entirely clear on what would constitute a protected result indication, though. In EAP TLS, since we have authorization error messages, and a "Finished" message, is the absence of a TLS alert considered a "protected result indication" in this context? I think that this is the case since an alert could still be sent after the peer successfully authenticates the authenticator, and if a "finished" message is sent instead, that means everything is ok. From aboba@internaut.com Sat May 10 16:30:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 10 May 2003 08:30:15 -0700 (PDT) Subject: [eap] Issue 124: Identity Protection Message-ID: Issue 124: Identity Protection Submitter name: Mark Schurman Submitter email address: mschur@microsoft.com Date first submitted: May 6, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I had a few comments on this doc, with regards to identity protection: Page 4: When the term Confidentiality is defined, it includes the sentence "A method making this claim MUST support identity protection." However, "identity protection" is not defined in this list, and is not seen until page 29. This list should include a quick description for the term. Page 5, heading 2, point 1: This paragraph mentions that the initial Identity Request is optional, and gives a few scenarios as examples. I'd suggest adding identity protection in this list as well. (Knowing that some implementations can determine it from other information is somewhat useful, but it seems more useful to me to state that, even if the identity can't be determined yet, delaying the identity request could be desirable from a security standpoint.) Page 29: Heading "Identity Protection", paragraph 1: Should we provide more details on this? One question I had was whether a complete identity response could be delayed only at the EAP server's discretion (by delaying the identity request), or if the EAP peer (client) could unilaterally choose to delay the complete identity response. For example, if the client were configured to perform an EAP type that supports identity protection (like PEAP), which of the following statements is appropriate, or do we want to leave this unspecified in the draft? A) The EAP peer MUST always respond to an identity request with complete identity information. [The next paragraph in the draft qualifies this, describing different requirements for the peer-name portion vs. the realm portion of the identity response.] B) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer {SHOULD, MAY} respond to an identity request with {complete, complete or partial} identity information. C) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer MAY disregard the initial (cleartext) identity request, providing an incomplete [or blank?] response. However, the EAP peer {SHOULD, MUST} provide complete identity information to the protected identity request. or some other permutation. Is this information / behavior that we want to require/restrict, allow/disallow, or leave unspecified? I also have one comment on page 10. The first sentence in this paragraph and the last sentence in the paragraph seem to contradict - may be we need to remove the first sentence completely. Lower layer CRC or checksum is not necessary. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer. If lower layers exhibit a high loss rate, then retransmissions are likely, and since EAP Success and Failure are not retransmitted, timeouts are also likely to result. EAP methods such as EAP TLS [RFC2716] include a message integrity check (MIC) and regard MIC errors as fatal. Therefore if a checksum or CRC is not provided by the lower layer, then some methods may not behave well. From jari.arkko@piuha.net Sat May 10 19:01:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat, 10 May 2003 21:01:47 +0300 Subject: [eap] Issue 124: Identity Protection In-Reply-To: References: Message-ID: <3EBD3E8B.7030109@piuha.net> Bernard Aboba wrote: > Page 29: Heading "Identity Protection", paragraph 1: Should we provide > more details on this? One question I had was whether a complete identity > response could be delayed only at the EAP server's discretion (by delaying > the identity request), or if the EAP peer (client) could unilaterally > choose to delay the complete identity response. For example, if the client > were configured to perform an EAP type that supports identity protection > (like PEAP), which of the following statements is appropriate, or do we > want to leave this unspecified in the draft? > > A) The EAP peer MUST always respond to an identity request with complete > identity information. [The next paragraph in the draft qualifies this, > describing different requirements for the peer-name portion vs. the realm > portion of the identity response.] This may be the best we can do. But the current draft sections 7.3 and 5.1 appear incomplete with regards to how you actually leave the username portion out. Should I send "@foo.com" or "foo.com" or perhaps even "dummy@foo.com"? This does not appear to have been specified anywhere. > B) In cases where the EAP peer is performing an EAP type that supports > identity protection, the EAP peer {SHOULD, MAY} respond to an identity > request with {complete, complete or partial} identity information. The peer may support many things, but how does it know what the authenticator is going to ask it to do? > C) In cases where the EAP peer is performing an EAP type that supports > identity protection, the EAP peer MAY disregard the initial (cleartext) > identity request, providing an incomplete [or blank?] response. However, > the EAP peer {SHOULD, MUST} provide complete identity information to the > protected identity request. Again, it is unclear to me what the order of events is. Assuming the peer supports M1, M2, and M3 where only M1 supports identity protection, does this mean that the peer never provides a good enough identity response for M2 & M3? If yes, the introduction of the first identity-protecting method would disable all other methods... This appears to be a problem for all alternatives A-C, assuming the 7.3 approach is considered a part of A. Policy would be one way of fixing this problem. Policy could say that now we will use identity protection. In general, I'm not too happy about introducing new policy knobs, however. Perhaps we could say that if all the methods you are prepared to accept (in terms of policy and availability of credentials) support identity privacy, then you don't send full identity information? --Jari From aboba@internaut.com Sun May 11 03:45:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 10 May 2003 19:45:47 -0700 (PDT) Subject: [eap] Issue 124: Identity Protection In-Reply-To: <3EBD3E8B.7030109@piuha.net> References: <3EBD3E8B.7030109@piuha.net> Message-ID: > This may be the best we can do. But the current draft sections 7.3 and > 5.1 appear incomplete with regards to how you actually leave the username > portion out. Should I send "@foo.com" or "foo.com" or perhaps even > "dummy@foo.com"? This does not appear to have been specified anywhere. In fact, the RFC 2284bis doesn't say anything at all about what can be in the Identity Response -- not even that it should contain an NAI. I think that's intentional, actually. If the goal is to specify this, then I'd suggest an update to RFC 2486 (as you've proposed), or a change to RFC 2869bis. > > B) In cases where the EAP peer is performing an EAP type that supports > > identity protection, the EAP peer {SHOULD, MAY} respond to an identity > > request with {complete, complete or partial} identity information. > > The peer may support many things, but how does it know what the > authenticator is going to ask it to do? Yes. It only knows what methods it would accept. The peer could be set to only accept methods that support identity protection, and therefore could provide a userid-less response to the Identity Request. > > C) In cases where the EAP peer is performing an EAP type that supports > > identity protection, the EAP peer MAY disregard the initial (cleartext) > > identity request, providing an incomplete [or blank?] response. However, > > the EAP peer {SHOULD, MUST} provide complete identity information to the > > protected identity request. > > Again, it is unclear to me what the order of events is. Assuming the > peer supports M1, M2, and M3 where only M1 supports identity > protection, does this mean that the peer never provides a good > enough identity response for M2 & M3? If the peer cares that much about identity protection, it won't accept M2 and M3. Otherwise, I think it has to provide the identity, since it won't know whether it will be asked to do M1, M2 or M3. > Perhaps we could say that if all the methods you are prepared > to accept (in terms of policy and availability of credentials) > support identity privacy, then you don't send full identity > information? Yes, that makes sense to me. From aboba@internaut.com Sun May 11 04:18:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 10 May 2003 20:18:34 -0700 (PDT) Subject: [eap] Issue 125: Retransmission Issue Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 10, 2003 Reference: Document: RFC2869bis-20 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue: RADIUS [RFC2865] does not define retransmission behavior. However we have seen situations (such as a network-wide reboot) where RADIUS storms can occur, swamping the RADIUS server(s). In these situations it would be preferrable for RADIUS clients to support exponential backoff and a more conservative initial RTO estimate, as in TCP. Change Section 2.3 from: "2.3. Retransmission As noted in [RFC2284], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible for retransmission of packets between the RADIUS client and the RADIUS server. It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet. If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP- Response corresponding to the Request, then the EAP-Request is retransmitted." To: "2.3. Retransmission As noted in [RFC2284], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible for retransmission of packets between the RADIUS client and the RADIUS server. It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet. If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP- Response corresponding to the Request, then the EAP-Request is retransmitted. In RADIUS [RFC2865], the RADIUS client is responsible for retransmission of RADIUS packets. RADIUS/EAP client implementations SHOULD support dynamic estimation of the RADIUS retransmission timeout, using the algorithms specified in [RFC2988]. Since RADIUS Access-Requests may be routed the RADIUS server based on the NAI realm [RFC2486], dynamic retransmission timeout estimates SHOULD be maintained on a per-realm or per-EAP session basis." From aboba@internaut.com Sun May 11 04:44:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 10 May 2003 20:44:11 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 124: Identity Protection Message-ID: The text of Issue 124 is given below. The proposed resolution is as follows: Change text in Section 5.1 from: "The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity). Since Identity Requests and Responses are not protected, from a security perspective, it may be preferable for protected method- specific Identity exchanges to be used instead." To: "The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity). Since Identity Requests and Responses are not protected, from a privacy perspective, it may be preferable for protected method-specific Identity exchanges to be used instead. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as providing only the realm portion of the NAI [RFC2486])" ------------------------------------------------------------------ Issue 124: Identity Protection Submitter name: Mark Schurman Submitter email address: mschur@microsoft.com Date first submitted: May 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-May/001183.html Document: EAP-02 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I had a few comments on this doc, with regards to identity protection: Page 4: When the term Confidentiality is defined, it includes the sentence "A method making this claim MUST support identity protection." However, "identity protection" is not defined in this list, and is not seen until page 29. This list should include a quick description for the term. Page 5, heading 2, point 1: This paragraph mentions that the initial Identity Request is optional, and gives a few scenarios as examples. I'd suggest adding identity protection in this list as well. (Knowing that some implementations can determine it from other information is somewhat useful, but it seems more useful to me to state that, even if the identity can't be determined yet, delaying the identity request could be desirable from a security standpoint.) Page 29: Heading "Identity Protection", paragraph 1: Should we provide more details on this? One question I had was whether a complete identity response could be delayed only at the EAP server's discretion (by delaying the identity request), or if the EAP peer (client) could unilaterally choose to delay the complete identity response. For example, if the client were configured to perform an EAP type that supports identity protection (like PEAP), which of the following statements is appropriate, or do we want to leave this unspecified in the draft? A) The EAP peer MUST always respond to an identity request with complete identity information. [The next paragraph in the draft qualifies this, describing different requirements for the peer-name portion vs. the realm portion of the identity response.] B) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer {SHOULD, MAY} respond to an identity request with {complete, complete or partial} identity information. C) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer MAY disregard the initial (cleartext) identity request, providing an incomplete [or blank?] response. However, the EAP peer {SHOULD, MUST} provide complete identity information to the protected identity request. or some other permutation. Is this information / behavior that we want to require/restrict, allow/disallow, or leave unspecified? I also have one comment on page 10. The first sentence in this paragraph and the last sentence in the paragraph seem to contradict - may be we need to remove the first sentence completely. Lower layer CRC or checksum is not necessary. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer. If lower layers exhibit a high loss rate, then retransmissions are likely, and since EAP Success and Failure are not retransmitted, timeouts are also likely to result. EAP methods such as EAP TLS [RFC2716] include a message integrity check (MIC) and regard MIC errors as fatal. Therefore if a checksum or CRC is not provided by the lower layer, then some methods may not behave well. [jari arkko]: > Page 29: Heading "Identity Protection", paragraph 1: Should we provide > more details on this? One question I had was whether a complete identity > response could be delayed only at the EAP server's discretion (by > delaying the identity request), or if the EAP peer (client) could > unilaterally choose to delay the complete identity response. For > example, if the client were configured to perform an EAP type that > supports identity protection (like PEAP), which of the following > statements is appropriate, or do we want to leave this unspecified in > the draft? > > A) The EAP peer MUST always respond to an identity request with complete > identity information. [The next paragraph in the draft qualifies this, > describing different requirements for the peer-name portion vs. the > realm portion of the identity response.] This may be the best we can do. But the current draft sections 7.3 and 5.1 appear incomplete with regards to how you actually leave the username portion out. Should I send "@foo.com" or "foo.com" or perhaps even "dummy@foo.com"? This does not appear to have been specified anywhere. > B) In cases where the EAP peer is performing an EAP type that supports > identity protection, the EAP peer {SHOULD, MAY} respond to an identity > request with {complete, complete or partial} identity information. The peer may support many things, but how does it know what the authenticator is going to ask it to do? > C) In cases where the EAP peer is performing an EAP type that supports > identity protection, the EAP peer MAY disregard the initial (cleartext) > identity request, providing an incomplete [or blank?] response. However, > the EAP peer {SHOULD, MUST} provide complete identity information to the > protected identity request. Again, it is unclear to me what the order of events is. Assuming the peer supports M1, M2, and M3 where only M1 supports identity protection, does this mean that the peer never provides a good enough identity response for M2 & M3? If yes, the introduction of the first identity-protecting method would disable all other methods... This appears to be a problem for all alternatives A-C, assuming the 7.3 approach is considered a part of A. Policy would be one way of fixing this problem. Policy could say that now we will use identity protection. In general, I'm not too happy about introducing new policy knobs, however. Perhaps we could say that if all the methods you are prepared to accept (in terms of policy and availability of credentials) support identity privacy, then you don't send full identity information? From aboba@internaut.com Sun May 11 05:11:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 10 May 2003 21:11:32 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 119: EAP inappropriate for peer-to-peer Message-ID: The text of Issue 119 is available on the EAP Issues Web page: http://www.drizzle.com/~aboba/EAP/eapissues.html The proposed resolution is as follows: In the EAP Keying Framework document, add the following requirements to Section 4.1: Liveness Methods deriving keys SHOULD exchange random nonces, and SHOULD protect the nonces from modification. Man-in-the-middle and replay protection Methods deriving keys SHOULD detect replay and man-in-the-middle attacks in either direction. From jari.arkko@piuha.net Sun May 11 07:17:05 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 09:17:05 +0300 Subject: [eap] Issue 125: Retransmission Issue In-Reply-To: References: Message-ID: <3EBDEAE1.2050101@piuha.net> Bernard Aboba wrote: > In RADIUS [RFC2865], the RADIUS client is responsible for retransmission > of RADIUS packets. RADIUS/EAP client implementations SHOULD support > dynamic estimation of the RADIUS retransmission timeout, using the algorithms > specified in [RFC2988]. Since RADIUS Access-Requests may be routed the RADIUS server > based on the NAI realm [RFC2486], dynamic retransmission timeout estimates > SHOULD be maintained on a per-realm or per-EAP session basis." Ok. --Jari From jari.arkko@piuha.net Sun May 11 07:48:46 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 09:48:46 +0300 Subject: [eap] Proposed resolution to Issue 124: Identity Protection In-Reply-To: References: Message-ID: <3EBDF24E.1050307@piuha.net> Bernard Aboba wrote: > Since Identity Requests and Responses are not protected, from a > privacy perspective, it may be preferable for protected > method-specific Identity exchanges to be used instead. > Where the peer is configured to only accept authentication > methods supporting protected identity exchanges, the peer > MAY provide an abbreviated Identity Response (such as > providing only the realm portion of the NAI [RFC2486])" Very good. But I'm still wondering whether we should be more explicit about what the spec says about the format of Identity Responses. In issue 33 we decided not to tie the Identity Response to always be a NAI. (Is that decision still wise, if we intend to update NAI RFC later? Perhaps it is, we can't do the update simultaneously...) Anyway, should we be more explicit in Section 5.1 that this is the case? For instance: "Note that the identity is often represented as a NAI [RFC2486], but this specification allows any format to be used." --Jari From jari.arkko@piuha.net Sun May 11 12:35:59 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 14:35:59 +0300 Subject: [eap] editorial issues on 2284bis-03.f Message-ID: <3EBE359F.6090706@piuha.net> A few minor editorial nits that should probably be handled somehow: > 1. Introduction > > EAP may be used on dedicated links as well as switched circuits, and > wired as well as wireless links. To date, EAP has been implemented > with hosts and routers that connect via switched circuits or dial-up > lines using PPP [RFC1661]. It has also been implemented with switches > and access points using IEEE 802 [IEEE.802.1990]. EAP encapsulation > on IEEE 802 wired media is described in [IEEE.802.1X]. Add wireless LANs to this list: "EAP encapsulation on IEEE wireless LANs is described in [IEEE.802-11.1999]." > 1.2 > authenticator > The end of the EAP link initiating EAP authentication. The > term authenticator is used in [IEEE.802.1X], and has the > same meaning in this document. > > peer > The end of the EAP Link that responds to the authenticator. > In [IEEE.802.1X], this end is known as the Supplicant. Just wondering about the capitalization. Does IEEE 802.1X really call something "authenticator" and something else "Supplicant"? > 1.3 Security claims terminology for EAP methods > > These terms are used in particular in Section 7.2: s/in particular in Section 7.2/to described the security properties of EAP methods/ > Advantages > The EAP protocol can support multiple authentication mechanisms > without having to pre-negotiate a particular one. Propose to use a slightly different formatting here, maybe the XML2RFC style='symbol' lists? > 2. ... > > For sessions in which the authenticator acts as a pass-through, it > MUST determine the outcome of the authentication solely based on > the Accept/Reject indication sent by the backend authentication > server; the outcome MUST NOT be determined by the contents of an > EAP packet sent along with the Accept/Reject indication, or the > absence of such an encapsulated EAP packet. This normative language should be moved somewhere else, it seems a bit out of place in the advantages list. Maybe Section 2.2? > 2.1. ... > Supporting multiple authentication methods within an EAP conversation > would add complexity to the EAP protocol, would enable > man-in-the-middle attacks (see Section 7.4), and would result in > interoperability problems, since existing EAP implementations > typically do not support multiple authentication methods. The above text seems a bit out of place, its like a statement of the consensus in the wg and why we have done something. Suggested rewrite: "Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations.", and move this text to be the lead-in for the last paragraph. > 6.1 Definition of Terms Remove the 6.1 heading, I believe the reader will find it easier to go to the right place in the document if the structure of the IANA section is "6.1. Packet Codes" and "6.2. Method Types". Merge the below paragraphs in the above text, after the first paragraph in 6. > 6.2 Recommended Registration Policies Paragraph 2 goes to new 6.1, rest to 6.2. --Jari From jari.arkko@piuha.net Sun May 11 12:36:39 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 14:36:39 +0300 Subject: [eap] displayable message Message-ID: <3EBE35C7.7010104@piuha.net> From the terms section: > Displayable Message > This is interpreted to be a human readable string of > characters, and MUST NOT affect operation of the protocol. > The message encoding MUST follow the UTF-8 transformation > format [RFC2279]. First, I'm not too happy to have keyword behaviour in the terms section. Secondly, in Section 5.5 this term is used for the OTP challenge, which I believe contains machine readable sequence numbers and seeds. That would seem to affect the behaviour of the protocol! Suggested rewrite: move the MUST-NOT-affect-operation requirement to the relevant sections where the term is referred to. Keep the UTF-8 requirement here. Consider replacing 5.5 "displayable message" with simply a reference to the OTP RFC format. --Jari From aboba@internaut.com Sun May 11 13:25:01 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 11 May 2003 05:25:01 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 124: Identity Protection In-Reply-To: <3EBDF24E.1050307@piuha.net> References: <3EBDF24E.1050307@piuha.net> Message-ID: > (Is that decision still wise, > if we intend to update NAI RFC later? Perhaps it is, we can't do the > update simultaneously...) We have to decide if we're going to make RFC 2284bis dependent on RFC 2486bis. > Anyway, should we be more explicit > in Section 5.1 that this is the case? For instance: "Note that > the identity is often represented as a NAI [RFC2486], but > this specification allows any format to be used." I think the point is that the NAI is not required for peer-to-peer authentication or use outside of roaming. However, if the EAP peer wishes to support roaming, then the NAI format is required. Something along those lines should probably be stated in RFC 2486bis. From aboba@internaut.com Sun May 11 19:51:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 11 May 2003 11:51:38 -0700 (PDT) Subject: [eap] Re: editorial issues on 2284bis-03.f Message-ID: Filed (along with the Displayable Message issue) as Issue 126. From jari.arkko@piuha.net Sun May 11 21:39:52 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 23:39:52 +0300 Subject: [eap] more editorial issues in 2284bis-03.f Message-ID: <3EBEB518.5010601@piuha.net> > Length > > The Length field is two octets and indicates the length of the EAP > packet including the Code, Identifier, Length and Data fields. I'd prefer "The Length field is two octets. It indicates the number of octets in the EAP packet including the Code, Identifier, Length, and Data fields." Also, Section 4 and 4.1 have duplicate text for the description of the Length field. Suggest cutting the first text shorter, maybe "The Length field is two octets and indicates the length of the complete EAP packet." > 4.1 ... > > Retransmitted Requests MUST be sent with the same Identifier value > in order to distinguish them from new Requests. The contents of > the data field is dependent on the Request Type. The peer MUST "are dependent" ? > 5. Initial EAP Request/Response Types > > All EAP implementations MUST support Types 1-4, which are defined in > this document, and SHOULD support Type 254. Follow-on RFCs MAY define > additional EAP Types. MAY in the last sentence does not appear to be an implementation requirement. Replace with "Implementations MAY support other Types defined here or in future RFCs." > 5.7 Expanded Types > > Description > > Due to EAP's popularity, the original method Type space, which > only provides for 255 values, is being allocated at a pace which > if continued would result in exhaustion within a few years. This is an interesting status report, but may not be very useful in a protocol specification. In any case, the text that comes after this explains the purpose of the scheme. Suggestion: delete the first sentence. > 7.11. ... > > This can be done by enabling users to configure which are the > acceptable ciphersuites as a matter of security policy; or, the > ciphersuite negotiation MAY be authenticated using keying material > derived from the EAP authentication and a MAC algorithm agreed upon > in advance by lower-layer peers. s/MAC/MIC/ --Jari From jari.arkko@piuha.net Sun May 11 21:43:15 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 23:43:15 +0300 Subject: [eap] security properties issues in 2284bis-03.f Message-ID: <3EBEB5E3.7080802@piuha.net> I have a few question marks related to specific security issues: > Replay protection > This refers to protection against replay of EAP messages, > including EAP Requests and Responses, and method-specific > success and failure indications. Question: Is it always so that replay protection of messages implies replay protection of the full method? I could imagine a broken method which initializes the replay protection (e.g. client gives a counter) in a way which makes it possible for someone to replay the whole method? Suggest s/EAP messages including EAP requests and responses, and/ an EAP method or its messages, including/ > Man-in-the-Middle resistance > The ability for the peer to demonstrate to the > authenticator that it has acted as the peer for each > authentication method within the conversation. Similarly, > the authenticator demonstrates to the peer that it has > acted as the authenticator for each authentication method > within the conversation. If this is not possible, then the > authentication sequence or tunnel may be vulnerable to a > man-in-the-middle attack. This applies only for tunnels and sequences, but the text could be clearer about it. Replace last sentence with "If this is not possible, then there may be a vulnerability to a man-in-the-middle attack." Add a new sentence at the beginning: "This property applies only for the use of multiple methods in a combination, such as in authentication sequences or tunnels.". > MiTM resistance: No (In many places.) I believe this should really be a "N/A" instead, because an individual method can do little to protect against MitM even if its perfect. Unless the method is a tunnel method, of course, in which case it can do or not do much for MitM... > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction. Both peers > may act as authenticators and authenticatees at the same time. Perhaps add a reference to Section 7.7 which talks about the limitations of two simultaneous authentications. > Where a single EAP authentication method is utilized, but other > methods are run within it (a "tunneled" method) the prohibition > against multiple authentication methods does not apply. Such > "tunneled" methods appear as a single authentication method to EAP. > Backward compatibility can be provided, since a peer not supporting a > "tunneled" method can reply to the initial EAP-Request with a Nak > (legacy or expanded). To address security vulnerabilities, > "tunneled" methods MUST support protection against man-in-the-middle > attacks. "support protection" sounds like an optional to use thing. Maybe we should say "protect". Note that this would require at least a policy-based mechanism to prevent problems with non-key-generating methods. --Jari From jari.arkko@piuha.net Sun May 11 21:43:27 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 23:43:27 +0300 Subject: [eap] other issues in 2284bis-03.f Message-ID: <3EBEB5EF.2020509@piuha.net> A few additional questions and comments: > 3.4 Lower layer indications > > Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation MUST NOT conclude > that authentication has succeeded based on those indications. The last sentence has too many NOTs, I think. How about "However, lower layer success indications MUST NOT affect EAP message processing so that the EAP implementation would conclude ..." > 4.1 Request and Response > > Description > > The Request packet (Code field set to 1) is sent by the > authenticator to the peer. Each Request has a Type field which > serves to indicate what is being requested. Additional Request > packets MUST be sent until a valid Response packet is received, or > an optional retry counter expires. Retry counter? This seems to be the only place we talk about retry counters. Perhaps a timeout is assumed instead? If so, "..., or until a timeout expires." > 7.14. > > [a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=1 (Request) and Type=Method-Type. This > implies that methods supporting "strict interpretation" do not > utilize Notification, but instead support their own > method-specific error messages. Hmm... perhaps they don't use notification at all and just want to avoid getting them? Suggested rewrite: "... do not utilize Notification or support their own method-specific notification messages." > Where an authenticator operates as a pass-through, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP layer header fields (Code, Identifier, > Length). Since pass-through authenticators rely on a backend > authenticator server to implement methods, the EAP method layer > header fields (Type, Type-Data) are not examined as part of the > forwarding decision. The forwarding model is illustrated in Figure 2. > Compliant pass-through authenticator implementations MUST by default > be capable of forwarding packets from any EAP method. This specification is insufficient for me to implement a passthrough: it doesn't do some things per above, but what does it do then? I do realize that the proper specification depends on the AAA protocol translation for instance, so maybe we shouldn't expect to have a full specification here. Perhaps reference 2869bis? Or should we list the actions that the forwarding decision must make? --Jari From jari.arkko@piuha.net Sun May 11 21:54:35 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 11 May 2003 23:54:35 +0300 Subject: [eap] Proposed resolution to Issue 124: Identity Protection In-Reply-To: References: <3EBDF24E.1050307@piuha.net> Message-ID: <3EBEB88B.4050205@piuha.net> Bernard Aboba wrote: >>(Is that decision still wise, >>if we intend to update NAI RFC later? Perhaps it is, we can't do the >>update simultaneously...) > > > We have to decide if we're going to make RFC 2284bis dependent on RFC > 2486bis. I really don't want additional dependencies, so the choices are really referring to 2486 classic, or none at all... if we refer to it I'm sure folks will pick up the 2486bis later when it comes out even if 2284bis isn't updated for the reference. However, if we put in the reference now to 2284bis, this will restrict the current usage to current 2486. Thus it appears that the possible choices we have are: (1) Leave the format open (maybe add a note that typically NAI is used) (2) Reference 2486 and describe the additional cases such as domain-only-for-id-protection in 2284bis. --Jari From aboba@internaut.com Mon May 12 18:36:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 May 2003 10:36:10 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 126: Miscellaneous NITs Message-ID: I'd like to propose that these proposed changes be accepted. Note that I've moved some of the changes that require more discussion into another issue. ------------------------------------------------------------------- Issue 126: Miscellaneous NITs Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 10, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-May/001191.html Document: EAP-03f Comment type: E Priority: S Section: Various Rationale/Explanation of issue: A few minor editorial nits that should probably be handled somehow: > 1.2 > authenticator > The end of the EAP link initiating EAP authentication. The > term authenticator is used in [IEEE.802.1X], and has the > same meaning in this document. > > peer > The end of the EAP Link that responds to the authenticator. > In [IEEE.802.1X], this end is known as the Supplicant. Just wondering about the capitalization. Does IEEE 802.1X really call something "authenticator" and something else "Supplicant"? [BA] - It uses Authenticator and Supplicant. The definition of authenticator should be: authenticator The end of the EAP link initiating EAP authentication. The term Authenticator is used in [IEEE.802.1X], and authenticator has the same meaning in this document. > 1.3 Security claims terminology for EAP methods > > These terms are used in particular in Section 7.2: s/in particular in Section 7.2/to described the security properties of EAP methods/ > Advantages > The EAP protocol can support multiple authentication mechanisms > without having to pre-negotiate a particular one. Propose to use a slightly different formatting here, maybe the XML2RFC style='symbol' lists? > 2. ... > > For sessions in which the authenticator acts as a pass-through, it > MUST determine the outcome of the authentication solely based on > the Accept/Reject indication sent by the backend authentication > server; the outcome MUST NOT be determined by the contents of an > EAP packet sent along with the Accept/Reject indication, or the > absence of such an encapsulated EAP packet. This normative language should be moved somewhere else, it seems a bit out of place in the advantages list. Maybe Section 2.2? > 2.1. ... > Supporting multiple authentication methods within an EAP conversation > would add complexity to the EAP protocol, would enable > man-in-the-middle attacks (see Section 7.4), and would result in > interoperability problems, since existing EAP implementations > typically do not support multiple authentication methods. The above text seems a bit out of place, its like a statement of the consensus in the wg and why we have done something. Suggested rewrite: "Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations.", and move this text to be the lead-in for the last paragraph. > 6.1 Definition of Terms Remove the 6.1 heading, I believe the reader will find it easier to go to the right place in the document if the structure of the IANA section is "6.1. Packet Codes" and "6.2. Method Types". Merge the below paragraphs in the above text, after the first paragraph in 6. > 6.2 Recommended Registration Policies Paragraph 2 goes to new 6.1, rest to 6.2. > Length > > The Length field is two octets and indicates the length of the EAP > packet including the Code, Identifier, Length and Data fields. I'd prefer "The Length field is two octets. It indicates the number of octets in the EAP packet including the Code, Identifier, Length, and Data fields." Also, Section 4 and 4.1 have duplicate text for the description of the Length field. Suggest cutting the first text shorter, maybe "The Length field is two octets and indicates the length of the complete EAP packet." [BA] This could be conceived of including MAC headers too, so I'd prefer we leave it as it is. > 4.1 ... > > Retransmitted Requests MUST be sent with the same Identifier value > in order to distinguish them from new Requests. The contents of > the data field is dependent on the Request Type. The peer MUST "are dependent" ? > 5. Initial EAP Request/Response Types > > All EAP implementations MUST support Types 1-4, which are defined in > this document, and SHOULD support Type 254. Follow-on RFCs MAY define > additional EAP Types. MAY in the last sentence does not appear to be an implementation requirement. Replace with "Implementations MAY support other Types defined here or in future RFCs." > 5.7 Expanded Types > > Description > > Due to EAP's popularity, the original method Type space, which > only provides for 255 values, is being allocated at a pace which > if continued would result in exhaustion within a few years. This is an interesting status report, but may not be very useful in a protocol specification. In any case, the text that comes after this explains the purpose of the scheme. Suggestion: delete the first sentence. > 7.11. ... > > This can be done by enabling users to configure which are the > acceptable ciphersuites as a matter of security policy; or, the > ciphersuite negotiation MAY be authenticated using keying material > derived from the EAP authentication and a MAC algorithm agreed upon > in advance by lower-layer peers. s/MAC/MIC/ From aboba@internaut.com Mon May 12 18:42:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 May 2003 10:42:11 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 127: Security Terms Message-ID: I'd like to recommend that the proposed changes be accepted. Any objections? ----------------------------------------------------------------- Issue 127: Security Terms Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 12, 2003 Reference: Document: EAP-02 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: I have a few question marks related to specific security issues: > Replay protection > This refers to protection against replay of EAP messages, > including EAP Requests and Responses, and method-specific > success and failure indications. Question: Is it always so that replay protection of messages implies replay protection of the full method? I could imagine a broken method which initializes the replay protection (e.g. client gives a counter) in a way which makes it possible for someone to replay the whole method? Suggest s/EAP messages including EAP requests and responses, and/ an EAP method or its messages, including/ > Man-in-the-Middle resistance > The ability for the peer to demonstrate to the > authenticator that it has acted as the peer for each > authentication method within the conversation. Similarly, > the authenticator demonstrates to the peer that it has > acted as the authenticator for each authentication method > within the conversation. If this is not possible, then the > authentication sequence or tunnel may be vulnerable to a > man-in-the-middle attack. This applies only for tunnels and sequences, but the text could be clearer about it. Replace last sentence with "If this is not possible, then there may be a vulnerability to a man-in-the-middle attack." Add a new sentence at the beginning: "This property applies only for the use of multiple methods in a combination, such as in authentication sequences or tunnels.". > MiTM resistance: No (In many places.) I believe this should really be a "N/A" instead, because an individual method can do little to protect against MitM even if its perfect. Unless the method is a tunnel method, of course, in which case it can do or not do much for MitM... > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction. Both peers > may act as authenticators and authenticatees at the same time. Perhaps add a reference to Section 7.7 which talks about the limitations of two simultaneous authentications. [BA] "For a discussion of security issues in peer-to-peer operation, see Section 7.7." From aboba@internaut.com Mon May 12 18:51:44 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 May 2003 10:51:44 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 128: Accept with modifications Message-ID: The text of Issue 128 is enclosed below. I'd like to propose that we accept this change with the modifications below. ---------------------------------------------------------------------- Issue 128: Encapsulation reference Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 12, 2003 Reference: Document: EAP-03.f Comment type: E Priority: S Section: Various Rationale/Explanation of issue: > 1. Introduction > > EAP may be used on dedicated links as well as switched circuits, and > wired as well as wireless links. To date, EAP has been implemented > with hosts and routers that connect via switched circuits or dial-up > lines using PPP [RFC1661]. It has also been implemented with switches > and access points using IEEE 802 [IEEE.802.1990]. EAP encapsulation > on IEEE 802 wired media is described in [IEEE.802.1X]. Add wireless LANs to this list: "EAP encapsulation on IEEE wireless LANs is described in [IEEE.802-11.1999]." [BA] - Ah, but it isn't defined there. It *will* be defined in IEEE 802.11i, but the encapsulation could be different from that specified in IEEE 802.1X-2001. For example, it has been suggested that EAP be encapsulated within IEEE 802.11 Authenticate frames instead of data frames. So I would suggest that we add a reference to IEEE 802.11i (a work in progress) instead. From jari.arkko@piuha.net Mon May 12 19:18:59 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 12 May 2003 21:18:59 +0300 Subject: [eap] Proposed resolution to Issue 126: Miscellaneous NITs In-Reply-To: References: Message-ID: <3EBFE593.2050209@piuha.net> Bernard Aboba wrote: > Also, Section 4 and 4.1 have duplicate text for the description of > the Length field. Suggest cutting the first text shorter, maybe > "The Length field is two octets and indicates the length of the > complete EAP packet." > > [BA] This could be conceived of including MAC headers too, so I'd prefer > we leave it as it is. Yes, I see your point. Better have duplicated correct text than one correct and one incorrect text ;-) --Jari From aboba@internaut.com Mon May 12 19:13:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 May 2003 11:13:09 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 129: More NITs Message-ID: The text of Issue 129 is enclosed below. The proposed resolution is as follows: Change the text in Section 5.5 from: "Displayable Message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [RFC2279]." To: Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Change the text in Section 3.4 from: "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, lower layer success indications MUST NOT affect EAP message processing so that an EAP implementation MUST NOT conclude that authentication has succeeded based on those indications." To: "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, lower layer success indications MUST NOT affect EAP message processing so that an EAP implementation cannot conclude that authentication has succeeded based on those indications." Change the text in Section 7.14 from: "[a] On the peer, all EAP packets MUST be silently discarded, except for those with Code=1 (Request) and Type=Method-Type. This implies that methods supporting "strict interpretation" do not utilize Notification, but instead support their own method-specific error messages." To: "[a] On the peer, all EAP packets MUST be silently discarded, except for those with Code=1 (Request) and Type=Method-Type. This implies that methods supporting "strict interpretation" do not send or expect to receive Notification-Requests but instead support their own method-specific error messages." Change: "Where an authenticator operates as a pass-through, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method." To: "Where an authenticator operates as a pass-through, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). This includes performing validity checks on the Code, Identifer and Length fields, as described in Section 4.1. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method. The use of the RADIUS protocol for encapsulation of EAP in pass-through operation is described in [RFC2869bis]." ------------------------------------------------------------ Issue 129: More NITs Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 12, 2003 Reference: Document: EAP-03.f Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >From the terms section: > Displayable Message > This is interpreted to be a human readable string of > characters, and MUST NOT affect operation of the protocol. > The message encoding MUST follow the UTF-8 transformation > format [RFC2279]. First, I'm not too happy to have keyword behaviour in the terms section. Secondly, in Section 5.5 this term is used for the OTP challenge, which I believe contains machine readable sequence numbers and seeds. That would seem to affect the behaviour of the protocol! Suggested rewrite: move the MUST-NOT-affect-operation requirement to the relevant sections where the term is referred to. Keep the UTF-8 requirement here. Consider replacing 5.5 "displayable message" with simply a reference to the OTP RFC format. > 3.4 Lower layer indications > > Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation MUST NOT conclude > that authentication has succeeded based on those indications. The last sentence has too many NOTs, I think. How about "However, lower layer success indications MUST NOT affect EAP message processing so that the EAP implementation would conclude ..." > 4.1 Request and Response > > Description > > The Request packet (Code field set to 1) is sent by the > authenticator to the peer. Each Request has a Type field which > serves to indicate what is being requested. Additional Request > packets MUST be sent until a valid Response packet is received, or > an optional retry counter expires. Retry counter? This seems to be the only place we talk about retry counters. Perhaps a timeout is assumed instead? If so, "..., or until a timeout expires." [BA] This section is trying to indicate that Requests are retransmitted until a maximum retry counter expires. The goal is not to give up just because a single retransmission attempt timed out. > 7.14. > > [a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=1 (Request) and Type=Method-Type. This > implies that methods supporting "strict interpretation" do not > utilize Notification, but instead support their own > method-specific error messages. Hmm... perhaps they don't use notification at all and just want to avoid getting them? Suggested rewrite: "... do not utilize Notification or support their own method-specific notification messages." > Where an authenticator operates as a pass-through, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP layer header fields (Code, Identifier, > Length). Since pass-through authenticators rely on a backend > authenticator server to implement methods, the EAP method layer > header fields (Type, Type-Data) are not examined as part of the > forwarding decision. The forwarding model is illustrated in Figure 2. > Compliant pass-through authenticator implementations MUST by default > be capable of forwarding packets from any EAP method. This specification is insufficient for me to implement a passthrough: it doesn't do some things per above, but what does it do then? I do realize that the proper specification depends on the AAA protocol translation for instance, so maybe we shouldn't expect to have a full specification here. Perhaps reference 2869bis? Or should we list the actions that the forwarding decision must make? From jari.arkko@piuha.net Mon May 12 20:20:53 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 12 May 2003 22:20:53 +0300 Subject: [eap] Proposed resolution to Issue 129: More NITs In-Reply-To: References: Message-ID: <3EBFF415.50307@piuha.net> Bernard Aboba wrote: > The text of Issue 129 is enclosed below. The proposed resolution is as > follows: > > Change the text in Section 5.5 from: > > "Displayable Message > This is interpreted to be a human readable string of > characters, and MUST NOT affect operation of the protocol. > The message encoding MUST follow the UTF-8 transformation > format [RFC2279]." > > To: > > Displayable Message > This is interpreted to be a human readable string of > characters. The message encoding MUST follow the > UTF-8 transformation format [RFC2279]. Ok (but that was in Section 1.2) And we need a change to Section 5.5, because that still refers to Displayable Message. In there, change "The Request contains a displayable message containing an OTP challenge." to "The Request contains an OTP challenge in the format described in [RFC2289].". > Change the text in Section 3.4 from: > > "Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation MUST NOT conclude > that authentication has succeeded based on those indications." > > To: > > "Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation cannot conclude > that authentication has succeeded based on those indications." Hmm... I still have trouble parsing it. Could be my problem, but did you mean "MUST NOT affect EAP message processing; an EAP implementation cannot conclude..."? > Change the text in Section 7.14 from: > > "[a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=1 (Request) and Type=Method-Type. This > implies that methods supporting "strict interpretation" do not > utilize Notification, but instead support their own > method-specific error messages." > > To: > > "[a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=1 (Request) and Type=Method-Type. This > implies that methods supporting "strict interpretation" do not > send or expect to receive Notification-Requests but instead support their > own method-specific error messages." Ok. > Change: > > "Where an authenticator operates as a pass-through, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP layer header fields (Code, Identifier, > Length). Since pass-through authenticators rely on a backend > authenticator server to implement methods, the EAP method layer > header fields (Type, Type-Data) are not examined as part of the > forwarding decision. The forwarding model is illustrated in Figure 2. > Compliant pass-through authenticator implementations MUST by default > be capable of forwarding packets from any EAP method." > > To: > > "Where an authenticator operates as a pass-through, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP layer header fields (Code, Identifier, > Length). This includes performing validity checks on the Code, Identifer > and Length fields, as described in Section 4.1. > > Since pass-through authenticators rely on a backend > authenticator server to implement methods, the EAP method layer > header fields (Type, Type-Data) are not examined as part of the > forwarding decision. The forwarding model is illustrated in Figure 2. > Compliant pass-through authenticator implementations MUST by default > be capable of forwarding packets from any EAP method. The use of > the RADIUS protocol for encapsulation of EAP in pass-through > operation is described in [RFC2869bis]." Very good, just what I was looking for. Thanks! --Jari From aboba@internaut.com Tue May 13 04:36:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 May 2003 20:36:09 -0700 (PDT) Subject: [eap] EAP WG last call summary: draft-ietf-eap-rfc2284bis-02.txt Message-ID: EAP WG last call on draft-ietf-eap-rfc2284bis-02.txt is drawing to a close. A summary of the issues raised is given below. Given the number of issues that were raised, we will be going to EAP WG last call again on the next version of the document, once the resolutions of the issues raised are resolved and a new version appears on the IETF archive. If you haven't read the document and commented, there are only a few hours remaining. Summary of issues raised in EAP WG last call for RFC 2284bis-02: Issue # Fixed Issue Description Issue 104 EAP-03 Sequence Prohibition Issue 108 EAP-03 Downgrade Attacks on Lower Layer Ciphersuite Negotiations Issue 109 EAP-03 Attacker or Adversary? Issue 110 EAP-03 Miscellaneous Nits Issue 111 EAP-03 Lower Layer Requirements Issue 112 EAP-03 Rewrite of IANA considerations Issue 113 EAP-03 Rewrite of Security Considerations Section Issue 114 EAP-03 Terminology fixes Issue 115 EAP-03 Multiplexing fixes Issue 116 EAP-03 Success and Failure cleanup Issue 117 EAP-03 Miscellaneous technical nits Issue 120 EAP-03 Passphrases in EAP Issue 121 Text Proposed Document meaning of successful authentication Issue 122 EAP-03 Clarification of LL requirements Issue 124 EAP-03 Identity Protection Issue 126 EAP-03 Miscellaneous NITs Issue 127 EAP-03 Security Terms Issue 128 EAP-03 Encapsulation Reference Issue 129 EAP-03 More NITs EAP issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From ltarkkal@ssh.com Tue May 13 06:50:43 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Tue, 13 May 2003 08:50:43 +0300 Subject: [eap] Issue XXX: Potential deadlock Message-ID: <20030513055043.GA3459@tehdas> Sorry about the late submission, but I have been buried in work. Potential Deadlock Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Document: Rfc2284bis Comment type: T Priority: S There exist a couple of deadlocks currently in the proposed EAP protocol as used in e.g. PPP. I do not recall it being discussed earlier. Assume we have two PPP peers (A and B) negotating LCP, and both desire to authenticate each other with EAP. A authenticates B with EAP and B authenticates A with EAP. Now assume that both EAP Success messages are "lost" after the authentication rounds are completed, and since both parties now have an EAP authentication pending, they will not start negotiating a NCP (e.g. IPCP) for the link. The system is effectively in deadlock. There are some solutions: 1) Require that Success messages are ACK'd. 2) Require authenticatee to retransmit last message untill it receives a final (Success/Failure) response from the client. Neither of these is backwards compatible. Currently the only sensible solution for a PPP implementation is to initiate an NCP when it "guesses" that an EAP client has completed (after a suitable timeout) to avoid the above deadlock. This is of course against the current recommendation of this WG, but that recommendation means very little if it causes a deadlock. Note that the lack of an explicit ACK of success means that it is difficult in this case to distinguish between "sequential authentication" where several methods are applied after each other and a dropped EAP-Success. I do not propose a fix in this submission, because this interplays with other issues currently under discussion, but I wanted a separate issue up on this, so it does not get forgotten. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From Pasi.Eronen@nokia.com Tue May 13 08:05:07 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 13 May 2003 10:05:07 +0300 Subject: [eap] RE: Proposed resolution to Issue 129: More NITs Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612228D@esebe023.ntc.nokia.com> Bernard Aboba wrote: > Change the text in Section 3.4 from: >=20 > "Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation MUST NOT conclude > that authentication has succeeded based on those indications." >=20 > To: >=20 > "Lower layer failure indications provided to EAP by the lower layer > MUST be processed and will cause an EAP exchange in progress to be > aborted. However, lower layer success indications MUST NOT affect EAP > message processing so that an EAP implementation cannot conclude > that authentication has succeeded based on those indications." Well, actually lower layer success indications could (or even should) be processed in some circumstances (when the peer would be willing to accept an EAP Success message). How about this? "If a peer receives a lower layer success indication when it would be willing to accept an EAP Success message, it MAY conclude that the Success message was lost, and behave as it had received a Success message. In all other circumstances, lower layer success indications MUST NOT affect EAP message processing." (Or should that MAY be a SHOULD?) > Change the text in Section 7.14 from: >=20 > "[a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=3D1 (Request) and Type=3DMethod-Type. This > implies that methods supporting "strict interpretation" do not > utilize Notification, but instead support their own > method-specific error messages." >=20 > To: >=20 > "[a] On the peer, all EAP packets MUST be silently discarded, except > for those with Code=3D1 (Request) and Type=3DMethod-Type. This > implies that methods supporting "strict interpretation" do not > send or expect to receive Notification-Requests but instead=20 > support their > own method-specific error messages." Actually, I think we don't need Section 7.14 anymore. The "strict interpretation" was very useful when it was possible to switch from one method to another (and it was possible that successful authorization result would require more than one successful EAP method). Now sequences are forbidden, and the "usual" ("non-strict") processing rules specify the same behavior. E.g. 2.1 says that the peer must silently discard requests for other types, and 4.2 deals with Success/Failure. The only thing left is Notifications. I think this could be dealt in Section 5.2 by adding the following after the first paragraph. "An EAP method MAY indicate within its specification that Notification messages must not be sent during that method.=20 In this case, the peer MUST silently discard Notification Requests from the point where an initial Request for=20 that Type is answered with a Response of the same Type." (and by removing 7.14) Best regards, Pasi From Pasi.Eronen@nokia.com Tue May 13 08:44:17 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 13 May 2003 10:44:17 +0300 Subject: [eap] RE: Issue XXX: Potential deadlock Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612228E@esebe023.ntc.nokia.com> Lauri Tarkkala wrote: > Assume we have two PPP peers (A and B) negotating LCP, and both > desire to authenticate each other with EAP. A authenticates B > with EAP and B authenticates A with EAP. >=20 > Now assume that both EAP Success messages are "lost" after the > authentication rounds are completed, and since both parties > now have an EAP authentication pending, they will not > start negotiating a NCP (e.g. IPCP) for the link. The > system is effectively in deadlock. I think this situation is not any different from the one-way case. 2284bis already mentions that Success and Failure packets are not acknowledged, and thus timeouts are possible if the link has high error rate. Consider a single EAP conversation where the Success packet is lost. This results in a timeout for the peer. If the peer is happy with the overall situation (e.g. it would enable the link if it received a Success packet), it may enable the link anyway (initiate NCP in case of PPP). In case of two simultaneous EAP conversations, the PPP connection will succeed if both parties follow this behavior. Also, the party that has longer timeout may consider=20 a NCP packet as "lower layer success indication", and process=20 it appropriately (if we allow lower layer success indications,=20 as I proposed in my previous message). (The EAP implementations are not in a true deadlock, because on both parties, one of the EAP conversations has already ended, and the conversation instance that is "dangling" is=20 not waiting for anything from the other "dangling" instance). Best regards, Pasi From jari.arkko@piuha.net Tue May 13 08:49:05 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 13 May 2003 10:49:05 +0300 Subject: [eap] RE: Issue XXX: Potential deadlock In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612228E@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612228E@esebe023.ntc.nokia.com> Message-ID: <3EC0A371.1070102@piuha.net> Pasi.Eronen@nokia.com wrote: > I think this situation is not any different from the one-way > case. 2284bis already mentions that Success and Failure packets > are not acknowledged, and thus timeouts are possible if the link > has high error rate. ... > (The EAP implementations are not in a true deadlock, because > on both parties, one of the EAP conversations has already > ended, and the conversation instance that is "dangling" is > not waiting for anything from the other "dangling" instance). Yes, I think that is right. Lauri Tarkkala wrote: > Note that the lack of an explicit ACK of success means that > it is difficult in this case to distinguish between > "sequential authentication" where several methods are > applied after each other and a dropped EAP-Success. That's right, but we've discouraged the use of sequences. So I don't think this is an issue. --Jari From ltarkkal@ssh.com Tue May 13 08:43:47 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Tue, 13 May 2003 10:43:47 +0300 Subject: [eap] RE: Issue XXX: Potential deadlock In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612228E@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612228E@esebe023.ntc.nokia.com> Message-ID: <20030513074347.GA4643@tehdas> On Tue, May 13, 2003 at 10:44:17AM +0300, Pasi.Eronen@nokia.com wrote: > I think this situation is not any different from the one-way > case. 2284bis already mentions that Success and Failure packets > are not acknowledged, and thus timeouts are possible if the link > has high error rate. Ok. We have a different opinion under what circumstances the protocol run should succeed. Please note that PPP (LCP, NCP, CHAP, etc) can easily succeed in conditions where a couple of packets are lost, even in the absence of "lower layer indications". The case is not that different from the one-way case, as you suggest. I used the term "dead-lock" quite loosely, as you pointed out. The system will recover with a timeout, and terminate the link and possible re-try authentication, but this is essentially a reset and re-run of the protocol (with some additional headache for the user). > Consider a single EAP conversation where the Success packet is > lost. This results in a timeout for the peer. If the peer is > happy with the overall situation (e.g. it would enable the link > if it received a Success packet), it may enable the link anyway > (initiate NCP in case of PPP). > In case of two simultaneous EAP conversations, the PPP > connection will succeed if both parties follow this > behavior. Also, the party that has longer timeout may consider Indeed. Assuming both implementations are good and have been written by people who have at least some understanding of concurrent systems. You'd be surprised at the quality of EAP/PPP implementations in wide use today. Please remember, that an EAP implementation written according to the "improved" specs, must interoperate with the implementations written according to the "classic" specs, and in this case, the sane behaviour is to consider the "send of the last response" by the authenticatee to the EAP authenticator to be the "lower layer indication". > a NCP packet as "lower layer success indication", and process > it appropriately (if we allow lower layer success indications, > as I proposed in my previous message). "Lower layer success indications" are what currently any decent EAP/PPP implementation uses to determine authentication success, what this "success indication" is, may then differ. What this does however, is build a dependency into the EAP protocol that "reliable half-duplex lower layer success indications" should be used in some cases. i This is a behaviour I'd like to live without, but I can accept as "historical baggage". Anyways, their use must be specified, like Assuming that the WG now feels that lower layer indications should be considered here, I propose the following changes: Add to section 3.1 [6] If EAP is used authenticate the peers communicating over a lower layer that does not provide reliable transport then because of the unreliable EAP-Success/EAP-Failure messages: - If the lower layer provides an indication mechanism that the authenticator has accepted the authenticatee then this SHOULD be used to complement the EAP-Success message, and the authenticatee MUST consider this indication as equivalent to an EAP-Success message. Note that both peers might be authenticating each other with EAP. - If the lower layer does not provide a sufficiently reliable indication mechanism, then the authenticatee should consider a suitable timeout (e.g. 2*RTT of link) after the last sent EAP message to be equivalent to an EAP-Success and rely on other used protocols for indications of link failure. Add to section 3.4 If an unreliable transmission medium is used, s.t. delivery of the EAP-Success packet is not guaranteed under reasonable assumptions of link quality AND link layer mechanisms exist for indicating that the authenticator has decided that protocol can proceed past the authentication phase THEN these mechanisms MUST be used to signal that authentication has succeeded. See point [6] in Section 3.1. Note that this does not define the lower-layer mechanism to be used, in case it is ambiguous and the term "lower-layer" is even a bit mis-leading. E.g. in the case of PPP/EAP there is really no "lower-layer mechanism", but a willingess to initiate or respond to NCP negotiations is considered an "indication of authentication success". The term "lower layer indication" is a bit mis-leading, but the above changes fit best into the -02 draft. This will mean that if future EAP/PPP implementations are written to wait for "link layer indication" before proceeding, then they may in some link conditions fail to interopate. I can certainly live with this. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From aboba@internaut.com Tue May 13 13:51:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 13 May 2003 05:51:15 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 132: Accept Message-ID: The text of Issue 132 is given below. This was extracted from one of Pasi's comments on Issue 129. I would like to recommend that the changes proposed in Issue 132 be accepted. Any objections? ---------------------------------------------------------- Issue 132: Redundancy of Section 7.14 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 13, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 7.14 Rationale/Explanation of issue: I think we don't need Section 7.14 anymore. The "strict interpretation" was very useful when it was possible to switch from one method to another (and it was possible that successful authorization result would require more than one successful EAP method). Now sequences are forbidden, and the "usual" ("non-strict") processing rules specify the same behavior. E.g. 2.1 says that the peer must silently discard requests for other types, and 4.2 deals with Success/Failure. The only thing left is Notifications. I think this could be dealt with in Section 5.2 by adding the following after the first paragraph. "An EAP method MAY indicate within its specification that Notification messages must not be sent during that method. In this case, the peer MUST silently discard Notification Requests from the point where an initial Request for that Type is answered with a Response of the same Type." (and by removing 7.14) From aboba@internaut.com Tue May 13 13:53:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 13 May 2003 05:53:49 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 130: Reject Message-ID: The text of Issue 130 (and subsequent discussion) is given below. It appears that there is no true deadlock and so I would recommend that this issue be rejected. Any objections? -------------------------------------------------------- Issue 130: Potential Deadlock Submitter name: Lauri Tarkkala Submitter email address: ltarkkal@ssh.com Date first submitted: May 13, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: There exist a couple of deadlocks currently in the proposed EAP protocol as used in e.g. PPP. I do not recall it being discussed earlier. Assume we have two PPP peers (A and B) negotating LCP, and both desire to authenticate each other with EAP. A authenticates B with EAP and B authenticates A with EAP. Now assume that both EAP Success messages are "lost" after the authentication rounds are completed, and since both parties now have an EAP authentication pending, they will not start negotiating a NCP (e.g. IPCP) for the link. The system is effectively in deadlock. There are some solutions: 1) Require that Success messages are ACK'd. 2) Require authenticatee to retransmit last message untill it receives a final (Success/Failure) response from the client. Neither of these is backwards compatible. Currently the only sensible solution for a PPP implementation is to initiate an NCP when it "guesses" that an EAP client has completed (after a suitable timeout) to avoid the above deadlock. This is of course against the current recommendation of this WG, but that recommendation means very little if it causes a deadlock. Note that the lack of an explicit ACK of success means that it is difficult in this case to distinguish between "sequential authentication" where several methods are applied after each other and a dropped EAP-Success. I do not propose a fix in this submission, because this interplays with other issues currently under discussion, but I wanted a separate issue up on this, so it does not get forgotten. Lauri [Pasi Eronen]: Lauri Tarkkala wrote: > Assume we have two PPP peers (A and B) negotating LCP, and both > desire to authenticate each other with EAP. A authenticates B > with EAP and B authenticates A with EAP. > > Now assume that both EAP Success messages are "lost" after the > authentication rounds are completed, and since both parties > now have an EAP authentication pending, they will not > start negotiating a NCP (e.g. IPCP) for the link. The > system is effectively in deadlock. I think this situation is not any different from the one-way case. 2284bis already mentions that Success and Failure packets are not acknowledged, and thus timeouts are possible if the link has high error rate. Consider a single EAP conversation where the Success packet is lost. This results in a timeout for the peer. If the peer is happy with the overall situation (e.g. it would enable the link if it received a Success packet), it may enable the link anyway (initiate NCP in case of PPP). In case of two simultaneous EAP conversations, the PPP connection will succeed if both parties follow this behavior. Also, the party that has longer timeout may consider a NCP packet as "lower layer success indication", and process it appropriately (if we allow lower layer success indications, as I proposed in my previous message). (The EAP implementations are not in a true deadlock, because on both parties, one of the EAP conversations has already ended, and the conversation instance that is "dangling" is not waiting for anything from the other "dangling" instance). [Jari Arkko]: Pasi.Eronen@nokia.com wrote: > I think this situation is not any different from the one-way > case. 2284bis already mentions that Success and Failure packets > are not acknowledged, and thus timeouts are possible if the link > has high error rate. ... > (The EAP implementations are not in a true deadlock, because > on both parties, one of the EAP conversations has already > ended, and the conversation instance that is "dangling" is > not waiting for anything from the other "dangling" instance). Yes, I think that is right. Lauri Tarkkala wrote: > Note that the lack of an explicit ACK of success means that > it is difficult in this case to distinguish between > "sequential authentication" where several methods are > applied after each other and a dropped EAP-Success. That's right, but we've discouraged the use of sequences. So I don't think this is an issue. From aboba@internaut.com Tue May 13 14:02:08 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 13 May 2003 06:02:08 -0700 (PDT) Subject: [eap] Re: Issue 131: Lower Layer Success Indications Message-ID: The question is in what circumstances a peer is willing to accept a Success message. I think that includes any one-way method after completion of the method; and any mutually authenticating method after the peer has authenticated the authenticator. However, we're already covering the latter case in Section 4.2. So the question is whether we want to make this change purely to benefit one-way methods. The problem is that the implementation survey disclosed that none of the implementations surveyed implemented lower layer success indications as described in RFC 2284. Unless we've got implementations that are willing to do this, I'm not sure that it makes a difference. ----------------------------------------------------------- Issue 131: Lower layer success indications Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 13, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 3.4 Rationale/Explanation of issue: Lower layer success indications could (or even should) be processed in some circumstances (when the peer would be willing to accept an EAP Success message). In Section 3.4, Change: "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, lower layer success indications MUST NOT affect EAP message processing so that an EAP implementation MUST NOT conclude that authentication has succeeded based on those indications." To: "If a peer receives a lower layer success indication when it would be willing to accept an EAP Success message, it MAY conclude that the Success message was lost, and behave as it had received a Success message. In all other circumstances, lower layer success indications MUST NOT affect EAP message processing." (Or should that MAY be a SHOULD?) From yohba@tari.toshiba.com Tue May 13 13:56:15 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 13 May 2003 08:56:15 -0400 Subject: [eap] Proposed Resolution of Issue 132: Accept In-Reply-To: References: Message-ID: <20030513125615.GB1018@catfish> On Tue, May 13, 2003 at 05:51:15AM -0700, Bernard Aboba wrote: > The text of Issue 132 is given below. This was extracted from one of > Pasi's comments on Issue 129. > > I would like to recommend that the changes proposed in Issue 132 be > accepted. Any objections? > > ---------------------------------------------------------- > Issue 132: Redundancy of Section 7.14 > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: May 13, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 7.14 > Rationale/Explanation of issue: > > I think we don't need Section 7.14 anymore. The > "strict interpretation" was very useful when it was possible > to switch from one method to another (and it was possible that > successful authorization result would require more than one > successful EAP method). > > Now sequences are forbidden, and the "usual" ("non-strict") > processing rules specify the same behavior. E.g. 2.1 says that > the peer must silently discard requests for other types, and 4.2 > deals with Success/Failure. > > The only thing left is Notifications. I think this could be > dealt with in Section 5.2 by adding the following after the first > paragraph. > > "An EAP method MAY indicate within its specification that > Notification messages must not be sent during that method. > In this case, the peer MUST silently discard Notification > Requests from the point where an initial Request for > that Type is answered with a Response of the same Type." I think this additional text would require a change in section 5.2 from: "The peer MUST respond to a Notification Request with a Notification Response; a Nak Response MUST NOT be sent." To: "The peer MUST respond to a Notification Request with a Notification Response unless the EAP authentication method specification prohibits the use of Notification message. In any case, a Nak Response MUST NOT be sent in response to a Notification Request." BTW, it is not clear to me whether RFC2284bis prohibits Notification between methods or not __when methods are running inside a tunneling method__. Yoshihiro Ohba > > (and by removing 7.14) > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Tue May 13 17:32:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 13 May 2003 09:32:05 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 132: Accept In-Reply-To: <20030513125615.GB1018@catfish> References: <20030513125615.GB1018@catfish> Message-ID: > BTW, it is not clear to me whether RFC2284bis prohibits Notification > between methods or not __when methods are running inside a tunneling > method__. I think that's up to the tunneling method to define. From jari.arkko@piuha.net Wed May 14 11:36:36 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 13:36:36 +0300 Subject: [eap] new state machine document and issue #98 Message-ID: <3EC21C34.5050407@piuha.net> Thank you for the new state machine document! This version (-02) is much better than the previous one. I still have some comments, though, and I will send them as my review of the document progresses. The first comment is that I checked issue #98 that I filed earlier on the -01 document: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2098 It seems to be handled, but there's a few details left that should perhaps be fixed: - Delete the paragraph from the abstract that starts with "This document is still a work in progress." Sure it is, all I-Ds are and we'd have to remove the statement anyway at some point... - The text and the state machine pictures are inconsistent in the capitalization of the ELSE label. Sometimes "ELSE", sometimes "else". - I still didn't find any statement that would clarify the role of the state machine transitions vs. MAY/SHOULD/MUST requirements in 2284bis. I *think* your intention is that any transition-like requirements end up as transitions in your document, regardless of the strength of the keyword possible associated with it in some other document. Suggested text to add in 3.2 or other appropriate place: "This document specifies the possible transitions and actions for EAP peers, authenticators, and pass-through authenticators. It does not attempt to characterize the RFC 2119 requirement levels (MAY, SHOULD, MUST, and so on) of these transitions." - The "methodState = { SUCC | CON_SUCC | ... }" notation has not been explained. - In the text: "Next, the method must decide whether to process the packet or silently discard it. If the packet looks like it wasn't sent by the legitimate authenticator (e.g. it has invalid MIC, and this case should never occur), the method can set intCheck=FALSE. In this case, the method must not modify methodState, and it should not modify its own method-specific state." It is not 100% clear that MICs are optional. Suggested rewrite: "Next, the method must decide whether to process the packet or silently discard it. Some methods may use MIC values in the messages to ensure that the messages have been sent by the legitimate authenticator. If the method can perform such a check, and finds that the MIC is invalid, it sets intCheck to FALSE. In this case, the method must not modify methodState, and it should not modify its own method-specific state." --Jari From jari.arkko@piuha.net Wed May 14 12:21:05 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 14:21:05 +0300 Subject: [eap] sm-02 nits Message-ID: <3EC226A1.1010205@piuha.net> 1. Abstract is too long, appears to be more of an introduction than a brief abstract. Suggested rewrite: "This document describes informational state machines for the participants in the Extensible Authentication Protocol (EAP). State machines are given for the EAP peers and authenticators, the passthrough method, and for the backend adapter. The state machine for the EAP authenticator can operate with local authentication or through a backend authentication server connected via an Authentication, Authorization, and Accounting (AAA) protocol. The state machines have been described using the EAP multiplexing model, which divides the events and actions to those handled by the EAP multiplexer and those handled by the EAP methods." 2. Isn't it customary to expand abbreviations in the title? Perhaps this document could be called "State Machines for the Extensible Authentication Protocol (EAP)"? 3. Can we synchronize the figures in Section 2.2 of RFC 2284bis-03, and Section 2 of the SM draft? At the same time, it might make sense to call Section 2 "Introduction", and treat the above additional subjects: - Document authority (take text from 3.2) Also, it might make sense to combine the format text in the first and last paragraphs of section 2 in one place. 4. In 3.2, perhaps replace the last sentence with "If there are any discrepancies between this document and [RFC2284bis], [RFC2869bis], the latter two take precedence." 5. In 4.2, perhaps the notation in "IN: eapReqData, (reqId)" could be clarified. I suppose the paranthesis mean optional or out-of-scope information? Or do they mean parameters to a function? 6. Spelling: Passtrhough, peerto. 7. References to be split to normative and non-normative. For this document, I believe the normative ones are 2119, 2284bis, and 2869bis. IEEE documents are non-normative. 8. It might make sense to refer to just 2284bis, not 2284. --Jari From jari.arkko@piuha.net Wed May 14 12:53:12 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 14:53:12 +0300 Subject: [eap] sm-02 authenticator timeout failure issue Message-ID: <3EC22E28.3030403@piuha.net> 2284bis-03.f: The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation. sm-02 authenticator: From the figure we can see that when aWhile goes to zero, you will go to RETRANSMIT, possibly retransmit a few times, and eventually go to FAILURE, and set eapReqData. I have three issues with the above: 1) 2284bis could be clearer, imho, that even after a number of timeouts you don't send a Failure. Suggested rewrite: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." 2) The FAILURE state constructs a Failure response, but 2284bis forbids this to be sent when the failure is due to a timeout (I think). 3) You could say perhaps that the Failure response is not really sent, and is only internally constructed, because eapReq is not set. However, if this is true then FAILURE and SUCCESS states both have an issue when used in other cases: they don't set eapReq either. Suggested fix: set eapReq in FAILURE and SUCCESS. Provide a different state for timeout-based failures, which does nothing. --Jari From jari.arkko@piuha.net Wed May 14 13:24:54 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 15:24:54 +0300 Subject: [eap] Length too large Message-ID: <3EC23596.5070905@piuha.net> The description of the Length field is as follows: The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. What happens if the Length field indicates a length greater than the received number of octets? Perhaps this should also be specified: A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Also, perhaps change "should be ignored" to "MUST be ignored". --Jari From Pasi.Eronen@nokia.com Wed May 14 13:44:50 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 14 May 2003 15:44:50 +0300 Subject: [eap] sm-02 authenticator timeout failure issue Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122291@esebe023.ntc.nokia.com> Hi, This issue was listed in Appendix A of sm-02 draft=20 as a "known inconsistency" between 2284bis and SM (the Failure response is actually sent although eapReq is not set; see Section 5.1 of sm-02 draft). Here's an updated diagram that fixes this, and also attempts to show how timeouts are calculated=20 (changes to -02 version are shown in blue). http://www.cs.hut.fi/~peronen/eap/eap_authenticator_14052003.png (Does the handling of timeouts look ok? The idea is that=20 if a method has some idea what the timeout should be, it=20 sets methodTimeout. eapRttEstimate comes from the lower layer) Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, May 14, 2003 2:53 PM > To: eap@frascone.com > Subject: [eap] sm-02 authenticator timeout failure issue >=20 >=20 >=20 > 2284bis-03.f: >=20 > The authenticator MUST NOT send a Success or Failure packet as a > result of a timeout. After a suitable number of timeouts have > elapsed, the authenticator SHOULD end the EAP conversation. >=20 > sm-02 authenticator: >=20 > From the figure we can see that when aWhile goes to zero, > you will go to RETRANSMIT, possibly retransmit a few times, > and eventually go to FAILURE, and set eapReqData. >=20 > I have three issues with the above: >=20 > 1) 2284bis could be clearer, imho, that even after a number > of timeouts you don't send a Failure. Suggested rewrite: > "The authenticator is responsible for retransmitting requests > as described in Section 4.1. After a suitable number of > retransmissions, the authenticator SHOULD end the EAP > conversation. The authenticator MUST NOT send a Success > or Failure packet when retransmitting or when it fails > to get a response from the peer." >=20 > 2) The FAILURE state constructs a Failure response, > but 2284bis forbids this to be sent when the > failure is due to a timeout (I think). >=20 > 3) You could say perhaps that the Failure response > is not really sent, and is only internally > constructed, because eapReq is not set. However, > if this is true then FAILURE and SUCCESS states > both have an issue when used in other cases: > they don't set eapReq either. >=20 > Suggested fix: set eapReq in FAILURE and SUCCESS. > Provide a different state for timeout-based > failures, which does nothing. >=20 > --Jari From jari.arkko@piuha.net Wed May 14 13:50:21 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 15:50:21 +0300 Subject: [eap] open issues list in the sm-02 document Message-ID: <3EC23B8D.9010301@piuha.net> > o 2284bis: "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. " Issue: Seems like the peer should > be able to send as many responses as it gets requests for the same > id. It may not send a response for prior id after it has sent a > response to current id. This is how the state machine works, and > hopefully the wording in 2284bis will be modified to match. I agree. > o What to do if we get a timeout, Policy.isSatisfied() is TRUE, but > methodState is not CON_ACC? Issue: can peer go into authenticated > state without getting a Success -either internal to the method > (Con_ACC) or and EAP Success? IMHO, no. (But perhaps you have discussed this as a part of the Success thread; I didn't check.) > o What to do if we get an altAccept, Policy.isSatisfied() is TRUE, > but methodState is not CON_ACC? Issue: same as above As above. > o Do we need a new variable to signal the lower layer that keying > material is available (in eapKey), or is it enough that the lower > layer checks if eapKey!=NONE after getting eapSuccess? I think it may be more readable to just use one variable. --Jari From jari.arkko@piuha.net Wed May 14 14:29:14 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 14 May 2003 16:29:14 +0300 Subject: [eap] mapping between the state machine and 2284bis Message-ID: <3EC244AA.8080801@piuha.net> Hi, I'm trying to go through and check the state machine against the 2284bis document, to see if they are consistent and that neither one lacks anything. Below I'll treat each individual state in the peer state machine and discuss whether the corresponding funtionality exists in 2284bis. The summary is that there specifications are pretty well in sync, but a few issues may need to be worked on. DISABLED: OK -- not covered in 2284bis INITIALIZE: OK -- more detail in sm - I think this is inline with Section 2.1, though 2284bis does not explicitly talk about this DISCARD: OK (with a nit) -- 2284bis has more detail - Section 4 has a silent discard for other Code values - I also recently sent e-mail about whether Length >= received PDU should cause a silent discard. This too might be something that parseEapReq does, though it isn't specified in detail. - Perhaps there should be a "logEvent" call, as is required in 2284bis in the silent discard definition? RETRANSMIT: OK (but one open issue) -- same level of detail - Section 4: If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response. - But note the open issue listed in the sm document about multiple responses to the same retransmitted request while waiting for user input NOTIFICATION: OK -- same level of detail - I think the state machine is in line with Section 2.1 SEND_RESPONSE: OK -- this is just an abstraction in the sm GET_METHOD: NOT OK -- same level of detail, one nit and one problem - Incoming arrow valid according to Section 2.1 and Section 4 - First if branch valid according to Section 2.1 - Second if branch valid, but note that it would be imho clearer if setting the methodState to NORMAL in METHOD would also result in setting currentMethod to NONE. Then we could remove "resetCurrentMethod"? On the other hand, you appear to rely on currentMethod to stay intact for forbidding sequences... right? - The third if branch appears unclear or perhaps incorrect. Section 2.1: "A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an an authenticator receiving an unexpected Nak SHOULD silently discard it and log the event." And here we send a Nak (even if we were in the middle of another method). The spec talks about it being invalid for the authenticator to send other types while already doing one authentication method. We also talk about the strict mode, where such requests would be silently discarded. But I didn't find a place that says what we should do outside the strict mode for such requests. So should we respond with a Nak, as the sm does? Or silent discard? If silent discard, we need to split the third if branch into two, one dealing with currentmethod = NONE and one with the other case. METHOD: NOT OK -- one nit and one small error - Aligned with A.1 in general, but: - Perhaps there should be a call to logEvent, to show the SHOULD requirement in A.1? - A.1 allows MIC failure to be a fatal error. This does not appear to be handled by the sm. The following MUST requirement from 2284bis don't appear to be handled: Nak (Type 3) or Expanded Nak (Type 254) are valid only for Response packets, they MUST NOT be sent in a Request. (I'm assuming this can be interpreted on the peer side as silent discard...) I didn't look at FAILURE and SUCCESS, because alternative indications were being discussed on the list. Also, the other state machines remain to be checked... --Jari From Pasi.Eronen@nokia.com Wed May 14 15:11:43 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 14 May 2003 17:11:43 +0300 Subject: [eap] RE: mapping between the state machine and 2284bis Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BAFA@esebe023.ntc.nokia.com> Jari, Big thanks for reviewing the state machine document!=20 We've spent so much time on those diagrams what we're=20 probably blind to any problems in it by now :-) > DISCARD: OK (with a nit) -- 2284bis has more detail > - Section 4 has a silent discard for other Code values > - I also recently sent e-mail about whether Length >=3D > received PDU should > cause a silent discard. This too might be something > that parseEapReq does, though it isn't specified in > detail. Yes, parseEapReq is supposed to do this: if the PDU has=20 invalid length or code, it doesn't set rxReq (which results=20 in silenty discard). > - Perhaps there should be a "logEvent" call, as is > required in 2284bis in the silent discard definition? We discussed this, but decided not to show any logging calls here. Real implementations will probably log many events not explicitly mentioned for logging in 2284bis (such as success=20 and failure!), and logging does not change the behavior of the change machine. (For the same reason, we didn't include any "statistics" variables that would not change the operation of the state machine, but could be interesting to show in some authenticator management interface) > GET_METHOD: NOT OK -- same level of detail, one nit and one problem > - Incoming arrow valid according to Section 2.1 and Section 4 > - First if branch valid according to Section 2.1 > - Second if branch valid, but note that it would be imho > clearer if setting the methodState to NORMAL in METHOD > would also result in setting currentMethod to NONE. > Then we could remove "resetCurrentMethod"? On the other > hand, you appear to rely on currentMethod to stay intact > for forbidding sequences... right? There's a new version of the peer diagram that has simplified this state and METHOD state considerably. You may want to review that one instead (although we don't have yet the explanatory text for it). It's available at: http://www.cs.hut.fi/~peronen/eap/eap_peer_13052003.png Regarding your question: Setting methodState to NORMAL can't reset currentMethod, because NORMAL is used for two different purposes: when the method has ended, and when the method can either continue or end (this is one of the things handled differently in 13052003 version). > - The third if branch appears unclear or perhaps incorrect. Section = 2.1: > "A peer MUST NOT send a Nak (legacy or expanded) in reply to a > Request, after an initial non-Nak Response has been sent. Since > spoofed EAP Request packets may be sent by an attacker, an an > authenticator receiving an unexpected Nak SHOULD silently discard > it and log the event." > > And here we send a Nak (even if we were in the middle of > another method). The spec talks about it being invalid for > the authenticator to send other types while already doing > one authentication method. We also talk about the strict > mode, where such requests would be silently discarded. > But I didn't find a place that says what we should do > outside the strict mode for such requests. So should we > respond with a Nak, as the sm does? Or silent discard? > If silent discard, we need to split the third if branch > into two, one dealing with currentmethod =3D NONE and > one with the other case. Again, this is handled quite differently in 13052003 version, but the basic principle is correct in sm-02 version as well: the third branch (that sends the Nak) is reached only if currentMethod is NONE or IDENTITY (assuming we're not inside a tunnel, something removed in 13052003 version completely).=20 So we are not in the middle of a method, and haven't sent any responses for Types >=3D4 yet. > METHOD: NOT OK -- one nit and one small error > - Aligned with A.1 in general, but: > - Perhaps there should be a call to logEvent, to show the > SHOULD requirement in A.1? > - A.1 allows MIC failure to be a fatal error. This does > not appear to be handled by the sm. As an unintended consequence of other changes, the last=20 item seems to be better handled in 13052003 version :-) Best regards, Pasi From aboba@internaut.com Wed May 14 18:36:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 14 May 2003 10:36:45 -0700 (PDT) Subject: [eap] Notes from the 5/14/03 EAP Design Conference call (fwd) Message-ID: -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Wednesday, May 14, 2003 9:24 AM To: gwz@cisco.com; npetroni@cs.umd.edu; yohba@tari.toshiba.com; henrik@levkowetz.com; Bernard Aboba (I hope I didn't forget too many people from the participant list, or too much issues from these notes :-) EAP Conference call May 14, 2003 -------------------------------- At least: Glen, Nick, Bernard, Yoshihiro, Henrik, Pasi Wow, what an echo! ...echo! ...echo.. Issues 121 and 131 ------------------ While nobody currently implements lower layer indications, they could be useful in some circumstances to avoid long timeouts. However, we want to avoid the situation where the peer enables the link but the authenticator does not. Thus, I think the agreement was roughly: - The peer may process lower layer success indications if it would be willing to accept an EAP Success packet at that point. - If the peer has not received a method-specific success message OR a lower layer success indication, if it times out when waiting for Success, it does not enable the link (even if it has authenticated the authenticator). - We need some text describing the limitations of lower layer indications. E.g. depending on the link layer, they may get lost; and they should not have naturally occuring "false positives". These lower layer indications could be less well protected than EAP Success, but it seems that an attacker who spoofs a lower layer indication can't actually achieve anything, because at that point the peer is anyway satisfied (e.g. has authenticated the authenticator, if using a mutually authenticating method). And if the environment contains active attackers, we are presumably deriving keys anyway. In 802.*, EAPOL-Key message is sort-of lower layer success indication (since the server would not send it unless it had succeeded). Certainly after the four-way handshake is concluded, you know that you received access. We also discussed if Finished message in EAP-TLS is a method-specific success message. Each method can define whatever it wants, but in this case it probably is: since the peer's last response does not contain anything useful, the authenticator can make its decision before sending Finished (and if the decision is no, send Alert). Issue 125 --------- TCP retransmission timers may not be appropriate for our purpose (RADIUS server load is probably more important than network congestion in our case). What should the default be? How about random jitter? Will be discussed in the mailing list. This might also be a RADIUS problem. Glen will send some comments to IESG, since 2869bis is in last call? State machine ------------- State machine should be ready for Vienna. Best regards, Pasi From jrv@umich.edu Wed May 14 02:18:51 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 13 May 2003 21:18:51 -0400 Subject: [eap] tommorrow meeting In-Reply-To: References: Message-ID: <2127032.1052860731@localhost> I am not able to join the conversation tomorrow. I am having a medical problem this week - hopefully I will be better by Thursday and getting email. I am pretty happy with 2284 and 2869 bis and with the stqte machine. I have one major concern with both 2284bis and with the state machine - and that is that tunnelled methods will not be able to do sequences of methods. Another concern is that the keying material information be taken from 2284 and put in its own section, if possible. I think keying is not always necessqry so putting it in its own section is important. Sorry I can't join you tomorrow -- John --On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba wrote: > > I think the problem is not with EAP, or AAA. The problem is with the EAP > > lower layers, such as PPP and 802.1X. If they had a way to carry > > authorization results, this problem wouldn't exist. In PANA, we carry > > PANA result so this wouldn't be a problem. > > 802.1X considered, and rejected the carriage of authorization results. It > was simpler to just recommend that the AAA result and EAP results agree. > > > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we > > are discovering that (1) and (2) must agree too. > > This is not a "discovery" -- it is an implication of the proposed state > machine. > > > So, when an authentication > > method succeeds, but authorization fails, should the authenticatin > > server go back and flip the authentication method to "failed" so that > > the results are all aligned? > > If the authentication method supports an authorization failure error > message, it can send that and there is no problem. Alternatively, the AAA > server can send a Reject/EAP Failure. If this does not agree with the EAP > method, which completed successfully, then the peer may silently discard > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > layer failure indication such as an LCP-Terminate or 802.11 > Deauthenticate/Disassociate. > > Why doesn't this address the problem? > > > We could make (1) and (2) the same, and keep (3) independent. But the > > problem is there is no equivalent of (3) for the last hop when PPP or > > 802.1X is used. > > That seems needlessly complex -- given that our goal is to improve > interoperability. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Wed May 14 02:41:09 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 13 May 2003 21:41:09 -0400 Subject: [eap] tommorrow meeting In-Reply-To: References: Message-ID: <2174662.1052862069@[10.0.1.2]> I am not able to join the conversation tomorrow. I am having a medical problem this week - hopefully I will be better by Thursday and getting email. I am pretty happy with 2284 and 2869 bis and with the stqte machine. I have one major concern with both 2284bis and with the state machine - and that is that tunnelled methods will not be able to do sequences of methods. Another concern is that the keying material information be taken from 2284 and put in its own section, if possible. I think keying is not always necessqry so putting it in its own section is important. Sorry I can't join you tomorrow -- John --On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba wrote: > > I think the problem is not with EAP, or AAA. The problem is with the EAP > > lower layers, such as PPP and 802.1X. If they had a way to carry > > authorization results, this problem wouldn't exist. In PANA, we carry > > PANA result so this wouldn't be a problem. > > 802.1X considered, and rejected the carriage of authorization results. It > was simpler to just recommend that the AAA result and EAP results agree. > > > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we > > are discovering that (1) and (2) must agree too. > > This is not a "discovery" -- it is an implication of the proposed state > machine. > > > So, when an authentication > > method succeeds, but authorization fails, should the authenticatin > > server go back and flip the authentication method to "failed" so that > > the results are all aligned? > > If the authentication method supports an authorization failure error > message, it can send that and there is no problem. Alternatively, the AAA > server can send a Reject/EAP Failure. If this does not agree with the EAP > method, which completed successfully, then the peer may silently discard > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > layer failure indication such as an LCP-Terminate or 802.11 > Deauthenticate/Disassociate. > > Why doesn't this address the problem? > > > We could make (1) and (2) the same, and keep (3) independent. But the > > problem is there is no equivalent of (3) for the last hop when PPP or > > 802.1X is used. > > That seems needlessly complex -- given that our goal is to improve > interoperability. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Wed May 14 02:48:43 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 13 May 2003 21:48:43 -0400 Subject: [eap] tommorrow meeting Message-ID: <2201889.1052862523@[10.0.1.2]> I am not able to join the conversation tomorrow. I am having a medical problem this week - hopefully I will be better by Thursday and getting email. I am pretty happy with 2284 and 2869 bis and with the stqte machine. I have one major concern with both 2284bis and with the state machine - and that is that tunnelled methods will not be able to do sequences of methods. Another concern is that the keying material information be taken from 2284 and put in its own section, if possible. I think keying is not always necessqry so putting it in its own section is important. Sorry I can't join you tomorrow -- John --On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba wrote: > > I think the problem is not with EAP, or AAA. The problem is with the EAP > > lower layers, such as PPP and 802.1X. If they had a way to carry > > authorization results, this problem wouldn't exist. In PANA, we carry > > PANA result so this wouldn't be a problem. > > 802.1X considered, and rejected the carriage of authorization results. It > was simpler to just recommend that the AAA result and EAP results agree. > > > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we > > are discovering that (1) and (2) must agree too. > > This is not a "discovery" -- it is an implication of the proposed state > machine. > > > So, when an authentication > > method succeeds, but authorization fails, should the authenticatin > > server go back and flip the authentication method to "failed" so that > > the results are all aligned? > > If the authentication method supports an authorization failure error > message, it can send that and there is no problem. Alternatively, the AAA > server can send a Reject/EAP Failure. If this does not agree with the EAP > method, which completed successfully, then the peer may silently discard > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > layer failure indication such as an LCP-Terminate or 802.11 > Deauthenticate/Disassociate. > > Why doesn't this address the problem? > > > We could make (1) and (2) the same, and keep (3) independent. But the > > problem is there is no equivalent of (3) for the last hop when PPP or > > 802.1X is used. > > That seems needlessly complex -- given that our goal is to improve > interoperability. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Wed May 14 02:51:38 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 13 May 2003 21:51:38 -0400 Subject: [eap] Re: Issue 121: Document meaning of successful authentication Message-ID: <2212401.1052862698@[10.0.1.2]> I am not able to join the conversation tomorrow. I am having a medical problem this week - hopefully I will be better by Thursday and getting email. I am pretty happy with 2284 and 2869 bis and with the stqte machine. I have one major concern with both 2284bis and with the state machine - and that is that tunnelled methods will not be able to do sequences of methods. Another concern is that the keying material information be taken from 2284 and put in its own section, if possible. I think keying is not always necessqry so putting it in its own section is important. Sorry I can't join you tomorrow -- John --On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba wrote: > > I think the problem is not with EAP, or AAA. The problem is with the EAP > > lower layers, such as PPP and 802.1X. If they had a way to carry > > authorization results, this problem wouldn't exist. In PANA, we carry > > PANA result so this wouldn't be a problem. > > 802.1X considered, and rejected the carriage of authorization results. It > was simpler to just recommend that the AAA result and EAP results agree. > > > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we > > are discovering that (1) and (2) must agree too. > > This is not a "discovery" -- it is an implication of the proposed state > machine. > > > So, when an authentication > > method succeeds, but authorization fails, should the authenticatin > > server go back and flip the authentication method to "failed" so that > > the results are all aligned? > > If the authentication method supports an authorization failure error > message, it can send that and there is no problem. Alternatively, the AAA > server can send a Reject/EAP Failure. If this does not agree with the EAP > method, which completed successfully, then the peer may silently discard > the EAP Failure. Again there is no issue, as long as the NAS sends a lower > layer failure indication such as an LCP-Terminate or 802.11 > Deauthenticate/Disassociate. > > Why doesn't this address the problem? > > > We could make (1) and (2) the same, and keep (3) independent. But the > > problem is there is no equivalent of (3) for the last hop when PPP or > > 802.1X is used. > > That seems needlessly complex -- given that our goal is to improve > interoperability. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From gwz@cisco.com Thu May 15 04:56:47 2003 From: gwz@cisco.com (Glen Zorn) Date: Wed, 14 May 2003 20:56:47 -0700 Subject: [eap] RE: Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational In-Reply-To: <200302130047.TAA20157@ietf.org> Message-ID: <000b01c31a96$14b6d990$1200000a@amer.cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C31A5B.68598830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit draft-aboba-radius-rfc2869bis-21.txt says in section 2.3: "In RADIUS [RFC2865], the RADIUS client is responsible for retransmission of RADIUS packets. RADIUS/EAP client implementations SHOULD support dynamic estimation of the RADIUS retransmission timeout, using the algorithms specified in [RFC2988]." The reasoning behind this modification to the RADIUS retransmission strategy is that "... we have seen situations (such as a network-wide reboot) where RADIUS storms can occur, swamping the RADIUS server(s). In these situations it would be preferrable for RADIUS clients to support exponential backoff and a more conservative initial RTO estimate, as in TCP." (see http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20125). However, the TCP RTO algorithms are designed to prevent network congestion, which (though it may occur) is not the problem we're trying to solve here, which I think might be better modeled as a server resource contention problem. Furthermore, the problem is not specific to EAP-over-RADIUS; in the situation mentioned above, the same behavior would be observed regardless of the authentication protocol in use. This fact suggests that a solution to the problem (presupposing that a protocol-based solution is reasonable) should be published as an update to RFC 2865, rather than RFC 2869. There are other reasons why the RFC 2998 algorithms are inappropriate for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4); others include an initial TMO that is likely to be too short in situations where one or more RADIUS proxies are traversed, the large granularity of the timers specified and the deterministic nature of the algorithms used which in the worst case could result in all the clients firing repeated salvos of requests in lockstep (not a good way to reduce instantaneous server loading!). ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 24,713 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_000C_01C31A5B.68598830 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_000C_01C31A5B.68598830-- From aboba@internaut.com Thu May 15 05:54:19 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 14 May 2003 21:54:19 -0700 (PDT) Subject: [eap] RE: Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational In-Reply-To: <000b01c31a96$14b6d990$1200000a@amer.cisco.com> References: <000b01c31a96$14b6d990$1200000a@amer.cisco.com> Message-ID: Overall, I agree with Glen's comments and would therefore recommend that the paragraph in question be removed from RFC 2869bis, and that a separate document be developed to specify RADIUS retransmission behavior in more detail. > the TCP RTO algorithms are designed to prevent network congestion, which > (though it may occur) is not the problem we're trying to solve here, > which I think might be better modeled as a server resource contention > problem. The basic principle embodied in the TCP RTO algorithms is "conservation of packets" -- that a new packet should not enter the network until there is reason to believe that another packet has left it. Both a server resource contention problem and congestion manifest themselves in terms of increased delays and packet loss, and so it seems to me that the principle applies in both cases -- and can be addressed dynamic timeout estimation, backoff and jittering. > Furthermore, the problem is not specific to EAP-over-RADIUS; > in the situation mentioned above, the same behavior would be observed > regardless of the authentication protocol in use. This fact suggests > that a solution to the problem (presupposing that a protocol-based > solution is reasonable) should be published as an update to RFC 2865, > rather than RFC 2869. I agree with Glen that the problem can occur with any RADIUS usage (authentication or accounting), and therefore is not specific to RADIUS/EAP. It therefore would be best to handle this as a separate document. > There are other reasons why the RFC 2998 algorithms are inappropriate > for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4); Section 2.4 mentions that TCP is too aggressive in terms of retransmission. However in practice we are seeing RADIUS client implementations that are much *more* aggressive than TCP. For example, one RADIUS client from a well known vendor has a default RTO of 1 second with no backoff. Several thousand of these clients recently caused a service outage on our network after a network-wide password reset resulted in a RADIUS server overload. Since the clients did not back off (or jitter) the result was extremely high load as clients kept retrying EAP authentication without success, hammering the servers until we had to change the network-wide configuration to bring the network online again. The other thing mentioned in section 2.4 is that faster failover is desired than what TCP would provide. It seems to me that RTO estimation and failover are orthogonal issues so that doing dynamic RTO estimation and backoff need not adversely affect failover algorithms. > others include an initial TMO that is likely to be too short in > situations where one or more RADIUS proxies are traversed, the large > granularity of the timers specified and the deterministic nature of the > algorithms used which in the worst case could result in all the clients > firing repeated salvos of requests in lockstep (not a good way to reduce > instantaneous server loading!). I agree that jitter is required here, and that the initial RTO might be set to a higher value (say, 5 seconds). From aboba@internaut.com Thu May 15 18:49:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 15 May 2003 10:49:34 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 125: Reject Message-ID: Due to problems pointed out by Glen Zorn in his comments on Issue 125, I would like to recommend that Issue 125 be rejected. Any objections? From aboba@internaut.com Thu May 15 19:02:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 15 May 2003 11:02:12 -0700 (PDT) Subject: [eap] Issue 133: IESG comments on RFC 2869bis Message-ID: Submitter name: Russ Housley Submitter email address: housley@vigilsec.com Date first submitted: May 15, 2003 Reference: Document: RFC2869bis-21 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Section 4.1 says: RADIUS/EAP is used in order to provide authentication and authorization for network access. As a result, both the RADIUS and EAP portions of the conversation are open to attack. Does "open to attack" mean likely target of attack? If so, please use these words. If not, please clarify. Section 4.2 says: When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the encryption transform, and per-packet authentication, integrity and replay protection MUST be used. A typical IPsec policy for an IPsec- capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812". I agree that DES-CBC should not be used; however, we ought to tell the implementors what algorithm ought to be used for interoperability. Further, the text requires integrity protection, but no integrity mechanisms are discussed. Also, the discussion of IPsec policy should not be split between these two paragraphs. I propose the following: When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. AES-CBC SHOULD be used as the encryption transform, and HMAC-SHA1-96 SHOULD be used as the authentication function. DES-CBC SHOULD NOT be used as the encryption transform. A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812". Later in section 4.2, the text says: "... it is important that trust be demonstrated ..." In this context, "trust" is very ambiguous. Please reword. I think that the paragraph should discuss "authentication" and "authorization." Later in section 4.2, change "Certificate Authority (CA)" to "Certification Authority (CA)." In section 4.3.1, please add an informative reference for ARP. In section 4.3.2, please add a pointer to Section 4.2 in the very last sentence. In section 4.3.8, please change "even where IPsec is utilized for transmission layer security" to "even where IPsec is used." In section 4.3.9, the text says: "As described in Section 4 ..." Since this text appears in a subsection of section 4 and there is no text following the single digit heading, a more precise pointer is appropriate. In section 4.3.9, the last paragraph should tell what security services are expected from the "wrapping mechanism." I believe that they are confidentiality, integrity, and data origin authentication. From aboba@internaut.com Thu May 15 19:04:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 15 May 2003 11:04:16 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 133: Accept Message-ID: I'd like to propose that we accept the changes proposed in Issue 133. Fixes are available for inspection at: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt BTW, if you haven't read and reviewed this document, or if you have any issue that you haven't posted yet, now would be a good time to do so. From jari.arkko@piuha.net Thu May 15 21:12:57 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 15 May 2003 23:12:57 +0300 Subject: [eap] Issue 133: IESG comments on RFC 2869bis In-Reply-To: References: Message-ID: <3EC3F4C9.3090502@piuha.net> > Section 4.2 says: > > When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the > encryption transform, and per-packet authentication, integrity and > replay protection MUST be used. A typical IPsec policy for an IPsec- > capable RADIUS client is "Initiate IPsec, from me to any destination > port UDP 1812". > > This causes an IPsec SA to be set up by the RADIUS client prior to > sending RADIUS traffic. If some RADIUS servers contacted by the client > do not support IPsec, then a more granular policy will be required: > "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination > port UDP 1812". > > I agree that DES-CBC should not be used; however, we ought to tell the > implementors what algorithm ought to be used for > interoperability. Further, the text requires integrity protection, but no > integrity mechanisms are discussed. Also, the discussion of IPsec policy > should not be split between these two paragraphs. I agree. > I propose the following: > > When IPsec ESP is used with RADIUS, per-packet authentication, > integrity and replay protection MUST be used. AES-CBC SHOULD be > used as the encryption transform, and HMAC-SHA1-96 SHOULD be used > as the authentication function. DES-CBC SHOULD NOT be used as the > encryption transform. > > A typical IPsec policy for an IPsec-capable RADIUS client is > "Initiate IPsec, from me to any destination port UDP 1812". This Maybe "... client is to require IPsec from this node to any destination port UDP 182. This ..." We don't appear to have any standard language for expressing IPsec policies in text like this. Also, "initiate" sounds like it is an IKE-only construct. > IPsec policy causes an IPsec SA to be set up by the RADIUS client > prior to sending RADIUS traffic. If some RADIUS servers contacted > by the client do not support IPsec, then a more granular policy > will be required: "Initiate IPsec, from me to > IPsec-Capable-RADIUS-Server, destination port UDP 1812". Maybe: ... will be needed: IPsec is reqquired from this node to any of the IPsec capable RADIUS servers on destination port UDP 1812. --Jari From ltarkkal@ssh.com Fri May 16 18:05:59 2003 From: ltarkkal@ssh.com (Lauri Tarkkala) Date: Fri, 16 May 2003 20:05:59 +0300 Subject: [eap] Proposed resolution of Issue 130: Reject In-Reply-To: References: Message-ID: <20030516170559.GA569@tehdas> On Tue, May 13, 2003 at 05:53:49AM -0700, Bernard Aboba wrote: > The text of Issue 130 (and subsequent discussion) is given below. > It appears that there is no true deadlock and so I would recommend that > this issue be rejected. IMHO this issue can be rejected, under the condition, that the use of lower-layer indications is specified under the following conditions: - EAP transmissions are unreliable, and lower layer indications are unreliable. - EAP transmissios are unreliable, but lower layer indications are reliable. - Both positive and negative indications are specified. These have been discussed in this thread, and in other threads. One suggested proposal for the wording (regarding positive indications) was given by me earlier on in the Issue 130 thread, and by others in other threads. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From aboba@internaut.com Fri May 16 16:11:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 16 May 2003 08:11:10 -0700 (PDT) Subject: [eap] EAP WG "pseudo WG last call" on draft-aboba-radius-rfc2869bis-22.txt Message-ID: This is announcing a "pseudo EAP WG last call" on the RADIUS/EAP specification, draft-aboba-radius-rfc2869bis-22.txt. This should appear on the IETF archive on Monday, May 19, 2003. Until then it is available for inspection here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt The "pseudo EAP WG last call" will last until Monday, June 2, 2003. Please send comments to the eap mailing list (eap@frascone.com) in the format described in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From aboba@internaut.com Fri May 16 16:20:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 16 May 2003 08:20:34 -0700 (PDT) Subject: [eap] EAP-03 now available Message-ID: draft-ietf-eap-rfc2869bis-03.txt has now been submitted to the IETF archive. It should be available on Monday, May 19, 2003 at this location: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2868bis-03.txt Until then it is available for inspection here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-03.l.txt The new EAP-03 version resolves the following issues found during EAP WG last call: 104-117, 120, 122, 124, 126-129, 132. The following issues remain unresolved: 121, 131, 134. For more detail on open and resolved issues, see the EAP Issues List at: http://www.drizzle.com/~aboba/EAP/eapissues.html From aboba@internaut.com Sun May 18 01:51:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 17 May 2003 17:51:24 -0700 (PDT) Subject: [eap] 802.1aa/D6 now available (fwd) Message-ID: From: Tony Jeffree Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The description of the Length field is as follows: The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. What happens if the Length field indicates a length greater than the received number of octets? Perhaps this should also be specified: A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Also, perhaps change "should be ignored" to "MUST be ignored". 2284bis-03.f: The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation. 2284bis could be clearer, imho, that even after a number of timeouts you don't send a Failure. Suggested rewrite: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." From aboba@internaut.com Sun May 18 16:39:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 18 May 2003 08:39:24 -0700 (PDT) Subject: [eap] Issue 139: Response to duplicate requests Message-ID: Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: "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. " Seems like the peer should be able to send as many responses as it gets requests for the same id. It may not send a response for prior id after it has sent a response to current id. This is how the state machine works, and hopefully the wording in 2284bis will be modified to match. From aboba@internaut.com Sun May 18 16:46:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 18 May 2003 08:46:58 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 138 Message-ID: Here are the proposed fixes to Issue 138 (enclosed). In Section 2, change: "The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation." To: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." In Section 4, change: "The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception." To: " The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded." ---------------------------------------------------------- Issue 138: Miscellaneous -03 issues Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 2, 4 Rationale/Explanation of issue: The description of the Length field in Section 4 is as follows: The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. What happens if the Length field indicates a length greater than the received number of octets? Perhaps this should also be specified: A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Also, perhaps change "should be ignored" to "MUST be ignored". 2284bis-03.f: The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation. 2284bis could be clearer, imho, that even after a number of timeouts you don't send a Failure. Suggested rewrite: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." From jari.arkko@piuha.net Sun May 18 17:10:34 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 18 May 2003 19:10:34 +0300 Subject: [eap] Proposed resolution to Issue 138 In-Reply-To: References: Message-ID: <3EC7B07A.3020002@piuha.net> Ok, thanks. --Jari Bernard Aboba wrote: > Here are the proposed fixes to Issue 138 (enclosed). > > In Section 2, change: > > "The authenticator MUST NOT send a Success or Failure packet as a > result of a timeout. After a suitable number of timeouts have > elapsed, the authenticator SHOULD end the EAP conversation." > > To: > > "The authenticator is responsible for retransmitting requests > as described in Section 4.1. After a suitable number of > retransmissions, the authenticator SHOULD end the EAP > conversation. The authenticator MUST NOT send a Success > or Failure packet when retransmitting or when it fails > to get a response from the peer." > > In Section 4, change: > > "The Length field is two octets and indicates the length of the EAP > packet including the Code, Identifier, Length and Data fields. > Octets outside the range of the Length field should be treated as > Data Link Layer padding and should be ignored on reception." > > To: > > " The Length field is two octets and indicates the length of the EAP > packet including the Code, Identifier, Length and Data fields. > Octets outside the range of the Length field should be treated as > Data Link Layer padding and MUST be ignored on reception. > A message with the Length field set to a value larger than the > number of received octets MUST be silently discarded." > > ---------------------------------------------------------- > Issue 138: Miscellaneous -03 issues > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net > Date first submitted: May 14, 2003 > Reference: > Document: EAP-03 > Comment type: T > Priority: S > Section: 2, 4 > Rationale/Explanation of issue: > The description of the Length field in Section 4 is as follows: > > The Length field is two octets and indicates the length of the EAP > packet including the Code, Identifier, Length and Data fields. > Octets outside the range of the Length field should be treated as > Data Link Layer padding and should be ignored on reception. > > What happens if the Length field indicates a length greater than > the received number of octets? Perhaps this should also be specified: > > A message with the Length field set to a value larger than the > number of received octets MUST be silently discarded. > > Also, perhaps change "should be ignored" to "MUST be ignored". > > 2284bis-03.f: > > The authenticator MUST NOT send a Success or Failure packet as a > result of a timeout. After a suitable number of timeouts have > elapsed, the authenticator SHOULD end the EAP conversation. > > 2284bis could be clearer, imho, that even after a number > of timeouts you don't send a Failure. Suggested rewrite: > > "The authenticator is responsible for retransmitting requests > as described in Section 4.1. After a suitable number of > retransmissions, the authenticator SHOULD end the EAP > conversation. The authenticator MUST NOT send a Success > or Failure packet when retransmitting or when it fails > to get a response from the peer." From Internet-Drafts@ietf.org Mon May 19 11:11:12 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 19 May 2003 06:11:12 -0400 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-03.txt Message-ID: <200305191011.GAA13653@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-03.txt Pages : 54 Date : 2003-5-16 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-16151454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-16151454.I-D@ietf.org> --OtherAccess-- --NextPart-- From rgm-sec@htt-consult.com Tue May 20 14:12:04 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Tue, 20 May 2003 09:12:04 -0400 Subject: [eap] Vienna plans In-Reply-To: Message-ID: <5.1.0.14.2.20030520091125.02cf1358@localhost> Will there be an EAP session at Vienna? I am working on my justification for the $1600 airfair..... Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jari.arkko@piuha.net Tue May 20 20:29:53 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 20 May 2003 22:29:53 +0300 Subject: [eap] Vienna plans In-Reply-To: <5.1.0.14.2.20030520091125.02cf1358@localhost> References: <5.1.0.14.2.20030520091125.02cf1358@localhost> Message-ID: <3ECA8231.3070701@piuha.net> Robert Moskowitz wrote: > Will there be an EAP session at Vienna? Yes. > I am working on my justification for the $1600 airfair..... Hey, us europeans need to do that almost every time... ;-) --Jari From jari.arkko@piuha.net Wed May 21 14:40:30 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 21 May 2003 16:40:30 +0300 Subject: [eap] sm-02 authenticator timeout failure issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122291@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122291@esebe023.ntc.nokia.com> Message-ID: <3ECB81CE.2050401@piuha.net> Pasi.Eronen@nokia.com wrote: > Hi, > > This issue was listed in Appendix A of sm-02 draft > as a "known inconsistency" between 2284bis and SM > (the Failure response is actually sent although > eapReq is not set; see Section 5.1 of sm-02 draft). > > Here's an updated diagram that fixes this, and also > attempts to show how timeouts are calculated > (changes to -02 version are shown in blue). > > http://www.cs.hut.fi/~peronen/eap/eap_authenticator_14052003.png > > (Does the handling of timeouts look ok? The idea is that > if a method has some idea what the timeout should be, it > sets methodTimeout. eapRttEstimate comes from the lower > layer) Looks OK, IMHO. Thanks. --Jari From jari.arkko@piuha.net Wed May 21 14:53:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 21 May 2003 16:53:47 +0300 Subject: [eap] Re: mapping between the state machine and 2284bis In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BAFA@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BAFA@esebe023.ntc.nokia.com> Message-ID: <3ECB84EB.8000307@piuha.net> Pasi.Eronen@nokia.com wrote: > Jari, > > Big thanks for reviewing the state machine document! > We've spent so much time on those diagrams what we're > probably blind to any problems in it by now :-) > > >>DISCARD: OK (with a nit) -- 2284bis has more detail >> - Section 4 has a silent discard for other Code values >> - I also recently sent e-mail about whether Length >= >> received PDU should >> cause a silent discard. This too might be something >> that parseEapReq does, though it isn't specified in >> detail. > > > Yes, parseEapReq is supposed to do this: if the PDU has > invalid length or code, it doesn't set rxReq (which results > in silenty discard). OK. >> - Perhaps there should be a "logEvent" call, as is >> required in 2284bis in the silent discard definition? > > > We discussed this, but decided not to show any logging calls > here. Real implementations will probably log many events not > explicitly mentioned for logging in 2284bis (such as success > and failure!), and logging does not change the behavior of the > change machine. > > (For the same reason, we didn't include any "statistics" > variables that would not change the operation of the state > machine, but could be interesting to show in some authenticator > management interface) Sounds good. The picture almost doesn't fit to a page now, it makes sense to restrict it. (Did you say that you consider statistics and logging out of scope somewhere in the document?) >>GET_METHOD: NOT OK -- same level of detail, one nit and one problem >> - Incoming arrow valid according to Section 2.1 and Section 4 >> - First if branch valid according to Section 2.1 >> - Second if branch valid, but note that it would be imho >> clearer if setting the methodState to NORMAL in METHOD >> would also result in setting currentMethod to NONE. >> Then we could remove "resetCurrentMethod"? On the other >> hand, you appear to rely on currentMethod to stay intact >> for forbidding sequences... right? > > > There's a new version of the peer diagram that has simplified > this state and METHOD state considerably. You may want to review > that one instead (although we don't have yet the explanatory > text for it). > > It's available at: > http://www.cs.hut.fi/~peronen/eap/eap_peer_13052003.png > > Regarding your question: Setting methodState to NORMAL can't > reset currentMethod, because NORMAL is used for two different > purposes: when the method has ended, and when the method can > either continue or end (this is one of the things handled > differently in 13052003 version). The new version looks very good, much clearer. Thanks... >>- The third if branch appears unclear or perhaps incorrect. Section 2.1: >> "A peer MUST NOT send a Nak (legacy or expanded) in reply to a >> Request, after an initial non-Nak Response has been sent. Since >> spoofed EAP Request packets may be sent by an attacker, an an >> authenticator receiving an unexpected Nak SHOULD silently discard >> it and log the event." >> >> And here we send a Nak (even if we were in the middle of >> another method). The spec talks about it being invalid for >> the authenticator to send other types while already doing >> one authentication method. We also talk about the strict >> mode, where such requests would be silently discarded. >> But I didn't find a place that says what we should do >> outside the strict mode for such requests. So should we >> respond with a Nak, as the sm does? Or silent discard? >> If silent discard, we need to split the third if branch >> into two, one dealing with currentmethod = NONE and >> one with the other case. > > > Again, this is handled quite differently in 13052003 version, > but the basic principle is correct in sm-02 version as well: the > third branch (that sends the Nak) is reached only if > currentMethod is NONE or IDENTITY (assuming we're not inside a > tunnel, something removed in 13052003 version completely). > So we are not in the middle of a method, and haven't sent any > responses for Types >=4 yet. Yes, at least the new version appears to work correctly for this. (FYI: I was confused for a while trying to search the condition which handles the reception of a new non-NOTIF method while already doing something else. It turns out that it was the "else" branch from RECEIVED to DISCARD. I'm not sure whether this should be made more explicit in the picture, but should at least be pointed out by the text.) >>METHOD: NOT OK -- one nit and one small error >> - Aligned with A.1 in general, but: >> - Perhaps there should be a call to logEvent, to show the >> SHOULD requirement in A.1? >> - A.1 allows MIC failure to be a fatal error. This does >> not appear to be handled by the sm. > > > As an unintended consequence of other changes, the last > item seems to be better handled in 13052003 version :-) I'm not sure why this works in the new version. Can you explain? If intCheck == FALSE then you just discard and continue as-is. On the other hand, if "decision" is set to FAIL, then you have a fatal error. So you'll have to interpret fatal MIC errors as something where intCheck is set to TRUE? You can do this, but this should probably be explained somewhere. Another way is to transition non-deterministically to either DISCARD or FAILURE when intCheck == FALSE ;-) --Jari From aboba@internaut.com Wed May 21 17:17:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 21 May 2003 09:17:16 -0700 (PDT) Subject: [eap] IETF 57 Draft Cutoff Dates Message-ID: NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html From aboba@internaut.com Wed May 21 23:00:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 21 May 2003 15:00:58 -0700 (PDT) Subject: [eap] Discussion: Retransmission Issues Message-ID: One issue that has been coming up lately surrounding EAP is retransmission behavior. This includes: a) EAP authenticator retransmission algorithms b) 802.1X supplicant retry algorithms c) RADIUS client retransmission algorithms If any of these algorithms is too aggressive, the result can be excessive load, queueing delays and high packet loss. To fix this, it is important to introduce the concept of exponential backoff to EAP, 802.1X and RADIUS. We've had a discussion with respect to EAP and RADIUS transport behavior in the context of Issue 125 on the EAP issues list (http://www.drizzle.com/~aboba/EAP/eapissues.html). Let me try to outline how I think we can fix this. The TCP retransmission algorithms outlined in RFC 2988 form a good basis for a proposal, but as Glen Zorn has pointed out, RFC 2988 is inapplicable in places and is also incomplete (e.g. no jittering). That means that merely citing RFC 2988 is insufficient; more detail is required. A reasonable start is to recommend dynamic RTO estimation, using RTOmin=1 second, RTOinitial=3 seconds, and RTOmax=60 seconds. For the RADIUS client, the suggestion has been to increase RTOinitial to 5 seconds (Glen Zorn). The RTO value is backed off exponentially (doubled) on retransmission, and a moving average estimator is used, as specified in RFC 2988. One issue is whether the timer granularity in RFC 2988 is appropriate or not. In order to provide jitter, the actual RTO value is chosen randomly on the interval [max(0, RTO - 200 ms), RTO + 200 ms]. Note that although RFC 2865 warns that TCP-based retransmission may be too aggressive, we have seen cases of RADIUS clients with retransmission algorithms (e.g. 1 second RTO with no backoff) considerably more aggressive than TCP and this can cause RADIUS server overload. From jari.arkko@piuha.net Thu May 22 06:13:36 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 22 May 2003 08:13:36 +0300 Subject: [eap] Discussion: Retransmission Issues In-Reply-To: References: Message-ID: <3ECC5C80.6050709@piuha.net> Bernard Aboba wrote: > Let me try to outline how I think we can fix this. > > The TCP retransmission algorithms outlined in RFC 2988 form a good basis > for a proposal, but as Glen Zorn has pointed out, RFC 2988 is inapplicable > in places and is also incomplete (e.g. no jittering). That means that > merely citing RFC 2988 is insufficient; more detail is required. > > A reasonable start is to recommend dynamic RTO estimation, using > RTOmin=1 second, RTOinitial=3 seconds, and RTOmax=60 seconds. For the Ok, but see below. > RADIUS client, the suggestion has been to increase RTOinitial to 5 seconds > (Glen Zorn). The RTO value is backed off exponentially (doubled) on > retransmission, and a moving average estimator is used, as specified in > RFC 2988. One issue is whether the timer granularity in RFC 2988 is Ok. What is the timer granularity in 2988? > appropriate or not. In order to provide jitter, the actual RTO value is > chosen randomly on the interval [max(0, RTO - 200 ms), RTO + 200 ms]. I would expect e.g. randomness of dial-in clients connecting to provide some randomness between different EAP sessions. In other words, not all would retransmit at the same time, if that was the reason why you wanted to provide jitter. But I'm OK with providing it too, not sure we can rely on the connection randomnessin in all cases. > Note that although RFC 2865 warns that TCP-based retransmission may be too > aggressive, we have seen cases of RADIUS clients with retransmission > algorithms (e.g. 1 second RTO with no backoff) considerably more > aggressive than TCP and this can cause RADIUS server overload. Yes. I'm generally OK with this approach, but I'm wondering what all this will do to, say for fast movements. In most of the cases you would see very quick responses, probably in the order of a hundred or few hundreds of ms. But if a packet is lost an initial RTO of 3 and one retransmission causes a deley of at least 6 seconds. Do the timers have to have only second granularity and does RTOmin have to be 1 s? --Jari From aboba@internaut.com Thu May 22 13:58:28 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 22 May 2003 05:58:28 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: <3ECCCA52.8060000@kolumbus.fi> References: <3ECCCA52.8060000@kolumbus.fi> Message-ID: In practice, many APs send an Identity Request with hints encoded in it. These hints include the Identity of the NAS, as well as other information, along with a Displayable message. I'll look around for the specification for this and get an issue submitted so that we can discuss it in more detail. However, this is not specified in any IEEE specification, including IEEE 802.1X or IEEE 802.11i. On Thu, 22 May 2003, Jari Arkko wrote: > > Just for my education: assuming a client has multiple NAIs > and credentials, how does it decide which one to send? I > remember some talk about SSIDs as well as the contents > of the EAP ID request. But what exactly is currently done > by implementations, and has IEEE specified something about > this? > > --Jari > > From jari.arkko@piuha.net Thu May 22 14:28:04 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 22 May 2003 16:28:04 +0300 Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: References: <3ECCCA52.8060000@kolumbus.fi> Message-ID: <3ECCD064.8080307@piuha.net> Bernard Aboba wrote: > In practice, many APs send an Identity Request with hints encoded in it. > These hints include the Identity of the NAS, as well as other information, > along with a Displayable message. > > I'll look around for the specification for this and get an issue submitted > so that we can discuss it in more detail. However, this is not specified > in any IEEE specification, including IEEE 802.1X or IEEE 802.11i. Interesting. So, what is the practise on the client side then? Do the implementations bring up a window to display the Displayable Message to the user, and then the user decides? Or is there some magic involved where the client decides that the hint is of a specific format and decides all by itself without asking the user? --Jari From aboba@internaut.com Thu May 22 14:13:33 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 22 May 2003 06:13:33 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: <3ECCD064.8080307@piuha.net> References: <3ECCCA52.8060000@kolumbus.fi> <3ECCD064.8080307@piuha.net> Message-ID: > So, what is the practise on the client side then? Do the implementations > bring up a window to display the Displayable Message to the user, > and then the user decides? Or is there some magic involved where > the client decides that the hint is of a specific format and decides > all by itself without asking the user? I think that either is permissible. The Displayable Message part of the Identity Request is displayed to the user, and the rest of the message is meant to be machine readable, and so could be used to make an automatic decision. From jari.arkko@piuha.net Thu May 22 14:55:30 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 22 May 2003 16:55:30 +0300 Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: References: <3ECCCA52.8060000@kolumbus.fi> <3ECCD064.8080307@piuha.net> Message-ID: <3ECCD6D2.8040101@piuha.net> Bernard Aboba wrote: > I think that either is permissible. The Displayable Message part of the > Identity Request is displayed to the user, and the rest of the message is > meant to be machine readable, and so could be used to make an automatic > decision. I'm not sure I understand where the "rest of the message" is. Rfc2284bis-03: Type-Data This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required. So, the Type-Data field use completely used for the Displayable Message part. What other fields do we have for the other things? --Jari From jari.arkko@piuha.net Wed May 28 14:19:26 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 28 May 2003 16:19:26 +0300 Subject: [eap] issue 141 Message-ID: <3ED4B75E.2080906@piuha.net> In general I agree with what has been stated in http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20141 and support the proposed changes. However, I think the term "cryptographic separation" should stay in the document, because the definition is more precise than the suggested replacement. Also, regardin the MSK and EMSK, should we instead move the normative language to the main body, not delete it completely? --Jari From jari.arkko@piuha.net Wed May 28 14:25:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 28 May 2003 16:25:47 +0300 Subject: [eap] issue 138 Message-ID: <3ED4B8DB.4030807@piuha.net> The text changes for issue 138 (which I filed earlier) appear OK for me. Perhaps this issue can be closed. http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20138 --Jari From aboba@internaut.com Wed May 28 14:18:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 28 May 2003 06:18:51 -0700 (PDT) Subject: [eap] Re: issue 138 In-Reply-To: <3ED4B8DB.4030807@piuha.net> References: <3ED4B8DB.4030807@piuha.net> Message-ID: Any objections to accepting the changes proposed in Issue 138? These are enumerated below. For a full list of issues, see: http://www.drizzle.com/~aboba/EAP/eapissues.html In Section 2, change: "The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation." To: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." In Section 4, change: "The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception." To: "The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded." ----------------------------------------------------- Issue 138: Miscellaneous -03 issues Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 2, 4 Rationale/Explanation of issue: The description of the Length field in Section 4 is as follows: The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. What happens if the Length field indicates a length greater than the received number of octets? Perhaps this should also be specified: A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Also, perhaps change "should be ignored" to "MUST be ignored". 2284bis-03.f: The authenticator MUST NOT send a Success or Failure packet as a result of a timeout. After a suitable number of timeouts have elapsed, the authenticator SHOULD end the EAP conversation. 2284bis could be clearer, imho, that even after a number of timeouts you don't send a Failure. Suggested rewrite: "The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer." From jari.arkko@piuha.net Wed May 28 14:57:46 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 28 May 2003 16:57:46 +0300 Subject: [eap] issue 139 (Response to duplicate requests) Message-ID: <3ED4C05A.9030907@piuha.net> Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20139 I agree that there's some confusion in the documents regarding this. The bad thing we wish to prevent from happening is a retransmission causing the user input to be asked for the second time. Or a cryptographic calculation (e.g. random generation) be run with different results. Currently, 2284bis says that if you get a request while you are processing the old one, ignore the new request. The state machine simply processes the request again, and sends a copy of the previous input. The basic reason for this is that the when we are in some state, we do not suddenly jump to process the next input request just because one arrived. This leads me to think that 2284 might be best fixed by replacing the following text: 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. with this: If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response. Received Requests SHOULD NOT be processed before the previously received Request has been processed. (And perhaps the reasons for invalid EAP messages can find some other location in the document? If they are necessary, that is.) Note that the proposed text above ignores possibility that a lengthy operation, such as user input or smart card communication, could be interrupted by something coming from the authenticator. Do we have anything that could do this? Failure? Would it be important to handle that? If we make the state machine handle events from both sides (network and user/smart card) it would become complicated. So I would like to avoid that if possible. --Jari From aboba@internaut.com Wed May 28 14:42:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 28 May 2003 06:42:21 -0700 (PDT) Subject: [eap] Issue 139: Response to duplicate requests Message-ID: I think this language was put there because of token cards. The peer checks the validity of the EAP layer header (Code, Identifier, Length) as well as EAP method header (Type, Type-Data), and so a packet is silently discarded is if these validity checks fail. But here let's assume that both the initial Request and the retransmitted Request are valid. If the authenticator is retransmitting a Request before a Response has been sent, that must be because the authenticator has not estimated the RTO timer well. While we do have some language relating to dynamic RTO estimation, it could be that the EAP method requires user input (e.g. punching in a token value) and that the RADIUS server did not provide a good "hint" as to how long this should take (e.g. Session-Time attribute wasn't included). In this case the authenticator could use an RTOinit = 3 seconds, but the user might take longer than that to respond. So the authenticator will retransmit the Request. Off the top of my head, I don't see anything wrong with sending a Response to the initial Request, or sending a duplicate Response to the subsequent Request. The question is really about the processing of the duplicate Request. Does this result in an automatic resending of the Response, or is there a requirement for additional user action -- the user just typed in her token, and now we're asking for it again? That is what needs to be avoided. The current text attempts to handle this by discarding a Request which arrives before a Response is sent. An alternative to this would be to resend the Response -- but make it clear that this is automatic (occurs in the EAP layer) and does not require any user action. So the user wouldn't have to type in their token again until they get a *new* Request. ---------------------------------------------------- Issue 139: Response to duplicate requests Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: "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. " Seems like the peer should be able to send as many responses as it gets requests for the same id. It may not send a response for prior id after it has sent a response to current id. This is how the state machine works, and hopefully the wording in 2284bis will be modified to match. From aboba@internaut.com Wed May 28 14:50:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 28 May 2003 06:50:03 -0700 (PDT) Subject: [eap] Re: issue 139 (Response to duplicate requests) In-Reply-To: <3ED4C05A.9030907@piuha.net> References: <3ED4C05A.9030907@piuha.net> Message-ID: > This leads me to think that 2284 might be best fixed by > replacing the following text: > > 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. > > with this: > > If a peer receives a valid duplicate Request for which it has > already sent a Response, it MUST resend its original Response. > Received Requests SHOULD NOT be processed before the previously > received Request has been processed. Perhaps we need to clarify the first sentence by adding "without additional user interaction". In the second sentence, are we saying that packets are processed in the order that they are received? I think so. > (And perhaps the reasons for invalid EAP messages can find some > other location in the document? If they are necessary, that is.) I think at some point we need to state what checks are made by what entities. But perhaps that is a separate issue. > Note that the proposed text above ignores possibility that > a lengthy operation, such as user input or smart card communication, > could be interrupted by something coming from the authenticator. > Do we have anything that could do this? Failure? Would it be > important to handle that? We've said that we don't send Failure as the result of a timeout. It is certainly possible that the user could take so long that the authenticator might have given up -- but that wouldn't constitute an interruption. So I think it is fine to process packets in the order they are received, with no interrupts. > If we make the state machine handle > events from both sides (network and user/smart card) it would > become complicated. So I would like to avoid that if possible. I agree. From aboba@internaut.com Wed May 28 17:57:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 28 May 2003 09:57:29 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: <3ECCD6D2.8040101@piuha.net> References: <3ECCCA52.8060000@kolumbus.fi> <3ECCD064.8080307@piuha.net> <3ECCD6D2.8040101@piuha.net> Message-ID: > I'm not sure I understand where the "rest of the message" is. > Rfc2284bis-03: > > Type-Data > > This field MAY contain a displayable message in the Request, > containing UTF-8 encoded ISO 10646 characters [RFC2279]. The > Response uses this field to return the Identity. If the Identity > is unknown, this field should be zero bytes in length. The field > MUST NOT be null terminated. The length of this field is derived > from the Length field of the Request/Response packet and hence a > null is not required. > > So, the Type-Data field use completely used for the Displayable > Message part. What other fields do we have for the other things? In order to answer your question about "what is actually done in practice" I did a capture of an EAP session on our 802.11 network. Here is what is sent in the EAP-Request/Identity: 0000: 00 6E 65 74 77 6F 72 6B 69 64 3D 4D 53 46 54 57 .networkid=MSFTW 0010: 4C 41 4E 2C 6E 61 73 69 64 3D 63 75 73 72 65 64 LAN,nasid=cusred 0020: 30 34 30 63 33 34 30 39 2C 70 6F 72 74 69 64 3D 040c3409,portid= 0030: 30 0 So the first octet is a NULL, followed by a comma delimited list of parameters. The networkid parameter provides the SSID, the nasid parameter provides the identity of the NAS (cusred040c3409), and the portid parameter provides the port identifier (zero here). My understanding is that the material prior to the null (not present here) was to be presented to the user and the information after that (the comma delimited parameter list) is for machine consumption. From jari.arkko@piuha.net Wed May 28 20:07:16 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 28 May 2003 22:07:16 +0300 Subject: [eap] Re: deciding which NAI to send in ID-RESPONSE In-Reply-To: References: <3ECCCA52.8060000@kolumbus.fi> <3ECCD064.8080307@piuha.net> <3ECCD6D2.8040101@piuha.net> Message-ID: <3ED508E4.7020601@piuha.net> Bernard Aboba wrote: > My understanding is that the material prior to the null (not present here) > was to be presented to the user and the information after that (the comma > delimited parameter list) is for machine consumption. Very nice example, thanks. So, how do we treat this matter then? It seems that current practise does not match what 2284bis says (unless the last part of the text applies only to responses): This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. (... stuff about responses ... ) The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required. We could (1) ignore such practise and pretend it doesn't exist or (2) change the definition to say that there may be a null, after which the Displayable Message ends a Non-Displayble message begins ;-) --Jari From jari.arkko@piuha.net Wed May 28 21:14:03 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 28 May 2003 23:14:03 +0300 Subject: [eap] Re: issue 139 (Response to duplicate requests) In-Reply-To: References: <3ED4C05A.9030907@piuha.net> Message-ID: <3ED5188B.2010801@piuha.net> Bernard Aboba wrote: >> If a peer receives a valid duplicate Request for which it has >> already sent a Response, it MUST resend its original Response. >> Received Requests SHOULD NOT be processed before the previously >> received Request has been processed. > > > Perhaps we need to clarify the first sentence by adding "without > additional user interaction". In the second sentence, are we saying that > packets are processed in the order that they are received? I think so. IMHO the first sentence is enough without an addition, but if you want to add one, maybe "without re-processing the request"? As to the second sentence, yes, this implies also that requests are processed in order. (The main point was though to prevent "interrupting" the current request, no matter what.) Will this be a problem? I don't think so... >>Note that the proposed text above ignores possibility that >>a lengthy operation, such as user input or smart card communication, >>could be interrupted by something coming from the authenticator. >>Do we have anything that could do this? Failure? Would it be >>important to handle that? > > > We've said that we don't send Failure as the result of a timeout. It is > certainly possible that the user could take so long that the authenticator > might have given up -- but that wouldn't constitute an interruption. So I > think it is fine to process packets in the order they are received, with > no interrupts. Good, this makes things simple. --Jari From aboba@internaut.com Thu May 29 18:12:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 29 May 2003 10:12:52 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: <20030529170003.30210.15379.Mailman@wolverine> References: <20030529170003.30210.15379.Mailman@wolverine> Message-ID: > We could (1) ignore such practise and pretend it doesn't exist or (2) > change the definition to say that there may be a null, after which > the Displayable Message ends a Non-Displayble message begins ;-) Well, there apparently are some people who care about this and want to use it for something. Perhaps if they spoke up we could determine what to do. Off the top of my head, I would think that an Appendix describing what is currently done might be appropriate. It also might make sense to have an IANA registry for the parameters so that interoperability is possible. On the other hand, I could also see handling this issue in a separate draft if it is determined that the effort to specify this is significant (and RFC 2284bis might be delayed). From aboba@internaut.com Thu May 29 18:29:57 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 29 May 2003 10:29:57 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 139: Response to Duplicate Requests Message-ID: The text of Issue 139 is enclosed below. The proposed resolution is as follows. In Section 4.1 of RFC 2284bis, change: "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." To: "If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the Request. Requests MUST be processed in the order that they are received. -------------------------------------------------- Issue 139: Response to duplicate requests Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: May 14, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: "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. " Seems like the peer should be able to send as many responses as it gets requests for the same id. It may not send a response for prior id after it has sent a response to current id. This is how the state machine works, and hopefully the wording in 2284bis will be modified to match. From aboba@internaut.com Thu May 29 18:54:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 29 May 2003 10:54:49 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 141: Minor NITs Message-ID: The text of issue 141 is enclosed below. The proposed fixes are as follows: In Section 5, change: "In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A possible registered stringprep profile is specified in [SASLPREP]." To: "In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP]." In Section 1.3, change: "EAP Master key (MK) A key derived between the EAP client and server during the EAP authentication process that is purely local to the EAP method. The MK MUST NOT be exported from the EAP method or be made available to a third party. Since derivation of the MK is a residue of the successful completion of the EAP authentication exchange, proof of MK possession may be used to shorten future EAP exchanges between the same EAP client and server, a technique known as "fast resume". Master Session Key (MSK) Keying material that is derived between the EAP client and server. The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. Where a backend authentication server is present, acting as an EAP server, it will typically transport the MSK to the authenticator. The MSK differs from the MK in that it not assumed to remain local to the EAP method, and is known by all parties in the EAP exchange: the peer, authenticator and the authentication server (if present). The MSK MAY be derived from the MK via a one-way function, or it may be an independent quantity. However possession of the MSK MUST NOT provide any information useful in determining the MK. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. However, unlike the MSK, the EMSK is known only to the EAP peer and EAP server and MUST NOT be provided to a third party. The EMSK therefore MUST NOT be transported by the backend authentication server to the authenticator. The EMSK is reserved for future uses that are not defined yet. For example, it could be used to derive additional keying material for purposes such as fast handoff, man-in-the-middle vulnerability protection, etc." To: "Master Session Key (MSK) Keying material that is derived between the EAP client and server. The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. Where a backend authentication server is present, acting as an EAP server, it will typically transport the MSK to the authenticator, so that in this case, the MSK is available to the peer, authenticator and authentication server. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. Unlike the MSK, the EMSK is known only to the EAP peer and EAP server and is not provided to a third party. The EMSK is reserved for future uses that are not defined yet. For example, it could be used to derive additional keying material for purposes such as fast handoff, man-in-the-middle vulnerability protection, etc." In Section 7.10, change: "Non-overlapping substrings of the MSK MUST be cryptographically separate from each other. This is required because some existing ciphersuites form TSKs by simply splitting the MSK to pieces of appropriate length. Likewise, non-overlapping substrings of EMSK MUST be cryptographically separate from each other, and from substrings of the MSK." To: "Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 1.3. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the MSK to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK." --------------------------------------------------------------------- Issue 141: Minor NITs Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: May 19, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: - Section 5: "In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A possible registered stringprep profile is specified in [SASLPREP]." SASLPREP is not (yet) a registered stringprep profile. Proposed text: "A preliminary version of a possible stringprep profile is described in [SASLPREP]." - Section 1.3: I think it would be simpler if the terminology section only defined the terms, but would not specify any requirements for EAP implementations. At least, unnecessary duplication of those requirements should be avoided. Here are some proposed changes that would simplify 1.3 somewhat: - Master Session Key (MSK): delete second paragraph (similar text was already deleted from 7.10) - Delete "EAP Master key (MK)": no longer necessary since the term is not used anywhere. - Key derivation: Delete the last two sentences (unnecessary duplication) - Key strength: Delete (unnecessary duplication, since it's already specified in main text) - Extended Master Session Key (EMSK): Proposed replacement: "Additional keying material that is derived between the EAP client and server, reserved for future use." - Cryptographic separation: delete. Instead, add to section 7.10, 4th paragraph, after the first sentence: "That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption." [Jari Arkko] - In general I agree with what has been stated in http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20141 and support the proposed changes. However, I think the term "cryptographic separation" should stay in the document, because the definition is more precise than the suggested replacement. Also, regarding the MSK and EMSK, should we instead move the normative language to the main body, not delete it completely? From uri@bell-labs.com Thu May 29 19:30:25 2003 From: uri@bell-labs.com (Uri Blumenthal) Date: Thu, 29 May 2003 14:30:25 -0400 Subject: [eap] Re: submitting EAP-SIM document References: <000801c32165$dbb8ca00$23a50587@EDC> Message-ID: <3ED651C1.6010207@bell-labs.com> This is a multi-part message in MIME format. --------------010701050405000100090909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, My colleange Sarvar Patel asked me to post his analysis of EAP-SIM draft. Here's the summary in short, and since the entire paper (in PDF) is only 16 KB, I'm attaching it to this posting. EAP-SIM specifies a mechanism for mutual authentication and session key agreement using the GSM-SIM and by proposing enhancement to the GSM authentication procedures. Unfortunately, as we show it does not succeed in its goal of providing 128 bit security from the current 64 bit security of GSM. Furthermore, it does not provide session independence between different sessions. For the first problem, we are able to provide solutions, but the second problem does not seem solvable in practice. --------------010701050405000100090909 Content-Type: application/pdf; name="AnalyisOfEAP.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="AnalyisOfEAP.pdf" JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1dSZMcRxUOrvMr+oYc4W51LV1dDUEENhbgsCHMzBA+YIKQZpNs z2iXMXf+N117vq/zLZlV1TMC8AHVVFZmvn3N7NeL9SpJF+vqv+4fF7cnr08en+aLm7cnrxfl Kqv+V79x/31xu/j8fD9st0g2q12xOL8+SeoXySLJ0lWaL4pdtkrXyeL89uTR4pPz70/y1brc Dzi/PHn0WfWcJKukaP9wV/1htyrz9vlp9Vyuyu6DH5sJiu755+Z90Y1/C+NfNOM3BfO+3VDe ff+yWX+bts/X1fNmlTPDn9T7X692KQDUDfimHdBveNlMmHbPZzjgS1jiT/WAbJWlzB4OZrgC GBFmBkeIg54Gd4CTBeD0qxbmTepuYNfwkY9IKhfcwA7eVM/FKisYCPH5tp4wHyZsdsTA885D 48enyZ6B93vMK45epvt/potlWlZQ90jfDTuq+XS7Kt0NbwaMfKCv29EFN7zeQlaJk8NFu0qY vKu9A6G4oq9/hNk6ALPFnkIVdHsBzcvFMtlWCKtGfN3gc92t977Bf4+xC2DiK3i+g/HvfDvI 2odzWAwnw8Wew+S4WM2+BYW9pxN5eeM+vICRuI23gOQOi5sei7sGi1nHI/jFU5jxDWDlg7sd bfBvW5np0YaQtjRLwmhGCdZPtnIJhjMRnN6CYNRoWqZFWmGlQk7p5cHmxdeVLvilqyqeAXER p8hZb2BvT9294cbfAQmdeX4FCCAc+6SRr4wofWfT38Cml7DJs+Z9r96+bN6XVOWvgdcyBgWv XBCvqC5DiJHJr2FnUUKQubh2BpOXyBfKRp9LskBYFbeMW/QyZMbAT1gZRc4HT94t814Sn/cS NCi4Ik7FZQjSguQbkYjkwG1o3xM8kpVF6MjIy8PPBm2GVNYYFZ8jN/yDB8PZbrfbtn/6ufnT lmq/PEkr72rQfgg3MUTIdggaPiMnBhGeQEeYS8MYmfamWbP0in4QmyKh/wC69Qx064GuNCpb foJRHErNVu+wefmiG/wKLDUyAOFNou1fhhNsWOaG3b3IQXbNfEFVPMO3rK2x8y2+fMlCFsGK sXzYiH62d3wKSfT/uxQ64U6RjxXmIKL1XpoVHAmUAuK5LtiHvwJ5CYhBXoJo+8m0Gg0QJ62j 0L1GnfIpCxwuJHpxPzWY2Jqkop3J67URLP0E+CWzILOJwn7JrhHkrN6x04ir45yEuihkWsgl Mr0PQ7lX9oNwKSIFzTjBS8dF28HdEV1X8jGKUOcYldQxsusPEiwj0JfSS7vjkrgjU/ehZPH/ TFo6iLW0PIioFZmVewbyOySDc3DdbKZP0Ym0EEOseJOrAyxsMN6bKNyR+UdKaM5IBEpotPfD m93fN59S88g7v0Hsg0yBjCkabpyMt6fHtFfLPE2rxPCgIyMt1xyq1eIbHDtEF9W9uHtfIs0Q +IkjFTeX1yg4EmmLDtWVvBCPL9FWolJAs+AVQN45tyvh4zGPPWAAzWXPFcabQC0/i8sy6XHA 8aBt7UqBMCf6fVpoz6tSho1T0IFJUZkwPorWdLkYDvlAY7NpkYmHe9e+YlVMTELEixJPdoJy cfWJBCnU5+KB5IO0ccLEcpzoXT+saNiYqrZNJnKsWCtts6+9ltPUld1/sNMb99QxmBM9h+bs cNtKaov05OzdyG0daqe7SpMOX6wrxqsKr0ldeC3J5E5TiLnzpe+56FpfSGJ+0s6Xz9slNyR4 cNLu2NlC2kCufVzgDP4CZ9f6ai7gmdlN3zfzqpEG7EOhxVpnPPYmefty3I6ENKl7TKrGjnwY 0Zfav91T3GlVEqWC14eovsSI065mFcdZ9CQ1WdQSrUbI0Zl6Srcslr9xS5FaR/ODRO1tD//v qeFhQC26icTwa3rzOYtLrXdgIucDif//XoH5ewX2Bq9msCFmeEAtA3JZmNUomKxWou35Cq6H no+TExDdR18N0G8NkNV5b+cctJOeIlQjxQMSxEWaIip828yZVSzlPFMay9sCZ9WAD95gGBmd 6ShlaT5dv9nEdmyv5JJV6eg4UzpFjx2niA1FJDJ2rXvd6sUejH81z9QTN6XqIxr8Bj7AZf6p 8AmSnkiiFoTaYdDK+SJZFJuBgni/PkXO7CLepbAXdew5fm03TO3V3wsR1AymBTKatp8Cb+Cj IJuLLQXGYqafwTpp2wwZlVYprjcV/njPL8hChrZMz+cOi7Y5vpO5s6XdtGirf9c89wcNeFZA q34KX0IBhZ9IK34hjpVM2DIpCs/xg8S1nKTX47tPfAhzIKlx8vh0P0OTanFe/aJ91WVhkmTw 7xG14imD036isj2GVP//MunOl1zASpX97F82gBc57a9Jg6D87ADKwgIlMsw4KBNYqY40+rc1 D6WDelGnS6edLtOn8/LlgQPrlTqy8rbKtQ4r/3BA/Z1D/r8Baf9dr5eqkjcFOfi5AAQDLcxz BRBCnUsUrL83WnhNtHB9QNBVJ9mDUycRHAekN3CcgxeB486oHUAzgcHj2cHGahsTqyKwdylm +SKOi41LmwFHpqcUYTg13VWwgS0MKgZMlxPxVRIgCPQXEtAXsncem45FcB2hevLdwbfm6QUl d7UgT2xmCjq2F1PtDq1DTJRmGnWyyF6uny6JSXYvHrfC3SMe3puXiY8MyEitUdPAU3zmRCsi arl4e+dJhw0nahzbyMUnjNp4NFsT3yCIlCJpxRwF4gQZVQu+iXzMcT5Iy4hpea6Yhh+TfUNX hsSGaFX52BMdLIRXbHjRBNHCrvbM7Uw1u/azvgNCVPvhjaiCy6E1Rh7qhEkOOwRxzkRaWtON 7YZ7IogyqGWzos6VLLNyS2uxZA8iQ9vPu2r6zyOog+bGAhPP06McMTITYQ7eYo1ycpB+Gr3j a8KY9QlqFOR9zqCWjDkO/n4kXRV2fYFmSYT2sHbkKDB75GDXoEEXgTDOku0qhBuJVhNmYi16 By4zIsozTzY0eR3Py3fSSKxuBnX+xmtBkR21zIJY2TH2cFtOQ7PZA5EWdsnS1HJQidceP2uN kscSaM5D1iIE8Sivxiu8xSUqnudcu/XJ2Ddjcx187IlE+bXEMkEtVEor2JGyKAe9L0bj4F8f 5VxUCglLTrtc8izxPy2UkQImHp30GS6Th4DrT36eSTnEKVrc8U0MeV9oEFPtQaed5yAZLyr2 rvnQDMqgVz+aHFt9zdjOreyIKNYCjKDsdJCl0kIZkcSiwhBvZ3nFPgSlFWZn9+kOOWrnYjwM xdfBNNYXqagxm6KV1d7v/tCWiKwg0k4RiCo2krmLLchGakVILUEk9uchTZkoT0+aoWd7zOtk lvm6pNnHuLvcGA9CK1VpkXHQ/aT3cQ2PpkXwbqqgGk9QYVjsnh970EOrPtlPlRkRFtcmrt3o AJ3T9m7S0JTDRCV8bIHBdNCf4fkLeOZ98qg+H2c89g2Ryes77yElWIxJCVJ7FhCI79XbeuV6 fWMxGu9+iSmu416mRliduIGoJUXHTEykB3nIfCPN3ClG41kC+8ke34nGjSmU9EnN1u2lewFS k1bA0J7mbq7vHgE0vLNv99JnZ1JkE39raHh4oXnrYuZfq+sEnZcXlcBsd+sd3rE95tztOO1u 6IRSlYKIRZIQSSfEYveleLuKeHmQlMEaa5Ajraaopo+UTmofjGGwLUDl02JHdUDDo1Nrp3BQ 08DR7z4Ur+QVm4h5wlldt2xoXtT94bpQQjq+J/GMvYIYqe0m1LejVZecdlkm6zVNstZ/xp+t EZES3wd4pDYae27AdqiE6wo6jBK57rhRt1rfb6ltpkgkoqWfqWnM2+pisdBxqRvJxKgJUB8Z w68a5uy86Ej4Oz35KE27OmqiXl0RelPJ5vDKnaDsQbAusYfY8c21R70CwkcP7KztXQqx/nus SrWtm0lLrX4ApNpFdtarQ401YK2XHoVAM/8j+wUpnni1IsIUdAqG91eCRfpTANceE8cnpUxK qs6yki5MMaMiqibxZaQJDdK0tsH2UrAPFdxNVqG5pUtgY48ygx+a5eh8wIxfNczXj/5NM9uW C3v+CMyLzBxwAtoW8AxnYQNO3Vun7g0Lnl+mh4hHbftoh/LJVBTv9vNa4wUshR9Vtgpk/DEC 0c2xO0h2lS4q4e4CmGTITyh3wHSOI/zGxdSJb963mOauWEgdO0rhH+7Og86STJFY8cU3veDH xzdBxhY5X2xEtvmZ/MWwmrMlHqfV0rNBk/kZgY8c7OeKyDLfw0gx220v600UPj2TRiJtxdzr O2pZgjy6yKA3SIXz2SHx55w8l5gFpbkPrdlemZbVx4My/ba2h8PdHpHWRUzlabTV7rJHXH+Q 9jhTMjO0fTK+AjB5e0wvB1gOmOPmj/Hp4rBw0CLi9nKmZuhm/Yn0+8q0z/TLzlP9PBFe4RiP rrrYRfoA1JgloOdk3n6MqULm6fJec9XlNOuAnqrd4YhUafEeg1j856d5CD+1jj8cPyurzx2B MRYGvfB7sn8D9Fo1B0UhPO7ilCn5eORlGE/OF385qf77D8RiQkplbmRzdHJlYW0KZW5kb2Jq CjcgMCBvYmoKMzM3MgplbmRvYmoKMjIgMCBvYmoKPDwvTGVuZ3RoIDIzIDAgUi9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V1Lt9xGEd7Pr5id7XMYefQYzWjBggRDOAkYnMth QVjEdkyCr31jm5vg7PMH+MWMpBmp65uuR7d6XoC9saxRq7u66qtnl97Nl1lezJft3/0/XryZ vZu9m2+ysv3T/Zf77xdv5p/czB4/y1fz7QM3r2Z599/5vFnO18smy+t8fvNm9vDDo5t/zKqs 3mxv3rycPfxne11mZb27/qa9XmXF/v737fX+5rz78e6idO/8wr1DfvZpe7HJlpXv5u/bi3w5 TudX/a/rinkap09Gw7V8684QF0ae/LL7ZbYudtfP4LVP2ut1VjA/J2P9IL31BVzjlO/ch9/3 Nxsv+e/dXyJZvoNh37o//ns/h01iGr7uiZIX9Mer/fXH/nrtXc3rQzYbR/oaXktW85JlUCQK zp4fRuQypC1STCTnHTtb5PyMlSj8pTi7t+wLcWqEoZD1+GFEdsdhcHavlPv78dZNsz4OAiyq YrUFx/kiL7NNHCadQixfexYSLVnTxMpP4wO5nwS05SUhbZDAE45DCvNExQkwq6mY2zhFkTL8 LFAccVaEZm/ai8aIe3Y18luQNuSAA/H0YX7DiQZj/lScjsBF8qjcXTx+1szzVUuwrQW2KNfr dqRF0bQTaH9U9IsbZDzrp1MRKKmyJYGePG8BypHRJtvsH/gaBryF9X0Eanbrb1yucd7+AQbb LWkwKReboqXsIl9vGXH4QQ+cX7Q79yB+43wAVxk3kQz0+TDpDla20+7mtMizVT2KkrOqMqvn w00fQO6nockoeZaICkHW236YmlkcGaUGbK1Y0X3u3tEQSyTgrQSUdo2VVLtYlCsZ5qVEjkCw xSndAmaIO3gJZrqI1D8CQtyxBEfG4DeRrIMMiHhLHiO+pqh7iH5DKr6UaNEbfWWz3oLWaPMh rd8DDuMoyNyMF80hR5CbgobMPWCCZmMjyZFdeZWGxhgawn8EhF/ATHYaYFBWv4P7skZAmmrr RLoFOQq8XyYKsKgCkEnOYbveAbO8AsY+EqjYyYtL1bDZKHl+ou+2j9s93F0NrnnNmMy04YUT zStRlzDug+NWG/EbtcVh3G9RlcvWpBzBVXP6+ahiQsPu3/BSER2QyYIsPx9gcBwXaQfZLU8f zHBaCVeN+h6v4wMUmmD95GdX73IRQES7kzeZxXfk7i8b96Kwjf4d6OArMsj5t/lJNuqa+J0h zE4m8H3IBEQZ0hSJaCSL3CK+RtT7Y0RyVTgAimMgYckLNbMoMjRERIBw/SZIBGxRNMbOqhgC iKFr5sXgf290jdvvTl7U7Vjj7uyjJPk8r3aKqVh3IaAvWko9mK0zOvY4tY6o4+0d/w728tP2 emsfD9Gstz0bDrh6C+N97McDGBnv1/R9lff1w6+f92+rKB0bQke0loSXf6Bv+wZ+/oLevoel vgeVos3mo2dtbigrr3dWSt2St/3Jn0HGCTyhzSJa4GJmhQwbas0qsSM+C4sv8iucETqDAA8H 88A3P7Ld6glC7Hj7Kc4fnwQ+/tBRaBDCrxYOEjN7wvNYj5MWrRM10GmLk9Xuk6cIc0aaQ2po y8+OR1ef4lqDbIBDs2xrkVR94H+v81CIReni7bzLdfYEsYuPDhGu4u2Mp15FZEywaq4Vhm2I QY2ehvgm5IEdHW1ZaXuASEN9vNZQMaLSZLwvSpUv4oJcxRGHbAMuKWHcybY7QQrAsJUjAdFD vffMkav1mlSVIz5M8JALg6zGYJlv1ujEbZ2BTSU4cUZ9Y8+JIMcBNe2uHgq2Rtpv2ZHijTD7 sjG9IdKE3ES08yDyyLi73MXgm4lBzOMZnycMUU+CCj2MdvIYgpZPigyrBe21vRovVFT4fCBZ FyEnQpJIa5QWLs3o5BRExiHT8krT1uzs5HrEUNxSgsMo6wwemkUp1MX1zcmeMrcHo5WqFH4y Ho3DWDZEUB/DGjrBJaZ5Pe/QYnjSmU3R020wpjfDw73Z3t1aDI/zRvFnoJTErFSQv4ME5IMo QUERTYsy2RV/ZYSd/cTwSuRjdmP9cqwVNtXCWytivt5vuB46ZUKl8vTqny0i1lktGJVHcI6M 7GwncwyIc2wRhOF25vRpycp3L1ZJQkjML3bxKFwD6laxqHvTXjgVQGKm6TwKtBhlJDI2JwaZ CdOI2UfetksnOyJEpS4k09KrpzXnQ6po9i74ihaiRLrgIk6LhaZaBlxL9xzptNsZs6vxYSZN dYlJN2Npiy1VoTmWRkvPz+anyIMc4v2iKMtWjUBWeyjt/8ujB+0xhFTZQAYXU9iq9iIT/CVh mHivHlX8VEyIP6ckhvo1Lwh3kY+OJFjAqFOwxBgzOb7Sr4qZCL/12h5gCkgJ3ttVNMY5RFtH xAkxsklW3ju/fPpI23ltf9HhMoYc0xtFWM26qJYFjcEj0TRz3SLohqNhv+l3gHuLtgGiWRQk MIgIuLXMEW6bPeJnfEj9eBl/klcXVBUiCudXD4F2eDgVaUsiRQky1g7ifPVI2keC5Lgmjb3S lpSz4dVEtmrC43z/ZWUt3mnH1wrzYc+YQ/XLmhaMTIu9pM1QmDZOT0+oWW07jiY4F3hQdu0N lCPljSchWXANOcsaJH6XHvuyB3/0hhxOBCtddx4Sj+FlO8h8OFJDFXt6Qey8EaFjRqEJTRZH xO7LzZrE7tG6wK34A1z/WtkqssnnGHwQe9Pgjojy7Bnci4VECf8K7/m5G624FHpdy+BgfS3N 1tffgP72lkYiDMWEDb3Zm6Byx/gjrSYN7FSXKeHYqHYEi6pY02C4OEsxdCQGyo7kBkxryiQW VyhRJLTlgo6AP4eH/QYSf2ROZx2hUDmJ8RZWujnRwuVfloiN4uvc0hak8xov6ZmGc6Adw5Wc eJnwo+ukVEk92j4HOPhlz09DKANDG1hOhHASYDockTOuc+hpRgMZKmMv0LYgPGnPCPFZXy1W inw/LVntfRAR2NuezaGBvT2bhjK+DGFdezKEWy/5gdlJFnEjaSw+RSWef7Dp7S6NeaRJ7uw0 cylSYjQJUWq5xCMwifT/VM+VZwWtwiDIWhJPIkA2SazOCKIUPowIcmiMqqfkxlkH1fokkdhF uWmI0YA2pR9R7IlSxpRhe0kGxdIu4aBHxPnZkXo8Tpiy74dqzupDXWgCntKcq96PTL4DG4zE OEX+PR6O/xcqVpR+ItTIKtd1awcfNBdptpbyrqtssXYaixTkJYNO2PUVYe4W9O6c3v0SVOJd /+uhBwlEDe7h9q4PRwm4z432FhTyB8/c3LYdTd5ucNu1o6dPUJImtMA1rg2YMZpDkCf+FLYh T2mRD9Fc0UraeElLlPcRESYoHByZh9a2JKjDqjh7sbeTsULB3p3K3ltLpCrjK9sia2KTdDym pokgYzZNDyMGhX3xxyJlccdDv5HgDUQsqqKRa9949tEqe8RvQ9gbWPqh29jmQiPKpJq6yUip mGc+usVnuOwwmqI3iO3okqEFnnGj441LCDccL74k1gJoNA9izEtoj2XMNw/YjyEUkZcntk7E 1TlJVV4q9JPXXf+jpXsQXTz1g9iE16FmqYETlRhx1Cc8mHZjXFraaKiER6RMBQQQFLMfmsBX /gvACZlwUv8ke9pPtOT5prNG4RwMsSDhvLauyJE1eReK2Li1Obs6/Rjsiun7jRR85z4cdKBu h5vlkoYzcBGEky39d9YcztmprkWuU2g/VsDE71lNjTfEN6P7v5BFCZmTTLAfN08sZNzUeSUR md5LCUDnJAxpOmnvmKtQaWsjLmmzIvuGXBG9TtEqgmksOcxeSwBNypyL0aig5D8YOcwZU1OI LGkFQ7CPNbEnUNK6wakJ+ERnG0W51LwArRe3RdcNYRjx813kySQ+q3PGVrOjdLe1w0wSpCTe 1J00YXH0YzR+TmdkoAup8Ud8RsWHfF5pPl9jvdCEDI/UpzsbmBSO7Y3/NFwJonsQO/NG/sRO gQ58FLD30Z0CfWn1snO5uO4mn9EPl05uLcgVd0QesQ0yngiA3XkmZ1N4KVpp4QuRf/nDi0HR sEQntSPTqUkrCm07ndzhj/9mvD1tcLzvHdpPldmZWstFiiHl60gfdt11Szc4ZzfprzG0s4u8 7e+h3D5pr60fntd8DZEDDrW/UJPK20pasFAkhr1qaPqRvf1NPKLjS9ayNjBSWOxRh7gfV0Tp 4+2gEHUkjAZxtXJ4Mahq5bRxk9gK2Clxkyl9RhdVvqFJ4MTJagF2j3QIM4XFl8j6ClXAU+NA RopFgmbCpkXEPRSNhSNpqJ0iHD58Eao47Z8XD/wq1fU6C/n+x6G9GiKcBR/nBHkKvi88Y9gu nft63tiYf9cuKyUwYqKofxKVDKbubBUfVSefXa7ZCaf7aN6RyraDxEEMDmrN/oOc1kTxwDO1 Ly7rnPab6/774VMa2BM1g/2whiLV9qKveEjCJ+1ZoHMEJ0QWP8X324N63Yi8Kep6RW+atiAo mR0EoKeI8mmbGeSP+gHYHpQTB/cfbg79GEJa8DysqFlUy5I6nVPbfZ3DhBR3NYgFQh145vtW kWegpthQViXOM8TJvxocf7RQi+8f7ZPZkbn9oyKN6nKaViYe7E5RsnqAGCVTJGzMLrRHdF3g Ogd8HPVLHdcCIvZ3nNzFuiyEYUM/hw7Hk5v5n2bt3/8AnFR+5mVuZHN0cmVhbQplbmRvYmoK MjMgMCBvYmoKMzQ3MQplbmRvYmoKMjYgMCBvYmoKPDwvTGVuZ3RoIDI3IDAgUi9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V3Lstu2Gd7rKbQ79kzJkBR1W2WSuu2kddOpo5mu YydOHNfHdhy7zWv0iSuSokh8wn8DQEonE3tjmBQI/PjvN7xfFnlZLYvmb/+PF28W7xfvl7t8 1fxp/2v87xdvll8eFp89K8tlWedFvTy8XJTtk3K5L5bbYpsXRbk8vFk8qh4fflps893x2eG7 xaO8Ga7y/eY0hsdLePy0Ge/ydXUaf+u+/sIdvu6GG2q2tzDby2ZcX7y/q0/jb5rxPl/1v//e /dwH7/A82yvh6/cwxtV+BWN8/zsYw+re8Y+Ns+HrAPnvPcd4RI/18ohPR9zIqmq3zMpNvq+G 5+UR0svD08Wjw+O7429X/dQ/Ng8dkK/zyj2i8Rb7N3/2gbsf/NI9XHkfvoBvOA//Db/8w3gB zmqcdTtz/KcD3qYmNvWpfbmjPd9z3Bq9hg8dRvc//DhexUuYBcfSVz/4qaWsiPnYA3kDpOXs 4lvu0HEZp2XXxFdfcSfvwMe/vzF5UJDCnZ++WTtsavQ+rgnnu/dg55nyfu3GWy/kEM8dnESw 4svOTLhGfJmFFnFG1Y54jmP20O7Vh4Yb/rl7uaCW5fzY+QzLTNqfZavdumFvWcfWPJtwJmTx 6R33UD/NPbfo/JKHDKT8FQhCRHAFztHczPnx386SYnfSI1o+mZX5ejOg/0iUrPLN8vzQmeqT B9f7DSAX/8jBjcWpdFyORmoWYs7PAg5G8w0QI1ciX5yGfZkV4ngOesUBfymtCUHlEGj46dyT 0yCP07/pLO2T7+vb/X5LAAkwhOC0rMzK6mrd0XrPMfEM9XtjBTmL6qZjYOmZ1TF9uFpzwEMW IwDToIcBa3RA5+CE8wQ5qEnY6CnVmcaLlFr1VNJ2EjEp1O1R92PxKxG7RojiWZn0TYWicBr8 qxmUZU6ZNewa9bQtkbP/swM9sHA1yRjTy6rjHHFYE7RULO7IYHcNmxgY7HMOpaRvpuaxt6Eh kkQTriICg0VGBQar3sycwyxQaqiJGNezjnkWPSy+AGb6dTc+i7onMDZZfzSEYuy+2WBFiHHF 9hQmyUCLyAVYDwLSjE5JGD72Q/d8N2KDBCcrjqc+Nq7TmWHhJ/JHwN6ZxO6hGVD+Ur1HC1c3 kSmpJPHz+AmMU5D0VCIEODmSDmsQCAaV7MdiPLfOj2OdzRKDuEVDm3aQg2zWW8t4mDjG9xFM r30UwxjYEthl/fmo/u1HHPMWTGTnkPCEJayWyOvEfvshmsmBDFWyLia1vVhLk443sXoDAVbK iMP1szZ5vEFkkSHno5VkiMmApwNEeLTJdUiHR9Bz4IrNEaBasxjTcZn4Sb/+Fa31qSI1WV3u 8orxH96iaLqiQapWmwbuNgVx9Eq/95TYdUt+A9bDrfHakdI9qddu2MBtJTCY3K1e80FyUkdL gr83g7IY8BzNiZNNVqrwSWk+EKodqv2MEfuOO8qel+1dX104kOZQXSnnFrsQE5NyHhKOhX4V yFIkcsbnyOEJCNasOPIKf3wTV8IyWASucxC0PtshVLndNGQwIFT730eCuSN1B0mQIWJ8vFis NrkCAe7MhDByHipdUOejkqJlrJdbQ4NeU1JCOMmaw9/rVQofsepyh+ZL2uEs8h84AgCQS7Zn uK11DcHMHgZt7M1rorDuYFaB0GsAPSKtB4HqlRytV7gaJxDoj+05BzUJrzS5U1sq/MjyQYwe o2D7UX1QbKiPRbUOocBJvyEWJDGJcEYmBQ1N2YzWwEWKRC2WVEyeEo+FNMCBDvWki13T00qa k9ftaUBDXhAEMBcT2oTr4G3IYaRnoSQwBxVG1oUprmBHgqyuNg0HGtgqi/MmqzE2ZW9A+/k8 NoGO4+kySwJFNyscJRswVqFlGaye3UhslGUiJ6zQWXFs9rbCcL0MclOf9VEXZV6bwHp1JfY5 0KwQL02XcETFPEvaRUOfrypQ3iazrqtJ/Ddmk1Rn8MTapInFDsUMcGYWKwh1s8c4vbbpbM75 GdiraFLT7tWoippAni9FJwkPusq7l0DNGliDBBxTdiRNy3qraAo0VFg9yFzeAgs1+VtNVg5+ Gc1A1isXpZ9T3tg1za0JxbUs87HHk42YS+yPDvmY2Bm7BpMxMkUsTkEPAwawZgCL4uFWf6zl qUwyvinjk/Zx0OqdpBizmJXcWJ1ZZTDbp7x8G+Bv0kDFACIVrerPbmTin7dfFF4D5NImPTK/ 2rXav+kIYEsRgL4Ox9mZFGDxKEA0EbLOg0iVPNJ9hzE/vwIwbE2iuPAMjd+2cRCl8eDL4ceL aIz+pkQ1udbiN32e7nT1bz7Sq2VMDaQ7VF68vogRq0y3z0vO1VZQOSWqD8iI0zlh0znLA89b odYORKDXbHFalsOaggC0SprUZlQwST2HDJEPknKk46DE5CydKNipsh5BLCemNMH5qonp8MKX HQqf055ZUS+7pLPVdu92KHlw+bIJC3nYvQda07iRU05k4YwjKhymdvYQnw1P87op2qzlVZh0 9OlOR6UCXYMzZatVpUgq1Os5AQLoNCDke1ibLFqkC93GZspDmK0fjz4EOnululCnFO49kpKB nc2wipeUWK3XOSfK1mEZizN4Tc4R5bN2SECZmiv0UWCtiq3qZVYvZ6kAXXm91di0whyYJFv2 GNuWMTzJ9TpcxZSgnEAg0970KI1Jb4FZuJrQ6omtI4nLv1awZzb8AoJRQh78qpNkesPZEZQ7 IfwwPgcScDaL5U3tw2rgN2wMSBJPgS7MoMZGWV1snFpNFu0QW6QGutNln9CyNNCZh0v/b/tL oiTwLQeUcC+qyWmpRwxn6bgAPG9WrEr5Ewg0fP8zP/GSH3dWbrJJdCvVIIYTio909VBYIHEI PRf2MR5KUZuT73Aiw2ueXo/VeMrg7RbiUdcsHV1TWr+zhJ9gynAHtfRyugI3nMmhG9qLZzK3 RBO1h+4VDF2PV6bcbFzHbueV+fPjuyOT9EJDIlETD0RVUIrg4nz6lMmkcX5lCMHnC65lNJ0u FnQz5S3TddRSe8SDW2pJDSBMtuFE9TH6ZNUHUklDE3q43RbDAo7Cs73xZvJKp5lKAVn1jd0a RnWs4pp1DVjlQTi3S56M8hA6B9IB5L+6DDBc5MzUO47VKPGspWL/ByKvRkSXyN+YwtuMphyT ii/7m9veNruxkXK9+2HEq5N0fn8854lo4JkHbYs0+Q5cX7iwtr5jIcSUO6LQuoVOvtdr4kjo nTW1kkAFMX0EikkBCYeG5pBUCX2sx0BXNDxgqEnSXNM6axsijvmstPLpojR+nKBN7gcQ+ErY MyoqBDVB5o8m5eUacWGqyHY2y35KDstw0KgYv7VfhVBioM31S9TCwnlNgoOncgo/K2BfVlcr t2xKHwHUNXbQV3BEGd0+/DtrEYFaf7y6I3lB2UCcpHZGVVglzd6kSQ4D+JKBGNLrsB/qWxFE ufslhf6ajICSSYG3s9ALii1kjHDaaXvDmNiH1XO62u9zrlvtpIROI3agm2+KYoDpYqusSZHO ucr+krXSAzveS8mASDmiU+/V+YXOO1I1m/G7R6x1fQgcxAs2UjlH+bKJC0e11ZIwLvAKVJPA NrWPmS72p0d82bA4sthto3o/rHKtRLes0CI6IFebbsWWiBmW4zer8WBH7sNBABP6pmR7c8lL RcJEeIyJTYGTg7bKSwskkc3SmAkRTQF6v8qqzG2J7MqYrXarZuaBReG+fOaMVn/VZISqHMe/ N5t3v5ouF++GXIW6wr/fm82TcjpblW6G/rITI/ujFGmW0wiS7fLwtJFwd0dBXjkznZ0Qrfgj n5bu06X7tO1YNCraetu9vYfuDw6pjh7/0mHXChwR1Gz33dcKp2QF1jaSotm+bBA3O0JpMwJQ B66njX5zp1ZvTEZaiCY/pbtJ4HY+9NfX17JI62OXdSQvCe/uEd7teaZrCkwmnvMyWz1y3810 lvGsLmP6LKsypaOR8Dt3ouyLBHeODV/6C0yGzd4uLsoKcsuP0n7Se+bbPvNbriZsousk2eYX dBTYmoDmUwDO3MrUyJtlkqwvxlI0r6/EMelfVppJ5EGQVG+6bER/iw2Eoc2yKyBSn6h40WrM mjK+EiVzW+wh54eb8Ys1OX+4B0YPZ4tnqA1Fr8ZBFdMKTQ5ekwKqZwxKpS/c1aO/lcFXWG8I IErapdwF4so28nzNW2gVTZMy2x+QeGW7Ok9LSS//A4xg6ccUckvR3VrCGpZKPJfFXVzp67fa bih+KtxrddFkxcTBrfkDUpqufNl8VheNBx5rNP/BdM4yOb0dqlUYmLRmpG+Er+9VIMHTZOd6 pDjRspvFgd/cNUomIzi8viTA8KLDEdNl2qdThlnQmIjUFFkON3BDbgaovTM964TF2UeK6Wxf w/gJjPtI9sa9p3Pyml9dpzeTCm2VyMk7LukRGi86u91LGQOv89SQhikgFJbyHChBJLixCrj1 anIpO+Pi4tpdT7umFCZTApsQWQt3+0Ul+SI8WEHP5n+yJpvX+PW0y6rctPQknFiVFHGlS1zY jKgoxztB0z1kMthCoktfoigk+XXfsf3M8fdYwWJqt6v25N3IDZY+0JtYC+1sNvXKYknEeo8K B/fEDVHDNdr2SrddfZXScTHkIVSnxfroZwjlb4gd+HwlXhdFyjJOhY7cWBH+mU3BeRZjfTrS +bOoIwVGL0yCUah7lggiUXetyFIBRqU2+ThYBxmu0R/op1ki3fQaaCC8E5BO96dd6p6Kx4D0 PeGGwT8dlv9cNH//D3lOPB9lbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjM1NTkKZW5kb2Jq CjMwIDAgb2JqCjw8L0xlbmd0aCAzMSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nO1c227cRgx936/Qm20gq6xW2pUWfeolKAr06mzR59pb147rW1Kn7W/0iyutrjweksNZ yS6KJkBgWqMZDoc8vAyVh2gRJ8toUf1tfzi/mT3MHqIiTqs/+18Nfz6/iT7bzl6fJquofGF7 MUv2v06izSLKF5s4WSfR9mZ2fH+yfTdbl0+2u9nx+4pI401L/1LRq3hZNPTH4eCrenDa0nfD h49D4kNFZPG6nSbav+maExc8B/p3aU3kvl6mlldF/6xMjjRucLdfrJ8Pmb0dMoOc/gb0X/XL eUu/AmaJjHCyy+FKuC0crEo7G0/YDfFHRRTxOnO9SVQDxbIbPiRznkl6QkY+wjmh+uHL/JqE 1Xt2GJ4AUQR+dtPBiSogiuNWGvknyMrEw/tasIt2skanCycbE20Ap21VL91sch+9vX5yPPNs uajmmydpXEymziJAiuJAtSEPL2B7eEQ4M658yTI8Ak73aqZBNUqcsIW4jIvze8BpcSY8PqQD AWkncY8nhjTOrJ2o6IXiIVso9G1F53G6dMlR3KB4Am507JfFl8WViOmhqDSH/wKe8Aw2i5tD bSCn96sTT8cPaJIeK0NimgzwPyeSKOE0j5cDNNWCzHvHwXQPGZ+ZccrDAzAKQwxSXS4oY04J QQMXwvH4nOAKTiYah6Zs55RxlOV4LunWW+p8qIQjxdyDvEn2gayJkH5a+4dFK6FPwV98W9Od gn8Bz8MVLBnyvBwSBSvLM0kiaKu4usMTEKtNF6tKDr3Z7n9dU1/Pjt+eHJWali99jtUE8NZ9 8GZKQFqMa8UcWANZnFmLTkwKKToeMhLlYnJZJuM2BUlEtDiTxjPvrzWeCARoMe8r1hRcrihj ZHgJ4IsskrlELQ7PlFDXNFdk8vbiSv4ewK6oQrDrITfeHZKXbypiw7BhUlTOuPI+ytIQUT+H Mqra76zHZ17inl6to0WvNp0ZjlFSwVPEaa4tKoEMkt2YINTHolctT84oWoj6TZwEekjNDiWg 1MpcYsjOhylitmqKvRilyTzPQ4vnPx6ic+SIkFH3TP1KovNFtdHiGK+4ZZ4WRYlHPSqJoZWo f9YSk3gdEZiQPHuUmDGb580AwRwmwnVNuZFXfn941CIW+8gxmrLhcZK53pqmvqhywd+dtCZi BVHdvxXzdngFHqL8qyr+CYurfOqMOEbNbAjnfOD/TjIbUzTorEGW0VsJkBmHk1aotlZID7bY QyNKh+B75UOe/U1Hu9xCuaI/JYdgwpp0+CYp34xXsRkp//K/thg1U/O/BvUM9fF8CDeEuJZ2 zC/g1kPtDssTh+4VxNWC5uZs2sefSIgg2rkpUkZP3XCZbvrUlrkDWBQ0W9USNfRIYujxNDIT FHGkHhZTbOSayW4ortQ7o+yMkHlPiiz8rZ/ofHCwlsZbjVq0aLB4YxZstWiPAv13YIXaNShK j1dyFIB2CcQHUFdgHmIgIt7TvoRx6xWvQTHPZHoNHCY5hUMGWP0sdmpfEx79i0bNA8lBhVzP Gjh7Y+xfAxd7Z8boEfKrZvoI5ZlKmdrt/ESV5PBrV21Zxi7ZWq3Js2pqPYLXGyOrOhReWo1Z 9ZCppT7GWl51GTIAU/+SXngGjOIk+ikW3Q66e/XMjbR6jljKsrZRa/fB5PDQoAKL/46GhWRV VHYJDQuvTzdRsqo2s72YLTeVpVbtC+nJUclFV7KPa7PNSP1pQH9e0UnS2/1djcxd/8NtTRek CltAT9Bgwkd4/wOMv6rHr9byeuz7zd675v95UoplXRWc8jJl6EZ07RzbUh5BnX9vKmLwJlaC vq81sWN0Dsr1tn7eCe6r+nlHf7Nnc8EgavjtAnkoBshiewN+EmCq107eukKm8e+fEg/82RuV Aoub//qLp0BobwA0lw+Lv53EZU23k/61AC2nQBrKGa3MB2mWq1G/BAYC+f4RudYJ7tGHy+wk /NscXnEaDGpJsda0Hr6Y/W+TFps05Q7PAb3oX/iI6Ke9o0zYG2RT2iN2IZCZRoUXcVkxIww/ f1MnHi8H3Dc5VUJo8X/L0AD6wrsFvRR6nqVJtX5I14apWR3rGbw2N2Fh7psa8+e7czDIFu3F e8mJQt1uvBzqOtoCeKv6T0SaTPE5Yx4jPUU/kMi8WP33nyagdZ7PzT2DSqzThd8QHlR9cx5/ zn+chFp4YMH/KQ6KB4Whjtb4b2q+bl5mC43ih3w/AjKRmU2FQLGSRaa1fpg13ffw1g8mR+q+ GgNjFcjT/OmInVh+ceOLR2/+fYThHw0HXIhD2X2gfOJNkKmnQDMo3HCrLEIZ3seg5X6op58l jNd88kxBqajwIoNi4du/oGBaU/Tcoi27Lg9Zd+PWFL7KZLrG1DRLc/OmL+pMKkcUiTkXzq3w 0ZYnnIVfTn0JQIjZlJxpOP+XD0H8pq5Je9fLPM3KreC9Tvnv0ezNNvphVv39B0eP2ddlbmRz dHJlYW0KZW5kb2JqCjMxIDAgb2JqCjE4MzAKZW5kb2JqCjUgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgovRm9udCAyMCAw IFIKPj4KL0NvbnRlbnRzIDYgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDI0IDAgUgo+PgovQ29udGVudHMgMjIg MCBSCj4+CmVuZG9iagoyNSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9Gb250IDI4IDAgUgo+PgovQ29udGVudHMgMjYgMCBSCj4+CmVuZG9iagoyOSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDMyIDAg Ugo+PgovQ29udGVudHMgMzAgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvS2lkcyBbCjUgMCBSCjIxIDAgUgoyNSAwIFIKMjkgMCBSCl0gL0NvdW50IDQKL1JvdGF0 ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKPj4K ZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUvTmFtZS9SNC9UUi9JZGVudGl0eT4+ CmVuZG9iagoxOSAwIG9iago8PC9SNAo0IDAgUj4+CmVuZG9iagoyMCAwIG9iago8PC9SOQo5 IDAgUi9SMTEKMTEgMCBSL1IxMwoxMyAwIFIvUjE1CjE1IDAgUi9SMTgKMTggMCBSPj4KZW5k b2JqCjI0IDAgb2JqCjw8L1I5CjkgMCBSL1IxMQoxMSAwIFIvUjE1CjE1IDAgUj4+CmVuZG9i agoyOCAwIG9iago8PC9SOQo5IDAgUi9SMTEKMTEgMCBSL1IxNQoxNSAwIFI+PgplbmRvYmoK MzIgMCBvYmoKPDwvUjkKOSAwIFIvUjE1CjE1IDAgUj4+CmVuZG9iagoxNyAwIG9iago8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1hPWFFEQitUVDEwQm8wMC9Gb250QkJveFsw IDAgMTg0MyAxNDU0XS9GbGFncyA0Ci9Bc2NlbnQgMTQ1NAovQ2FwSGVpZ2h0IDE0NTQKL0Rl c2NlbnQgMAovSXRhbGljQW5nbGUgMAovU3RlbVYgMjc2Ci9DaGFyU2V0KC9iYXJiMnJpZ2h0 KQovRm9udEZpbGUzIDE2IDAgUj4+CmVuZG9iagoxNiAwIG9iago8PC9TdWJ0eXBlL1R5cGUx Qy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzIDAgUj4+c3RyZWFtCnicY2RgYWJgZGQU iPCPCHRx0g4JMTRwyjcwAInJy3ExsHRoyHd3wxk87N3fpYTuCt7ivy4AUsKdlFiUZFSUmZ5R wsAAFGBgbGdgYmRk0ueTYb8uw278M1v0b+PPbNbfG9l+Kv3lZ5X59fa3jwyrMNtfEO87UBQk y8fAAAAx9CWcCmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTI4CmVuZG9iago4IDAgb2Jq Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSGVsdmV0aWNhLUJvbGQ+PgplbmRv YmoKOSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L0hlbHZldGljYS1Cb2xkL1R5 cGUvRm9udC9OYW1lL1I5Pj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvSGVsdmV0aWNhLUJvbGRPYmxpcXVlPj4KZW5kb2JqCjExIDAgb2JqCjw8 L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSGVsdmV0aWNhLUJvbGRPYmxpcXVlL1R5cGUvRm9u dC9OYW1lL1IxMT4+CmVuZG9iagoxMiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL1RpbWVzLUJvbGQ+PgplbmRvYmoKMTMgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9C YXNlRm9udC9UaW1lcy1Cb2xkL1R5cGUvRm9udC9OYW1lL1IxMz4+CmVuZG9iagoxNCAwIG9i ago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzLVJvbWFuPj4KZW5kb2Jq CjE1IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtUm9tYW4vVHlwZS9G b250L05hbWUvUjE1L0VuY29kaW5nIDM0IDAgUj4+CmVuZG9iagozNCAwIG9iago8PC9UeXBl L0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxMzMvZWxsaXBzaXMKMTQ2L3F1b3RlcmlnaHRdPj4K ZW5kb2JqCjE4IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvWE9YUURCK1RUMTBC bzAwL1R5cGUvRm9udC9OYW1lL1IxOC9Gb250RGVzY3JpcHRvciAxNyAwIFIvRmlyc3RDaGFy IDEvTGFzdENoYXIgMS9XaWR0aHNbIDk3OV0KPj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVj ZXIoR05VIEdob3N0c2NyaXB0IDcuMDUpCi9UaXRsZShNaWNyb3NvZnQgV29yZCAtIEFuYWx5 c2lzIG9mIEVBUC5kb2MpCi9DcmVhdG9yKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikKL0Ny ZWF0aW9uRGF0ZSg1LzI5LzIwMDMgMTQ6MTg6MzEpCi9BdXRob3IodXJpKT4+ZW5kb2JqCnhy ZWYKMCAzNQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMTMyOTcgMDAwMDAgbiAKMDAwMDAx NDg4NyAwMDAwMCBuIAowMDAwMDEzMjA4IDAwMDAwIG4gCjAwMDAwMTMzNDUgMDAwMDAgbiAK MDAwMDAxMjYxNiAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDM0NTcgMDAw MDAgbiAKMDAwMDAxNDA4NyAwMDAwMCBuIAowMDAwMDE0MTUxIDAwMDAwIG4gCjAwMDAwMTQy MjcgMDAwMDAgbiAKMDAwMDAxNDI5OSAwMDAwMCBuIAowMDAwMDE0Mzg0IDAwMDAwIG4gCjAw MDAwMTQ0NDUgMDAwMDAgbiAKMDAwMDAxNDUxOSAwMDAwMCBuIAowMDAwMDE0NTgxIDAwMDAw IG4gCjAwMDAwMTM4NTMgMDAwMDAgbiAKMDAwMDAxMzY0OSAwMDAwMCBuIAowMDAwMDE0NzQ5 IDAwMDAwIG4gCjAwMDAwMTM0MDAgMDAwMDAgbiAKMDAwMDAxMzQzMCAwMDAwMCBuIAowMDAw MDEyNzc2IDAwMDAwIG4gCjAwMDAwMDM0NzcgMDAwMDAgbiAKMDAwMDAwNzAyMCAwMDAwMCBu IAowMDAwMDEzNTA0IDAwMDAwIG4gCjAwMDAwMTI5MjAgMDAwMDAgbiAKMDAwMDAwNzA0MSAw MDAwMCBuIAowMDAwMDEwNjcyIDAwMDAwIG4gCjAwMDAwMTM1NTYgMDAwMDAgbiAKMDAwMDAx MzA2NCAwMDAwMCBuIAowMDAwMDEwNjkzIDAwMDAwIG4gCjAwMDAwMTI1OTUgMDAwMDAgbiAK MDAwMDAxMzYwOCAwMDAwMCBuIAowMDAwMDE0MDY3IDAwMDAwIG4gCjAwMDAwMTQ2NzIgMDAw MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAzNSAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgo+Pgpz dGFydHhyZWYKMTUwNjQKJSVFT0YK --------------010701050405000100090909-- From jari.arkko@piuha.net Thu May 29 20:08:04 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 29 May 2003 22:08:04 +0300 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: <20030529170003.30210.15379.Mailman@wolverine> Message-ID: <3ED65A94.6030509@piuha.net> Bernard Aboba wrote: >>We could (1) ignore such practise and pretend it doesn't exist or (2) >>change the definition to say that there may be a null, after which >>the Displayable Message ends a Non-Displayble message begins ;-) > > > Well, there apparently are some people who care about this and want to use > it for something. Perhaps if they spoke up we could determine what to do. > > Off the top of my head, I would think that an Appendix describing what is > currently done might be appropriate. It also might make sense to have an > IANA registry for the parameters so that interoperability is possible. > On the other hand, I could also see handling this issue in a separate > draft if it is determined that the effort to specify this is significant > (and RFC 2284bis might be delayed). Yes. If we want to find something in between, one approach would be to define that there may be a null character which terminates the Displayable Message, and that the contents beyond that are implementation specific. This would at least warn people not to go beyond the null, and leave the possibility for later to document the contents of that field. --Jari From jari.arkko@piuha.net Thu May 29 20:18:34 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 29 May 2003 22:18:34 +0300 Subject: [eap] Proposed Resolution to Issue 139: Response to Duplicate Requests In-Reply-To: References: Message-ID: <3ED65D0A.7050509@piuha.net> Bernard Aboba wrote: > To: > > "If a peer receives a valid duplicate Request for which it has > already sent a Response, it MUST resend its original Response > without reprocessing the Request. Requests MUST be processed > in the order that they are received. Ok. Maybe add "..., and MUST be processed to their completion before inspecting the next request" to make it 100% clear that there are no interrupts? --Jari From aboba@internaut.com Thu May 29 20:02:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 29 May 2003 12:02:03 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 139: Response to Duplicate Requests In-Reply-To: <3ED65D0A.7050509@piuha.net> References: <3ED65D0A.7050509@piuha.net> Message-ID: > Maybe add "..., and MUST be processed to their completion > before inspecting the next request" to make it 100% clear > that there are no interrupts? OK. Will add. From jari.arkko@piuha.net Thu May 29 20:26:12 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 29 May 2003 22:26:12 +0300 Subject: [eap] Proposed Resolution to Issue 141: Minor NITs In-Reply-To: References: Message-ID: <3ED65ED4.8090200@piuha.net> Ok. --Jari Bernard Aboba wrote: > The text of issue 141 is enclosed below. The proposed fixes are as > follows: > > In Section 5, change: > > "In this case, the input should be processed using an > appropriate stringprep [RFC3454] profile, and encoded in octets using > UTF-8 encoding [RFC2279]. A possible registered stringprep profile > is specified in [SASLPREP]." > > To: > > "In this case, the input should be processed using an > appropriate stringprep [RFC3454] profile, and encoded in octets using > UTF-8 encoding [RFC2279]. A preliminary version of a possible > stringprep profile is described in [SASLPREP]." > > In Section 1.3, change: > > "EAP Master key (MK) > A key derived between the EAP client and server during the > EAP authentication process that is purely local to the EAP > method. The MK MUST NOT be exported from the EAP method or > be made available to a third party. Since derivation of > the MK is a residue of the successful completion of the EAP > authentication exchange, proof of MK possession may be used > to shorten future EAP exchanges between the same EAP client > and server, a technique known as "fast resume". > > Master Session Key (MSK) > Keying material that is derived between the EAP client and > server. The MSK is used in the derivation of Transient > Session Keys (TSKs) for the ciphersuite negotiated between > the EAP peer and authenticator. Where a backend > authentication server is present, acting as an EAP server, > it will typically transport the MSK to the authenticator. > > The MSK differs from the MK in that it not assumed to > remain local to the EAP method, and is known by all parties > in the EAP exchange: the peer, authenticator and the > authentication server (if present). The MSK MAY be derived > from the MK via a one-way function, or it may be an > independent quantity. However possession of the MSK MUST > NOT provide any information useful in determining the MK. > > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client > and server that is exported by the EAP method. However, > unlike the MSK, the EMSK is known only to the EAP peer and > EAP server and MUST NOT be provided to a third party. The > EMSK therefore MUST NOT be transported by the backend > authentication server to the authenticator. The EMSK is > reserved for future uses that are not defined yet. For > example, it could be used to derive additional keying > material for purposes such as fast handoff, > man-in-the-middle vulnerability protection, etc." > > To: > > "Master Session Key (MSK) > Keying material that is derived between the EAP client and > server. The MSK is used in the derivation of Transient > Session Keys (TSKs) for the ciphersuite negotiated between > the EAP peer and authenticator. Where a backend > authentication server is present, acting as an EAP server, > it will typically transport the MSK to the authenticator, > so that in this case, the MSK is available to the peer, > authenticator and authentication server. > > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client > and server that is exported by the EAP method. Unlike > the MSK, the EMSK is known only to the EAP peer and > EAP server and is not provided to a third party. The EMSK is > reserved for future uses that are not defined yet. For > example, it could be used to derive additional keying > material for purposes such as fast handoff, > man-in-the-middle vulnerability protection, etc." > > In Section 7.10, change: > > "Non-overlapping substrings of the MSK MUST be cryptographically > separate from each other. This is required because some existing > ciphersuites form TSKs by simply splitting the MSK to pieces of > appropriate length. Likewise, non-overlapping substrings of EMSK > MUST be cryptographically separate from each other, and from > substrings of the MSK." > > To: > > "Non-overlapping substrings of the MSK MUST be cryptographically > separate from each other, as defined in Section 1.3. That is, knowledge > of one substring MUST NOT help in recovering some other substring without > breaking some hard cryptographic assumption. This is required because > some existing ciphersuites form TSKs by simply splitting the MSK to pieces > of appropriate length. Likewise, non-overlapping substrings of the EMSK > MUST be cryptographically separate from each other, and from > substrings of the MSK." > > --------------------------------------------------------------------- > Issue 141: Minor NITs > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: May 19, 2003 > Reference: > Document: EAP-03 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > - Section 5: "In this case, the input should be processed using an > appropriate stringprep [RFC3454] profile, and encoded in octets using > UTF-8 encoding [RFC2279]. A possible registered stringprep profile > is specified in [SASLPREP]." > > SASLPREP is not (yet) a registered stringprep profile. Proposed > text: "A preliminary version of a possible stringprep > profile is described in [SASLPREP]." > > - Section 1.3: I think it would be simpler if the terminology section > only defined the terms, but would not specify any requirements > for EAP implementations. At least, unnecessary duplication > of those requirements should be avoided. Here are some > proposed changes that would simplify 1.3 somewhat: > > - Master Session Key (MSK): delete second paragraph (similar text > was already deleted from 7.10) > - Delete "EAP Master key (MK)": no longer necessary since > the term is not used anywhere. > - Key derivation: Delete the last two sentences (unnecessary > duplication) > - Key strength: Delete (unnecessary duplication, since it's > already specified in main text) > - Extended Master Session Key (EMSK): Proposed replacement: > "Additional keying material that is derived between the EAP > client and server, reserved for future use." > - Cryptographic separation: delete. Instead, add to section 7.10, > 4th paragraph, after the first sentence: "That is, knowledge > of one substring MUST NOT help in recovering some other > substring without breaking some hard cryptographic assumption." > > [Jari Arkko] - In general I agree with what has been > stated in http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20141 > and support the proposed changes. However, I think the term "cryptographic > separation" should stay in the document, because the definition > is more precise than the suggested replacement. > > Also, regarding the MSK and EMSK, should we instead > move the normative language to the main body, not > delete it completely? > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Thu May 29 20:37:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 29 May 2003 12:37:27 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 134: EAP transport issues Message-ID: The text of Issue 134 is enclosed below. The proposed fix is as follows: In Section 4.1, delete "Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be computed as described in [RFC2988]. This includes use of Karn's algorithm to filter RTT estimates resulting from retransmissions. A maximum of 3-5 retransmissions is suggested. When run over a reliable lower layer (e.g., EAP over ISAKMP/ TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Note that in this case the peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. Where the authentication process requires user input, the measured round trip times are largely determined by user responsiveness rather than network characteristics, so that RTO estimation is not helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute)." Add Section 4.3: "4.3 Retransmission Behavior Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested. When run over a reliable lower layer (e.g., EAP over ISAKMP/ TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. Where the authentication process requires user input, the measured round trip times may be determined by user responsiveness rather than network characteristics, so that dynamic RTO estimation may not be helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). In order to dynamically estimate the EAP retransmission timer, the algorithms for estimation of SRTT, RTTVAR and RTO described in [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with the following potential modifications: a) When EAP is transported over a single link (as opposed to over the Internet), smaller values of RTOinitial, RTOmin and RTOmax MAY be used. Recommended values are RTOinitial=1 second, RTOmin=200ms, RTOmax=20 seconds. b) When EAP is transported over a single link (as opposed to over the Internet), estimates MAY be done on a per-authenticator basis, rather than a per-session basis. This enables the retransmission estimate to make the most use of information on link-layer behavior c) An EAP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared they should be initialized with the next RTT sample taken as described in [RFC2988] equation 2.2." ------------------------------------------------------------- Issue 134: EAP transport issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 15, 2003 Reference: Document: EAP-02 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: RFC 2988 doesn't include support for jittering, and includes a good deal of material that doesn't relate to EAP. As a result, more specific guidance is required in order to make it clear how dynamic retransmission timeout estimation is to be applied. From jari.arkko@piuha.net Thu May 29 21:27:25 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 29 May 2003 23:27:25 +0300 Subject: [eap] Proposed resolution to Issue 134: EAP transport issues In-Reply-To: References: Message-ID: <3ED66D2D.6020409@piuha.net> Looks good, thanks! --Jari Bernard Aboba wrote: > The text of Issue 134 is enclosed below. The proposed fix is as follows: > > In Section 4.1, delete > > "Because the authentication process will often involve user > input, some care must be taken when deciding upon > retransmission strategies and authentication timeouts. By > default, where EAP is run over an unreliable lower layer, the > EAP retransmission timer SHOULD be computed as described in > [RFC2988]. This includes use of Karn's algorithm to filter RTT > estimates resulting from retransmissions. A maximum of 3-5 > retransmissions is suggested. > > When run over a reliable lower layer (e.g., EAP over ISAKMP/ > TCP, as within [PIC]), the authenticator retransmission timer > SHOULD be set to an infinite value, so that retransmissions do > not occur at the EAP layer. Note that in this case the peer > may still maintain a timeout value so as to avoid waiting > indefinitely for a Request. > > Where the authentication process requires user input, the > measured round trip times are largely determined by user > responsiveness rather than network characteristics, so that RTO > estimation is not helpful. Instead, the retransmission timer > SHOULD be set so as to provide sufficient time for the user to > respond, with longer timeouts required in certain cases, such > as where Token Cards (see Section 5.6) are involved. > > In order to provide the EAP authenticator with guidance as to > the appropriate timeout value, a hint can be communicated to > the authenticator by the backend authentication server (such as > via the RADIUS Session-Timeout attribute)." > > Add Section 4.3: > > "4.3 Retransmission Behavior > > Because the authentication process will often involve user > input, some care must be taken when deciding upon > retransmission strategies and authentication timeouts. By > default, where EAP is run over an unreliable lower layer, the > EAP retransmission timer SHOULD be dynamically estimated. > A maximum of 3-5 retransmissions is suggested. > > When run over a reliable lower layer (e.g., EAP over ISAKMP/ > TCP, as within [PIC]), the authenticator retransmission timer > SHOULD be set to an infinite value, so that retransmissions do > not occur at the EAP layer. The peer may still maintain a > timeout value so as to avoid waiting indefinitely for a Request. > > Where the authentication process requires user input, the > measured round trip times may be determined by user > responsiveness rather than network characteristics, so that dynamic > RTO estimation may not be helpful. Instead, the retransmission timer > SHOULD be set so as to provide sufficient time for the user to > respond, with longer timeouts required in certain cases, such > as where Token Cards (see Section 5.6) are involved. > > In order to provide the EAP authenticator with guidance as to > the appropriate timeout value, a hint can be communicated to > the authenticator by the backend authentication server (such as > via the RADIUS Session-Timeout attribute). > > In order to dynamically estimate the EAP retransmission timer, > the algorithms for estimation of SRTT, RTTVAR and RTO described > in [RFC2988] are RECOMMENDED, including use of Karn's algorithm, > with the following potential modifications: > > a) When EAP is transported over a single link (as > opposed to over the Internet), smaller values of RTOinitial, > RTOmin and RTOmax MAY be used. Recommended values are > RTOinitial=1 second, RTOmin=200ms, RTOmax=20 seconds. > > b) When EAP is transported over a single link (as opposed > to over the Internet), estimates MAY be done on a > per-authenticator basis, rather than a per-session > basis. This enables the retransmission estimate to make the > most use of information on link-layer behavior > > c) An EAP implementation MAY clear SRTT and RTTVAR after > backing off the timer multiple times as it is likely that the > current SRTT and RTTVAR are bogus in this situation. Once SRTT and > RTTVAR are cleared they should be initialized with the next RTT > sample taken as described in [RFC2988] equation 2.2." > > > ------------------------------------------------------------- > Issue 134: EAP transport issues > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: May 15, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > > RFC 2988 doesn't include support for jittering, and includes a good deal > of material that doesn't relate to EAP. As a result, more specific guidance > is required in order to make it clear how dynamic retransmission timeout > estimation is to be applied. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From jari.arkko@piuha.net Fri May 30 15:27:42 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 30 May 2003 17:27:42 +0300 Subject: [eap] issue 121 (meaning of successful authentication) Message-ID: <3ED76A5E.9060400@piuha.net> We are in this discussion mainly because there are several factors that affect the final network access allowed or not -decision: the success of the authentication itself as well as various authorization checks related to the authenticated identity, time of day, phase of moon and so on. Still, these factors will result in one decision, and that decision must be communicated to the user. EAP in general lacks facilities for communicating the specific reason for the failure (or success for that matter) to the user, e.g. authenticated/authorized bits, specific extent of the authorization, and so on. What further complicates the picture is that there are EAP level indications (Success/Failure), AAA level indications (Accept/Reject), method level indications, and possibly some link level indications. We appear to have consensus that the various different indications should agree. That is, if we are going to fail the user based on an authz decision, we should do so at the method, EAP, and AAA layers. I agree with this, but note that there is one case where it seems hard to make these all agree: if it really is so that we must be able to fail an authentication and still provide restricted access, then it becomes very hard for a method to show agreement if that method is mutually authenticating and uses MICs. (Perhaps this is not a serious concern, if this case is documented.) Proposed text (search for "Here at the proposed fixes") on the issue site takes the approach of "toning down" the meaning of authentication, but does not explicitly mention the reasons why authentication is not exactly the same thing as in normal terminology. I am in favor of an explict explanation. In addition, we need text to explain the failed auth, succeeded authz case above. Finally, change "(e.g. where the peer may not be authorized for reasons of policy)" to "(e.g. due to a valid user not being authorized to get the requested service)". --Jari From jsalowey@cisco.com Sat May 31 01:05:58 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 30 May 2003 17:05:58 -0700 Subject: [eap] Re: submitting EAP-SIM document In-Reply-To: <3ED651C1.6010207@bell-labs.com> Message-ID: <005b01c32708$6a9b9a70$0200000a@amer.cisco.com> Hi Savar, Thank you for taking the time to look at the EAP-SIM draft. Your comments are valuable feedback. With respect to only 64 bits of security this is indeed a problem that has been overlooked (at least by me). I think the appropriate action would be to revise the draft to require the client to check to make sure the RAND values within a request are different. Also EAP-SIM most definitely relies upon the secrecy of Kcs to maintain session independence. As you point out, we must require that all triplets remain secret, because if an attacker obtains RAND and Kc then he or she can act as the network. This is discussed in several sections in the draft, but stronger wording on this fundamental assumption is probably warranted. In general I am less concerned about Kc exposure on the authenticator side than on the client side. This is because with EAP-SIM triplets do not have to leave the home domain to facilitate roaming authentication (EAP-SIM typically terminates in the home network) which is different than the VLR model in GSM. On the client side there are implementations that perform EAP-SIM calculations on the SIM card that prevent triplet exposure. Nonetheless it is still a serious consideration. Once again thanks for your time. I expect we will be updating the draft to address your comments in the near future. Regards, Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Uri Blumenthal > Sent: Thursday, May 29, 2003 11:30 AM > To: EAP mailing List > Cc: Sarvar Patel; 'S.Mizikovsky' > Subject: [eap] Re: submitting EAP-SIM document > > > Folks, > > My colleange Sarvar Patel asked me to post his analysis > of EAP-SIM draft. Here's the summary in short, and since > the entire paper (in PDF) is only 16 KB, I'm attaching > it to this posting. > > EAP-SIM specifies a mechanism for mutual authentication and > session key > agreement using the GSM-SIM and by proposing enhancement to the GSM > authentication procedures. Unfortunately, as we show it does not > succeed in its goal of providing 128 bit security from the current 64 > bit security of GSM. Furthermore, it does not provide session > independence between different sessions. For the first > problem, we are > able to provide solutions, but the second problem does not > seem solvable > in practice. > > From alper@docomolabs-usa.com Sat May 31 02:54:05 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Fri, 30 May 2003 18:54:05 -0700 Subject: [eap] issue 121 (meaning of successful authentication) In-Reply-To: <3ED76A5E.9060400@piuha.net> Message-ID: > We are in this discussion mainly because there are > several factors that affect the final network access > allowed or not -decision: the success of the authentication > itself as well as various authorization checks related > to the authenticated identity, time of day, phase of > moon and so on. Still, these factors will result in > one decision, and that decision must be communicated > to the user. EAP in general lacks facilities for > communicating the specific reason for the failure > (or success for that matter) to the user, e.g. > authenticated/authorized bits, specific extent of > the authorization, and so on. > > What further complicates the picture is that > there are EAP level indications (Success/Failure), AAA > level indications (Accept/Reject), method level indications, > and possibly some link level indications. > > We appear to have consensus that the various different > indications should agree. I think we should agree on the semantics of each one of these "indications". Do they all mean "authentication", or all "authorization", or a static mix of both, or a dynamic mix of both (e.g., method indication may mean auth or authz, depending on the method)? Once we separate which ones mean what, then yes, the same types should all agree. > That is, if we are going > to fail the user based on an authz decision, we should > do so at the method, EAP, and AAA layers. I agree with > this, but note that there is one case where it seems > hard to make these all agree: if it really is so that > we must be able to fail an authentication and still > provide restricted access, then it becomes very hard > for a method to show agreement if that method is > mutually authenticating and uses MICs. (Perhaps this > is not a serious concern, if this case is > documented.) > > Proposed text (search for "Here at the proposed fixes") > on the issue site takes the approach of "toning down" the > meaning of authentication, but does not explicitly mention > the reasons why authentication is not exactly the same > thing as in normal terminology. I am in favor of an > explict explanation. In addition, we need text to explain > the failed auth, succeeded authz case above. I agree to both. Alper > Finally, > change "(e.g. where the peer may not be authorized > for reasons of policy)" to "(e.g. due to a valid user > not being authorized to get the requested service)". > > --Jari > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >