opened
jborean93
username_0
This PR is to add support for generating Kerberos tokens with Channel Binding tokens. This is used in some areas to try and stop MiM attacks by having the authentication bind a value from a higher layer. I've tested this manually through a custom branch on requests-kerberos with a WinRM endpoint where the CBT level is set to strict.

I am a novice at C so happy to take some pointers around the code and potential improvements to what I have done.
Added support for Channel Binding Tokens
issue
created
nitzmahone
username_1
@username_2 - since Apple seem to have picked up the ball again on maintaining/enhancing their code for this project, what's the status of this fork? Are you intending to track Apple's work, or should we explore merging back with theirs (especially since this introduces a new API differential from their code)?
comment
created
02strich
username_2
I think you are probably right in looking to merge back changes given that Apple has come back. Due to personal commitments I am sadly not able to commit to a more detailed answer of the path forward right now, but I am certainly looking at it.
comment
created
jborean93
username_0
@username_1 @username_2 I've raised a PR which is similar to this one but with some Python 3 tweaks here https://github.com/apple/ccs-pykerberos/pull/55. It has some details around how I tested it and hopefully I'll hear back from one of the devs there soon.
comment
created
nitzmahone
username_1
@username_2 Apple doesn't seem to be particularly active on their fork at the moment either. Requests-kerberos is currently using this fork, and in addition, there are a couple of other things that we need to merge for Ansible. If you're unable to continue maintaining this fork, any chance you could allow myself and/or @username_0 commit rights to this repo and maintainer access to the pypi project (so we can publish updates)? I'd really hate to create yet another fork, but we've also got customers that are waiting on updates from us that are blocked on getting features merged into one kerberos library or another. If so, drop me a note at `mrd -at- redhat-dot-com` and we can discuss logistics. I've had the same thing happen with a couple of other projects that Ansible relies on, but we've managed to avoid creating any new forks thus far...
comment
created
jborean93
username_0
@username_1 I was planning on raising a request on their mailing list for the calendar project to see what they come back with but I agree they don't seem very active with that project.
comment
created
02strich
username_2
@username_1 I had reached out to you via email but not heard back yet so let me check here: given the upstream implementation as well as other forks are in better shape then a) when I started this fork and b) the fork itself I am wondering whether it is still worthwhile to maintain this fork. If you believe yes, I am more then happy to work through the logistics of granting you access - please let me know what you think
comment
created
nitzmahone
username_1
username_2: you've got mail ;)
comment