EAP peer implementation from wpa_supplicant as a library

[Jouni Malinen]

On Sun, Dec 09, 2007 at 07:31:36PM +0100, Alan DeKok wrote:

>   The interface right now looks pretty good.  Some comments:
> 
>  - 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?

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

-- 
Jouni Malinen                                            PGP id EFC895FA