Near Field Communication, a technology for wireless exchange between devices only centimeters apart, can be helpful to pass somewhat sensitive data. We can see it being useful for credentials, provided that their use is very, very limited.

Much of what we do in the InternetWide Architecture is founded on centrally managed infrastructure. For security, we center around Kerberos. In this system, we have short credentials of only a few hundred bytes, valid for a day or so, and the related secrets may be protected with a temporary password or PIN.

Imagine creating Kerberos tickets for certain purposes, and storing them in an NFC device. The range over which a ticket is active can be modified to various levels of flexibility:

• So-called TGTs are fully capable of representing a client;
• Crossover TGTs are only capable of representing a client to a certain realm;
• Service tickets can only be used to access one particular service.

So, the range of control varies from "generic user ticket" to "specific ticket to let a user access a particular service". Somewhere in the middle is a possibility to have a dead-end realm for guests or, more generally, for NFC tag users, with only limited reach. Also useful is that a client identity will be safely stored on the NFC tag. All these settings leave information that ACLs can use to decide on client access.

What we need, is a storage format for NFC tags. A container format is already defined, known as NDEF and supported in mobile device APIs. NDEF specifies how data can be pushed, prefixed by metadata. As soon as we are clear about the data to be stored (such as Kerberos' Ticket and/or TGS-REP structure) and how to express this in a type we can start programming tags!

Tags are usually writeable, but this is not considered part of common use. With the storage of Kerberos tickets however, a new write is needed roughly on a daily basis. Note that a chip such as NTAG216 can store a good size of 888 bytes and survive 100k rewrites -- good for a daily rewrite for about 275 years. In short, this seems to be practical.

The result is very interesting -- because we may be storing a credential on a read/write medium, rather than making it perform in a challenge/response interaction, but the use of the credentials are limited by the existing semantics of the Kerberos system!

Moreover, there is a portion of data that is supposed to be encrypted. The key to which it is encrypted may be chosen to match our purposes. At the low end, there could be a PIN (of any size and syntax) to encrypt the secret parts. The parts that are being transferred are now protected by this PIN. Even though the data might be tapped by nearby listeners, and even though they are then subject to password cracking attempts, the combination is difficult to mount.

The PIN used may in fact be changed for every new ticket, so for every new day. Imagine what that means for a TGT -- even though it gives away a strong credential, it will still require the entry of a PIN to match, and storing that PIN is senseless beyond the limited life of the TGT itself.

Anything that radiates password-protected data over the air is at best a pragmatic system --wired alternatives are infinately stronger-- but it may nonetheless disarm remote parties from cracking attempts. Remote parties are already remote when they are more than one day away from a tapping opportunity -- or more than a few centimeters! Meanwhile, the user does have a practical solution; when authentication is required, he can tap the phone on the key chain in his pocket, possibly enter the PIN, and continue working.

Being cryptographers at heart, we will endeavour to improve this situation and regain the advantage of good independence of the two factors of authentication --something held and something known-- which means that we should make the most of the PIN, and especially avoid the risk of an oracle that can be queried offline by any rogue eavesdropper.

About once a day, the tag on the key chain must be rewritten. This can be done by any device, including the mobile device, given that it runs through a more elaborate procedure involving long-term secrets. This can be done in a safer setting, such as behind their office desk or perhaps in a camera-free toilet!