[7266] in Kerberos
Re: ref_flags
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Mon May 13 19:10:34 1996
To: kerberos@MIT.EDU
Date: 13 May 1996 18:52:42 -0400
From: tytso@dcl.mit.edu (Theodore Y. Ts'o)
In article <3193BAC7.5819@slh0633.wins.icl.co.uk> Dave Clarke <DGClarke1@aol.com> writes:
>As I understand it, Kerberos provides protection against replays, and out
>of sequence messages. However, If using GSS-API I place, for example
>GSS_C_REPLAY_FLAG into the req_flags of gss-init_security_context, the
>value in ret_flags after the call never includes this feature. I have
>checked in src/lib/gssapi/krb5/init_sec_context.c, and the following is
>observed:...
>
>Surely it would be better to return the requested feature if it was
>supplied, and not if it wasn't.
>
>I understand that the replay & sequence checks can't be disabled, but
>doing things the way they are now gives rise to difficulties deciding
>whether a given context conforms to required policy, since I can't
>request a feature generically, looking at the ret_flags to determine
>support for it or not.
The issue is that while Kerberos provides protection against replay
attacks of the authentication mechanism, the GSSAPI implementation which
is currently in the MIT tree does not support detection of replay and
out of sequence messages of data messages sent via gss_seal and
gss_wrap. Those features simply weren't implemented in the GSSAPI
implementation that was donated to us by OpenVision, which is why the
current implementation masks out those flags --- quite correctly, since
the current GSSAPI library does not provide those security services.
We are currently in the process of integrating a more recent version of
the GSSAPI library, which OpenVision has generously supplied to us, but
it won't be ready in time for the Beta 6 release. (I want to get that
release out as soon as possible, pending resolution of a few issues.)
- Ted
