On Wednesday, November 23, 2005 10:23:25 AM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Jim Rees <[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
