EAP peer implementation from wpa_supplicant as a library
Mon Dec 24 00:46:44 PST 2007
Jouni Malinen wrote:
>> - exposing TTLS TLV data to the server would be useful
>> - allowing the server to add TTLS TLV data would be useful
> I would assume you are referring to TTLS AVPs here. Would this be mainly
> to allow PAP/CHAP/MS-CHAP/MS-CHAPv2 to be implemented elsewhere or is
> there some additional AVPs that are commonly transmitted within TTLS?
Yes. There isn't any additional data inside of TTLS, but there are a
number of discussions about it.
>> - having method checks for PAP/CHAP/MS-CHAP in phase 2
>> like is done for the EAP methods would be useful
> I added a separate flags for this into struct eap_user (ttls_auth
> bitfield). This changed the default behavior from all non-EAP phase 2
> methods allowed to not allow any of them unless explicitly allowed in
> this bitfield.
>> - ability to completely control phase2 method would be good
>> i.e. run one EAP library for phase1, and another for phase2
>> it's weird, but it can catch corner cases and assumptions
> This would likely require larger changes, but then again, designing a
> nicer interface for this could also be useful from the view point of
> simplifying the current design where EAP-PEAP/TTLS/FAST have their own
> implementations.. This should probably also allow phase 2 to be proxied
> to an external host or at least have hooks in place for such
> functionality (i.e., having to wait for phase 2 reply).
Yes, exactly. I'll see if I can make some progress down that path.
More information about the Hostap