ANN: BROWSER-ID a new SASL Authentication mechanism under development

[Austin King]

At Mozilla, we're experimenting with a new SASL plugin for BrowserID[1].

BrowserID is a decentralized identity system that makes it possible
for users to prove ownership of email addresses in a secure manner,
without requiring per-site passwords[2].

I'm looking for feedback on implementing a SASL authentication mechanism.
I've got roughly the happy case working with pluginviewer and OpenLDAP.

Don protective eye-ware and visit:
https://github.com/ozten/sasl-browserid

Any feedback is appreciated, but specifically:
* Code review / contributions
* Preferred distribution channel
* Licensing
* Enterprise or Academic Use Cases
* Next steps and Timing

Once this plugin is production quality, what is the best way to 
distribute it? Should
we try to get it upstream into Cyrus SASL, downstream it into OS 
distributions, or

just provide it for download from a website?

Licensing - is there any preferred licensing for the code? This 
partially depends on
the target distribution channel. We want to balance this decision with 
input from
your community. plugins_common is currently a dependency. We'll re-write 
that

to get it out of the repo (unless it's not an issue).

Use Cases - Is this plugin worth building? We're finding we need it for 
our LDAP

directories which are used from web applications. Authentication using SASL
seems more secure than using proxy authentication. BrowserID is an awkward
auth mechanism in that it originates from JavaScript in web content. Are 
there other
valid user cases (webmail?) where this plugin could see some real world 
use? Perhaps

webmail...?

Next Steps - I see centrally registering auth mechanisms, RFCs for 
mechanism communication,

etc are mentioned. Is this still common practice?

Other feedback can come in bugs [3], pull requests, etc

thanks,
ozten

[1] https://browserid.org
[2] http://lloyd.io/how-browserid-works
[3] https://github.com/ozten/sasl-browserid/issues

Re: ANN: BROWSER-ID a new SASL Authentication mechanism under development

[Alexey Melnikov]

Hi Austin,

Austin King wrote:


At Mozilla, we're experimenting with a new SASL plugin for BrowserID[1].

BrowserID is a decentralized identity system that makes it possible
for users to prove ownership of email addresses in a secure manner,
without requiring per-site passwords[2].


Is there a SASL-related spec for this, or at least an example of the 
SASL exchange?



I'm looking for feedback on implementing a SASL authentication mechanism.
I've got roughly the happy case working with pluginviewer and OpenLDAP.

Don protective eye-ware and visit:
https://github.com/ozten/sasl-browserid

Any feedback is appreciated, but specifically:
* Code review / contributions
* Preferred distribution channel
* Licensing
* Enterprise or Academic Use Cases
* Next steps and Timing

Once this plugin is production quality, what is the best way to 
distribute it? Should

we try to get it upstream into Cyrus SASL,



downstream it into OS distributions, or
just provide it for download from a website?


My personal preferences are to try to get it into the upstream. The next 
step down is a patch in "contrib". Separate download is of course always 
an option.


I will need to have a look at the build dependencies. Complicated 
dependencies are not a showstopper, but at least we should eliminate 
circular dependencies (if any).


Licensing - is there any preferred licensing for the code? This 
partially depends on
the target distribution channel. We want to balance this decision with 
input from
your community. plugins_common is currently a dependency. We'll 
re-write that

to get it out of the repo (unless it's not an issue).


I think CMU BSD-style license is the best. Then it makes your code 
compatible with Cyrus SASL.


Use Cases - Is this plugin worth building? We're finding we need it 
for our LDAP
directories which are used from web applications. Authentication using 
SASL
seems more secure than using proxy authentication. BrowserID is an 
awkward
auth mechanism in that it originates from JavaScript in web content. 
Are there other
valid user cases (webmail?) where this plugin could see some real 
world use? Perhaps

webmail...?

Next Steps - I see centrally registering auth mechanisms, RFCs for 
mechanism communication,

etc are mentioned. Is this still common practice?


Very much so. I can help you with this as well, as I've written some 
SASL-related RFCs.



Other feedback can come in bugs [3], pull requests, etc

thanks,
ozten

[1] https://browserid.org
[2] http://lloyd.io/how-browserid-works
[3] https://github.com/ozten/sasl-browserid/issues 


Best Regards,
Alexey

--
Internet Messaging Team Lead, 
JID: same as my email address
twitter: aamelnikov

Re: ANN: BROWSER-ID a new SASL Authentication mechanism under development

[Austin King]

On 09/02/2011 05:17 AM, Alexey Melnikov wrote:

Hi Austin,

Austin King wrote:


At Mozilla, we're experimenting with a new SASL plugin for BrowserID[1].

BrowserID is a decentralized identity system that makes it possible
for users to prove ownership of email addresses in a secure manner,
without requiring per-site passwords[2].


Is there a SASL-related spec for this, or at least an example of the 
SASL exchange?

I can definitely use your help!
https://github.com/ozten/sasl-browserid/blob/master/docs/sasl-browserid-design.md

I'll be documenting this better over time and just started talking to 
our security team about

a architecture review.



Once this plugin is production quality, what is the best way to 
distribute it? Should

we try to get it upstream into Cyrus SASL,



downstream it into OS distributions, or
just provide it for download from a website?


My personal preferences are to try to get it into the upstream. The 
next step down is a patch in "contrib". Separate download is of course 
always an option.

Great, eventually having source in Cyrus SASL tree makes a lot of sense.


I will need to have a look at the build dependencies. Complicated 
dependencies are not a showstopper, but at least we should eliminate 
circular dependencies (if any).
The plugin depends on curl and yajl 2 [1] for the browserid.org 
verification call.
The plugin also depends on mysql to maintain a session cache. This is 
useful for web oriented uses of the plugin.


I'm not sure there are any "long-lived connection" use cases, but if so 
they would not need a session, so mysql is optional.


The session backend could be generalized to be like auxprop (other 
backends besides mysql), but I'll only build out one backend in the 
short term.


Next Steps - I see centrally registering auth mechanisms, RFCs for 
mechanism communication,

etc are mentioned. Is this still common practice?


Very much so. I can help you with this as well, as I've written some 
SASL-related RFCs.
Again, much appreciated. If you like IRC, we're in 
ircs://irc.mozilla.org/#identity

ozten is my nick.

thanks,
Austin

[1] http://lloyd.github.com/yajl/

Re: ANN: BROWSER-ID a new SASL Authentication mechanism under development

[Austin King]

On 09/02/2011 05:17 AM, Alexey Melnikov wrote:

Hi Austin,

Austin King wrote:


At Mozilla, we're experimenting with a new SASL plugin for BrowserID[1].

BrowserID is a decentralized identity system that makes it possible
for users to prove ownership of email addresses in a secure manner,
without requiring per-site passwords[2].


Is there a SASL-related spec for this, or at least an example of the 
SASL exchange?
I've documented our current demo, which is a concrete example using 
Django (web application framework) and OpenLDAP.

https://github.com/ozten/mozillians/blob/browserid/docs/browserid.rst

Feedback appreciated.

thanks,
austin


Best Regards,
Alexey