Our use of credentials is much more secure on a desktop or laptop than it could ever be on a mobile phone. The reasons are the size-constrained input capabilities of phones and the customary use of phones in the presence of others. But perhaps we can securely import credentials into our phones?

NFC tags are simple smart cards or keychain fobs that are passive until NFC feeds and activates them. Commonly, the application is then to download data from it, in the form of NDEF records. These records can then be processed by the active party. It is common for these fobs to go up to a few hundred bytes of NDEF data, with 888 bytes being among the biggest sizes available.

Usually, we do not like the security implications of fixed secrets, but when a time constraint is built into them we can drop some of our concerns. This is for example the case with Kerberos tickets, which usually last no more than a day or so. The general thinking is that it is good to protect them from abuse, but as long as any secrets contained in them are properly protected it would be incredibly difficult to attack them, and an attack is thought to last much longer than the ticket lifetime.

Integration between NFC Tokens and Kerberos

It is indeed practical to combine Kerberos tickets with keychain fobs. A ticket with state-of-the-art cryptography uses about 350 bytes, and can be passed verbatim to any service we intend to address, including Kerberos' own services. But we also need a session key to prove to those services that we own the ticket, and for that we might add a second 275 byte record in the NDEF, holding an encrypted structure EncTicketPart. Given a 888 byte token, we have 263 bytes left for NDEF headers.

The encrypted structure would only be decipherable to the intended recipient, which would be our phone. Meaning, we sit behind our laptop or desktop and, using our existing Kerberos session we export the credentials, encrypting the session key specifically for our mobile phone; in doing so, we might use either a fixed key stored on the mobile phone, and/or incorporate a PIN to be entered by the user. We construct an NDEF holding ticket and encrypted key data, and store it on our NFC Tag.

What we have basically done, is export a part of our credentials cache in a form that is easily imported into our mobile environment. In fact, it can be imported over and over again, anytime we care. This makes it easy to require the presentation of the NFC Tag for each new use of a ticket, after a phone lockout, after some time has passed or to renew the ticket. In each of these cases there may or may not be a requirement to enter a PIN that can be mixed with a phone-stored fixed secret; it should however be noted that regular PIN entry makes it more likely that it would be observed.

Applications of Tickets on NFC Tags

The most powerful thing we could store on an NFC Tag are the ticket and key data for a user's initial login. This would allow them to derive any further tickets by contacting their KDC. The KDC is stateless, and should not notice that the ticket is touring the world.

It is also possible to deliberately provide only a service ticket. This may be helpful to welcome guests, perhaps to access a Kerberos-protected printer, internet access facility, and so on. With the design of TLS-KDH in mind, it should be easy to come up with useful examples of this principle. Typical guest tags would be protected with a one-time password that they would need to enter upon swiping the NFC Tag.

Somewhere in the middle, there could also be realm crossover tickets. These represent a client that has migrated from one realm into another, where its powers to crossover may be more constrained. The client's identity may be easily filtered in ACLs so that this mechanism might benefit guest access.

Finally, it is possible to share a ticket without adding the key data. This means that the mobile phone is uncapable of acting on behalf of the ticket. What it can do however, is use the ticket (if it is a TGT) in a communication with its own Kerberos realm to arrange a user-to-user session key. This can then be used to protect various applications, including chat and telephony. In this case, additional records may be added to present contact opportunities that would welcome such protected communication.

Support for Multiple Devices

In general, key data blocks are considered to apply to the preceding ticket, but there could be multiple key data blocks after a single ticket. (But note that the sizes quoted above indicate that current NFC Tags may not be able to carry these larger NDEF structures yet.)

It is possible for key data blocks to hold an identity; this field may be used to describe the targeted mobile device. Each of the key data blocks should hold the same information, but re-encrypted to another party.

It may seem better to only vary the EncryptionKey structure, but that would add complexity and it would mean that the client identity are both no longer protected in the sense of privacy, and in the sense of tamper-proofing. Note that most fields are protected when they are received over a TGS-REP and it would be a silly idea to weaken that for wireless communication.

When the client identity begins with pin+ or password+, the device may assume that it should mix a PIN or password with the remainder of what the identity indicates. If nothing more is added, the trailing + is removed and the identity simply reads pin or password and it is assumed that the suitable bit of information is passed out-of-band. Note that it is insecure to only use a simple secret, such as a 4-digit PIN code, because that reduces the information on the NFC Tag to an offline oracle with too little entropy to really stand a chance. Such things should only be done for guest tokens, with personal PIN codes that change with every new token.

Note: We may setup more elaborate schemes in the identity. It could be used to prescribe when and how to require another swipe or PIN/password.

Support for Multiple Identities

Kerberos tickets are owned by a cetain client identity, which is made available to the user in the encrypted key data. As described before, a spaceous NFC Tag could host a list of tickets and key data structures, where the latter describe the last preceding ticket. The result of this general rule is that we may provide multiple identities on one NFC Tag.

When multiple identities are presented in one NDEF structure, then it may be assumed that we are to store them separately, and pull them out when we need to. As a rule of thumb, the first identity presented in any given NDEF should remain the one selected for immediate use; additional identities are considered add-on information, to be processed only when multiple identities can be handled.

In a comparable, but somewhat different scenario, multiple NFC Tags can each hold an identity. These are presented independently, but as the above makes clear, it is often useful to be able to hold on to older identities while new ones are being made the current. The added use case for spreading identities of NFC Tags would then be that a mere NFC Tag swipe suffices to switch the identity used on a phone. Hold a personal NFC Tag in your right pocket and a business NFC Tag in your left pocket and you will be able to switch very quickly!