The EU funded project PrimeLife has just made one of their first deliverable available on their webpage. PrimeLife tries to bring sustainable privacy and identity management to future networks and services.
First Report on Standardisation and Interoperability - Overview and
Analysis of Open Source Initiatives
http://www.primelife.eu/images/stories/deliverables/d3.3.1_d3.4.1-public.pdf
Scope of the deliverable:
This deliverable aims at giving an overview of standardisation and open source initiatives that are relevant for PrimeLife. It decribes the state of work there as well as possible and actual cooperations.
From the PLING Wiki:
The joint PLING & PrimeLife F2F meeting will enable an opportunity to discuss the work of the IG to date and to set directions and priorities for future work in conjunction with the PrimeLife Project members. Being part of TPAC week will also allow interactions from other W3C Groups.
Here is the main page for the PLING group:
http://www.w3.org/Policy/pling/
Here is their Wiki:
http://www.w3.org/Policy/pling/wiki/Main_Page
Here is a pointer to their workshop:
http://www.w3.org/Policy/pling/wiki/TPAC2008
We now have a web page up for this upcoming MIT Communications Futures Program workshop (http://cfp.mit.edu/events/oct08/Call-for-participation-privsec-oct-08-workshop.shtml), to take place at The Stata Center at MIT on October 21-22. The page includes an introduction to the workshop, a draft agenda, and a pointer to the registration and lodging pages.
Pictures and slides are now available for the 1st IEEE Key Management Summit. For the recordings you still have to wait…
Henning recently posted a very interesting mail to the IETF mailing list about a new mailing list:
RECIPE (Reducing Energy Consumption with Internet ProtocolsExploration). Based on some very preliminary discussions in Dublin, I’ve set up a new discussion list to talk about the intersection of Internet protocols and energy management. The goal is NOT how to make protocols, routers or servers more energy-efficient, but rather how to use Internet (application) protocols to better manage energy consumers and (local) producers. There has been a fair amount of work in this area, but mostly focused on lower layers, such as ZigBee. The initial goal of the discussion is to identify whether there is a need for work here or not. I’m also in discussion with a major local utility. The discussion will take place at recipe@ietf.org, with subscription details at https://www.ietf.org/mailman/listinfo/recipe A bit more detail is below: In the next few years, the demands on the electric grid will change substantially. New power sources, such as wind and solar, delivery varying amounts of power based on the time of day, while new consumers, such as plug-in hybrids, impose additional demands. Local generators, such as small-scale solar and wind turbines, can produce additional energy. Grid control can better match energy supply and demand, and flatten peak usage by deferring non-time-critical demands to low-usage times. For example, an office building can use low-cost off-peak energy to produce ice, which is then melted during the day to provide air conditioning. In the home, dishwashers and washing machines can defer their operation. There has even been discussion of using plug-in hybrids as energy storage devices that charge their batteries at night and release energy to the power grid during the peak usage periods. In addition, end users need to be able to determine easily what devices are consuming how much energy. For example, energy monitoring may alert a homeowner that a hot water pipe is leaking or that an AC air vent has been disconnected. All of these new usages demand a much smarter grid that interacts with power consumers and producers at the edges of the grid. With near- universal broadband and wireless data network deployments, this is becoming quite feasible. Given the diversity of consumer and industrial products that need to be controlled, we need standardized, light-weight protocols that can provide core control functions. We envision at least three core functions related to energy control: (1) A device should be able to query a grid controller to get permission to start operation. It would obtain a time-of-day when the device should start operation (or ask again). The query may indicate a “class-of-service”, such as off-peak tariff. (2) The grid controller may ask a household or company to reduce its energy consumption to a certain level for load management during peak power periods. The household or company would then shut down non- essential consumers or defer energy-consuming tasks, such as hot-water heating or vehicle charging. (3) A controller can ask a device about its power usage or total energy consumption. Particularly for the first two cases, devices need to be able to discover their energy controller, since different consumers within the same region may use different distribution or energy management companies. Particularly for the second case of grid-controlled devices, strong authentication is needed to prevent malicious or accidental shutdown of electrical systems.
A number of emergency services experts are meeting to discuss ongoing work on IP-based emergency services in Vienna, Austria on 21st to 23rd October 2008. The first workshop day is focusing on tutorials to help those interested in the classical 1-1-2 emergency call to get up-to-speed with architectures and standards developed for next generation emergency calling. During the second day various recent activities of standardization organizations around the world will be presented. The third workshop day is dedicated to early warning standardization efforts and the outlook to future emergency services activities.
Participation from those working in standardization organizations as well as persons with interest into the subject is highly appreciated.
For socializing an evening program has been organized.
More information about the workshop can be found behind the following link:
http://www.emergency-services-coordination.info/esw5.html
This page also points to previous workshops that took place in New York, Washington, Brussels and Atlanta.
The IEEE Key Management Summit brings together the top companies that develop cryptographic key management for storage devices with the standards organizations that make interoperability possible and the customers that rely on key management to secure their encrypted data.
With recent legislation, such as California’s SB 1386 or Sarbanes-Oxley, companies now have to publicly disclose when they lose unencrypted personal data. To meet this new need for encryption, many companies have developed solutions that encrypt data on hard disks and tape cartridges. The problem is that these data storage vendors need a solution for managing the cryptographic keys that protect the encrypted data.
This summit aims to provide clarity to the key management by showing how existing products and standards organizations address the problem of interoperability and security.
KMS 2008 is co-located with the IEEE Mass Storage and Systems Technologies conference (MSST) in Baltimore, Maryland on September 23-24, 2008.
The agenda for the two workshop days can be found here and here.
See more details at http://www.keymanagementsummit.com/2008/
I am a member fo the program committee.
Henning Schulzrinne gave an interesting presentation about the cost of bandwidth as a contribution to the ongoing discussion about P2P traffic “optimization”. This BOF was an outcome of the workshop in New York in May this year.
Jari Arkko just recently published an interesting draft on the subject of incentives. Here is the abstract:
Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to-peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution.
More details about the next emergency services workshop that will take place in Vienna in October (21st - 23rd) are available.
We hope to see you there!
In a recent mail a CAP implementers workshop was announced. Here is the text from the mail:
The Common Alerting Protocol (CAP), an OASIS standard adopted as ITU Recommendation X.1303, is the foundation standard for all-media public warning. Designed as an all-hazards alert format, CAP is being
implemented worldwide for earthquakes, public health, and many other emergencies, in addition to weather events.
Details:
This Workshop is planned for 9-10 December 2008 at the WMO (World Meteorological Organization) in Geneva, in cooperation with OASIS and ITU. It will be primarily a forum for discussions among CAP implementers and ICT or emergency management organizations on topics requiring coordination. These topics may include, among others: having an internationally agreed list of authorities for common types of CAP alerts; disseminating, aggregating, and authenticating CAP alerts; making globally unique identifiers for CAP alerts; and, best practices for text in the CAP “description” and “instruction” elements.
You may be aware that this Workshop follows on the October 2006 “Workshop and Demonstration of Advances in ICT Standards for Public Warning” held at ITU in Geneva, see http://www.itu.int/ITU-T/worksem/ictspw and http://www.oasis-open.org/events/ITU-T-OASISWorkshop2006/proceedings.php
Since that 2006 Workshop, there have been notable developments
including:
- The ITU-D (ITU Development sector) approved guidance for developing nations on CAP implementation
- OASIS established its Emergency Management Member Section to accelerate implementation of CAP and allied emergency data exchange standards
- The U.S. FCC (Federal Communications Commission) issued an order requiring use of CAP
- The WMO SWIC (Severe Weather Information Centre) began work on CAP warnings of Tropical Cyclones
- The U.S. National Weather Service (NWS) continued improving its CAP messages and developing its Next Generation Warning Tool
- The Weather Channel underscored to NWS the need to institute CAP
- The U.S. Environmental Protection Agency began developing CAP alerts for air quality warnings
- The Earth Observations Summit highlighted CAP implementation as a major achievement
- Canada and the U.S. coordinated on implementation of their respective CAP-based alerting systems
- EUMETNET began exploring how to adapt METEOALARM to support CAP.
We are glad to announce that the next emergency services workshop is going to take place in Vienna, Austria, from the 21st to the 23rd October 2008. Frequentis is going to host the workshop. Up-to-date information will be available on the ESW webpage.
We are always late with our work on the t-shirts for the emergency services workshop. Now, we are about to finish the design for the workshop in Atlanta that took place last April. Here is the design Richard Barnes came up with:
Pictures from the workshop are also available here.
Bruce Lowekamp posted a mail to the BEHAVE list announcing FlexNES. FlexNES is a tool for a Linux router that allows the emulation of different NAT behaviors. It works by using iptables to filter packets and pass them through a user-level application that performs the NAT behavior before passing them back through iptables. It currently is limited to UDP (its goal was to reproduce all of the different good and bad behaviors in 4787), but the general architecture should be extensible to other protocols.
FlexNES is available under the GPLv2 license. Jeremey Beker wrote the software as his MS project for the College of William and Mary CS Department. I was his advisor for the project.
FlexNES is available at
http://code.google.com/p/flexnes/
Here is a really nice slide set that explains the attack and the consequences.
Thank you Thomas for sending me the pointer.
Looking for some old GEOPRIV mail regarding the design decisions we made for HELD I ran into this interesting post by James Snell’s blog. Lisa posted the link in response to my question of what WSDL is actually good for. James writes:
“Those who are familiar with my history with IBM should know that I was
once a *major* proponent of the WS-* approach. I was one of the original
members of the IBM Emerging Technologies Toolkit team, I wrote so many
articles on the subject during my first year with IBM that I was able to
pay a down payment on my house without touching a dime of savings or
regular paycheck, and I was involved in most of the internal efforts to
design and prototype nearly all of the WS-* specifications. However,
over the last two years I haven’t written a single line of code that has
anything to do with WS-*. The reason for this change is simple: when I
was working on WS-*, I never once worked on an application that solved a
real business need. Everything I wrote back then were demos. Now that
I’m working for IBM’s WebAhead group, building and supporting
applications that are being used by tens of thousands of my fellow
IBMers, I haven’t come across a single use case where WS-* would be a
suitable fit.”
I have mixed feelings when I think about my past work on designing protocol that ship around XML on top of HTTP. There are three issues where I could never receive good recommendations:
- What URI scheme should I select? Use http: & https: or define something new
- Should I define new ports? Use port 80 or allocate a separate port.
- How should errors that happen as part of the application be treated? 200 OK (with error indication at the higher layer) or something else.
Even the choice of the XML language is not so trivial either, see a previous post.
Today, Pasi distributed a mail about the liaison statement from ITU-T SG 17 on X.1034 (”Guideline on extensible authentication protocol based authentication and key management in a data communication network”). The liaison which was briefly discussed in SAAG and EMU meetings, is now available here:
https://datatracker.ietf.org/liaison/466/
After years of work the LoST specifcation (and the DHCP-based discovery of a LoST server) has been published as RFC 5222 (and RFC 5223). The abstract of the LoST specification says:
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
Now, we have to finish our remaining working group items, in particular the framework and the so-called “Phone BCP” document.
A topic for discussion at the IETF#72 week was also the recently announced DNS cache poisoning attack. The attack was demonstrated live during the DNSEXT session and took only a few seconds to complete. There are various solutions (see this presentation and this one) to deal with the attack but the threat is very real and significant. A long term solution is DNS security.
I do not know to what degree the details of the attack are known already. Hence, I should not describe the details here.
In June 2008 the GEOPRIV chair, Robert Sparks, organized an interim meeting in Dallas. I took some picture and you can find them here. I also created an audio recording of the meeting. I hope to make it available as well.
We used the Dublin IETF meeting again for our experiments. We met on Saturday before the IETF meeting started to get everything setup and todo interop testing. Then, we used our setup during the IETF week. Richard distributed a mail about the scope of the work and a more complete description is available here.
Henning also posted a mail about their experiments with LoST about non-emergency services applications.
These are the things we took a look at:
- Obtaining location information using HELD
- ECRIT emergency calling (including LoST)
- Location-enhanced Jabber presence
- LoST-based discovery of nearby points of interest (non-emergency services usage of LoST)
I spent the Saturday working on the LoST implementation. We had 2 LoST servers, one from Henning and another one developed by University of Krakow. I ran into a problem that took me quite some time to fix: The LoST server used a Postgres database and we had to put real service boundaries for Dublin and Ireland into the LoST database to ensure that reasonable results are returned. Loading the database with the correct geodetic format (essentially with the service boundaries for the region) wasn’t so easy as there are far too many ways to encode location information. The emergency call itself worked fine when we used the “PSAP” written by Karl Heinz — his implemented implemented multipart MIME but my N810 Gizmo SIP client didn’t.
At IETF#71 a BOF about Reducing Unwanted Communications in SIP took place. While the BOF to form an RFC 5111 Exploratory Group went fine the subsequent charter discussions did not lead to anything. Consequently, there was no group formed and no face-to-face meeting was scheduled for IETF#72.
Hence, a few of us, namely Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS charter.
Jonathan, Henning and I came up with a first text proposal based on the discussion we had during the meeting. Please find the first charter text here.
Before the IETF#72 meeting a few of us had a phone conference call to agree on the main points for the presentation that John Elwell later gave. Everything looked roughly OK (whatever that means in context of this topic that has stalled the SIP mailing list for a long time).
Anyway, John gave his presentation and the disagreement surfaced again. I suspect that meeting minutes are going to capture some of the discussions; they are not yet available. In short, it was a disaster. There does not seem to be a good understanding of the problem and how any solution could improve things. Folks gave up on fixing E.164 & SIP Identity related issues some time ago already.
For me it is rather unclear what is going to happen next. Maybe it is time to re-think the entire subject again…
Paul Hoffman gave an interesting talk at the SAAG meeting about SSL VPNs. I took away three things:
- Consider the user in the design. Many IPsec/IKE based VPNs are just far too difficult to configure.
- Try to develop things that can be done without standardization efforts. For many of the SSL vendors there does not seem to be a need to standardize their protocol; the client and the server come from the same vendor.
- There is very little for the IETF todo in terms of standardization work.
Paul also points to a couple of challenges
There was an interesting presentation at the SAAG meeting about a standard developed within the Trusted Computing Group (TCG) . The slide set describes the IF-MAP protocol to obtain information from different network components.
Paul Hoffman sent a mail to the SAAG mailing list and is asking for a review of a NIST document on firewalls. Here is the info he provided:
Draft SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy, provides recommendations on developing firewall policies and on selecting, configuring, testing, deploying, and managing firewalls. The publication covers a number of firewall technologies, including packet filtering, stateful inspection, application-proxy gateways, host-based, and personal firewalls. SP 800-41 Revision 1 updates the original publication, which was released in 2002. NIST requests comments on draft SP 800-41 Revision 1 by August 15, 2008. Please submit comments to 800-41comments@nist.gov with “Comments SP 800-41″ in the subject line.
URL: http://csrc.nist.gov/publications/PubsDrafts.html#800-41-Rev1
