[20048] in Kerberos_V5_Development
Re: Current semantics for channel-bindings in GSSAPI
daemon@ATHENA.MIT.EDU (Simo Sorce)
Mon Mar 2 11:53:25 2020
Message-ID: <02b02b60cc2ac8abdecebab1107e8cc3f79ebc19.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Isaac Boukris <iboukris@gmail.com>
Date: Mon, 02 Mar 2020 11:52:47 -0500
In-Reply-To: <CAC-fF8TV20-jOORjBzJKtS1s7u-fbxkyLN=v_dAbLfKY8EEkig@mail.gmail.com>
MIME-Version: 1.0
Cc: Nico Williams <nico@cryptonector.com>,
"krbdev@mit.edu Dev List" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, 2020-03-02 at 17:22 +0100, Isaac Boukris wrote:
> That may explains why Windows HTTP client would ask INTEG indeed. Note
> that over TLS Win LDAP client won't request INTEG even in SPNEGO,
> while the HTTP does.
I guess that makes sense because in that case integrity is provided by
the TLS channel, so you just need to bind to it to insure no tampering
happened.
Although HTTPS could be seen as the same, I assume they didn't want to
have the client/server application need to distinguish between HTTP and
HTTPS (especially because HTTPS was not so common when the SPNEGO RFC
was drafted) so it was easier to just always protect the integrity of
the mech list... for what it was worth ...
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
