Abstract: A pre-shared key (PSK) updating method is disclosed. A first communication apparatus stores a first PSK for processing, within an aging periodicity of the first PSK, a packet exchanged between the first communication apparatus and a second communication apparatus. The first communication apparatus may receive, within the aging periodicity of the first PSK, a first protocol packet that is sent by the second communication apparatus and includes a first PSK key material for generating a second PSK. The second PSK is for processing, within an aging periodicity of the second PSK, a packet exchanged between the first communication apparatus and the second communication apparatus.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, processing time, and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: This application discloses a method for Internet key exchange protocol (IKE) authentication using a certificate. The method includes: A first device parses a certificate to obtain signature information in the certificate. The first device fills an AUTH payload field in an IKE identity authentication (AUTH) message based on the signature information in the certificate, where signature information indicated by the AUTH payload field matches the signature information in the certificate. The first device sends the IKE AUTH message to a second device. In the method for Internet key exchange protocol IKE authentication using a certificate provided in this application, the first device may automatically parse the signature information in the certificate, and fill the related field of the IKE AUTH message based on the signature information. Therefore, user configuration is simplified and product usability is improved.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, processing time, and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, more processing time and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, more processing time and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: This application discloses a method for Internet key exchange protocol (IKE) authentication using a certificate. The method includes: A first device parses a certificate to obtain signature information in the certificate. The first device fills an AUTH payload field in an IKE identity authentication (AUTH) message based on the signature information in the certificate, where signature information indicated by the AUTH payload field matches the signature information in the certificate. The first device sends the IKE AUTH message to a second device. In the method for Internet key exchange protocol IKE authentication using a certificate provided in this application, the first device may automatically parse the signature information in the certificate, and fill the related field of the IKE AUTH message based on the signature information. Therefore, user configuration is simplified and product usability is improved.

Abstract: The method includes: receiving, by a first member device, a second EAPOL-MKA packet sent by a second member device; determining, by the first member device, a first cipher suite, and determining a first secure association key SAK corresponding to the first cipher suite; and sending, by the first member device, the first cipher suite and the first SAK to the second member device in CA. Based on the foregoing technical solution, a device in the CA may determine a cipher suite and a secure association key corresponding to the cipher suite that are used for MACsec secure data transmission. In addition, all devices in the CA support the determined cipher suite. In this way, a problem that the cipher suite needs to be re-determined because one or more devices do not support the cipher suite determined by the first device can be avoided.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, more processing time and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: In the IKE or IPSec SA rekeying, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA is changed on both ends, e.g., the initiator and the responder. If the cryptographic suite is not changed, then the rekey exchange does not include the cryptographic suite. Additionally, in the IPSec SA rekey, if the flowing information is not changed in either end, the rekey exchange further does not include the Traffic Selector (TS). As such, the size of the payload is decreased, which saves bandwidth, more processing time and power in the course of the IKE SA or the IPSec SA rekey.

Abstract: Disclosed are a system, method and devices for simultaneous MACsec key agreement (MKA) negotiation between the devices. The present application controls a basic TLV message exchange between supplicant and authenticator in case of race condition to establish the secure association key (SAK) channel. The present application by controlling a basic TLV message exchange enables to establish a secure channel in race condition and achieves a high reliability of the product as this makes product launch MACsec services quickly and available for the service. Accordingly, when both sides (two supplicants) exchange hello with basic TLV at the same time, triggering the race condition, drops first message from the authenticator at supplicant and update the peer MN and the supplicant will not send reply. The authenticator when send next message (basic+potential peer TLV) with peer MN incremented by 1, the supplicant will respond with incremental message with live peer TLV.

Abstract: Disclosed are a system, method and devices for simultaneous MACsec key agreement (MKA) negotiation between the devices. The present application controls a basic TLV message exchange between supplicant and authenticator in case of race condition to establish the secure association key (SAK) channel. The present application by controlling a basic TLV message exchange enables to establish a secure channel in race condition and achieves a high reliability of the product as this makes product launch MACsec services quickly and available for the service. Accordingly, when both sides (two supplicants) exchange hello with basic TLV at the same time, triggering the race condition, drops first message from the authenticator at supplicant and update the peer MN and the supplicant will not send reply. The authenticator when send next message (basic+potential peer TLV) with peer MN incremented by 1, the supplicant will respond with incremental message with live peer TLV.

Abstract: Disclosed are a system, method and devices for simultaneous MACsec key agreement (MKA) negotiation between the devices. The present application controls a basic TLV message exchange between supplicant and authenticator in case of race condition to establish the secure association key (SAK) channel. The present application by controlling a basic TLV message exchange enables to establish a secure channel in race condition and achieves a high reliability of the product as this makes product launch MACsec services quickly and available for the service. Accordingly, when both sides (two supplicants) exchange hello with basic TLV at the same time, triggering the race condition, drops first message from the authenticator at supplicant and update the peer MN and the supplicant will not send reply. The authenticator when send next message (basic+potential peer TLV) with peer MN incremented by 1, the supplicant will respond with incremental message with live peer TLV.

Abstract: The method includes: receiving, by a first member device, a second EAPOL-MKA packet sent by a second member device; determining, by the first member device, a first cipher suite, and determining a first secure association key SAK corresponding to the first cipher suite; and sending, by the first member device, the first cipher suite and the first SAK to the second member device in CA. Based on the foregoing technical solution, a device in the CA may determine a cipher suite and a secure association key corresponding to the cipher suite that are used for MACsec secure data transmission. In addition, all devices in the CA support the determined cipher suite. In this way, a problem that the cipher suite needs to be re-determined because one or more devices do not support the cipher suite determined by the first device can be avoided.