search

usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
58 stars 20 forks source link

Authentication, TOTP and the TOTP Window #40

Open AlexThurston opened 3 years ago

AlexThurston commented 3 years ago

environment Demo and Production

Endpoint in which the error is experienced POST https://demo.acvts.nist.gov/acvp/v1/login

The dilemma I am running into has to do with the adherence to the TOTP windows (which if I'm not mistaken is 30s). We have a system that needs to be able to asynchronously and intermittently (when required) refresh tokens that may have expired. This system services a team of people who each have their own subset of test sessions that they are currently working on. The bulk access token route doesn't solve my issue because I cannot control when a particular user will have a single or collection of test session JWTs that need to be refreshed. More specifically, two users could interact with the system seconds apart trying to interact with different test sessions. The first person will be allowed, but the second person will not be able to refresh their token because the TOTP Window has already been used as the error states.

Hopefully I've described the problem well enough.

smuellerDD commented 3 years ago

Am Donnerstag, den 19.11.2020, 15:10 -0800 schrieb Alex Thurston:

environment Demo and Production

Endpoint in which the error is experienced POST https://demo.acvts.nist.gov/acvp/v1/login

The dilemma I am running into has to do with the adherence to the TOTP windows (which if I'm not mistaken is 30s).  We have a system that needs to be able to asynchronously and intermittently (when required) refresh tokens that may have expired.  This system services a team of people who each have their own subset of test sessions that they are currently working on.  The bulk access token route doesn't solve my issue because I cannot control when a particular user will have a single or collection of test session JWTs that need to be refreshed.  More specifically, two users could interact with the system seconds apart trying to interact with different test sessions.  The first person will be allowed, but the second person will not be able to refresh their token because the TOTP Window has already been used as the error states.

Hopefully I've described the problem well enough.

Either you have a central TOTP server that everybody is accessing to get a value, or you have organizational means to control the access to the seed or you get different credentials for each user. But that would imply each user must complete the full test cycle on their own.

Ciao Stephan

AlexThurston commented 3 years ago

Bah! I feel stupid asking this question. Of course! Thanks very much!

AlexThurston commented 3 years ago

I might have jumped the gun on my excited for this issue having a solution. I don't think that centralizing the TOTP server is actually going to help.

The fact doesn't change that once a TOTP is generated and used, the same TOTP cannot be used for any subsequent auth actions for 30 seconds. And I can't generated a new one since the internal is set to 30 seconds. Unless I'm missing something, for any given seed password, the same TOTP will be generated for a given interval. Whether the TOTP service generating is centralized or not, the same value will be created.

AlexThurston commented 3 years ago

To say it another way, I can only hit the /login route once every 30 seconds.

smuellerDD commented 3 years ago

Am Freitag, 20. November 2020, 18:59:44 CET schrieb Alex Thurston:

Hi Alex,

I might have jumped the gun on my excited for this issue having a solution. I don't think that centralizing the TOTP server is actually going to help.

The fact doesn't change that once a TOTP is generated and used, the same TOTP cannot be used for any subsequent auth actions for 30 seconds. And I can't generated a new one since the internal is set to 30 seconds. Unless I'm missing something, for any given seed password, the same TOTP will be generated for a given interval. Whether the TOTP service generating is centralized or not, the same value will be created.

Yes, that is right. That is why I asked for the multi-login facility /login/ refresh to refresh multiple JWT with one TOTP value.

At the same time, with one TOTP value you can perform multiple requests which each is given one JWT.

That said, for one user, the limitation with the TOTP does not really exist. For the demo server, each user has his own TOTP seed / certificate which implies that for the demo server, I see no limitation with the TOTP.

But if you have multiple users for one given TOTP seed / certificate (e.g. prod server), then you have the limitation that they can only have one authentication globally within 30 seconds. If this is a problem for you, maybe, NIST can issue you multiple different TOTP seeds connected with one (lab) certificate.

Ciao Stephan

AlexThurston commented 3 years ago

We have one set of credentials organizationally so it’s a bit of a predicament.

I wonder if there is something that can be done on ACVPs end to address this use case.

smuellerDD commented 3 years ago

Am Sonntag, 22. November 2020, 21:46:03 CET schrieb Alex Thurston:

Hi Alex,

We have one set of credentials organizationally so it’s a bit of a predicament.

I wonder if there is something that can be done on ACVPs end to address this use case.

As I said, Chris may check whether it is poaaible to allow more than one TOTP seed per certificate. This way you could use different TOTP values at the same time and yet have a common certificate to use the same JWT by different users.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/usnistgov/ACVP-Server/issues/40#issuecomment-731844543

Ciao Stephan

AlexThurston commented 3 years ago

@celic Any word if what I can do to make my use case possible?

celic commented 3 years ago

We definitely prefer that each user has their own certificate and then this is no longer an issue. That would be the solution here in my opinion. If you would like to set that up, please email Jason Arnold. (Who is out this week, holiday in the US).

smuellerDD commented 3 years ago

Am Montag, den 23.11.2020, 08:14 -0800 schrieb Chris Celi:

We definitely prefer that each user has their own certificate and then this is no longer an issue. That would be the solution here in my opinion. If you would like to set that up, please email Jason Arnold. (Who is out this week, holiday in the US).

This is no option unfortunately that will satisfy all users. The problem is that with this solution you bind a specific test session to one and only one lab member.

However, assume you have one lab member who triggers the registration. Now, we forward the vectors to the customer for processing which may take some days. Then, this lab member becomes ill or is on vacation. Now, you need to wait until he is back as no other user can reuse his JWT.

celic commented 3 years ago

Let me make sure I get this straight so I can bring this to the team...

Users want JWTs to be shareable between their respective teams so they can collaborate on submissions. TOTP windows restrict the ability for multiple users to use the same certificate to accomplish this goal. ACVP Server would prefer that each individual user has a separate certificate.

Is there anything I am missing? We may be able to accommodate this rather efficiently.

smuellerDD commented 3 years ago

Yes, I think you are right on the mark.

Ciao Stephan

— Cui bono?

Am 23.11.2020 um 17:39 schrieb Chris Celi notifications@github.com:

 Let me make sure I get this straight so I can bring this to the team...

Users want JWTs to be shareable between their respective teams so they can collaborate on submissions. TOTP windows restrict the ability for multiple users to use the same certificate to accomplish this goal. ACVP Server would prefer that each individual user has a separate certificate.

Is there anything I am missing? We may be able to accommodate this rather efficiently.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

AlexThurston commented 3 years ago

I think that about covers it. If you need more specific use-cases or examples I can certainly describe them in more detail.

celic commented 3 years ago

When we have something concrete I'll share it to gather some feedback. Right now we are considering an endpoint where a user can request a JWT to access an existing TS. It would only be granted if the user belonged to the same lab.

AlexThurston commented 3 years ago

I had a thought (and maybe I'm mistaken) but was there a period early on in ACVP where the TOTP windows (30 seconds) wasn't being enforced? Could a simple, stop-gap, solution be to turn it off for demo until we have a long-term solution? If can be kept active on production.

celic commented 3 years ago

Correct, it was not enforced on the old server architecture. That's not something we can change though.

On Thu, Nov 26, 2020, 2:05 PM Alex Thurston notifications@github.com wrote:

I had a thought (and maybe I'm mistaken) but was there a period early on in ACVP where the TOTP windows (30 seconds) wasn't being enforced? Could a simple, stop-gap, solution be to turn it off for demo until we have a long-term solution? If can be kept active on production.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP-Server/issues/40#issuecomment-734445952, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQXEO33RAYTO2AJYIZLADSR2RGLANCNFSM4T4BIOZQ .

AlexThurston commented 3 years ago

Not to pile on, but another use case and way in which this seems to be causing some consternation is with our unit and integration tests. These obviously run very quickly but are written to be independent from each other so there is often login actions that happen within the 30 second window.

AlexThurston commented 3 years ago

I was wondering if there was any thought or way forward on this use case? Not sure if it would work, or adhere to the spirit of the TOTP, but I had a thought on how this might be addressed. What if the TOTP window was applied to a token individually?

That is to say that you can use the same TOTP value for different tokens, but you can't use the same TOTP for the same token.

For example, let's say you had 3 access tokens A1, B1 and C1. And a TOTP T1

For a given TOTP window:

AlexThurston commented 3 years ago

I was wondering if there was any thought or movement on how this might be addressed as a use case. As our system grows and more and more test sessions are being maintain, I suspect it is only going to exacerbate the dilemma.

AlexThurston commented 3 years ago

I had a thought on how this might be addressed for one of our use cases.

Would it be possible to make the expiry of the access token generated for a test session match a test session's expiry (ie, 30 days?). This would mean that access tokens specifically for test session would not need to be refreshed during the test sessions life which will reduce the need to generate TOTP when dealing with test sessions?

This would means that we can manage a large number of test sessions, asynchronously without having to worry about their access tokens expiring before they've expired. I appreciate that this extends the life of an access token but these are only for test sessions so the potential exposure is small. AFAIK, the data within a test session ends up being public and is not normally proprietary or sensitive.

If this still bring security concerns then perhaps it could be only applied to Demo. Although having it consistent across both deployment would be ideal.

AlexThurston commented 3 years ago

Would it be possible to make the expiry of the access token generated for a test session match a test session's expiry (ie, 30 days?). This would mean that access tokens specifically for test session would not need to be refreshed during the test sessions life which will reduce the need to generate TOTP when dealing with test sessions?

Any thoughts on this as a. potential solution to making the management of a large number of test session more adaptable to asynchronous tooling?