[4056] in Kerberos
Re: Delegation in KRB
daemon@ATHENA.MIT.EDU (Gary Gaskell)
Wed Oct 19 02:30:45 1994
To: kerberos@MIT.EDU
Date: Wed, 19 Oct 94 05:46:41 GMT
From: gaskell@thunder.dstc.qut.edu.au (Gary Gaskell)
Derek Atkins (warlord@MIT.EDU) wrote:
: One-hop cross-realm authentication is a Kerberos-IV thing. True
: realm-hopping is in Kerberos v5. The RFC documents krbv5, but I bet
: you are looking at v4!
: -derek
: Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
: Member, MIT Student Information Processing Board (SIPB)
: Home page: http://www.mit.edu:8001/people/warlord/home_page.html
: warlord@MIT.EDU PP-ASEL N1NWH PGP key available
Derek,
I was reading the internet RFC 1510. The proxy part is copied here for discussion
purposes.
---------------rfc1510 section 2.5----------------------
2.5. Proxiable and proxy tickets
At times it may be necessary for a principal to allow a service to
perform an operation on its behalf. The service must be able to take
on the identity of the client, but only for a particular purpose. A
principal can allow a service to take on the principal's identity for
a particular purpose by granting it a proxy.
The PROXIABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ticket-granting server that it is OK to
issue a new ticket (but not a ticket-granting ticket) with a
different network address based on this ticket. This flag is set by
default.
This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf, e.g., a print service client can give
the print server a proxy to access the client's files on a particular
file server in order to satisfy a print request.
------------end insert-----------------------
I interpret this as that the TGS can issue a new ticket with a new network
address. Is it possible for the target that is delegated to, to repeat this
request to the TGS for another ticket, with another network address?
You mention cross-realm authentication as a KRB 4 thing. Sorry, my question
was more aimed at delegation within a domain/realm. Simply is it possible to
continually delegate? Reading section 2.5, it seems that the ticket,
reissued from the TGS is not able to be submitted in a further delegation
request.
In reading the docs, I see no mention of delegation chains either nested
or not (looking back to the Varadharajan, Allan and Black paper titled,
" An Analysis of the proxy Problem in Distributed Systems".)
--
regards
Gary Gaskell
DSTC
Cooperative Research Centre for Distributed Systems Technology
Queensland University of Technology
Ph +61-7-864 1051 FAX +61-7-864 1282
Email gaskell@dstc.qut.edu.au URL http://www.dstc.edu.au/intro.html