ietf-wg-httpapi / httpapi-privacy

Pre-adoption draft for HTTPAPI about not exposing api keys
Other
0 stars 0 forks source link

Revoking signature-based authentication #8

Open Acconut opened 1 month ago

Acconut commented 1 month ago

The draft recommends revoking credentials if they are received over an insecure channel. This makes sense for requests which directly include an API key, for example as a Bearer token, because an eavesdropper can directly see and abuse the API key.

Another common form for API authentication is using an authentication pair consisting of a pair ID for identifying the user and a secret, which is only known to the service provider and the user. An authenticated request then includes the pair ID and a signature generated with a HMAC and the secret. The request does not directly include the secret. AWS uses this approach, for example.

If an attacker eavesdrops on such a request, they obtain knowledge about the pair ID, but not the secret. While leaking the pair ID may not be ideal, obtaining the ID and signature does not allow an attacker to abuse the authentication pair and forge signatures. Should in these cases the authentication pair still be revoked? Should the draft distinguish between requests that directly include the secret credentials and those which include signatures?

richsalz commented 4 weeks ago

So instead of key material, a key identifier is passed. I agree that it is reasonable to send that in the clear. The text should make it (sic) clear that sending a key identifier is NOT the same as sending a key, and that this can be okay.