Chapter 5, PacketCable Voice Configuration
Available Languages
Table Of Contents
PacketCable Voice Configuration
PacketCable EMTA Secure Provisioning
BACC PacketCable Secure Provisioning Flow
PacketCable EMTA BASIC Provisioning
PacketCable TLV 38 and MIB Support
Configuring Euro-PacketCable MIBs
Troubleshooting eMTA Provisioning
Embedded Media Terminal Adapter
PacketCable Provisioning Server
Ethereal, SnifferPro, or Other Packet Capture Tools
MTA Device Certificate Hierarchy
MTA Manufacturer Code Verification Certificates
CableLabs Service Provider Certificate Hierarchy
CableLabs Service Provider Root Certificate
Service Provider CA Certificate
Operational Ancillary Certificates
Code Verification Certificate Hierarchy
CableLabs Code Verification Root CA Certificate
CableLabs Code Verification CA Certificate
Manufacturer Code Verification Certificate
Service Provider Code Verification Certificate
Certificate Revocation Lists for CVCs
PacketCable Voice Configuration
This chapter describes all activities you must perform to bring a PacketCable voice deployment into service. This chapter contains information on these variants of PacketCable:
•
PacketCable EMTA Secure Provisioning
•
This chapter also includes information that will help to solve issues that might arise and hinder PacketCable voice technology deployment:
•
This chapter assumes that you are familiar with the contents of the PacketCable MTA Device Provisioning Specification, PKT-SPPROV1.5-I01-050128. See www.packetcable.com for details.
PacketCable EMTA Secure Provisioning
This section deals exclusively with the secure PacketCable voice provisioning. PacketCable Secure is designed to minimize the possibility of theft of telephony service, malicious disruption of service, and so on. PacketCable Secure depends on the Kerberos infrastructure to mutually authenticate the MTA and provisioning system. SNMPv3 is also used to secure the conversation between the MTA and the provisioning system.
BACC PacketCable Secure Provisioning Flow
All PacketCable provisioning flows are defined as a sequence of steps. When diagnosing an EMTA provisioning problem, this flow description helps identify which step in the PacketCable provisioning flow is failing. Figure 5-1 illustrates the secure provisioning flow for PacketCable embedded MTAs.
Figure 5-1 Embedded-MTA Secure Power-on Provisioning Flow
Note
In addition, the KDC log file content is critical to understanding the root cause of any KDC failure.
1.
2.
This information is needed to allow the MTA to contact the KDC and ProvServer. Some key troubleshooting hints are:
–
–
–
–
–
If a packet trace reveals that the MTA is cycling between flow steps MTA 1 and 2, there is probably a problem with the configuration of DHCP option 122 (realm name or provisioning server FQDN sub-options), DHCP option 12 (host name), or DHCP option 15 (domain name). All are required DHCP content for the MTA.
3.
–
–
–
4.
–
–
5.
Some key troubleshooting hints are:
–
–
6.
–
7.
8.
9.
10.
11.
12.
PacketCable EMTA BASIC Provisioning
BACC also supports PacketCable BASIC, which offers a simpler, DOCSIS-like, non-secure provisioning flow.
The following describes the BASIC.1 flow:
1.
2.
3.
4.
Note
The BASIC.2 flow is identical to BASIC.1, with the following exceptions:
•
•
The BASIC PacketCable flow is similar to the DOCSIS flow with the following differences:
•
•
•
(See "DOCSIS Configuration" for additional information about the DOCSIS flow.)
Note
PacketCable TLV 38 and MIB Support
BACC supports the complete set of PacketCable 1.5 MIBs.
BACC supports TLV 38 in PacketCable configuration templates. This TLV lets you configure multiple SNMP notification targets. Configuration of this TLV means that all notifications are also issued to the targets configured through TLV 38.
SNMP v2C Notifications
BACC supports both SNMP v2C TRAP and INFORM notifications from the PacketCable MTA.
Euro-PacketCable
Euro-PacketCable services are essentially the European equivalent of North American PacketCable services with the following differences:
•
•
For Euro-PacketCable certificates, the kdc.ini must have the property "euro-packetcable = true". See Euro-PacketCable Support for more information.
When using Euro-PacketCable, ensure that the value of thePacketCable property /pktcbl/prov/locale is set to EURO. (The default is NA for North America.) You can specify the locale in the Configuration File utility. See Using the Configuration File Utility, page 12-25 for more information.
Euro-PacketCable MIBs
Euro-PacketCable MIBs are essentially snapshots of draft-IETF MIBs. MTA configuration files consist essentially of SNMPVarBinds that reference the MIBs. There are substantial differences between the PacketCable and Euro MIBs; therefore, the PacketCable and Euro-PacketCable configuration files are incompatible. During installation sample files for PacketCable (cw29_config.tmpl) and Euro-PacketCable (ecw15_mta_config.tmpl)are copied to the <BACC_HOME>/rdu/samples directory.
The following Euro-PacketCable MIBS are shipped with BACC:
•
•
•
•
•
•
•
Configuring Euro-PacketCable MIBs
To configure BACC to use Euro-PacketCable MIBs, you must change the BACC RDU property that specifies the MIBs to be loaded. By default, this property contains the PacketCable MIBs
You can do this in one of the following ways:
•
•
•
The property name is /snmp/mibs/mibList (properties file), or SNMPPropertyKeys.MIB_LIST (the Prov API constant name). The property value is a comma-separated value (CSV) consisting of the required MIB names, as shown:
/snmp/mibs/mibList=SNMPv2-SMI,SNMPv2-TC,INET-ADDRESS-MIB,CISCO-SMI,CISCO-TC,SNMPv2-MIB,RFC 1213-MIB,IANAifType-MIB,IF-MIB,DOCS-IF-MIB,DOCS-IF-EXT-MIB,DOCS-BPI-MIB,CISCO-CABLE-SPECTR UM-MIB,CISCO-DOCS-EXT-MIB,SNMP-FRAMEWORK-MIB,DOCS-CABLE-DEVICE-MIB,DOCS-CABLE-DEVICE-MIB-O BSOLETE,DOCS-QOS-MIB,CISCO-CABLE-MODEM-MIB,DOCS-IETF-BPI2-MIB,INTEGRATED-SERVICES-MIB,DIFF SERV-DSCP-TC,DIFFSERV-MIB,TCOMLABS-MIB,PKTC-TCOMLABS-MTA-MIB,PKTC-TCOMLABS-SIG-MIBTroubleshooting eMTA Provisioning
Provisioning PacketCable Embedded Media Terminal Adapters (eMTAs) is a relatively complex process; however, with the right tools and `tricks of the trade,' getting eMTAs operational can be straightforward.
This chapter assumes that Network Registrar and BACC are both in use; however, much of the information also applies for other deployments. Basic knowledge of Network Registrar (scopes, policies, basic DNS zone setup, and record entry) and BACC (class of service, DHCP criteria, external files, and BACC directory structure) is assumed.
The PacketCable eMTA provisioning process consists of 25 steps for the Secure flow; the BASIC flow has far fewer steps. To troubleshoot eMTAs, knowledge of these 25 steps from the PacketCable provisioning specification is absolutely essential.
This section contains the following topics:
Components
Before troubleshooting eMTAs, you should be familiar with the following system components as described in the subsections that follow.
•
•
Embedded Media Terminal Adapter
The eMTA is a cable modem and a Media Terminal Adapter (MTA) in one box, with a common software image. The CM and MTA each have their own MAC address and each performs DHCP to get its own IP address. The eMTA contains, at minimum, three certificates. One certificate is a unique MTA certificate. A second certificate identifies the MTA's manufacturer. Both the device and manufacture certificates are sent by the MTA to authenticate itself to the key distribution center (KDC). The third certificate is a telephony root certificate used to verify the certificates sent by the KDC to the MTA. The KDC's certificates will be chained from the telephony root, therefore the telephony root must reside on the MTA to validate the authenticity of the KDC certificates. The MTA portion receives its own configuration file, which it uses to identify its controlling call agent, among other things.
DHCP Server
The DOCSIS specifications mandate that cable modems negotiate their IP address using the Dynamic Host Configuration Protocol (DHCP). The MTA, like most CPEs on a DOCSIS network, must use DHCP to obtain its IP address and other crucial information (DNS servers, PacketCable option 122 for Kerberos realm name, provisioning server FQDN).
Note
When using BACC with PacketCable support, be aware that a correctly-configured BACC will automatically populate the ToD server, DNS servers, TFTP server, as well as the Option 122 fields; these do not need to be explicitly set in the Network Registrar policy.
DNS Server
The Domain Name System (DNS) server is fundamental in PacketCable provisioning. The PacketCable provisioning server, which is the device provisioning engine (DPE) in a BACC architecture, must have an address (A) record in the appropriate zone, because its fully qualified domain name (FQDN) is provided to the MTA in Option 122 by the DHCP server. The KDC realm must have a zone of the same name as the realm name containing a server (SRV) record that contains the FQDN of the Kerberos server.
The Kerberos server identified in the SRV record must itself have an A record in the appropriate zone. The call management server (CMS) identified in the MTA configuration file must also have an A record in the appropriate zone. Lastly, the MTAs themselves must have A records in the appropriate zone, since the CMS reaches the MTA by resolving its FQDN. Dynamic DNS (DDNS) is the preferred method of creating A records for the MTA. See the Cisco Network Registrar documentation for information on configuring and troubleshooting DDNS.
Key Distribution Center
The KDC is responsible for authenticating MTAs. As such, it must check the MTA's certificate, and provide its own certificates so that the MTA can authenticate the KDC. It also communicates with the DPE (the provisioning server) to validate that the MTA is provisioned on the network.
PacketCable Provisioning Server
The PacketCable provisioning server is responsible for communicating the location of the MTA configuration file to the MTA, and/or provisioning MTA parameters via SNMP. SNMPv3 is used for all communication between the MTA and the provisioning server. The keys used to initiate SNMPv3 communication are obtained by the MTA during its authentication phase with the KDC. Provisioning server functionality is provided by the DPE in a BACC architecture.
Call Management Server
The call management server (CMS) is essentially a soft switch, or call-agent, with additional PacketCable functionality to control, among other things, quality of service on a cable network. The MTA sends a network call signaling (NCS) restart in progress (RSIP) message to the CMS upon successful PacketCable provisioning.
Key Variables
This section describes the key variables required to provision an eMTA correctly.
Certificates
The MTA_Root.cer file contains the MTA root certificate (a certificate that is rooted in official PacketCable MTA root). The MTA_Root.cer will not usually cause significant problems.
You must know in advance what telephony root certificate is required for the MTAs you want to provision. Deployments in production networks use telephony certificates rooted in the PacketCable real root. There is also a PacketCable test root used in lab and testing environments. The KDC certificates used by the KDC to authenticate itself to the MTA must be rooted in the same telephony root that is stored on the MTA (PacketCable real or test root).Most MTA vendors support test images that have Telnet and/or HTTP login capabilities so that you can determine which telephony root is enabled, and change the root used (in most cases, you can only select between the PacketCable real or test root).
The most common scenario has the KDC loaded with certificates (from the $BACC_HOME/kdc/solaris/packetcable/certificates dir) as follows:
•
•
•
•
•
The first four certificates comprise the telephony certificate chain. The MTA_Root.cer file contains the MTA root used by the KDC to validate the certificates sent by the MTA.
Note
To determine if you are using PacketCable test root, open the CableLabs_Service_Provider_Root.cer file in Windows, and validate that the Subject OrgName entry is O = CableLabs, and/or check that the Subject Alternative name reads CN=CABLELABS GENERATED TEST ROOT FOR EQUIPMENT TEST PURPOSES ONLY.
The KDC certificate (KDC.cer) contains the realm name to use. The realm name that BACC (and the corresponding DNS zone) is configured to use must match this realm name. Additionally, the MTA configuration file realm org name must match the organization name as seen in the telephony root.
The KDC certificate has a corresponding private key that must be installed in the $BACC_HOME/kdc/solaris directory. Usually it is named KDC_private_key.pkcs8 or KDC_private_key_proprietary. When changing certificates, you must also change the private key.
Scope Selection Tag(s)
In most scenarios, BACC is involved in processing all DHCP requests from scopes with scope selection tags that match selection criteria specified in the DHCP criteria page of the BACC administrative user interface. Client Class can also be used to tie scopes to BACC processing; ensure you make this association before you attempt to provision devices.
MTA Configuration File
The MTA configuration file contains the location of the CMS. Additionally, it must contain an entry for Realm Name. This value must match that of the certificate chain in use.
Certain table entries within the MTA configuration file are indexed by the realm name delivered to the MTA in Option 122. This realm name entry in the MTA configuration file must match that delivered in Option 122. For example, if DEF.COM was the realm name delivered in Option 122, MTA configuration file entries in the pktcMtaDevRealm table would be indexed with a suffix made up of the ASCII-coded character values (in dot delimited decimal format when using the Cisco Broadband Configurator) of the realm name, for example 68.69.70.46.67.79.77. There are many free ASCII conversion pages available on the web to make this conversion easier.
Troubleshooting Tools
The 25 eMTA secure provisioning steps contained in PacketCable MTA Device Provisioning Specification, are shown in Figure 5-1.
This section contains the following topics:
•
•
Logs
These log files are used to maintain the following information:
•
•
•
Note
Ethereal, SnifferPro, or Other Packet Capture Tools
A packet capture tool is indispensable when troubleshooting the eMTAs. The Ethereal version, as packaged by CableLabs, includes numerous packet decoders specific to PacketCable. These include the Kerberos AS and AP packets.
•
•
Troubleshooting Scenarios
The scenarios listed in Table 5-1 are possible failures involving embedded MTAs.
Table 5-1 Troubleshooting Scenarios
KDC does not start.
The KDC certificate does not correspond to the private key.
Ensure that you have matching certificates and private key.
The KDC license expired or is missing.
Restore KDC license to $BACC_HOME/kdc directory.
The MTA device does not appear in the BACC Devices page.
An incorrect cable helper address may have been configured.
Fix the helper address.
The scope selection tags do not match the DHCPCriteria selected in the BACC user interface.
Verify that the MTA scope selection tags match those in the PacketCable DHCP criteria created, in BACC, for the relevant MTA(s).
The Network Registrar Extension point is not properly installed.
Re-install the Network Registrar Extension Point. See the Cisco Broadband Access Center for Cable Installation Guide for the appropriate instruction.
The cable modem portion did not receive Option 122.
Verify that the tags on the scope of the cable modem portion match the DOCSIS DHCP criteria configure for BACC.
MTA does not accept the DHCP offer and continually cycles through the DHCP flow.
There are invalid DHCP options configured.
Check that scope policy includes DNS server option, and/or check cnr_ep.properties file includes entry for primary and secondary DNS servers.
The DHCP offer may have come from a DHCP server different from the one indicated in the cable modem portion's Option 122 suboption 1.
Check the cnr_ep.properties file to ensure that the primary and secondary DHCP servers are set correctly.
Both the KDC.log file and the ethereal trace indicate that the MTA never contacts the KDC.
An incorrect DNS server is specified in the cnr_ep.properties file and/or the MTA scope policy.
Check /correct cnr_ep.properties DNS servers.
A zone is missing or has been incorrectly set up for the Kerberos realm.
Make sure a zone with same name as realm is created and contains an `SRV' record of format `_kerberos._udp 0 0 88 <KDC FQDN>'.
There is a missing or incorrect KDC `A' record entry.
Ensure that an `A' record exists for the FQDN contained in the Kerberos zone's `SRV' record.
The DPE FQDN cannot be resolved.
Ensure that dpe.properties provFQDNs entry has the correct FQDN and IP of the DPE.
KDC reports failure during the Kerberos AS-Request.
The MTA certificate does not match the MTA root used by KDC.
Verify that the MTA_Root.cer is correct by comparing the MTA_Root.cer against that used on a working system.
If it is correct, the MTA itself could have a certificate problem. This situation is extremely rare and if this is the case, contact the MTA manufacturer.
FQDN lookup by KDC to Prov Server failed. The device may not yet be provisioned in BACC.
Verify that the device appears. It should be given both a class of service and a DHCP criteria.
A clock skew error. See the "PacketCable Checklists" section for additional information.
Ensure that all BACC network elements are clock-synced via NTP. See the Broadband Access Center for Cable Command Line Interface Reference for additional information.
A mismatch may exist between the KDC and the DPE.
Note
Check that these three entries exist in the $BACC_HOME/kdc/solaris/keys directory:
•
•
•
Your system will have the DPE FQDN, and Realm name different from this example. Contents of these entries must match the entry in either the dpe.properties `KDCServiceKey' entry, or the keys generated using the keygen utility.
The KDC reports success at the AS-Request/Reply (steps 9 and 10 in Figure 5-1) but MTA never moves past step 9, and continually reprovisions up to that step.
There is a certificate mismatch between the telephony root loaded or enabled on the MTA, and that loaded on the KDC.
Check certificates on MTA and KDC.
Although highly unlikely, it is possible that there is a corrupted telephony certificate chain.
Note
Ensure that the correct certificate is loaded/enabled on MTA. If no devices can be provisioned correctly, try a different certificate on the KDC.
Failure at AP Request/Reply (step 14 in Figure 5-1)
A clock skew error. See the "PacketCable Checklists" section for additional information.
Ensure that all BACC network elements are clock-synced via NTP. See the Broadband Access Center for Cable Command Line Interface Reference for additional information.
Cannot resolve Prov Server FQDN.
Make sure that the provisioning server (DPE) has a correct DNS entry.
Ensure that dpe.properties provFQDNs entry has the correct FQDN and IP of the provisioning server (DPE)There is no route from the MTA to the DPE.
Correct the routing problem.
The MTA never issues a TFTP request for a configuration file.
There is no route to the TFTP server running on the DPE.
Correct the routing problem.
The MTA never receives the TFTP configuration file.
The configuration file is not cached at the DPE.
Wait until the next provisioning attempt, at which time the file should be cached. If this fails, reset the MTA.
A conflicting TFTP server option is included in the network registrar MTA scope policy.
Since BACC inserts the DPE address for the TFTP server, you can safely remove this option from the policy.
The MTA receives a configuration file but the DPE fails to receive the SNMP Inform (step 25 in Figure 5-1) as seen in the dpe.log file.
One of:
•
•
•
Ensure that the MTA configuration file is consistent.
The MTA reports success (step 25 in Figure 5-1) although an RSIP is not sent.
The MTA cannot resolve the IP address of the CMS FQDN given in the MTA configuration file.
Verify that a DNS entry exists for the CMS.
The MTA cannot reach the IP address(es) of the CMS. This is an indication that no route is configured.
Resolve all routing problems.
The MTA reports success (step 25 in Figure 5-1), although it proceeds to contact the KDC again for CMS service.
The MTA configuration file points to an incorrect cable modem.
Correct the configuration file, or reconfigure the Cisco BTS 10200 to use the FQDN listed in the configuration file.
The MTA configuration file has its pktcMtaDevCmsIPsecCtrl value missing, or it is set to 1. This means it will perform secure NCS call signaling, or it will use an ASCII suffix that does not match that of the CMS FQDN.
Correct the configuration file. If you intend to perform secure signaling, take the necessary steps to configure the KDC and the BTS for support.
The MTA reports success (step 25 in Figure 5-1), RSIPs, but gets no response or gets an error in response from the soft switch.
The MTA is unprovisioned or has been incorrectly provisioned on the Cisco BTS 10200.
Provision MTA on the Cisco BTS 10200.
An eMTA DNS entry does not exist.
Place an entry in the correct DNS zone for the eMTA. Dynamic DNS is the preferred method. See the Cisco Network Registrar documentation for information on enabling DDNS.
Certificate Trust Hierarchy
There are two certificate hierarchies affiliated with BACC PacketCable, the MTA Device Certificate Hierarchy and the CableLabs Service Provider Certificate Hierarchy, as shown in Figure 5-2.
Figure 5-2 PacketCable Certificate Hierarchy
Prior to working with the BACC PacketCable implementation, you should thoroughly familiarize yourself with these technology documents:
•
•
Note
The elements of the Euro-PacketCable certificates that are different from the PacketCable certificates are indicated in the tables below.
For Euro-PacketCable the Euro-PacketCable certificates are the only valid certificates, any requirements that are stated in [PKT-SP-SEC-I08-030415] for PacketCable which refer to PacketCable Certificates are changed to the corresponding requirements for the Euro-PacketCable certificates.
Euro-PacketCable compliant embedded MTAs must have the Euro-DOCSIS root CVC CA's public key stored in the CM's non-volatile memory instead of the DOCSIS CVC CA's public key. Euro-PacketCable compliant standalone MTAs must have the tComLabs CVC Root Certificate and the tComLabs CVC CA certificate stored in non-volatile memory. The CVC of manufacturers are verified by checking the certificate chain.
Certificate Validation
PacketCable certificate validation in general involves validation of an entire chain of certificates. For example, when the Provisioning Server validates an MTA Device certificate, the following chain of certificates is validated:
MTA Root Certificate + MTA Manufacturer Certificate + MTA Device Certificate
The signature on the MTA Manufacturer Certificate is verified with the MTA Root Certificate and the signature on the MTA Device Certificate is verified with the MTA Manufacturer Certificate. The MTA Root Certificate is self-signed and is known in advance to the Provisioning Server. The public key present in the MTA Root Certificate is used to validate the signature on this same certificate.
Usually the first certificate in the chain is not explicitly included in the certificate chain that is sent over the wire. In the cases where the first certificate is explicitly included it must already be known to the verifying party ahead of time and must not contain any changes to the certificate with the possible exception of the certificate serial number, validity period, and the value of the signature. If changes other than these exist in the CableLabs Service Provider Root certificate that was passed over the wire in comparison to the known CableLabs Service Provider Root certificate, the device making the comparison must fail the certificate verification.
The exact rules for certificate chain validation must fully comply with RFC 2459, where they are referred to as Certificate Path Validation. In general, X.509 certificates support a liberal set of rules for determining if the issuer name of a certificate matches the subject name of another. The rules are such that two name fields may be declared to match even though a binary comparison of the two name fields does not indicate a match. RFC 2459 recommends that certificate authorities restrict the encoding of name fields so that an implementation can declare a match or mismatch using simple binary comparison.
PacketCable security follows this recommendation. Accordingly, the DER-encoded tbsCertificate.issuer field of a PacketCable certificate must be an exact match to the DER-encoded tbsCertificate.subject field of its issuer certificate. An implementation may compare an issuer name to a subject name by performing a binary comparison of the DER-encoded tbsCertificate.issuer and tbsCertificate.subject fields.
The sections below specify the required certificate chain, which must be used to verify each certificate that appears at the leaf node (at the bottom) in the PacketCable certificate trust hierarchy illustrated in Figure 5-2.
Validity period nesting is not checked and intentionally not enforced. Thus, the validity period of a certificate need not fall within the validity period of the certificate that issued it.
MTA Device Certificate Hierarchy
The device certificate hierarchy exactly mirrors that of the DOCSIS1.1/BPI+ hierarchy. It is rooted at a CableLabs issued PacketCable MTA Root certificate, which is used as the issuing certificate of a set of manufacturer's certificates. The manufacturer's certificates are used to sign the individual device certificates.
The information contained in the following tables contains the PacketCable specific values for the required fields according to RFC 2459. These PacketCable specific values must be followed according toTable 5-2, except that Validity Periods should be as given in the respective tables. If a required field is not specifically listed for PacketCable then the guidelines in RFC 2459 must be followed.
MTA Root Certificate
This certificate must be verified as part of a certificate chain containing the MTA Root Certificate, MTA Manufacturer Certificate, and the MTA Device Certificate.
MTA Manufacturer Certificate
This certificate must be verified as part of a certificate chain containing the MTA Root Certificate, MTA Manufacturer Certificate, and the MTA Device Certificate. The state/province, city and manufacturer's facility are optional attributes. A manufacturer may have more than one manufacturer's certificate, and there may exist one or more certificates per manufacturer. All certificates for the same manufacturer may be provided to each MTA either at manufacture time or during a field update. The MTA must select an appropriate certificate for its use by matching the issuer name in the MTA Device Certificate with the subject name in the MTA Manufacturer Certificate. If present, the authorityKeyIdentifier of the device certificate must match the subjectKeyIdentifier of the manufacturer certificate as described in RFC 2459. The <CompanyName> field that is present in O and CN may be different in the two instances.
MTA Device Certificate
This certificate must be verified as part of a certificate chain containing the MTA Root Certificate, MTA Manufacturer Certificate and the MTA Device Certificate. The state/province, city and manufacturer's facility are optional attributes. The MAC address must be expressed as six pairs of hexadecimal digits separated by colons, for example, "00:60:21:A5:0A:23". The alpha hexadecimal characters (A-F) must be expressed as uppercase letters. The MTA device certificate should not be replaced or renewed.
MTA Manufacturer Code Verification Certificates
Code Verification Certificate (CVC) specification for embedded MTAs must be identical to the DOCSIS 1.1 CVC, specified in DOCSIS specification SP-BPI+-I11-040407.
CableLabs Service Provider Certificate Hierarchy
The Service Provider Certificate Hierarchy is rooted at a CableLabs issued CableLabs Service Provider Root certificate. That certificate is used as the issuing certificate of a set of service provider's certificates. The service provider's certificates are used to sign an optional local system certificate. If the local system certificate exists then that is used to sign the ancillary equipment certificates, otherwise the ancillary certificates are signed by the Service Provider's CA.
The information contained in Table 5-5 contains the specific values for the required fields according to RFC 2459. These specific values must be followed. If a required field is not specifically listed then the guidelines in RFC 2459 must be followed exactly.
CableLabs Service Provider Root Certificate
Before any Kerberos key management can be performed, an MTA and a KDC need to perform mutual authentication using the PKINIT extension to the Kerberos protocol. An MTA authenticates a KDC after it receives a PKINIT Reply message containing a KDC certificate chain. In authenticating the KDC, the MTA verifies the KDC certificate chain, including KDC's Service Provider Certificate signed by the CableLabs Service Provider Root CA.
Service Provider CA Certificate
This is the certificate held by the service provider, signed by the CableLabs Service Provider Root CA. It is verified as part of a certificate chain that includes the CableLabs Service Provider Root Certificate, Telephony Service Provider Certificate, optional Local System Certificate and an end-entity server certificate. The authenticating entities normally already possess the CableLabs Service Provider Root Certificate and it is not transmitted with the rest of the certificate chain.
The fact that a Service Provider CA Certificate is always explicitly included in the certificate chain allows a Service Provider the flexibility to change its certificate without requiring reconfiguration of each entity that validates this certificate chain (for example, MTA validating a PKINIT Reply). Each time the Service Provider CA Certificate changes, its signature must be verified with the CableLabs Service Provider Root Certificate. However, a new certificate for the same Service Provider must preserve the same value of the OrganizationName attribute in the SubjectName. The <Company> field that is present in O and CN may be different in the two instances.
Local System CA Certificates
A Service Provider CA may delegate the issuance of certificates to a regional Certification Authority called Local System CA (with the corresponding Local System Certificate). Network servers are allowed to move freely between regional Certification Authorities of the same Service Provider. Therefore, the MTA MIB does not contain any information regarding a Local System Certificate (which might restrict an MTA to KDCs within a particular region).
Operational Ancillary Certificates
All these are signed by the either the Local System CA or by the Service Provider CA. Other ancillary certificates may be added to this standard at a later time.
Key Distribution Center Certificate
This certificate must be verified as part of a certificate chain containing the CableLabs Service Provider Root Certificate, Service Provider CA Certificate and the Ancillary Device Certificates. The PKINIT specification requires the KDC certificate to include the subjectAltName v.3 certificate extension, the value of which must be the Kerberos principal name of the KDC.
Delivery Function (DF)
This certificate must be verified as part of a certificate chain containing the CableLabs Service Provider Root Certificate, Service Provider CA Certificate and the Ancillary Device Certificates. This certificate is used to sign phase 1 IKE intra-domain exchanges between DFs (which are used in Electronic Surveillance). Although Local System Name is optional, it is required when the Local System CA signs this certificate. The IP address must be specified in standard dotted-quad notation, for example, 245.120.75.22.
PacketCable Server Certificates
These certificates must be verified as part of a certificate chain containing the CableLabs Service Provider Root Certificate, Service Provider Certificate, Local System Operator Certificate (if used) and the Ancillary Device Certificates. These certificates are used to identify various servers in the PacketCable system. For example, they may be used to sign phase 1 IKE exchanges or to authenticate a PKINIT exchange. Although the Local System Name is optional, it is REQUIRED when the Local System CA signs this certificate. 2IP address values must be specified in standard dotted decimal notation, for example, 245.120.75.22. DNS Name values must be specified as a fully qualified domain name (FQDN), for example, device.packetcable.com.
The CN attribute value for CMS certificates must be the Element ID. The subjectAltName extension must include either the IP Address or the FDQN of the CMS. The CN attribute value for CMTS certificates must be the Element ID. The subjectAltName extension must include either the IP Address or the FDQN of the CMTS.
The CN attribute value for MGC certificates must be the Element ID. The subjectAltName extension must include either the IP Address or the FDQN of the MGC.
Certificate Revocation
Out of scope for PacketCable at this time.
Code Verification Certificate Hierarchy
The CableLabs Code Verification Certificate (CVC) PKI is generic in nature and applicable to all CableLabs projects needing CVCs. This means the basic infrastructure can be re-used for every CableLabs project. There may be differences in the end-entity certificates required for each project, but in the cases where end-entity certificates overlap, one end-entity certificate could be used to support the overlap.
The CableLabs CVC hierarchy does not apply to E-MTAs. Refer to section 11 for more information.
Common CVC Requirements
The following requirements apply to all Code Verification Certificates:
•
•
•
•
CableLabs Code Verification Root CA Certificate
This certificate must be validated as part of the certificate chain containing the CableLabs Code Verification Root CA Certificate, the CableLabs Code Verification CA, and the Code Verification Certificates. See "Certificate Validation" section for additional information on how to validate certificates.
CableLabs Code Verification CA Certificate
The CableLabs Code Verification CA Certificate must be validated as part of a certificate chain containing the CableLabs Code Verification Root CA Certificate, CableLabs Code Verification CA Certificate and the Code Verification Certificate. See "Certificate Validation" section for additional information on how to validate certificates. There may be more than one CableLabs Code Verification CA. A S-MTA must support one CableLabs CVC CA at a time.
Manufacturer Code Verification Certificate
The CableLabs Code Verification CA issues this certificate to each authorized Manufacturer. It is used in the policy set by the cable operator for secure software download.
The Company Name in the Organization may be different than the Company Name in the Common Name.
Service Provider Code Verification Certificate
The Service Provider Code Verification Certificate must be validated as part of a certificate chain containing the CableLabs Code Verification Root CA Certificate, the CableLabs Code Verification CA Certificate, and the Service Provider Code Verification Certificate. Refer to the "Certificate Validation" section for additional information on how to validate certificates.
The Company Name in the Organization may be different than the Company Name in the Common Name.
Certificate Revocation Lists for CVCs
The S-MTA is not required to support Certificate Revocation Lists (CRLs) for CVCs.
Feedback