PROXY tickets and GSSAPI

[Nicolas Williams]

On Wed, Jun 26, 2002 at 03:48:54PM -0400, Wyllys Ingersoll wrote:
> 
> So, the benefit of PROXY tickets as opposed to a more general FORWARDABLE
> ticket is that the PROXY ticket may only be used from the addresses 
> specified
> in the ticket, correct?  Is an addressless PROXY ticket equivalent to a 
> FORWARDABLE
> ticket?

No, the difference between "proxied" and "forwarded" is that a proxied
ticket cannot be a TGT and a forwarded ticket must be a TGT. That is it.

> Is there a way to actually specify a service or list of services that 
> the server may
> act as a proxy for ?   Example, you only want the PROXY server to use your
> creds to access "print" services on some server but not other kerberized 
> services?

Well, the KRB-CRED messages, which is used to forward/proxy tickets and
which is used in the Kerberos GSS mech (RFC1964) can include more than
one ticket in it, so, if you know a priori what service tickets the
receipient will need then you can send all of those.

Problem is, no protocol out there, e.g., kerberized TELNET, GSS-API and
things that use such as FTP, and so on, none of them support sending
creds more than once, more than at session setup time. Well, ok, that's
not quite correct - it may be that kerberized TELNET supports that in
the spec, but it's not supported by any implementatio to my knowledge.
And SSHv2 with external GSS key exchange supports session re-keying by
engaging in another GSS exchange during which creds can be forwarded.

But overall, there is no mechanism by which a server can ask a client
for more proxied tickets and no mechanism by which a client can send
fresh forwarded or proxied tickets to the server (the latter generally
can't be done without session re-keying). Specifically the GSS-API does
not support the generation/acceptance of GSS messages that are only for
credentials forwarding. AND THERE IS NO REASON FOR IT TO BE SO.

But what would be the value of using proxied tickets instead of
forwarded tickets if it were practical?

I see two valuable reasons for being able to use proxied tickets in
practice:

1. So users can see to whom any remote services are impersonating them

and

2. So users can veto specific impersonation requests.

(2) is not likely to be used by many users, and (1), well, users would
just minimize the window with such log entries scrolling off.

(1) could be implemented by forwarding the KDC logs to the users' point
of initial login (where they get their initial TGTs).

Or (1) could be implemented by letting services ask the clients for
proxy service tickets on demand. And that would also facilitate (2).

Think of ssh-agent but for service tickets (or even better, for AP
exchanges).

Or think of a proxy TGS which users can start on their workstations.
A user would get a TGT, start their proxy TGS, and forward proxy tickets
for the user to talk to himself (the ticket enc key would be the session
key of the TGT) - the services would treat that proxied ticket as a
pseudo-TGT and use it to get service tickets from the user's proxy TGS.

These are the OOB channels I had in mind yesterday - something like
ssh-agent, which is really a channel multiplexed onto one stream
connection - or something like a proxy TGS which is truly an OOB.

But are any such OOB channels really necessary? If you can forward to
the users the TGS log entries relevant to them, wouldn't that sudffice?

The point of sending a service proxied tickets instead of forwarded
tickets would be that the user doesn't fully trust the service, so the
user sends something less than authorization to impersonate her to all
other services (and users). But users won't want to vet every
impersonation request. I'd love to see a proxy TGS/ssh-krb5-agent sort
of thing implemented, but I'm not dying for it.


> -Wyllys


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.