Skip to content

TR-069

How to implement TR-069, ACS & Mutual TLS Authentication using TeskaLabs SeaCat PKI.

This document elaborates on how to implement secure, mutually authenticated TLS communication between CPE and ACS for TR-069. The base of this technical specification is the Technical Report "TR-069 CPE WAN Management Protocol Issue: 1 Amendment 6" published by The Broadband Forum.

It details how to enrol CPE using SCEP.

Architecture

SeaCat PKI & TR-069 architecture

Remarks

  • TR-069 client on CPE is an HTTPS client
  • ACS is an HTTP server
  • NGINX provides HTTPS termination and mutual TLS authentication
  • SeaCat PKI provides CA capability (Certification Authority)
  • SCEP client on CPE uses HTTP/1.0 protocol which is prescribed by SCEP specification

Certificates

Server CA Certificate

A long-term (20+ years) X.509 certificate that is pre-loaded into CPE during manufacturing. Also named "trusted root certificate".

CPE CA Certificate

A long-term (20+ years) X.509 certificate that downloaded into CPE using SCEP tool. CPE Certification Authority (CA) is operated by SeaCat PKI. This is typically different certificate from Server CA certificate.

CPE Certificate

A shorter (~ 1 year) unique CPE client certificate that is generated (enrollment) and renewed during a CPE lifecycle using SCEP. It is generated by SeaCat PKI CA, using CPE CA Certificate, based on the SCEP request from CPE (enrollment or renewal). The CPE private key is generated and stored on the CPE. Also named "client certificate".

Server Certificate

Issued by Server CA for 3 months, renewed periodically.

Detailed CPE ceremonies for Unique CPE client certificate

The ceremonies are handled by SCEP.

Enrollment

This is initial ceremony that obtains a first client certificate for CPE.

Triggered: After the CPE network connectivity becomes available, can be triggered periodically.

Pre-condition: CPE doesn't have the client certificate.

  1. CPE generates a client private/public key pair (CPK)
  2. CPE generates a Certificate Signing Request (CSR) using CPK
  3. CPE submits CSR to a SeaCat PKI over HTTPS PUT call (no client certificate is needed).
  4. The response contains a Client certificate or an error code.
  5. If error, the enrollment ceremony is restarted after 1 minute.
  6. The Client certificate is stored on CPE permanent storage and used with CPK for TR-069 / HTTPS calls to ACS.

CSR details:

  • The value of the CN field of CSR (and client certificate) MUST be globally unique for each CPE. Specifically, the CN field MUST adhere to the format recommended for the username/userid in TR-069 CPE WAN Management Protocol Issue: 1 Amendment 6 Section 3.4.4.

Renewal

This is regular ceremony that renews a client certificate when it's lifecycle is ending.

Triggered: After the CPE network connectivity becomes available and periodically 4x per day.

Pre-condition: CPE has the client certificate (even expired).

  1. CPE checks if the client certificate is about to expire or expired
  2. If a client certificate is expiring, CPE generates a new CSR
  3. CPE submits CSR to a SeaCat PKI over HTTPS PUT call (no client certificate is needed).
  4. The response contains a Client certificate or an error code.
  5. If error, this ceremony is restarted after 1 minute, when a client certificate is expired or after 4 hours when not yet expired.
  6. The Client certificate is stored on CPE permanent storage and used with CPK for TR-069 / HTTPS calls to ACS.

Remark: CRS requirements are the same as for Enrollment.

Remark: The renewal ceremony is very similar to an enrollment.

Communication flow

SeaCat PKI & TR-069 Flow

HTTPS/TLS specification

  • TLS v1.2+
  • RSA 2048 for CPE
  • RSA 4096 for Server
  • RSA 8192 for CA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Reference