diff options
Diffstat (limited to 'contrib/hostapd/doc/eap.doxygen')
-rw-r--r-- | contrib/hostapd/doc/eap.doxygen | 56 |
1 files changed, 0 insertions, 56 deletions
diff --git a/contrib/hostapd/doc/eap.doxygen b/contrib/hostapd/doc/eap.doxygen deleted file mode 100644 index f0f135a..0000000 --- a/contrib/hostapd/doc/eap.doxygen +++ /dev/null @@ -1,56 +0,0 @@ -/** -\page eap_module EAP server implementation - -Extensible Authentication Protocol (EAP) is an authentication framework -defined in RFC 3748. hostapd uses a separate code module for EAP server -implementation. This module was designed to use only a minimal set of -direct function calls (mainly, to debug/event functions) in order for -it to be usable in other programs. The design of the EAP -implementation is based loosely on RFC 4137. The state machine is -defined in this RFC and so is the interface between the server state -machine and methods. As such, this RFC provides useful information for -understanding the EAP server implementation in hostapd. - -Some of the terminology used in EAP state machine is referring to -EAPOL (IEEE 802.1X), but there is no strict requirement on the lower -layer being IEEE 802.1X if EAP module is built for other programs than -%wpa_supplicant. These terms should be understood to refer to the -lower layer as defined in RFC 4137. - - -\section adding_eap_methods Adding EAP methods - -Each EAP method is implemented as a separate module, usually as one C -file named eap_<name of the method>.c, e.g., eap_md5.c. All EAP -methods use the same interface between the server state machine and -method specific functions. This allows new EAP methods to be added -without modifying the core EAP state machine implementation. - -New EAP methods need to be registered by adding them into the build -(Makefile) and the EAP method registration list in the -eap_server_register_methods() function of eap_methods.c. Each EAP -method should use a build-time configuration option, e.g., EAP_TLS, in -order to make it possible to select which of the methods are included -in the build. - -EAP methods must implement the interface defined in eap_i.h. struct -eap_method defines the needed function pointers that each EAP method -must provide. In addition, the EAP type and name are registered using -this structure. This interface is based on section 4.4 of RFC 4137. - -It is recommended that the EAP methods would use generic helper -functions, eap_msg_alloc() and eap_hdr_validate() when processing -messages. This allows code sharing and can avoid missing some of the -needed validation steps for received packets. In addition, these -functions make it easier to change between expanded and legacy EAP -header, if needed. - -When adding an EAP method that uses a vendor specific EAP type -(Expanded Type as defined in RFC 3748, Chapter 5.7), the new method -must be registered by passing vendor id instead of EAP_VENDOR_IETF to -eap_server_method_alloc(). These methods must not try to emulate -expanded types by registering a legacy EAP method for type 254. See -eap_vendor_test.c for an example of an EAP method implementation that -is implemented as an expanded type. - -*/ |