Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt
Paul Duffy <paduffy@cisco.com> Wed, 26 February 2003 22:17 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29150 for <dhcwg-archive@odin.ietf.org>; Wed, 26 Feb 2003 17:17:31 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QMRDk16486 for dhcwg-archive@odin.ietf.org; Wed, 26 Feb 2003 17:27:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMRDp16483 for <dhcwg-web-archive@optimus.ietf.org>; Wed, 26 Feb 2003 17:27:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29030 for <dhcwg-web-archive@ietf.org>; Wed, 26 Feb 2003 17:16:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMPip16414; Wed, 26 Feb 2003 17:25:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMODp16369 for <dhcwg@optimus.ietf.org>; Wed, 26 Feb 2003 17:24:13 -0500
Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28925 for <dhcwg@ietf.org>; Wed, 26 Feb 2003 17:14:00 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1QMHsJR012893; Wed, 26 Feb 2003 17:17:54 -0500 (EST)
Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-94.cisco.com [161.44.149.94]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18073; Wed, 26 Feb 2003 17:17:53 -0500 (EST)
Message-Id: <4.3.2.7.2.20030226170700.023e6bd8@funnel.cisco.com>
X-Sender: paduffy@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Feb 2003 17:17:13 -0500
To: dhcwg@ietf.org
From: Paul Duffy <paduffy@cisco.com>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt
Cc: Sam Hartman <hartmans@mit.edu>, Ken Raeburn <raeburn@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Thanks for the careful read Sam/Ken...inline please... At 04:06 PM 2/21/2003 -0500, you wrote: >Hi. I'm not subscribed to the list, so please copy me on responses. >I'm sending these comments because a review of the option from a >Kerberos viewpoint was requested. > >First, I do not believe this document is an appropriate work item of >the IETF for the following reasons. I do not think it likely there >will ever be multiple implementations of the standard, so I do not >think it likely that the the standard will meet criteria for >advancement. The standard seems focused on a specific deployment >situation and in fact on a specific category of tightly specified >devices and has insufficient generic applicability to devices outside >that specific environment to be an Internet standard. I understand >these devices are being deployed on the open Internet. However it is >not necessary for the IETF to specify all protocols that are used over >the Internet. I realize this concern applies equally to the base >packetcable configuration option and as such will probably be >discarded. Objection noted, but the DHC WG and the IESG have already decided that it is appropriate for CableLabs to seek RFC status for its DHCP needs. Given that DHCP option 122 has been IESG approved, I do not see why it is any more/less appropriate to discuss this sub-option than any of the sub-options currently contained in DHCP option 122. See http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-06.txt Regarding your comment re: lack of "multiple implementations"...there are currently several dozen manufacturers that implement the PacketCable provisioning, security, signalling, etc, protocols. >The second reason this document seems poorly scoped for the IETF is >that while based on Kerberos, the authentication technology discussed >is not in fact Kerberos. The Packetcable group needed a standard and >could not wait for the Kerberos working group to conclude and publish >a document. As such they adopted a draft that is incompatible both >with RFC 1510 and with current drafts within the Kerberos working >group. Fields are added to protocol messages in a manner that does >cause implementations of RFC 1510 to reject the messages and will >interfere with future expansion of the protocol. The mandatory to use >encryption systems for Packetcable Kerberos are not even specified in >the IETF drafts or published RFCs. The Kerberos working group has >decided not to standardize the encryption systems that Packetcable >uses in part because the encryption systems that are being >standardized are significantly stronger. It may be possible to >implement a system that supports both Packetcable Kerberos and IETF >Kerberos--I know one vendor who is trying to do that. For many reasons (some of which you point out above...time being THE biggest, we need to get a product to market), PacketCable does not strictly adhere to RFC 1510. It is my hope that we can avoid expanding this discussion into a full-blown, fine-tooth-combing of the PacketCable Security architecture...this would take far too long. The simple intent of this draft, in context of the PacketCable Security architecture, is to give the service provider a mechanism to force ticket expiration on a remote device. The need to expire the ticket is independent from the specific flavor/variant of Kerberos employed. I sense that your main objection to this draft is that it implies that PacketCable Security is not 100% RFC 1510 compliant. Will one or two lines clarifying this, along with a ref to the PacketCable Security spec, suffice? >However it seems that the IETF should not spend time standardizing a >DHCP sub option for controlling an authentication system outside of the >scope of the IETF for use in a limited environment. Disagree...same reasoning as my first point. >If the IETF decides that this work is within our scope, a note needs >to be added to the draft clarifying the Kerberos compatibility issue. >A pointer to the Packetcable Kerberos specification should be added >along with a note that this specification is incompatible with current >RFC 1510 implementations and with ongoing working in the IETF. Something along the line of... "Note that the PacketCable Security Specification differs from RFC 1510, see [ref] for full technical details of PacketCable's Kerberos implementation". >The rationale for this draft claims that it will be used among other >reasons to cancel subscriber service. The presence of a Kerberos >ticket should not be used to imply authorization to use a service; >this is incompatible both with RFC 1510 and with current Kerberos >drafts. Even if the authorization data field is used to convey >authorization along with authentication, service tickets with should >not be issued with lifetimes longer than are acceptable. I.E. you >should only issue a ticket with a lifetime as long as you are willing >to have authorization cached. > >I believe that this problem should be fixed by removing the text >proposing that using this option is appropriate to notify a device >that service has been canceled and adding a requirement that the >security of the deployment MUST NOT depend on this option being >honored. The option if it exists should serve to invalidate caches to >deal with operational problems such as emergency rekeying of services >or testing, and the only effect of failing to honor this option should >be a temporary loss of service. Agreed. Service authorization is a bogus/incorrect argument. The text... "The service provider requires this capability to support operational functions such as disabling a subscriber's service, forcing re- establishment of security associations, or for testing and remote diagnostic of CCDs. " ...needs to be changed to something like... "The service provider requires this capability to support operational functions such as forcing re-establishment of security associations or for testing and remote diagnostic of CCDs. " >The format of this option is insufficiently extensible. Many of the >sixteen code points for available services have already been used and >experiences shows new Kerberos services tend to be deployed over time. 2 of 16 bits == many ? The PacketCable provisioning team collectively came up with the 16 bit field and feels this is sufficient for the foreseeable future. If we run out of bits, we can always extend into another sub-option. >Why would you want to selectively invalidate some but not all tickets? >If this option exists, it seems like providing a mechanism to >completely invalidate the cache should be sufficient. I share Kens concerns re: forcing all tickets to expire. Public key ops are expensive and we try to avoid them when possible (for scaling reasons, avalanche restart conditions, etc.). >Finally security considerations need to discuss the disadvantages of >storing persistent Kerberos tickets. Other deployments of Kerberos >are moving away from doing this and instead storing tickets in >volatile memory. It would be excellent if the write up of this issue >in the security considerations section gave numbers to justify the >need for persistent tickets, although requiring this would be >excessive. A couple of points here... It is my feeling that the security considerations section should specifically address the contents/functionality of this specific sub-option. An expanded general discussion re: pro/con of storing tickets is beyond what is needed here. That said, the PacketCable Security spec recommends specific ticket lifetime limits that are driven by the encryption algorithm selection. Per previous option 122 discussions, all agreed that the Cablelab's drafts should not be duplicating the PacketCable specifications. >--Sam Ken's point re: the verb "persist" is noted. I'll change the text. Cheers, >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt… Sam Hartman
- [dhcwg] Re: Comments on draft-ietf-dhc-pktc-kerb-… Ken Raeburn
- Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-… Paul Duffy
- Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-… Sam Hartman