Research Disclosure no longer supports Internet Explorer

AUTHENTICATION WITHOUT CURRENT TIME BACKGROUND Public-key cryptography is based on a pair of related keys: a private key that is kept secret by the owner, and a public key that can be disseminated widely. Another party may encrypt a message to the key-pair owner using the available public key, so that only the owner is able to decrypt the message using the secret private key. Even if third parties intercept the message in transit, they are unable to decrypt it with the available public key. Public keys are also used for various security certificates. For example, a public key certificate (also known as a “digital certificate”) is an electronic document used to prove validity of a user’s public key. The certificate includes the public key, information about the public key and the identity of its owner (or “subject”), and a digital signature of an issuer (or “certificate authority”) that has verified the certificate's contents. If another user trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject using the public key. X.509 is an International Telecommunication Union (ITU) standard that defines the format of public key certificates (often referred to as “X.509 certificates”) used in many applications and Internet security protocols. These are further specified in Internet Engineering Task Force (IETF) specification RFC 5280 entitled “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” For example, X.509-compliant certificates are specified for use in IETF RFC 4301 (entitled “Security Architecture for Internet Protocol”), IETF RFC 8446 (entitled “Transport Layer Security Protocol 1.3”), IETF RFC 5216 (entitled “EAP-TLS Authentication Protocol”), and IETF RFC 9190 (entitled “EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3”). In general, these protocols specify X.509-compliant certificates to be used in mutual authentication between peer nodes (often referred to as “node A” and “node B”). However, they also specify X.509-compliant certificates to be used in the common asymmetrical case when node A has already been authenticated by other node(s) but B is not yet authenticated. In such a case, the primary need for authentication is to prevent intrusion by requesting node A to authenticate node B, while the authentication of node A by node B is less important. The certificate authority (CA) is responsible for lifecycle management (LCM) of certificates, such as issuing new certificates, revocation of existing certificates, etc. The issuing CA is referred to as a certificate’s “root of the trust”. X.509 public key certificates contain a field named “validity period” that indicates the duration when a certificate is valid. When a certificate is issued by a CA, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to expiration of the validity period. Under such circumstances, the CA needs to revoke the certificate. SUMMARY According to IETF RFC 5280, one mandatory step when validating a certificate is to verify that the certificate’s validity period includes the current time and date. However, a node (e.g., node B) is unable to validate the certificate presented by another node (e.g., node A) when node B has no reliable time source. For example, this may be the case during initial installation of node B or during node B’s recovery after a power failure, particularly when node B’s only source of time is via communication with another node (e.g., node A). This lack of available time source needed to perform certificate validation may cause a network operator to disable authentication between nodes, which opens the network to various undesirable security risks. An object of embodiments of the present disclosure is to facilitate certificate validation and mutual authentication by a node without a reliable time source when validation is initiated, thereby addressing exemplary problems summarized above and described in more detail below. Some embodiments include methods (e.g., procedures) for a second node of a communication network (e.g., 5G network). These exemplary methods include obtaining a first security certificate associated with a first node of the communication network. The first security certificate includes the following: a first field indicating a validity duration for the security certificate, and one or more other fields. These exemplary methods also include provisionally validating the first security certificate based on verifying the one or more other fields without verifying the first field. These exemplary methods also include, based on the provisional validation, obtaining a current time from the first node. These exemplary methods also include validating the first security certificate based on verifying that the current time is within the validity duration indicated by the first field. In some embodiments, these exemplary methods also include the following operations:  initializing the first node’s time reference based on a current time obtained previously from the first node; and  restarting operation such that the first node’s time reference is lost or discarded. In such case, obtaining the first security certificate is responsive to restarting operation. In some embodiments, the current time is obtained from the first node via one of the following: network time protocol (NTP), or precision time protocol (PTP). In some embodiments, the first security certificate is obtained via IEEE 802.1X protocol. In some embodiments, the first node is a first gNodeB (gNB) and the second node is a second gNB. In other embodiments, the first node is a centralized unit of a gNB and the second node is a distributed unit of the gNB. In other embodiments, the first node is an Open-RAN distributed unit (O-DU) and the second node is an Open-RAN radio unit (O-RU). In other embodiments, the first node is a first network function (NF) of a core network and the second node is a second NF of the core network. Other embodiments and variants of the exemplary methods summarized above are described herein. Other embodiments include nodes (e.g., user equipment, network equipment) configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure such nodes to perform operations corresponding to any of the exemplary methods described herein. Embodiments described herein may provide various benefits or advantages. For example, embodiments may facilitate authentication techniques such as IEEE802.1X to be deployed in a network without the need for operator interventions during node recoveries, such as disabling authentication and/or site visits. This may reduce network maintenance costs, such as for networks in which the only source of current time for certain nodes is other nodes in the network (e.g., via PTP or NTP). These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates certain mutual authentication problems that may occur between two nodes in a communication network. Figure 2 illustrates mutual authentication operations between two nodes according to some embodiments of the present disclosure. Figure 3 shows an exemplary 5G network architecture in which various embodiments of the present disclosure may be implemented. Figure 4 shows an exemplary O-RAN architecture in which various embodiments of the present disclosure may be implemented. Figure 5 illustrates operations mutual authentication between two O-RAN nodes, according to some embodiments of the present disclosure. Figure 6 shows an exemplary method (e.g., procedure) for a second node of a communication network, according to various embodiments of the present disclosure. Figures 7-8 show two example communication systems according to some embodiments of the present disclosure. Figure 9 shows an example wireless device according to some embodiments of the present disclosure. Figure 10 shows an example network node according to some embodiments of the present disclosure. Figure 11 shows an example virtualization environment in which some embodiments of the present disclosure may be virtualized. Node A (trusted) Node B (untrusted) PTP/NTP (current time) Mutual (re)authentication (802.1X with EAP-TLS) X Power outage and r...