Sending this e-mail in behalf of Florent Bersani:
Hi Alan, Aurelien forwarded me your remark on the identity attribute format. Many thanks for taking the time to read it and giving some feedback. The main difference between EAP-SIM (as well as EAP-PSK) and EAP-TTLS attribute format (as pointed out by Michael Richardson earlier on this list) is that EAP-SIM uses a length field that encodes the length in multiple of 4 bytes whereas EAP-TTLS uses a length field that encodes the length in bytes, hence the padding differences. As Henry already said, I tend to think that this is essentially a matter of opinion, thus I do not think it is worth to engage in too much discussion. I'll try to confirm/infirm mine. Indeed, as contrary to EAP-SIM I am not bound with existing implementations, I might consider changing EAP-PSK to take your input into account :-) Anyway, the EAP-SIM attribute is not as error-prone as you seem to say, since, apart from the commercial applications, you have the open source open1X implementation (http://www.open1x.org/) that seems to work fine... and I believe Aurelien succeeded in implementing it for EAP-PSK :-) Some more comments in-line. Best regards, Florent > Subject: > Re: How does FreeRADIUS manage errors ? > From: > "Alan DeKok" <[EMAIL PROTECTED]> > Date: > Tue, 27 Apr 2004 13:33:20 -0400 > > To: > [EMAIL PROTECTED] > > >[EMAIL PROTECTED] wrote: > > >>> Many thanks for your remark, I have transfered it to >>> the EAP-PSK design team and they should come back to >>> you by tomorrow after having studied the TTLS design >>> you suggest. >> >> > > *Please* use the TTLS format. It's actually the Diameter format, >which has been around for ~6 years. It's been peer reviewed, and the >attribute design is included in published RFC's. > > > >>> However, when you say "If you want to convince people >>> to use your system, re-using existing code & design is >>> excellent practice", you seem quite unfair IMHO as the >>> EAP-PSK attribute design is precisely inspired by the >>> EAP-SIM AT-Identity attribute design >> >> > > EAP-SIM has not been peer reviewed. > I tend to disagree (or you have a different definition of peer than I do ;-), see for instance the following public reviews: http://mail.frascone.com/pipermail/public/eap/2003-June/001326.html http://mail.frascone.com/pipermail/public/eap/2003-September/001673.html http://mail.frascone.com/pipermail/public/eap/2003-November/001897.html http://mail.frascone.com/pipermail/public/eap/2003-December/002034.html BTW, you seem to have read it yourself ;-) >The author has been asked to >change the format, and has not done so. > I guess you are referring to Michael Richardson's review (http://mail.frascone.com/pipermail/public/eap/2003-September/001673.html) and Henry's answer (http://mail.frascone.com/pipermail/public/eap/2003-September/001680.html) > The protocol has *not* been >accepted by the IETF EAP group as a WG document, > I see a very good reason for that: the EAP WG is currently not chartered to standardize any EAP method. You can't put the blame technically on EAP-SIM for being merely out of the current EAP WG scope. > and most likely will >NEVER be published as an RFC. > > > That sounds quite interesting and contradictory to what Henry announced recently (see http://mail.frascone.com/pipermail/public/eap/2004-April/002421.html) Do you have any justification for your statement? Personally, considering for instance RFC 2026, I doubt you have any, which disappoints me very much of you :-( > If you want your protocol to be accepted and published as a >standard, using the TTLS/Diameter attribute format will help. Using >the EAP-SIM attribute format will not help. > > Alan DeKok. > > Subject: > Re: How does FreeRADIUS manage errors ? > From: > "Alan DeKok" <[EMAIL PROTECTED]> > Date: > Tue, 27 Apr 2004 11:08:17 -0400 > > To: > [EMAIL PROTECTED] > > > ... > > > PLEASE fix the protocol. PLEASE PLEASE fix the protocol. > >------ > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AT_IDRES | Length | Actual Identity Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : Identity : > : . : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >... > > The identity does not include any terminating null characters. > Because the length of the attribute must be a multiple of 4 bytes, > the sender pads the identity with zero bytes when necessary. >---- > > The "actual identity length" field is NOT needed. DELETE IT. >Having two lengths is a recipe for disaster. In fact, inventing a new >attribute format is a waste of time. > > See the EAP-TTLS draft for examples of a better attribute design. >It uses one length, padded fields, and there are NO problems. > > The extra bytes sent in the packets by using EAP-TTLS attributes >instead of your attribute design are *irrelevant*. The code savings, >development time, maintenance, decreased bugs, and decreased security >flaws caused by re-using existing code will be HUGE. > > e.g. You can steal the existing code in rlm_eap_ttls/ttls.c to >create/parse the attributes. You can define EAP-PSK-FOO attributes in >the dictionary, to re-use the existing VALUE_PAIR data structures. >The savings will be *significant*. > > If you want to convince people to use your system, re-using existing >code & design is excellent practice. > > Alan DeKok. > Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr�ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr�ce � Yahoo! Messenger !T�l�chargez Yahoo! Messenger sur http://fr.messenger.yahoo.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
