Yubico Forum

Ok, the title doesn't really say much, sorry for that - but I really couldn't think about any good, short, precise phrasing for this ... idea.

Let me allow you a peek into the thinking process behind it all.

Since I heard about the Yubikey on Security Now, I was thinking about its applications and possibilities - I recently got one myself, otherwise I couldn't post this, of course. It occurred to me, that there is one possible promlem with the architecture. One Key can only authenticate itself against one server - now, this relation is fine because then, the single server always knows the state of my key and can therefore examine the submitted OTPs more precisely.
Now picture this: you already have a yubikey for your OpenID account and similar stuff (like this forum and the wiki) so basically, this key authenticates against Yubico. Now another party comes along, which implemented the yubikey but does not want to rely on Yubicos server for whatever reason. In the current situation, you'll have to get a second Yubikey from this new party to authenticate against their server. So you might end up with the same problem, that all the other "type in this number"-OTP-tokens have - you get a bunch of them for different accounts.

Now, the solution to this problem would be, that the database entries from Yubico (public ID, secret ID and AES chiffre) have to be transferred to the other party - so that one key can authenticate to two different servers without communication between them. The new problem would of course be, that neither server would know the exact state of the Yubikey and thus some information from the OTP gets less valuable. But you would gain a little bit more redundancy.
Technically, this transfer would be quite easy. You give an OTP to the new server, which asks Yubico to authenticate it. Then the new server has to ask the Yubico server to send its database entries, establish an SSL connection between them, have the user give the Yubico server a consecutive OTP to the first one to verify the transfer and if all goes well, have the Yubico server submit the entry to the key through an SSL connection to the new server. (I hope this explanation isn't too confusing )
One advantage of this procedure is, that the key and the secret informations are never in the same place, which could eventually destroy all cryptographic security.

If you need a nice and flashy example of this, think about PayPal or Blizzard (World of Warcraft login) - they don't support OpenID and they probably never will, but they might consider implementing the Yubikey. But why have them send you another one if you already have one?

What do you think about it?

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

This ties in a little with what I've been thinking about the PAM module.

On the one hand, I don't want to have to rely on the Yubico servers being up in order to be able to log into my boxes. But on the other hand, I don't want to have to use two Yubikeys.

So my thinking was a bit simpler than yours; my local pam module has a "most recent" entry of it's own, that it would use in the case of the yubico servers being offline, but if they aren't, then it passes the key along to yubico for validation. Pending a successful validation, the PAM module authorizes the user to log in. If it's a fail at yubico, then we prevent the user from logging in. But if the yubico servers are down, then we use our own database to determine whether to allow them to log in.

I realize that there's the possibility that a key could be replayed against my local server, if the yubico servers were down.

Any better ideas on implementation?

ouch - replay attack - baaaad ... very baaad.

Well, the only way I can think of to solve this is a communication between the servers. There seems to be no other way. So, the Yubico Server needs to know, that your Key also authenticates against your own PAM module and vice versa - so if one is used to authenticate, it sends a copy of the used token to the other - not to verify it, but to validate it, so that it can't be replayed to the server which was not used for authentication in the first place.
This would completely blast the idea of load balancing and redundancy, because we would have communication between the servers after all.
I think we're running against a wall here. I guess we should agree on the fact, that a Yubikey is small enough to have a few of them dangling off your keychain

<off-topic>Maybe Yubico should offer Yubikeys that glow in different colors to keep them apart?</off-topic>

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

Yubico’s CEO has confirmed that she is planning to add more colors to the YubiKey by summer timeframe. In the meantime Yubico will come up with colored stickers that are very resistant against being peeled off (using a special adhesive). If you would like some of the colored stickers please email support@yubico.com with your address and this note Yubico will send the stickers as soon as they come in.

Thanks for the information - that's really good to hear

BTT: Should it be possible to sacrifice some security to gain redundancy, load balancing and one-key for more services possibility?

As I understand it, one could build the infrastructure for load balancing and redundancy but this would still mean one key for one service (with more authentication servers in the backend).

So it all comes down to spreading OpenID even for PayPal transactions, World of Warcraft accounts and bank accounts, eh? Somewhat a cool idea though...

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

I'm going to just glue my two YubiKeys together A small colored sticker will help me figure out which end to insert!

If you glue them together, you will no longer be able to plug either one into a standard USB port.

Look at the left part of this picture: http://en.wikipedia.org/wiki/File:USB.svg

The Yubikey lacks the metal case around the actual plug - but the other side of the connection looks kind of the same, just upside down (to touch the contacts). If you glue two Yubikeys together, the second key would hit the counterpart when you try to plug it in.

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

Perhaps like this

Yeah, that'd definately work

You could actually move the two keys closer together, so that just the 'plugs' keep standing out, you know?

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

We have the exact same issue with SecurID tokens. Many IT professionals are carrying around numerous of the tokens just because the authentication systems don't interact with each other.

I've posted in the same forum about this before, and I'll say it again... We need an "identity" layer. All the Yubikey provides is to prove that "someone" has "that particular" key. It does not prove that I have it.

I don't think we should focus too much on the Yubikey. It is just an enabler, we need something else, something that can manage your identity, almost like OpenID and what Clavid is doing, but with better integration, simpler APIs, and better support. Then it won't matter how many Yubikeys you're carrying around -- as long as you can prove your identity, you're set.

My thoughts at least...

Cheers

Massyn