Hannes Tschofenig

I have just distributed the announcement for a workshop on Smart Object Security on the 23rd March 2012 in Paris (attached to the IETF meeting).

We are seeking input from participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.

In particular, we are interested to hear about:

• What techniques for issuing credentials have been deployed?
• What extensions are useful to make existing security protocols more suitable for smart objects?
• What type of credentials are frequently used?
• What experience has been gained when implementing and deploying application layer, transport layer, network layer, and link layer security mechanisms (or a mixture of all of them)?
• How can “clever” implementations make security protocols a better fit for constrained devices?
• Are there lessons we can learn from existing deployments?

More workshop details can be found on the webpage of our host:
http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/

If you plan to participate at the workshop please drop us a message (with a short description of what you are planning to contribute) and we can give you an early notice regarding your participation.

Category: IETF, workshop | No Comments »

Last week the IETF held their face-to-face meeting in Tapei, Taiwan and privacy was on the agenda for discussion (among many other topics, of course). As reported earlier I am involved in two meta-documents that should help others in writing about privacy properties of Internet protocols.

The first document is a terminology document: draft-hansen-privacy-terminology-03.txt

A question I typically receive is “How does this relate to other privacy terminology efforts in other organizations?” When I started with the work on draft-hansen-privacy-terminology-00.txt the most complete terminology writeup was the work by Marit Hansen and Andreas Pfitzmann, with early versions of their writeup from before 2000. I called Marit and asked her whether she and Andreas would be OK with bringing the work to the IETF after I had realized that the IETF document authors regularly write about privacy properties but they all use different terminology. draft-hansen-privacy-terminology-00.txt was more or less a translation of the most recent MS Word-based terminology writeup by Marit & Andreas. It was a lot of work to translate the long document into the IETF ASCII format.

Guess what comments I received?

• This is too long.
• This is too scientific.
• There are too many terms – nobody is going to remember them.

While the terms Marit and Andreas introduced were a great match for the academic industry the regular IETF participants needed something different. If you believe that the audience matters for any form of document and presentation then you know what I am talking about.

When providing guidelines to engineers (rather than to lawyers, which many other privacy terminology publications seem to be aiming for – although they do not state it) it is important to keep the terms and the presentation relevant to them. Sounds easy; isn’t it? It is a bit tougher when you actually have the document in a text editor in front of you.

In a step-by-step fashion I have changed the writeup of the document to what it is today – a short and concise document. Still, it is by far not yet finalized. The feedback I got during this IETF meeting showed it. While I have received a lot of positive feedback various folks noticed bugs here and there.

Let me pick two examples from my presentation to the SAAG participants.

1. Here is the definition of a pseudonym: “A pseudonym is an identifier of a subject other than one of the subject’s real names.” Sounds good but protocols do not really mandate a real name to be used to begin with. They contain a field, such as the ‘name’, but do not mandate that the text that it put in there is actually the subject’s real name. In fact, most protocols (if not all) work just fine when you put something else in there. One could argue that IETF protocols are using only pseudonyms. This is clearly an example of how the protocol engineering is different from the deployment of the finished protocol. Should we focus on other properties instead, such as the ability to protocols to mint identifiers and to recycle them?
2. In the definitions we talk about the “attacker’s perspective“. Most people felt uncomfortable with the term attack in the case when we refer to the intended communication participant. For example, when I make a call to a friend but he leaks some conversation details then it is difficult to call him an attacker. The same is true for many other user to Web service provider interactions. But how should we call these entities?

These questions and a couple of others will have to be addressed in the upcoming draft update and hopefully we will be able to re-submit it as draft-iab-privacy-terminology-00.txt (if the approval process of the IAB completes within the expected time-frame).

The second document is the privacy considerations document: draft-iab-privacy-considerations-01.txt

This document is the main deliverable of the IAB privacy program and tries to offer guidance to engineers to write privacy related text in IETF documents when designing Internet protocols. It should also offer guidance to the members of the IETF privacy directorate. This directorate is a per-invitation only group that reviews IETF specifications with a focus on privacy. These reviews are typically triggered by the IETF security area directors during the IESG review phase.

As one can imagine, it is not easy to come up with useful guidance for those engineering systems. So, we looked at what was available to us. Here is a brief summary:

1. Privacy Principles: There are lots of privacy principles published over the years. The most well-known principles are the Fair Information Practices (FIPs) but there are many others. They all make sense, sound intuitive, and great. The problem with them is that they are so high level that they do not provide a lot of guidance for engineers.
2. Then, there are Privacy Impact Assessments (PIAs). They are also useful but they focus on those who deploy and are not ideally suited for engineers who design protocols and architectures. These engineers typically try to develop more generic systems and try to create building blocks that are not only useful for one single deployment.
3. Finally, there are privacy engineering guidelines written by scientists for other scientists. Two good examples come to my mind, namely
   (a) “Engineering Privacy” by Sarah Spiekermann, and Lorrie Cranor, and (b) “Engineering Privacy by Design” by Seda Guerses, Carmela Troncoso, and Claudia Diaz. While their work is great it assumes that those who design systems are in control of every component. This may be true for some clean slate designs but certainly an assumption that does not hold true for engineers in the IETF. There, the existing deployment has to be taken into consideration and a single protocol developed just forms one piece of larger distributed system. For this reason most engineers try to aim for a more generic design rather than developing for a purpose-built system suitable only for a single task. I tried to explain this issue in more detail in my writeup for the Berlin Group and as input to the Dagstuhl Online Privacy workshop, which took place February this year.

Having provided these three examples of why we couldn’t just reference existing work a group of people in the IAB looked into the way how we dealt with privacy in IETF protocols so far (in form of privacy reviews). Have a look at these example reviews; they took some time and I believe they are fairly useful examples. Those reviews helped to form the existing privacy guidelines found in Section 4 of draft-iab-privacy-considerations-01.txt.

I had used earlier versions of the guidelines in documents I worked on and I will certainly do that again for the current draft version to see whether they require further fine-tuning. I would obviously appreciate it if someone else tries to do the same.

Independently of these two documents described in this blog post there is lots of other IETF work that deserves more privacy discussion input. I will write about that topic later.

In any case, if you have feedback on these two documents please drop a mail to the IETF privacy discussion list.

Category: IETF, Privacy, Talks | No Comments »

The National Strategy for Trust Identifies in Cyberspace (NSTIC) project effort inspired me to think about the problems with Internet and Web security and what could be done about them.  The NSTIC strategy document claims that there are three main problems, namely

• passwords usage leads to identity theft and fraud,
• customer account maintenance is a burden for businesses,
• identity proofing, and attribute assurance is expensive.
  

With these identified problems the strategy document then focuses its attention on how to get to a Web SSO solution deployed, which also causes secondary problems to arise. To deal with those trust frameworks come in the picture. Trust frameworks extend the technical components with operational and legal aspects.

In reading the strategy document I was wondering whether this is the only way to approach the problems they had outlined, and whether there are other problems that need to be addressed. On top of the identified problems, the NSTIC strategy document lists a few guiding principles and I was wondering whether I can agree with them and whether there are some missing.

With this starting point I started to talk to various Web security experts (together with my IAB colleague Andrei Robachevsky) to hear what their views are. There are some common aspects in the feedback we had gotten but there is obviously a lot of variation.

I have seen some solution specific contributions to the IETF on specific areas of the problem space during this year. For example, many folks agree that there is a problem with a non-cryptographic session management (as it is done today in HTTP with cookies). The solution ideas obviously vary a lot but I believe there is probably consensus that this needs to be fixed.  When it comes to authentication using passwords a common view is non-existent from what I can tell. Some want to get rid of passwords altogether, some others suggest to introduce Web SSO solutions that at least lower the number of passwords from the Relying Parties and push them to much fewer Identity Providers, again others are more convinced about introducing strong password based protocols, yet others see the problem in the way how passwords are used in HTML forms, then there are ideas for flexible authentication frameworks, etc. The list goes on with other aspects.

Wouldn’t it be good to have the big picture articulated and discussed by the experts in the community? Starting the work on specific solutions (in the IETF, W3C, or somewhere else) potentially in various different directions is so much easier to-do having a rough idea where to go.

Together with Mike Hanson and Sean Turner we have compiled a first draft version together.

Please have a look at it and provide your feedback.

Category: Identity Management, IETF, Security | No Comments »

A couple of privacy reviews have been conducted by the IAB during the last 6-9 months and they can be found here. Among these reviews is one on IPv6.

The purpose of these reviews was to determine what design decisions were made that had an impact to privacy and how privacy was considered during this process. The expectation was that this would help us to develop a set of recommendations.

This work lead to a new draft: draft-iab-privacy-considerations draft-iab-privacy-considerations-01.txt is now shorter  (examples got removed; background and scope description shortened) and contains new recommendations. In addition, draft-hansen-privacy-terminology was updated as well. Rhys Smith joined as a co-author and the feedback on the IETF-Privacy mailing list have been incorporated. The document is also shorter and provides a better motivation and background. It introduces a common vocabulary to talk about anonymity, unlinkability, unobservability, and pseudonymity.

If you have read previous versions of the privacy terminology or the privacy consideration document please re-read them. They both have gotten a major update!

Category: IETF, Privacy | 1 Comment »

I participate in the Future Internet Architecture (FIA) research working group created by the European Commission in May 2010. The main objective of FIA is to

define a common set of architectural design principles and a common reference architecture that can guide and unify key technologies developments

Via that group (and also through various workshops) I get exposed to different Future Internet architecture ideas. Recently, I ran into this RINA architecture proposal and looked at the slides with the title ‘Networking is IPC: A Guiding Principle to a Better Internet‘.

There, the authors complain about the [Internet] as being a “fundamentally broken architecture” and argue it is a bunch of hacks (with “no or little science”).

I was curious about what is broken. Have a look at their analysis on slide 5, 6 and 7. Slide 6 talks about addressing and routing and slide 7 about adhoc scalability and security.

I wish if authors could provide a bit more background. I fully understand that authors want to create something new without spending too much time with the past.

Anyway, I thought I should read through their paper, which could have provided more insight. Here is the paper.

Here is the analysis of today’s problems from their paper:

Today, the pure form of the Internet’s best-effort delivery model has not been able to effectively respond to new requirements (e.g., security, quality-of-service, wireless, mobility). Many individual networks in the Internet today represent commercial entities—Internet Service Providers (ISPs). An ISP may be willing to provide better than best-effort service to its customers or its peers for a price or to meet a Service Level Agreement (SLA). The lack of a structured view of how this could be accomplished has led to ad hoc solutions and so-called “layer violations” where in-network elements (e.g., routers, proxies, middleboxes) deeply inspect passing datagrams so as to perform application- or transport-specific processing.

Many papers follow the same pattern.  No analysis of today’s deployment problems immediately followed yet-another solution proposal.
[Note: In discussions I was told that I have to buy the book of the authors, which contains the analysis.]

Unfortunately, for the computer science publication industry it does not seem to beneficial to actually explore a problem in a scientific way anymore. It would take a while to figure out what the problems are with and the conclusions may potentially reveal that their new ideas don’t solve the problem either.

Hence, here is a call from my side to funding agencies to support activities that try to shed some light on real-world problems. I want those to be documented and I don’t want to hear about the author’s solutions right away.

Interestingly, some of these publications exist (although not too many of them, IMHO). For example, take a look at “An Experimental Study of Home Gateway Characteristics” or “An Untold Story of Middleboxes in Cellular Networks“.

[Note: I am not against future Internet architecture ideas. I am always excited about new ideas. I just want the authors to be honest. If they just don't care about prior work or deployment problems then they should be allowed to say that.]

Category: Internet Architecture | No Comments »

Listening to a talk at the 2nd International Conference on Mobile Internet Architecture Evolution of Post-LTE (MIRACLE 2011) conference  one of the speakers complain about 7 challenges with the Internet. In addition to these Internet problems he says that IP has not changed for such a long time. He concludes that a new, Future Internet, is needed.

Here are the challenges he observes:

1. Mobility is limited.
2. QoS is difficult to guarantee.
3. Scalability pressure.
4. Address Depletion.
5. Optimized integration insufficient.
6. Energy consumption.
7. Security weakness.

I have heard many of these talks before and so I know the story line already. I would feel so much better if presenters could make a differentiation between lack of technical work and current deployment situation. They often want to define new technical standards but the problems are actually with the deployment. As an example, if there is a problem with getting mobility protocols deployed then why should a new protocol change that? The same goes for QoS protocols, etc.

Can someone explain me the reasoning here?

Category: IETF, Internet Architecture, Talks | 1 Comment »

In a presentation by Dave Thaler he illustrated the negative effects of energy consumption of keep alive messages that have to be sent regularly to keep state at middleboxes (NATs and firewalls) alive.

He concluded that the PCP protocol will solve this issue and asks for market adoption of it.

This reminds me to the work I have done on Next Steps in Signaling (NSIS) NAT & Firewall signaling. The specification can be found here and implementations are available as well, for example from Goettingen University. A paper can be found here.

The NSIS work did not got deployed. Let’s see whether the PCP will do better…

Category: IETF | No Comments »

Tara Whalen and I recently gave a talk to the International Working Group on Data Protection in Telecommunications (IWGDPT) about IPv6 privacy. The slides are available here.

With the increasing IPv6 deployment the concerns about potential privacy problems re-surface again. In the presentation we tried to highlight two aspects:

1. It is very important to describe the threat model (and there are various aspects one can be worried about).
2. The focus on the MAC-generated IPv6 interface identifier is not the only aspect to look at when dealing with address privacy. The question of IPv6 privacy is more complicated.

I often hear IPv6 privacy concerns in Internet governance meetings and I wish that the discussions could be a bit more focused.

To provide some data about what is implemented and deployed we suggest to start a survey. The current survey proposal writeup is available here:

(It has not yet been distributed yet.)

Category: IETF, Privacy, Talks | No Comments »

Today I gave a talk at the 2nd International Conference on Mobile Internet Architecture Evolution of Post-LTE (MIRACLE 2011) workshop in Beijing, China.

Here are my slides.

In my talk I asked the audience about what can be done to help others to design Internet Protocol-based architectures. I look at the guidance that the IETF and the IAB provides in their documents and asked the audience whether those are sufficient.

I ran into that question when I recently was invited to the German Federal Ministry of Economics and Technology in their attempt to standardize a smart metering architecture. When I looked at their specification I was shocked about the lack of understanding of what is needed to come up with an interoperable specification.

The IETF standardizes building blocks as well as architectures. For me there is no doubt that more and more efforts will be started to develop Internet protocol profiles outside the IETF and it would help to give them some tools in their hands to-do their job properly.

Feedback on the slides appreciated. (I am also working on a draft on that topic.)

Category: Internet Architecture, Privacy, Security, Talks, workshop | No Comments »