Online Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The protocol enables users to determine the revocation state of a specific certificate, and may provide a more efficient source of revocation information than is possible with Certificate Revocation Lists (CRL).
The protocol specifies the data exchanged between an OCSP client (for example, the Oracle® Enterprise Session Border Controller) and an OCSP responder, the Certification Authority (CA), or its delegate, that issued the target certificate. An OCSP client issues a request to an OCSP responder and suspends acceptance of the certificate in question until the responder replies with a certificate status.
Certificate status is reported as
- good
- revoked
- unknown
good indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate’s validity interval.
revoked indicates that the certificate has been revoked, either permanently or temporarily.
unknown indicates that the responder cannot identify the certificate.
Caveats
OCSP is currently supported only on TLS interfaces; it is not currently supported for use with IKEv1 and IKEv2.
Unreachable OCSR
With OCSP enabled, the client implementation running on the Oracle® Enterprise Session Border Controller supports message exchange between the Oracle® Enterprise Session Border Controller and an OCSR as specified in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The Oracle® Enterprise Session Border Controller contacts the OCSR whenever a remote client attempts to establish an SSL/TLS connection with the Oracle® Enterprise Session Border Controller. The Oracle® Enterprise Session Border Controller sends a request to the OCSR to check the current status of the certificate presented by the remote client. The Oracle® Enterprise Session Border Controller suspends processing of the SSL/TLS connection request pending receipt of the OCSR response. In previous releases (prior to Version S-CX6.3.0), a good OCSR response resulted in the establishment of a secure SSL/TLS connection. A revoked or unknown OCSR response, or the failure to reach an OCSR, resulted in the rejection of the connection attempt.
This behavior, which adheres to the requirements of RFC 2560, conflicts with the requirements of Section 5.4.6.2.1.6.4.a.i of UCR 2008 which requires an OCSP client to attempt authentication of remote clients in the event of an unreachable OCSR.
Release S-CX6.3F1 adds a new attribute (ignore-dead-responder) to the TLS profile configuration element to provide compliance with DISA/DoD requirements specifying OCSP client operations when faced with unreachable OCSRs. By default, the attribute is disabled meaning that all client connections will be disallowed in the event of unreachable OCSRs.
In DISA/DoD environments ignore-dead-responder should be enabled, allowing local certificate-based authentication by the Oracle® Enterprise Session Border Controller in the event of unreachable OCSRs. Successful authentication is achieved if the certificate presented by the remote client was signed by a Certificate Authority (CA) referenced by the trusted-ca-certificates attribute. If the local authentication succeeds, the secure TLS/SSL connection is established; otherwise the connection is rejected.
Unreachable OCSR Configuration
The following sample configuration implements DISA/DoD-compliant client behavior in the event of an unreachable OCSR.
ACMEPACKET# configure terminal
ACMEPACKET(configure)# security#
ACMEPACKET(security)# tls-profile
ACMEPACKET(security)# show
tls-profile
name DoD
end-entity-certificate sylarCert-2048
trusted-ca-certificates dod1 dod2 disaA disaB IBM1
cipher-list all
verify-depth 10
mutual-authenticate disabled
tls-version tlsv1
cert-status-check enabled
cert-status-profile-list DoD
ignore-dead-responder enabled
...
...
ACMEPACKET(tls-profile)#
OCSR Status Monitoring
OCSR monitoring is provided to track the reachability of individual OCSRs, and, in topologies containing multiple OCSRs, the overall availability of OCSR service.
If monitoring is enabled for individual OCSRs, reachability is monitored by observing responder transactions.
Initially, all OCSRs are considered reachable. If a previously reachable OCSR fails to respond to a certificate status request, the Oracle® Enterprise Session Border Controller marks the OCSR as unreachable, and generates an SNMP trap and log entry indicating that status. If a previously unreachable OCSR respond to a certificate status request, the Oracle® Enterprise Session Border Controller returns the OCSR to the reachable status, and generates an SNMP trap and log entry indicating that status change.
Use the following procedure to enable monitoring of individual OCSRs.
OCSR Access via FQDN
Prior software releases supported OCSR access only via IPv4 addresses and port numbers. In response to a DISA/DoD request, Release S-CX6.3F1 adds support for OCSR access via FQDNs. Since multiple public key infrastructure (PKI) elements capable of supporting OCSP requests can exist within a DISA/DoD environment, the Domain Name Service (DNS) lookup that resolves the FQDN can result in more than one OCSR IP address being returned to the Oracle® Enterprise Session Border Controller in its role of OCSP client. When processing a lookup that contains more than one IP address, the Oracle® Enterprise Session Border Controller uses a round-robin algorithm to select from the list of OCSR addresses.
OCSR Access via FQDN is available on all media interfaces and on the wancom0 administrative interface. Note that support for FQDN-based access is requires the configuration of DNS support.
If the realm attribute is configured in the certificate-status-profile configuration element, the required DNS query is issued on the corresponding network interface. This model requires configuration of the dns-ip-primary attribute, and optionally the dns-ip-backup1 and dns-ip-backup2 attributes for the realm’s network interface.
If the realm attribute is not configured in the certificate-status-profile, the required DNS query is issued on the wancom0 interface. This model requires configuration of the dns-ip-primary attribute, and optionally the dns-ip-backup1 and dns-ip-backup2 attributes for the wancom0 interface.
Access via an FQDN is supported by a new attribute (hostname) in the cert-status-profile configuration element.
The Oracle® Enterprise Session Border Controller allows configuration of both an OCSR IP address and port number (using the ip-address and port attributes) and an OCSR domain (using the hostname attribute).
In such cases the verify-config command issues a warning and notes that IP address-based access will be used.
OCSR Access Configuration via IP Address
The following sample configuration accesses an OCSR at 192.168.7.100:8080.
ORACLE# configure terminal ORACLE(configure)# security# ORACLE(secirity)# cert-status-profile# ORACLE(cert-status-profile)# show cert-status-profile name defaultOCSP ip-address 192.168.7.100 hostname port 8080 type OCSP trans-proto HTTP requestor-cert ocspVerisignClient responder-cert VerisignCA2 trusted-cas realm-id admin retry-count 1 dead-time 0 last-modified-by last-modified-date ORACLE(cert-status-profile)#
OCSR Access Configuration via FQDN
The following sample configuration accesses one or more OCSRs at example.disa.mil.
Note that in the absence of a specified domain, the wancom0 interface must be DNS-enabled.
ORACLE# configure terminal ORACLE(configure)# security# ORACLE(cert-status-profile)# show cert-status-profile name DISAdomain2 ip-address hostname example.disa.mil port type OCSP trans-proto HTTP requestor-cert responder-cert trusted-cas dod1 dod2 disaA disaB IBM1 realm-id retry-count 1 dead-time 0 last-modified-by last-modified-date ORACLE(cert-status-profile)#
Direct and Delegated Trust Models
RFC 2560 specifies that an OCSR must digitally sign OCSP responses, and that an OCSP client must validate the received signature. In prior releases, successful validation of the signed response served to authenticate the responder. Such an authentication method is referred to as a direct trust model in that it does not require confirmation from a trusted Certificate Authority (CA). Rather it requires that the OCSP client be in possession of the public counterpart of the private key used by the OCSR to sign the response. This certificate is identified by the responder-cert attribute in the cert-status-profile configuration element. Prior to Release S-CX6.3F1, authentication via signature validation was the only authentication method provided by the OCSP client implementation.
Release S-CX6.3F1 continues support for the direct trust model, while also supporting an alternative delegated trust model as described in Section 5.4.6.2.1.6.1.e.3.c of UCR 2010. The delegated trust model requires that OCSR be authenticated by a trusted CA. Within the DISA/DoD delegated trust model, an OCSR certificate is appended to every response, thus eliminating the need for a pre-provisioned responder certificate. The appended certificate is a signing certificate issued and signed by a DoD-approved CA that issued the certificate that is being validated. These OCSR certificates have a short lifespan and are reissued regularly.
Direct Trust Model Configuration
The direct trust model is used in virtually all commercial/enterprise environments. Configuration of the direct trust model is unchanged from that contained in the latest version of your hardware or the Oracle® Enterprise Session Border ControllerConfiguration Guide.
