Penguin

Differences between current version and previous revision of EAP.

Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History

Newer page: version 2 Last edited on Tuesday, August 23, 2005 11:39:14 am by CraigBox
Older page: version 1 Last edited on Tuesday, August 23, 2005 11:26:57 am by CraigBox Revert
@@ -1,17 +1,11 @@
 [Acronym] for __E__xtensible __A__uthentication __P__rotocol. 
  
-Specified in RFC:2284, EAP is a method of conducting an authentication conversation between a client (called a __supplicant__) and an authentication server. Intermediate devices such as AccessPoint~s and ProxyServer~s do not take part in the conversation. Their role is to relay EAP messages between the parties performing the authentication
+Specified in RFC:2284, EAP is a method of conducting an authentication conversation between a client (called a __supplicant__) and an authentication server. Intermediate devices such as AccessPoint~s and ProxyServer~s do not take part in the conversation - they simply relay EAP messages between the endpoints
  
-EAP messages are transported between a wireless station and an [802.1X] Authenticator using __EAPOL__ (EAP __o__ver __L__an). The EAP messages are transported between an 802.1X Authenticator and the Authentication Server using [RADIUS]. The EAP framework supports the definition of EAP-Type Authentication Methods. Currently implemented EAP-Type Authentication Methods include EAP-MD5, EAP-TLS, EAP-TTLS, EAP-PEAP, and Cisco’s EAP-LEAP.  
-  
- ; EAP-AKA : An EAP type for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) mechanism.UMTS AKA is based on symmetric keys, and runs typically in a UMTS Subscriber Identity Module, a smart card like device.EAP-AKA includes optional identity privacy support and an optional re-authentication procedure.  
-; EAP-LEAP : EAP-Lightweight Extensible Authentication Protocol is a [Cisco] [Proprietary] EAP-Type. It is designed to overcome some basic wireless authentication concerns through Mutual Authentication and the use of dynamic WEP keys.  
-; EAP-MD5 : An EAP-Type for authentication. It is analogous to the PPP CHAP protocol. A challenge string is sent from the Authentication Server to the Supplicant in the MD5-Challenge Request. The challenge string with the user password is hashed using MD5 and the hash is returned in the MD5-Challenge Response. The Authentication Server performs the same hash and compares the result with that returned by the Supplicant to determine whether the authentication is a Success or Failure. EAP-MD5, as defined in RFC 2284, is the most basic EAP-Type, which must be supported by all implementations of EAP. It is not a strong authentication method and does not support dynamic WEP keys.  
-; EAP-PEAP : Protected Extensible Authentication Protocol is a two-phase authentication like EAP-TLS. In the first phase the Authentication Server is authenticated to the Supplicant using an X.509 certificate. Using TLS, a secure channel is established through which any other EAP-Type can be used to authenticate the Supplicant to the Authentication Server during the second phase. A certificate is only required at the Authentication Server. EAP-PEAP also supports identity hiding where the Authenticator is only aware of the anonymous username used to establish the TLS channel during the first phase but not the individual user authenticated during the second phase.  
-; EAP-SIM : An EAP type for authentication and session key distribution using the GSM Subscriber Identity Module ([SIM]). The mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets.The mechanism also includes network authentication, user anonymity support and a re-authentication procedure.  
-  
-; EAP-TLS : An EAP-Type for authentication based upon X.509 certificates. Because it requires both the Supplicant and the Authentication Server to have certificates, it provides explicit Mutual Authentication and is resilient to man-in-the-middle attacks. After successful authentication a secure TLS link is established to securely communicate a unique session key from the Authentication Server to the Authenticator. Because X.509 certificates are required on the Supplicant, EAP-TLS presents significant management complexities.  
-  
-; EAP-TTLS : EAP Tunneled [TLS] is an EAP-Type for authentication that employs a two-phase authentication process. In the first phase the Authentication Server is authenticated to the Supplicant using an X.509 certificate. Using TLS, a secure channel is established through which the Supplicant can be authenticated to the Authentication Server using legacy PPP authentication protocols such as PAP, CHAP, and MS-CHAP. EAP-TTLS has the advantage over EAP-TLS that it only requires a certificate at the Authentication Server. It also makes possible forwarding of Supplicant requests to a legacy RADIUS server. EAP-TTLS also supports identity hiding where the Authenticator is only aware of the anonymous username used to establish the TLS channel during the first phase but not the individual user authenticated during the second phase.  
-  
-(Adapted from [Interlink Networks|http://www.interlinknetworks.com/support/faq7-1-2.htm]). Probably not CC licensed in current state. Please gnome.  
+; EAP-AKA : AddToMe  
+; EAP-LEAP : AddToMe  
+; EAP-MD5 : AddToMe  
+; EAP-PEAP : AddToMe  
+; EAP-SIM : AddToMe  
+; EAP-TLS : AddToMe  
+; EAP-TTLS : AddToMe