[20143] in Kerberos_V5_Development
Re: Is GSS_C_INTEG_FLAG required for calling gss_wrap/unwrap
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Sun Jun 28 12:43:03 2020
MIME-Version: 1.0
In-Reply-To: <CAC-fF8SbJbEg=8gX2JhzN0wwTCfjA1Dud0hOWMnqqzEn9WyN8A@mail.gmail.com>
From: Isaac Boukris <iboukris@gmail.com>
Date: Sun, 28 Jun 2020 18:42:41 +0200
Message-ID: <CAC-fF8Rx0vc_eTYKUHndMBGY3NhV=TfMxeHmrwvWRZQM5XPEmQ@mail.gmail.com>
To: "krbdev@mit.edu Dev List" <krbdev@mit.edu>,
Stefan Metzmacher <metze@samba.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Jun 26, 2020 at 1:57 PM Isaac Boukris <iboukris@gmail.com> wrote:
>
> According to RFC 2274, GSS_C_INTEG_FLAG:
> True - Integrity service may be invoked by calling either gss_get_mic
> or gss_wrap routines.
>
> But per my testing even with GSS_KRB5_CRED_NO_CI_FLAGS_X and not
> asking for GSS_C_INTEG_FLAG (integ/conf are false in ap-req), both
> parties are able to call gss_wrap/unwrap (windows server), is that
> expected?
For more context, and to correct some of what I said in the
channel-bindings discussion; I was trying to test if an intercepted
token from a clear-text ldap connection could be used over TLS, and it
looks like it could not, if the client requested the integ flag.
As I see it, with GSS-SPNEGO sasl mech the security layers are derived
from the GSS flags so when the integ flag is set in the ap-request the
bind is not accepted when over TLS (so that is why we need
GSS_KRB5_CRED_NO_CI_FLAGS_X).
On the other hand with the GSSAPI sasl mech (rfc4752), the integ flag
is always requested in the GSS level (so Windows allows ap-req with
integ flag over TLS), and the sasl security layers (even 0) are
negotiated after the GSS context is established, by exchanging more
sasl tokens protected by gss_wrap/unwrap.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
