draft-ietf-dhc-pktc-kerb-tckt-02.txt   draft-ietf-dhc-pktc-kerb-tckt-03.txt 
Internet Engineering Task Force P. Duffy Internet Engineering Task Force P. Duffy
INTERNET DRAFT Cisco Systems INTERNET DRAFT Cisco Systems
DHC Working Group May 2003 DHC Working Group June 2003
Document: draft-ietf-dhc-pktc-kerb-tckt-02.txt Document: draft-ietf-dhc-pktc-kerb-tckt-03.txt
PacketCable Security Ticket Control Sub-option PacketCable Security Ticket Control Sub-option
for the CableLabs Client Configuration Option. for the DHCP CableLabs Client Configuration Option.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026. with all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 38 skipping to change at line 38
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines a new sub-option for the CableLabs Client This document defines a new sub-option for the DHCP CableLabs
Configuration (CCC) Option. This new sub-option will be used to Client Configuration (CCC) Option. This new sub-option will be
direct CableLabs Client Devices (CCDs) to invalidate locally used to direct CableLabs Client Devices (CCDs) to invalidate
persisted security tickets. security tickets stored in CCD non volatile memory (i.e. locally
persisted security tickets).
1. Conventions used in this document 1. Conventions used in this document
Duffy 1 Duffy 1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [2]. RFC 2119 [2].
2. Terminology 2. Terminology
skipping to change at line 90 skipping to change at line 91
expensive ticket acquisition for locally persisted, non-expired expensive ticket acquisition for locally persisted, non-expired
tickets. This feature greatly reduces the security overhead of tickets. This feature greatly reduces the security overhead of
a deployment. a deployment.
This sub-option allows the service provider to control the This sub-option allows the service provider to control the
lifetime of tickets persisted locally on a CCD. The service lifetime of tickets persisted locally on a CCD. The service
provider requires this capability to support operational provider requires this capability to support operational
functions such as forcing re-establishment of security functions such as forcing re-establishment of security
associations, remote testing, and remote diagnostic of CCDs. associations, remote testing, and remote diagnostic of CCDs.
Duffy Expires November 2003 2 Duffy Expires December 2003 2
It should be noted that, although based on the Kerberos V5 RFC It should be noted that, although based on the Kerberos V5 RFC
[5], the PacketCable Security Specification is not a strict [5], the PacketCable Security Specification is not a strict
implementation of this RFC. See [4] for details of the implementation of this RFC. See [4] for details of the
PacketCable Security Specification. PacketCable Security Specification.
4. Security Ticket Control Sub-option 4. Security Ticket Control Sub-option
This sub-option defines a Ticket Control Mask (TCM) that This sub-option defines a Ticket Control Mask (TCM) that
instructs the CCD to validate/invalidate specific application instructs the CCD to validate/invalidate specific application
server tickets. The sub-option is encoded as follows: server tickets. The sub-option is encoded as follows:
skipping to change at line 126 skipping to change at line 127
positions are assigned as follows. positions are assigned as follows.
Bit #0 - the PacketCable Provisioning Server used by the CCD. Bit #0 - the PacketCable Provisioning Server used by the CCD.
Bit #1 - the group of all PacketCable Call Management Servers Bit #1 - the group of all PacketCable Call Management Servers
used by the CCD. used by the CCD.
Bit #2 - #15. Reserved and MUST be set to 0. Bit #2 - #15. Reserved and MUST be set to 0.
If a CCD does not locally store tickets, it MUST ignore this sub- If a CCD does not locally store tickets, it MUST ignore this sub-
option. option. Bit values not known to the CCD MUST be ignored.
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign a sub-option code to this sub-option IANA is requested to assign a sub-option code to this sub-option
from the "CableLabs Client Configuration" sub-option number space from the "CableLabs Client Configuration" sub-option number space
(maintained within the BOOTP-DHCP Parameters Registry). (maintained within the BOOTP-DHCP Parameters Registry).
Duffy Expires November 2003 3 Duffy Expires December 2003 3
IANA is also requested to maintain a new number space of IANA is also requested to maintain a new number space of
"CableLabs Client Configuration Option Ticket Control Mask Bit "CableLabs Client Configuration Option Ticket Control Mask Bit
Definitions", located in the BOOTP-DHCP Parameters Registry. The Definitions", located in the BOOTP-DHCP Parameters Registry. The
initial bit definitions are described in section 4 of this initial bit definitions are described in section 4 of this
document. IANA is requested to register future bit mask document. IANA is requested to register future bit mask
definitions via an "IETF Consensus" approval policy as described definitions via an "IETF Consensus" approval policy as described
in RFC 2434 [3]. in RFC 2434 [3].
6. Security Considerations 6. Security Considerations
skipping to change at line 177 skipping to change at line 178
It should be noted that the downstream filtering of DHCP packets It should be noted that the downstream filtering of DHCP packets
will not prevent spoofed DHCP servers behind the CMTS, but the will not prevent spoofed DHCP servers behind the CMTS, but the
network infrastructure behind the CMTS is assumed to be closely network infrastructure behind the CMTS is assumed to be closely
controlled by the service provider. controlled by the service provider.
7. References 7. References
7.1. Normative 7.1. Normative
Duffy Expires November 2003 4 Duffy Expires December 2003 4
[1] B. Beser and P. Duffy, "DHCP Option for CableLabs Client [1] B. Beser and P. Duffy, "DHCP Option for CableLabs Client
Configuration", RFC 3495, March 2003. Configuration", RFC 3495, March 2003.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [3] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[4] "PacketCable Security Specification", PKT-SP-SEC-I08-030415, [4] "PacketCable Security Specification", PKT-SP-SEC-I08-030415,
skipping to change at line 222 skipping to change at line 223
specifications: specifications:
Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris,
Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Rodney Osborne (Arris Interactive); Steven Bellovin and Chris
Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria
Stachelek, Matt Osman, Venkatesh Sunkad (CableLabs); Klaus Stachelek, Matt Osman, Venkatesh Sunkad (CableLabs); Klaus
Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak
Patil (Com21); Jeff Ollis, Rick Vetter (General Patil (Com21); Jeff Ollis, Rick Vetter (General
Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter
Duffy Expires November 2003 5 Duffy Expires December 2003 5
Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay
Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon);
Prithivraj Narayanan (Wipro), and Burcak Beser (Juniper Prithivraj Narayanan (Wipro), and Burcak Beser (Juniper
Networks). Networks).
9. Author's Addresses 9. Author's Addresses
Paul Duffy Paul Duffy
Cisco Systems Cisco Systems
300 Apollo Drive 300 Apollo Drive
skipping to change at line 267 skipping to change at line 268
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. PURPOSE.
Acknowledgement Acknowledgement
Duffy Expires November 2003 6 Duffy Expires December 2003 6
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Duffy Expires November 2003 7 Duffy Expires December 2003 7
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/