When asked for a title, hoping for something catchy enough to draw audience away from parallel sessions, I suggested 'IOT - The 'I' needs to be identity'. Wonderfully catchy, and sufficiently vague to give me the flexibility to create whatever content I saw fit as long as it somehow tied together IoT and identity.
But admittedly, any CIS attendee trying to decide between my session and Brian Campbell's session showing vacation pics in the room next door, might justifiably interpret the title to mean that I would argue for the importance of identity to securing the IoT - as hinted at by the 'needs'. I, of course, fully believe in this argument and in my session actually asserted that it was both the opportunity and the responsibility of the audience in the room (and other CIS attendees as well as the wider identity community) to ensure that IoT security (particularly the authentication and authorization of actors) was built with identity as a central concept (and further, leveraging standardized identity protocols like OAuth and OpenID Connect).
If we fail in this, then the default security mechanism in the IoT will be passwords over SSL. Good luck with that.
There are a number of promising efforts on the above front including ACE, UMA, COSE etc.
But there is another side to the relationship between identity and IoT.
If the above efforts are focused on 'Identity for things'; i.e., being able to securely and interoperably authenticate things, users, and clouds in the IoT, the flip side is 'things for IoT'; i.e., leveraging the things around us in order to authenticate ourselves into applications and systems (and, of course, dealing with the privacy implications of this model).
As I knew that other speakers (such as Eve Maler, Daniel Headrick, Hannes Tschofenig, & Morteza Ansari) in the IoT track were going to address the 'Identity for Things' topic, I chose to focus my CIS session on the 'Things for Identity' aspect (along with speakers Steve Wilson and Karl Martin).
As is my wont, I started with a taxonomy.
If a thing/device is to facilitate a user's authentication, then necessarily there must be some sort of interaction between the user and that device. Below is my attempt at a categorization of human and device interactions, differentiated by whether active (i.e., the user explicitly and consciously performs some action) or passive (i.e., the user need not consciously perform any particular action), and whether the user experience of the interaction is motivated by authentication or something else (such as using an application).
More and more we are relying on mobile devices (as the 'something to have' factor) to facilitate user authentication beyond the typical password (a weak 'something you know' factor). These phone-based 2FA systems can offer improved usability compared to earlier models of dedicated security fobs. Critically, phones are something the user *already* has, and one far more likely for an employee to have in their possession than some OTP fob IT provided them.
Continuous authentication was a big theme at CIS. Continuous authentication is the premise that, in contrast to today's reality of requiring the user login on a frequency of hours or days (depending on the nature of the resource/application), we can effectively authenticate on a much smaller frequency (seconds or minutes) and so effectively smooth out the 'assurance curve' of how much confidence we can place in the user's identity. But, of course, this model of continuous authentication is incompatible with explicit authentication actions (as in the top-right corner of the graphic) since users would not accept the burden of such frequent explicit logins (whether supplying a password, or touching a USB key, or swiping their finger to a scanner).
Consequently, continuous authentication *demands* the passive authentication modes of the lower-right corner. So the trend towards continuous authentication is actually a trend away from the top-right corner of explicit authentication actions (such as swiping a phone's fingerprint scanner or touching a Nymi band's electrode) to the lower-right corner of a passive authentication model (such as a Nest thermostat reporting on the presence of a user in the living room, or a smart car asserting that somebody of the right weight was in the driver seat, etc.).
Another implication of continuous authentication is the requirement that mechanisms send indications of the interactions between device and user to an authentication server for aggregation and analysis. It's all well and good for my Nest to be aware that somebody is in my living room, but that information needs to be communicated to an authentication server if it is to be factored into an determination of whether some user trying to login with my username/password is actually me. In my session I argued that the FIDO architecture, although currently optimized for the explicit authentication modes (e.g., fingerprint swipe, etc.) could be extended to support the passive continuous model. FIDO's architecture explicitly distinguishes between the interaction that happens locally between the user and some sort of device sensor and how the details of this interaction are communicated to the server through cryptographic protocols. Consequently, it would appear to provide useful plumbing for multiple and arbitrary devices communicating information about their current state up to an authentication server. Watch this space.
But of course, authenticating the user is not the end of the story. Once identified, relevant identity attributes for that user must be communicated to the applications that the user is trying to access. Identity tokens, whether SAML assertions or OpenID Connect id_tokens provide standardized structured formats, making it easy for applications to consume these identity attributes.
I wrapped up my CIS session with the above slide, putting the different authentication models of active and passive into a framework that includes standardized identity tokens. And, Step 5 is meant to imply that the we are not done with that initial delivery of identity to the application. The flow of information can be bi-directional.
So again, apologies for the misleading title of ''The IoT needs Identity'. A better description of the actual content would have been 'Identity needs the IoT'. But good luck getting this sort of change made in the conference hand-outs and website in the last few days.