Providing a mechanism for certificate revocation is a normal part of PKI management. When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA, and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. Two methods of supporting certificate revocation are defined in this specification: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP). The CMTS MUST support configuration of none, one or both certificate revocation methods to be enabled at the same time.
13.4.1 Certificate Revocation Lists67
[RFC 3280] defines a method for revoking certificates using [X.509] Certificate Revocation Lists (CRLs).
Figure 13-3 shows a framework for managing and distributing CRLs. A CRL is a digitally signed, time stamped list of certificate serial numbers revoked by a Certificate Authority (CA). When a CA identifies the compromised certificates, the CA could generate the CRLs itself, or a CA could delegate the CRL generation to a third party CRL Issuer. The CRL Repository is a system that maintains a database of revoked certificates. The interface between the CA or CRL Issuer and CRL Repository is outside the scope of this specification.
Figure 13-3 - CRL Framework
The CMTS retrieves CRL entries from the CRL Repository and uses this information to verify if a certificate received during the CM registration process is revoked.68
13.4.1.1 CMTS CRL Support 69
The CMTS MUST support retrieval of CRL files formatted as defined in [RFC 3280]. CRL files may identify revoked certificates that were issued from different CAs. Therefore, the CMTS MUST support extensions related to indirect CRL files as defined in [RFC 3280]. The CMTS MUST support HTTP as defined in [RFC 2616] for downloading CRL files.
Before using the information in a CRL file, the CMTS MUST verify that its digital signature chains to a trusted root CA. Trusted root CAs are administratively provisioned in the CMTS. If the CRL file digital signature cannot be verified, the CMTS MUST discard the CRL file. The CMTS MUST validate if a CA certificate or CM certificate is revoked during the certificate validation process specified in Section 13.3.2.
If the CRL contains the nextUpdate value the CMTS MUST refresh the CRL after the specified time has passed. If the CMTS fails to retrieve the new CRL, it MUST log an event [DOCSIS OSSIv3.0] and continue to use its current
66 Revised per SECv3.0-N-09.0774-2 on 5/7/09 by JB. 67 Revised per SECv3.0-N-09.0774-2 on 5/7/09 by JB.
CRL. If the CMTS fails to retrieve the new CRL it should attempt to retry retrieval of the CRL file on a periodic basis. If the CRL does not contain the nextUpdate value the CMTS MUST refresh the CRL according to the configured value as defined in [DOCSIS OSSIv3.0].
When the CMTS is configured to use a CRL it MUST attempt to retrieve the CRL file each time it starts up. During CMTS startup it is possible that some CMs may perform BPI+ authorization before the CRL file has been retrieved. When the CMTS is configured to use a CRL and a CM’s device certificate chain is validated during CMTS startup before the CRL file is retrieved the CMTS MUST log an event for that CM [DOCSIS OSSI3.0] and bypass CRL checking.
13.4.2 Online Certificate Status Protocol70
[RFC 2560] defines an Online Certificate Status Protocol (OCSP) for querying the status of a digital certificate. The CMTS sends a certificate status request to an OCSP responder when it receives a CA certificate or a CM certificate (see Figure 13-4). The OCSP responder sends a status response indicating that the certificate is "good," "revoked," or "unknown." The OCSP responder checks only the revocation status of a certificate; it does not verify the validity of the certificate itself. The CMTS uses the result from the OCSP responder during certificate validation process specified in Section 13.3.2.
OCSP
Responder CMTS
Figure 13-4 - OCSP Framework
The CMTS MUST be capable of acting as an OCSP client as defined in [RFC 2560]. The CMTS SHOULD cache the OCSP response status for a certificate if the nextUpdate value is present in the OCSP response. If the CMTS caches the OCSP response status for a given certificate, it MUST retrieve the revocation status from the cache. Once the nextUpdate time for that certificate has passed, the CMTS MUST continue using the revocation status value from the cache until an update is retrieved from the OCSP Responder. If the CMTS is unable to retrieve the OCSP status for an uncached certificate or if the retrieved status is "unknown" the CMTS MUST log an event [DOCSIS OSSIv3.0] and assume the certificate status to be "good." If the nextUpdate value is not present in the OCSP response, the CMTS MUST NOT cache the OCSP response status for a certificate. If the CMTS is configured with OCSP Responder information, it MUST send an OCSP request when a CA certificate or CM certificate is obtained using the Authentication Information message, or Authentication Request message respectively, unless there is a valid certificate status in the cache. When the CMTS is attempting to communicate with the OCSP Responder, the exchange should not significantly delay the CM provisioning process. If no response is received, the CMTS MUST proceed using the currently cached revocation status. For uncached certificate states, the CMTS MUST proceed as if a response with the status "good" has been received. 71
The CMTS MUST support OCSP over HTTP as described in [RFC 2560]. The CMTS MAY generate a signature in the OCSP request. The CMTS MUST bypass validation of the signature in an OCSP response based on the
configured value as defined in [DOCSIS OSSIv3.0].
14 SECURE SOFTWARE DOWNLOAD
14.1 Introduction
DOCSIS supports downloading code to CMs. Authenticating the source and verifying the integrity of downloaded code is vital to the overall operation and security of DOCSIS-based networks.
The software download module is an attractive target for an attacker. If an attacker were able to mount a scalable attack against the software download module, he could potentially install code to disable all the CMs within a domain, or disrupt service on a wide scale. To thwart these attacks, the attacker is forced to overcome several security barriers.