Security The following sections specify security considerations for implementers of PEAP. Security Considerations for Implementers Fast Reconnect PEAP fast reconnect is desirable in applications such as wireless roaming. This feature allows sessions to be resumed without completing a full authentication. However, some issues that should be considered to introducing security vulnerabilities include: In cases where no identity is proved with an inner EAP method, implementers should ensure that the appropriate authorization checks are still performed for the session. To protect against risks associated with incorrectly assigning identity on fast reconnection scenarios, implementations should strongly tie identity information to the TLS session. That is, the PEAP implementation must determine the user identity even with a session resume. If it cannot do so, then it must not authorize access. The reason is that because no inner EAP authentication takes place during fast reconnect; proof of identity is based exclusively on the TLS session. Identity Verification Because the TLS session has not yet been negotiated, the initial identity request/response occurs in the clear, without integrity protection or authentication. It is therefore vulnerable to snooping and packet modification. If the initial EAP identity request/response has been tampered with, then, after the TLS session is established, it is conceivable that the PEAP server will discover that it cannot verify the peer's claim of identity. For example, the peer's user ID may not be valid or may not be within a handled by the PEAP server. In a case where the PEAP server is unable to validate the peer's identity claims, the PEAP server must abort the authentication. Moreover, it cannot be assumed that the peer identities presented within multiple packets will be the same. For example, the initial EAP-Response/Identity might correspond to a machine identity, while subsequent identities might be those of the user. Thus, PEAP implementations should not abort the authentication just because the identities do not match. However, because the initial EAP-Response/Identity determines the EAP server handling the authentication, if this or any other identity is inappropriate for use with the destination EAP server, there is no alternative but to terminate the PEAP conversation. Authentication Outcomes Because the cleartext EAP success or failure messages can be tampered with, implementations should rely only on the with status messages to determine the outcome of a session. Index of Security Parameters Security parameter Section Allowable EAP inner EAP method configuration Sections and
A Abstract data model peer ( 28, 36) server ( 28, 46) 15 C 26 27 26 15 72 20 Cryptobinding SoH processing no support 56 server and peer 60 server only 59 TLV data request from server to client 64 64 64 response from client to server 66 66 65 Cryptobinding and SoH processing no support successful PEAP 56 57 58 PEAP server and PEAP peer 62 successful PEAP 61 62 PEAP server only 59 59 21 D Data model - abstract peer ( 28, 36) server ( 28, 46) E 20 21 21 16 20 16 21 Examples cryptobinding SoH processing no support 56 server and peer 60 server only 59 TLV data request from server to client 64 64 64 response from client to server 66 66 65 cryptobinding and SoH processing no support successful PEAP 56 57 58 PEAP server and PEAP peer 62 successful PEAP 61 62 PEAP server only 59 56 F 15 G 7 H Higher-layer triggered events 39 29 48 29
I Implementer - security considerations 68 68 68 68 10 Initialization peer ( 29, 38) server ( 29, 48) 7 L Local events peer interface with EAP ( 35, 46) 35 overview ( 35, 45) TLS session 45 46 server EAP inner method authentication 55 55 interface with 35 35 35 TLS session 54 55 M Message processing peer 31 handling ( 29, 39) key management ( 34, 45) 40 30 39 phase 1 - TLS tunnel establishment ( 31, 39) 33 status ( 29, 39) 30 server 31 error handling ( 29, 48) key management ( 34, 54) 49 30 49 1 - TLS tunnel establishment ( 31, 48) 33 status ( 29, 48) 30 Messages 20 21 21 16 19 16 18 16 18 16 19 N 9 O 19 19 11 P 68 18 18 16 16 20 Peer abstract data ( 28, 36) 39 29 initialization ( 29, 38) local events interface with EAP ( 35, 46) 35 overview ( 35, 45) TLS session 45 46 message processing 31 error handling ( 29, 39) key management ( 34, 45) 40 30 39 phase 1 - TLS tunnel establishment ( 31, 39) 33 status ( 29, 39) 30 overview ( 28, 28)
sequencing rules 31 error handling ( 29, 39) key management ( 34, 45) 40 30 39 phase 1 - TLS tunnel establishment ( 31, 39) 33 status ( 29, 39) 30 timer events ( 35, 45) timers ( 29, 38) 15 15 69 Protocol Details 28 R 9 10 9 13 23 S Security implementer considerations 68 68 68 68 68 68 Sequencing peer 31 handling ( 29, 39) key management ( 34, 45) 40 30 39 phase 1 - TLS tunnel establishment ( 31, 39) 33 status ( 29, 39) 30 server 31 error handling ( 29, 48) key management ( 34, 54) 49 30 49 phase 1 - TLS tunnel establishment ( 31, 48) 33 status ( 29, 48) 30 Server abstract data model ( 28, 46) 48 29 initialization ( 29, 48) local events EAP inner method authentication 55 55 interface with 35 35 35 TLS session 54 55 message processing 31 handling ( 29, 48) key management ( 34, 54) 49 30 49 phase 1 - TLS tunnel establishment ( 31, 48) 33 status ( 29, 48) 30 overview ( 28, 28) sequencing rules 31 error handling ( 29, 48) key management ( 34, 54) 49 30 49 phase 1 - TLS tunnel establishment ( 31, 48) 33 status ( 29, 48) 30 timer events ( 35, 54) timers ( 29, 48) 24 25 24 25 15 T Timer events peer ( 35, 45) server ( 35, 54) Timers peer ( 29, 38) server ( 29, 48) 18 18 72 16 Triggered events - higher-layer 39 29 48 29