Dynamic Service Keys

Although the security specification implies that dynamic service keys should be supported, it currently does not place any requirements as to what messages might be used to implement this. Any mechanism used to support dynamic service keys should at a minimum, have the following properties:
  1. It should allow previously unknown core network devices to register with the KDC and obtain a service key
  2. It should associate an expiration time and version number with a key
  3. It should (obviously) be as secure as reasonably possible. In particular, it should exhibit Perfect Forward Secrecy.
  4. Preferably, it should re-use as many as possible of the messages and formats already required by the specification.
This version of the IPfonix, Inc. KDC includes an implementation of a dynamic keying mechanism that is designed to meet these goals. We describe it here so that implementors of other devices on the PacketCable network can use the provided mechanism to obtain service keys from the KDC without the need to pre-provision static keys into their devices.

As far as possible, the operations involved in obtaining a dynamic service key mirror those used by the MTA to establish shared secrets between itself and application servers.

In order to obtain a dynamic service key, the server should perform the following steps:
  1. Perform a PKINIT exchange with the KDC. The requirements on this exchange exactly match the requirements on the PKINIT exchange already described in the specification, with the exception that in the AS-REQ the server must provide a sequence of certificates rooted in the CableLabs Service Provider Root certificate rather than the MTA Root certificate. The precise requirements for these certificates are already provided in the PacketCable security specification.
  1. The PKINIT exchange should request a ticket for a service named “createkey” running on the KDC1. The principal identifier for this service is:

createkey/<KDC FQDN>@REALM

  1. Once it has obtained a ticket for the createkey service, the server then submits an AP-REQ to the KDC. This is exactly as described in section 6.5.2 of the security specification, with the following changes:

	                                   duration [0] INTEGER OPTIONAL -- duration in seconds

where the duration is the requested life of the service key in seconds. In the current implementation, the KDC ignores this value. In the future, however, it will be used.

Only the following ciphersuite is recognized:

  1. The AP-REP is identical to the AP-REP already described in the security specification, with the following changes:

                  PrincipalIdentifier, -- principal identifier associated with the key
                  INTEGER,             -- key version number
                  OCTET STRING,        -- key value
                  UTCTime OPTIONAL     -- key expiration

The PrincipalIdentifier type is defined as:

PrincipalIdentifier ::= SEQUENCE {

The contents of the key value OCTET STRING are the desired 24-octet 3DES service key.

1 In order to meet the requirement of Perfect Forward Secrecy, tickets for the createkey service can be obtained only via an AS-REQ. They cannot be obtained via a TGS-REQ.