Current semantics for channel-bindings in GSSAPI

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Current semantics for channel-bindings in GSSAPI

Isaac Boukris
Hi Greg, all

Following the discussion on  IRC, there is currently a difference in
between Heimdal and MIT, when the client does not send bindings, and
the server does pass bindings to accept(), in MIT it fails, in Heimdal
it succeeds.

In Windows, there is a three option flag:
LdapEnforceChannelBindings=0 - not enforced at all.
LdapEnforceChannelBindings=1 - enforced on supporting clients
(bindings not zeroes, and that ad-element).
LdapEnforceChannelBindings=2 - enforced for all clients.

To my understanding, we can implement LdapEnforceChannelBindings=2 in
MIT and LdapEnforceChannelBindings=1 in Heimdal by passing the
bindings to accept(), but not vise versa.

In my opinion MIT behavior is correct, allowing to enforce
channel-binding indeed, and I think we should consider the same in
Heimdal.

Nevertheless, we need a way to implement both option. The only way I
can think how to currently implement LdapEnforceChannelBindings=1 in
MIT is to call accept() twice and hope not to get replay-errors.

Thoughts?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
I was able to confirm that Windows would enforce channel-bindings (not
allow all zeroes), when I add this ad-element in the MIT client code I
get an error, while it works when I do pass the CB, even with level 2
(using "tls-server-end-point" from rfc 5056).

https://github.com/iboukris/krb5/commit/1897f9a65a79587209b14d1e6cb584dfc2cf2138

$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/ldapsearch -h
adc.acme.com -b dc=acme,dc=com cn=administrator -Y GSSAPI -N -O
maxssf=0 -ZZ
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-0C090569, comment:
AcceptSecurityContext error, data 80090346, v4563


btw, these are the openldap/cyrus wip branches I test with:
https://github.com/iboukris/openldap/commits/gssapi_cbind
https://github.com/iboukris/cyrus-sasl/commits/sasl_gssapi_cbt


Hacked MIT client code:

authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
    cusec: 233908
    ctime: 2020-02-28 13:14:45 (UTC)
    subkey
    seq-number: 758067575
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data: 3010300ea0040202008fa106040400400000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set


Windows client:

authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
        cksumtype: cKSUMTYPE-GSSAPI (32771)
        checksum: 100000009e41a51ed7c90b3597bc7217c4d3c41e02400000
        Length: 16
        Bnd: 9e41a51ed7c90b3597bc7217c4d3c41e
        .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
        .... .... .... .... .... .... ..0. .... = Integ: Do NOT use
integrity protection
        .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
Confidentiality (sealing)
        .... .... .... .... .... .... .... 0... = Sequence: Do NOT
enable out-of-sequence detection
        .... .... .... .... .... .... .... .0.. = Replay: Do NOT
enable replay protection
        .... .... .... .... .... .... .... ..1. = Mutual: Request that
remote peer authenticates itself
        .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
    cusec: 73
    ctime: 2020-02-26 18:24:27 (UTC)
    subkey
    seq-number: 2072188652
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data:
3081a9303fa0040202008da137043530333031a003020100a12a04280000000000300000…
                AuthorizationData item
                    ad-type: AD-TOKEN-RESTRICTIONS (141)
                    ad-data:
30333031a003020100a12a04280000000000300000f450fe871880d38a409147a4f8e2d7…
                        restriction-type: 0
                        restriction:
0000000000300000f450fe871880d38a409147a4f8e2d79a2107498eaab6449f374a2ec1…
                AuthorizationData item
                    ad-type: AD-LOCAL (142)
                    ad-data: b0b55b71c9010000876ec90000000000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
                AuthorizationData item
                    ad-type: AD-TARGET-PRINCIPAL (144)
                    ad-data:
6c006400610070002f007300640063002e0073006d0062002e006e006500740040005300…
                        Target Principal: ldap/[hidden email]

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Greg Hudson
In reply to this post by Isaac Boukris
On 2/27/20 8:27 PM, Isaac Boukris wrote:
> Following the discussion on  IRC, there is currently a difference in
> between Heimdal and MIT, when the client does not send bindings, and
> the server does pass bindings to accept(), in MIT it fails, in Heimdal
> it succeeds.

There are a few reasons why I think Heimdal's behavior is better:

* It's symmetric with the initiator.

* It's symmetric with other mechanisms like Moonshot.  (More research
may be required here; in particular, does NTLM enforce channel bindings
when one party doesn't pass them?)

* GSS generally does not fail a security context if it can't fulfill a
requested option; instead, the caller can find out which options
succeeded.  For instance, if you ask for confidentiality and the mech
can't provide that, you get a security context without the
confidentiality flag set.

* gss_accept_sec_context() has output flags but not input flags.  So
it's easy to add a channel-bound flag indicating that channel bindings
were used; it's significantly harder to add an input flag to indicate
whether channel bindings should be enforced.

* Even without any other changes, Heimdal's behavior allows channel
bindings to be introduced into an application protocol gradually,
whereas MIT's behavior requires upgrading all of the clients before any
of the servers.  Neither party polices the other, but when both parties
supply channel bindings the negotiation will fail if an attacker replays
it within a different channel.

For historical context, there is a lot of conversation about
draft-ietf-kitten-channel-bound-flag in the kitten archives, although
this specific point is only touched on at the end (after Sam's review).

> To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
> documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
> I was able to confirm that Windows would enforce channel-bindings (not
> allow all zeroes)

I am a little confused about the need for this flag.  The GSS client
code knows whether the application supplied channel bindings, so it
seems like it can fail locally if channel bindings are expected.  I
guess it doesn't know whether the server is level 0 or level >=1, but
I'm still not sure what security guarantees level 1 is trying to provide.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Stefan Metzmacher
Am 28.02.20 um 18:00 schrieb Greg Hudson:

> On 2/27/20 8:27 PM, Isaac Boukris wrote:
>> Following the discussion on  IRC, there is currently a difference in
>> between Heimdal and MIT, when the client does not send bindings, and
>> the server does pass bindings to accept(), in MIT it fails, in Heimdal
>> it succeeds.
>
> There are a few reasons why I think Heimdal's behavior is better:
>
> * It's symmetric with the initiator.
>
> * It's symmetric with other mechanisms like Moonshot.  (More research
> may be required here; in particular, does NTLM enforce channel bindings
> when one party doesn't pass them?)
As far as I can tell the server enforces them when the client provides
them. That means there's a way in the protocol to distinguish between
GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.

E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.

While KERB_AP_OPTIONS_CBT is needed for that for kerberos.

> * GSS generally does not fail a security context if it can't fulfill a
> requested option; instead, the caller can find out which options
> succeeded.  For instance, if you ask for confidentiality and the mech
> can't provide that, you get a security context without the
> confidentiality flag set.
>
> * gss_accept_sec_context() has output flags but not input flags.  So
> it's easy to add a channel-bound flag indicating that channel bindings
> were used; it's significantly harder to add an input flag to indicate
> whether channel bindings should be enforced.
I think using excplicit acceptor_creds and flag the requested behavior
there, it's similar to the ignore transited problem.

It would be good to make some generic progress here, as we'll likely
need more of these application driven options.

> * Even without any other changes, Heimdal's behavior allows channel
> bindings to be introduced into an application protocol gradually,
> whereas MIT's behavior requires upgrading all of the clients before any
> of the servers.  Neither party polices the other, but when both parties
> supply channel bindings the negotiation will fail if an attacker replays
> it within a different channel.
>
> For historical context, there is a lot of conversation about
> draft-ietf-kitten-channel-bound-flag in the kitten archives, although
> this specific point is only touched on at the end (after Sam's review).
>
>> To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
>> documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
>> I was able to confirm that Windows would enforce channel-bindings (not
>> allow all zeroes)
>
> I am a little confused about the need for this flag.  The GSS client
> code knows whether the application supplied channel bindings, so it
> seems like it can fail locally if channel bindings are expected.  I
> guess it doesn't know whether the server is level 0 or level >=1, but
> I'm still not sure what security guarantees level 1 is trying to provide.
The problem is kerberos or NTLMSSP without GSS_C_CONF_FLAG and without
GSS_C_INTEG_FLAG. If this is used within TLS the server receiving the
AP-REQ could just replay that to another server. A client knowning about
the correct channel bindings can prevent such attacks, but the server
needs level=1 (or higher) to detect that.

metze


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
In reply to this post by Greg Hudson
On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:

>
> On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > Following the discussion on  IRC, there is currently a difference in
> > between Heimdal and MIT, when the client does not send bindings, and
> > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > it succeeds.
>
> There are a few reasons why I think Heimdal's behavior is better:
>
> * It's symmetric with the initiator.
>
> * It's symmetric with other mechanisms like Moonshot.  (More research
> may be required here; in particular, does NTLM enforce channel bindings
> when one party doesn't pass them?)
>
> * GSS generally does not fail a security context if it can't fulfill a
> requested option; instead, the caller can find out which options
> succeeded.  For instance, if you ask for confidentiality and the mech
> can't provide that, you get a security context without the
> confidentiality flag set.
>
> * gss_accept_sec_context() has output flags but not input flags.  So
> it's easy to add a channel-bound flag indicating that channel bindings
> were used; it's significantly harder to add an input flag to indicate
> whether channel bindings should be enforced.
>
> * Even without any other changes, Heimdal's behavior allows channel
> bindings to be introduced into an application protocol gradually,
> whereas MIT's behavior requires upgrading all of the clients before any
> of the servers.  Neither party polices the other, but when both parties
> supply channel bindings the negotiation will fail if an attacker replays
> it within a different channel.

I find more value in being able to enforce it at least on one side,
and to my understanding that is the main feature in MS implementation,
and level 2 is intended to be the default at some point.
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

While I agree we also need level 1, and we could also use better
signaling with the client, I don't think it is a reason to regress on
the main feature, technically people may be using it, although
unlikely. Also, I was hoping to provide server support for current MIT
releases.

> For historical context, there is a lot of conversation about
> draft-ietf-kitten-channel-bound-flag in the kitten archives, although
> this specific point is only touched on at the end (after Sam's review).
>
> > To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
> > documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
> > I was able to confirm that Windows would enforce channel-bindings (not
> > allow all zeroes)
>
> I am a little confused about the need for this flag.  The GSS client
> code knows whether the application supplied channel bindings, so it
> seems like it can fail locally if channel bindings are expected.  I
> guess it doesn't know whether the server is level 0 or level >=1, but
> I'm still not sure what security guarantees level 1 is trying to provide.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Greg Hudson
In reply to this post by Stefan Metzmacher
On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> As far as I can tell the server enforces them when the client provides
> them. That means there's a way in the protocol to distinguish between
> GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
>
> E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
>
> While KERB_AP_OPTIONS_CBT is needed for that for kerberos.

RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
the vanishingly unlikely scenario where all bits of the hash are zero,
it's possible to distinguish between a client's
GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.

>From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
a lever to force applications to supply TLS channel bindings.  It
enables a weird policy: at server enforcement level 1, client
applications that don't provide bindings will interoperate if and only
if they are running on a sufficiently old versions of Windows.  That's
not a coherent policy in the context of open standards, but it probably
makes sense for a pure Windows ecosystem.

>> * gss_accept_sec_context() has output flags but not input flags.  So
>> it's easy to add a channel-bound flag indicating that channel bindings
>> were used; it's significantly harder to add an input flag to indicate
>> whether channel bindings should be enforced.
>
> I think using excplicit acceptor_creds and flag the requested behavior
> there, it's similar to the ignore transited problem.
>
> It would be good to make some generic progress here, as we'll likely
> need more of these application driven options.

draft-ietf-kitten-channel-bound-flag does define
gss_create_sec_context(), and there's an implementation for MIT kicking
around if we have a need for it.  (The draft as a whole doesn't reflect
working group consensus as I understand it, but that specific part of it
could be implemented.)

"Ignore transited policy" would probably be best handled through
gss_set_sec_context_option(), rather than a GSS request flag.  GSS flags
are somewhat precious, and the application preference is very
specifically about tolerating a particular krb5 KDC implementation's
non-conformance to a specific part of RFC 4120.

Still, for the reasons I laid out, I think channel binding policing is
best left to the application via an output flag.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Stefan Metzmacher
Am 28.02.20 um 21:33 schrieb Greg Hudson:

> On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
>> As far as I can tell the server enforces them when the client provides
>> them. That means there's a way in the protocol to distinguish between
>> GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
>>
>> E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
>>
>> While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
>
> RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> the vanishingly unlikely scenario where all bits of the hash are zero,
> it's possible to distinguish between a client's
> GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
>
> From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> a lever to force applications to supply TLS channel bindings.  It
> enables a weird policy: at server enforcement level 1, client
> applications that don't provide bindings will interoperate if and only
> if they are running on a sufficiently old versions of Windows.  That's
> not a coherent policy in the context of open standards, but it probably
> makes sense for a pure Windows ecosystem.
For SMB windows sends channel bindings of 16 zeros together with
the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
the request if the md5sum of gss_channel_bindings_struct { 0, } would be
provided instead.

I guess the bit means that client and server should agree that both
sides use 16 zeros. In that case the AP exchange is protected by
GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
knowing the session key.

>>> * gss_accept_sec_context() has output flags but not input flags.  So
>>> it's easy to add a channel-bound flag indicating that channel bindings
>>> were used; it's significantly harder to add an input flag to indicate
>>> whether channel bindings should be enforced.
>>
>> I think using excplicit acceptor_creds and flag the requested behavior
>> there, it's similar to the ignore transited problem.
>>
>> It would be good to make some generic progress here, as we'll likely
>> need more of these application driven options.
>
> draft-ietf-kitten-channel-bound-flag does define
> gss_create_sec_context(), and there's an implementation for MIT kicking
> around if we have a need for it.  (The draft as a whole doesn't reflect
> working group consensus as I understand it, but that specific part of it
> could be implemented.)
>
> "Ignore transited policy" would probably be best handled through
> gss_set_sec_context_option(), rather than a GSS request flag.
Using gss_create_sec_context() and
gss_set_sec_context_option(GSS_KRB5_NO_TRANSIT_CHECK_X) instead of
gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) would work for
me from Samba.

But I don't yet understand what it takes to implement that in the
Kerberos libraries as the resulting sec_context is not attached
to the krb5 mech.

> GSS flags are somewhat precious, and the application preference is very
> specifically about tolerating a particular krb5 KDC implementation's
> non-conformance to a specific part of RFC 4120.
>
> Still, for the reasons I laid out, I think channel binding policing is
> best left to the application via an output flag.

I guess it would also be good to export the raw 16 byte value
and also indicate that the client asked for the channel bindings to
match exactly (with KERB_AP_OPTIONS_CBT or by providing MsvChannelBindings).

Maybe using gss_inquire_sec_context_by_oid() would be a good idea
for these cases instead of using ret_flags from gss_accept_sec_context().

metze


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[hidden email]> wrote:

>
> Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> >> As far as I can tell the server enforces them when the client provides
> >> them. That means there's a way in the protocol to distinguish between
> >> GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
> >>
> >> E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
> >>
> >> While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> >
> > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > the vanishingly unlikely scenario where all bits of the hash are zero,
> > it's possible to distinguish between a client's
> > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> >
> > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > a lever to force applications to supply TLS channel bindings.  It
> > enables a weird policy: at server enforcement level 1, client
> > applications that don't provide bindings will interoperate if and only
> > if they are running on a sufficiently old versions of Windows.  That's
> > not a coherent policy in the context of open standards, but it probably
> > makes sense for a pure Windows ecosystem.
>
> For SMB windows sends channel bindings of 16 zeros together with
> the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> provided instead.
>
> I guess the bit means that client and server should agree that both
> sides use 16 zeros. In that case the AP exchange is protected by
> GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> knowing the session key.

Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
not over TLS behaves similar to SMB described above. Also, I noticed
that Windows HTTP client requests INTEG, both when over TLS and when
not, although it isn't used afai understand.


Authenticator from win HTTP client over TLS:

authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
        cksumtype: cKSUMTYPE-GSSAPI (32771)
        checksum: 100000009e41a51ed7c90b3597bc7217c4d3c41e22000000
        Length: 16
        Bnd: 9e41a51ed7c90b3597bc7217c4d3c41e
        .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
        .... .... .... .... .... .... ..1. .... = Integ: Integrity
protection (signing) may be invoked
        .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
Confidentiality (sealing)
        .... .... .... .... .... .... .... 0... = Sequence: Do NOT
enable out-of-sequence detection
        .... .... .... .... .... .... .... .0.. = Replay: Do NOT
enable replay protection
        .... .... .... .... .... .... .... ..1. = Mutual: Request that
remote peer authenticates itself
        .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
    cusec: 1416
    ctime: 2020-03-02 12:45:49 (UTC)
    subkey
        keytype: 23
        keyvalue: 3a403dfc58e6561718c297a024d6f146
    seq-number: 59339976
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data:
3081c63015a00402020081a10d040b3009020112020111020117303fa0040202008da137…
                AuthorizationData item
                    ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
                    ad-data: 3009020112020111020117
                        ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                        ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                        ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                AuthorizationData item
                    ad-type: AD-TOKEN-RESTRICTIONS (141)
                    ad-data:
30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
                        restriction-type: 0
                        restriction:
0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
                AuthorizationData item
                    ad-type: AD-LOCAL (142)
                    ad-data: 50e51e0afe010000469b7e1300000000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
                AuthorizationData item
                    ad-type: AD-TARGET-PRINCIPAL (144)
                    ad-data:
48005400540050002f006100700061006300680065002e0073006d0062002e006e006500…
                        Target Principal: HTTP/[hidden email]


Authneticator from Win HTTP client not over TLS:

authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
        cksumtype: cKSUMTYPE-GSSAPI (32771)
        checksum: 100000000000000000000000000000000000000022000000
        Length: 16
        Bnd: 00000000000000000000000000000000
        .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
        .... .... .... .... .... .... ..1. .... = Integ: Integrity
protection (signing) may be invoked
        .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
Confidentiality (sealing)
        .... .... .... .... .... .... .... 0... = Sequence: Do NOT
enable out-of-sequence detection
        .... .... .... .... .... .... .... .0.. = Replay: Do NOT
enable replay protection
        .... .... .... .... .... .... .... ..1. = Mutual: Request that
remote peer authenticates itself
        .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
    cusec: 1401
    ctime: 2020-03-02 12:11:55 (UTC)
    subkey
        keytype: 23
        keyvalue: 341b481cde0552be9aeb3ab1a384f340
    seq-number: 1077780979
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data:
3081c63015a00402020081a10d040b3009020112020111020117303fa0040202008da137…
                AuthorizationData item
                    ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
                    ad-data: 3009020112020111020117
                        ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                        ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                        ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                AuthorizationData item
                    ad-type: AD-TOKEN-RESTRICTIONS (141)
                    ad-data:
30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
                        restriction-type: 0
                        restriction:
0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
                AuthorizationData item
                    ad-type: AD-LOCAL (142)
                    ad-data: 10395209fe01000092925f1300000000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
                AuthorizationData item
                    ad-type: AD-TARGET-PRINCIPAL (144)
                    ad-data:
48005400540050002f006100700061006300680065002e0073006d0062002e006e006500…
                        Target Principal: HTTP/[hidden email]


Authenticator from Win LDAP client not over TLS:
authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
        cksumtype: cKSUMTYPE-GSSAPI (32771)
        checksum: 10000000000000000000000000000000000000002a400000
        Length: 16
        Bnd: 00000000000000000000000000000000
        .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
        .... .... .... .... .... .... ..1. .... = Integ: Integrity
protection (signing) may be invoked
        .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
Confidentiality (sealing)
        .... .... .... .... .... .... .... 1... = Sequence: Enable
Out-of-sequence detection for sign or sealed messages
        .... .... .... .... .... .... .... .0.. = Replay: Do NOT
enable replay protection
        .... .... .... .... .... .... .... ..1. = Mutual: Request that
remote peer authenticates itself
        .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
    cusec: 1386
    ctime: 2020-03-02 10:57:38 (UTC)
    subkey
        keytype: 18
        keyvalue:
df460e11e7a15ee9014d1775b290986bbf017bb6134f3df1151754bfa9f5332f
    seq-number: 1618541302
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data:
3081a9303fa0040202008da137043530333031a003020100a12a04280000000000300000…
                AuthorizationData item
                    ad-type: AD-TOKEN-RESTRICTIONS (141)
                    ad-data:
30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
                        restriction-type: 0
                        restriction:
0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
                AuthorizationData item
                    ad-type: AD-LOCAL (142)
                    ad-data: f0e01e0afe010000bc921b1300000000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
                AuthorizationData item
                    ad-type: AD-TARGET-PRINCIPAL (144)
                    ad-data:
6c006400610070002f007300640063002e0073006d0062002e006e006500740040005300…
                        Target Principal: ldap/[hidden email]


Authenticator from Win LDAP client over TLS:

authenticator
    authenticator-vno: 5
    crealm: SMB.NET
    cname
    cksum
        cksumtype: cKSUMTYPE-GSSAPI (32771)
        checksum: 100000009e41a51ed7c90b3597bc7217c4d3c41e02400000
        Length: 16
        Bnd: 9e41a51ed7c90b3597bc7217c4d3c41e
        .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
        .... .... .... .... .... .... ..0. .... = Integ: Do NOT use
integrity protection
        .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
Confidentiality (sealing)
        .... .... .... .... .... .... .... 0... = Sequence: Do NOT
enable out-of-sequence detection
        .... .... .... .... .... .... .... .0.. = Replay: Do NOT
enable replay protection
        .... .... .... .... .... .... .... ..1. = Mutual: Request that
remote peer authenticates itself
        .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
    cusec: 1388
    ctime: 2020-03-02 11:12:49 (UTC)
    subkey
        keytype: 18
        keyvalue:
62ca02f9357f8f13e8b3d538292942282d4d1e376e0dba0cc1eb1795ebb66c52
    seq-number: 23297322
    authorization-data: 1 item
        AuthorizationData item
            ad-type: AD-IF-RELEVANT (1)
            ad-data:
3081a9303fa0040202008da137043530333031a003020100a12a04280000000000300000…
                AuthorizationData item
                    ad-type: AD-TOKEN-RESTRICTIONS (141)
                    ad-data:
30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
                        restriction-type: 0
                        restriction:
0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
                AuthorizationData item
                    ad-type: AD-LOCAL (142)
                    ad-data: d0e21e0afe010000a878291300000000
                AuthorizationData item
                    ad-type: AD-AP-OPTIONS (143)
                    ad-data: 00400000
                        AD-AP-Options: 0x00004000, ChannelBindings
                            .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
                AuthorizationData item
                    ad-type: AD-TARGET-PRINCIPAL (144)
                    ad-data:
6c006400610070002f007300640063002e0073006d0062002e006e006500740040005300…
                        Target Principal: ldap/[hidden email]

> >>> * gss_accept_sec_context() has output flags but not input flags.  So
> >>> it's easy to add a channel-bound flag indicating that channel bindings
> >>> were used; it's significantly harder to add an input flag to indicate
> >>> whether channel bindings should be enforced.
> >>
> >> I think using excplicit acceptor_creds and flag the requested behavior
> >> there, it's similar to the ignore transited problem.
> >>
> >> It would be good to make some generic progress here, as we'll likely
> >> need more of these application driven options.
> >
> > draft-ietf-kitten-channel-bound-flag does define
> > gss_create_sec_context(), and there's an implementation for MIT kicking
> > around if we have a need for it.  (The draft as a whole doesn't reflect
> > working group consensus as I understand it, but that specific part of it
> > could be implemented.)
> >
> > "Ignore transited policy" would probably be best handled through
> > gss_set_sec_context_option(), rather than a GSS request flag.
>
> Using gss_create_sec_context() and
> gss_set_sec_context_option(GSS_KRB5_NO_TRANSIT_CHECK_X) instead of
> gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) would work for
> me from Samba.
>
> But I don't yet understand what it takes to implement that in the
> Kerberos libraries as the resulting sec_context is not attached
> to the krb5 mech.
>
> > GSS flags are somewhat precious, and the application preference is very
> > specifically about tolerating a particular krb5 KDC implementation's
> > non-conformance to a specific part of RFC 4120.
> >
> > Still, for the reasons I laid out, I think channel binding policing is
> > best left to the application via an output flag.
>
> I guess it would also be good to export the raw 16 byte value
> and also indicate that the client asked for the channel bindings to
> match exactly (with KERB_AP_OPTIONS_CBT or by providing MsvChannelBindings).
>
> Maybe using gss_inquire_sec_context_by_oid() would be a good idea
> for these cases instead of using ret_flags from gss_accept_sec_context().
>
> metze
>

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:

> On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[hidden email]> wrote:
> > Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> > > > As far as I can tell the server enforces them when the client provides
> > > > them. That means there's a way in the protocol to distinguish between
> > > > GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
> > > >
> > > > E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
> > > >
> > > > While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> > >
> > > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > > the vanishingly unlikely scenario where all bits of the hash are zero,
> > > it's possible to distinguish between a client's
> > > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> > >
> > > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > > a lever to force applications to supply TLS channel bindings.  It
> > > enables a weird policy: at server enforcement level 1, client
> > > applications that don't provide bindings will interoperate if and only
> > > if they are running on a sufficiently old versions of Windows.  That's
> > > not a coherent policy in the context of open standards, but it probably
> > > makes sense for a pure Windows ecosystem.
> >
> > For SMB windows sends channel bindings of 16 zeros together with
> > the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> > the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> > provided instead.
> >
> > I guess the bit means that client and server should agree that both
> > sides use 16 zeros. In that case the AP exchange is protected by
> > GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> > knowing the session key.
>
> Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
> not over TLS behaves similar to SMB described above. Also, I noticed
> that Windows HTTP client requests INTEG, both when over TLS and when
> not, although it isn't used afai understand.

Stephan, Isaac, in SMB CBs should be completely ignored in any case
because there is no outer channel to bind to.
That is why CBs are set to all 0 even when KERB_AP_OPTIONS_CBT is set.

This AP REQ flag just states: "The client is capable of doing CBs
correctly", but it is only relevant when there is an actual channel to
bind to. In SMB there is no support for running in an outer TLS (or
otherwise) channel, so sending all 0 (or not sending CBs at all) is
simply the correct thing to do and nothing special to SMB.

When it comes to Channel Bindings this is the decision tree:

1) Is the GSSAPI exchange going over an outer protection channel ?
   NO -> (2)
   YES -> (3)

2) Do not set CB (client) and do not require CB (server), STOP
   [Completely ignore KERB_AP_OPTIONS_CBT]

----- From here on we are operating in a protected channel -----
3) Is CB mandatory ? (In win this means LdapEnforceChannelBindings=2,
or as MS-KILE calls it ApplicationRequiresCBT)
   NO -> (4)
   YES -> (5)

4) The client can send CBs or not
The server must be prepared to handle CBs, but can ignore them
Special case:
Did the client sends KERB_AP_OPTIONS_CBT set to 4000?
   NO -> (4.1)
   YES -> (4.2)

4.1) Ignore CBs if they are all 0s or NULL
Check CBs otherwise. FAIL if CBs do not match

4.2) FAIL is CBs are all 0s and FAIL if CBs do not match
[Ignore CBs only if they are NULL(?) <- Isaac can you test this
scenario?]

----- From here on Channel Bindings are REQUIRED -----
5) Client must set valid CBs, Server must require valid CBs
   If CBs do not match (they must be different from all 0s) FAIL
   [Completely ignore KERB_AP_OPTIONS_CBT]

> Authenticator from win HTTP client over TLS:

Isaac, note that the SPNEGO spec is exclusively about authentication,
contexts are not retained, and cannot be used for GSSAPI services once
authentication completes. So there really is no much point in
confidentiality or integrity flags.
Channel Bindings SHOULD definitely be sent always on HTTPS, but
conf/integ flags are completely orthogonal to CBs so it is unclear to
me why you would care.

> authenticator
>     authenticator-vno: 5
>     crealm: SMB.NET
>     cname
>     cksum
>         cksumtype: cKSUMTYPE-GSSAPI (32771)
>         checksum: 100000009e41a51ed7c90b3597bc7217c4d3c41e22000000
>         Length: 16
>         Bnd: 9e41a51ed7c90b3597bc7217c4d3c41e
>         .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
>         .... .... .... .... .... .... ..1. .... = Integ: Integrity
> protection (signing) may be invoked
>         .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
> Confidentiality (sealing)
>         .... .... .... .... .... .... .... 0... = Sequence: Do NOT
> enable out-of-sequence detection
>         .... .... .... .... .... .... .... .0.. = Replay: Do NOT
> enable replay protection
>         .... .... .... .... .... .... .... ..1. = Mutual: Request that
> remote peer authenticates itself
>         .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
>     cusec: 1416
>     ctime: 2020-03-02 12:45:49 (UTC)
>     subkey
>         keytype: 23
>         keyvalue: 3a403dfc58e6561718c297a024d6f146
>     seq-number: 59339976
>     authorization-data: 1 item
>         AuthorizationData item
>             ad-type: AD-IF-RELEVANT (1)
>             ad-data:
> 3081c63015a00402020081a10d040b3009020112020111020117303fa0040202008da137…
>                 AuthorizationData item
>                     ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
>                     ad-data: 3009020112020111020117
>                         ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
>                         ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
>                         ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
>                 AuthorizationData item
>                     ad-type: AD-TOKEN-RESTRICTIONS (141)
>                     ad-data:
> 30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
>                         restriction-type: 0
>                         restriction:
> 0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
>                 AuthorizationData item
>                     ad-type: AD-LOCAL (142)
>                     ad-data: 50e51e0afe010000469b7e1300000000
>                 AuthorizationData item
>                     ad-type: AD-AP-OPTIONS (143)
>                     ad-data: 00400000
>                         AD-AP-Options: 0x00004000, ChannelBindings
>                             .... .... .... .... .1.. .... .... .... =
> ChannelBindings: Set
>                 AuthorizationData item
>                     ad-type: AD-TARGET-PRINCIPAL (144)
>                     ad-data:
> 48005400540050002f006100700061006300680065002e0073006d0062002e006e006500…
>                         Target Principal: HTTP/[hidden email]
>
>
> Authneticator from Win HTTP client not over TLS:
>
> authenticator
>     authenticator-vno: 5
>     crealm: SMB.NET
>     cname
>     cksum
>         cksumtype: cKSUMTYPE-GSSAPI (32771)
>         checksum: 100000000000000000000000000000000000000022000000
>         Length: 16
>         Bnd: 00000000000000000000000000000000
>         .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
>         .... .... .... .... .... .... ..1. .... = Integ: Integrity
> protection (signing) may be invoked
>         .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
> Confidentiality (sealing)
>         .... .... .... .... .... .... .... 0... = Sequence: Do NOT
> enable out-of-sequence detection
>         .... .... .... .... .... .... .... .0.. = Replay: Do NOT
> enable replay protection
>         .... .... .... .... .... .... .... ..1. = Mutual: Request that
> remote peer authenticates itself
>         .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
>     cusec: 1401
>     ctime: 2020-03-02 12:11:55 (UTC)
>     subkey
>         keytype: 23
>         keyvalue: 341b481cde0552be9aeb3ab1a384f340
>     seq-number: 1077780979
>     authorization-data: 1 item
>         AuthorizationData item
>             ad-type: AD-IF-RELEVANT (1)
>             ad-data:
> 3081c63015a00402020081a10d040b3009020112020111020117303fa0040202008da137…
>                 AuthorizationData item
>                     ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
>                     ad-data: 3009020112020111020117
>                         ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
>                         ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
>                         ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
>                 AuthorizationData item
>                     ad-type: AD-TOKEN-RESTRICTIONS (141)
>                     ad-data:
> 30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
>                         restriction-type: 0
>                         restriction:
> 0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
>                 AuthorizationData item
>                     ad-type: AD-LOCAL (142)
>                     ad-data: 10395209fe01000092925f1300000000
>                 AuthorizationData item
>                     ad-type: AD-AP-OPTIONS (143)
>                     ad-data: 00400000
>                         AD-AP-Options: 0x00004000, ChannelBindings
>                             .... .... .... .... .1.. .... .... .... =
> ChannelBindings: Set
>                 AuthorizationData item
>                     ad-type: AD-TARGET-PRINCIPAL (144)
>                     ad-data:
> 48005400540050002f006100700061006300680065002e0073006d0062002e006e006500…
>                         Target Principal: HTTP/[hidden email]
>
>
> Authenticator from Win LDAP client not over TLS:
> authenticator
>     authenticator-vno: 5
>     crealm: SMB.NET
>     cname
>     cksum
>         cksumtype: cKSUMTYPE-GSSAPI (32771)
>         checksum: 10000000000000000000000000000000000000002a400000
>         Length: 16
>         Bnd: 00000000000000000000000000000000
>         .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
>         .... .... .... .... .... .... ..1. .... = Integ: Integrity
> protection (signing) may be invoked
>         .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
> Confidentiality (sealing)
>         .... .... .... .... .... .... .... 1... = Sequence: Enable
> Out-of-sequence detection for sign or sealed messages
>         .... .... .... .... .... .... .... .0.. = Replay: Do NOT
> enable replay protection
>         .... .... .... .... .... .... .... ..1. = Mutual: Request that
> remote peer authenticates itself
>         .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
>     cusec: 1386
>     ctime: 2020-03-02 10:57:38 (UTC)
>     subkey
>         keytype: 18
>         keyvalue:
> df460e11e7a15ee9014d1775b290986bbf017bb6134f3df1151754bfa9f5332f
>     seq-number: 1618541302
>     authorization-data: 1 item
>         AuthorizationData item
>             ad-type: AD-IF-RELEVANT (1)
>             ad-data:
> 3081a9303fa0040202008da137043530333031a003020100a12a04280000000000300000…
>                 AuthorizationData item
>                     ad-type: AD-TOKEN-RESTRICTIONS (141)
>                     ad-data:
> 30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
>                         restriction-type: 0
>                         restriction:
> 0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
>                 AuthorizationData item
>                     ad-type: AD-LOCAL (142)
>                     ad-data: f0e01e0afe010000bc921b1300000000
>                 AuthorizationData item
>                     ad-type: AD-AP-OPTIONS (143)
>                     ad-data: 00400000
>                         AD-AP-Options: 0x00004000, ChannelBindings
>                             .... .... .... .... .1.. .... .... .... =
> ChannelBindings: Set
>                 AuthorizationData item
>                     ad-type: AD-TARGET-PRINCIPAL (144)
>                     ad-data:
> 6c006400610070002f007300640063002e0073006d0062002e006e006500740040005300…
>                         Target Principal: ldap/[hidden email]
>
>
> Authenticator from Win LDAP client over TLS:
>
> authenticator
>     authenticator-vno: 5
>     crealm: SMB.NET
>     cname
>     cksum
>         cksumtype: cKSUMTYPE-GSSAPI (32771)
>         checksum: 100000009e41a51ed7c90b3597bc7217c4d3c41e02400000
>         Length: 16
>         Bnd: 9e41a51ed7c90b3597bc7217c4d3c41e
>         .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
>         .... .... .... .... .... .... ..0. .... = Integ: Do NOT use
> integrity protection
>         .... .... .... .... .... .... ...0 .... = Conf: Do NOT use
> Confidentiality (sealing)
>         .... .... .... .... .... .... .... 0... = Sequence: Do NOT
> enable out-of-sequence detection
>         .... .... .... .... .... .... .... .0.. = Replay: Do NOT
> enable replay protection
>         .... .... .... .... .... .... .... ..1. = Mutual: Request that
> remote peer authenticates itself
>         .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
>     cusec: 1388
>     ctime: 2020-03-02 11:12:49 (UTC)
>     subkey
>         keytype: 18
>         keyvalue:
> 62ca02f9357f8f13e8b3d538292942282d4d1e376e0dba0cc1eb1795ebb66c52
>     seq-number: 23297322
>     authorization-data: 1 item
>         AuthorizationData item
>             ad-type: AD-IF-RELEVANT (1)
>             ad-data:
> 3081a9303fa0040202008da137043530333031a003020100a12a04280000000000300000…
>                 AuthorizationData item
>                     ad-type: AD-TOKEN-RESTRICTIONS (141)
>                     ad-data:
> 30333031a003020100a12a04280000000000300000611ed30f4a652ff51cc54444a2f18d…
>                         restriction-type: 0
>                         restriction:
> 0000000000300000611ed30f4a652ff51cc54444a2f18d3f310b1d394513a458410cbde2…
>                 AuthorizationData item
>                     ad-type: AD-LOCAL (142)
>                     ad-data: d0e21e0afe010000a878291300000000
>                 AuthorizationData item
>                     ad-type: AD-AP-OPTIONS (143)
>                     ad-data: 00400000
>                         AD-AP-Options: 0x00004000, ChannelBindings
>                             .... .... .... .... .1.. .... .... .... =
> ChannelBindings: Set
>                 AuthorizationData item
>                     ad-type: AD-TARGET-PRINCIPAL (144)
>                     ad-data:
> 6c006400610070002f007300640063002e0073006d0062002e006e006500740040005300…
>                         Target Principal: ldap/[hidden email]
> > > > > * gss_accept_sec_context() has output flags but not input flags.  So
> > > > > it's easy to add a channel-bound flag indicating that channel bindings
> > > > > were used; it's significantly harder to add an input flag to indicate
> > > > > whether channel bindings should be enforced.
> > > >
> > > > I think using excplicit acceptor_creds and flag the requested behavior
> > > > there, it's similar to the ignore transited problem.
> > > >
> > > > It would be good to make some generic progress here, as we'll likely
> > > > need more of these application driven options.
> > >
> > > draft-ietf-kitten-channel-bound-flag does define
> > > gss_create_sec_context(), and there's an implementation for MIT kicking
> > > around if we have a need for it.  (The draft as a whole doesn't reflect
> > > working group consensus as I understand it, but that specific part of it
> > > could be implemented.)
> > >
> > > "Ignore transited policy" would probably be best handled through
> > > gss_set_sec_context_option(), rather than a GSS request flag.
> >
> > Using gss_create_sec_context() and
> > gss_set_sec_context_option(GSS_KRB5_NO_TRANSIT_CHECK_X) instead of
> > gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) would work for
> > me from Samba.
> >
> > But I don't yet understand what it takes to implement that in the
> > Kerberos libraries as the resulting sec_context is not attached
> > to the krb5 mech.
> >
> > > GSS flags are somewhat precious, and the application preference is very
> > > specifically about tolerating a particular krb5 KDC implementation's
> > > non-conformance to a specific part of RFC 4120.
> > >
> > > Still, for the reasons I laid out, I think channel binding policing is
> > > best left to the application via an output flag.
> >
> > I guess it would also be good to export the raw 16 byte value
> > and also indicate that the client asked for the channel bindings to
> > match exactly (with KERB_AP_OPTIONS_CBT or by providing MsvChannelBindings).
> >
> > Maybe using gss_inquire_sec_context_by_oid() would be a good idea
> > for these cases instead of using ret_flags from gss_accept_sec_context().
> >
> > metze
> >

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
In reply to this post by Greg Hudson
On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
>
> On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > Following the discussion on  IRC, there is currently a difference in
> > between Heimdal and MIT, when the client does not send bindings, and
> > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > it succeeds.
>
> There are a few reasons why I think Heimdal's behavior is better:

Taking a closer look at MIT accept() code, it looks like there is a
case where no checksum is provided at all, where MIT would skip
channel-bindings even if the server provided ones. It sounds like
Windows also supports this.

https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
In reply to this post by Simo Sorce-3
On Mon, Mar 2, 2020 at 3:02 PM Simo Sorce <[hidden email]> wrote:

>
> On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> > On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[hidden email]> wrote:
> > > Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > > > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> > > > > As far as I can tell the server enforces them when the client provides
> > > > > them. That means there's a way in the protocol to distinguish between
> > > > > GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
> > > > >
> > > > > E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
> > > > >
> > > > > While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> > > >
> > > > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > > > the vanishingly unlikely scenario where all bits of the hash are zero,
> > > > it's possible to distinguish between a client's
> > > > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> > > >
> > > > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > > > a lever to force applications to supply TLS channel bindings.  It
> > > > enables a weird policy: at server enforcement level 1, client
> > > > applications that don't provide bindings will interoperate if and only
> > > > if they are running on a sufficiently old versions of Windows.  That's
> > > > not a coherent policy in the context of open standards, but it probably
> > > > makes sense for a pure Windows ecosystem.
> > >
> > > For SMB windows sends channel bindings of 16 zeros together with
> > > the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> > > the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> > > provided instead.
> > >
> > > I guess the bit means that client and server should agree that both
> > > sides use 16 zeros. In that case the AP exchange is protected by
> > > GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> > > knowing the session key.
> >
> > Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
> > not over TLS behaves similar to SMB described above. Also, I noticed
> > that Windows HTTP client requests INTEG, both when over TLS and when
> > not, although it isn't used afai understand.
>
> Stephan, Isaac, in SMB CBs should be completely ignored in any case
> because there is no outer channel to bind to.
> That is why CBs are set to all 0 even when KERB_AP_OPTIONS_CBT is set.

Right, that is why I compared it with LDAP when not over TLS.

> This AP REQ flag just states: "The client is capable of doing CBs
> correctly", but it is only relevant when there is an actual channel to
> bind to. In SMB there is no support for running in an outer TLS (or
> otherwise) channel, so sending all 0 (or not sending CBs at all) is
> simply the correct thing to do and nothing special to SMB.

I think the point was made, that Windows client sends
KERB_AP_OPTIONS_CBT even when not over TLS.

> When it comes to Channel Bindings this is the decision tree:
>
> 1) Is the GSSAPI exchange going over an outer protection channel ?
>    NO -> (2)
>    YES -> (3)
>
> 2) Do not set CB (client) and do not require CB (server), STOP
>    [Completely ignore KERB_AP_OPTIONS_CBT]

As above, in this case Windows client sends KERB_AP_OPTIONS_CBT.

> ----- From here on we are operating in a protected channel -----
> 3) Is CB mandatory ? (In win this means LdapEnforceChannelBindings=2,
> or as MS-KILE calls it ApplicationRequiresCBT)
>    NO -> (4)
>    YES -> (5)
>
> 4) The client can send CBs or not
> The server must be prepared to handle CBs, but can ignore them
> Special case:
> Did the client sends KERB_AP_OPTIONS_CBT set to 4000?
>    NO -> (4.1)
>    YES -> (4.2)
>
> 4.1) Ignore CBs if they are all 0s or NULL
> Check CBs otherwise. FAIL if CBs do not match

Note, CBs are only checked if LdapEnforceChannelBindings>=1, here if
LdapEnforceChannelBindings=0 it works even with wrong CBs.

> 4.2) FAIL is CBs are all 0s and FAIL if CBs do not match
> [Ignore CBs only if they are NULL(?) <- Isaac can you test this
> scenario?]

Not sure how to test this, but note that here too if
LdapEnforceChannelBindings=0 Windows would accept even wrong bindings,
so it's like passing GSS_C_NO_CHANNEL_BINDINGS in GSS.

> ----- From here on Channel Bindings are REQUIRED -----
> 5) Client must set valid CBs, Server must require valid CBs
>    If CBs do not match (they must be different from all 0s) FAIL
>    [Completely ignore KERB_AP_OPTIONS_CBT]
>
> > Authenticator from win HTTP client over TLS:
>
> Isaac, note that the SPNEGO spec is exclusively about authentication,
> contexts are not retained, and cannot be used for GSSAPI services once
> authentication completes. So there really is no much point in
> confidentiality or integrity flags.

Right, that is why the INTEG request was weird.

> Channel Bindings SHOULD definitely be sent always on HTTPS, but
> conf/integ flags are completely orthogonal to CBs so it is unclear to
> me why you would care.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
On Mon, 2020-03-02 at 15:54 +0100, Isaac Boukris wrote:

> On Mon, Mar 2, 2020 at 3:02 PM Simo Sorce <[hidden email]> wrote:
> > On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> > > On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[hidden email]> wrote:
> > > > Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > > > > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> > > > > > As far as I can tell the server enforces them when the client provides
> > > > > > them. That means there's a way in the protocol to distinguish between
> > > > > > GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
> > > > > >
> > > > > > E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
> > > > > >
> > > > > > While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> > > > >
> > > > > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > > > > the vanishingly unlikely scenario where all bits of the hash are zero,
> > > > > it's possible to distinguish between a client's
> > > > > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> > > > >
> > > > > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > > > > a lever to force applications to supply TLS channel bindings.  It
> > > > > enables a weird policy: at server enforcement level 1, client
> > > > > applications that don't provide bindings will interoperate if and only
> > > > > if they are running on a sufficiently old versions of Windows.  That's
> > > > > not a coherent policy in the context of open standards, but it probably
> > > > > makes sense for a pure Windows ecosystem.
> > > >
> > > > For SMB windows sends channel bindings of 16 zeros together with
> > > > the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> > > > the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> > > > provided instead.
> > > >
> > > > I guess the bit means that client and server should agree that both
> > > > sides use 16 zeros. In that case the AP exchange is protected by
> > > > GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> > > > knowing the session key.
> > >
> > > Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
> > > not over TLS behaves similar to SMB described above. Also, I noticed
> > > that Windows HTTP client requests INTEG, both when over TLS and when
> > > not, although it isn't used afai understand.
> >
> > Stephan, Isaac, in SMB CBs should be completely ignored in any case
> > because there is no outer channel to bind to.
> > That is why CBs are set to all 0 even when KERB_AP_OPTIONS_CBT is set.
>
> Right, that is why I compared it with LDAP when not over TLS.
>
> > This AP REQ flag just states: "The client is capable of doing CBs
> > correctly", but it is only relevant when there is an actual channel to
> > bind to. In SMB there is no support for running in an outer TLS (or
> > otherwise) channel, so sending all 0 (or not sending CBs at all) is
> > simply the correct thing to do and nothing special to SMB.
>
> I think the point was made, that Windows client sends
> KERB_AP_OPTIONS_CBT even when not over TLS.
>
> > When it comes to Channel Bindings this is the decision tree:
> >
> > 1) Is the GSSAPI exchange going over an outer protection channel ?
> >    NO -> (2)
> >    YES -> (3)
> >
> > 2) Do not set CB (client) and do not require CB (server), STOP
> >    [Completely ignore KERB_AP_OPTIONS_CBT]
>
> As above, in this case Windows client sends KERB_AP_OPTIONS_CBT.

It doesn't matter, the server should simply not set CBs and ignore the
whole thing.

>
> > ----- From here on we are operating in a protected channel -----
> > 3) Is CB mandatory ? (In win this means LdapEnforceChannelBindings=2,
> > or as MS-KILE calls it ApplicationRequiresCBT)
> >    NO -> (4)
> >    YES -> (5)
> >
> > 4) The client can send CBs or not
> > The server must be prepared to handle CBs, but can ignore them
> > Special case:
> > Did the client sends KERB_AP_OPTIONS_CBT set to 4000?
> >    NO -> (4.1)
> >    YES -> (4.2)
> >
> > 4.1) Ignore CBs if they are all 0s or NULL
> > Check CBs otherwise. FAIL if CBs do not match
>
> Note, CBs are only checked if LdapEnforceChannelBindings>=1, here if
> LdapEnforceChannelBindings=0 it works even with wrong CBs.

This is something we should not care for anymore at this point, that
can simply be handled by passing no CBs in the server (equivalent to
level =0).

> > 4.2) FAIL is CBs are all 0s and FAIL if CBs do not match
> > [Ignore CBs only if they are NULL(?) <- Isaac can you test this
> > scenario?]
>
> Not sure how to test this, but note that here too if
> LdapEnforceChannelBindings=0 Windows would accept even wrong bindings,
> so it's like passing GSS_C_NO_CHANNEL_BINDINGS in GSS.

This is how to test:
Use a krb5 GSSAPI based LDAP client, configure server with lvl=1, do
set KERB_AP_OPTIONS_CBT, omit CBs completely ?

It is not hugely important, but it would be nice to know what to
expect.

> > ----- From here on Channel Bindings are REQUIRED -----
> > 5) Client must set valid CBs, Server must require valid CBs
> >    If CBs do not match (they must be different from all 0s) FAIL
> >    [Completely ignore KERB_AP_OPTIONS_CBT]
> >
> > > Authenticator from win HTTP client over TLS:
> >
> > Isaac, note that the SPNEGO spec is exclusively about authentication,
> > contexts are not retained, and cannot be used for GSSAPI services once
> > authentication completes. So there really is no much point in
> > confidentiality or integrity flags.
>
> Right, that is why the INTEG request was weird.

I think Integrity here is needed to be able to sign the MicMechList and
stuff like that. As that is used to prevent tampering with the SPNEGO
outer layer. And I assume layering within SSPI meant we need the flag
at the mechanism level (you need it in NTLMSSP or there is no
negotiation of a session key useful for signing), so it is retained in
krb5 mechanisms as well.

And in fact if you look at RFC 4178 you'll find this in the
Introduction:
"""
   If per-message integrity services [RFC2743] are available on the
   established mechanism security context, then the negotiation is
   protected to ensure that the mechanism list has not been modified.
"""

> > Channel Bindings SHOULD definitely be sent always on HTTPS, but
> > conf/integ flags are completely orthogonal to CBs so it is unclear to
> > me why you would care.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
On Mon, Mar 2, 2020 at 5:04 PM Simo Sorce <[hidden email]> wrote:

>
> On Mon, 2020-03-02 at 15:54 +0100, Isaac Boukris wrote:
> > On Mon, Mar 2, 2020 at 3:02 PM Simo Sorce <[hidden email]> wrote:
> > > On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> > > > On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[hidden email]> wrote:
> > > > > Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > > > > > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> > > > > > > As far as I can tell the server enforces them when the client provides
> > > > > > > them. That means there's a way in the protocol to distinguish between
> > > > > > > GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
> > > > > > >
> > > > > > > E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
> > > > > > >
> > > > > > > While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> > > > > >
> > > > > > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > > > > > the vanishingly unlikely scenario where all bits of the hash are zero,
> > > > > > it's possible to distinguish between a client's
> > > > > > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> > > > > >
> > > > > > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > > > > > a lever to force applications to supply TLS channel bindings.  It
> > > > > > enables a weird policy: at server enforcement level 1, client
> > > > > > applications that don't provide bindings will interoperate if and only
> > > > > > if they are running on a sufficiently old versions of Windows.  That's
> > > > > > not a coherent policy in the context of open standards, but it probably
> > > > > > makes sense for a pure Windows ecosystem.
> > > > >
> > > > > For SMB windows sends channel bindings of 16 zeros together with
> > > > > the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> > > > > the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> > > > > provided instead.
> > > > >
> > > > > I guess the bit means that client and server should agree that both
> > > > > sides use 16 zeros. In that case the AP exchange is protected by
> > > > > GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> > > > > knowing the session key.
> > > >
> > > > Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
> > > > not over TLS behaves similar to SMB described above. Also, I noticed
> > > > that Windows HTTP client requests INTEG, both when over TLS and when
> > > > not, although it isn't used afai understand.
> > >
> > > Stephan, Isaac, in SMB CBs should be completely ignored in any case
> > > because there is no outer channel to bind to.
> > > That is why CBs are set to all 0 even when KERB_AP_OPTIONS_CBT is set.
> >
> > Right, that is why I compared it with LDAP when not over TLS.
> >
> > > This AP REQ flag just states: "The client is capable of doing CBs
> > > correctly", but it is only relevant when there is an actual channel to
> > > bind to. In SMB there is no support for running in an outer TLS (or
> > > otherwise) channel, so sending all 0 (or not sending CBs at all) is
> > > simply the correct thing to do and nothing special to SMB.
> >
> > I think the point was made, that Windows client sends
> > KERB_AP_OPTIONS_CBT even when not over TLS.
> >
> > > When it comes to Channel Bindings this is the decision tree:
> > >
> > > 1) Is the GSSAPI exchange going over an outer protection channel ?
> > >    NO -> (2)
> > >    YES -> (3)
> > >
> > > 2) Do not set CB (client) and do not require CB (server), STOP
> > >    [Completely ignore KERB_AP_OPTIONS_CBT]
> >
> > As above, in this case Windows client sends KERB_AP_OPTIONS_CBT.
>
> It doesn't matter, the server should simply not set CBs and ignore the
> whole thing.

I think the client should send KERB_AP_OPTIONS_CBT when so configured
(tbd), even when not over TLS.

> > > ----- From here on we are operating in a protected channel -----
> > > 3) Is CB mandatory ? (In win this means LdapEnforceChannelBindings=2,
> > > or as MS-KILE calls it ApplicationRequiresCBT)
> > >    NO -> (4)
> > >    YES -> (5)
> > >
> > > 4) The client can send CBs or not
> > > The server must be prepared to handle CBs, but can ignore them
> > > Special case:
> > > Did the client sends KERB_AP_OPTIONS_CBT set to 4000?
> > >    NO -> (4.1)
> > >    YES -> (4.2)
> > >
> > > 4.1) Ignore CBs if they are all 0s or NULL
> > > Check CBs otherwise. FAIL if CBs do not match
> >
> > Note, CBs are only checked if LdapEnforceChannelBindings>=1, here if
> > LdapEnforceChannelBindings=0 it works even with wrong CBs.
>
> This is something we should not care for anymore at this point, that
> can simply be handled by passing no CBs in the server (equivalent to
> level =0).
>
> > > 4.2) FAIL is CBs are all 0s and FAIL if CBs do not match
> > > [Ignore CBs only if they are NULL(?) <- Isaac can you test this
> > > scenario?]
> >
> > Not sure how to test this, but note that here too if
> > LdapEnforceChannelBindings=0 Windows would accept even wrong bindings,
> > so it's like passing GSS_C_NO_CHANNEL_BINDINGS in GSS.
>
> This is how to test:
> Use a krb5 GSSAPI based LDAP client, configure server with lvl=1, do
> set KERB_AP_OPTIONS_CBT, omit CBs completely ?

Not sure what 'omit' would mean here, sorry.

> It is not hugely important, but it would be nice to know what to
> expect.
>
> > > ----- From here on Channel Bindings are REQUIRED -----
> > > 5) Client must set valid CBs, Server must require valid CBs
> > >    If CBs do not match (they must be different from all 0s) FAIL
> > >    [Completely ignore KERB_AP_OPTIONS_CBT]
> > >
> > > > Authenticator from win HTTP client over TLS:
> > >
> > > Isaac, note that the SPNEGO spec is exclusively about authentication,
> > > contexts are not retained, and cannot be used for GSSAPI services once
> > > authentication completes. So there really is no much point in
> > > confidentiality or integrity flags.
> >
> > Right, that is why the INTEG request was weird.
>
> I think Integrity here is needed to be able to sign the MicMechList and
> stuff like that. As that is used to prevent tampering with the SPNEGO
> outer layer. And I assume layering within SSPI meant we need the flag
> at the mechanism level (you need it in NTLMSSP or there is no
> negotiation of a session key useful for signing), so it is retained in
> krb5 mechanisms as well.
>
> And in fact if you look at RFC 4178 you'll find this in the
> Introduction:
> """
>    If per-message integrity services [RFC2743] are available on the
>    established mechanism security context, then the negotiation is
>    protected to ensure that the mechanism list has not been modified.
> """

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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
In reply to this post by Isaac Boukris
On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:

> On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > Following the discussion on  IRC, there is currently a difference in
> > > between Heimdal and MIT, when the client does not send bindings, and
> > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > it succeeds.
> >
> > There are a few reasons why I think Heimdal's behavior is better:
>
> Taking a closer look at MIT accept() code, it looks like there is a
> case where no checksum is provided at all, where MIT would skip
> channel-bindings even if the server provided ones. It sounds like
> Windows also supports this.
>
> https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659

Given this case it sounds like relaxing MITs code to accept when
clients do not send Channel Bindings to allow the context to be
established brings consistency not only across implementations but also
within the MIT code by simplifying away that condition.


Here I am going to try to summarize how I and Isaac think we should
change the semantics so that we can interoperate better.

Premise: Isaac was investigating on how to handle connecting to Windows
servers that implement a configuration flag called
LdapEnforceChannelBinding

This flag can be configured with 3 levels:

Level 0: CBs are completely disabled
Level 1: CBs are optional. Specifically clients that do not send
KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
clients that send KERB_AP_OPTIONS_CBT are required to send matching
Channel Bindings.
Level 2: All clients must send Channel Bindings, without exceptions.

This applies only to the LDAP service as far as we know, but requires
us to try to allow these configurations in servers that are used to
emulate Windows AD (eg Samba).

With current MIT code we can only really implement
LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
in the acceptor, and level 2 when passing CBs, however as stated
multiple times over the years in previous conversations, this MIT krb5
behavior makes it hard to perform gradual conversions of the clients.

With current Heimdal, in contrast, it looks like we can only implement
LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
in the acceptor, and level 1 when passing CBs, this means we do not
have a way to enforce CBs at all.

We'd like to propose that both MIT and Heimdal code converge in
behavior and agree in implementing the following behavior:

[ACCEPTOR SIDE]

1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
then Channel Bindings are ignored (equivalent to level = 0)
2) When passing actual Channel Bindings to gss_accept_sec_context()
then Channel Bindings are checked only if the client sends non zero
CBs. (allows us to implement level = 1)
3) If the client sent CBs and we verified them set a new flag in
ret_flags that signify CBs were received and checked (this will allow
us to implement level = 2 behavior by failing the connection if the
flag is missing).

Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
this then the above point (2) above is split in two sub options:

2) When passing actual Channel Bindings to gss_accept_sec_context()
then:
2.1) Channel Bindings are checked only if the client sends non zero CBs
and KERB_AP_OPTIONS_CBT is not present.
2.2) Channel Bindings are enforced if the client provides the
KERB_AP_OPTIONS_CBT.

NOTE in 2.2 we propose that context establishment fails if CBs are not
provided, we do not rely on the application to check ret_flags in this
case.

Optionally[B] we add a krb5.conf flag like "require channel bindings"
that causes the gss_accept_sec_context() function to fail if CBs are
passed into it and the client does not send CBs (ie we do not rely on
the applications to check ret_flags, the context establishment fails
just like MIT code currently does).

Option B allows operators relying on current MIT behavior to retain it
by simply adding this option in krb5.conf and not having to worry to
change pre-existing applications in order to enforce CBs.


[INITIATOR SIDE]

Optionally [C] we add a krb5.conf flag like "require channel bindings"
that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
The flag should always be emitted and will cause clients that have not
been updated to send CBs to fail against servers that have support for
interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
that all their client software has been properly updated before
switching the same flag on on the servers.


In closing,

Although Options B and C could use different config options we suggest
the exact same option to be used for both initiator and acceptor for
consistency of behavior and to reduce the number of knobs to dial for
admins. Applications that need special exceptions can always be
configured to point to a different custom krb5.conf file.

NOTE: "require channel bindings" defaults to False in our proposal.


We can say that Options A,B,C are in decreasing order of importance to
us, but I personally would like to see all three implemented at the
same time if at all possible.


HTH,
Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <[hidden email]> wrote:

>
> On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > Following the discussion on  IRC, there is currently a difference in
> > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > it succeeds.
> > >
> > > There are a few reasons why I think Heimdal's behavior is better:
> >
> > Taking a closer look at MIT accept() code, it looks like there is a
> > case where no checksum is provided at all, where MIT would skip
> > channel-bindings even if the server provided ones. It sounds like
> > Windows also supports this.
> >
> > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
>
> Given this case it sounds like relaxing MITs code to accept when
> clients do not send Channel Bindings to allow the context to be
> established brings consistency not only across implementations but also
> within the MIT code by simplifying away that condition.
>
>
> Here I am going to try to summarize how I and Isaac think we should
> change the semantics so that we can interoperate better.
>
> Premise: Isaac was investigating on how to handle connecting to Windows
> servers that implement a configuration flag called
> LdapEnforceChannelBinding
>
> This flag can be configured with 3 levels:
>
> Level 0: CBs are completely disabled
> Level 1: CBs are optional. Specifically clients that do not send
> KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> clients that send KERB_AP_OPTIONS_CBT are required to send matching
> Channel Bindings.
> Level 2: All clients must send Channel Bindings, without exceptions.
>
> This applies only to the LDAP service as far as we know, but requires
> us to try to allow these configurations in servers that are used to
> emulate Windows AD (eg Samba).
>
> With current MIT code we can only really implement
> LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> in the acceptor, and level 2 when passing CBs, however as stated
> multiple times over the years in previous conversations, this MIT krb5
> behavior makes it hard to perform gradual conversions of the clients.
>
> With current Heimdal, in contrast, it looks like we can only implement
> LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> in the acceptor, and level 1 when passing CBs, this means we do not
> have a way to enforce CBs at all.
>
> We'd like to propose that both MIT and Heimdal code converge in
> behavior and agree in implementing the following behavior:
>
> [ACCEPTOR SIDE]
>
> 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> then Channel Bindings are ignored (equivalent to level = 0)
> 2) When passing actual Channel Bindings to gss_accept_sec_context()
> then Channel Bindings are checked only if the client sends non zero
> CBs. (allows us to implement level = 1)
> 3) If the client sent CBs and we verified them set a new flag in
> ret_flags that signify CBs were received and checked (this will allow
> us to implement level = 2 behavior by failing the connection if the
> flag is missing).
>
> Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> this then the above point (2) above is split in two sub options:
>
> 2) When passing actual Channel Bindings to gss_accept_sec_context()
> then:
> 2.1) Channel Bindings are checked only if the client sends non zero CBs
> and KERB_AP_OPTIONS_CBT is not present.
> 2.2) Channel Bindings are enforced if the client provides the
> KERB_AP_OPTIONS_CBT.
>
> NOTE in 2.2 we propose that context establishment fails if CBs are not
> provided, we do not rely on the application to check ret_flags in this
> case.
>
> Optionally[B] we add a krb5.conf flag like "require channel bindings"
> that causes the gss_accept_sec_context() function to fail if CBs are
> passed into it and the client does not send CBs (ie we do not rely on
> the applications to check ret_flags, the context establishment fails
> just like MIT code currently does).

Hmm, if we provide a krb5.conf for this, then I think it might make
more sense to use set_cred/context_option over ret flag. So the logic
would be lib-defaults is false (not fail), can be overridden by
krb5.conf, and again by application code.

> Option B allows operators relying on current MIT behavior to retain it
> by simply adding this option in krb5.conf and not having to worry to
> change pre-existing applications in order to enforce CBs.
>
>
> [INITIATOR SIDE]
>
> Optionally [C] we add a krb5.conf flag like "require channel bindings"
> that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> The flag should always be emitted and will cause clients that have not
> been updated to send CBs to fail against servers that have support for
> interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> that all their client software has been properly updated before
> switching the same flag on on the servers.
>
>
> In closing,
>
> Although Options B and C could use different config options we suggest
> the exact same option to be used for both initiator and acceptor for
> consistency of behavior and to reduce the number of knobs to dial for
> admins. Applications that need special exceptions can always be
> configured to point to a different custom krb5.conf file.

Not sure about making it the same option, it has side impacts.

> NOTE: "require channel bindings" defaults to False in our proposal.

Thanks for summing it up.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
On Mon, 2020-03-02 at 19:00 +0100, Isaac Boukris wrote:

> On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <[hidden email]> wrote:
> > On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > > Following the discussion on  IRC, there is currently a difference in
> > > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > > it succeeds.
> > > >
> > > > There are a few reasons why I think Heimdal's behavior is better:
> > >
> > > Taking a closer look at MIT accept() code, it looks like there is a
> > > case where no checksum is provided at all, where MIT would skip
> > > channel-bindings even if the server provided ones. It sounds like
> > > Windows also supports this.
> > >
> > > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
> >
> > Given this case it sounds like relaxing MITs code to accept when
> > clients do not send Channel Bindings to allow the context to be
> > established brings consistency not only across implementations but also
> > within the MIT code by simplifying away that condition.
> >
> >
> > Here I am going to try to summarize how I and Isaac think we should
> > change the semantics so that we can interoperate better.
> >
> > Premise: Isaac was investigating on how to handle connecting to Windows
> > servers that implement a configuration flag called
> > LdapEnforceChannelBinding
> >
> > This flag can be configured with 3 levels:
> >
> > Level 0: CBs are completely disabled
> > Level 1: CBs are optional. Specifically clients that do not send
> > KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> > clients that send KERB_AP_OPTIONS_CBT are required to send matching
> > Channel Bindings.
> > Level 2: All clients must send Channel Bindings, without exceptions.
> >
> > This applies only to the LDAP service as far as we know, but requires
> > us to try to allow these configurations in servers that are used to
> > emulate Windows AD (eg Samba).
> >
> > With current MIT code we can only really implement
> > LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> > in the acceptor, and level 2 when passing CBs, however as stated
> > multiple times over the years in previous conversations, this MIT krb5
> > behavior makes it hard to perform gradual conversions of the clients.
> >
> > With current Heimdal, in contrast, it looks like we can only implement
> > LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> > in the acceptor, and level 1 when passing CBs, this means we do not
> > have a way to enforce CBs at all.
> >
> > We'd like to propose that both MIT and Heimdal code converge in
> > behavior and agree in implementing the following behavior:
> >
> > [ACCEPTOR SIDE]
> >
> > 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> > then Channel Bindings are ignored (equivalent to level = 0)
> > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > then Channel Bindings are checked only if the client sends non zero
> > CBs. (allows us to implement level = 1)
> > 3) If the client sent CBs and we verified them set a new flag in
> > ret_flags that signify CBs were received and checked (this will allow
> > us to implement level = 2 behavior by failing the connection if the
> > flag is missing).
> >
> > Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> > this then the above point (2) above is split in two sub options:
> >
> > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > then:
> > 2.1) Channel Bindings are checked only if the client sends non zero CBs
> > and KERB_AP_OPTIONS_CBT is not present.
> > 2.2) Channel Bindings are enforced if the client provides the
> > KERB_AP_OPTIONS_CBT.
> >
> > NOTE in 2.2 we propose that context establishment fails if CBs are not
> > provided, we do not rely on the application to check ret_flags in this
> > case.
> >
> > Optionally[B] we add a krb5.conf flag like "require channel bindings"
> > that causes the gss_accept_sec_context() function to fail if CBs are
> > passed into it and the client does not send CBs (ie we do not rely on
> > the applications to check ret_flags, the context establishment fails
> > just like MIT code currently does).
>
> Hmm, if we provide a krb5.conf for this, then I think it might make
> more sense to use set_cred/context_option over ret flag. So the logic
> would be lib-defaults is false (not fail), can be overridden by
> krb5.conf, and again by application code.

set_context_option would require a new API to create a context before
calling gss_accept_sec_context()
set_cred_option would force to acquire crede before accepting which
means you cannot accept and let the system chose the best key in a
keytab.
Either of these means bigger changes to existing code as well.

So they both have drawbacks that I rather not have to rely on,
ret_flags still is the simplest way to provide a signal back when
needed, even though in some cases it won't be used.
however if ret_flags is undesireable to touch a
gss_inquire_sec_context_by_oid() could be used, it still has a greater
impact on existing code than may be desirable, but at least it won't
require new APIs or forcing creds.

> > Option B allows operators relying on current MIT behavior to retain it
> > by simply adding this option in krb5.conf and not having to worry to
> > change pre-existing applications in order to enforce CBs.
> >
> >
> > [INITIATOR SIDE]
> >
> > Optionally [C] we add a krb5.conf flag like "require channel bindings"
> > that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> > The flag should always be emitted and will cause clients that have not
> > been updated to send CBs to fail against servers that have support for
> > interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> > that all their client software has been properly updated before
> > switching the same flag on on the servers.
> >
> >
> > In closing,
> >
> > Although Options B and C could use different config options we suggest
> > the exact same option to be used for both initiator and acceptor for
> > consistency of behavior and to reduce the number of knobs to dial for
> > admins. Applications that need special exceptions can always be
> > configured to point to a different custom krb5.conf file.
>
> Not sure about making it the same option, it has side impacts.

I feel like distinguishing is excessive, it is unlikely you are ok to
force one and not another, in practice, on the same system. And should
you really need it because of compatibility issues in one application,
you can always use the escape hatch of using a different config file
for that specific app.

> > NOTE: "require channel bindings" defaults to False in our proposal.
>
> Thanks for summing it up.
>

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
On Mon, Mar 2, 2020 at 8:44 PM Simo Sorce <[hidden email]> wrote:

>
> On Mon, 2020-03-02 at 19:00 +0100, Isaac Boukris wrote:
> > On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <[hidden email]> wrote:
> > > On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > > > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > > > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > > > Following the discussion on  IRC, there is currently a difference in
> > > > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > > > it succeeds.
> > > > >
> > > > > There are a few reasons why I think Heimdal's behavior is better:
> > > >
> > > > Taking a closer look at MIT accept() code, it looks like there is a
> > > > case where no checksum is provided at all, where MIT would skip
> > > > channel-bindings even if the server provided ones. It sounds like
> > > > Windows also supports this.
> > > >
> > > > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
> > >
> > > Given this case it sounds like relaxing MITs code to accept when
> > > clients do not send Channel Bindings to allow the context to be
> > > established brings consistency not only across implementations but also
> > > within the MIT code by simplifying away that condition.
> > >
> > >
> > > Here I am going to try to summarize how I and Isaac think we should
> > > change the semantics so that we can interoperate better.
> > >
> > > Premise: Isaac was investigating on how to handle connecting to Windows
> > > servers that implement a configuration flag called
> > > LdapEnforceChannelBinding
> > >
> > > This flag can be configured with 3 levels:
> > >
> > > Level 0: CBs are completely disabled
> > > Level 1: CBs are optional. Specifically clients that do not send
> > > KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> > > clients that send KERB_AP_OPTIONS_CBT are required to send matching
> > > Channel Bindings.
> > > Level 2: All clients must send Channel Bindings, without exceptions.
> > >
> > > This applies only to the LDAP service as far as we know, but requires
> > > us to try to allow these configurations in servers that are used to
> > > emulate Windows AD (eg Samba).
> > >
> > > With current MIT code we can only really implement
> > > LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> > > in the acceptor, and level 2 when passing CBs, however as stated
> > > multiple times over the years in previous conversations, this MIT krb5
> > > behavior makes it hard to perform gradual conversions of the clients.
> > >
> > > With current Heimdal, in contrast, it looks like we can only implement
> > > LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> > > in the acceptor, and level 1 when passing CBs, this means we do not
> > > have a way to enforce CBs at all.
> > >
> > > We'd like to propose that both MIT and Heimdal code converge in
> > > behavior and agree in implementing the following behavior:
> > >
> > > [ACCEPTOR SIDE]
> > >
> > > 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> > > then Channel Bindings are ignored (equivalent to level = 0)
> > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > then Channel Bindings are checked only if the client sends non zero
> > > CBs. (allows us to implement level = 1)
> > > 3) If the client sent CBs and we verified them set a new flag in
> > > ret_flags that signify CBs were received and checked (this will allow
> > > us to implement level = 2 behavior by failing the connection if the
> > > flag is missing).
> > >
> > > Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> > > this then the above point (2) above is split in two sub options:
> > >
> > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > then:
> > > 2.1) Channel Bindings are checked only if the client sends non zero CBs
> > > and KERB_AP_OPTIONS_CBT is not present.
> > > 2.2) Channel Bindings are enforced if the client provides the
> > > KERB_AP_OPTIONS_CBT.
> > >
> > > NOTE in 2.2 we propose that context establishment fails if CBs are not
> > > provided, we do not rely on the application to check ret_flags in this
> > > case.
> > >
> > > Optionally[B] we add a krb5.conf flag like "require channel bindings"
> > > that causes the gss_accept_sec_context() function to fail if CBs are
> > > passed into it and the client does not send CBs (ie we do not rely on
> > > the applications to check ret_flags, the context establishment fails
> > > just like MIT code currently does).
> >
> > Hmm, if we provide a krb5.conf for this, then I think it might make
> > more sense to use set_cred/context_option over ret flag. So the logic
> > would be lib-defaults is false (not fail), can be overridden by
> > krb5.conf, and again by application code.
>
> set_context_option would require a new API to create a context before
> calling gss_accept_sec_context()
> set_cred_option would force to acquire crede before accepting which
> means you cannot accept and let the system chose the best key in a
> keytab.
> Either of these means bigger changes to existing code as well.
>
> So they both have drawbacks that I rather not have to rely on,
> ret_flags still is the simplest way to provide a signal back when
> needed, even though in some cases it won't be used.
> however if ret_flags is undesireable to touch a
> gss_inquire_sec_context_by_oid() could be used, it still has a greater
> impact on existing code than may be desirable, but at least it won't
> require new APIs or forcing creds.

I see.

> > > Option B allows operators relying on current MIT behavior to retain it
> > > by simply adding this option in krb5.conf and not having to worry to
> > > change pre-existing applications in order to enforce CBs.
> > >
> > >
> > > [INITIATOR SIDE]
> > >
> > > Optionally [C] we add a krb5.conf flag like "require channel bindings"
> > > that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> > > The flag should always be emitted and will cause clients that have not
> > > been updated to send CBs to fail against servers that have support for
> > > interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> > > that all their client software has been properly updated before
> > > switching the same flag on on the servers.
> > >
> > >
> > > In closing,
> > >
> > > Although Options B and C could use different config options we suggest
> > > the exact same option to be used for both initiator and acceptor for
> > > consistency of behavior and to reduce the number of knobs to dial for
> > > admins. Applications that need special exceptions can always be
> > > configured to point to a different custom krb5.conf file.
> >
> > Not sure about making it the same option, it has side impacts.
>
> I feel like distinguishing is excessive, it is unlikely you are ok to
> force one and not another, in practice, on the same system. And should

Initiator is for talking with other servers, I don't see why that
would be unlikely.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Simo Sorce-3
On Mon, 2020-03-02 at 21:00 +0100, Isaac Boukris wrote:

> On Mon, Mar 2, 2020 at 8:44 PM Simo Sorce <[hidden email]> wrote:
> > On Mon, 2020-03-02 at 19:00 +0100, Isaac Boukris wrote:
> > > On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <[hidden email]> wrote:
> > > > On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > > > > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > > > > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > > > > Following the discussion on  IRC, there is currently a difference in
> > > > > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > > > > it succeeds.
> > > > > >
> > > > > > There are a few reasons why I think Heimdal's behavior is better:
> > > > >
> > > > > Taking a closer look at MIT accept() code, it looks like there is a
> > > > > case where no checksum is provided at all, where MIT would skip
> > > > > channel-bindings even if the server provided ones. It sounds like
> > > > > Windows also supports this.
> > > > >
> > > > > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
> > > >
> > > > Given this case it sounds like relaxing MITs code to accept when
> > > > clients do not send Channel Bindings to allow the context to be
> > > > established brings consistency not only across implementations but also
> > > > within the MIT code by simplifying away that condition.
> > > >
> > > >
> > > > Here I am going to try to summarize how I and Isaac think we should
> > > > change the semantics so that we can interoperate better.
> > > >
> > > > Premise: Isaac was investigating on how to handle connecting to Windows
> > > > servers that implement a configuration flag called
> > > > LdapEnforceChannelBinding
> > > >
> > > > This flag can be configured with 3 levels:
> > > >
> > > > Level 0: CBs are completely disabled
> > > > Level 1: CBs are optional. Specifically clients that do not send
> > > > KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> > > > clients that send KERB_AP_OPTIONS_CBT are required to send matching
> > > > Channel Bindings.
> > > > Level 2: All clients must send Channel Bindings, without exceptions.
> > > >
> > > > This applies only to the LDAP service as far as we know, but requires
> > > > us to try to allow these configurations in servers that are used to
> > > > emulate Windows AD (eg Samba).
> > > >
> > > > With current MIT code we can only really implement
> > > > LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> > > > in the acceptor, and level 2 when passing CBs, however as stated
> > > > multiple times over the years in previous conversations, this MIT krb5
> > > > behavior makes it hard to perform gradual conversions of the clients.
> > > >
> > > > With current Heimdal, in contrast, it looks like we can only implement
> > > > LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> > > > in the acceptor, and level 1 when passing CBs, this means we do not
> > > > have a way to enforce CBs at all.
> > > >
> > > > We'd like to propose that both MIT and Heimdal code converge in
> > > > behavior and agree in implementing the following behavior:
> > > >
> > > > [ACCEPTOR SIDE]
> > > >
> > > > 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> > > > then Channel Bindings are ignored (equivalent to level = 0)
> > > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > > then Channel Bindings are checked only if the client sends non zero
> > > > CBs. (allows us to implement level = 1)
> > > > 3) If the client sent CBs and we verified them set a new flag in
> > > > ret_flags that signify CBs were received and checked (this will allow
> > > > us to implement level = 2 behavior by failing the connection if the
> > > > flag is missing).
> > > >
> > > > Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> > > > this then the above point (2) above is split in two sub options:
> > > >
> > > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > > then:
> > > > 2.1) Channel Bindings are checked only if the client sends non zero CBs
> > > > and KERB_AP_OPTIONS_CBT is not present.
> > > > 2.2) Channel Bindings are enforced if the client provides the
> > > > KERB_AP_OPTIONS_CBT.
> > > >
> > > > NOTE in 2.2 we propose that context establishment fails if CBs are not
> > > > provided, we do not rely on the application to check ret_flags in this
> > > > case.
> > > >
> > > > Optionally[B] we add a krb5.conf flag like "require channel bindings"
> > > > that causes the gss_accept_sec_context() function to fail if CBs are
> > > > passed into it and the client does not send CBs (ie we do not rely on
> > > > the applications to check ret_flags, the context establishment fails
> > > > just like MIT code currently does).
> > >
> > > Hmm, if we provide a krb5.conf for this, then I think it might make
> > > more sense to use set_cred/context_option over ret flag. So the logic
> > > would be lib-defaults is false (not fail), can be overridden by
> > > krb5.conf, and again by application code.
> >
> > set_context_option would require a new API to create a context before
> > calling gss_accept_sec_context()
> > set_cred_option would force to acquire crede before accepting which
> > means you cannot accept and let the system chose the best key in a
> > keytab.
> > Either of these means bigger changes to existing code as well.
> >
> > So they both have drawbacks that I rather not have to rely on,
> > ret_flags still is the simplest way to provide a signal back when
> > needed, even though in some cases it won't be used.
> > however if ret_flags is undesireable to touch a
> > gss_inquire_sec_context_by_oid() could be used, it still has a greater
> > impact on existing code than may be desirable, but at least it won't
> > require new APIs or forcing creds.
>
> I see.
>
> > > > Option B allows operators relying on current MIT behavior to retain it
> > > > by simply adding this option in krb5.conf and not having to worry to
> > > > change pre-existing applications in order to enforce CBs.
> > > >
> > > >
> > > > [INITIATOR SIDE]
> > > >
> > > > Optionally [C] we add a krb5.conf flag like "require channel bindings"
> > > > that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> > > > The flag should always be emitted and will cause clients that have not
> > > > been updated to send CBs to fail against servers that have support for
> > > > interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> > > > that all their client software has been properly updated before
> > > > switching the same flag on on the servers.
> > > >
> > > >
> > > > In closing,
> > > >
> > > > Although Options B and C could use different config options we suggest
> > > > the exact same option to be used for both initiator and acceptor for
> > > > consistency of behavior and to reduce the number of knobs to dial for
> > > > admins. Applications that need special exceptions can always be
> > > > configured to point to a different custom krb5.conf file.
> > >
> > > Not sure about making it the same option, it has side impacts.
> >
> > I feel like distinguishing is excessive, it is unlikely you are ok to
> > force one and not another, in practice, on the same system. And should
>
> Initiator is for talking with other servers, I don't see why that
> would be unlikely.

I do not see why you would want to weaken a client connection on the
same server where you want to require inbound connections to use CBs by
distinguishing the two options.
After all the peer of the initiator can always ignore bindings, so it
is not like there is going to be an interop issue if you force your
client to provide the bindings.
But it gives you better assurance that the machine, as a whole, tries
to bound on to channels in all communications.

Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current semantics for channel-bindings in GSSAPI

Isaac Boukris
On Mon, Mar 2, 2020 at 9:11 PM Simo Sorce <[hidden email]> wrote:

>
> On Mon, 2020-03-02 at 21:00 +0100, Isaac Boukris wrote:
> > On Mon, Mar 2, 2020 at 8:44 PM Simo Sorce <[hidden email]> wrote:
> > > On Mon, 2020-03-02 at 19:00 +0100, Isaac Boukris wrote:
> > > > On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <[hidden email]> wrote:
> > > > > On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > > > > > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[hidden email]> wrote:
> > > > > > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > > > > > Following the discussion on  IRC, there is currently a difference in
> > > > > > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > > > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > > > > > it succeeds.
> > > > > > >
> > > > > > > There are a few reasons why I think Heimdal's behavior is better:
> > > > > >
> > > > > > Taking a closer look at MIT accept() code, it looks like there is a
> > > > > > case where no checksum is provided at all, where MIT would skip
> > > > > > channel-bindings even if the server provided ones. It sounds like
> > > > > > Windows also supports this.
> > > > > >
> > > > > > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
> > > > >
> > > > > Given this case it sounds like relaxing MITs code to accept when
> > > > > clients do not send Channel Bindings to allow the context to be
> > > > > established brings consistency not only across implementations but also
> > > > > within the MIT code by simplifying away that condition.
> > > > >
> > > > >
> > > > > Here I am going to try to summarize how I and Isaac think we should
> > > > > change the semantics so that we can interoperate better.
> > > > >
> > > > > Premise: Isaac was investigating on how to handle connecting to Windows
> > > > > servers that implement a configuration flag called
> > > > > LdapEnforceChannelBinding
> > > > >
> > > > > This flag can be configured with 3 levels:
> > > > >
> > > > > Level 0: CBs are completely disabled
> > > > > Level 1: CBs are optional. Specifically clients that do not send
> > > > > KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> > > > > clients that send KERB_AP_OPTIONS_CBT are required to send matching
> > > > > Channel Bindings.
> > > > > Level 2: All clients must send Channel Bindings, without exceptions.
> > > > >
> > > > > This applies only to the LDAP service as far as we know, but requires
> > > > > us to try to allow these configurations in servers that are used to
> > > > > emulate Windows AD (eg Samba).
> > > > >
> > > > > With current MIT code we can only really implement
> > > > > LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> > > > > in the acceptor, and level 2 when passing CBs, however as stated
> > > > > multiple times over the years in previous conversations, this MIT krb5
> > > > > behavior makes it hard to perform gradual conversions of the clients.
> > > > >
> > > > > With current Heimdal, in contrast, it looks like we can only implement
> > > > > LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> > > > > in the acceptor, and level 1 when passing CBs, this means we do not
> > > > > have a way to enforce CBs at all.
> > > > >
> > > > > We'd like to propose that both MIT and Heimdal code converge in
> > > > > behavior and agree in implementing the following behavior:
> > > > >
> > > > > [ACCEPTOR SIDE]
> > > > >
> > > > > 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> > > > > then Channel Bindings are ignored (equivalent to level = 0)
> > > > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > > > then Channel Bindings are checked only if the client sends non zero
> > > > > CBs. (allows us to implement level = 1)
> > > > > 3) If the client sent CBs and we verified them set a new flag in
> > > > > ret_flags that signify CBs were received and checked (this will allow
> > > > > us to implement level = 2 behavior by failing the connection if the
> > > > > flag is missing).
> > > > >
> > > > > Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> > > > > this then the above point (2) above is split in two sub options:
> > > > >
> > > > > 2) When passing actual Channel Bindings to gss_accept_sec_context()
> > > > > then:
> > > > > 2.1) Channel Bindings are checked only if the client sends non zero CBs
> > > > > and KERB_AP_OPTIONS_CBT is not present.
> > > > > 2.2) Channel Bindings are enforced if the client provides the
> > > > > KERB_AP_OPTIONS_CBT.
> > > > >
> > > > > NOTE in 2.2 we propose that context establishment fails if CBs are not
> > > > > provided, we do not rely on the application to check ret_flags in this
> > > > > case.
> > > > >
> > > > > Optionally[B] we add a krb5.conf flag like "require channel bindings"
> > > > > that causes the gss_accept_sec_context() function to fail if CBs are
> > > > > passed into it and the client does not send CBs (ie we do not rely on
> > > > > the applications to check ret_flags, the context establishment fails
> > > > > just like MIT code currently does).
> > > >
> > > > Hmm, if we provide a krb5.conf for this, then I think it might make
> > > > more sense to use set_cred/context_option over ret flag. So the logic
> > > > would be lib-defaults is false (not fail), can be overridden by
> > > > krb5.conf, and again by application code.
> > >
> > > set_context_option would require a new API to create a context before
> > > calling gss_accept_sec_context()
> > > set_cred_option would force to acquire crede before accepting which
> > > means you cannot accept and let the system chose the best key in a
> > > keytab.
> > > Either of these means bigger changes to existing code as well.
> > >
> > > So they both have drawbacks that I rather not have to rely on,
> > > ret_flags still is the simplest way to provide a signal back when
> > > needed, even though in some cases it won't be used.
> > > however if ret_flags is undesireable to touch a
> > > gss_inquire_sec_context_by_oid() could be used, it still has a greater
> > > impact on existing code than may be desirable, but at least it won't
> > > require new APIs or forcing creds.
> >
> > I see.
> >
> > > > > Option B allows operators relying on current MIT behavior to retain it
> > > > > by simply adding this option in krb5.conf and not having to worry to
> > > > > change pre-existing applications in order to enforce CBs.
> > > > >
> > > > >
> > > > > [INITIATOR SIDE]
> > > > >
> > > > > Optionally [C] we add a krb5.conf flag like "require channel bindings"
> > > > > that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> > > > > The flag should always be emitted and will cause clients that have not
> > > > > been updated to send CBs to fail against servers that have support for
> > > > > interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> > > > > that all their client software has been properly updated before
> > > > > switching the same flag on on the servers.
> > > > >
> > > > >
> > > > > In closing,
> > > > >
> > > > > Although Options B and C could use different config options we suggest
> > > > > the exact same option to be used for both initiator and acceptor for
> > > > > consistency of behavior and to reduce the number of knobs to dial for
> > > > > admins. Applications that need special exceptions can always be
> > > > > configured to point to a different custom krb5.conf file.
> > > >
> > > > Not sure about making it the same option, it has side impacts.
> > >
> > > I feel like distinguishing is excessive, it is unlikely you are ok to
> > > force one and not another, in practice, on the same system. And should
> >
> > Initiator is for talking with other servers, I don't see why that
> > would be unlikely.
>
> I do not see why you would want to weaken a client connection on the
> same server where you want to require inbound connections to use CBs by
> distinguishing the two options.
> After all the peer of the initiator can always ignore bindings, so it
> is not like there is going to be an interop issue if you force your
> client to provide the bindings.
> But it gives you better assurance that the machine, as a whole, tries
> to bound on to channels in all communications.

I really don't follow, as initiator you you talk to other servers, you
likely to need different options.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
12