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:
- It should allow previously unknown
core network devices to register with the KDC and obtain a service
key
- It should associate an expiration
time and version number with a key
- It should (obviously) be as secure
as reasonably possible. In particular, it should exhibit Perfect
Forward Secrecy.
- 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:
- 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.
- The PKINIT exchange should request
a ticket for a service named “createkey” running on the
KDC.
The principal identifier for this service is:
createkey/<KDC
FQDN>@REALM
- 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:
- The DOI is (arbitrarily) set to
250 (decimal)
- The Application Specific Data is
an ASN.1 encoded value defined as:
CREATE_KEY_APPLICATION_SPECIFIC_DATA ::= SEQUENCE {
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:
- Authentication Algorithm must
have the value 0x00, corresponding to no authentication
- Encryption Transform ID must have
the value 0x01, corresponding to 3DES (because only 3DES service
keys are supported by PacketCable)
- The AP-REP is identical to the
AP-REP already described in the security specification, with the
following changes:
- The DOI is (arbitrarily) set to
250 (decimal)
- The kerberos subkey field contains
a 24-octet 3DES session key, ks.
- The Application Specific Data
contains an ASN.1 OCTET STRING. The contents of the OCTET STRING are
encoded object, padded as necessary to a multiple of eight octets,
and encrypted by 3DES CBC encryption with a null IV and using the
key ks.
- Once decrypted, the OCTET STRING
in the Application Specific Data contains a SERVICE_KEY object:
SERVICE_KEY ::= SEQUENCE (
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 {
PrincipalName,
Realm
}
The contents of the key value OCTET STRING are the desired 24-octet 3DES service key.