Current semantics for channel-bindings in GSSAPI
Simo Sorce
simo at redhat.com
Mon Mar 2 09:02:28 EST 2020
On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <metze at samba.org> 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/apache.smb.net at SMB.NET
>
>
> 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/apache.smb.net at SMB.NET
>
>
> 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/sdc.smb.net at SMB.NET
>
>
> 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/sdc.smb.net at SMB.NET
> > > > > * 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
More information about the krbdev
mailing list