Getting new work started in the IETF usually requires a Birds-of-a-Feather (BoF) meeting to discuss goals for the work and to help assess the level of interest in and support for new work. In this article, we’ll review the BoFs that took place during the IETF, their intentions and outcomes. If you’re inspired to arrange a BoF meeting, please be sure to read RFC 5434, Considerations for Having a Successful Birds-of-a- Feather (BoF) Session. Full descriptions of the BoFs that were proposed in the run-up to the IETF 81 meeting can be found on the wiki.
REPUTE—Reputation Services
CatharusDescription: This was a Working Group-forming BoF meeting to gauge momentum and interest in working on protocols and other specifications for providing a general- purpose reputation framework. In the open Internet, making a meaningful choice about the handling of content requires an assessment of its safety or trusworthiness. This is based on a trust metric for the owner (identity) of an identifier associated with the content, to distinguish (likely) good actors from bad actors. The generic term for such information is reputation. This working group would develop mechanisms for reputation reporting by independent services. One mechanism would be for a basic assessment of trustworthiness. Another would provide a range of attribute/value data that is used as input to such an assessment.
Proceedings: http://www.ietf.org/proceedings/81/repute.html
Outcome: Discussion was rather wide-ranging during the meeting but focused down to working specifically on reputation services for email. Several concerns were expressed about the complexity of this work if not very narrowly focused, and the fact that prior work in this space hasn’t gained traction historically. Nonetheless, people are interested in doing the work and there were a lot of people interested in seeing the output, so chartering discussions for a Working Group will continue.
MULTRANS—Multicast Transition
Description: This BoF meeting considered the question of how to devise the means whereby existing multicast mechanisms can operate successfully when signaling and content must traverse one or more IP version boundaries.
Proceedings: http://www.ietf.org/proceedings/81/multrans.html
Outcome: The BoF identified the concrete scenarios that were of most importance, namely IPv4 sources with both IPv4 and IPv6 receivers to support IPTV applications. The discussion concerning whether or not these applications are required to work interdomain did not conclude. Several gaps in understanding were identified and the existing list of requirements needs further work and input. The meeting did not reach the point of considering the question of whether a Working Group could be formed, so a second BoF meeting during IETF 82 seems likely.
CICM—Common Interface to Cryptographic ModulesCanada Goose
Description: The Common Interface to Cryptographic Modules (CICM) (pronounced kick-em) defines an abstract API for the security services provided by cryptographic modules developed by multiple vendors. The API is intended to support high assurance cryptography, security domain separation, and enhanced module, key, and channel management capabilities that are vendor neutral. The purpose of a CICM Working Group would be to publish an API for high assurance cryptographic devices and to provide guidance for any new submissions related to high assurance cryptos.
Proceedings: http://www.ietf.org/proceedings/81/cicm.html
Outcomes: It wasn’t clear from the presented materials how this work could fit in the IETF, and the question of whether it would be a better fit for the IRTF was raised. Significant charter reworking is required and more detailed elaboration of how the proposed work could impact on existing IETF protocols.
WOES—Web Object Encryption and Signing
Description: Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption, digital signatures, and message authentication codes (MACs) for data that is being carried in JSON format.
Different proposals for providing such security services have already been defined and implemented. This proposed Working Group’s task is to standardize two security services, integrity protection (signature and MAC) and encryption, in order to increase interoperability of security features between protocols that use JSON. The Working Group would base its work on well-known message security primitives (e.g., CMS), and would solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct.
Proceedings: http://www.ietf.org/proceedings/81/woes.html
Outcome: This BoF meeting went very well. There was clear consensus about the work plan and very little controversy on the points raised. A draft charter for the WG, to be called JavaScript Object Signing and Encryption (JOSE), was submitted to the community for review on 30 August.
This article was posted on 27 October 2011 .