EAP peer implementation from wpa_supplicant as a library

[Alan DeKok]

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.

  OK, thanks.

>>  - 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.

  Alan DeKok.