Brocade FastIron Ethernet Switch Security Configuration Guide - Manual (Page 175)

authentication server to protect messages from unauthorized users’ eavesdropping activities. Since
EAP-TLS requires PKI digital certificates on both the clients and the authentication servers, the roll
out, maintenance, and scalability of this authentication method is much more complex than other
methods. EAP-TLS is best for installations with existing PKI certificate infrastructures.
• EAP-TTLS (Internet-Draft) - The EAP Tunnelled Transport Level Security (TTLS) is an extension of
EAP-TLS Like TLS, EAP-TTLS provides strong authentication; however it requires only the
authentication server to be validated by the client through a certificate exchange between the server
and the client. Clients are authenticated by the authentication server using user names and
passwords.
A TLS tunnel can be used to protect EAP messages and existing user credential services such as
Active Directory, RADIUS, and LDAP. Backward compatibility for other authentication protocols such as
PAP, CHAP, MS-CHAP, and MS-CHAP-V2 are also provided by EAP-TTLS. EAP-TTLS is not
considered foolproof and can be fooled into sending identity credentials if TLS tunnels are not used.
EAP-TTLS is suited for installations that require strong authentication without the use of mutual PKI
digital certificates.
• PEAP (Internet-Draft) - Protected EAP Protocol (PEAP) is an Internet-Draft that is similar to EAP-
TTLS. PEAP client authenticates directly with the backend authentication server. The authenticator
acts as a pass-through device, which does not need to understand the specific EAP authentication
protocols.
Unlike EAP-TTLS, PEAP does not natively support user name and password to authenticate clients
against an existing user database such as LDAP. PEAP secures the transmission between the client
and authentication server with a TLS encrypted tunnel. PEAP also allows other EAP authentication
protocols to be used. It relies on the mature TLS keying method for its key creation and exchange.
PEAP is best suited for installations that require strong authentication without the use of mutual
certificates.
Configuration for these challenge types is the same as for the EAP-MD5 challenge type.
NOTE
If the 802.1X Client will be sending a packet that is larger than 1500 bytes, you must enable jumbo at
the Global config level of the CLI. If the supplicant or the RADIUS server does not support jumbo
frames and jumbo is enabled on the switch, you can set the CPU IP MTU size. Refer to
Setting the IP
MTU size on page 175, next.
Setting the IP MTU size
When jumbo frames are enabled on a FastIron device and the certificate in use is larger than the
standard packet size of 1500 bytes, 802.1X authentication will not work if the supplicant or the RADIUS
server does not support jumbo frames. In this case, you can change the IP MTU setting so that the
certificate will be fragmented before it is forwarded to the supplicant or server for processing. This
feature is supported in the Layer 2 switch code only. It is not supported in the Layer 3 router code.
To enable this feature, enter commands such as the following:
device(config)# interface ethernet 3/1
Brocade(config-if-e1000-3/1)# ip mtu 1500
Syntax: [no] ip mtu num
The num parameter specifies the MTU. Ethernet II packets can hold IP packets from 576 - 1500 bytes
long. If jumbo mode is enabled, Ethernet II packets can hold IP packets from 576 - 10,218 bytes long.
Ethernet SNAP packets can hold IP packets from 576 - 1492 bytes long. If jumbo mode is enabled,
SNAP packets can hold IP packets from 576 to 10,200 bytes long. The default MTU is 1500 for Ethernet
II packets and 1492 for SNAP packets.
Setting the IP MTU size
FastIron Ethernet Switch Security Configuration Guide 175
53-1003088-03