Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 10:39 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Wed Nov 25, 2015 1:24 pm 
Offline

Joined: Wed Nov 25, 2015 12:33 pm
Posts: 2
We are beginning to use Yubikeys for two-fact auth (we'll be using Yubikey OTP, nothing else), and I've realised that I don't fully understand the usage and standards regarding the OTP public identities.

Background:

Currently, our test service uses authentication via the Yubicloud service - that all works fine, with Yuibikeys fresh 'out-of-the-box'. However, we will *probably* want to set up our own authentication servers internal to our network, so that authentication can continue to work if/when we have a complete external network outage. So, in order to get the AES keys, I need to reprogram slot 1 of our Yubikeys. The ideal situation might be if our keys were able to be authenticated via both our own authentication servers, as well as the Yubicloud service (though I realise that that opens up some possibility of OTP replay attacks.)

So, various questions:

1. Is it possible to use the personalization GUI to reset the AES key, but to retain the existing public identity - and then have the new AES key uploaded to the Yubicloud servers?

2. Am I right in assuming that all 'cc....' public identities which come with fresh 'out-of-the-box' Yuibikeys are guaranteed to be unique?

3. The personalization GUI autogenerates new 'vv....' public identities which are then able to be uploaded to the Yubicloud servers. What guarantee is there that such identities are not already present on the Yubicloud servers? And what happens on the Yubicloud servers in the event of such a clash?

4. What is the significance of the 'vv' (= 0xFF) prefix?

5. Referring to section 5.4 of the Yubikey manual, is the 'customer prefix' part of the six byte public identity? Are the currently-assigned customer prefixes currently 'accessible as a global repository'?

Thanks for any explanations.


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

PostPosted: Wed Nov 25, 2015 4:48 pm 
Offline
Site Admin
Site Admin

Joined: Mon Dec 08, 2014 2:52 pm
Posts: 314
1. Is it possible to use the personalization GUI to reset the AES key, but to retain the existing public identity - and then have the new AES key uploaded to the Yubicloud servers?

Yes, there are 2 configuration slot in the Yubikey OTP side. You can configure slot 2 with your won custom generated credential. You can also move pre-configured credential from slot 1 to slot 2, and generate a new custom credential in slot1

2. Am I right in assuming that all 'cc....' public identities which come with fresh 'out-of-the-box' Yuibikeys are guaranteed to be unique?

Yes, those are unique.


3. The personalization GUI autogenerates new 'vv....' public identities which are then able to be uploaded to the Yubicloud servers. What guarantee is there that such identities are not already present on the Yubicloud servers? And what happens on the Yubicloud servers in the event of such a clash?

Yes, they will be unique, no clashes.


4. What is the significance of the 'vv' (= 0xFF) prefix?

Nothing, it is just a reserved names space to make everything easier. We know that YubiCloud validates CC and VV names space. All other name spaces are for customers to choose and use within internal validations

5. Referring to section 5.4 of the Yubikey manual, is the 'customer prefix' part of the six byte public identity? Are the currently-assigned customer prefixes currently 'accessible as a global repository'?

No, they are not.


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 25, 2015 11:32 pm 
Offline

Joined: Thu Oct 16, 2014 11:51 pm
Posts: 82
Yubico's Tom2's answers are solid and outline the ability of two different AES keys to reside in the two available slots (short-press=slot 1, long-press=slot 2) to allow for two different Yubico OTP validation services to be used: theirs + yours or yours + yours.

Used in that way, you can:
1) swap slots, which moves yubico's key to slot 2 (if you prefer to give priority to your internal service)
2) put your internally generated key in the other slot (slot 1 if you do the above) for use with your own authentication servers.
3) validate against your internal service or yubico's service as needed.

One additional clarification:

Just in case you were planning to try to upload the exact same key to both your internal server as well as yubico's servers: this won't work.

Why? To prevent replay attacks, the Yubico OTPs depend on locally incremented power-on and usage counters which are internal to the key and associated with the key and slots. These are part of the encrypted/hashed data used to generate each OTP. Verification tracks their presumed position and allows only the handful of codes generated "not too many steps" from the last known position of the counters (which are then updated server-side on each successful validation).

Using two separated verification services that do not synchronize the counter positions means that one service will very likely lag behind the other and then the key will no longer be accepted. And re-syncing with one service starts pushing it out of sync with the other.

Brendan


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 27, 2015 3:11 pm 
Offline

Joined: Wed Nov 25, 2015 12:33 pm
Posts: 2
Thanks for the responses. I've now got a couple of resulting questions:

Tom2 wrote:
... You can also move pre-configured credential from slot 1 to slot 2, and generate a new custom credential in slot1


Thanks very much: that sounds exactly what we'd like to do, but I didn't realise it was possible to do it via the personalization tools. I'll give it a try.

Tom2 wrote:
durks wrote:
Referring to section 5.4 of the Yubikey manual, is the 'customer prefix' part of the six byte public identity? Are the currently-assigned customer prefixes currently 'accessible as a global repository'?


No, they are not.


I assume your reply corresponds to the second of my two questions, right?

So, for my own understanding, can you clarify whether or not the 'customer prefix' is supposed to part of the six byte public identity?

Beyond that, I am struggling to understand some of the detail on section '5.4.1. Interoperability guidelines in Yubico OTP mode' in the Yubikey Manual.

For example, the manual says that public IDs should be six bytes (i.e. the default config) to remain interoperable, but then goes on to say that such IDs are interoperable if (and only if?) the first byte is 0x28 (=modhex dj). How would that square with the use of a 'customer prefix'?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group