[OpenAFS] openafs and Kerberos

[Jeffrey Hutzelman]

On Wednesday, November 23, 2005 10:23:25 AM -0800 Russ Allbery 
<rra@stanford.edu> wrote:

> Jim Rees <rees@umich.edu> writes:
>
>> What bothers me is that you can't delegate credentials unless you have
>> used those credentials for login.
>
> The OpenSSH folks consider this to be a security requirement, although I
> don't really understand why.

There are really two issues here.

First, the GSSAPI key exchange and user authentication methods do not allow 
for the delegation of credentials other than those used for the operation. 
This is a limitation of the protocol, which results in part from a 
limitation of the GSSAPI -- there simply is no way to delegate credentials 
other than as a side-effect of context establishment.


We could have chosen to provide a means to establish an additional context 
purely for the side-effect, but that would have been rather kludgy, and it 
would have solved only the special case where GSSAPI is used for 
authentication, but using credentials other than those the user wished to 
delegate.  It does nothing to address the more general problem, which 
includes cases where GSSAPI is not used for authentication as well as 
situations in which the user wishes to delegate credentials well after the 
session has been established (consider the case of renewing tickets, and 
wanting to forward the renewed tickets over already-established 
connections).

The most likely way to solve these problems would involve an extension to 
SSH to allow credential delegation on an already-established session, 
regardless of what authentication method was used.  At the moment, I don't 
have time to write that document.



The second issue relates to OpenSSH's handling of delegated credentials 
which do not end up being used to authorize login.  I can think of two 
cases where this might happen:

- A client attempts the GSSAPI userauth method, successfully establishes a
  context, and delegates credentials, but the userauth fails due to an
  authorization failure or other problem.  In this case, there is no
  particular security reason why the server should drop the delegated
  credentials, but it is _probably_ what the user wanted, and is somewhat
  easier to implement as well.

- A client uses the GSSAPI key exchange method and forwards credentials,
  but then ends up not using the external-gssapi userauth method, or uses
  it unsuccessfully.  In this case, there is again no security reason why
  the server should drop the delegated credentials(*), and it may be the
  case that the user did not intend for them to be dropped.  However, it
  may also be the case that the user does want them dropped, especially
  if external-gssapi failed due to an authorization failure, which is
  similar to the above case (and, in fact, difficult to distinguish for
  a user not familiar with the details of the protocol).  Unfortunately,
  the server has no way to tell the difference, so it's got to pick some
  behavior.  I won't defend OpenSSH's choice as being "more secure", but
  it is a valid choice.

(*) It may be the case that the client should not have delegated, but that
is the client's problem.  By the time the server has the credentials, it
is too late to do anything about it.

-- Jeff