Persona Privacy Policy
Issues for Mozilla Persona. To avoid duplicates, please search before submitting a new issue. Advanced search. 16 open, 47 total. 9 open, 33 total. 2 year graph, updates weekly. No documentation guides. The text was updated successfully, but these errors were encountered.
Last Updated: 06 March 2013
This privacy policy explains to what extent Mozilla Corporation (*) ('Mozilla') collects and uses information about users of Persona ('Persona Service'), where such users use the Mozilla-created servers and client.
Definitions
'Personal Information' is information that you provide to us that personally identifies you, such as your name, phone number, or email address. Except for your email address, Mozilla does not collect or require end-users of the Persona Service to furnish Personal Information.
'Non-Personal Information' is information that cannot by itself be directly associated with a specific person or entity. Non-Personal Information includes but is not limited to your computer’s configuration and which web browser you use.
'Potentially Personal Information' is information that is Non-Personal Information in and of itself but that could be used in conjunction with other information to personally identify you. For example, Uniform Resource Locators ('URLs') (the addresses of web pages) and Internet Protocol ('IP') addresses (the addresses of computers on the internet) can be Personal Information when combined with internet service provider ('ISP') records.
'Operational Data' means data regarding a user’s usage of the Services, such as access log data (such as data about when people access the service and with what piece of software). Mozilla collects Operational Data to help us so that we can ensure that we have sufficient capacity to meet user needs and otherwise to help with the operations of the Services.
'Usage Statistics' refers to the Non-Personal Information Mozilla will use to understand your use of the Service. Such information may include but is not limited to the amount of data you are storing with the service, the frequency with which you access the service, bandwidth utilization, user interaction data, and traffic shaping.
For clarity, Usage Statistics and Operational Data from your use of the Persona Service are not stored with your Personal Information. We take steps to aggregate or delete Operational Data and Usage Statistics after we no longer need it, unless we are required by law to keep it longer.
Gathering, Use and Disclosure of Transmission Data
Account Information
Before you are able to use Persona, you will be required to register. To register, the Persona Service will require the following Personal Information and Potentially Personal Information from you: an email address and password. Your email address is transferred to Mozilla using encryption called SSL. Your email address is used by us to provide you the services, such as allowing us to help you recover your account if you lose your password. Your password is transferred to Mozilla using SSL encryption but is only retained by Mozilla’s servers in an encrypted format (which means that it is not practically feasible to recover the password from this format).
Mozilla Personal Security Manager
Once you have registered, your password is used to help prevent unauthorized access to your account.
Data Used to Provide the Services
Mozilla receives and uses the following information for the purpose of providing and improving the Persona Service: IP address, email, date and time of accessing the Persona Service, and various operational data such as the type of client OS and browser version (which are also known as the user agent string).
Disclosure to Third Parties
The Persona Service will disclose your verified email address to a Web site of your choosing, only after you have expressly consented to such disclosure. A Web site is allowed to request a verified email address, which results in you being prompted about the site’s request. After you have agreed, the service may remember your choice, so that you may remain signed-in on the site on subsequent visits.
Mozilla will not otherwise knowingly disclose Personal Information or Potentially Personal Information to other third parties, except when required to do so, such as in order to comply with any law, regulation, or valid legal process, such as a search warrant, subpoena, statute, court order, or if necessary or appropriate to address an unlawful or harmful activity.
What Data is Analyzed by Mozilla?
Mozilla uses the Usage Statistics to understand your use of the Persona Service, unless you opt-in to share more information with us for this purpose.
How Are the Usage Statistics Used?
Mozilla will use the Usage Statistics gathered through the operation of the Persona Service to improve our products and services. By identifying aggregate patterns and trends in usage, Mozilla and its community are able to better design products and services to improve users’ experiences, both in terms of content and ease of use.
Where is the Operational Data Available?
Mozilla is an open organization that believes in sharing as much information as possible about its products, its operations, and its associations with its wider community. As such, Persona Service users should expect that Mozilla will make all Usage Statistics publicly available at some point. However, any publicly available Usage Statistics will only be reported on an aggregate, anonymous basis. No Personal Information or Potentially Personal Information will be available in any of these public reports.
How to Disable or Opt-Out of Persona
If at any time, you decide you no longer want to use the Persona Service, you may cancel your Persona Account by visiting https://persona.org/, signing in using any of your email addresses and your password, clicking the 'edit' button, and clicking 'remove' next to each of your email addresses. If you do not remember your password, you can use the email-verification-based password-reset feature to first recover access to your account, then delete it.
Other Disclosures
In certain other limited situations, Mozilla may disclose your Personal Information, such as when necessary to protect our websites and operations (e.g., against attacks); to protect the rights, privacy, safety, or property of Mozilla or its users; to enforce our terms of service; and to pursue available legal remedies. Additionally, Mozilla may need to transfer Personal Information to an affiliate or successor in the event of a change of our corporate structure or status, such as in the event of a restructuring, sale, or bankruptcy.
Service Providers
We work with third parties who provide services and content delivery networks and other services of an administrative nature. We may share information about you with such third parties for the purpose of enabling these third parties to provide such services.
Transfer of Data to the U.S.
Mozilla is a global organization and operates in different countries. Privacy laws and common practices vary from country to country. Some countries may provide for less legal protection of your personal data; others may provide more legal protection. By using the Persona Service, you consent to the transfer of the information collected, as outlined by this Policy, to Mozilla in the United States, which may provide a lesser level of data protection than in your country of residence.
Data Retention
We will retain any information collected for the period necessary to fulfill the purposes outlined in this Policy unless a longer retention period is required by law and/or regulations.
Privacy Policy Changes
Mozilla Personal
Mozilla may change this Privacy Policy from time to time. Each time you use the Persona Service the current version of this Privacy Policy will apply. Any and all changes will be reflected on this page. You should periodically check this page for any changes to the current policy. To make your review more convenient, we will post an effective date at the top of this page. Material changes will also be announced through the standard mechanisms through which Mozilla communicates with the Mozilla community. It is your responsibility to ensure that you understand the terms of this Privacy Policy.
What This Privacy Policy Doesn’t Cover
This policy does not apply to other Mozilla websites, products, or services. It also does not apply to your use of third-party clients or use of non-Mozilla servers. If you choose to use a third-party Persona client or servers provided by an entity other than Mozilla, this policy does not apply and Mozilla assumes no liability whatsoever for such products or services.
For More Information
You may request access, correction, or deletion of Personal Information or Potentially Personal Information, as permitted by law. We will seek to comply with such requests, provided that we have sufficient information to identify the Personal Information or Potentially Personal Information related to you. Any such requests or other questions or concerns regarding this Policy and Mozilla’s data protection practices should be addressed to:
Mozilla CorporationAttn: Legal Notices – Privacy
331 E. Evelyn Avenue
Mountain View, CA 94041
Phone: +1-650-903-0800
My good friend Nico Williams reckons that HTTP is the new TCP, and TCP the new IP. If this is the case, then perhaps the rest of this article isn’t worth reading. However, not every application – particularly in the slower-moving corporate world – is going to move to the web overnight, and even though off-line web-based applications continue to improve, some of us still prefer our thick-client mail readers, amongst other things. Further, remote logon protocols such as SSH, and file sharing protocols such as CIFS and NFS, don’t always have direct web equivalents.
Now, Mozilla Persona solves a bunch of interesting authentication problems: it has the best properties of public key infrastructure (in particular, the server doesn’t need to share a key with the identity provider), without of some of its drawbacks (because certificates are short-lived, the revocation issue becomes less important). Another really nice property of Persona is that it doesn’t require you to initially authenticate in a particular way – one might use passwords, one time passwords, smartcards, PKIX certificates, Kerberos tickets, EAP, some combination of the above – and as long as your identity provider knows who you are and can issue a Persona certificate, you’re good to go.
So, one might think: can we bring the benefits of Persona to non-web applications? We can. In the non-web world, many network protocols abstract away authentication using the Simple Authentication and Security Layer (SASL) or Generic Security Service Application Program Interface (GSS-API). We’re going to gloss over the details of these, suffice to say that in return for an application exchanging an arbitrary number of messages within its own protocol, the server is able to authenticate the client (and possibly vice versa). There may also be a shared key which can be used to encrypt or sign subsequent traffic.
Protocols that can use SASL or GSS-API for authentication include the acronym soup of IMAP, SMTP, XMPP, LDAP, CIFS, NFS, SSH and even HTTP itself. So, if we profile Persona for SASL and GSS-API, we can authenticate using a Persona identity – that is, a verified e-mail address or similar – within any of these application protocols.
This is indeed what we have been working on. Myself and Nico have written an Internet Draft that profiles BrowserID as a SASL and GSS-API security mechanism (we use “BrowserID” to refer to the actual protocol). My company, PADL, has developed an open source implementation which is available on Github. (We have also prototyped a Windows Security Support Provider which enables applications such as Outlook, Exchange and Internet Explorer to work with Persona. Plug: we are exploring commercial possibilities for this in conjunction with our partner Painless Security.)
In the rest of this article, we’ll take a look at how Persona for the non-web differs from normal web-based authentication, and show an example demonstrating signing into an IMAP server with Persona from the Apple Mail client.
Persona recap
There are plenty of articles on how Persona works, but we’ll recap the protocol here for convenience. Persona is a federated, decentralised authentication protocol. Users sign-in using a browser to an identity provider (IdP), which is an entity that can authenticate their e-mail address, although it can be any verifiable address that looks like an e-mail address.
When attempting to authenticate to a server (termed a Relying Party, or RP), the browser generates a private/public key pair, and asks the IdP to issue a certificate vouching for the public key. (These certificates may be cached.) The browser then generates an assertion, which contains the RP URL and a timestamp, and signs it with the user’s private key. The browser presents this and the user’s certificate to the web server, which validates the URL and timestamp and uses the user’s and IdP’s public keys to authenticate the user.
More information on Persona is available in the Mozilla Persona web site. It has been written about on this blog in Persona Beta 2 launch and the first Persona release post.
Extending to the non-web
At its simplest, using Persona for the non-web is identical to the web case, with the exception that the assertion contains a service principal name instead of a HTTPS URL. Service principal names are a construct inherited from the Kerberos that identify a service (for example, “imap” or “xmpp”) running on a particular host. (They may also identify a specific instance of a service running on a host.) For example, the service principal name for the IMAP server on mail.example.com would be “imap/mail.example.com”. Because Persona audiences have to be URLs, we encapsulate the service principal name inside a URN.
We don’t say anything about how the application sends the assertion to the server, because neither the SASL nor GSS-API abstractions do. This is the application protocol’s business: typically, it will have a particular message in its own protocol that can encapsulate an authentication token (in IMAP, for example, this is the “AUTHENTICATE” message). All we do say is that the application must allow the user to sign into their IdP and generate an assertion, which means they must have the ability to run an embedded web browser. Most operating systems provide a plug-in interface for new security mechanisms, so this is usually possible.
So far, this is pretty simple: throw up a web browser control, use a slightly strange-looking URL to identify the server, get an assertion and send it to the server. The server verifies the assertion, identifies the user as per normal, and all is well. And indeed, this is pretty much the protocol; it’s testament to the designers of Persona that it can so easily be re-purposed.
However, there are a few small tweaks that we have made to make Persona more useful for the non-web case. We describe these below.
Replay detection
The Persona specification doesn’t say anything about whether it’s safe to replay an assertion to a server or not. We’re a little paranoid, particularly because we don’t know whether the application is using transport security such as SSL/TLS. So we have built replay detection into the protocol. This works by either having the server maintain a cache of assertions it has received within a particular time frame, or having the client cryptographically sign a server-generated nonce.
Channel binding
Even if the client is using TLS, it can be desirable to protect against a man-in-the-middle that has a valid server certificate, but is not the party that authenticated the client. Channel binding allows the client to bind the assertion to a TLS server certificate or session. The server verifying the assertion can then verify that it matches the certificate it sent to the client. (The channel binding is simply an additional claim in the assertion, protected by the same chain of trust as the other claims.)
Key exchange
Not every application protocol uses TLS. Some protocols, such as NFS and CIFS, rely on a key negotiated by the authentication protocol to sign and potentially encrypt messages. Other protocols might support TLS but not require it. As such, having the client and server agree on a session key can be useful. We accomplish this by having the client and server perform an Elliptic Curve Diffie-Hellman (ECDH) key exchange. The resulting shared secret can be used to sign and encrypt messages using the SHA-1 hash algorithm and 128-bit or 256-bit AES.
Other hash and encryption algorithms may be used without changing the base protocol; these are the ones we have defined for now, which are based on what contemporary Kerberos implementations do. A well-designed implementation should be field-upgradable to support new algorithms.
We also provide a pseudo-random function so applications that do their own encryption or integrity protection can derive a key.
Mutual authentication
Again, for applications that don’t use channel-bound TLS, it’s nice for the client to be able to authenticate the server, not just the converse. We do this by allowing the server to send back a certificate, just as it would in TLS. In this case, we actually use standard X.509/PKIX certificates, rather than Persona ones: we felt that trading architectural symmetry for the ability to re-use existing keying infrastructure was the right compromise.
Mozilla Personal
(We could also specify Persona certificates, but that would require IdPs to issue host certificates. And given IdPs are ultimately authenticated using X.509 certificates, this approach has questionable value. Its primary advantage is that it would sidestep the CA infrastructure for host authentication, as only IdPs would need to be issued X.509 certs.)
Fast re-authentication
Applications such as mail clients tend to make and tear down a lot of connections, most often concurrently. Explicitly signing in with Persona and/or performing public key operations in JavaScript would make Persona for a non-starter for these protocols. To solve this, we allow the server to return a cookie (called a “ticket”, a homage to Kerberos) which can be used to subsequently re-authenticate. Unlike web cookies, this cookie is bound to a cryptographic key, so subsequent authentications have the same degree of security as the original private key signed one. Instead of sending an assertion signed with a user’s private key, we sign the assertion using a HMAC with a key derived from the initial key exchange.
Putting it all together
An assertion for authenticating to the IMAP server on mail.example.com might look like the following:
The “ma” in the “opts” claim indicates that mutual authentication is desired. The “ecdh” claim contains the selected ECDH curve and client public key, for session key agreement. The “nonce” claim is used for mutual authentication, to bind the request and response assertions together. The remaining claims, “exp” and “aud” are identical to a Persona web assertion, except the audience contains a service principal name. (We have omitted the signature on the assertion and the user’s certificate, as these do not differ from the web use case.)
One other difference is that the server will send back its own assertion, either signed in the exchanged key or in a long-term private key. This looks something like the following:
The response assertion contains an advisory expiry time, an echoed nonce, the server’s ECDH public key, and an optional ticket for fast re-authentication.
Implementation
Protocol specifications are all very well, but it’s also important to have an implementation that will work with existing applications. Ours is available at https://github.com/PADL/gss_browserid.
The client side runs on OS X, and the server should run on any modern POSIX-compliant system that has a Kerberos library, libcurl and OpenSSL installed. Porting the client UI to other operating systems should be reasonably straightforward; the most difficult part is finding a library that can display a web browser control, and implementing a function that returns an assertion. On OS X, we use the built-in WebKit framework to accomplish this. (There is also the beginning of a Windows port that uses MSHTML, but it isn’t fully baked yet. We expect it should be complete by the end of 2013.)
Our implementation is divided into two components, libbrowserid and mech_browserid, which we discuss below.
libbrowserid
libbrowserid is a general-purpose C library for acquiring and verifying Persona assertions. You can if you wish build it without building the SASL/GSS-API mechanism; this might be useful if you want a native code local verifier. (As with all local verifiers, beware that the Persona protocol is subject to change. We’ll be tracking any changes.)
If you want a taste of how you might use this library independently of SASL/GSS-API, have a look at sample/bidget.c and sample/bidverify.c: these two short programs (~50 LOC) demonstrate respectively how to acquire and verify a Persona assertion using libbrowserid.
mech_browserid
The mech_browserid module is a plugin, built on top of libbrowserid, that allows SASL and GSS-API consuming applications to seamlessly use Persona. You’ll need to have a recent version of MIT Kerberos or Heimdal installed, as well as Cyrus SASL (if your application uses SASL). You will also need a recent version of OpenSSL with ECDH enabled, as well as libcurl; the versions that ship with OS X 10.8 work fine. (Building against the version of Heimdal that ships with OS X is difficult and not recommended.)
To build, run the “autogen.sh” script in the top-level directory, and then it’s the usual “configure” and “make” dance. You may need the –with-krb5 option to configure in order to specify where you installed Kerberos. The build/ subdirectory has some sample scripts for invoking configure, which you can tweak to suit. You will need to build with -DGSSBID_DEBUG in order for the SASL examples to work, for the reason described in #ifdef GSSBID_DEBUG on GitHub.
For example, assuming Kerberos has been installed in /usr/local, one might type:
After you’ve installed (with “make install”) you’ll need to add a line to /usr/local/etc/gss/mech that looks like the following:
Replace /usr/local in both the configuration file and library paths above with the prefix in which you installed Kerberos and mech_browserid, respectively.
Testing
You can test gss_browserid using the samples distributed with the Cyrus SASL distribution. You will need a recent version of Cyrus SASL that supports GS2 (you can tell by whether libgs2.so is installed into the sasl2 directory). If you’re not configuring mutual authentication (i.e. you haven’t generated a server certificate) then you will also need a small patch to Cyrus, which can be found in contrib/cyrus-sasl.patch. Apply that and “make install” in the plugins directory of Cyrus SASL before running the tests.
First, make sure your SASL_PATH environment variable is set to where the GS2 SASL plugin is installed. For example, if the GS2 SASL plugin is installed in /usr/local/lib/sasl2:
Start the server program below, replacing host.example.com with your canonical hostname (but not “-s host”, as that specifics the service name):
And then the client:
If it works, you should see the Persona sign-in page pop up (remember, this currently works on OS X only). After typing in your e-mail address and password, you should be able to authenticate (you will see “successful authentication” on the server side).
If you try it again, it should work without prompting, as you will have a cached ticket. You can list your tickets with the bidtool command:
To remove the ticket cache, use “bidtool tdestroy”. (Kerberos users should find these commands familiar. Other useful commands include “bidtool rlist”, to show the replay cache, and “bidtool certlist”, to show the IdP public key cache. There are similar commands to purge expired entries, and to destroy, each type of cache.)
If it doesn’t work, well: it’s true that error reporting is sub-optimal right now, and debugging can be difficult. Ensure you:
- built libbrowserid with -DGSSBID_DEBUG;
- that SASL_PATH points to a directory in which libgs2.so resides, and
- that /usr/local/etc/gss/mech (replacing path as appropriate) points to where mech_browserid.so is installed.
If you see the Persona dialog but authentication fails, make sure the hostname you specified matches the name the server is using. If you’re comfortable with a debugger, setting a breakpoint on gssBidInitSecContext can be useful. If all else fails, drop me a line or post to the dev-identity mailing list.
To keep this article short, we haven’t touched on configuring mutual authentication (or, more correctly, server authentication). Configuring this is briefly described in README.md in the top-level directory of the source distribution. gss_browserid can also do other fun things such as surface certificate attributes to applications, even if they’re embedded in a SAML assertion tunnelled inside the user’s certificate. We’ll talk about those things in a future article.
Applications
So, why would you want to use this when you can authenticate to your (for example) IMAP server using passwords, DIGEST-MD5 or Kerberos? Here are some possibilities: your webmail provider wants to standardize on Persona authentication and deprecate password-based authentication (it could happen). You work in an enterprise that requires some complex multi-factor authentication using, say, hardware tokens and client certificates: it’s relatively trivial to build a Persona IdP than a new authentication protocol, so this allows you to deploy this authentication policy with all clients that support GSS-API or SASL. (This might be particularly useful for accessing e-mail outside the firewall.)
In this example, we demonstrate how to use Persona to authenticate using the OS X Mail client. You should be warned that this is not for the faint of heart: it involves installing a plugin that fools Mail into using Persona when you ask for Kerberos authentication. (Note that this will prevent you from using Kerberos from Mail. And it is completely unsupported by Apple. But this is the Mozilla Hacks blog, right?)
First, you’ll need to setup your IMAP server to support Persona, but as long as it supports Cyrus SASL, and you’ve got the SASL examples above working on the same machine, it should “just work”. Again, make sure SASL_PATH is set correctly and the IMAP server has read/write access to its authority and replay cache files (on OS X, these will be created in ~/Library/Caches/com.padl.gss.BrowserID; on other platforms, they will be in /tmp or $XDG_RUNTIME_DIR).
You can test your IMAP SASL configuration with the cyradm tool (presuming you’re using Cyrus imapd). For example:
If there are any problems getting this to work (you don’t see the cyradm prompt with your IMAP server name), then you’ll need to troubleshoot this before proceeding. Otherwise, proceed to install the “masquerade as Kerberos” plugin, which may be found in the contrib/BrowserIDHelper directory of gss_browserid. In that directory, you can simply type “make && make install” to build and install. (To remove it, delete ~/Library/Mail/Bundles/BrowserIDHelper.mailbundle.)
You will also need to modify the application sandbox so that the gss_browserid mechanism and its configuration files can be loaded. As root, apply the patch in application.sb.patch, adjusting paths as necessary. Then, delete ~/Library/Containers/com.apple.mail/Container.plist, and start Mail.
In Preferences/Accounts/Advanced for the mail server that you wish to authenticate to with Persona, set Authentication to “Kerberos Version 5 (GSSAPI)”. This kludge is necessary because Mail is not SASL mechanism agnostic; it only supports a fixed set of mechanisms, such as GSSAPI and DIGEST-MD5.
All going to plan, you should be prompted to sign in:
There you have it.
Conclusion
It’s possible to use Persona for non-web applications today, but there’s still a way to go before it’s ready for prime time. We want to finish defining the protocol and publish it as an RFC, which in turn will require the underlying BrowserID (and JOSE) specifications to be stable. The implementation needs testing with more applications and complete ports to Linux and Windows. Applications that assume a specific set of SASL or GSS-API mechanisms need to be updated to be mechanism agnostic. Enterprise use cases will require IdPs that can bridge from Active Directory and other common authentication providers.
We look forward to seeing how Persona evolves and how it can be applied to the non-web in the coming months.
Finally, if you are planning on building your own implementation of draft-howard-gss-browserid, please get in touch directly or on the ietf-kitten mailing list.
Acknowledgments
My draft co-author, Nico Williams, provided much advice on the protocol design. The gss_browserid implementation was based on the Moonshot GSS EAP mechanism, sponsored by JANET(UK). Thanks also to Sam Hartman at Painless Security, and the identity team at Mozilla.
About Luke Howard
Luke Howard founded PADL Software in 1999. He is the author of RFC 2307 and has contributed to many open source projects including OpenLDAP, MIT Kerberos and Heimdal. He built the first commercially shipping Active Directory replacement, XAD, and has worked for both Apple and Novell. In 2013, he is working on bringing Mozilla Persona to non-web applications. He is also a composer and musician who has played on more than 50 albums and once made lunch for Brian Eno.
About Robert Nyman [Editor emeritus]
Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.