Hannes Tschofenig

The Networking 2009 conference took place from the 11th to the 15th May 2009 in Aachen, Germany. Attached to the conference were a couple of workshops; the 2nd International Workshop on Mobile and Wireless Networks Security (MWNS’09) was one of them. I had the honor to give the keynote speech about “Mobility and Security: The Tussles Continue”. I have chosen this title because I noticed a fairly huge gap between what is standardized and what finds it way into deployment and the gap from research to deploy in the area of mobility is almost insane. So, I was wondering what the value of a lot of standardization & research efforts are (other than being nice on paper, which is already suffient for a lot of people).

I produced a slide set that went through some of the mobility protocols and asked around what the deployment situation is (unless I knew it already). Mobility is particularly interesting because a lot of the folks working on this topic have a good understanding of network layer protocols although only certain application layer protocols benefit from it. Unfortunately, persons with knowledge of network layer protocols AND application layer protocols are hard to find and one of the favorite applications, namely voice-over-IP, is also a fairly complex beast from a business and regulatory point of view (as I had to learn with my involvement in IP-based emergency service).

Anyway, here is the slide set:

When you click through the slides you will notice that I don’t see a bright future for HIP and MIP. My main argument is that the incentives are not right. Now, you would probably wonder why I contribute to these protocols. Well, I think that they are technically a good idea. I still hope that Dual Stack Mobile IPv6 will see some deployment IFF some of the protocol design bugs are fixed, namely

1. Mobile Node to Home Agent Security needs to be much less complex to implement.
2. Route Optimization has to work in the current Internet (i.e., one that is full of middleboxes).

If these two aspects cannot be fixed for MIPv6 then I don’t see a reason why someone would even think about deploying it. (Please note that my thinking about Proxy Mobile IP is significantly different because the deployment incentives are easier to understand for those who are in the position to deploy it. It is, however, less interesting for researchers…).

It would be interesting to get your feedback to my slide set.

 Loading ...

Jari Arkko provided a nice summary of some of the BOFs that have been proposed for the Stockholm IETF meeting in July:

Multipath-TCP: I have already approved this BOF, but we do need more feedback on how it should be run, scoped, etc.

Multimob: I suspect we have not made real progress since the last BOF.
There is some energy though. I’m open to suggestions on what we should do here.

Netext: I would like to run the second slot of NETEXT as a real BOF (including possibly getting new chairs). I think we need some serious architectural guidance here as well. The various sides of the argument are too deep in their positions to be very constructive in discussion.
How can we best get an impartial analysis, the architectural guidance, and a civil discussion?

Eapfix: This is about Glen Zorn’s belief that a number of EAP documents have severe problems, and he wants to fix them. However, there is no document detailing what the problems are, no mailing list, etc. No BOF should be held for this, but the ADs need to work with Glen on determining if there’s something to do, and if so, is there energy to do it. I think the next step is that Glen writes a clear document on what the problems are, otherwise this is a non-starter.

More information can be found on the IETF BOF page.

What is this about?

At IETF#74 (”San Francisco”) a BOF was held discussing potential work on early warning in the IETF known as “Authority-to-Citizen (ATOCA)”. The BOF went well and there was a lot of interest to start some work. Soon after the BOF discussions around the charter text started, see here. It appears that the scope of the work needs to be hashed out a bit more in order to complete the charter text.

I proposed a few suggestions regarding the scope and to depricate the term “authority” given that there are a lot of emotions attached to it with little added technical content.

Where are the slides from the IETF ATOCA meeting?

Good question. The chairs have never uploaded them. Here are they:

Here you can also download them.

Where do the discussions take place?

The discussion is taking place on this list: https://www1.ietf.org/mailman/listinfo/earlywarning

Subscribe to it, get involved and state your opinion.

Where can I find some of the discussed documents?

There are essentially 2 documents that are relevant for this discussion, namely

1. Requirements, Terminology and Architecture
2. SIP Event Package for the Common Alerting Protocol (CAP)

Document (1) will be updated based on the terminology also used in the Internet Email architecture.

I like coffee; no secret. Jouni Korhonen sent me a nice picture that I would like to share with you:

 Loading ...

Jason Livingood sent around a proposal for a BOF in Stockholm. Here is what he wrote:

This is an open call for participation in the new “homegate” mailing list, which is dedicated to discussing issues relating to broadband home gateway devices.  There has been a BoF request submitted relating to this, which you can find at here.

This work is centered on three key themes:

(1) work to improve the network experience a home user gets,

(2) work to keep home networks secure, and

(3) work to bring new functionality to home users.  You can find many more details in the PDF document that is referred to above.

If this topic is of interest to you, please join our new mailing list at https://www.ietf.org/mailman/listinfo/homegate.  One of our first discussions for the mailing list will be to discuss a problem statement, work on a possible draft charter, and more.

Jari Arkko just sent around this mail:

Here’s another BOF proposal for Stockholm. Its a transport area BOF, but I have promised to help Magnus and Lars on this case, given that Lars is one of the proponents and Magnus will be on vacation for much of the time before the IETF. All the material should be available from

http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp

And the primary specification is

http://tools.ietf.org/html/draft-ford-mptcp-multiaddressed-00

This is a design that comes out of a research project called Trilogy (UCL, UC3M, Nokia etc). It has also been one of the models discussed in the RRG. The basic idea is that you can do multihoming at the TCP layer so that a host can employ all available paths simultaneously. Different paths are chosen through the use of different source/destination addresses or interfaces. The model has some nice theoretical properties, such as the ability to use network capacity to its maximum. It also has a number of nice practical properties. For instance, I believe the protocols can be constructed so that each separate flow looks like its own TCP session to an on-path firewall. And I don’t think applications are impacted. But the proposal also shares some of the properties that Shim6 was criticized for. For instance, it requires host changes, network management becomes complicated if multiple prefixes are needed, etc. However, it does solve a number of problems that Shim6 had. In particular, the transport layer feels like the right architectural place in the stack, given that it is aware of the throughput, packet loss, etc.

Other background information: They are asking for a experimental RFCs and a place to work out the protocol details in the IETF. This would be very much like the Lisp WG. There are two existing implementations and at least one other coming up.

Some of the issues about this effort include:

1) There are some variations of the protocol design. I think these can largely be left for the WG to work out; in the BOF I’m more interested in clarity about the big picture than detailed fights about protocol variants… but we may need discussions with the proponents on what gets presented.

2) The SCTP folk have expressed interest that the BOF should be scoped to look at the use of multiple paths in any transport protocol (SCTP and TCP at least). My current thinking is that it would be better to concentrate on TCP only. Its the practical, deployable extension that we could develop. The BOF should focus on the question of whether this should be done or not.

3) If the community agrees the work should be done, where should it happen (new WG, TCPM, etc)? Perhaps we can postpone this discussion for later, but for now its clear that we’re at least not going forward without a public BOF process.

4) How serious are the remaining Shim6-like issues? (E.g., inability of network providers to control this multihoming or sudden changes of addresses underneath, affecting, e.g., IPsec policy)

5) There are no commercial vendors who have expressed interest to implement this in their products, at least not yet.

6) Some other things that I can’t think of right now — I am very familiar with the background of this effort, but I have not time to read up on the mailing list or drafts yet… feel free to add to the list.

My thinking at the moment is that we should at least have the BOF. We can tell more after the meeting. Thoughts? Comments?

Ian Jacobs distributed a mail about planned W3C working groups:

Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the  Device APIs and Policy Working Group: http://www.w3.org/2009/05/DeviceAPICharter

As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period.

W3C invites public comments through 2009-06-25 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/

Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments.

If you should have any questions or need further information, please contact Dominique Hazaël-Massieux, Mobile Web Initiative Activity Lead <dom@w3.org>.

[0] http://www.w3.org/2007/uwa/
[1]
http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation
[2] http://www.w3.org/Consortium/Member/List

A new IETF working group has been formed in the Real-time Applications and Infrastructure Area.  For additional information, please contact the Area Directors or the WG Chairs.

Extensible Messaging and Presence Protocol (xmpp)

Current Status: Active Working Group

Last Modified: 2009-05-29

Chair(s):

Joe Hildebrand <jhildebr@cisco.com>
Sean Turner <turners@ieca.com>

Real-time Applications and Infrastructure Area Director(s):

Robert Sparks <rjsparks@nostrum.com>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:

Robert Sparks <rjsparks@nostrum.com>

Mailing Lists:

General Discussion: xmpp@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp
Archive: http://www.ietf.org/mail-archive/web/xmpp/

Description of Working Group:

The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923.

Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard.

Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented.
A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies.

XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups.

Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed.

In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group’s technical objectives and the group clearly documents the reasons for making them.

Goals and Milestones:

Mar 2010 Decide upon a direction for server-to-server connection reuse.
Aug 2010 Deliver rfc3920bis and rfc3921bis to the IESG.
Dec 2010 Decide upon a direction for end-to-end encryption.
Jan 2011 Define a framework for SIP-XMPP interworking.
Feb 2011 Define a solution for server-to-server connection reuse.
Aug 2011 Define a solution for end-to-end encryption.

NIST has posted a preliminary agenda for their Key Management Workshop (June 8-9, 2009 in Gaithersburg, VA). You can download it here:
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Preliminary_Agenda_KMWshop.pdf

I have mentioned this workshop already in a previous blog post. As a short-cut, the main web page for the workshop can be found here: http://csrc.nist.gov/groups/ST/key_mgmt/

This Call For Paper might be of interest to those working in the security/identity management space:

The Internet Society is sponsoring a research paper on Trust and Identity in connection with the 2010 Network and Distributed System Security Symposium (NDSS’10) in San Diego. Lucy Lynch suggested to me that this might be of interest to you and colleagues of yours in connection with the work of the IRTF and/or the GENI project.

NDSS issues Call for Papers: Trust and Identity among topics solicited

The 2010 Network and Distributed System Security Symposium (NDSS’10) Call for Papers is now open. The Program Committee is seeking submissions for papers and panels on a wide range of network and distributed system security topics.

This year, the Internet Society (ISOC) is sponsoring a paper on Trust and Identity to address current problems in on-line identity management. ISOC will cover travel, registration, and hotel costs for the designated author to attend NDSS’10, present the paper and receive a USD 500 cash award.

NDSS’10 will be held in San Diego, California, 28 February – 3 March at the Dana on Mission Bay. The deadline for submission of titles and abstracts is Friday, 11 September 2009. The deadline for full paper and panel submissions is Friday, 18 September 2009.

Visit the NDSS’10 website for submission guidelines and other details: http://www.isoc.org/isoc/conferences/ndss/10/

For those who are interested in fair usage policies, QoS and net neutrality this activity could be of relevance for you. Bob Briscoe posted mails to various IETF lists about a potential  BoF or Bar BoF:

I’d like to launch a concrete protocol-specification activity on congestion exposure (with re-ECN as a candidate solution) in Stockholm? Here at the ICCRG in Tokyo, we’ve just agreed that this doesn’t conflict with the new IRTF ICCRG  design team in this space or prejudge any consensus on direction (see background below). The question is purely about timing…

I’m finding that re-ECN seems to feature somewhere in the plans of those expressing an opinion in the ICCRG discussions. My concern: the protocol that will take longest needs to be finished soonest. E.g.
ECN took 7 years from first research paper to proposed standard.

Therefore, I’d like to propose we get started on a specific protocol specification activity, in parallel to the ICCRG design team. We have to set this up so it doesn’t imply it is the *official and only* way forward. But it’s a good punt to be starting on.

My questions are:

• Do you think discussions should start on building a BoF on “Congestion Exposure” in Stockholm (getting late but still do-able)?
• Or less ambitiously should we arrange another ad hoc BoF (bar BoF) in Stockholm, building on ICCRG work in Tokyo this week, to get a community together to form a BoF later?
• Or do people actively oppose anyone doing anything yet on congestion exposure or re-ECN in the IETF or IRTF?

Background on TCP-unfriendly and on re-ECN

You may be aware that, in San Francisco we had discussions in TSVArea (prompted by Matt Mathis’s talk) on whether to move beyond TCP-friendliness as a comprehensive direction for both sharing Internet capacity and future congestion controls. In the IRTF ICCRG the same week it was decided to set up a design team to work on the way forward and propose it in an informational RFC – Matt Mathis has kicked off a first shot <draft-mathis-iccrg-unfriendly-00.txt>. We just had the launch meeting of that design team at the ICCRG here in Tokyo.

Re-ECN is a change to IP to make congestion as transparent to the network as it is to the endpoints (hence congestion exposure). Then:

1. i) causes of excessive congestion can be kept in check if ISPs choose – but at the bulk packet level like the Internet architecture should be – agnostic to behaviour of individual flows;
2. ii) and ISPs that under-provision can be held to account as well. (see the end for the status of re-ECN).

Re-ECN status

We’ve been keeping a draft spinning on this proposed change to IP since 2005. It’s still an individual contribution waiting for the right time.
<draft-briscoe-tsvwg-re-ecn-tcp-07>
<draft-briscoe-tsvwg-re-ecn-tcp-motivation-00>

When we first presented it and had subsequent ad hoc BoFs, the idea fell on stony ground. I think because back then few could see the limitations of TCP-friendly. Even if you still think there’s something in TCP-friendly, it was apparent from the lack of any hum it received in SF that we at least need something wider.

It seems re-ECN is one of those things people want someone else to have already done. It gives a permit to be able to work on protocols that are really safe and fair, but they’re not strictly TCP-friendly (e.g. mTCP, relentless, etc). For instance, re-ECN would allow ISPs to count how little congestion LEDBAT traffic was causing, so they need not count it against the user’s allowance, etc.

We’ve now implemented it. There’s now a great amount of security analysis on trying to game it and attack it and how it defends itself. People are working on using it as a basis for other DDoS protection mechanisms. Another is trying to build traffic engineering over it. Others are interested in deploying it using proxies. It’s potential impact on net neutrality etc is being analysed by regulatory and economics people. So has it’s time come?

FYI; this workshop was announced on the W3C PLING mailing list.

CALL FOR PARTICIPATION

20-22 July 2009
Imperial College London, UK
http://ieee-policy.org

The symposium brings together researchers and practitioners working on policy-based systems across a range of application areas including policy-based networking, privacy and security management, storage area networking, and enterprise systems. POLICY 2009 has grown out of a highly successful series of workshops and this is recognized by the elevation of the event to an IEEE symposium.

This year, in addition to the latest research results from the communities working in any area of policy-based management and computing, we encourage contributions on policy-based techniques in support of privacy and security management, including the policy life-cycle, detection and resolution of inconsistency, refining policies from users’ requirements, and usability issues.

[Keynote Talks]
* Is the user STILL the enemy?
Dr. Anne Adams, Institute for Educational Technology, The Open University, UK

* Policy & IT
Dr. Claudio Bartolini, HP Labs, Palo Alto, USA

[Programme]
The programme includes 15 full papers and 16 short papers covering a range of topics that include Privacy and Security Management, Policy Applications, Policy Refinement, Systems and Tools, Formal Semantics of Policies. The full programme can be seen @ http://ieee-policy.org/program.html

[Dates]
Early-bird Registration Deadline: 5 June 2009 Symposium Dates: 20-22 July 2009

[Location]
The symposium will be held in the heart of London, on the South Kensington Campus of Imperial College London. Further information on the venue and accommodation options can be found @ http://ieee-policy.org/location.html

Robert Sparks provided a summary of the recent SIPit event:

SIPit 24 was hosted by JPNIC and NICT the week of May 18-22, 2009 in Akihabara, Tokyo, Japan.

Because of the recent global economic changes and the outbreak of flu, we had a smaller event than usual.  There were 65 attendees from 28 companies visiting from 11 countries.
Despite the smaller number of participants we still had 43 distinct implementations.

The mix of implementations was unusual. There were fewer proxies/ b2buas/sbcs than normal.
We also had a higher mix of partial implementations focusing on enabling testing.

GRUU is being more widely implemented – there were 8 implementations present.

As at the last SIPit, there were no implementations of the sip-config, sip-consent, or session-policy frameworks.

The roles represented (some implementations act in more than one role):
25 endpoints
6 proxy/registrars
6 b2bua/sbcs
4 test/monitoring tools

Implementations using each transport for SIP messages:
UDP    100%
TCP     81%
TLS     52% server-auth, 26% mutual-auth
SCTP     7%
DTLS     5%

57% of the implementations supported SIP over IPv6 (This is a big increase over past events, and is related to where the event was held.)

For DNS we had support for:
Full RFC3263        : 76%
SRV only        : 5%
A records only    : 8%
no DNS support    : 11%

Support for various items:
71% rport
20% sigcomp
26% enum
10% RFC4320 fixes
24% invfix
69% session-timer
20% IPSec
12% outbound
14% diversion

There was only 1 implementation claiming support for Identity. 2 for the dial-string URI (RFC4967), and two for Service URNs (RFC5031). We asked proxies to test processing an INVITE with a service URN in the Request- URI and To: header field and a pair of SIP URIs in the route header. The majority of reports back were that the message would be rejected (but they are changing their code).

There were 4 MSRP and 3 XCAP implementations present.

There was one implementation of location-conveyance.

The UAs implemented these methods:
95% INVITE, CANCEL, ACK, BYE (some endponts did messaging/presence
only)
95% REGISTER
88% NOTIFY
88% SUBSCRIBE
83% PRACK
80% OPTIONS
76% REFER
71% UPDATE
68% INFO
61% MESSAGE
56% PUBLISH

Support for various extensions in the endpoints:
82%   RFC3262 100rel
31%   RFC3323 privacy
23%   RFC3327 path
8%   RFC3840/RFC3841 pref/caller-prefs
62%   RFC3891 replaces
10%   RFC4488 norefersub
3%   RFC4538 target-dialog

50% of the implementations were RFC 3489 STUN capable. 21% were RFC
5389 STUN capable.

There were 2 full ICE implementations (appearing in several instances), an additional implementation of an older spec, and several implementations underway that were not quite ready to test. There were no ICE-TCP implementations this time.
There were 7 TURN clients and 4 TURN server present.

70% of the UAs present both sent RTCP and paid attention to RTCP they recieved

39% of the endpoints present supported SRTP – a large uptick from the last event.
Only one had code based on the dtls-srtp.

Support for multipart/mime continues to increase – 58% of the endpoints present would handle it.  There were no implementations present testing S/MIME.

Of the SIP-Events implementations, the following packages were
supported:
65%    presence
65%    refer
39%    message-summary
32%    reg
16%    conf
13%    dialog

23% of those implementations supported eventlist.

There were 6 SIP-Events implementations present supporting winfo.

Four of the proxies/b2buas present still rely only on max-forwards.
There were two implementations of fork-loop-fix, but no implementations of max-breadth.

Based on a query from James Polk, I asked endpoints how they reacted to receiving a 300 class response to an initial invite. Of those who responded:
25% would stop processing the call
33% would follow the redirect if and only if there was only one contact
17% would follow the first contact if one or more were present
25% would follow all contacts (or give the user a choice of which to follow)

In a recent review by Bernard Aboba regarding a documents I wrote together with Henning Schulzrinne about “trustworthy location information” (with slides from the last IETF meeting below).

The above slides build on previously presented slides shown below:

Bernard included a link to an interesting article that is worth reading when working in the area of emergency services. Here is the abstract of the article “Couple swarmed by SWAT team after 911 ‘hack’”:

A Washington State teenager is facing 18 years in prison on charges that he used his PC to access Orange County, California’s 911 emergency response system and convinced the sheriff’s department into storming an area couple’s home with a heavily armed SWAT team.

This teenager spoofed the telephone number he used for making the emergency call (a mechanism that is quite easy todo in the PSTN due to the lack of security). Then, the phone number is used for retrieving the location of the emergency caller by the emergency services infrastructure. Now, they got location of the place of the caller (but unfortunately the wrong one).

Cullen announced a new list for discussing operational issues around SIP. You can subscribe at https://www.ietf.org/mailman/listinfo/sip-ops

The purpose of the SIP-Ops mailing list is to discuss issues and requirements related to operating a SIP domain, which may drive the need for IETF standardization or Best-Common-Practice documentation. For example, issues or needs related to troubleshooting, diagnostics, security, and administration relating to operating a SIP domain would be candidates for this list. This is not a list to ask questions about implementing current standards, nor about specific product/vendor issues. Issues related to peering between domains are more appropriate for discussion in SPEERMINT.

Here is an announcement of interest for the IETF KEYPROV working group (and security groups in the IETF in general. http://xml.coverpages.org/keyManagement.html#NIST-KeyManagement200906 says:

A NIST Key Management Workshop will be held June 8-9, 2009 at the U.S. National Institute of Standards and Technology, Gaithersburg, Maryland, USA. Registration is required by May 18, 2009. Overview: “Key management is a fundamental part of cryptographic technology and is considered the most difficult aspect associated with its use. Of particular concern are the scalability of the methods used to distribute keys and the usability of these methods. NIST is undertaking an effort to improve the overall key management strategies used by the public and private sectors in order to enhance usability of cryptographic technology, provide scalability across all cryptographic technologies, and support a global cryptographic key management infrastructure.

The first step in achieving this goal is to conduct a workshop to identify:

• (1) the various obstacles in using the key management methodologies currently in use;
• (2) the alternative technologies that need to be accommodated;
• (3) alternative strategies useful in achieving the stated goal; and,
• (4) approaches for transitioning from the current methodologies to the most desirable method…

There will be no registration fee for this workshop. Participation includes: [a] physically attending the workshop at NIST; [b] viewing the workshop presentations via WebCast at remote locations; [c] presentations; [d] discussion; [e] providing written comments and recommended relevant topics of interest… U.S. National Institute of Standards and Technology (NIST) publications on security (including encryption and key management) have played a prominent role for many years, especially for government applications. FIPS Publications are issued by NIST after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Reform Act of 1996 (Public Law 104-106) and the Federal Information Security Management Act of 2002 (Public Law 107-347). NIST Special Publications in the 800 series present documents of general interest to the computer security community. The Special Publication 800 series was established in 1990 to provide a separate identity for information technology security publications. This Special Publication 800 series reports on ITL’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.

Contact: Elaine Barker (technical and program questions) or Sara Caswell (administrative questions).

Richard Barnes started a project to develop encoders and decoders for the DHCP location options for a couple of different languages. So far, there is Javascript support for RFC 3825 (option 123) and RFC 4776 (option 99), and the work on a C++ version with roughly the same structure has been started. The other Java and C implementations will have to moved into this repository sometime soon.

Keep track of the project here: http://github.com/bifurcation/dhcp-loc

In the GEOPRIV working group the consensus call for RFC3825 fixes continues, see “[Geopriv] IETF74 Consensus Calls“  and “[Geopriv] Scope of 3825 fixes“.

Members of the WebApps WG in the W3C have asked for review from the IETF community regarding Cross-Origin Resource Sharing (CORS). The document can be found here:

http://www.w3.org/TR/2009/WD-cors-20090317/

This document defines a mechanism to enable client-side cross-origin
requests. Specifications that want to enable cross-origin requests in
an API they define can use the algorithms defined by this
specification. If such an API is used on http://example.org resources,
a resource on http://hello-world.examplecan opt in using the mechanism
described by this specification (e.g., specifying
Access-Control-Allow-Origin: http://example.org as response header),
which would allow that resource to be fetched cross-origin from
http://example.org .

The document’s status section contains information about how to provide feedback to them.

Richard released an updated version of his UI-based encoder/decoder of DHCP location information. He wrote:

The daunting thing about the DHCP location options (for me at least) has always been figuring out how to encode and decode them, so with some help from the loc-imp list, I’ve written a web-based encoder for the DHCP location options (RFC 3825, RFC 4776, and draft-thomson-geopriv-3825bis):

http://geopriv.dreamhosters.com/dhcloc/

The DISPATCH and the SIPCORE groups have been created and the work of the previous chairs has been acknowledged:

DISPATCH

• Charter:  http://www.ietf.org/html.charters/dispatch-charter.html
• Chairs:  Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>,  Mary Barnes <mary.barnes@nortel.com>
• Mailing List: https://www.ietf.org/mailman/listinfo/dispatch

SIPCORE

• Charter: http://www.ietf.org/html.charters/sipcore-charter.html
• Chairs: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Adam Roach <adam@nostrum.com>
• Mailing List: https://www.ietf.org/mailman/listinfo/sipcore

Vijay Gurbani has provided a nice summary about the TLS implementations in SIP stacks based on the SIPit interop events. Here is his text:

SIPit   Unique     Number of TLS
No.     Impl.          Impl.                   Percentage
———————————————————————–
16       57                  25                            44%
18       73                  30                            41%
19       90                  41                            45%
20       90                  42                           46%
21       70                  34                           49%
22       80                  50                           63%
23       50                  24                           48%

Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in
October 2008.
(2) Data for 16th SIPit is form my private archive
and is not reflected in [1].
(3) I don’t have data for 17th SIPit.

The percentage of the TLS implementations show a monotonic increase save a couple of hiccups.  I suspect that most new TLS (or even TCP) implementations are not tuned to performance as much as they are geared towards ensuring that the functionality itself exists.

[1] Robert J. Sparks, SIPit Summaries, archived at https://www.sipit.net/SIPitSummaries

Richard provided some additional code for the DHCP-civic RFC (RFC 4776):

http://geopriv.dreamhosters.com/dhcloc/dhcp99.js
http://geopriv.dreamhosters.com/dhcloc/dhcp123.js
http://geopriv.dreamhosters.com/dhcloc/bitbuffer.js

Martin also gave it a shot:

>>> var civic = new DhcpOption99();
>>> civic.country = ‘DE’;
“DE”
>>> civic.setDefaultLanguage(’de’, ‘Latn’);
>>> civic.A1 = ‘Bayern’;
“Bayern”
>>> civic.A2 = ‘Oberbayern’;
“Oberbayern”
>>> civic.A3 = ‘M\u00FCnchen’;
“München”
>>> civic.RD = ‘Marienplatz’; // note RD, not A6
…
>>> civic.setDefaultLanguage(’it’, ‘Latn’)
>>> civic.A1 = ‘Baviera’;
“Baviera”
>>> civic.A3 = ‘Monaco’;
“Monaco”
>>> civic
Civic Address of Client: country DE, {en-Latn} A1=”Bavaria”, A3=”Munich”, {it-Latn} A1=”Baviera”, A3=”Monaco”, {de-Latn} A1=”Bayern”, A2=”Oberbayern”, A3=”München”, HNO=”8″, LMK=”Rathaus”, PC=”80331″, PLC=”government-building”, POBOX=”Postfach 1000″, RD=”Marienplatz” what=2 country=DE defaultLanguage=de
>>> civic.encode()
02:44:45:00:02:65:6e:80:04:4c:61:74:6e:01:07:42:61:76:

61:72:69:61:03:06:4d:75:6e:69:63:68:00:02:69:74:01:07:

42:61:76:69:65:72:61:03:06:4d:6f:6e:61:63:6f:00:02:64:65:

01:06:42:61:79:65:72:6e:02:0a:4f:62:65:72:62:61:79:65:72:

6e:03:08:4d:c3:bc:6e:63:68:65:6e:13:01:38:15:07:52:61:74:

68:61:75:73:18:05:38:30:33:33:31:1d:13:67:6f:76:65:72:6e:

6d:65:6e:74:2d:62:75:69:6c:64:69:6e:67:1f:0d:50:6f:73:74:

66:61:63:68:20:31:30:30:30:22:0b:4d:61:72:69:65:6e:70:6c:

61:74:7a

position=0 buffer=[153] length=1224

All here:
http://held-location.sourceforge.net/dhcp/bitbuffer.js
http://held-location.sourceforge.net/dhcp/utf8.js
http://held-location.sourceforge.net/dhcp/dhcp123.js
http://held-location.sourceforge.net/dhcp/dhcp99.js

Richard Barnes has recently published another DHCP geolocation decode (RFC 3825). See http://geopriv.dreamhosters.com/dhcloc/rfc3825.html

Further refinements have been proposed by Martin Thomson. Here is what he provided:

http://held-location.sourceforge.net/held_js/dhcp123.js
http://held-location.sourceforge.net/held_js/bitbuffer.js

Using firebug:

>>> var opt = new DhcpOption123();
>>> opt.decode(’1f:cb:7e:9f:39:35:4b:e0:00:00:13:bf:ff:e9:00:01′)
>>> opt.toString(false) // RFC 3825
“Latitude: -26.252691477537155 [-28,-24), Longitude: 165.9375 [165.9375,166), Altitude: -23 [-256,0) Metres, Datum: WGS84"
>>> opt.toString(true) // 3825bis
"Latitude: -26.252691477537155
(-28.252691477537155,-24.252691477537155), Longitude: 165.9375 (165.90625,165.96875), Altitude: -23 (-151,105) Metres, Datum: WGS84"
>>> opt.latitude
-26.252691477537155
>>> opt.latitudeUncertainty
7
>>> opt.longitude
165.9375
>>> opt.longitudeUncertainty
13
>>> opt.altitudeType
1
>>> opt.altitude
-23
>>> opt.altitudeUncertainty
14
>>> opt.datum
1
>>> opt.encode()
1f:cb:7e:9f:39:35:4b:e0:00:00:13:bf:ff:e9:00:01:00 position=0 buffer= [17] length=128

Note that it doesn’t take the option code or length. You can add your own 7b:10: to the front…

Recently, OASIS announced the creation of a new key management standards effort called KMIP (Key Management Interoperability Protocol. See new stories below:
http://www.infoworld.com/article/09/02/12/HP_IBM_push_new_KMIP_encryption_key_standard_1.html
http://www.centredaily.com/business/technology/story/1115505.html

You can download the draft standard and FAQs from here:
http://xml.coverpages.org/KMIP/

A short summary:

The increased use of encryption for securing information in the enterprise reflects the critical importance of this technology in addressing regulatory requirements, protecting intellectual property and controlling the exposure of sensitive information. The widespread use of encryption, however, is complicated by inconsistencies and duplication in the key management systems supporting each of the encryption environments. Full-disk encryption systems for laptops have their own key management systems, as to encryption systems for array-based storage environments and content management systems. This proliferation of key management systems results in higher operational and infrastructure costs for enterprises using encryption. Even in those cases where a single key management system can support multiple encryption systems, there are typically different communication protocols between the key management system and each of the encryption systems. The proliferation of protocols, even when supported by a single enterprise key manager, results in higher costs for developing and supporting the key manager, costs that ultimately get passed on to the enterprises deploying encryption solutions.

OASIS Members Form Key Management Interoperability Protocol (KMIP) Committee
http://xml.coverpages.org/ni2009-02-27-a.html

The webinar slides are available at:
http://xml.coverpages.org/KMIP/KMIP-Webinar20090402.pdf

The Committee charter is available via the KMIP technical committee (TC)’s public web page and in linked hypertext format:

http://www.oasis-open.org/committees/kmip/charter.php
http://xml.coverpages.org/KMIP-Charter-CFP.html
http://xml.coverpages.org/keyManagement.html

Statement of purpose for the new OASIS Group:

The KMIP Technical Committee will develop specification(s) for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of “shared secrets”) and related areas.

Scope of the Group:

The initial goal is to define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs (Trusted Platform Modules) and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include:

* Storage Devices
* Networking Devices
* Personal devices with embedded storage (e.g. Personal Computers, Handheld
Computers, Cell Phones)
* Users
* Applications
* Databases
* Operating Systems
* Input/Output Subsystems
* Management Frameworks
* Key Management Systems
* Agents

If you use the XML2RFC format for editing your IETF drafts then you typically include the literature via references to always point to the latest version. This is pretty nice unless you want to use XML2RFC without Internet access. Ekr has developed a solution to that and posted it to the RAI mailing list. Here is the description of the tool he wrote: http://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc/bibxml2rfc.txt

bibxml2rfc is a bibliography helper program for xml2rfc files. One of the motivations for bibxml2rfc is that it’s hard to work with xml2rfc in offline settings. Either you need to download the entire database or manually enter each database entry. In either case, you need to significantly edit your XML file to add a new reference. bibxml2rfc is intended to mitigate these issues.

When handed an XML file, bibxml2rfc tries to identify the references and construct an appropriate bibliography. The general procedure is as follows:

- Find all <xref> elements in the XML file (<file>)
- Extract the “target” attributes.
- Look in the local bibliography cache (references/) for files named <target>.xml.
- If no cached entry is found or the the target appears to be an I-D (starts with “I-D.”), then try to fetch an entry out of the appropriate repository on xml.resource.org.
- Build two files:
+ <file>-normative containing reference entries for the normative references
+ <file>-informative containing reference entries for the informative references

bibxml2rfc determines whether a reference is normative or informative by looking at the ‘norm’ attribute in the <xref> element. If it is ‘true’, then the reference is normative. Note that a single instance of ‘norm=”true”‘ is sufficient to mark a reference normative, so if multiple <xref> elements are present, only one need be so marked.

The files can be downloaded here: http://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc/