aboutsummaryrefslogtreecommitdiffstats
path: root/doc/eap_server.doxygen
diff options
context:
space:
mode:
authorJouni Malinen <j@w1.fi>2009-11-28 19:19:48 (GMT)
committerJouni Malinen <j@w1.fi>2009-11-28 19:19:48 (GMT)
commit30c28971795f76502163e48225906bc45197635f (patch)
tree5a6b1ac5eccb181f4df26bcb7e9bc8320d4d4306 /doc/eap_server.doxygen
parente8f5625c453a03a95c0a68399476e148c07f537d (diff)
downloadhostap-30c28971795f76502163e48225906bc45197635f.zip
hostap-30c28971795f76502163e48225906bc45197635f.tar.gz
hostap-30c28971795f76502163e48225906bc45197635f.tar.bz2
Add new, shared doxygen documentation for hostapd and wpa_supplicant
Diffstat (limited to 'doc/eap_server.doxygen')
-rw-r--r--doc/eap_server.doxygen56
1 files changed, 56 insertions, 0 deletions
diff --git a/doc/eap_server.doxygen b/doc/eap_server.doxygen
new file mode 100644
index 0000000..4aca53d
--- /dev/null
+++ b/doc/eap_server.doxygen
@@ -0,0 +1,56 @@
+/**
+\page eap_server_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.
+
+*/