Ticket addresses w.r.t. forwarded tickets.
jaltman at columbia.edu
Tue Dec 6 10:14:47 EST 2005
Derek Atkins wrote:
> Sam Hartman <hartmans at MIT.EDU> writes:
>>>>>>> "Roland" == Roland Dowdeswell <Roland.Dowdeswell at MorganStanley.com> writes:
>> Roland> So, by default the MIT libs when asked to forward tickets
>> Roland> to the remote end will decide whether to include addresses
>> Roland> in the forwarded ticket by checking your current TGT and
>> Roland> seeing whether it has addresses. And the addresses that
>> Roland> the libs put in the forwarded ticket are determined via a
>> Roland> DNS forward lookup of the remote end's hostname. I would
>> Roland> like to have addressed TGTs while forwarding addressless
>> Roland> tickets, so I've put together a tiny patch which defines a
>> Roland> boolean in the [libdefaults] section of $KRB5_CONFIG to
>> Roland> let me do this [below].
>> Roland> What's the chance of including this in the main tree?
>> We'd really like to kill off addressful tickets. I'd like to see
>> significant demand for this before including it. But if someone else
>> wants to commit the patch I would not object.
> In delegated credentials I may want to delegate a credential that
> may only be used on a particular host.. Otherwise the processes
> on the destination may decide to copy my credential and use it
> elsewhere, which could be a security hole.
Your case is the exact opposite of Roland's case. As you are aware,
part of the problem these days with forwarding addressed tickets are
that without significant knowledge of the network infrastructure and
the configuration of the remote machine's network configuration, it is
next to impossible for the entity forwarding the ticket to determine
the correct set of addresses to restrict the ticket to.
We absolutely need to solve implement constraints but I just do not
see address constraints as being viable.
I would like to take a look at your patch. I believe that it will
assist in achieving the removal of addresses from tickets and would
consider applying it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3256 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20051206/ab7749fa/attachment.bin
More information about the krbdev