Network Working Group P. Duffy
Request for Comments: 3594 Cisco Systems
Category: Standards Track September 2003
PacketCable Security Ticket Control Sub-Option
for the DHCP CableLabs Client Configuration (CCC) Option
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines a new sub-option for the DHCP CableLabs Client
Configuration (CCC) Option. This new sub-option will be used to
direct CableLabs Client Devices (CCDs) to invalidate security tickets
stored in CCD non volatile memory (i.e., locally persisted security
tickets).
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2].
2. Terminology
Definitions of terms/acronyms used throughout this document:
CCC - CableLabs Client Configuration option, described in [1].
CCD - CableLabs Client Device. A PacketCable MTA is an example of a
CCD.
STC - Security Ticket Control. The CCC sub-option described in this
document.
Duffy Standards Track [Page 1]
RFC 3594 Security Ticket Control September 2003
MTA - Media Terminal Adapter. The CCD specific to the PacketCable
architecture.
PacketCable - multimedia architecture developed by CableLabs. See
[8] for full details.
3. Introduction
The CableLabs Client Configuration Option [1] defines several
sub-options used to configure devices deployed into CableLabs
architectures. These architectures implement the PacketCable
Security Specification [4] (based on Kerberos V5 [5]), to support CCD
authentication and establishment of security associations between
CCDs and application servers.
CCDs are permitted to retain security tickets in local persistent
storage. Thus a power-cycled CCD is enabled to avoid expensive
ticket acquisition for locally persisted, non-expired tickets. This
feature greatly reduces the security overhead of a deployment.
This sub-option allows the service provider to control the lifetime
of tickets persisted locally on a CCD. The service provider requires
this capability to support operational functions such as forcing re-
establishment of security associations, remote testing, and remote
diagnostic of CCDs.
It should be noted that, although based on the Kerberos V5 RFC [5],
the PacketCable Security Specification is not a strict implementation
of this RFC. See [4] for details of the PacketCable Security
Specification.
4. Security Ticket Control Sub-option
This sub-option defines a Ticket Control Mask (TCM) that instructs
the CCD to validate/invalidate specific application server tickets.
The sub-option is encoded as follows:
Code Len TCM
+-----+-----+-----+-----+
| 9 | 2 | m1 | m2 |
+-----+-----+-----+-----+
The length MUST be 2. The TCM field is encoded as an unsigned 16 bit
quantity per network byte order. Each bit of the TCM is assigned to
a specific server or server group. A bit value of 0 means the CCD
MUST apply normal invalidation rules (defined in [4]) to the locally
Duffy Standards Track [Page 2]
RFC 3594 Security Ticket Control September 2003
persisted ticket for the server/server group. A bit value of 1 means
the CCD MUST immediately invalidate the locally persisted ticket for
the server/server group.
Bit #0 is the least significant bit of the field. The bit positions
are assigned as follows:
Bit #0 - the PacketCable Provisioning Server used by the CCD.
Bit #1 - the group of all PacketCable Call Management Servers used
by the CCD.
Bit #2 - #15. Reserved and MUST be set to 0.
If a CCD does not locally store tickets, it MUST ignore this
sub-option. Bit values not known to the CCD MUST be ignored.
datatracker.ietf.org