[497] in Kerberos_Protocol
Re: Section 1 Kerberos Revisions for comment
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Fri Aug 4 15:36:55 2000
Date: Fri, 4 Aug 2000 15:34:34 -0400
From: Nicolas Williams <Nicolas.Williams@ubsw.com>
To: Clifford Neuman <bcn@ISI.EDU>
Cc: ietf-krb-wg@anl.gov, krb-protocol@MIT.EDU
Message-Id: <20000804153433.K21171@sm2p1386swk.wdr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200008030227.TAA05920@cayman-islands.isi.edu>
On Wed, 2 Aug 2000, Clifford Neuman wrote:
> Below is the preamble and section 1 (introduction) of the Kerberos
> revisions. It is followed by a list of things that have changed in
> this section since RFC1510. I think that there is not much that is
> unresolved in this section, though I would like feedback in particular
> on section 1.2 which is new. Please provide feedback on the list
> regarding any objections or suggestions for improvement this section.
>
> Clifford Neuman
I think it would be really nice if there were a common format for
encapsulating/naming multiple PAC data fields in a ticket.
Also, I do think that there is a minor form of authorization in
Kerberos: proxy tickets are a way of limiting the degree to which a
remote server may impersonate a client. Proxy tickets are not,
currently, very useful or, rather, they are not used much, in my
experience.
I have been pondering a number of ways of extending the useability of
proxy tickets, of giving more control to users and administrators over
principal impersonation. One possibility would be to have an out-of-band
protocol for remote server to request proxy tickets from the client as
needed. Another possibility would be to extend GSS-API and protocols
that support GSS-API to support such oob proxy ticket requests. Yet
another possibility is the restricted TGT idea I described in
http://www.mit.edu:8008/menelaus.mit.edu/kprot/485
With the out-of-band system users would have a chance to review, in
real-time, and even approve/deny proxy ticket requests. Most users might
not care, but in some circumstances such a feature might be very useful.
Nico
--
