Feature Request: Server Mode

[vanrein]

Is it difficult to add support for SASL on the server side? It is close AFAIK.

I'd like to have it for HTTP SASL, which is an Internet Draft we're working on. We're already doing it for Java and Apache modules, but I'd like to also demo WSGI middleware using it.

(I know I'm welcome to submit a PR. Frankly, for me this would be one level too deep to get into. So I hope this is a fair request to a project that already has most of the expertise.)

[ashafer01]

Hi @vanrein, this is definitely an interesting idea, and you're right its possible it may not be far off from what's already written. Would definitely have to do some more checking before making a call on this though.

What is the QOP need for the purposes of HTTP SASL? I don't see it mentioned on the draft. Most of our mechanism implementations currently only support auth-level QOP (only GSSAPI supports int and conf currently). If you need the higher levels on other mechs this is probably the biggest impediment.

Would there be any attribution to this project in any future standards documents or similar? (I'm honestly only vaguely familiar with the IETF RFC process)

Any more details about your specific requirements may be helpful. Any addition to this module would need to be general-purpose though.

May have more questions later. Also pinging @thobbs for optional comment due to the nature and possible scale of this request.

[vanrein]

Hey Alex, Thanks for taking this into consideration!

What is the QOP need for the purposes of HTTP SASL? I don't see it mentioned on the draft.

Point noted, thanks! To be honest, I never really looked into this field, but for HTTP SASL you are right, I should. Not sure if it adds value to HTTP SASL, but I should find out.

Most of our mechanism implementations currently only support `auth`-level QOP (only GSSAPI supports `int` and `conf` currently). If you need the higher levels on other mechs this is probably the biggest impediment.

Only auth is required, and the rest are generally disposed of in SASL; only GSSAPI in Kerberos5 can offer it and this is not really used because of TLSl indeed, GS2 formalises skipping it. A better path is to aim for "channel binding" with the underlying TLS layer that is needed anyway for SASL. I think this is what you're asking in relation to qop, right?

Would there be any attribution to this project in any future standards documents or similar? (I'm honestly only vaguely familiar with the IETF RFC process)

That can be done. Feedback on the document often leads to acknowledgements, and it's easy to mention a project alongside. Would you proof-read what I wrote about qop (or perhaps you even have suggested text).

Any more details about your specific requirements may be helpful. Any addition to this module would need to be general-purpose though.

Yes, it's the general nature why I decided to ask, indeed. The idea of the WSGI middleware is also to make a generic pluggable thing. We'll be using this with Kerberos and ideally a SCRAM mechanism. We're also hoping to incorporate channel binding. I might be asking too much with that though; the purpose really is to get to a solid identity framework that greatly improves the silly practices that now reign the web -- and make that easy.

May have more questions later. Also pinging @thobbs for optional comment due to the nature and possible scale of this request.

Thanks. Questions are always fine :)

…

-Rick

[thobbs]

Hey @ashafer01, @vanrein, thanks for pinging me for input.

Unfortunately, I've been away from this space for a while now, and realistically speaking, I simply won't have the time to re-engage at the level required to make intelligent comments about this. I trust @ashafer01 to make good decisions here in my absence.

Besides that, I'll just echo what Alex already said: additions to this library should be generally useful, and backwards compatibility should of course be maintained. Good luck with the new proposal!

[vanrein]

Hi Tyler and Alex,

I'll just echo what Alex already said: additions to this library should be generally useful, and backwards compatibility should of course be maintained. Good luck with the new proposal!

Should be no problem; what I am asking is more of the standard SASL functionality, of which the current kit is a partial implementation. I also believe it is useful to add more facilities than are currently in HTTP already :-) but that's because we're focussing on HTTP SASL. Alex, let me know if you think parts of SASL are hairy -- like channel binding which took me a long time to understand because its knowledge is scattered over multiple RFCs. We're actually testing a FireFox-demo with a SASL plugin at the moment, I can post it if you're curious.

…

-Rick

[vanrein]

Lovely, the proof-of-concept demo is working, so if you'd like to play around with HTTP SASL then be our guest! It builds on top of this base image by the way.