Standards Corner: Preventing Pervasive Monitoring

On Wednesday night, I watched NBC’s interview of Edward Snowden. The past year has been tumultuous one in the IT security industry. There has been some amazing revelations about the activities of governments around the world; and, we have had several instances of major security bugs in key security libraries: Apple's ‘gotofail’ bug  the OpenSSL Heartbleed bug, not to mention Java’s zero day bug, and others. Snowden’s information showed the IT industry has been underestimating the need for security, and highlighted a general trend of lax use of TLS and poorly implemented security on the Internet. This did not go unnoticed in the standards community and in particular the IETF.
Last November, the IETF (Internet Engineering Task Force) met in Vancouver Canada, where the issue of “Internet Hardening” was discussed in a plenary session. Presentations were given by Bruce Schneier, Brian Carpenter,  and Stephen Farrell describing the problem, the work done so far, and potential IETF activities to address the problem pervasive monitoring. At the end of the presentation, the IETF called for consensus on the issue. If you know engineers, you know that it takes a while for a large group to arrive at a consensus and this group numbered approximately 3000. When asked if the IETF should respond to pervasive surveillance attacks? There was an overwhelming response for ‘Yes'. When it came to 'No', the room echoed in silence. This was just the first of several consensus questions that were each overwhelmingly in favour of response. This is the equivalent of a unanimous opinion for the IETF.

Since the meeting, the IETF has followed through with the recent publication of a new “best practices” document on Pervasive Monitoring (RFC 7258). This document is extremely sensitive in its approach and separates the politics of monitoring from the technical ones.

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM.

The draft goes on to further qualify what it means by “attack”, clarifying that

The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator.

The past year has shown that Internet specification authors need to put more emphasis into information security and integrity. The year also showed that specifications are not good enough. The implementations of security and protocol specifications have to be of high quality and superior testing. I’m proud to say Oracle has been a strong proponent of this, having already established its own secure coding practices.

Cross-posted from Oracle Fusion Blog.

Why You Should Care About Privacy

On April 4, at 10am Pacific, Oracle Identity Management (@OracleIDM) will be hosting a twitter conversation on privacy (#PrivQA). I am pleased to confirm that the Ontario Commissioner of Information & Privacy, Dr. Cavoukian will be joining the conversation. In particular, I would like to encourage privacy and security industry folks to participate. For more information, see our recent newsletter Q&A with links to her whitepaper on privacy by design (PbD).

Privacy is an issue that has been of concern to myself and many other industry professionals. Most of us continue to be amazed that for the most part, both users and the application developer community simply do not care. When the subject arises, eyes immediately shut with yawns soon to follow.

Yet, every day, more and more problems emerge in the industry that are leading to monetary and even physical harm. For example, financial fraud appears to be exploding fuelled by easy access to personal information available on social services. Fraudsters combine social demographic information to leverage weak classic communications media like fax and telephone to convince financial institutions to transfer funds (see Canadian Government Advisory on Social Fraud). In another case, access to private information in Google, apparently enabled hackers to compromise Mat Honan's Apple accounts, even remotely wiping out his laptop, iPad, and iPhone (Wired Article). Here, where I live in BC, there is the sad story of Amanda Todd, who was bullied to the point, she committed suicide. Was this a lack of privacy? Was there a lack of appropriate anonymity? Was this poor system design? We are only just beginning to understand how far reaching privacy issues can be.

These cases also show there are some interesting relationships between anonymity, privacy, and security that need further exploration. Do I need to be anonymous? I live an honest life, why do I need to keep my personal information private? Why should I care about anonymity? The system is secure right? Nobody asks who is the security intended for. What motivates the service providers? What damages do they face in the event of real losses? We are now discovering that while we may have the best of intentions, the fraudsters out there do not. Boring as the subject of privacy may seem, we should all be worried. We should all care.

Dr. Cavoukian's efforts to get our industry to start thinking about Privacy-by-Design are to be applauded. I'm not sure where this will go, but I'm glad this conversation has started. Remember to join in the twitter conversation on April 4 at 10AM (Twitter hashtag #PrivQA).

Originally posted on: Oracle IDM Blog.

In the News: E.U. Says It Will Overhaul Privacy Regulations

Via Kevin Moulton...

The European Commission called on Thursday for stronger protection of Internet users’ personal information, after news of data leaks at companies like Facebook and Google highlighted concerns about digital privacy.

New York Times article.

UMA and OAuth 2 - First Impressions

I recently attended a briefing by Eve Maler, chair of the UMA Workgroup. As usual, Eve had lots of info to share, and I'd like to pass it on.

First, for those of you who don't know, OAuth 2.0, is a protocol designed to allow people to authorize one web service to access the resources of another web service. For example, allowing a photo printing service to access photos on Flickr.

UMA takes the concept of OAuth a step further and places the authorization server to a third party that works on behalf of an individual. By doing this, UMA take authorization from a resource perspective, and turns it into a consent server for users. That's pretty cool. So far, we've not had a good inter-site model for handling consent.

Where in the typical OAuth 2 deployment, user authorization and resource owner authorization are combined, UMA instead separates the processing of a user's consent, from authorizing access by the resource owner (e.g. Flickr).

Aside from the benefits Eve describes, here are a couple more things I like about the UMA proposal.

1. UMA recognizes that user information exists in many places on the Internet, and not just at a single IDP/OPs etc.
2. It supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.
3. It's a great way to separate the issue of user consent away from the resource owner's access control policy.
4. It becomes possible to handle consent when individuals are offline

The only downside I can see at the moment, is that the UMA Authorization server would get to know a lot about its users. What type of organizations would/could successfully offer UMA consent services? Any organization attempting this would have to have a strong privacy brand indeed. Monetizing private information would be a tough sell. Yet would users pay for the service? Anyway, not to worry, I'm sure someone will figure this out soon, if not already.

Will this be useful to the enterprise community? As with OAuth, I think so. This is an evolving space to watch.

Social Networks and Privacy

The Canadian Privacy Commissioner recently completed an in-depth review of Facebook after receiving a wide-ranging complaint about the privacy practices and policies of Facebook.

I won't go into the details here, I suggest you read the report yourself. It is a good read and has stirred discussion both here in Canada, the US, and around the world.

Not discussed, but I think equally important is the lack of identity "proofing" in these systems. There have been all sorts of reports of celebrity impersonations and now instances of kids creating profiles of their friends or teachers (for good or bad purposes). Since there is no identity-proofing in these systems, there is nothing to stop one person from spoofing another person - except for maybe a use agreement. Nothing procedurally or technically, except the general honesty of users, protects the rights of the people being spoofed. After all, if imitating people is not allowed in the agreement, that should be enough right?

At first look,social networking sites seem benign and have huge curiosity and networking value for us as individuals. As a society, we've been tending to minimize the privacy issues, saying "social sites don't make much money, let's give them a break." But as we are learning now, social networking sites are subject to the same kinds of criminal activities as the real-world. The possibility for fraud and identity-theft remains huge. Social networking sites need to step up their game and ensure that they know who their customers really are before they can begin to get the privacy of their customers (and those who aren't customers) under control.

Talking IGF at the European Identity Conference

Felix Gaehtgens of Kuppinger Cole interviews Oracle's Dr. Prateek Mishra about IGF and its role in setting a foundation for privacy at this week's European Identity Conference.

Check out more interviews, and comments about the EIC here.

Wednesday Is Data Privacy Day

January 28, 2009 is the second annual Data Privacy Day in the United States, Canada, and 27 European countries. Oracle has worked with other major companies to help found, sponsor and participate in Data Privacy Day activities in the United States.

Read more to find out what you can do today to become more knowledgeable about privacy and to protect your own personal information.

Taking A Picture With an iPhone Leads to Unexpected Loss of Privacy

An interesting post from the blog of the Privacy Commissioner of Canada:

One Man’s Experiment With a Location-Aware Lifestyle

In the scenario described, the services used all have configurable settings about how much information to share to the public. Yet by mashing together a couple of services (iPhone & Flickr), some unanticipated consequences occurred. In this case, a reporter was able to track down a women he saw in a park simply because he observed her taking a picture with her iPhone.

For me, this shows the real challenge behind building technology that supports privacy. Society is still learning "the hard way" that when it comes to the Internet, you have to be very careful about your privacy. Even with configurable privacy settings, people may not realize the impact of linking services together.

Principles of Identity

A few days ago, Microsoft's Kim Cameron re-issued his "Laws of Identity" in a "short version" that is easier to understand. Others, including Clayton Donley, and Dave Kearns have also commented.

Here is my look at Kim's laws. You'll find my own thoughts about identity principles in bold italics below.

People using computers should be in control of giving out information about themselves, just as they are in the physical world.

This is a really great principle. But in thinking about this, it is important to remember that there are multiple scenarios. In the real physical world we aren't always in direct control about information about our identities. There are valid reasons this happens. E.g. a courier receives a shipment order from a vendor to ship goods we ordered.

This issue is, did we have the ability to provide our consent. I would re-write the expression as:

People should be able to control or consent to the sharing of information about themselves.

Notice I didn't frame this as in the electronic world vs. physical world. I am also including situations where we are not directly involved in an exchange (such as between a merchant and courier).

The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

Ok. This is good stuff. But there is a lot going on here that may lead towards information systems challenges in the future. Let me give you an example. A "birthdate" is a pretty fundamental or "raw" piece of information. Because of this, we should restrict its use. Instead of using birthdate, let's use "predicates" that ask questions about individuals. One example might be, "Is Over 18?". The predicate eliminates the need for a raw birthdate, but it now implies more liability on the particular assertion.

There may also be different reasons for creating a predicate that imply different meanings. For example, is this person an "Adult?". In this case, we have the problem of defining how the question is answered. Is it the Identity Provider that dictates whether someone is an adult? Or do the relying parties define what they mean by "Adult"? Or, does it depend on the jurisdiction of the person involved?

Clearly there is a growing mapping problem that will be exposed as we move to minimized information and away from relatively simple raw data.

Without declaration by all parties, we will continue to have mapping and interpretation problems going forwards. I would therefore contend:

Parties exchanging information must be able to agree on definitions or be able to map between definitions of identity information exchanged.

It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

This is of course a great principle. But the worst thing from a privacy perspective that I can think of is when organizations link information without the use of quality identifiers that uniquely identify us. How many people have been caught up in DHS security screenings simply because their name matches a "person of interest" or worse is only similar to someone else's name? The bigger problem by far is bad matching.

However, this is in general a very good principle. But when things are done with our consent (see above), then I wonder if this requirement disappears as an issue. What we want to do is minimize undue propagation of identifiers. I prefer Kim's original text which talks about directionality. It speaks more to the propagation issue.

So I believe the issue is not necessarily the use of identifiers. The privacy issue is inappropriate linking of identities.

We need choice in terms of who provides our identity information in different contexts.

Now I know where Kim was coming from when he wrote this. This was all about why services like MS Passport will not succeed. He was right. But the problem I have with this "law" is that it is unbalanced. Not only should users get a choice, but relying parties also get to choose from whom they will accept information. They have to be able to choose authoritative sources of information. These sources can choose to accept information directly from individuals (self-asserted), or they may choose to select third-parties they trust. An example of this is how stores choose different credit card and debit card providers. Not all store accept all cards. The online world won't different from the real world.

Relying parties need to able choose which assurance levels (quality) of information from particular authoritative sources are acceptable. This should be done in mind of the user's right to choose a provider and correspondingly, the identity provider's right to control the release of information given the user's consent preferences and their own business and liability concerns.

The system must be built so we can understand how it works, make rational decisions and protect ourselves.

I'm not so sure. I don't think people want to know how systems work. But I do agree with the principle. People should be able to make rational and informed decisions about the use of personal information whether directly or indirectly through consent preferences.

Devices through which we employ identity should offer people the same kinds of identity controls - just as car makers offer similar controls so we can all drive safely.

Consistency of experience is very important. There is a limit to what people can or want to learn. But I don't like the implication that Microsoft sales representatives make that MS has solved the problem with Cardspace. There are many more modes of communication and interaction that have yet to be covered. What happens on cell-phones. What happens when we are "offline"?

Many of these issues are already being worked on over at www.openliberty.org. Come on over and check out the IGF Project. This is where we're building an API for application developers to access identity information using a broader set of principles.

Liberty Announces First Release of IGF and IAF Specifications

Great news! Liberty Alliance announced the release the first drafts of the Identity Governance Framework and the Identity Assurance Framework.

The current IGF draft has 3 major components:

• Privacy Constraints - This document describes a small set of atomic privacy constraints based on WS-Policy that can be used in other IGF specifications. Privacy constraints are atomic constraints on the use, display, retention, storage and propagation of identity data. When combined with policy frameworks such WS-Policy, such assertions can be used to describe composite constraints on identity data.
• Client Attributes Requirements Markup Language - This document describes an XML declaration format describing identity-related data usage by an application.
• CARML Profile for Privacy Constraints - This document profiles the use of privacy constraints within CARML.

The complete specifications page for IGF can be found here. I should also point out this is just the first release of an ongoing series of specifications around identity governance. Next steps will likely include profiling of IGF in connection with various communication protocols and Attribute Authority Policy Markup Language which is currently proposed as a profile of XACML.

The Identity Assurance Framework is a new specification that defines 4 levels of assurance that can be used between federated providers to define the level of assurance or trust-worthiness of information.

The four identity assurance levels outlined in the Liberty Identity Assurance Framework are based on a comprehensive set of process and policy criteria organizations must meet to participate in IAF-based federations. The IAF details authentication requirements to allow federation operators and federating organizations to address cross-industry business, policy and privacy requirements related to applications and services built using any federation protocol and falling into each identity assurance level. The first version of the Liberty Alliance Identity Assurance Framework released today is available for download.

For those of you wondering at this point, do these specifications represent new protocols? The answer is no. These specifications are really information-level policy declarations describing how and when to use identity-related information and its level of assurance. These declarations are intended to be used with any protocol system used to exchange information whether it be LDAP, ID-WSF, or WS-*. The diagram below should help show the relationship between IAF, IGF, and the various Identity protocols.

Many thanks to my fellow colleagues at Liberty Alliance who worked so hard to provide their input and contributions to these specifications. Without such excellent attention, this work would not have been possible!

Sometimes Fake Identities Are Well....Just Too Fake!

Techdirt comments that "If you're going to put up fake grassroots videos on youtube, shouldn't you at least pretend to be real people?"

I absolutely love this! I always here from people about how our right to privacy should be tied to our ability to fake an identity. However this article shows how not even trying to make it believable can backfire! Excuse me, is that Mr. or Ms. Asdfjkl?

The Identity Network

It seems that as time passes, there are going to be more and more web services that can provide information about ourselves such as who we are, and what our reputation is. We've moved from relatively simple enterprise identity systems where data was held in a corporate directory towards multiple networks of identity information networks where we provide information about ourselves with the different business service providers we make contact with. In turn, those businesses may start communicating about us on our behalf or for other business reasons. Lot's of issues to be worried about.

It is interesting that the debate around enterprise identity is still going on. Firstly, the post from Jackson Shaw that started some recent discussion on meta-directory and virtual-directory all off: You won't have me to kick around anymore! Which was promptly responded to by Jackson's former Zoomit colleague and identity guru at Microsoft, Kim Cameron: Metadirectory and claims. A discussion then ensued between Dave Kearns, and Kim. My colleague, Nishant Kaushik jumped in with "Virtual Directories + Provisioning = No More MetaDirectory".

Now it seems that in addition to having simple sources of identity information that can make assertions about who we are, or about how good we are - where we are is now going to become possible. Paul Madsen blogs about IGF and Yahoo! FireEagle. This is exciting stuff indeed. But scary too!

We are headed to a far more sophisticated, social concept of identity that spans many more boundaries that the olds days of the corporate e-mail system from which LDAP evolved. But not to worry, we've seen this before with the evolution of the Internet itself evolved based on layered architecture from forerunners like OSI, DECnet, IPX, SNA and others and evolved through multi-protocol routers and eventually evolved or migrated into TCP/IP. Just like we had silos of networks, we have silos of identities spring up all over the place. Suddenly all the complexity of inter-networking simplified into the web we have today.

I believe the Identity Inter-Network (or just plain Identity Network) is going to emerge as a set of abstracting layers that securely link the different sources of identity information with the applications that need and should have access providing we as users agree to it. Kim Cameron has already made a lot of observations about how the Identity Network should function. I'm betting there will be a few more observations to be made. But the important question isn't about which silo I choose to put my data into. The big question at this point is, "What are the equivalent OSI Layers of the Identity Network?" I'm pretty sure there are the communication protocols and transport protocols (LDAP, SAML, ID-WSF, WS-Fed), but what about discovery, routing, transformation/mapping, governance/policy (IGF), and assurance (IAF)? What other layers are needed or are going to emerge?

2 Articles on Why Liberty's IGF Is So Important

In the last couple of days, 2 blogs posts came to my attention that may be of interest.

The first is from Felix Gaehtgens of Kuppinger Cole. Felix talks about why IGF is becoming more important in today's increasingly global society...

[...] For a starter, many enterprises still have private identity data stored in many different data stores. Even though the trend is to minimise the number of “data silos” (places where identity data is stored), the reality is still that data can be found in many places. This creates a problem in our globalising society, where the HR department might be run in one country, and the support desk in another, and a myriad of services being outsourced yet to other locations. How can one ensure that the flow of data is controlled in such a way to ensure that all privacy laws are being complied with? Another example could be a federated environment of several suppliers working together in order to process an order. The order is received by company A, which then sends out several orders for parts to companies B1, B2 and B3, who then ship everything to company C that assembles everything and uses company D to ship out the finalised order to the customer.

Felix goes on to accurately describe CARML and AAPML and concludes:

So why another set of protocols? Isn’t this already addressed in some other standards? Liberty’s ID-WSF springs to mind, or SAML 2.0’s AttributeQuery, SPML, or even - to a certain extent - WS-Trusts Security Token Service. However, CARML and AAPML bridge a very important gap that is not addressed anywhere else: not how to request and receive attributes, but to express the need and purpose of identity data, and on the other side the allowed use and conditions for its consumption. IGF’s framework conceptually fits seamlessly into architectures harnessing today’s frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust, leave off.

The second bog post is from Sajjad, who writes:

IGF's framework conceptually fits seamlessly into architectures harnessing today's
frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust,
leave off.

I like to put sum it up this way - most of today's protocols deal with the "how" and "what" information should be transferred - the technical mechanisms for transferring information. For this, there are indeed many mechanisms each stressing different security objectives. IGF's role is to really talk about the "why", "when", "where", and for "whom" information should be consumed, shared, used, and updated.

SOX Compliance Journal: Identity Governance Framework

An article written by myself and Marco Casassa Mont of HP on Liberty Alliance's IGF initiative addressing privacy and SOX is featured in Sarbanes-Oxley Compliance Journal.

This article is a good introduction to the problems of privacy and compliance as it relates to personal information and how IGF is intended to make the compliance of applications and the businesses that deploy them much easier to achieve.

Enjoy

Canadian Privacy Commissioner's Annual Report

Yesterday, the Canadian Privacy Commissioner released Canada's Annual Report on the Privacy Act.

I'm looking forward to reading this report. But from the press release, it seems Canadians are becoming more concerned about the amount of information being exchanged with other countries...

Increasingly, Canadians’ personal information is being exchanged with law enforcement and security agencies in other countries. The government has claimed that this transborder flow of information will improve transportation safety and enhance our national security.
“We are particularly concerned about the number of travel-related security programs that have been put in place,” says Commissioner Stoddart. [...]

The increased collection of personal information under these programs increases the risk that Canadians will be the victims of inappropriate data matching, intrusive data mining, or the unintended consequences of the disclosure of personal information. This increases the risk of surveillance, rendition and unwarranted attention from law and security enforcement both at home and abroad.

In addition to these important security demands, the release also goes on to point out that the privacy act was written in 1982, when the Commordore 64 was the latest computer.

The Privacy Act, unfortunately, is not equipped to deal with the pressures imposed by tremendous technological change. In fact, Canada’s private sector privacy law, the Personal Information Protection and Electronic Documents Act, provides more protection for Canadians.

Interesting stuff indeed. I would also observe that along with technological change, the public is becoming much more educated about identity and the Internet. It is not surprising that as the public has become more educated, their privacy expectations and concerns are also rising.