* This is a new draft that attempts to define a useful convention for HTTP
authentication: a way to tell the client to open a browser window to start
authentication, and to close that window when authentication is complete.
Sure. Will 10 minutes+five for questions suffice?
__
* Relying on a fixed, random header name for security, even as a “defense
in depth” measure, is dangerous.
Thank you. +1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
How about requiring reverse proxies to automatically scrub all inbound HTTP
headers that start with "Sec-"?
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07
Making a header value “secret” will not protect anything.
___
OAuth mailing list
O
If you strip off the TLS, you *still* cannot pass messages around without
protecting them as if they had secrets because, well, the header name you are
using is secret. This is not a defense in depth.
___
OAuth mailing list
OAuth@ietf.org
https://www.i
* To quote your previous claim: "There is no such thing as an unguessable
name."
Right. That doesn’t mean *I* have to guess it.
* Even if your deployment team had such staggeringly bad operational
security practices as to allow people to take packet captures from an internal
network a
* I'm thinking of a uniformly random 16 byte name right now. Have at it.
Cute but missing the point. I don’t have to guess it. YOU have to securely
deploy it across your proxy (however many staff), your backend (however many
staff), your application developers (however many), and perhaps yo
* Again, authenticating the *connection* from the RP to the backend
services is good, but is completely orthogonal to authenticating the headers
themselves.
I strongly disagree. Authenticating the sender allows the receiver to make a
trust decision in the provenance and quality of the data
> But an unguessable header name is *simple* and effective and works right now
> with widely implemented functionality.
You mean like admin/admin for administrator access? There is no such thing as
an unguessable name. You claim the name will never be exposed to untrusted
parties. How so? Y
ifaat
On Mon, Oct 28, 2019 at 2:55 PM Salz, Rich
mailto:rs...@akamai.com>> wrote:
* To avoid the misconfiguration issue Neil raised, you probably need both:
a client-cert and a signature over the certificate being forwarded,
I am not so sure. One can argue that transport-level id
* To avoid the misconfiguration issue Neil raised, you probably need both:
a client-cert and a signature over the certificate being forwarded,
I am not so sure. One can argue that transport-level identity should be
secured by transport-level. But installing a client certificate on a revers
Sorry for jumping into this late.
Client <--> proxy <--> backend
The C/P side is protected by TLS. There must be similar protection on the P/B
side, such as client-cert, or a signature over the certificate being forwarded,
right?
___
OAuth mailing li
>Then you want OpenID Connect
great, thank you for the pointer.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Not to be pedantic, but adding OAuth support is a mechanism in support
of a goal. What's the end goal?
* Letting third party apps use the datatracker API?
* Letting people sign in to other apps with a datatracker account?
The latter.
__
>Do you want to enable applications to call datatracker APIs?
Not me, no. But I know of a couple that will be able to benefit
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
goal?
On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich
mailto:rs...@akamai.com>> wrote:
Thanks for the links, folks. I’m aware, and sorry for my sloppy terminology.
Imagine a service where anyone with a valid identity is authorized. There are
many of these on the net. Collapsing authentication
at, Aug 17, 2019 at 8:31 PM John Bradley
mailto:ve7...@ve7jtb.com>> wrote:
The openID Connect kind of OAuth server.
OAuth on its own is not designed to be secure for identity federation.
John B.
On 8/17/2019 1:23 PM, Salz, Rich wrote:
What’s the WG consensus (heh) on the best guide to adding OAUTH
What’s the WG consensus (heh) on the best guide to adding OAUTH support to an
existing server so that it can act as an identity provider? Which version of
oauth is most widely deployed by relying parties these days?
I want to add OAUTH support to the IETF datatracker.
Thanks for any pointers.
> A while ago, if I'm not mistaken, I glimpsed some report of vulnerabilities
> caused by incorrect public key comparison.
There was a recent issue raised by Hanno about incorrect public/private key
matching leading to incorrect revocation of a certificate; was that what you
were thinking of?
__
18 matches
Mail list logo
