On Mon Oct 8 19:28:34 2012, Marc-André Moreau wrote: > Hello, > > I originally removed the Kerberos code for the following reasons: > > I can handle a certain amount of "cleanup work" on people's > contributions, but please, this one was a royal pain. I got fed up > with it and honestly think it's worth more as reference code to start > again cleanly than anything else. It's cool when people get things > working their work, it is definitely not cool when I've got to spend > twice the amount of time getting it done cleanly. At the time, it was > also blocking me in the work towards WinPR, and judged it would be > better to come back to it when I could get help with it. The old code > is still there and has various improvements I did on top of it before > I decided it was just too much work for the moment. > > Here's the long term goal: > > Have Kerberos support implemented as an SSPI module just like the > current NTLM module. This will allow us to make use of the native > Kerberos SSPI module on Windows, just like we currently are on Windows. > > Here are the problems we need to work on before we can reach that point: > > Implementation of the Negotiate SSPI module, which abstracts the NTLM > and Kerberos modules on Windows. The Negotiate module basically checks > if Kerberos can be used in the current context and chooses it over > NTLM. The Negotiate module adds extra messages to the connection > sequence when Kerberos is used to negotiate Kerberos over NTLM. Right > now we're using the NTLM module directly, since it is functionally > equivalent to the Negotiate module when it chooses not to use Kerberos. > > There is another (architectural) issue: > > The current ASN.1 utils are located in libfreerdp-crypto, and the SSPI > modules are implemented cleanly as part of WinPR. WinPR does not > depend on FreeRDP libraries. The way ASN.1 encoding is done on Windows > is with msasn1.dll, a small and reusable ASN.1 encoding/decoding > engine that supports the various ASN.1 variants. It is in my plans to > have a clean reimplementation of that engine in WinPR such that it can > be used in our SSPI modules. > > I'm about to give a contract to a developer such that he implements > msasn1 as part of WinPR, with the goal of easing the implementation of > SSPI modules. > > If you want to start now, I guess it would make sense to temporarily > move the ASN.1 utils we have in libfreerdp-crypto to libwinpr-utils, > to avoid breaking the layering. When the msasn1 engine will be ready, > we will be able to modify the current code to make use of it and get > rid of the older utils completely. > > The points about having an engine and not custom utils for ASN.1 are > multiple, but one of them is very important: in the long run, I'd like > to be able to have enough tests, error checking, and all the proper > techniques to not only get code to runs, but code that is secure. > There is a HUGE amount of effort that goes into making such code > secure, but that's just the beginning of it. By using the WinPR > approach, we at least have a known architecture that has been > engineered before us, with known inputs, outputs, and error checking, etc. > > I've got some people contacting me about Kerberos development, but I > haven't seen any serious development except for the original code that > was temporarily removed to be later reimplemented. > > If you are interested, I'll guide you towards what we need. > > For others: it would be extremely helpful to find someone that would > help implementing other SSPI modules such as Schannel. Even just > writing tests would be really helpful. > > Let me know what you think, > > Best regards, > - Marc-Andre Hello,
thanks for this detailed answer. I get the point about the removal. We were especially concerned about deeper problems that this implementation might have uncovered (like fundamental incompatibilities or such...). So this is reassuring in a sense. Before we decide to commit ourself to work on KRB support we'd like to make sure that this will allow single signed-on, which is what we eventually need. From what I can see it should work out, but I'm not that familiar with all the protocols involved and might be missing something. Any thought regarding this aspect? Regards, Henri ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
