- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Thu, 29 Jun 2023 12:09:55 +0300
- To: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jun 28, 2023 at 01:28:53PM -0700, David Schinazi wrote: > Hello HTTP enthusiasts, > > The authors of draft-ietf-httpbis-unprompted-auth collected all the > feedback we received during and since IETF 116, and wrote a new revision > that attempts to address all of it. The major changes from -02 are: > > * Instead of defining a new "Unprompted-Authentication" header, we use > Authorization/Proxy-Authorization and instead create a new "Signature" HTTP > auth scheme (we dropped the HMAC option) > * We added the origin, realm, key ID and signature algorithm to the key > exporter context > * We send a portion of exporter output in addition to the signature > * We added a prefix to the signature input to mitigate key reuse issues > (even though reuse is banned) > > The updated draft is at: > https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-auth/ > > We'd love to hear your feedback. Some quick comments (this includes -04): - Using sf-binary is creating great deal of unnecressary complexity. Much simpler would be to use base64url for binary fields. Furthermore, it turns out all base64url characters are token-valid, so one would not even need the double quotes! - I don't think inserting delays to hide if validation succeeded or failed is a good idea. Another way to deal with it would be to always try to validate the signature if in scope with protected resources. This can abort early e.g., if key is not found. - There was a review comment about relative appeal of the options of doing validation in the TLS terminator versus pushing it downstream. Two reasons one might want to push the validation downstream are: 1) Avoiding configuration logistics challenges with keys. 2) The backends being better equipped to deal with load compared to the TLS terminator (especially if using HTTP/3). There was also comment about TLS terminator to be better equipped for caching. It seems to me that backend could cache N most recent successful nonces, and skip validation if nonce is found in the cache. I noticed that there does not seem to be one place that contains the headers that should be dropped unless configured otherwise (for trusted reverse proxy upstream). Here is a list of such headers from some piece of code I wrote: - client-cert - client-cert-chain - x-src-ip - x-real-ip - x-forwarded-* (i.e., anything starting with "x-forwarded-"). Which gives very dirty idea of using something starting with x-forwarded- for signaling this stuff. -Ilari
Received on Thursday, 29 June 2023 09:10:03 UTC