96x1H-IPI.5.1.240: 802.1X |
Approved
|
All of the display messages specified in this requirement will be displayed with the priority specified for 802.1X screens by 96x1COPS.7.2.200 in [7.1-4], unless otherwise specified.
Telephones that have a secondary Ethernet interface will forward (“pass-through”) all frames received on the Ethernet line interface or on the secondary Ethernet interface with the 802.1X Port Access Entity (PAE) group multicast address (01-80-C2-00-00-03) as the destination address to the other Ethernet port if and only if the value of the parameter DOT1X is “0” or “1”. If DOT1X has any other value, frames with the PAE group multicast address will not be forwarded between the Ethernet line interface and the secondary Ethernet interface.
|
Note:
|
802.1X frames are also called EAPOL frames, where EAPOL stands for Extensible Authentication Protocol over LAN.
|
Rationale:
|
Supporting pass-through of 802.1X frames allows an attached PC to authenticate with the network.
|
Approved
|
All EAPOL frames generated by the telephone will use the value 0000 0001 in the Protocol Version field.
|
Rationale:
|
Even though an 802.1X implementation conforming to the 2004 version of the standard is supposed to use a Protocol Version of 0000 0002, Broadcom has indicated that this resulted in interworking issues with existing implementations, so their implementation uses a Protocol Version of 0000 0001.
|
Approved
|
Telephones that have a secondary Ethernet interface will send a “proxy” EAPOL-Logoff frame on the Ethernet line interface if and only if the value of the parameter DOT1X is “1” and if link integrity is lost on the secondary Ethernet interface after at least one EAPOL frame that had the PAE group multicast address as the destination MAC address has been received on the secondary Ethernet interface. The destination MAC address of the proxy EAPOL-Logoff frame will be the PAE group multicast address, and the source MAC address will be the same as the source MAC address of the last frame received on the secondary Ethernet interface that had the PAE group multicast address as the destination MAC address.
|
Note:
|
A proxy Logoff frame may be sent whether or not the device attached to the secondary Ethernet interface was successfully authenticated, one will not be sent if the device sends EAPOL frames with a unicast destination address, and only one will be sent even if multiple devices were connected via a switch or hub. The multicast destination address is normally used in EAPOL-Start frames, but if the Authenticator initiates authentication and the device uses the Authenticator’s unicast address in subsequent messages, the telephone may not learn the device’s address in order to be able to send a proxy Logoff frame.
|
Note:
|
Based on the above, the following DOT1X modes will be supported:
0: PAE multicast pass-through without proxy Logoff (default)
1: PAE multicast pass-through with proxy Logoff
2: No PAE multicast pass-through or proxy Logoff
|
Rationale:
|
Support of proxy disconnect messages is important because network access switches normally put an access port back into unauthenticated state when they detect that a device has disconnected (to prevent an unauthenticated device from being plugged in subsequently), however, this would be undetectable for a device attached to an IP telephone’s secondary Ethernet interface. Proxy disconnect can also be circumvented by plugging a device into the phone through an additional switch or hub.
|
Approved
|
If and only if the value of the parameter DOT1X is “1”, if there is a delay between the time when the secondary Ethernet interface and the built-in Ethernet switch become active for forwarding frames and the time when frames received on the secondary Ethernet interface with the PAE group multicast address as the destination MAC address can be monitored, or if the telephone does not retain the MAC address of the device attached to the secondary Ethernet interface through a reset, or if the telephone cannot monitor the secondary Ethernet interface through a reset to ensure that a different device has not been connected, the link on the line interface and on the secondary Ethernet interface will be dropped for approximately one second when monitoring is started, before the Ethernet line interface speed is displayed (see 96x1H-IPI.3.1.100).
|
Rationale
|
Since 96x1H-IPI.3.1.100 requires that the secondary Ethernet interface be activated as soon as possible after power-up, it is possible that an attached device could be authenticated before the telephone is able to monitor the interface, and a subsequent loss of link on the secondary interface would not result in a proxy logoff being sent. Briefly dropping both the line and secondary Ethernet interfaces will force both the attached device and the Authenticator back to the Unauthenticated state so that the reauthentication can be monitored. This is done before the telephone authenticates (if it is going to) so that the telephone does not need to reauthenticate.
|
Approved
|
Supplicant operation and parameter values will be supported as specified in the 802.1X standard if and only if the value of the parameter DOT1XSTAT is not “0”. If DOT1XSTAT has any other value, Supplicant operation will not be supported.
|
Approved
for R6.3+
|
The parameter portValid will have a value of TRUE.
|
Rationale:
|
802.1X-2004 introduces the portValid parameter, and in spite of its definition in Section 8.2.2.2 of that standard, it must be set to TRUE for the Supplicant PAE state machine (Figure 8-17) to operate as indicated by Figure 8-7, i.e., for the Supplicant to assume that the port is authorized if it does not receive a response after the startPeriod timer expires after sending a third EAPOL-Start message and receiving no response, which allows operation if the Supplicant is enabled but the Authenticator is not.
|
Approved
|
IP telephones will respond to unicast EAPOL frames (frames with the telephone’s MAC address as the destination MAC address, and a protocol type of 88-8E hex) received on the Ethernet line interface if the value of DOT1XSTAT is “1” or “2”, but will only respond to EAPOL frames that have the PAE group multicast address as the destination MAC address if the value of DOT1XSTAT is “2”. If the value of DOT1XSTAT is changed to “0” from any other value after the Supplicant has been authenticated, an EAPOL-Logoff will be transmitted before the Supplicant is disabled.
|
Note:
|
Based on the above, the following 802.1X Supplicant operation modes will be supported based on the value of DOT1XSTAT:
0: Supplicant operation disabled (default)
1: Supplicant enabled, but responds only to received unicast EAPOL messages
2: Supplicant enabled, responds to received unicast and multicast EAPOL messages
|
Note:
|
When the Ethernet line interface link fails, the 802.1X Supplicant, if enabled, should enter the Disconnected state, as specified in the Supplicant PAE state machine in Section 8.2.11 of [7.2-7b].
|
Approved
|
All EAPOL frames generated by the telephone will not be tagged per IEEE 802.1Q
(see 96x1H-IPI.5.1.220), will use the PAE group multicast address as the destination address, and will be forwarded only to the Ethernet line interface.
|
Note:
|
Section 7.4 of 802.1X-2004 states that EAPOL frames transmitted by a PAE shall not be VLAN tagged, but may optionally be priority tagged, and that all PAEs shall be capable of receiving both priority tagged and untagged EAPOL frames.
|
Note:
|
Section 7.8 of 802.1X-2004 states that on IEEE 802.3 LANs, the reserved PAE group address be used as the destination MAC address. While the telephones will do this as specified above, for multiple Supplicants to be supported on a port, the Authenticator must use unicast destination MAC addresses.
|
Approved
|
The 802.1X Supplicant variable userLogoff will normally have a value of FALSE, although it may be briefly set to TRUE to force a state transition.
|
Rationale:
|
802.1X is used to authenticate the telephone device, not the end user, so the value of userLogoff should not be linked to the registration of a user or an extension number with a call server. However, briefly toggling the value of userLogoff may be used as a way to force the Supplicant into the LOGOFF state and then into the DISCONNECTED state, which then automatically transitions into the CONNECTING state, in which the Supplicant resumes sending EAPOL-Start messages.
|
Approved
|
All EAPOL frames received on the secondary Ethernet interface will be ignored by the telephone (except to learn the source MAC address as specified for “proxy” logoff, above), and forwarding (or not) between the Ethernet line interface and the secondary Ethernet interface will be controlled as specified above for pass-through.
The 802.1X Port Access Control MIB (see Section 10.6 of [7.2-7b]) will not be supported.
EAP (Extensible Authentication Protocol) with MD5-Challenge authentication will be supported as specified in IETF RFC 3748 [7.3-19i]
|
Approved
for R6.2.1+
|
if the value of DOT1XEAPS is "MD5".
EAP-TLS will be supported as specified in RFC 2716 [7.3-19f] if the value of DOT1XEAPS is "TLS". Other TLS requirements specified in 96x1H-IPI.5.1.1500 also apply.
If an EAP method requires the authentication of a network certificate, the requirements specified in 96x1H-IPI.5.1.1550 also apply.
|
Note:
|
An identity certificate is required for successful use of EAP-TLS (see 96xxIPI.5.1.1600).
|
Approved
|
A Supplicant identity and a password will be supported, each of which may have a length of up to 12 ASCII characters, that will be stored in non-volatile memory that will not be overwritten if new telephone software is downloaded. The default value of the identity will be the value of MACADDR (see 96x1H-IPI.2.1.100) without the colon separators. The default value of the password will be null. The identity and password will be set to their default values at manufacture.
The identity will be used in the Type-Data field of EAP-Response/Identity frames, and the password will be used only if the EAP method requires one. For EAP-MD5, the password will be used to compute the digest for the Value field of the Type-Data field of EAP-Response/MD5-Challenge frames (the Name field will be empty).
|
Note:
|
Even though the default value of the identity can contain alphabetic characters A-F (since the MAC address is converted to hexadecimal ASCII format), if one of these characters is deleted using the manual editing procedures specified below, it cannot be re-entered. To restore the default value, the RESET or CLEAR procedure would have to be used to reset values.
|
Note:
|
The stored credentials should continue to be used for EAP-Responses while the following credential entry screens are being displayed.
|
Note:
|
The default credentials will be used when a new telephone is first plugged in, so MD5 authentication will fail because the password is null (whether or not the default identity is correct), an EAP-Failure message will be received in response, and the credential entry screens will be displayed as specified below.
|
Approved
|
If an EAP-failure frame is received in response to the first authentication attempt after a power-up or a reset when
|
Approved
for R6.3+
|
either the EAP method in use does not require a password or when the EAP method in use does require a password and
|
Approved
|
the password is null, the following will be displayed on the reserved text lines:
|
|
|
802.1X ID=ddd...
#=OK New=|
|
|
|
where “ddd…” is the value of the identity and “|” is the cursor.
|
|
The numeric-only text entry requirements of 96x1H-IPI.3.2.100 apply.
If the ‘#’ button is pressed while the input buffer is not null, the contents of the input buffer will be used as the identity. If the ‘#’ button is pressed while the input buffer is null, the current value of the identity will be used. If the ‘*’ button or any other button on the telephone that is not valid for numeric-only text entry is pressed, error beep tone will be generated (see AUDIO.210.300 [7.1-11]) and the cursor will remain where it is. If the ‘#’ button is pressed
|
Approved
for R6.3+
|
and the EAP method in use does not require a password, the following will be displayed on the reserved text lines:
|
|
|
Waiting for 802.1X
authentication...
|
|
|
If the ‘#’ button is pressed and the EAP method in use does require a password,
|
Approved
|
a password-entry screen will be displayed on the reserved text lines as specified below.
|
|
|
Password=|
#=OK
|
|
|
where “|” is the cursor. The numeric-only password text entry requirements of 96x1H-IPI.3.2.100 apply. If the ‘#’ button is pressed while the input buffer is null, or if the ‘*’ button or any other button on the telephone is pressed, error beep tone will be generated and the cursor will remain where it is.
|
|
If the ‘#’ button is pressed while the input buffer is not null, the contents of the input buffer will be used as the password and the following will be displayed on the reserved text lines:
|
|
|
Waiting for 802.1X
authentication...
|
|
|
The Supplicant will then be returned to the CONNECTING state.
|
Note:
|
One way to return the Supplicant to the CONNECTING state is to briefly change the value of userLogoff to TRUE, which causes the Supplicant to enter the LOGOFF state and to send an EAPOL-Logoff frame, and then to change the value of userLogoff back to FALSE, which causes the Supplicant to move to the DISCONNECTED state, reinitialize values, and then move to the CONNECTING state.
|
Rationale:
|
Returning the Supplicant to the CONNECTING state causes it to start sending EAPOL-Start messages immediately, although the Authenticator may remain in the HELD state until its quietWhile timer expires. Sending an EAPOL-Start frame when the user enters new credentials will avoid any unnecessary delays due to the heldPeriod (default value = 60 seconds) or startPeriod (default value = 30 seconds) timers and brings the Supplicant back to a known state.
|
Approved
|
“Waiting for 802.1X authentication...” will also be displayed if a Request/Identity message is received when the Supplicant is enabled but not yet authenticated, as long as no other 802.1X-related text is already being displayed.
|
Rationale:
|
The Authenticator will send Request/Identity messages even if the Authentication Server is not functioning or is unreachable.
|
Approved
|
If the authentication is successful, the identity and, if used, the password, will be saved in non-volatile memory if the values used are different than the stored values, and the user interface will be restored to its previous state.
|
|
If the Supplicant times out waiting for an EAPOL frame from the Authenticator, or if an EAP-Failure frame is received after an authentication attempt during the procedures specified in 96x1H-IPI.3.1.100 while neither the 802.1X ID entry screen nor the 802.1X Password entry screen is being displayed, if
|
Approved
for R6.3+
|
either the EAP method in use does not require a password or the EAP method in use does require a password and
|
Approved
|
the stored password is not null, or if the stored password is null but more than one authentication attempt has been made since the telephone powered-up or reset, the name/logo image will be displayed as specified in 96x1H-IPI.3.1.100 (if it is not already being displayed), the following will be displayed on the reserved text lines:
|
|
|
802.1X failure
# to Continue
|
|
|
and the “#” button on the dial pad, if pressed, will be interpreted as a command to display the “802.1X ID” entry screen as specified above. Error beep tone will be generated in response to all other button presses.
|
|
If and only if an EAP-Failure frame is received after an authentication attempt made after the procedures specified in 96x1H-IPI.3.1.100 are complete, and only if an 802.1X Authentication interrupt screen is not already being displayed, an 802.1X Authentication interrupt screen will be displayed as specified by 96x1COPS.7.2.100 in [7.1-4] and below.
|
Approved
for R6.0
|
“802.1X” will be displayed on the Title Line and “Failed, try again” will be displayed on the Prompt Line.
|
Approved
for R6.1+
|
“802.1X Failed, try again” will be displayed on the Status Line.
|
Approved
|
“Device ID: ” followed by a user-input field (see 96x1COPS.4.1.400 and 96x1COPS.4.1.450 in [7.1-4]), will be displayed left-justified on the first available Application Line, with the current identity pre-populated in the field, and
|
Approved
for R6.3+
|
if the EAP method in use requires a password,
|
Approved
|
“Password: ” followed by a user-input field, will be displayed left-justified on the next available Application Line, and this field will be active for text entry. The current password will not be pre-populated in the field.
The user input fields will both have a field type of Number (see 96x1COPS.4.1.300 in [7.1-4]), although the Device ID field must also be able to display, but not allow user entry of, alphabetic characters A-F. Telephones without a touchscreen will label softkeys as specified by 96x1COPS.4.1.200 in [7.1-4], except that there will not be a softkey labeled Cancel, Symbol, 123, ABC or Case, the label Save will be changed to Enter, and it will only be present when at least one character is in each user-input field. Telephones with a touchscreen will display an Enter softkey only when at least one character is in the user-input field.
|
|
If Enter is pressed, the Supplicant will be returned to the CONNECTING state, the credentials entered by the user will be used in subsequent response messages, and the 802.1X Authentication interrupt screen will be replaced by an 802.1X Waiting interrupt screen displayed as specified in 96x1COPS.7.2.100 in [7.1-4] and below.
|
Approved
for R6.0
|
“802.1X” will be displayed on the Title Line. No text will be displayed on the Prompt Line.
|
Approved
for R6.1+
|
“802.1X” will be displayed on the Status Line.
|
Approved
|
The following text will be displayed, centered in the application area:
Authenticating…
No softkeys will be labeled.
The 802.1X Waiting interrupt screen will be removed if and only if an EAP-Success or an EAP-Failure frame is received. If the authentication is successful, the identity and password will be saved in non-volatile memory if the values used are different than the stored values.
|
Directory: public -> downloadFile.jsp?file= -> resources -> sites -> AVAYA -> content -> live -> SOLUTIONSpublic -> The german unification, 1815-1870public -> Preparation of Papers for ieee transactions on medical imagingpublic -> Harmonised compatibility and sharing conditions for video pmse in the 7 9 ghz frequency band, taking into account radar usepublic -> Adjih, C., Georgiadis, L., Jacquet, P., & Szpankowski, W. (2006). Multicast tree structure and the power lawpublic -> Duarte, G. Pujolle: fits: a flexible Virtual Network Testbed Architecturepublic -> Swiss Federal Institute of Technology (eth) Zurich Computer Engineering and Networks Laboratorypublic -> Tr-41. 4-03-05-024 Telecommunicationspublic -> Chris Young sets 2016 “I’m Comin’ Over” Tour headlining datesSOLUTIONS -> CM: How to enable 'auto answer' feature
Share with your friends: |
