[OAUTH-WG] Re: Call for adoption - PIKA

[Giuseppe De Marco <[e-mail]>]

Hey Richard,

Openid Discovery apparently doesn't get popular in the gov field, or at
least not alone and without some sort of trusted registries.
Openid Connect didn't get wide adoption in the R&E field that is still
using SAML2 with x.509 certificates mixed with a secured metadata exchange
mechanism mediate by trusted third parties, where the X.509 certificates
are distributed within the metadata and without any revocation mechanism
based on CRL/OCSP.

The previous two examples represent two important real-world large scale
deployment domains.

PIKA is a trust framework aiming to support the main trust model categories
we may have in mind, that we can categorize as follows:

Direct Trust: Trust is established directly between two parties without
intermediaries (bilateral relationship).
Third-Party Trust: Trust is facilitated by a trusted third party (Trust
Anchor, mechanisms of transitive trusts included).
Web of Trust: Each participant makes individual decisions about whom to
trust (end to end or multiple Trust Anchors)

DNS+TLS attests entities identity and cryptographic material for
confidentiality of the transport, using encryption; and proof of
ownership/authority for non repudiation, using signatures.

This is a basic requirement that we need. We need it also with any other
trust framework, be this based on DID resolution web methods or openid
federation or anything else RESTful or SOAP, if web endpoint based.

The next level is represented by all the requirements related to the
mitigation about the following issues:

- spoofing attacks based on slightly modified FQDNs, the end user trusts
the FQDN and no other additional checks would block the attack
- spoofing attacks using open url injected during the transaction (the
example shared in my previous email)
- lack of control about entities behaviour (LoA of the issued data,
accountability, rp overasking, categories of audiences, categories of
services offered ...)
  - early prevention of protocol/cryptography misues (disable a weka
algorith automatically in a multilateral federation)
- proof of realiability about specific compliances (security, regulations,
frameworks, other industrial ...)

metadata are crucial for this, since these forces the entity configurations
and provide mitigations to the issues. The trust framework should offer at
least a way to achieve this, because it should aim to be a framework
allowing the impl to use its tools to solve the common problems.

we may have different metadata for different scopes: administrative,
protocol specific.
we should have multiple cryptographic keys for different scopes: trust,
application protocols such as particular roles or features (key for AS, RP,
RS)

I am interested expanding the scopes of PIKA to offer in its framework one
or more solutions to the issues listed above if PIKA aims to provide
solutions to common problems.
In PIKA I read that its sole scope is "define a format for Proofs of Issuer
Key Authority", if confirmed no pain, it's legitimate (apologies for having
forced you in useless conversations).

According to the current PIKA draft, here my revision points:

- OpenID Federation (remove Connect)
- the revocation reasons in draft 35 was changed and simplified, please
update them accordingly or specify that for the scopes of PIKA other are
defined (in particular if expired to RFC 5280, as they was in openid
federation before the latest changes)
- the openid federation historical keys endpoint response contains only
public keys not valid anymore

good work, never stop


Il gio 27 giu 2024, 17:07 Richard Barnes <[e-mail]> ha scritto:

> Hi Giuseppe,
>
> Asking whether a technology addresses real-world challenges is a fair
> question.  The point of the current draft is that we have empirical
> evidence that X.509-based authentication works well for many cases, given
> the very wide usage of things like OpenID Connect Discovery.  PIKA seeks to
> address some operational deficiencies in those models, without changing the
> trust model.
>
> --Richard
>
> On Wed, Jun 26, 2024 at 8:21 PM Giuseppe De Marco <[e-mail]>
> wrote:
>
>> Hi Ethan,
>>
>> I have experience implementing LDAP clients with SASL and SSL, SAML2 SP,
>> IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509
>> is foundational to our digital infrastructure, making implementation
>> straightforward due to the widespread availability of supporting libraries.
>>
>> However, X.509 has not addressed all issues; it would be unwise to ignore
>> its limitations and pretend it fits all needs perfectly.
>>
>> I can be an advocate for PIKA and am eager to delve deeper into the
>> technical trust requirements envisioned by the PIKA working group
>> participants. A new specification should aim to tackle the unresolved
>> issues.
>>
>> Consider this real-world example to illustrate a point: Space Attack
>> Spoofing eIDs [1]. The article highlights a vulnerability due to the lack
>> of mechanisms for validating endpoints, which opens the door to
>> Man-in-the-Middle (MITM) attacks through spoofing.
>>
>> From my perspective, part of the solution lies in the trust framework
>> employed. Even with a vulnerability at one point, having trusted endpoints
>> could prevent the attack's success. If endpoints were cryptographically
>> attested through verifiable metadata certified by a trusted third party, or
>> through a trusted distribution method or trusted policy processing, the
>> attack would likely fail. The attacker would not be able to redirect data
>> to fraudulent endpoints.
>>
>> Regardless of the technology, data format, or other elements used, these
>> may not align with our personal preferences or comfort levels, I am
>> interested in discussing the level of technical trust evaluation we aim to
>> incorporate into PIKA. Specifically, which problems are we aiming to solve,
>> and which are we deliberately excluding from the scope of this new
>> specification.
>>
>> When selecting a technology for implementation, it is essential to assess
>> whether it addresses real-world challenges effectively. I am here to
>> investigate if PIKA meets these criteria currently or in the foreseeable
>> future, and to understand the roadmap for its development, if available.
>> This evaluation is vital for trusting a specification.
>>
>> I was too verbose, I am sorry.
>> Giuseppe
>>
>> [1]
>> https://ctrlalt.medium.com/space-attack-spoofing-eids-password-authenticated-connection-establishment-11561e5657b1
>>
>> Il giorno mer 26 giu 2024 alle ore 19:08 Ethan Heilman <[e-mail]>
>> ha scritto:
>>
>>> I strongly support this draft and would have immediate uses for PIKA
>>> if standardized.
>>>
>>> As someone who builds OIDC relying party software I am not worried
>>> about the X.509 certificate requirement, nor do I consider dependence
>>> on X.509s or the Web PKI to be an onerous requirement. I already have
>>> to deal with parsing and creating X.509 certificates in my relying
>>> party software.
>>>
>>> Given that JWK Set URI's use the Web PKI to authenticate the JWKs they
>>> serve via HTTPS, it only seems natural we would use that very same
>>> system, the Web PKI, to authenticate JWKs directly.
>>>
>>> Thanks,
>>> Ethan
>>>
>>>
>>> On Tue, Jun 25, 2024 at 8:46 PM Kristina Yasuda
>>> <[e-mail]> wrote:
>>> >
>>> > Sorry to chime in late as well…
>>> > I support adoption of this draft. I have read the thread and to me it
>>> seems like there is a mechanism being proposed that solved a concrete
>>> problem in a simple manner. Some of the discussion can happen after the
>>> draft is adopted.
>>> > Best,
>>> > Kristina
>>> >
>>> >
>>> > On Wed, Jun 26, 2024 at 7:49 AM Joseph Salowey <[e-mail]>
>>> wrote:
>>> >>
>>> >> Sorry to chime in late here. I'm in favor of adopting this draft.
>>> While I realize that X.509 isn't for everyone, there is an established
>>> community of users out there that overlaps with OAUTH users.  I think there
>>> are needs to both separate the distribution of the keys from the
>>> establishment of trust in those keys and in the auditability of the process
>>> of distribution.  I think this draft establishes a deployable mechanism
>>> based on existing technology.  X.509 is a good starting point and
>>> additional mechanisms can be added as needed.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Joe
>>> >>
>>> >> On Tue, Jun 25, 2024 at 3:12 PM Watson Ladd <[e-mail]>
>>> wrote:
>>> >>>
>>> >>> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
>>> >>> <[e-mail]> wrote:
>>> >>> >
>>> >>> > The other critique I voiced of the approach is that the
>>> application-level X.509 certificate can be used to secure the HOST part of
>>> the issuer, but not the entire issuer, since in general, the issuer will
>>> contain a PATH.  Yes, the service hosting the issuers controls all the
>>> paths, as Richard replied earlier, but it’s not the service who is the
>>> attacker that this enables.  The attackers that not securing the PATH
>>> enables are the tenants themselves.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > An attacker could host a tenant at the service and get an X.509
>>> certificate securing the HOST part of its issuer.  However, because a
>>> legitimate tenant at another path shares the same HOST, the attacker can
>>> copy its X.509 certificate chain and utilize a substitution attack to make
>>> unauthorized statements about the victim tenant – statements that were not
>>> made by the hosting service.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > This attack was not addressed, and I believe is intrinsic to the
>>> decision not to protect the entire issuer value.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > I believe that adopting this draft would result in this attack
>>> occurring in practice.
>>> >>>
>>> >>> To be clear, drafts get modified by the WG after adoption so adoption
>>> >>> is not the same thing as WGLC.
>>> >>>
>>> >>> However, I'm not sure I understand your attack scenario. If we have a
>>> >>> "tenant" distinguished by a path, there is already a security issue
>>> >>> with giving it the X509 certificate. It could then imitate any other
>>> >>> tenant on that server already. That's why we use reverse proxies and
>>> >>> put the certificate only on the proxying machines.
>>> >>>
>>> >>> Sincerely,
>>> >>> Watson
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Astra mortemque praestare gradatim
>>> >>>
>>> >>> _______________________________________________
>>> >>> OAuth mailing list -- [e-mail]
>>> >>> To unsubscribe send an email to [e-mail]
>>> >>
>>> >> _______________________________________________
>>> >> OAuth mailing list -- [e-mail]
>>> >> To unsubscribe send an email to [e-mail]
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list -- [e-mail]
>>> > To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>