Subject: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Feb 2003 16:06:48 -0500

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.

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.

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.

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.

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.

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.
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.

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.

--Sam

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 24 Feb 2003 15:00:27 -0500

> Kerberos viewpoint was requested.

Same here....

> to have authorization cached.

Agreed.  The security model should not rely on the CCD behaving
itself nicely.

Even if you want long-lived tickets, presumably to reduce the
frequency with which public-key PKINIT operations need to be done, and
if you want them to carry authorization data, you could use renewable
tickets or server-based hot-lists to close out a customer's access
fairly quickly.  Renewable tickets require repeated communication
with the KDC to get new valid tickets with later expiration times,
but they don't require the same public-key operations, and thus
should be cheaper in CPU time.

>   The option if it exists should serve to invalidate caches to
> or testing,

These do seem like valid reasons.

>   and the only effect of failing to honor this option should

If the issue is that the old service key has been exposed, failing to
honor this option could result in transmitting arbitrary data
"securely" to an intruder, or in a way that an intruder may be able to
read it.  I don't think there's much that can be done about that; it's
comparable to choosing not to check a certificate revocation list.

> completely invalidate the cache should be sufficient.

Completely invalidating the cache means starting over with public key
ops, and reauthenticating to unaffected services that may be in active
use at the time.  There may be some benefit to invalidating only
certain tickets, in cases like emergency rekeying of a single
compromised service.

I won't speak to the extensibility issue, not knowing much about the
Packet Cable context.

> need for persistent tickets, although requiring this would be

Keeping Kerberos tickets for the long term is probably not a great
idea, though since the CCD is presumably storing a public key pair
anyways, the usual reasons concerning limited exposure after a
compromise of the device don't apply as much.  The difficulty of
revocation is a more interesting issue.

However, since I'd expect the CCD is likely to reconnect and
reauthenticate to the system on power-up, avoidance of a huge server
load spike after a power outage by retaining tickets for a while would
be a good thing, especially with PKINIT.  (As would randomized delays,
if the retained tickets are found to have already expired at power-up
time.)

Oh, and an editorial issue: "Persist" is not a transitive verb in any
English-language dictionary I've checked; it doesn't take an object.
"The CCD persists Kerberos tickets" is just wrong.  "Persist" is what
the tickets do; it's not done to them.  Perhaps "retain" or "store"
should be used, maybe specifically mentioning persistent storage?
("Persistent", instead of "persisted", is fine as an adjective.)

Ken