[4056] in Kerberos

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post