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

[Joseph Salowey]

I support adoption.

Joe

On Wed, Sep 4, 2024 at 7:50 AM Joel Kamp  wrote:

> I support adoption.
>
> On Tue, Sep 3, 2024 at 5:49 AM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> As per the discussion in Vancouver, this is a call for adoption for the 
>> *Proof
>> of Issuer Key Authority (PIKA) *draft:
>> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
>>
>> Please, reply on the mailing list and let us know if you are in favor or
>> against adopting this draft as WG document, by *Sep 17th*.
>>
>> Regards,
>>  Rifaat & Hannes
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11

[Joseph Salowey]

On Sat, Feb 20, 2021 at 12:42 AM Vittorio Bertocci <
vittorio.berto...@auth0.com> wrote:

> Thank you Joseph for your comments!
>
>
[Joe] Thanks for your response, comments inline below:


> > 1.  (Editorial) What is the relationship between this document and RFC
> 7523.
> >   They are using JWT for different purposes, but I think it would be
> useful to
> >clarify this in the introduction.
> Good point, I agree it would be good to preempt doubts on this. I am
> suggesting to append the following language to the current introduction
> (pardon the XML).
>
> Please note: although both this document and  both
> use JSON Web Tokens in the context of the OAuth2 framework, the two
> specifications differ in both intent and mechanics. Whereas  defines how a JWT Bearer Token can be used to request an access
> token, this documents describes how to encode access tokens in JWT format.
>
>
[Joe] Yes, that looks good to me.


> >2.  (Issue) The specification does not specify any mandatory to
> implement for
> >the recommended asymmetric algorithms.  This will not help interop.
> Perhaps
> >specify one or both of  "RS256" and "ES256".
> The current text doesn’t mandate a format for two main reasons:
> - thanks to the AS metadata the negotiation between a RS and an AS is very
> easy to perform, hence the likelihood of interop issues at runtime is very
> low
> - worries that as crypto advances, what we mandate at this point might no
> longer be suitable.
> That said, if you feel strongly about this please do let me know, and I
> will be OK with adding RS256 as a mandatory supported alg for both AS and
> RS.
> From a cursory check, ES256 doesn’t seem to enjoy as widespread support at
> the moment (see https://jwt.io/ libraries list) hence I would be hesitant
> to make it mandatory.
>
>
[Joe] I think you should add RS256 as mandatory to implement.  Since RFC
7518 does not mandate an asymmetric algorithm it's possible that two
implementations make different choices on which one to support.


> >3. (Question) Is it currently possible to use the JWT access token in
> a mode
> >other than a bearer token?  For example is there a way to bind the
> JWT to a
> >verifiable key or identifier.  If there is, there should be some
> discussion of
> >this in the security considerations.  If not, do the authors know if
> there is
> >any work planned in this area?
> At this time, the main mechanisms that can work with non-bearer ATs are
> dPOP and MTLS. In both cases, the binding mechanism relies on a cnf claim
> (or reference to it) - which can be added to a JWT access token without
> changing any of the guidance in this specification. There's a quick primer
> for both approaches in
> https://auth0.com/blog/identity-unlocked-explained-episode-1/. Given that
> there are no changes in the AT format and verification, and MTLS/DPOP would
> be purely additive, any language here would likely be functionally
> equivalent to "You should be aware that MTLS exists, and the tokens defined
> here do not break it" (DPOP isn’t mentioned because it's still in progress)
> but my intuition is that the compatibility should be assumed, with a note
> being required when it's not the case and the reader should be aware of
> potential problems. What do you think?
>
>
[Joe] Thanks for the explanation. I don't think there needs to be anything
added to the document for this.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Joseph Salowey]

I think Signed JWK sets are useful and would like to see them used in more
use cases so separating out the specifications seems like a good idea.  We
will have to be careful specify what security and deployment properties you
are trying to achieve in different use cases.

On Tue, Mar 19, 2024 at 11:36 AM Watson Ladd  wrote:

> On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes  wrote:
> >
> > Hi Watson,
> >
> > I appreciate the concerns with regard to re-using Web PKI certs for
> cases such as these.  Care is required, but I think there is a path here.
> >
> > 1. Clearly there are cross-protocol concerns.  I expect that most usage
> here in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I
> would be comfortable with security considerations recommending that a key
> pair / certificate used for signing these things be used for no other
> purpose.
> >
>

[Joe] I think there may also be a consideration in some environments that
problems could arise if keys not intended for signing JWK sets could be
used to sign JWK sets.


> > 2. Validity times are definitely a challenge for the container signing
> use case, but from the conversations I've had with that community, they are
> taking an orthogonal approach.  As I tried to sketch in the document, they
> are establishing authorities that will vouch that a signed thing existed at
> a given time, so that a relying party can safely rewind their clock and
> validate as if it were that time.  See, e.g., SigStore <
> https://www.sigstore.dev/>, which has roughly this shape if you squint
> right.
>
> That should work out: might want a security considerations saying this.
>
> >
> > 3. I don't think there's actually any disconnect between HTTPS
> authentication and proof of authority.  The Web PKI is about authenticating
> domain names, which is what both use cases require.
>
> Only with certain validation methods. Others like agreed upon change
> to site content have a narrower scope and the BRs reflect this
> subtlety. To be honest you're probably safe and I am not the expert
> here.
>

[Joe] I think this can work and be useful in many cases, but there may be
some subtleties here that should be considered.  All the more reason to
document this.


> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming token

[Joseph Salowey]

Hi Atul,

I'm just starting to review the transaction tokens draft and have only a
minimal understanding of the token exchange document at this point so I'm
lacking a little background, but I have a few comments and questions below.

On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale  wrote:

> Hi all,
> We had a meeting today (notes here
> ) in which we discussed the
> question of what we should do if there is no incoming (external) token in
> the request to issue a Transaction Token
> 
> (TraT). We identified a few circumstances under which this can happen:
>
>- The requesting service is triggered by a non-OAuth based flow such
>as email or an internal trigger
>- The client of the requesting service uses means other than an access
>token to authorize the call (e.g. MTLS)
>
> [Joe] I think there will be a fair number of systems that support means of
authorizing non-oauth flows.



> We identified a few possibilities listed below. Please note that the
> Transaction Tokens draft assumes that the TraT Service trusts the
> requesting service, so all the possibilities below assume this.
>
>
[Joe] yes, you are trusting another part of the system to perform some
authorization and inform the token service of the result.


> Here are some possibilities we discussed:
>
>1. *Request Details*: Put the subject information in the
>request_details parameter of the TraT request, and the subject_token value
>is set to "N_A"
>2. *Self-Signed Token*: The requester generates a self-signed JWT that
>has the subject information and puts that in the subject_token value
>
> [Joe] I like having signed tokens, but if this is really information just
exchanged between two endpoints it may be more work than necessary.

>
>1. *Separate Separate Endpoint*: The TraT service exposes a separate
>endpoint to issue TraTs when there is no incoming token, and that endpoint
>can be defined such that the request does not have a subject_token
>parameter. This endpoint is not a profile of OAuth Token Exchange
>2. *Separate Endpoint Only*: Extending the thought above, the
>requester can always extract the content of the incoming token into the
>"request_details" parameter, so why do we need the Token Exchange endpoint
>
> [Joe] What do we gain by using token exchange? While it seems that there
is overlap between delegation/impersonation it seems that transaction
tokens are sort of a superset and contain additional information about the
context of the transaction.   If it looks like token exchange is too
constraining then transaction tokens may just be a different use case.
With the understanding I currently have I'd either go with 4. Separate
Endpoint Only or 2. Self Signed token.  Splitting the endpoints could be
valid, but it seems a bit weird for me, if we did decide to do that then
probably we wouldn't need to sign the information unless the request is
going to traverse multiple systems.



> We would like to understand how the group feels about these choices, or if
> you have other suggestions / thoughts on this topic.
>
> Thanks,
> Atul
>
> --
>
> 
>
> Atul Tulshibagwale
>
> CTO
>
>  
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Comments on draft-ietf-oauth-transaction-tokens-01

[Joseph Salowey]

I have reviewed the Transaction Token document.  In general I think it is a
needed document and I am glad there is work in this area. I have some
questions and comments below:

1. Section 4 defines Trust Domain and seems to point to RFC 7519.  I
couldn't find any reference to trust domain in 7519.

2. Why would you not include a kid claim? it seems that key rotation should
be supported. Is there harm in requiring a kid?

3. From the text, I don't really understand what the purp: claim is for.

4. One of the things I expected to see in some txn-tokens is a
username/email, but I did not see that in any examples, while there are
privacy considerations here, is there a reason why it is not included?
Would this be in the rctx: or the azd: claim? It not clear when I would use
azd or rctx for a particular data value.

5. As discussed on the list I think there may be cases where there will not
be an Oauth token to exchange.  THe decision is that this is out of scope
for this document, but the case should probably be mentioned.

6. Is it intended that a single transaction token service endpoint can
serve more than one trust domain? (it seems like the protocol supports, but
I am not sure if it is a design goal).

7. For a replacement token  7.4 it says the replacement may not change the
rctx, but does not say anything about the azd.   In section 5.2 it says
that azd: remains immutable during the call chain.  It seems that these two
things do not line up and the replacement token needs something to change.
 Perhaps azd is not immutable?  What are the asserted values that may
change referred to in 7.4.1.

8. Section 7.5 is referring to OAUTH client authentication? Should it refer
to RFC 8705 for mTLS/SPIFFE case?

9. Section 9.1 it probably should be mentioned earlier in the document that
a transaction token cannot be issued based on a refresh token.

Once again, thanks for your work on this document, I think it will be very
useful.

Joe
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Joseph Salowey]

The mechanism in the draft provides some separation between the trust
establishment and distribution which is useful.  This is definitely
applicable to the use cases described in the draft and I agree with Ethan
that it can help in other areas as well depending upon how things are
deployed.  I support this draft.

Joe

On Thu, Apr 11, 2024 at 7:16 PM Ethan Heilman  wrote:

> Hi Neil,
>
> I agree that PIKA would not protect against an attacker compromising a
> JWKS URI via a mis-issued TLS cert.
>
> I was thinking of a simpler attack where the attacker compromises the
> server where a JWKS URI is hosted or the JWKS is stored. For instance
> consider an JWKS which is read from a database. An attacker could use a SQL
> injection to add their own key to the JWKS. Because such an attacker does
> not compromise any TLS certificates PIKA would defeat this attack (assuming
> the verifier required PIKA for that JWT issuer).
>
> Today, write access to a JWKS is sufficient to comprise the signing
> authority of a JWT issuer. With PIKA write access to a JWKS may not be
> sufficient to compromise the signing authority of a JWT issuer.
>
> Thanks,
> Ethan
>
>
> On Thu, Apr 11, 2024 at 5:15 PM Neil Madden 
> wrote:
>
>> On 11 Apr 2024, at 01:12, Ethan Heilman  wrote:
>>
>>
>> I want to voice my support for this draft: Proof of Issuer Key Authority
>> (PIKA). The ability to reason about the past validity of JWKS is extremely
>> useful for using OIDC in signing CI artifacts and e2e encrypted
>> messaging.This includes what we are building at OpenPubkey (
>> github.com/openpubkey/openpubkey) and also proposed security
>> improvements to software supply chain systems like SigStore (
>> https://arxiv.org/pdf/2307.08201.pdf).
>>
>> I want to underscore the value of PIKA to increase the security of JWKS
>> URIs and OpenID Connect. Currently if an attacker compromises an OpenID
>> Provider's JWKS URI the attackers can substitute their own public keys and
>> impersonate any user to any relying parties who depend that OpenID
>> Provider. The effects of Google, Microsoft or Okta's JWKS URI being
>> controlled by a malicious party for even a few minutes could be
>> devastating. The widespread deployment of PIKA would remove this risk and
>> require that attackers compromise not only the JWKS URI but also the PIKA
>> signing keys.
>>
>>
>> I'm still digesting this draft, and generally supportive of it. However,
>> I don't think it stops the attack you mention here, which sounds similar to
>> threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
>> current OIDC model, an attacker that briefly compromises the jwks_uri of an
>> OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing
>> public keys under their own control with a long Cache-Control header.
>> Clients then might blindly cache that key set even beyond the time when the
>> certificate is revoked and the rightful owner restored.
>>
>> But I think this attack is basically the same even with PIKA. The
>> attacker in this case just uses their mis-issued cert to sign the PIKA and
>> serve that instead, perhaps putting a really long "exp" claim in it so that
>> clients cache it for a really long time. The only thing that would stop
>> that is if the draft insisted that clients regularly perform an OCSP or CRL
>> lookup on the cert in the x5c chain to make sure it hasn't been revoked.
>> But that would completely negate the benefits of avoiding clients all
>> hitting the OP jwks_uri: we've just shifted the burden from the OP to the
>> CA.
>>
>> Perhaps I'm missing something?
>>
>> [1]:
>> https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email
>>
>>
>> -- Neil
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Salowey]

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  wrote:

> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
>  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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11

[Joseph Salowey via Datatracker]

Reviewer: Joseph Salowey
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is the document has issues.

1.  (Editorial) What is the relationship between this document and RFC 7523. 
They are using JWT for different purposes, but I think it would be useful to
clarify this in the introduction.

2.  (Issue) The specification does not specify any mandatory to implement for
the recommended asymmetric algorithms.  This will not help interop.  Perhaps
specify one or both of  "RS256" and "ES256".

3. (Question) Is it currently possible to use the JWT access token in a mode
other than a bearer token?  For example is there a way to bind the JWT to a
verifiable key or identifier.  If there is, there should be some discussion of
this in the security considerations.  If not, do the authors know if there is
any work planned in this area?

4. Genart review pointed out a nit that should be fixed.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Secdir telechat review of draft-ietf-oauth-access-token-jwt-12

[Joseph Salowey via Datatracker]

Reviewer: Joseph Salowey
Review result: Ready

Thank you authors.  This version addresses all my comments.  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth