CMTS - Superseded by a later version of this document.

The CMTS’s first receipt of an Authorization Request message from an unauthorized CM initiates the activation of a new Authorization Key (AK), which the CMTS returns to the CM in an Authorization Reply message (see Section 7). This AK will remain active until it expires according to its predefined lifetime, Authorization Key Lifetime, which is a CMTS system configuration parameter (see Annex A).

The CMTS uses keying material derived from the CM’s Authorization Key for:

• Verifying the HMAC-Digest in Key Requests received from the CM;

• Encrypting (EDE mode two-key 3DES) the TEK in the Key Replies that it sends to the CM;

• Calculating the HMAC-Digests in Key Replies, Key Rejects and TEK Invalids sent to the CM. See Section 7 for TEK messaging (Key Requests, Key Replies, Key Rejects, etc) details.

The CMTS MUST be prepared to send an AK upon request. The CMTS MUST be able to support two simultaneously-active AKs for each client CM.

If the CMTS holds two active Authorization Keys for a CM, it responds to Authorization Requests with the newer of the two active keys. If the CMTS holds a single active Authorization Key, a received Authorization Request will trigger the activation of a new AK, as described below.

An Authorization Key "transition period" begins when the CMTS receives an Authorization Request from a CM and the CMTS has a single active AK for that CM. In response to this Authorization Request, the CMTS activates a second AK, which it returns to the requesting CM in an Authorization Reply. The CMTS MUST set the active lifetime of this second AK to be the remaining lifetime of the first AK plus the predefined Authorization Key Lifetime. The key transition period ends with the expiration of the older key. This is depicted in the top half of Figure 10-1.

The Authorization Key lifetime that the CMTS reports in an Authorization reply MUST be set to the remaining lifetimes of the AKs at the time the reply message is sent.

If a CM fails to reauthorize before the expiration of its most recently-acquired AK, the CMTS will hold no active Authorization keys for the CM and will consider the CM unauthorized. A CMTS MUST deactivate all TEKs associated with an unauthorized CM.

The CMTS tracks the lifetime of its Authorization Keys; the CMTS MUST immediately deactivate a key once it has expired.

A CMTS MUST use a CM’s active AK(s) to verify the HMAC-Digest in Key Requests received from the CM. If a CMTS receives a Key Request while in an AK transition period, and the AK Key Sequence Number indicates that the Request was authenticated with the newer of the two AKs, the CMTS MUST recognize this as an implicit acknowledgment that the CM has obtained the newer of the CM’s two active AKs.

The CMTS MUST use an active AK when calculating HMAC-Digests in Key Replies, Key Rejects and TEK Invalids, and when encrypting the TEK in Key Replies. When sending Key Replies, Key Rejects or TEK Invalids within a key transition period and the newer key has been implicitly acknowledged, the CMTS MUST use the newer of the two active. If the newer key has not been implicitly acknowledged, the CMTS MUST use the older of

Figure 10-1 illustrates the CMTS’s use of AKs.

Figure 10-1 - Authorization Key Management in CMTS and CM

The CMTS MUST be capable of maintaining two sets of active traffic encryption keys (and their associated CBC initialization vectors) per SAID. These correspond to two successive generations of keying material, and have overlapping lifetimes. The CMTS MUST make the newer TEK have a key sequence number one greater than that of the older TEK (modulo 16). Each TEK becomes active halfway through the lifetime of its predecessor and expires halfway through the lifetime of its successor. Once a TEK expires, the TEK becomes inactive and the CMTS MUST NOT use that TEK.

For each of its SAIDs, the CMTS transitions between active TEKs according to the following rules:

• For encrypting downstream traffic, the CMTS MUST use the oldest available active TEK;

• For decryption of upstream traffic, a transition period is defined that begins once the CMTS has sent the newer TEK to a CM within a Key Reply Message. The upstream transition period begins from the time the CMTS sends the newer TEK in a Key Reply Message and concludes once the older TEK expires. While in the transition period, the CMTS MUST be able to decrypt upstream traffic with whichever of the two active TEKs was used to encrypt it.

In other words, the CMTS encrypts with a given TEK for only the second half of that TEK’s total lifetime; the CMTS is able, however, to decrypt with a given TEK for that TEK’s entire lifetime.

The KEY_SEQ field in the Baseline Privacy EH element identifies which of the two active TEKs was used to encrypt the upstream frame’s packet data. The TOGGLE bit in the Privacy EH element (which is required to be equal to the least significant bit of the KEY_SEQ field) can be used by the CMTS to identify the encrypting TEK. Figure 10-2 illustrates how a CMTS manages TEKs. The Key Replies sent by a CMTS contain TEK parameters (the TEK itself, a key lifetime, a key sequence number and a CBC IV) for the two active TEKs. The key lifetimes that a

CMTS reports in a Key Reply MUST be set to the remaining lifetimes of these TEKs at the time that the Key Reply message is sent. TEK 1 Lifetime TEK 2 Lifetime TEK 3 Lifetime TEK 1 Remaining Lifetime Key Reply { TEKs 1,2} TEK 4 Lifetime newer TEK (encrypt and decrypt) older TEK (decrypt) Key Request Cable Modem CMTS TEK 2 TEK 1 TEK 5 TEK 3 TEK 2 TEK 2 TEK 1 TEK 3 TEK 5 TEK 2 newer TEK (decrypt) older TEK (encrypt and decrypt) TEK 3 TEK 4 TEK4 TEK 5 TEK 6 TEK 2 Remaining Lifetime Grace TEK 3 Remaining Lifetime Grace TEK 5 Lifetime TEK 3 TEK 4 Key Request Key Request TEK 4 Remaining Lifetime Grace TEK 4 Key Request TEK 5 Remaining Lifetime