[OpenAFS] Kerberos with AFS

[Jeffrey Hutzelman]

On Sun, 27 May 2001, Derrick J Brashear wrote:

> > > > What would the right approach be?  To forward just the v5 tickets and
> > > > then use them to obtain tokens, or to forward both?  Is there a place
> > > > where I can find sample code for doing forwarding of tickets and
> > > > tokens?  (We have some custom apps which we might need to modify to
> > > > perform such forwarding.)
> > > 
> > > The right approach would be to let the proposals on the table shake out
> > > and use something that's standardized instead of having another
> > > implementation which won't interoperate, but I suspect that's not the
> > > answer you're after.
> > 
> > That is not an option because there is nothing "standardized" to do
> > what I need (as far as I know).  The application is the Berkeley
> > "customs" suite, which we use to perform parallel builds with a
> > customs-enhanced GNU make.  It works well, but to use it in an AFS
> > environment will require forwarding the user's AFS credentials to the
> > machines participating in the build.
> > 
> > So I ask again: What is the right approach for forwarding AFS
> > credentials in a Kerberos v5 environment?  And where can I find
> > examples of code for performing such forwarding?
> 
> The right answer is to use a forwarded Kerberos v5 tgt and get an AFS
> credential on the remote machine. Telnet also has code to do it. My answer
> as far as SSH is still going to be the same, but I was hoping the relevant
> someone(s) would comment on the state of relevant standards-process
> documents, and from the looks of things they have not yet.

Derrick is correct -- the best answer is to forward your Kerberos v5 TGT,
and then use it to get tokens on the remote machine.  Kerberos credential
forwarding is available as a side-effect of using GSSAPI-KRB5 key exchange
and/or user authentication in the ssh v2 protocol.  See

draft-ietf-secsh-gsskeyex-01.txt
draft-galb-secsh-gssapi-01.txt

Patches are available from Simon Wilkinson to make OpenSSH support the
protocol extensions described in the two documents listed above.  I hope
to see these features rolled into the official OpenSSH distribution once
the standards work has progressed a little further.


For the moment, I would recommend that most sites hold off on deploying
this code for a few months.  While I have no reason to believe there is
anything wrong with it, I do expect incompatible protocol changes to both
key exchange and user auth in the next version of the draft.  Those
changes should be published well in advance of the August IETF meeting
(actually, I hope Simon will have _implemented_ the changes by August, but
I have no way to tell whether he will have time).

-- Jeff