PKI in Junos OS

PKI Applications Overview

The Junos OS uses public/private keys in the following areas:

• SSH/SCP (for secure command-line interface [CLI]-based administration)

• Secure Sockets Layer (SSL) (for secure Web-based administration and for https-based webauth for user authentication)

• Internet Key Exchange (IKE) (for IPsec VPN tunnels)

Note:

Note the following points:

• Currently Junos OS supports only IKE (using public key infrastructure (PKI) certificates for public key validation).

• The SSH and SCP are used exclusively for system administration and depends on the use of out-of-band fingerprints for public key identity binding and validation. Details on SSH are not covered in this topic.

Components for Administering PKI in Junos OS

The following components are required for administrating PKI in Junos OS:

• CA certificates and authority configuration

• Local certificates including the devices identity (example: IKE ID type and value) and private and public keys

• Certificate validation through a certificate revocation list (CRL)

Basic Elements of PKI in Junos OS

Junos OS supports three specific types of PKI objects:

• Private/public key pair

• Certificates

  • Local certificate—The local certificate contains the public key and identity information for the Juniper Networks device. The Juniper Networks device owns the associated private key. This certificate is generated based on a certificate request from the Juniper Networks device.

  • Pending certificate — A pending certificate contains a key pair and identity information that is generated into a PKCS10 certificate request and manually sent to a certificate authority (CA). While the Juniper Networks device waits for the certificate from the CA, the existing object (key pair and the certificate request) is tagged as a certificate request or pending certificate.

    Note:

    Junos OS Release 9.0 and later supports automatic sending of certificate requests through SCEP.

  • CA certificate — When the certificate is issued by the CA and loaded into the Junos OS device, the pending certificate is replaced by the newly generated local certificate. All other certificates loaded into the device are considered CA certificates.

• Certificate revocation lists (CRLs)

Note the following points about certificates:

• Local certificates are generally used when a Junos OS device has VPNs in more than one administrative domain.

• All PKI objects are stored in a separate partition of persistent memory, apart from the Junos OS image and the system’s general configuration.

• Each PKI object has a unique name or certificate-ID given to it when it is created and maintains that ID until its deletion. You can view the certificate-ID by using the show security pki local-certificate command.

• A certificate cannot be copied from a device under most circumstances. The private key on a device must be generated on that device only, and it should never be viewed or saved from that device. So PKCS12 files (which contain a certificate with the public key and the associated private key) are not supported on Junos OS devices.

• CA certificates validate the certificates received by the IKE peer. If the certificate is valid, then it is verified in the CRL to see whether the certificate has been revoked.

  Each CA certificate includes a CA profile configuration that stores the following information:

  • CA identity, which is typically the domain name of the CA

  • E-mail address for sending the certificate requests directly to the CA

  • Revocation settings:

    • Revocation check enable/disable option

    • Disabling of revocation check in case of CRL download failure.

    • Location of CRL Distribution Point (CDP) (for manual URL setting)

    • CRL refresh interval

PKI Management and Implementation

The minimum PKI elements required for certificate-based authentication in Junos OS are:

• CA certificates and authority configuration.

• Local certificates including the device’s identity (example: IKE ID type and value) and private and public keys

• Certificate validation through a CRL.

Junos OS supports three different types of PKI objects:

Internet Key Exchange

The procedure for digitally signing messages sent between two participants in an Internet Key Exchange (IKE) session is similar to digital certificate verification, with the following differences:

• Instead of making a digest from the CA certificate, the sender makes it from the data in the IP packet payload.

• Instead of using the CA's public-private key pair, the participants use the sender's public-private key pair.

Trusted CA Group

A Certificate Authority (CA) is a trusted third party responsible for issuing and revoking certificates. You can group multiple CAs (CA profiles) in one trusted CA group for a given topology. These certificates are used to establish connection between two endpoints. To establish IKE or IPsec, both the endpoints must trust the same CA. If either of the endpoints are unable to validate the certificate using their respective trusted CA (ca-profile) or trusted CA group, the connection is not established.

For example, there are two endpoints, endpoint A and endpoint B are trying to establish a secure connection. When endpoint B presents it’s certificate to endpoint A, the endpoint A will check if the certificate is valid. The CA of the endpoint A verifies the signed certificate that the endpoint B is using to get authorized. When trusted-ca or trusted-ca-group is configured, the device will only use the CA profiles added in this trusted-ca-group or the CA profile configured under trusted-ca to validate the certificate coming from endpoint B. If the certificate is verified as valid, the connection is allowed, else the connection is rejected.

Benefits:

• For any incoming connection request, only the certificate issued by that particular trusted CA of that endpoint gets validated. If not, the authorization will reject establishing the connection.

Cryptographic Key Handling Overview

With cryptographic key handling, persistent keys are stored in the memory of the device without any attempt to alter them. While the internal memory device is not directly accessible to a potential adversary, those who require a second layer of defense can enable special handling for cryptographic keys. When enabled, the cryptographic key handling encrypts keys when not immediately in use, performs error detection when copying a key from one memory location to another, and overwrites the memory location of a key with a random bit pattern when the key is no longer in use. Keys are also protected when they are stored in the flash memory of the device. Enabling cryptographic key handling feature does not cause any externally observable change in the behavior of the device, and the device continues to interoperate with the other devices.

A cryptographic administrator can enable and disable the cryptographic self-test functions; however, the security administrator can modify the behavior of the cryptographic self-test functions such configuring periodic self-tests or selecting a subset of cryptographic self-tests.

The following persistent keys are currently under the management of IKE and PKI:

• IKE preshared keys (IKE PSKs)

• PKI private keys

• Manual VPN keys

Handling TPM-Based Certificates

The TPM-based (Trusted Platform Module based) certificate available on your SRX Series Firewall guarantees secure identification of the device. Starting in Junos OS Release 24.2R1, you can use the TPM-based certificate with SRX1600, SRX2300 and SRX4300 Series Firewalls. When you use applications such as the advanced anti-malware (AAMW) detection using Juniper Advanced Threat Prevention Cloud, you can use the TPM-based certificate for attestation, allowing the applications to verify the legitimacy of your device. To learn more about TPM and how the firewall manages the TPM-based certificates using PKI, see Trusted Platform Module.