[432] in Kerberos
Re: RPC et al
daemon@TELECOM.MIT.EDU (Steve Miller)
Wed Jul 6 16:49:54 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Re: Short Ticket Lifetime--
Possible workaround -
It might be possible to tweek the code in a few places that set or read the
the ticket lifetime to change the effective units from 5minutes to some
larger value. This would not involve any protocol change. It wouldn't
interoperate properly with "vanilla" installations.
Re: RPC --
Mike Kazar's first point -- re a duplicate response -- is well
taken. I don't know what the existing code does, but the request and response
both carry the requestor's timestamp, so should always be matched up
appropriately, discarding extraneous responses. Note that the responses are
not quite idempotent, since they will contain different session keys.
The second point is also on target, that is some of the management operations
are not idempotent, and need more than just a raw datagram transport. I don't
know what they currently run on -- I thought it was TCP, which will offer
the right behavior.
An RPC that provides *At-most-once* semantics is one way to address these
issues, but not the only way. You need duplicate suppression and retransmission
at the transport layer to get the right behavior -- TCP could do all this,
or certain request/response protocols, or certain RPC protocols. There are
a multitude of RPC protocols around, all of which do not provide the right
services. Again, the only real concern about switching the protocols to
be RPC based, given the right semantics, is interoperability, and perhaps
performance at the potential bottlenecks such as the Kerberos server.
Steve
