> Adam Haberlach <[EMAIL PROTECTED]> wrote: > > I'm interested in seeing this happen, and can contribute some coding > > and testing time to this if someone points me towards documentation. I'm > > familiar with the basics of EAP (and have set up and tested FR and EAP-TLS).
I've been reading the code of EAP and EAP-TLS for some time. I'm also interested, and I'd like to contribute some coding and testing time too. > > My main concern right now is to re-arrange the code in rlm_eap_tls > so that it can be used by the proposed TTLS and PEAP modules. Once > that's done, TTLS and PEAP can be done by almost anyone. > > If you have sufficient equipment and skills to do that, then it > would be great. See 'xsupplicant' for an example of how it has a > simple TTLS module, which is uses TLS to do most of the work. > > e.g. The TLS code needs to do it's TLS work, and return any > application-layer data in a data structure. The existing rlm_eap_tls > module will then become a thin shim layer, which calls the 'decode > TLS' functions, and then looks at the application data. > > TTLS and PEAP will then be almost exactly the same as the re-written > TLS module. Yes I believe you are correct. Much code of EAP-TLS can be used by TTLS or PEAP. I think the major difference between EAP-TTLS and EAP-TLS is the second phase (i.e. the "tunnel" phase). Once the handshake is successful, the TTLS server should extract AVPs from the TLS records and append them to the RADIUS packet. Is my understanding correct? > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > â²Ø§~?ì¹» ®&Þþéì¹» ®&ÞI硶Úÿ 0~·ž§bºÊ+ƒùb²ßî±êì†Ù¥
