IF-MAP, the interface for a Metadata Access Point, is a standard client/server protocol for accessing a Metadata Access Point (MAP). The MAP acts as a central clearinghouse for information about network security objects and events, such as users, devices, and activity. The IF-MAP protocol defines a powerful publish/subscribe/search mechanism for an extensible set of identifiers and data types; MAP clients can publish metadata and/or consume metadata published by other clients.

The original IF-MAP specification, published in 2008, extended the TNC architecture to support standardized, dynamic data interchange among a wide variety of networking and security components, enabling customers to orchestrate security automation among multi-vendor systems providing coordinated defense-in-depth.  Since then, IF-MAP has been evolving to provide enhanced functionality and address new use cases.

Every running system needs regular maintenance – and so do our IF-MAP specs!  Occasionally they need to be tuned up and tweaked to ensure clarity for implementers and interoperability for end users.  Our implementers are our best source of feedback, from suggestions on areas where the spec needs to be tightened up, to ideas for new features to extend IF-MAP’s interoperability and usability.

Based on that input, we’ve released an update to IF-MAP, version 2.2, with a variety of incremental improvements.  For example, we clarified several areas of the spec, including the nature of the IF-MAP data model, the purpose and usage of the administrative-domain attribute, the difference between search and poll, and usage of identity identifiers vs. extended identifiers in search results.

We’ve also added normative language in several sections to reduce the potential for interpretive differences and thus improve interoperability.  Those areas include normalization of strings to lowercase, and of usernames in identity identifiers; schema compliance and prefix declaration; handling of various special-case poll results; validation of identifiers and metadata, and rejection of malformed identifiers; and how a MAP Server authenticates a MAP Client and authorizes IF-MAP operations.

Finally, we’ve added a couple of small new features to hopefully make life easier for implementers and end users!  As IF-MAP evolves to include optional features (such as MAP Content Authorization), MAP Client implementers need a way to identify whether the MAP Server supports these features.  Accordingly, we’ve defined a basic mechanism for MAP Clients to learn what version(s) of IF-MAP, and which optional features, are available from a particular MAP Server.  Also, as the use cases for IF-MAP continue to expand, timestamp granularity beyond a single second (as originally defined) is required, so we’ve added an optional ifmap-timestamp-fraction attribute to meet this need.

The landscape in which IF-MAP is applied changes constantly.  As we keep an eye on the future – the progress being made in the IETF SACM WG is very exciting! – we’re working to make sure that IF-MAP is addressing today’s needs and providing a flexible foundation for the challenges yet to come.