Kerberos Ticket Forwarding patch/update

[Douglas E. Engert]

Derrick Schommer wrote:
>> So I would read this is the client will only delegate if the client want's > to and the KDC says it is OK.
> 
> So, Windows must, as default behavior, set GSS_C_DELEGATE_FLAG (at least in CIFS) as it always received the second ticket when talking to a system that's setup as "Trusted for Delegation."
> 

It should depend on the application, CIFS might set it all the time, and assumes
a Windows KDC will also pass the OK-AS-DELEGATE flag, thus the delegation for CIFS
is controlled by KDC.

> Samba can do the same, if needed. However, windows does indeed send a second ticket to the smbclient regardless to the GSS_C_DELEGATE_FLAG as it is today (unless that's implemented somewhere outside of the smb libraries). As the patch I've submitted works against the virtualized storage device (ARX) without a problem.
> 
> Probably because krb5.conf has forwardable = true;

forwardable = true says request a TGT that can request another TGT (usually to forwarded).
It does not say to forward it.  The requested TGT may or may not have the forwardable
bit set. If not set it can not request additional TGTs to be forwarded.
thus limiting the number of forwards.

> 
> "forward should in most cases be set to true, in order to forward tickets obtained as "forwardable" to remote hosts by default." via http://www.fnal.gov/docs/strongauth/krb5conf.html
> 

Not exactly. It depends on the Kerberos implementation and the application.

  Reading the MAN pages for krb5.conf on Solaris 10:

   forward = [true | false]

          Forces applications to forward the  user's  credentials
          (after  authentication)  to  the  remote server. This is
          valid for the following applications: rlogin, rsh,  rcp,
          rdist, and telnet.

  With Heimdal:

  forward = boolean
                Forward credentials to remote host (for rsh(1),
                telnet(1), etc).

  and with MIT I don't see the option.

None of these default to true, and only hint at the being used  by the older
Kerberos clients like rsh, telnet and ftp. SSH controls forwarding/Delegation
with the client ssh_config option GSSAPIDelegateCredentials which defaults to no.

In general it is not a good idea to delegate to untrusted machines,
as the TGT is as good as the one you get at login. How the client determines
the trust is up to the client. The OK-AS-DELEGATE is advisory information
from the KDC. SSPI will usually require it to be set before it will delegate.
The only exception I know of is when using an older non Windows KDC that
does not support OK-AS-DELEGATE, and the ksetup /SetRealmFlag realm Delegate
has been set.

Some confusion arises, as Microsoft introduced the OK-AS-DELEGATE bit to
the Kerberos protocol before it was in the RFCs. Other implementations
are stating to implement it.  A transition would have been much easier if
it was originally a NOT-OK-AS-DELEGATE flag, but it too late for that.


> Derrick
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444