from:"Daniel Fett"

[OAUTH-WG] Re: Éric Vyncke's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

2024-06-03 Thread Daniel Fett

Sorry, I got confused with the section numbers.

We did initially have the order "updated threat model", "best
practices", and then "attacks and mitigations", but feedback the WG got
was that we should put the best practices front and center. That's why
we moved the best practices to section 2, but we kept the updated threat
model as section 3 as we wanted to give the background that I mentioned
below before diving into the details in section 4.

-Daniel

Am 03.06.24 um 13:33 schrieb Daniel Fett:

Thank you for the feedback!

I would like to keep the order as it is. Section 2 is short, but
explains a bit on the background why certain requirements were not
contained in RFC6749 and RFC6819, but are now best practices described
in Section 3.

-Daniel

Am 14.05.24 um 16:15 schrieb Éric Vyncke via Datatracker:

Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-security-topics-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

--
COMMENT:
--

Thank you for the work put into this document.

Special thanks to Hannes Tschofenig for the shepherd's detailed write-up
including the WG consensus *BUT* the justification of the intended status is
rather light.

My only comment is more on the flow: for the non-expert reader, reading
sections 3+4 (threat) before will make it easier to undestanding the reasoning
behind section 2.

I am trusting the SEC and APP ADs for the technical correctness of the document.

___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Éric Vyncke's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

2024-06-03 Thread Daniel Fett

Thank you for the feedback!

-Daniel

Am 14.05.24 um 16:15 schrieb Éric Vyncke via Datatracker:

Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-security-topics-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

--
COMMENT:
--

Thank you for the work put into this document.

Special thanks to Hannes Tschofenig for the shepherd's detailed write-up
including the WG consensus *BUT* the justification of the intended status is
rather light.

My only comment is more on the flow: for the non-expert reader, reading
sections 3+4 (threat) before will make it easier to undestanding the reasoning
behind section 2.

I am trusting the SEC and APP ADs for the technical correctness of the document.

___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

2024-06-03 Thread Daniel Fett

Thank you, this will be addressed in the next version I'll release in a 
few minutes.


-Daniel

Am 14.05.24 um 17:49 schrieb Zaheduzzaman Sarker via Datatracker:

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-oauth-security-topics-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/



--
COMMENT:
--

Thanks for working on this specification.

One observation, does it add any value to mention the OAuth working group in
the following sentence after publication?

   Section 2 says - This section describes the core set of security mechanisms
   and measures the OAuth working group considers to be best practices at the
   time of writing.

If there is no significant value add factor here, the it might be better to
omit the working group name from sentence.



___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Mahesh Jethanandani's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

2024-05-13 Thread Daniel Fett


Thanks for the review, Mahesh!

I fixed the usage of "man", "he", and "traditional" in this PR: 
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/99


The term "mastertheses" needs to remain as-is, as it appears only in a 
URL(!)


The term "native" is commonly used to describe a specific type of apps, 
see https://datatracker.ietf.org/doc/html/rfc8252, and I'd therefore 
like to keep it as-is


-Daniel

Am 12.05.24 um 07:31 schrieb Mahesh Jethanandani via Datatracker:

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-oauth-security-topics-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/



--
COMMENT:
--

Thank you for writing this document. Just a couple of comments.

Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "not RECOMMENDED"

The IANA review of this document seems to not have concluded yet.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language  for background and more
guidance:

  * Term "masterthesis"; alternatives might be "active", "central", "initiator",
"leader", "main", "orchestrator", "parent", "primary", "server"
  * Term "man"; alternatives might be "individual", "people", "person"
  * Term "he"; alternatives might be "they", "them", "their"
  * Term "traditional"; alternatives might be "classic", "classical", "common",
"conventional", "customary", "fixed", "habitual", "historic",
"long-established", "popular", "prescribed", "regular", "rooted",
"time-honored", "universal", "widely used", "widespread"
  * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
"intrinsic", "original"



___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] Parameter pollution with redirect_uri injection in Authorization step

2024-05-02 Thread Daniel Fett


Hi Mike,

we require exact redirect URI matching, which should solve the problem; 
in PAR you can use a dynamic redirect_uri, but the PAR request must be 
authenticated by the client then, making this attack unlikely.


-Daniel

Am 02.05.24 um 17:08 schrieb Michael Jones:


Hi Daniel and crew,

Do you believe this issue is addressed in the OAuth Security BCP?  If 
so, can you please add a reference to the pertinent text to this 
issue, so we can close it on that basis?


Thanks,

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

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-security-topics-26

2024-04-29 Thread Daniel Fett


Thank you for your review, Mike!

I created a PR addressing your comments: 
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/91/files


Please let me know if this looks good to you, I'll then release a new 
version with these changes.


Am 29.04.24 um 03:40 schrieb Michael Jones via Datatracker:

There’s a lot of duplicated text between 4.11.2. Authorization Server as Open
Redirector and 4.17. Authorization Server Redirecting to Phishing Site.
Consider refactoring to eliminate or reduce the duplication.


This was by mistake. The section 4.17 was supposed to be merged into 
4.11.2 since it addresses the same attack. I removed 4.17 in the new 
version.


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

Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-security-topics-25

2024-04-21 Thread Daniel Fett


Hi Russ,

thank you for your feedback on the OAuth Security BCP draft! I 
incorporated most of the proposed changes into the latest version (-26).


Some comments below:

Am 18.02.24 um 22:27 schrieb Russ Housley via Datatracker:

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ART-ART reviewer for this draft. Please treat these
comments just like any other last call comments.


Document: draft-ietf-oauth-security-topics-25
Reviewer: Russ Housley
Review Date: 2024-02-18
IETF LC End Date: 2024-02-22
IESG Telechat date: Unknown


Summary: Almost Ready

Major Concerns:

Section 4: Some of the subsections contain MUST, MUST NOT, SHOULD, and
MAY statements.  Given the structure of the document, I expected all of
the words that are defined in RFC 2119 to appear is Section 2, with
discussion of attacks in Section 4.  Please consider lower case words.


I absolutely see where you are coming from, but Section 4 intentionally 
provides normative requirements on top of those in Section 2. Our 
intention is to provide a brief rundown of the most important Best 
Practices in Section 2. However, some requirements are only applicable 
in certain cases (e.g., protocol options not commonly used), some 
require a lengthy detailed explanation, and some require explaining the 
context of a certain attack in order to make sense. Those are listed in 
Section 4.


Removing all requirements from Section 4 would effectively mean merging 
Sections 2 and 4. Since Section 2 was introduced in reponse to demands 
for a summary of the most important measures, we would prefer not to do 
that.


We did check carefully that the requirements defined in Section 4 
complement, but never contradict, those in Section 2.


I noticed, however, that the introductions to Sections 2 and 4 did not 
provide the full picture - I therefore changed the introduction to 
Section 2 to the following:


   This section describes the core set of security mechanisms and
   measures the
   OAuth working group considers best practices at the time of writing.
   Details
   about these security mechanisms and measures (including detailed attack
   descriptions) and requirements for less commonly used options are
   provided in
   (#attacks_and_mitigations).

And the one of Section 4 to the following:

   This section gives a detailed description of attacks on OAuth
   implementations,
   along with potential countermeasures. Attacks and mitigations
   already covered in
   [@!RFC6819] are not listed here, except where new recommendations
   are made.

   This section further defines additional requirements beyond those
   defined in
   Section (#recommendations) for certain cases and protocol options.



Minor Concerns:

Section 1: I recognize that the term "Anti-patterns" is gaining favor,
but I still think that you should provide a brif introduction to the
concept.  Perhaps: Anti-patterns are patterns in software development
that are considered bad programming practices, but they seem to happen
over and over.

Done!


Section 2.3: It says:

...  If not, the resource server must refuse to
serve the respective request. ...

The "If not" is ambiguous.  Which aspects of the previous sentence
does this cover?  Part is implemented by the access server and part is
implemented by the resource server.  Can the resource server always
determin whether the "the authorization server associates the access
token with the respective resource and actions"?  Please clarify.
Good catch, thank you! I expanded the "If not" to "If it was not", 
making clear that it refers to this part of the previous sentence: "... 
whether (...) was meant to be used for that particular resource server."


Section 2.5: When is client authentication not possible?  In other
words, under what circumstances does an authorization server
implementer ignore this SHOULD statement?


Thanks, changed to:

   Authorization servers SHOULD enforce client authentication if
   it is feasible, in the particular deployment, to establish a process for
   issuance/registration of credentials for clients and ensuring the
   confidentiality of those credentials.




Section 4.1.1: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/


Changed as proposed.




Section 4.1.2: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/


Changed as proposed.





Nits:

Abstract: Because the Abstract is not allowed to contain references:
   s/[RFC6749], [RFC6750], and [RFC6819]/
/RFC 6749, RFC 6750, and RFC 6819/

fixed

Section 1: s/client talks to/client is talking to/

fixed


Section 1: s/when feasible/as soon as feasible/

fixed


Section 2.5: s/authentication if possible./authentication./

Changed as shown above


Section 3: s/attacker model/threat model/ (multiple places)

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-security-topics-25

2024-04-21 Thread Daniel Fett


Thank you Thomas for your feedback!

I merged your PR and will release a new version soon.

-Daniel

Am 18.02.24 um 15:52 schrieb Thomas Fossati via Datatracker:

Reviewer: Thomas Fossati
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-security-topics-25
Reviewer: Thomas Fossati
Review Date: 2024-02-18
IETF LC End Date: 2024-02-22
IESG Telechat date: Not scheduled for a telechat

Summary:

This document contains the BCP for OAuth 2.0

It is well written, with a clear structure, and it contains a wealth of useful 
information.

Thank you, editors and the OAUTH WG for an excellent document.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

I have filed a PR to fix a few typos.

[1]https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/90

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

[OAUTH-WG] Type Metadata for SD-JWT VC

2024-04-03 Thread Daniel Fett


Hi all,

as discussed during IETF 119, we would like to introduce what we call 
Type Metadata to SD-JWT VC.


For a bit of context, the intention is to provide a mechanism to provide 
information about credential types (e.g., a JSON schema, 
display/rendering information, a name and description to be used by 
developers, etc.). Type Metadata can be organized in a hierarchical 
structure using "extends" relationships.


The need for such a mechanism developed from discussions around the 
'vct' (Verifiable Credentials Type) identifier 
 in SD-JWT VC 
and again in the context of the EUDI Wallet 
.


I drafted a first tentative design in this specification 
 
and we now want to revisit that and start moving pieces of that over to 
SD-JWT VC.


The first PR  
introduces the basic Type Metadata structures including the extension 
and integrity protection mechanisms. It lacks many of the features we 
would like to see in an MVP, so we plan to release a new draft only 
after introducing a few more features 
 in follow-on PRs.


We would like to invite you to review the PR and let us know if there is 
any feedback! I also plan to discuss this in more detail at an 
unconference session at the OAuth Security Workshop.


-Daniel, Brian, Oliver

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

Re: [OAUTH-WG] OAuth Security Workshop 2024 | April 10-12 | Rome, Italy

2024-03-05 Thread Daniel Fett

This is just a reminder that the final deadline for submissions for OSW 
is coming up on March 10 (Sunday).


https://oauth.secworkshop.events/osw2024

-Daniel

Am 04.01.24 um 10:21 schrieb Daniel Fett:


Hi all,

This year's OAuth Security Workshop will be hosted by Fondazione Bruno 
Kessler and will take place in Rome/Italy, April 10-12.


Like last year, there are two deadlines for the Call for Sessions, 
February 11 and March 10, in order to provide early feedback for those 
that need confirmed talks (e.g., for company sponsorship).


Please find more information on the workshop website, 
https://oauth.secworkshop.events/osw2024


Let me know if there are any questions!

-Daniel


___
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] AD Review of draft-ietf-oauth-security-topics-24

2024-02-08 Thread Daniel Fett


Hi Roman,

Thanks for your feedback, I just released a new version addressing your 
comments!


-Daniel

Am 08.02.24 um 14:54 schrieb Roman Danyliw:


Hi!

I need to apologize here.  I didn’t catch this email and was watching 
for revised I-D indicator in the Datatracker.  Thanks for producing 
this revision over the winter break.  The detailed explanations on the 
WG deliberations on the specific guidance I asked about was very 
helpful.  Likewise, the new introductory text finds the right balance 
in addressing how this document updates the others.


Practically, the revised draft in github addresses almost all of my 
feedback.  A few minor things from the previous thread:


*From:* OAuth  *On Behalf Of * Daniel Fett
*Sent:* Thursday, December 28, 2023 8:35 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24




*Warning:*External Sender - do not click links or open attachments 
unless you recognize the sender and know the content is safe.


Hi Roman,

thanks again for your feedback!

I have a few open questions below, but already incorporated most of 
your (and Hannes) feedback in the editor's copy:


- 
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html


- Diff to published version: 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt 
<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt>


I plan to publish the next version once we have resolved the 
discussion points below.


Also looking forward to feedback from the list and the co-editors!

-Daniel

Am 19.12.23 um 00:08 schrieb Roman Danyliw:

** Section 2.2.

    The privileges associated with an access token SHOULD be restricted

    to the minimum required for the particular application or use case.

Under what circumstances should access tokens not be restricted?  Can this 
be documented?

Due to the variety in architectures, I guess this would mostly boil 
down to performance reasons and architectural limitations (resource 
server or exact privileges are not known at the time of authorization).


I suggest that we add a sentence to discuss this to Section 4.10 
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#section-4.10>.


[Roman] Please do.  Thanks.

** Section 2.6.

    It is RECOMMENDED to use end-to-end TLS between the client and the

    resource server.  If TLS traffic needs to be terminated at an

    intermediary, refer to Section 4.13 for further security advice.

Is there further TLS guidance to provide?  Could BCP 195 be used (RFC9325)?

I would be fine with adding "according to BCP 195" in the first 
sentence. What do you think?


[Roman] That makes sense to me.

** Section 4.18.2.  Formally cite that these are Javascript (?) examples.

I added that these are JavaScript examples. Do you think we need a 
formal reference to ECMAScript? I don't think this would be very helpful.


[Roman] The compromise position would be to call it pseudocode and 
make an editorial distinction that this is an example.


OLD

Clients MUST utilize exact string matching to

   compare the initiator origin of an in-browser message with the

authorization server origin:

window.addEventListener("message", (e) => {

 // validate exact AS origin

 if (e.origin === https://honest.as.example) {

   // process e.data.code and e.data.state

 }

   })

NEW

Clients MUST utilize exact string matching to compare the initiator 
origin of an in-browser message with the authorization server origin.  
For example, in Javascript-like pseudo code, this comparison could 
look as follows:


window.addEventListener("message", (e) => {

 // validate exact AS origin

 if (e.origin === https://honest.as.example) {

   // process e.data.code and e.data.state

 }

   })

Regards,

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

Re: [OAUTH-WG] SD-JWT, use of JSON path in disclosure claim name

2024-02-08 Thread Daniel Fett


Hi Nikos,

this question comes up from time to time, so I'll quote myself 
:


"We thought a lot about pointer-based approaches like the one you 
propose in the beginning, but there are some drawbacks:


 1. The Verifier can re-assemble the document without checking the 
hashes. This is dangerous (see the second paragraph of 
https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#name-manipulation-of-disclosures).
 2. The current design in the draft allows to send smaller 
presentations if only a few claims are disclosed and recursive 
disclosures are used.
 3. There is no need to discuss corner cases, for example, where a 
child element is disclosed, but not the parent element. From my 
experience, the design the we currently have is slightly easier to 
implement (fewer special cases)."


I think the first point is particularly important for the security of 
SD-JWT.


That said, JSONPath is a query syntax and its misuse as pointers must 
stop :-) (Also, it is somewhat dangerous.) JSONPointers would be 
appropriate here.


-Daniel


Am 07.02.24 um 15:52 schrieb Nikos Fotiou:
I was wondering if ever occured to use a JSON path-like approach as 
disclosure name. This will result in a single top level _sd key and 
will remove the need for sperating discolsures that conern objects vs 
those that concern arrays. If this has been disussed in the past, what 
are its disadvantages? A version of example in 6.1 using this 
hypothetical approach follows.


SD-JWT payload (the difference is in the "nationalities" key, the hash 
values have been moved to the _sd claim . Note that the hash values 
are not correct )

{
     "_sd": [
       "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
       "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
       "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
       "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
       "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
       "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
       "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
       "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4",
       "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo",
       "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0"
     ],
     "iss": "https://issuer.example.com;,
     "iat": 168300,
     "exp": 188300,
     "sub": "user_42",
     "nationalities": [],
     "_sd_alg": "sha-256",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }


Disclosures for nationalities
Contents: ["lklxF5jMYlGTPUovMNIvCA", $['nationalities'][0],"US"]
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", $['nationalities'][1],"DE"]

Each attribute of the streat address can be easily represented as a 
different disclosure
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", $['address']['region'], 
"Sachsen-Anhalt"]

Contents: ["6Ij7tM-a5iVPGboS5tmvVA", $['address']['country'], "DE"]

Best,
Nikos



___
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] OAuth Security Workshop 2024 | April 10-12 | Rome, Italy

2024-01-04 Thread Daniel Fett


Hi all,

This year's OAuth Security Workshop will be hosted by Fondazione Bruno 
Kessler and will take place in Rome/Italy, April 10-12.


Like last year, there are two deadlines for the Call for Sessions, 
February 11 and March 10, in order to provide early feedback for those 
that need confirmed talks (e.g., for company sponsorship).


Please find more information on the workshop website, 
https://oauth.secworkshop.events/osw2024


Let me know if there are any questions!

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

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

2024-01-03 Thread Daniel Fett


Hi Axel,

It is to be expected that not all AS will immediately upgrade to adhere 
to the security BCP after its release. So a client who wants to use PKCE 
may encounter AS that don't support it.


See also the discussion in 
https://mailarchive.ietf.org/arch/msg/oauth/ZiwEfenZZlboikXxBLes5ebPmBw/


-Daniel

Am 03.01.24 um 17:39 schrieb axel.nenn...@telekom.de:


Hi Daniel,

there is also this sentence in this section 
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#name-authorization-code-grant 
in a paragraph on it own.


"Authorization servers MUST support PKCE [RFC7636 
<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>]."


Why must a client "ensure" that the AS supports PKCE if the security 
best practices say the AS MUST support PKCE?


//Axel

*From: *OAuth  on behalf of Daniel Fett 


*Date: *Wednesday, 3. January 2024 at 14:01
*To: *oauth@ietf.org 
*Subject: *Re: [OAUTH-WG] Shepherd Review of 
draft-ietf-oauth-security-topics-23


Hi Axel,

I would be happy to see OAuth move away from state as a CSRF 
protection mechanism in the future, but there is not too much to be 
gained from relying solely on PKCE right now. The main advantage is 
that relying on PKCE incentivizes clients to properly manage the 
session state in a cookie instead of relying on a parameter. Beyond 
that, there's a small reduction in effort required by the client, 
messages will be smaller messages, etc.. The disadvantage is that a 
client puts CSRF protection in the hands of the AS. Therefore, we 
chose the wording "ensure" to say that the client has be sure that the 
AS actually implements PKCE correctly before relying on it. What that 
means in the concrete instance is up to the client.


Likewise, to your second point, I do not see enough of an advantage to 
RECOMMEND relying solely on PKCE for CSRF protection.


The main intention here is to open the door to rely on PKCE, e.g., in 
closed ecosystems, ecosystems with in-depth conformance testing, 
first-party applications and similar. This also helps to avoid a lot 
of convoluted language telling client developers how to properly 
choose, track, and check state values in profiles such as FAPI (and 
the pitfalls when interpreting that language).


-Daniel

Am 02.01.24 um 10:31 schrieb axel.nenn...@telekom.de:

Hi,

sorry for being late in the game.

I am not too happy with this section:

"Clients that have ensured that the authorization server supports
Proof Key for Code Exchange (PKCE, [RFC7636

<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>])
MAY rely on the CSRF protection provided by PKCE."

 1. Maybe a minor point that is due to not being a native speaker,
but the verb "ensure" seems too strong.
If the AZ states in its metadata, that it supports PKCE than
this is "ensurance" enough, right? The client does not have to
"ensure" the support by actually testing compliance, right?
I suggest rephrasing that to "*If**the authorization server
**states in its meta-data support for**Proof Key for Code
Exchange* (PKCE, [RFC7636

<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>])
the client MAY rely on the CSRF protection provided by PKCE."
 2. I suggest changing the "MAY" into a recommendation for all
OAuth2-based protocols. OIDC flows can easily support PKCE,
and new clients SHOULD use PKCE, I think.
Suggestion:
"If the authorization server states in its meta-data support
for Proof Key for Code Exchange (PKCE, [RFC7636

<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>]),
it is RECOMMENDED the client relies on the CSRF protection
    provided by PKCE."

Kind regards

Axel

*From: *OAuth 
<mailto:oauth-boun...@ietf.org> on behalf of Daniel Fett

<mailto:fett=40danielfett...@dmarc.ietf.org>
*Date: *Thursday, 28. December 2023 at 14:38
*To: *oauth@ietf.org  <mailto:oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Shepherd Review of
draft-ietf-oauth-security-topics-23

Hi Hannes,

thanks again for your feedback! It is incorporated in the editor's
copy now.

-

https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html

- Diff to published version:

https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt

<https://author-tools.ietf.org/api/iddiff?doc_1=d

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

2024-01-03 Thread Daniel Fett

Hi Axel,

I would be happy to see OAuth move away from state as a CSRF protection
mechanism in the future, but there is not too much to be gained from
relying solely on PKCE right now. The main advantage is that relying on
PKCE incentivizes clients to properly manage the session state in a
cookie instead of relying on a parameter. Beyond that, there's a small
reduction in effort required by the client, messages will be smaller
messages, etc.. The disadvantage is that a client puts CSRF protection
in the hands of the AS. Therefore, we chose the wording "ensure" to say
that the client has be sure that the AS actually implements PKCE
correctly before relying on it. What that means in the concrete instance
is up to the client.

Likewise, to your second point, I do not see enough of an advantage to
RECOMMEND relying solely on PKCE for CSRF protection.

The main intention here is to open the door to rely on PKCE, e.g., in
closed ecosystems, ecosystems with in-depth conformance testing,
first-party applications and similar. This also helps to avoid a lot of
convoluted language telling client developers how to properly choose,
track, and check state values in profiles such as FAPI (and the pitfalls
when interpreting that language).

-Daniel

Am 02.01.24 um 10:31 schrieb axel.nenn...@telekom.de:

Hi,

sorry for being late in the game.

I am not too happy with this section:

"Clients that have ensured that the authorization server supports
Proof Key for Code Exchange (PKCE, [RFC7636
<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>])
MAY rely on the CSRF protection provided by PKCE."

1. Maybe a minor point that is due to not being a native speaker, but
the verb "ensure" seems too strong.
If the AZ states in its metadata, that it supports PKCE than this
is "ensurance" enough, right? The client does not have to "ensure"
the support by actually testing compliance, right?
I suggest rephrasing that to "*If the authorization server
**states in its meta-data support for Proof Key for Code Exchange*
(PKCE, [RFC7636

<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>])
the client MAY rely on the CSRF protection provided by PKCE."
2. I suggest changing the "MAY" into a recommendation for all
OAuth2-based protocols. OIDC flows can easily support PKCE, and
new clients SHOULD use PKCE, I think.
Suggestion:
"If the authorization server states in its meta-data support for
Proof Key for Code Exchange (PKCE, [RFC7636

<https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>]),
it is RECOMMENDED the clientrelies on the CSRF protection provided
by PKCE."

Kind regards

Axel

*From: *OAuth on behalf of Daniel Fett

*Date: *Thursday, 28. December 2023 at 14:38
*To: *oauth@ietf.org
*Subject: *Re: [OAUTH-WG] Shepherd Review of
draft-ietf-oauth-security-topics-23

Hi Hannes,

thanks again for your feedback! It is incorporated in the editor's
copy now.

-
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html

- Diff to published version:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt
<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt>

I plan to publish the next version once we have resolved the
discussion points from Roman's AD review.

-Daniel

Am 04.10.23 um 15:41 schrieb Tschofenig, Hannes:

Hi all,

here are some comments as part of my shepherd review of the OAuth
Security BCP.

First, I want to send a big "Thanks" to everyone in the group for
the work on this document and to the authors in particular. It has
taken us a while to come up with such an impressive list of
security recommendations for OAuth 2.0.

At this point in time my review comments can only be minor given
the amount of feedback this documents has already received.

Here are a few remarks.

I believe we should indicate that the specification updates other
OAuth RFCs. The obvious documents it updates are RFC 6749, RFC
6750 and RFC 6819.

You can set these "updates" in the template you are using.

In Section 1 you say:

It does not supplant the security advice given in

[RFC6749], [RFC6750], and [RFC6819], but complements those
documents.

In the subsequent paragraph you state that you "depreciate some
modes of operation".

I believe you are need

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

2023-12-28 Thread Daniel Fett

Hi Hannes,

thanks again for your feedback! It is incorporated in the editor's copy now.

-
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html

I plan to publish the next version once we have resolved the discussion
points from Roman's AD review.

-Daniel

Am 04.10.23 um 15:41 schrieb Tschofenig, Hannes:

Hi all,

here are some comments as part of my shepherd review of the OAuth
Security BCP.

First, I want to send a big "Thanks" to everyone in the group for the
work on this document and to the authors in particular. It has taken
us a while to come up with such an impressive list of security
recommendations for OAuth 2.0.

At this point in time my review comments can only be minor given the
amount of feedback this documents has already received.

Here are a few remarks.

I believe we should indicate that the specification updates other
OAuth RFCs. The obvious documents it updates are RFC 6749, RFC 6750
and RFC 6819.

You can set these "updates" in the template you are using.

In Section 1 you say:

It does not supplant the security advice given in

[RFC6749], [RFC6750], and [RFC6819], but complements those documents.

In the subsequent paragraph you state that you "depreciate some modes
of operation".

I believe you are need to be clear about what you are doing in
relationship to these prior documents. It might also be useful to say
something about OAuth 2.1.

Expand abbreviations on first use. Example: "AS" and "PKCE" in Section
2.1. The AS abbreviation is only expanded later in Section 3. Decide
whether you want to use abbreviations or not. You mix them throughout
the document without no reasons.

Listing the abbreviations in Section 1.2 may also be useful. There are
not that many abbreviations anyway.

I have wording suggestions for this paragraph:

FROM:

Authorization servers SHOULD use client authentication if possible.

It is RECOMMENDED to use asymmetric (public-key based) methods for

client authentication such as mTLS [RFC8705] or using signed JWTs

("Private Key JWT") in accordance with [RFC7521] and [RFC7523] (in

[OpenID.Core] defined as the client authentication method

private_key_jwt). When such methods for client authentication are

used, authorization servers do not need to store sensitive symmetric

keys, making these methods more robust against a number of attacks.

TO:

Authorization servers SHOULD enforce client authentication, if
possible.

It is RECOMMENDED to use asymmetric cryptography for

client authentication, such as mTLS [RFC8705] or using signed JWTs

("Private Key JWT"), in accordance with [RFC7521] and [RFC7523] (in

[OpenID.Core] defined as the client authentication method

private_key_jwt). When asymmetric cryptography for client
authentication is

used, authorization servers do not need to store sensitive symmetric

keys, making client authentication more robust against leakage of keys.

(Note: For the reader it is always better if they are told what attacks

are prevented rather than saying "a number of attacks". You don't want
the reader

to guess what you mean.)

Section 2 is a summary of what follows in Section 4. Maybe you can
make this explicit

either in the title of Section 2 or in the first paragraph of Section 2.

Section 3.

You write:

These attackers conform to the attacker model that was used in formal

analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal

attacker model. Implementers MUST take into account all possible

types of attackers in the environment in which their OAuth

implementations are expected to run.

When you say "these attackers" please clarify which attackers you are
talking about.

Prior to this paragraph you have just spoken about various forms of
network attackers.

Just before that you talked about network and web attackers.

Then, you introduce more attackers and you keep talking about "this
attacker model" and

"these attackers". Make it easier for the reader by referring
explictly which attackers

you are talking about in a specific paragraph.

Then, you conclude the section with a hint that there is an even
stronger attacker model.

As a reader I might want to know what this stronger attacker model
looks like and why you

do not consider it in this document.

Section 4.1.1:

You write:

Note: Vulnerabilities of this kind can also exist if the

authorization server handles wildcards properly.

I believe you are saying that the

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

2023-12-28 Thread Daniel Fett

Hi Roman,

thanks again for your feedback!

I have a few open questions below, but already incorporated most of your
(and Hannes) feedback in the editor's copy:

-
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html

I plan to publish the next version once we have resolved the discussion
points below.

Also looking forward to feedback from the list and the co-editors!

-Daniel

Am 19.12.23 um 00:08 schrieb Roman Danyliw:

** Section 2.1
When an OAuth client can interact with more than one authorization
server, a defense against mix-up attacks (see Section 4.4) is
REQUIRED. To this end, clients SHOULD
…

In the absence of these options, clients MAY instead use ...

The text is clear on saying some defense from a mix-up attack is needed. What
happens if the client cannot use the methods prescribed by the SHOULD and MAY
in this text?

** Section 2.1.1
Clients MUST prevent authorization code injection attacks (see
Section 4.5) and misuse of authorization codes using one of the
following options:

What approach should a confidential client take of PKCE is not used? It is
only recommended in the subsequent bulleted list.

In both of these cases, the most important point is that protections are
applied (REQUIRED/MUST). We further want to steer implementers towards a
specific solution.

In the first case, we give options but intentionally don't limit
implementers, as other solutions may exist. (Custom solutions should not
bring any interoperability issues here, as it is mostly internal to the
client. At the same time, we don't want to describe any of the other
solutions, as we provide robust solutions already.)

In the second case, we list all the options, but give guidance on which
to use, especially for confidential clients. We can't say that they MUST
use PKCE, as we want to permit the OpenID nonce approach. If the
implementer don't implement PKCE ("RECOMMENDED") or OpenID nonce ("MAY")
they are in violation of the MUST in the sentence before the list.

We (as the working group) spent quite some time refining the wording in
these paragraphs, in particular in the second case. I think they are
correct and I have a hard time coming up with a clearer way to express
the same thing, so I suggest to not change anything.

** Section 2.2.

The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case.

Under what circumstances should access tokens not be restricted? Can this be
documented?

Due to the variety in architectures, I guess this would mostly boil down
to performance reasons and architectural limitations (resource server or
exact privileges are not known at the time of authorization).

I suggest that we add a sentence to discuss this to Section 4.10
.

** Section 2.3
In particular, access tokens SHOULD be restricted to certain resource
servers (audience restriction), preferably to a single resource
server.

Is there anyway to refine this text to make the interplay of the SHOULD and
“preferably” clearer?

I propose to modify this as follows:

"In particular, access tokens SHOULD be audience-restricted to a
specific resource

server, or, if that is not feasible, to a small set of resource servers."

** Section 2.4
and authentication processes that require multiple
steps can be hard or impossible.

Is this difficulty due to complexity? It would be helpful to refine why it is
“hard”.

I propose the following text:

"Furthermore, the resource owner password credentials grant is not
designed to
work with two-factor authentication and authentication processes that
require
multiple user interaction steps. Authentication with cryptographic
credentials

(cf. WebCrypto [@W3C.WebCrypto], WebAuthn [@W3C.WebAuthn]) may be impossible
to implement with this grant type, as it is usually bound to a specific
web origin."

** Section 2.6.
It is RECOMMENDED to use end-to-end TLS between the client and the
resource server. If TLS traffic needs to be terminated at an
intermediary, refer to Section 4.13 for further security advice.

Is there further TLS guidance to provide? Could BCP 195 be used (RFC9325)?

I would be fine with adding "according to BCP 195" in the first
sentence. What do you think?

** Section 3.
Implementers MUST take into account all possible
types of attackers in the

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

2023-12-28 Thread Daniel Fett


Hi Roman,

thanks for the detailed review and your valuable feedback!

I think you raise one important point in particular that I'd like to 
discuss on the list:


Am 19.12.23 um 00:08 schrieb Roman Danyliw:

** I struggled to understand what was mandatory in the mix of RFC2119 keywords.
(a) Section 1 says “Nonetheless, it is RECOMMENDED that implementers upgrade 
their implementations and ecosystems when feasible.”

(b) Section 3 says “OAuth MUST ensure that the authorization of the resource 
owner (RO) (with a user agent) at the authorization server (AS) and the 
subsequent usage of the access token at the resource server (RS) is protected 
at least against the following attackers:”

(c) Section 3 later says “Implementers MUST take into account all possible 
types of attackers in the environment in which their OAuthimplementations 
are expected to run.”

(b) and (c) seem to be making strong statements mandatory requirements for 
high-level threats.  However, (a) seems to suggest that conformance is only 
recommended.


Let's ignore (b) here since the sentence is worded a bit strangely and 
I'll fix that independently of this discussion. (We can't really say 
"OAuth MUST..." — what does that even mean?)


The context for (a) are these two paragraphs:

/This document provides updated security recommendations to address 
these challenges. It does not supplant the security advice given in 
[RFC6749 
], 
[RFC6750 
], 
and [RFC6819 
], 
but complements those documents./


/This document introduces new requirements beyond those defined in 
existing specifications such as OAuth 2.0 [RFC6749 
] 
and OpenID Connect [OpenID.Core 
] 
and deprecates some modes of operation that are deemed less secure or 
even insecure. Naturally, not all existing ecosystems and 
implementations are compatible with the new requirements and following 
the best practices described in this document may break 
interoperability. Nonetheless, it is RECOMMENDED that implementers 
upgrade their implementations and ecosystems when feasible./


My understanding of the relationship of (a) to the rest of the document 
is roughly this: Since we're releasing this BCP now, most ecoystems will 
not be compliant to all of the normative requirements immediately. 
Therefore, an upgrade is RECOMMENDED. To be compliant, one must 
implement all the normative requirements described in the document.


I do, however, see how this can read like a contradiction and would 
therefore suggest to change the sentence in (a) to something like
"Nonetheless, implementers need to upgrade their implementations and 
ecosystems to be compliant to this document/BCP/..."


What do you and others think?

-Daniel

--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Transaction Tokens

2023-11-18 Thread Daniel Fett


I support adoption.

Am 14.11.23 um 13:57 schrieb Rifaat Shekh-Yusef:

All,

This is an *official *call for adoption for the *Transaction Tokens 
*draft:

https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/

Please, reply on the mailing list and let us know if you are in favor 
or against adopting this draft as WG document, by *Nov 28th*.


Regards,
 Rifaat & Hannes

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Identity Chaining

2023-11-18 Thread Daniel Fett


I support adoption.

Am 14.11.23 um 13:58 schrieb Rifaat Shekh-Yusef:

All,

This is an *official* call for adoption for the *Identity Chaining *draft:
https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/

Please, reply on the mailing list and let us know if you are in favor 
or against adopting this draft as WG document, by *Nov 28th.*


Regards,
 Rifaat & Hannes

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

2023-11-05 Thread Daniel Fett

I agree with Aaron!

Also we should be very careful about any additions to the Security BCP
at this point. It is very easy to re-start the "one more thing" loop
we've been stuck in for the last years. There may be more useful things
to say, but we should put them on the list for a future second version
of the BCP.

-Daniel

Am 05.11.23 um 20:03 schrieb Aaron Parecki:
I don't think the Security BCP should incorporate cookie best
practices directly in the document. If anything, it sounds like
possibly a candidate for inclusion in the Browser Apps BCP.

There are already some mentions of these cookie properties mentioned
in the Browser Apps BCP, though only in reference to specific
architectures, not as a general best practice. For example:

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

Aaron

On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt wrote:

Hey

I was reviewing security on some sites I managed and checked to
see if the recommendations were in the BCP.

I don't see anything around cookies such as httpOnly, sameSite,
secure.

I saw some HTTP security header suggestions buried in 4.16
(X-Frame-Options, CSP), but not for Strict-Transport-Security,
Permissions-Policy, or X-Content-Type-Options, and the CSP
guidance is rather vague.

I understand these are general web security best practices, and
perhaps I missed it, but I think it would be useful to call out
that best security practices around cookies and headers should
also be followed in Section 2, and either have the best practices
included, or direct the reader where to find them.

/Dick

___
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier

2023-11-03 Thread Daniel Fett


Hi Denis,

Am 31.10.23 um 17:10 schrieb Denis:

Hi Daniel,


Hi Denis,

a discussion on claims-based/biometric binding, probably what you're 
hinting at,



I am not hinting at a discussion "on claims-based/biometric binding".


Ok.


"Collaborative attacks against a Verifier" should be added to the 
Security Considerations section.



We will consider this.

-Daniel



Denis


-Daniel

Am 26.10.23 um 11:01 schrieb Denis:

Hi All,

Section 11.6. is about "Key Binding" which is indeed an important 
security feature.
However, in the context of "selective disclosure" while this feature 
is essential, it is insufficient.


Let us take an example: If a Token indicates that an individual has 
the nationality X, in case of a collusion between two individuals
and when using two pieces of software specifically developed for 
that purpose, an individual would be able to compute and transmit
a Token to another individual for the benefit of that other 
individual in order to cheat a Verifier. This is a collusion between 
two individuals.


The first individual may not have the knowledge of the private key 
but since he has the use of the private key, he is in a position to 
sign
anything he wants. Since the Token does not include claims allowing 
to uniquely identity the individual, "if he is not seen, he will not 
be caught".


"Collaborative attacks against a Verifier" should be added to the 
Security Considerations section.


There exist ways to counter collaborative attacks against a 
Verifier. These ways should be mentioned in the core of the document.


Denis


Hi all,

this release of SD-JWT includes one important normative change, 
which is a hash in the key binding JWT to ensure the integrity of 
presentations. The second biggest change is that we restructured 
some sections of the document to make it more readable.


As always, we're looking forward to discussing SD-JWT here on the 
mailing list and in Prague.


-Daniel

This is the full changelog:

   -06

*  Added hash of Issuer-signed part and Disclosures in KB-JWT

*  Fix minor issues in some examples

*  Added IANA media type registration request for the JSON
   Serialization

*  More precise wording around storing artifacts with sensitive data

*  The claim name _sd or ... must not be used in a disclosure.

*  Added JWT claims registration requests to IANA
*  Ensure claims that control validity are checked after decoding
   payload

*  Restructure sections around data formats and Example 1

*  Update JSON Serialization to remove the kb_jwt member and allow
   for the disclosures to be conveyed elsewhere

*  Expand the Enveloping SD-JWTs section to also discuss enveloping
   JSON serialized SD-JWTs

Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org:

Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

Title:   Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
 Kristina Yasuda
 Brian Campbell
Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt
Pages:   90
Dates:   2023-10-23

Abstract:

This specification defines a mechanism for selective disclosure of
individual elements of a JSON object used as the payload of a JSON
Web Signature (JWS) structure.  It encompasses various applications,
including but not limited to the selective disclosure of JSON Web
Token (JWT) claims.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

--
Please use my new email address:m...@danielfett.de

___
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

--
Please use my new email address:m...@danielfett.de

___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Relationship between SPICE and OAuth

2023-11-02 Thread Daniel Fett


Hi Hannes,

Am 02.11.23 um 15:23 schrieb Hannes Tschofenig:
Do you see a need for COSE/CBOR in your use case now? 


The main selling point of SD-JWT is simplicity, in the sense that it is 
easy to understand and easy to implement (relative to other credential 
formats). Both of this is due to the fact that it relies on the very 
well-known JWT/JWS specs with many good libraries available.


I have personally not heard demand for COSE/CBOR-based formats, maybe 
because SD-JWT is already serving the existing use cases quite fine and 
people are less familiar with COSE/CBOR.



Do you have other (maybe new) use cases that rely on COSE/CBOR?


I don't, but maybe others do?

-Daniel



As you can see, I am trying to find out whether there are real-world 
use cases that require us to do this work or whether we just do it 
because it can be done.



Ciao

Hannes


PS: A little bit of background for my questions: A few years ago the 
ACE working group was formed, where several people from the IoT 
community saw the need to standardize an authorization architecture. 
The idea was to re-use OAuth but the OAuth selected encoding formats 
based on JSON were seen as too "heavy" for IoT devices and networks. 
As a result, everything was re-defined in CBOR/COSE. CWT was one of 
the outcome of that work.


The idea was nice but the success was below my expectations.


Am 02.11.2023 um 13:23 schrieb Daniel Fett:


Hi Hannes,

Am 02.11.23 um 12:46 schrieb Hannes Tschofenig:
The question to the authors of the SD-JWT & related documents is: 
Does a CBOR/COSE serialization provide value in your use cases?


My point of view: It makes sense to define a format enabling SD for 
CBOR/COSE, but it will be more than just a different serialization. 
We had to make a number of choices for SD-JWT to reach the current 
format that is optimized for security, ease of use and compactness. 
Many of these choices were due to details of the encoding, e.g., the 
problems associated with canonical representations of JSON, avoiding 
double-JSON encoding, avoiding double-base64 encoding, the existing 
format for JWTs.


I expect that, due to different features in the underlying format, a 
CBOR-based solution will end up making very different trade-offs. 
This may even extend to providing a different featureset. We 
therefore should not strive to align SD-JWT and a CBOR-based solution 
as much as possible (or even putting them in the same draft), but we 
should attempt to create the best possible SD format for JOSE and, 
independently, the best possible SD format for COSE. Otherwise we 
would create two mediocre formats.


In that sense, I also don't see that SD-JWT should wait for a 
CBOR-based draft to start or even longer.


-Daniel



Ciao

Hannes



Am 02.11.2023 um 08:41 schrieb Daniel Fett:


I second what my co-authors Kristina and Brian said. It is a risk, 
and there are a lot of unknowns here.


I have a similar feeling regarding SD-JWT VC, even though that is 
farther away from the finish line.


And as an attempt to explain some of the responses: I think the 
communication here was less than ideal. Even if the authors of the 
drafts may have no more say than anyone else, as you pointed out, 
getting them on board with the idea before listing the drafts as 
"proposed work items" would have helped.


-Daniel

Am 01.11.23 um 15:54 schrieb Kristina Yasuda:


Moving a somewhat mature draft to another WG is highly likely slow 
down the progress on that document: there is no guarantee there 
will be an overlap in the WG members, there is a risk that 
discussions that were already resolved to be re-opened to be, etc.


I consider SD-JWT closer to a finish line then a start line and 
would not like its progress being slowed down by moving it to 
another WG at this point of document's lifecycle. I am not in 
favor of moving SD-JWT work to SPICE WG.


Best,

Kristina

*From:*OAuth  *On Behalf Of *Hannes Tschofenig
*Sent:* Wednesday, November 1, 2023 4:21 AM
*To:* oauth ; sp...@ietf.org
*Subject:* [OAUTH-WG] Relationship between SPICE and OAuth

Hi all,

I am a bit puzzled by the response Pam and I received when putting 
the agenda for the SPICE BOF together. It appears that most people 
have not paid attention to the discussions during the last few months.


Let me try to get you up to speed. So, here is my summary.

The OAuth working group has seen a lot of interest in the context 
of the SD-JWT/VC work and there have been complaints about the 
three WG sessions we scheduled at the last IETF meeting. (FWIW 
neither Rifaat nor I understood why we received these complaints 
given that people asked us for more slots. But that's another 
story...)


The SD-JWT/VC work is architecturally different to the classical 
OAuth (which is not a problem) but raises questions about the 
scope of the work done in the OAuth working group, as defined by 
the charter. The charter of a group is a "contract" with the 
steering

Re: [OAUTH-WG] Relationship between SPICE and OAuth

2023-11-02 Thread Daniel Fett

Hi Hannes,

Am 02.11.23 um 12:46 schrieb Hannes Tschofenig:
The question to the authors of the SD-JWT & related documents is: Does
a CBOR/COSE serialization provide value in your use cases?

My point of view: It makes sense to define a format enabling SD for
CBOR/COSE, but it will be more than just a different serialization. We
had to make a number of choices for SD-JWT to reach the current format
that is optimized for security, ease of use and compactness. Many of
these choices were due to details of the encoding, e.g., the problems
associated with canonical representations of JSON, avoiding double-JSON
encoding, avoiding double-base64 encoding, the existing format for JWTs.

I expect that, due to different features in the underlying format, a
CBOR-based solution will end up making very different trade-offs. This
may even extend to providing a different featureset. We therefore should
not strive to align SD-JWT and a CBOR-based solution as much as possible
(or even putting them in the same draft), but we should attempt to
create the best possible SD format for JOSE and, independently, the best
possible SD format for COSE. Otherwise we would create two mediocre
formats.

In that sense, I also don't see that SD-JWT should wait for a CBOR-based
draft to start or even longer.

-Daniel

Ciao

Hannes

Am 02.11.2023 um 08:41 schrieb Daniel Fett:

I second what my co-authors Kristina and Brian said. It is a risk,
and there are a lot of unknowns here.

I have a similar feeling regarding SD-JWT VC, even though that is
farther away from the finish line.

And as an attempt to explain some of the responses: I think the
communication here was less than ideal. Even if the authors of the
drafts may have no more say than anyone else, as you pointed out,
getting them on board with the idea before listing the drafts as
"proposed work items" would have helped.

-Daniel

Am 01.11.23 um 15:54 schrieb Kristina Yasuda:

Moving a somewhat mature draft to another WG is highly likely slow
down the progress on that document: there is no guarantee there will
be an overlap in the WG members, there is a risk that discussions
that were already resolved to be re-opened to be, etc.

I consider SD-JWT closer to a finish line then a start line and
would not like its progress being slowed down by moving it to
another WG at this point of document's lifecycle. I am not in favor
of moving SD-JWT work to SPICE WG.

Best,

Kristina

*From:*OAuth *On Behalf Of *Hannes Tschofenig
*Sent:* Wednesday, November 1, 2023 4:21 AM
*To:* oauth ; sp...@ietf.org
*Subject:* [OAUTH-WG] Relationship between SPICE and OAuth

Hi all,

I am a bit puzzled by the response Pam and I received when putting
the agenda for the SPICE BOF together. It appears that most people
have not paid attention to the discussions during the last few months.

Let me try to get you up to speed. So, here is my summary.

The OAuth working group has seen a lot of interest in the context of
the SD-JWT/VC work and there have been complaints about the three WG
sessions we scheduled at the last IETF meeting. (FWIW neither Rifaat
nor I understood why we received these complaints given that people
asked us for more slots. But that's another story...)

The SD-JWT/VC work is architecturally different to the classical
OAuth (which is not a problem) but raises questions about the scope
of the work done in the OAuth working group, as defined by the
charter. The charter of a group is a "contract" with the steering
committee (IESG) about the work we are supposed to be doing. There
is the expectation that the work described in the charter and in the
milestones somehow matches the work the group is doing (at least to
some approximation). See also the mail from Roman to the OAuth list
for the type of questions that surfaced:
https://mailarchive.ietf.org/arch/msg/oauth/a_MEz2SqU7JYEw3gKxKzSrRlQFA/

In time for the Prague IETF meeting a BOF request (with the shiny
name SPICE, see
https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/)
was submitted. It was subsequently approved by the IESG. SPICE aims
to cover the scope of the SD-JWT/VC work (plus work on defining the
CWT-based counterparts) -- my rough summary; details are here:
https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md

This BOF request again raised questions about the scope and the
relationship with OAuth, see Roman's note here:
https://mailarchive.ietf.org/arch/msg/spice/Aoe86A0x6bezllwx17Xd5TOQ3Pc/

Now, we are in the final stages of preparing the BOF for the Prague
IETF and in the agenda preparation we repeately get asked the same
question:

"Has the transfer of some of the OAuth documents already been agreed?"

The answer is "no". Nothing has been agreed. The purpose of the BOF
is to find this agreement.

So, if you have an opinion whether some of th

Re: [OAUTH-WG] Relationship between SPICE and OAuth

2023-11-02 Thread Daniel Fett

I second what my co-authors Kristina and Brian said. It is a risk, and
there are a lot of unknowns here.

I have a similar feeling regarding SD-JWT VC, even though that is
farther away from the finish line.

-Daniel

Am 01.11.23 um 15:54 schrieb Kristina Yasuda:

Moving a somewhat mature draft to another WG is highly likely slow
down the progress on that document: there is no guarantee there will
be an overlap in the WG members, there is a risk that discussions that
were already resolved to be re-opened to be, etc.

I consider SD-JWT closer to a finish line then a start line and would
not like its progress being slowed down by moving it to another WG at
this point of document's lifecycle. I am not in favor of moving SD-JWT
work to SPICE WG.

Best,

Kristina

*From:*OAuth *On Behalf Of *Hannes Tschofenig
*Sent:* Wednesday, November 1, 2023 4:21 AM
*To:* oauth ; sp...@ietf.org
*Subject:* [OAUTH-WG] Relationship between SPICE and OAuth

Hi all,

I am a bit puzzled by the response Pam and I received when putting the
agenda for the SPICE BOF together. It appears that most people have
not paid attention to the discussions during the last few months.

Let me try to get you up to speed. So, here is my summary.

The SD-JWT/VC work is architecturally different to the classical OAuth
(which is not a problem) but raises questions about the scope of the
work done in the OAuth working group, as defined by the charter. The
charter of a group is a "contract" with the steering committee (IESG)
about the work we are supposed to be doing. There is the expectation
that the work described in the charter and in the milestones somehow
matches the work the group is doing (at least to some approximation).
See also the mail from Roman to the OAuth list for the type of
questions that surfaced:
https://mailarchive.ietf.org/arch/msg/oauth/a_MEz2SqU7JYEw3gKxKzSrRlQFA/

In time for the Prague IETF meeting a BOF request (with the shiny name
SPICE, see
https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/)
was submitted. It was subsequently approved by the IESG. SPICE aims to
cover the scope of the SD-JWT/VC work (plus work on defining the
CWT-based counterparts) -- my rough summary; details are here:
https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md

This BOF request again raised questions about the scope and the
relationship with OAuth, see Roman's note here:
https://mailarchive.ietf.org/arch/msg/spice/Aoe86A0x6bezllwx17Xd5TOQ3Pc/

Now, we are in the final stages of preparing the BOF for the Prague
IETF and in the agenda preparation we repeately get asked the same
question:

"Has the transfer of some of the OAuth documents already been agreed?"

The answer is "no". Nothing has been agreed. The purpose of the BOF is
to find this agreement.

So, if you have an opinion whether some of the OAuth documents (in
particular draft-ietf-oauth-sd-jwt-vc,
draft-ietf-oauth-selective-disclosure-jwt,
draft-ietf-oauth-status-list) should move to a new working group then
you should speak up **now**.

The SPICE BOF (and the WIMSE BOF) will happen on Tuesday next week.
The first OAuth WG session happens shortly afterwards (also on
Tuesday). The outcome of the BOF(s) will guide us in our discussion
about re-chartering the OAuth working group (which is an item on the
OAuth agenda, see
https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-03).

Rifaat, Pam and I are mediators in this process and therefore we rely
on your input. Since you have to do the work, you should think about
where you want to do it.

Ciao

Hannes

PS: A process-related note. If you are author of a working group
document you are working for the group. With the transition from an
individual document to a working group document you have relinquished
control to the group. While your opinion is important, it has the same
weight as the opinion of any other working group participant. The
theme is "We reject: kings, presidents, and voting. We believe in:
rough consensus and running code".

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

--
Please use my new email address:m...@danielfett.de

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier

2023-10-31 Thread Daniel Fett


Hi Denis,

a discussion on claims-based/biometric binding, probably what you're 
hinting at, is out of the scope of this document, since we define 
neither mechanisms nor rules for that. This should be part of a 
discussion with a larger scope, like the Security & Trust document in 
OIDF's DCP group.


-Daniel

Am 26.10.23 um 11:01 schrieb Denis:

Hi All,

Section 11.6. is about "Key Binding" which is indeed an important 
security feature.
However, in the context of "selective disclosure" while this feature 
is essential, it is insufficient.


Let us take an example: If a Token indicates that an individual has 
the nationality X, in case of a collusion between two individuals
and when using two pieces of software specifically developed for that 
purpose, an individual would be able to compute and transmit
a Token to another individual for the benefit of that other individual 
in order to cheat a Verifier. This is a collusion between two individuals.


The first individual may not have the knowledge of the private key but 
since he has the use of the private key, he is in a position to sign
anything he wants. Since the Token does not include claims allowing to 
uniquely identity the individual, "if he is not seen, he will not be 
caught".


"Collaborative attacks against a Verifier" should be added to the 
Security Considerations section.


There exist ways to counter collaborative attacks against a Verifier. 
These ways should be mentioned in the core of the document.


Denis


Hi all,

this release of SD-JWT includes one important normative change, which 
is a hash in the key binding JWT to ensure the integrity of 
presentations. The second biggest change is that we restructured some 
sections of the document to make it more readable.


As always, we're looking forward to discussing SD-JWT here on the 
mailing list and in Prague.


-Daniel

This is the full changelog:

   -06

*  Added hash of Issuer-signed part and Disclosures in KB-JWT

*  Fix minor issues in some examples

*  Added IANA media type registration request for the JSON
   Serialization

*  More precise wording around storing artifacts with sensitive data

*  The claim name _sd or ... must not be used in a disclosure.

*  Added JWT claims registration requests to IANA
*  Ensure claims that control validity are checked after decoding
   payload

*  Restructure sections around data formats and Example 1

*  Update JSON Serialization to remove the kb_jwt member and allow
   for the disclosures to be conveyed elsewhere

*  Expand the Enveloping SD-JWTs section to also discuss enveloping
   JSON serialized SD-JWTs

Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org:

Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

Title:   Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
 Kristina Yasuda
 Brian Campbell
Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt
Pages:   90
Dates:   2023-10-23

Abstract:

This specification defines a mechanism for selective disclosure of
individual elements of a JSON object used as the payload of a JSON
Web Signature (JWS) structure.  It encompasses various applications,
including but not limited to the selective disclosure of JSON Web
Token (JWT) claims.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

--
Please use my new email address:m...@danielfett.de

___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-24.txt

2023-10-23 Thread Daniel Fett


Hi all,

with this release of the security BCP, I have started to implement 
Hannes' feedback from the shepherd's writeup, updated some references, 
and made some other editorial changes.


There are no normative changes in this version.

-Daniel

Am 23.10.23 um 18:55 schrieb internet-dra...@ietf.org:

Internet-Draft draft-ietf-oauth-security-topics-24.txt is now available. It is
a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

Title:   OAuth 2.0 Security Best Current Practice
Authors: Torsten Lodderstedt
 John Bradley
 Andrey Labunets
 Daniel Fett
Name:draft-ietf-oauth-security-topics-24.txt
Pages:   62
Dates:   2023-10-23

Abstract:

This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader
application of OAuth 2.0.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-security-topics-24

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

2023-10-23 Thread Daniel Fett


Hi all,

this release of SD-JWT includes one important normative change, which is 
a hash in the key binding JWT to ensure the integrity of presentations. 
The second biggest change is that we restructured some sections of the 
document to make it more readable.


As always, we're looking forward to discussing SD-JWT here on the 
mailing list and in Prague.


-Daniel

This is the full changelog:

  -06

   *  Added hash of Issuer-signed part and Disclosures in KB-JWT

   *  Fix minor issues in some examples

   *  Added IANA media type registration request for the JSON
  Serialization

   *  More precise wording around storing artifacts with sensitive data

   *  The claim name _sd or ... must not be used in a disclosure.

   *  Added JWT claims registration requests to IANA

   *  Ensure claims that control validity are checked after decoding
  payload

   *  Restructure sections around data formats and Example 1

   *  Update JSON Serialization to remove the kb_jwt member and allow
  for the disclosures to be conveyed elsewhere

   *  Expand the Enveloping SD-JWTs section to also discuss enveloping
  JSON serialized SD-JWTs

Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org:

Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

Title:   Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
 Kristina Yasuda
 Brian Campbell
Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt
Pages:   90
Dates:   2023-10-23

Abstract:

This specification defines a mechanism for selective disclosure of
individual elements of a JSON object used as the payload of a JSON
Web Signature (JWS) structure.  It encompasses various applications,
including but not limited to the selective disclosure of JSON Web
Token (JWT) claims.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Redaction Reasons

2023-10-20 Thread Daniel Fett


The Holder can put such information into the KB-JWT, if required.

-Daniel

Am 20.10.23 um 16:28 schrieb Orie Steele:

In some ways this is related to the question about disclosures.

On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett 
 wrote:


At least at the moment I don't think that there is a huge need for
such a feature. I don't think that we should clutter the existing
SD-JWT data structures with such information.

I tend to agree with the latter.

There is substantial security / privacy risk, making disclosures carry 
ANY information other than what the issuer committed to.


If required, it could go into a separate data structure in the
SD-JWT, for example a list of JSON pointers with a mapping to the
respective redaction reasons.


This assumes the issuer knows why the holder chose not to disclose a 
field For some use cases that's probably a knowable thing... it 
also prevents the holder from using the disclosures as an unsecured 
channel to communicate with the verifier.


-Daniel

Am 18.10.23 um 05:03 schrieb Tom Jones:

That's leaking the existence of PII. That requires permission of
the subject. I think it's way more complicated than you think.

thx ..Tom (mobile)

On Tue, Oct 17, 2023, 6:20 AM Orie Steele
 <mailto:orie@transmute.industries> wrote:

Hello,

In government documents that feature redaction, it's common
for the redaction to be given a reason.

For example, in the Mueller report, we can see "Harm to
Ongoing Matter", "Personal Privacy", "Investigative
Technique", as well as "IT" and "HOM".

In SD-JWT we see the following:

Case 1

"_sd": [
      "IjCRF...znc", // disclosure hash
      "Qdpt9pL...lhU9UDo" // disclosure hash
]

and

Case 2

{ "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash  }

After verification and applying disclosures these annotations
are no longer present.

I wonder if it would be worth allowing a reason for why a
holder might have retained a redaction (or chose not to
disclose for a reason).

Since the payload is committed to by the issuer, this
information would have to be present in the disclosures
collection for the SD-JWT.

Here is an example disclosure:

[
  "8UbQ9NZ6xseoDqMW_Bd50A", // salt
  "type", // json object key (always a string)
  [ // json object value
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ]
]

Consider the following strawman syntax for disclosing a
redaction reason:

{
  "disclosure hash" : "Personal Privacy" || "Harm to Ongoing
Matter"
}

This allows a UI to map the redaction reason into a
presentation (ui) layer for the issuer secured payload.

Since it's an unsecured object, it can be extended with other
fields at the discretion of the holder or issuer.

However it might be secured by nesting it inside another JWT
or SD-JWT.

It would only slightly complicate the verification logic, you
would need to filter any encoded disclosures by the `ey`
prefix, since they will never be found in the payload, as we
know they will hash differently than array encoded
disclosures, which will be found in the payload.

I'll be giving a presentation on this topic to the W3C
Credentials community group later today, happy to shuttle
their reactions back to this list.

Apologies if this has been discussed previously.

Regards,

OS


-- 



ORIE STEELEChief Technology Officerwww.transmute.industries
<http://www.transmute.industries>

<https://transmute.industries>

___
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


-- 
Please use my new email address:m...@danielfett.de


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



--


ORIE STEELEChief Technology Officerwww.transmute.industries

<https://transmute.industries>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Clarification on SD-JWT verification

2023-10-20 Thread Daniel Fett


Hi Jacob,

the intention was to cover the first case you listed. We should clarify 
this.


-Daniel

Am 20.10.23 um 15:02 schrieb Jacob Ward:

Hello again,

On a similar note to my previous email, could I get some clarity on a 
step in the SD-JWT verification process?


/4. If any digests were found more than once in the previous step, the 
SD-JWT MUST be rejected.


/
Step 4 in Section 6.1 (as shown above) could have multiple meanings in 
my opinion:
- The digest was found multiple times (for example in an "_sd" array 
and as an array element).

- More than one Disclosure have the same digest.

On first reading of this I assumed that this step only covered the 
first of those two cases, but it has been pointed out to me by a 
colleague that it could cover both. If it is the case that both cases 
are covered by this step, then I think it would be helpful to clarify 
this in the text.


Cheers,

Jacob

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Verification strictness

2023-10-20 Thread Daniel Fett


Hi Jacob,

this check is mainly important for the Holder to ensure the integrity of 
the received SD-JWT. For the Verifier, there is not much to gain by 
checking this (but it also doesn't hurt either).


However, we intended to keep the algorithms for the Holder and Verifier 
similar and therefore decided to not make an exception for the Verifier 
here. It also enforces good "hygiene" for the Holder to not send any 
Disclosures that don't belong into the SD-JWT (for example, a Disclosure 
that originates from a claim in a recursive data structure, but where 
the parent claim is not disclosed to the Verifier). This can also help 
to avoid privacy problems.


-Daniel

Am 20.10.23 um 10:58 schrieb Jacob Ward:

Hello all,

Please let me know if there's a better channel to ask questions and/or 
raise issues with the SD-JWT spec.


Currently as part of verification of an SD-JWT the following is stated:

/Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that /

  * /the Issuer-signed JWT is valid, i.e., it is signed by the Issuer
and the signature is valid, and/
  * /*all Disclosures are correct, i.e., their digests are referenced
in the Issuer-signed JWT.*/

As highlighted I have a question about this second bullet point. Can I 
ask why the Disclosures must be referenced in the Issuer-signed JWT 
and not simply ignored if they do not exist in the JWT? There doesn't 
appear to be a security benefit to simply halt and to not verify what 
could otherwise be a valid SD-JWT, as the unbound Disclosures would 
never be processed as part of the SD-JWT verification anyway.


Apologies if this is something that has previously been discussed.

Jacob Ward

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Redaction Reasons

2023-10-20 Thread Daniel Fett

At least at the moment I don't think that there is a huge need for such 
a feature. I don't think that we should clutter the existing SD-JWT data 
structures with such information.


If required, it could go into a separate data structure in the SD-JWT, 
for example a list of JSON pointers with a mapping to the respective 
redaction reasons.


-Daniel

Am 18.10.23 um 05:03 schrieb Tom Jones:
That's leaking the existence of PII. That requires permission of the 
subject. I think it's way more complicated than you think.


thx ..Tom (mobile)

On Tue, Oct 17, 2023, 6:20 AM Orie Steele  
wrote:


Hello,

In government documents that feature redaction, it's common for
the redaction to be given a reason.

For example, in the Mueller report, we can see "Harm to Ongoing
Matter", "Personal Privacy", "Investigative Technique", as well as
"IT" and "HOM".

In SD-JWT we see the following:

Case 1

"_sd": [
      "IjCRF...znc", // disclosure hash
      "Qdpt9pL...lhU9UDo" // disclosure hash
]

and

Case 2

{ "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash }

After verification and applying disclosures these annotations are
no longer present.

I wonder if it would be worth allowing a reason for why a holder
might have retained a redaction (or chose not to disclose for a
reason).

Since the payload is committed to by the issuer, this information
would have to be present in the disclosures collection for the SD-JWT.

Here is an example disclosure:

[
  "8UbQ9NZ6xseoDqMW_Bd50A", // salt
  "type", // json object key (always a string)
  [ // json object value
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ]
]

Consider the following strawman syntax for disclosing a redaction
reason:

{
  "disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
}

This allows a UI to map the redaction reason into a presentation
(ui) layer for the issuer secured payload.

Since it's an unsecured object, it can be extended with other
fields at the discretion of the holder or issuer.

However it might be secured by nesting it inside another JWT or
SD-JWT.

It would only slightly complicate the verification logic, you
would need to filter any encoded disclosures by the `ey` prefix,
since they will never be found in the payload, as we know they
will hash differently than array encoded disclosures, which will
be found in the payload.

I'll be giving a presentation on this topic to the W3C Credentials
community group later today, happy to shuttle their reactions back
to this list.

Apologies if this has been discussed previously.

Regards,

OS


-- 



ORIE STEELEChief Technology Officerwww.transmute.industries



___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

2023-10-04 Thread Daniel Fett


I am not aware of any IPR associated with this document.

-Daniel

Am 04.10.23 um 17:10 schrieb Tschofenig, Hannes:


In my earlier email I forgot to include John.

John, I also need your confirmation!

*Von:*OAuth  *Im Auftrag von *Tschofenig, Hannes
*Gesendet:* Mittwoch, 4. Oktober 2023 15:41
*An:* oauth@ietf.org
*Betreff:* [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current 
Practice


Hi Daniel, Torsten, Andrey,

as part of the shepherd write-up, all authors of 



must confirm that any and all appropriate IPR disclosures required for 
full


conformance with the provisions of BCP 78 and BCP 79 have been filed.

Here is the draft:

draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current 
Practice 



Please, reply to this email, on the mailing list, and indicate if you are

aware of any IPRs associated with this document.

Ciao

Hannes


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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

2023-10-01 Thread Daniel Fett


I support adoption.

Am 30.09.23 um 14:52 schrieb Rifaat Shekh-Yusef:

All,

This is an official call for adoption for the *JWT and CWT Status 
List* draft:

https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/

Please, reply *on the mailing list *and let us know if you are in 
*favor *or*against *adopting this draft as WG document, by *Oct 13th*.


Regards,
 Rifaat & Hannes

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC9449 (7646)

2023-09-18 Thread Daniel Fett


The erratum looks correct to me.

-Daniel

Am 18.09.23 um 08:57 schrieb RFC Errata System:

The following errata report has been submitted for RFC9449,
"OAuth 2.0 Demonstrating Proof of Possession (DPoP)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7646

--
Type: Editorial
Reported by: Michiel Albracht

Section: 4.2

Original Text
-
When the authentication server or resource server provides a DPoP-Nonce

Corrected Text
--
When the authorization server or resource server provides a DPoP-Nonce

Notes
-
authentication server must be authorization server

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC9449 (draft-ietf-oauth-dpop-16)
--
Title   : OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Publication Date: September 2023
Author(s)   : D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. 
Jones, D. Waite
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

2023-08-28 Thread Daniel Fett


+1

Am 28.08.23 um 10:33 schrieb Joseph Heenan:

I support adoption.

Joseph


On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef 
 wrote:


All,

This is an official call for adoption for the *Protected Resource 
Metadata* draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *Sep 6th.*


Regards,
 Rifaat & Hannes

___
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

2023-08-24 Thread Daniel Fett


Thanks, Hannes.

The fact that technologies like AnonCreds are based on such old 
principles, yet they are not uniformly standardized, often times limited 
to a few implementations that may or may not be secure, are full of 
security footguns, lack hardware support, and are just extremely hard or 
impossible to deploy speaks for itself.


That's why things like SD-JWT exist and gain traction.

Yes, you have to jump through hoops to get unlinkability, but it is not 
impossible, and it seems to be a good tradeoff for many.


-Daniel

Am 24.08.23 um 11:55 schrieb Hannes Tschofenig:

Hi Watson,


deploying technologies can be complex because the incentives need to
align. Not everything that looks great on paper gets adopted in the time
frame or manner we like. In this specific case U-Prove has not been seen
excitement in the industry. There are reasons but it is difficult to say
what those exactly are.


In the OAuth group we have been trying hard to rally the community
around the use of specific technologies. I see SD-JWT as a stepping
stone in the right direction. As time progresses we will see other
technologies surface again and we have the JSON Web Proof work in our
pipeline.


In any case, we have to not just look at the list of features but also
reach out to those who deploy the technologies in question and to listen
to them.


Ciao

Hannes


Am 23.08.2023 um 07:32 schrieb Watson Ladd:

Dear all,

I read with alarm that the EU Digital Wallet is mandating SD-JWT,
perhaps under the illusion that it meets the standard, 22 year old
security definition for schemes of this type. It of course doesn't, as
said quite clearly in the security considerations section 10.4 and
10.5. Why on earth are we pursing this "solution" when actual
solutions to the problems presented have existed for 19 years? There's
been substantial research on this area, as seen in Microsoft's U-Prove
system just to name one instance.

This is apparently an article of discussion on the EU Digital Wallet
project as well, but I think the IETF needs to have its own discussion
of the issues here and not just say "well, it would be nice if we had
an RFC for this" especially given the negative privacy impacts.

Sincerely,
Watson Ladd

PS: they appear quite aware, but apparently convening the right
committee to approve the signature scheme is too hard. Anyway, not
relevant to us in the IETF.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

2023-08-23 Thread Daniel Fett


Hi Watson,

can you please be specific about the "standard, 22 year old security 
definitions" and "schemes of this type"?


Not having to make assumptions would certainly help to have a useful 
discussion.


-Daniel

Am 23.08.23 um 07:32 schrieb Watson Ladd:

Dear all,

I read with alarm that the EU Digital Wallet is mandating SD-JWT,
perhaps under the illusion that it meets the standard, 22 year old
security definition for schemes of this type. It of course doesn't, as
said quite clearly in the security considerations section 10.4 and
10.5. Why on earth are we pursing this "solution" when actual
solutions to the problems presented have existed for 19 years? There's
been substantial research on this area, as seen in Microsoft's U-Prove
system just to name one instance.

This is apparently an article of discussion on the EU Digital Wallet
project as well, but I think the IETF needs to have its own discussion
of the issues here and not just say "well, it would be nice if we had
an RFC for this" especially given the negative privacy impacts.

Sincerely,
Watson Ladd

PS: they appear quite aware, but apparently convening the right
committee to approve the signature scheme is too hard. Anyway, not
relevant to us in the IETF.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

2023-07-31 Thread Daniel Fett


I support adoption.

Am 29.07.23 um 21:27 schrieb Rifaat Shekh-Yusef:

All,

This is an official call for adoption for the *Attestation-Based 
Client Authentication *draft discussed in SF.

https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *August 11th*.


Regards,
 Rifaat & Hannes


___
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] OAuth Security Workshop 2023

2023-07-13 Thread Daniel Fett


Hi all,

registration is (finally) open for OSW 2023. Please follow this link: 
https://oauth.secworkshop.events/osw2023


Accommodation at the University's student dormitories can be booked via 
the online shop as well (single and double rooms). All of these rooms 
are located on campus close to our conference venue.


-Daniel

Am 19.05.23 um 16:15 schrieb Daniel Fett:


All,

we are very happy to announce that the Call for Sessions for the OAuth 
Security Workshop 2023 in London is now open!


We have two deadlines this time, June 4th and July 2nd, in order to 
provide early feedback for those that need confirmed talks (e.g., for 
company sponsorship). Please find all details at 
https://oauth.secworkshop.events/osw2023 
<https://oauth.secworkshop.events/osw2023>


You will also find a schedule outline for your travel planning there. 
We are still working on registration, accommodation and sponsorship 
opportunities. Please find all information that we have at this point 
on the website!


Let me know if there are any questions!

-Daniel


___
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] BCP: Mix-Up Attacks, Implicit Grant Variant

2023-06-14 Thread Daniel Fett


Hi Alexander,

Am 14.06.23 um 15:19 schrieb Alexander Rademann:

**

Hello, everyone!

Section 4.4.1 of the BCP 
 
draft lists several variants of mix-up attacks; the description of the 
Implicit grant variant reads as follows: "In the implicit grant, the 
attacker receives an access token instead of the code; the rest of the 
attack works as above."


Given the attack description in that section, it is not clear to me 
why an attacker would receive the access token and which part the 
"rest of the attack" refers to. When the Implicit grant is used, H-AS 
sends the access token (via redirect) to the user agent, which 
extracts it and sends it to the client. However, the client does not 
send the access token to A-AS, does it? (I hope that I didn’t overlook 
anything in that section.)




I also checked the referenced paper 
; there, the authors assume that the 
access token is sent to the authorization server under the control of 
the attacker (or, using their terminology, identity provider) to 
access some resource. [Appendix B, p. 31ff] Perhaps this (or some 
similar) assumption should be added to the description of this variant?


**


The underlying assumption is that when then user selected to use A-AS in 
the beginning, the access token would also be used with a Resource 
Server under the attacker's control.


-Daniel



**

I'm sorry if I missed anything or if this has already been addressed 
before, I'm new to this mailing list and did not find anything in the 
archives.


Kind regards

Alex



___
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] Simplification and consolidation of SD-JWT terminology and format

2023-06-14 Thread Daniel Fett


Hi Hannes,

maybe it was a bit implicit, but the point of Brian's email was to 
specifically do what you said - discuss this normative change here first.


Although this is an extremely small change, we are conscious about not 
introducing breaking changes unless there is a tangible, practical 
advantage. This is such a change and we would be interested to hear 
feedback from the list.


To illustrate the change further, taking Example 1 from the spec, the 
issuance would be changed from the current format:


eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZ
Gs2V0JwWnlnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5T
k9PQVljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04R
EtZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2ZwU
ElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQVROM29RT
DlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQkNGR3FkRzJvI
iwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMGhyRE8wNzgiXSwgI
mlzcyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwM
DAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOiAic2hhLTI1NiIsICJjbmYiO
iB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4IjogIlRDQUVSM
TladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV
1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0NGpUOUYySFpRIn19fQ.Kxtki3s03m
PtQQ1huyZvoTggStQWfcNrcKSOZ2Kdn5XNmT-jLK0JGYMPH8_ZF4wiSGhx-KzPNXOwqz
euff9kjA

To this new format:

eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZ
Gs2V0JwWnlnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5T
k9PQVljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04R
EtZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2ZwU
ElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQVROM29RT
DlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQkNGR3FkRzJvI
iwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMGhyRE8wNzgiXSwgI
mlzcyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwM
DAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOiAic2hhLTI1NiIsICJjbmYiO
iB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4IjogIlRDQUVSM
TladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV
1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0NGpUOUYySFpRIn19fQ.Kxtki3s03m
PtQQ1huyZvoTggStQWfcNrcKSOZ2Kdn5XNmT-jLK0JGYMPH8_ZF4wiSGhx-KzPNXOwqz
euff9kjA~

(Note the additional ~ at the end.)

The suggested clarification in the terminology will help to make the 
spec more concise and clear.


-Daniel

Am 14.06.23 um 09:27 schrieb Hannes Tschofenig:


Hi Brian,


please note that this is a working group item and you cannot make 
decisions in a small group with off-line discussions.


Hence, I suggest to propose the changes to the list and get support 
for it. As you know, we need to follow this approach to give everyone 
in the group a chance to get their voice heard.



Ciao
Hannes


Am 13.06.2023 um 20:58 schrieb Brian Campbell:
Following some offline discussions and feedback there's a plan to 
make some small simplifying changes to the SD-JWT draft to 
consolidate the format and associated terminology. Basically the 
terms "Combined Format for Issuance" and "Combined Format for 
Presentation'' will go away and the whole structure, issued or 
presented, can simply be called an SD-JWT. To align the two formats, 
the last Disclosure will always be followed by a `~` (tilde) 
character (currently the Combined Format for Issuance does not have 
the trailing tilde). When holder/key binding is required for 
presentation of a SD-JWT, a holder/key binding JWT will be appended 
to the end of the whole thing after the trailing tilde. That's all 
there is to it, which isn't much, but I think the result will be 
shortening and simplifying the spec text. And also make the 
terminology easier and more natural when talking about uses or 
applications of SD-JWT.


/CONFIDENTIALITY NOTICE: This email may contain confidential and 
privileged material for the sole use of the intended recipient(s). 
Any review, use, distribution or disclosure by others is strictly 
prohibited.  If you have received this communication in error, please 
notify the sender immediately by e-mail and delete the message and 
any file attachments from your computer. Thank you./


___
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Security Workshop 2023

2023-05-19 Thread Daniel Fett


All,

we are very happy to announce that the Call for Sessions for the OAuth 
Security Workshop 2023 in London is now open!


We have two deadlines this time, June 4th and July 2nd, in order to 
provide early feedback for those that need confirmed talks (e.g., for 
company sponsorship). Please find all details at 
https://oauth.secworkshop.events/osw2023 



You will also find a schedule outline for your travel planning there. We 
are still working on registration, accommodation and sponsorship 
opportunities. Please find all information that we have at this point on 
the website!


Let me know if there are any questions!

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

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

2023-04-13 Thread Daniel Fett


Hi Lars,

we addressed your comments in -15 which we just uploaded: 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html


-Daniel


Am 12.04.23 um 17:07 schrieb Brian Campbell:
Thank you, Lars, for the review and ballot. I put together this small 
PR with updates for the comments/nits 
https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/4


On Wed, Apr 12, 2023 at 5:18 AM Lars Eggert via Datatracker 
 wrote:


Lars Eggert has entered the following ballot position for
draft-ietf-oauth-step-up-authn-challenge-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

for more information about how to handle DISCUSS and COMMENT
positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/



--
COMMENT:
--

# GEN AD review of draft-ietf-oauth-step-up-authn-challenge-14

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team
(Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/oLXp-vndky-rjnfs7kkHjH8acSg).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for
background and more
guidance:

 * Term `traditional`; alternatives might be `classic`,
`classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you
may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me
know what you
did with these suggestions.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://openid.net/specs/openid-connect-core-1_0.html

### Grammar/style

 Section 2, paragraph 12
```
hentication level, and the new one- selecting the appropriate
token for each
                               ^^
```
This word seems to be formatted incorrectly. Consider fixing the
spacing or
removing the hyphen completely.

 Section 4, paragraph 1
```
 Subsequent to the challenge in Figure 3, a cl
 ^
```
Consider using "after".

 Section 5, paragraph 1
```
 requirements, the resource servers needs a way of accessing
information abou
                                    ^
```
The verb form "needs" does not seem to match the subject "servers".

 Section 6.2, paragraph 6
```
ation server as a result of the requirements propagation method
described he
                                
```
An apostrophe may be missing.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You
can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the
[`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool




/CONFIDENTIALITY NOTICE: This email may contain confidential and 
privileged material for the sole use of the intended recipient(s). Any 
review, use, distribution or disclosure by others is strictly 
prohibited.  If you have received this communication in error, please 
notify the sender immediately by e-mail and delete the message and any 
file attachments from your computer. Thank you./


___
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] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

2023-04-13 Thread Daniel Fett


Hi Warren,

we addressed your comments in -15 which we just uploaded: 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html


-Daniel


Am 12.04.23 um 01:18 schrieb Warren Kumari:





On Tue, Apr 11, 2023 at 4:10 PM, Brian Campbell 
 wrote:


Thank you, Warren, for the review and ballot. I've replied inline
below and put together this small PR with corresponding edits:
https://github.com/danielfett/draft-dpop/pull/183/files


On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker
mailto:nore...@ietf.org>> wrote:

Warren Kumari has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)


Please refer to

https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/



for more information about how to handle DISCUSS and COMMENT
positions.


The document, along with other ballot positions, can be found
here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/




--
COMMENT:
--

Thank you for writing this; I found it a fascinating and
informative read.


Appreciate that! Thanks :)


I don't have any particularly substantive comments, but I do
have some nits and
similar to hopefully further improve the document.

1: "These stolen artifacts can later be used together
independent of the client
application to access protected resources." -- I found this
really hard to
parse. I think that some of it is the "used together
independent" formulation -
adding a comma would help, but I think just dropping
"together" works even
better (it does say "artifacts" in plural, so that's already
covered?)


Indeed that is really hard to parse. I agree with dropping the
word "together".



Ta!




2: "Properly audience restricting access tokens can prevent
such misuse" - I
think that it would be helpful to reword this, or find a
reference for
"audience restricting"


That sentence caught the ire of Éric Vyncke in his review/ballot
and already had one attempt at improvement by me

.
But I can also add a reference, of sorts. I'm not aware of a
good/easy reference for the concept of audience restricting but
can point to the RFC7519 JWT `aud` claim as an example of .



Okey dokey, thanks.




3: Might it be worth adding a reference for XSS? I'm guessing
that the audience
will already be familiar, but if not,
https://owasp.org/www-community/attacks/xss/
 ?


I feel like "cross-site scripting (XSS)" stands on its own okay
and still gives an unfamiliar audience enough to search for more
info.


Fair 'nuff.



4: Question: Why is the Nonce optional? Perhaps I missed it,
but I was unable
to find any discussion (I was expecting something in Sec 8,9
or 10) providing
some reason why a server might not use a nonce (the closest I
found was "The
logic through which the server
   makes that determination is out of scope of this
document.", so I'm guessing
   that there *is* a reason, but... )


Long story short, the reason is basically that there's complexity
and extra round trip costs in using it. And there were and are
differing perceptions of its value in different circumstances. The
rough consensus was to leave its use (if/when/how) at the
discretion of the server.



Okey dokey, works for me. Feel free to ignore this comment, but 
mentioning that some implementations might choose not to use a nonce 
because of "complexity and extra round trip costs" might be helpful 
for others like me who were mystified.

(I really do mean feel free to ignore this, I won't be offended :-P)
W




/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s).
Any review, use, distribution or disclosure by others is strictly
prohibited.  If you have received this communication in error,

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

2023-04-13 Thread Daniel Fett


Hi Eric,

we addressed your comments in -15 which we just uploaded: 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html


-Daniel


Am 11.04.23 um 17:05 schrieb Eric Vyncke (evyncke):


Thank you, Brian, for your prompt reply and the PR.

Your point about the tags around "none" is well taken.

Regards

-éric

*From: *Brian Campbell 
*Date: *Tuesday, 11 April 2023 at 16:11
*To: *Eric Vyncke 
*Cc: *The IESG , "draft-ietf-oauth-d...@ietf.org" 
, "oauth-cha...@ietf.org" 
, "oauth@ietf.org" , 
"rifaat.s.i...@gmail.com" 
*Subject: *Re: Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: 
(with COMMENT)


Thanks for the review and ballot Éric. I've replied inline below and 
put together this PR with corresponding edits: 
https://github.com/danielfett/draft-dpop/pull/182/files


On Mon, Apr 10, 2023 at 11:45 PM Éric Vyncke via Datatracker 
 wrote:


Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

for more information about how to handle DISCUSS and COMMENT
positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/



--
COMMENT:
--


Thank you for the work put into this document.

Please find below some non-blocking COMMENT points, and some nits.

Special thanks to Rifaat Shekh-Yusef for the shepherd's detailed
write-up
including the WG consensus (and the author count) even if the
justification of
the intended status is rather light.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non blocking)

## Section 1

Should there be a reference to OAuth ?

Sure, we'll add a RFC6749 reference with OAuth in that first sentence 
in Section 1.



s/The mechanism described herein /The mechanism specified herein /
? as it is
proposed standard

Makes sense. We'll update.


Adding a short description of SPA would be useful, or simply
remove this
reference ?

I'll try to rephrase that sentence somewhat to be more descriptive.

# NITS (non blocking / cosmetic)

## Section 2

` Properly audience restricting access tokens can prevent such
misuse` is
difficult to parse

I'll try to tighten it up.

## Section 4.1

s/repeated below for ease of reference/repeated below in figure 3
for ease of
reference/ ?

Sure, I'll change to ref figure 3.


## Section 4.2

s/MUST NOT be none or an identifier for a symmetric algorithm
(MAC)/MUST NOT be
'none' or an identifier for a symmetric algorithm/

  "none" is wrapped in a  tag in the HTML/HTMLized 
versions of the draft, which is consistent with treatment of other JWS 
algorithm literals in the document.



## Section 6.1

`JSON Web Tokens (JWT)` the JWT acronym has already been defined.

 Good point. I'll just use the acronym there.


*/CONFIDENTIALITY NOTICE: This email may contain confidential and 
privileged material for the sole use of the intended recipient(s). Any 
review, use, distribution or disclosure by others is strictly 
prohibited.  If you have received this communication in error, please 
notify the sender immediately by e-mail and delete the message and any 
file attachments from your computer. Thank you./*



___
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] Murray Kucherawy's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

2023-04-13 Thread Daniel Fett

Thanks for your comments, Murray!

Replies below.

Am 13.04.23 um 07:45 schrieb Murray Kucherawy via Datatracker:

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

--
COMMENT:
--

Most of the SHOULDs here seem unsupported to me, in the sense that I'm not
clear what interoperability breaks if I decide not to do what it says. Some
prose about that would be helpful to include.

Looking at the draft again, we have only a few SHOULDs and for all of
them I think it is clear what the consequences are of not doing it.

For example, the first one reads "To reduce the likelihood of false
negatives, servers SHOULD..." which implies that not following the
SHOULD means risking false negatives. The other instances are concerned
with providing information to clients in DPoP challenges. I think it is
sufficiently clear that not providing this information may make it
harder for the client to respond properly and to debug errors.

At this time, we do not see the need for additional explanation for any
of the SHOULDs.

I know this isn't the first OAUTH document I've reviewed, but I still find it
strange that claim names are not quoted or in all-caps or something. In prose,
they just look like typos to me.

As I wrote in the thread for Step-Up Authn:

"Since the same comment was raised also for DPoP, my two cents on this:

We discussed this very topic when finalizing RFC9207. Back then, we
noticed that when using the correct markup in the XML (), the HTML
renders fine (gray background, monospaced font) but depending on how the
textual format is created, there may or may not be quotes around the
parameter. Adding quotes manually in the XML source does not make too
much sense as they'll needlessly show up in the HTML as well. IIRC there
was some version of xml2rfc that added quotes around parts but that
was removed again.

So the consensus was that prioritizing proper HTML output makes sense
and we did not add any quotes (with the blessing of the RFC editor)."

-Daniel

___
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] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

2023-04-13 Thread Daniel Fett




Am 13.04.23 um 08:11 schrieb Vittorio Bertocci:
On the SHOULD on top of S4. There are pretty common situations in 
which failing to get a response from an API is an acceptable outcome, 
and presenting an interactive prompt isn't. A classic example is a 
background update that the client can use to proactively fetch fresh 
data, that isn't critical for the application function and wasn't 
initiated by the user. As such, an interactive prompt could disrupt 
the user experience by requiring an action without clear context and 
not in pursuit of a goal the user expressed. A MUST would force a 
complying client to act on the challenge, making those scenarios hard 
to handle.


On the SHOULD on top of S5. There we are just describing what the OIDC 
specification mandates for ID tokens, hence not providing any new 
normative guidance.We echo what OIDC mandates for ID tokens there 
because we want to apply the same logic for access tokens, as we later 
describe in the same section. In that description we don't introduce a 
more restrictive MUST because that would make it hard for the (many) 
existing authorization server+OIDC implementations to comply, limiting 
adoption and for a relatively small return.


On the quotes: Brian has more experience in RFC authoring than I do, 
but it's night on his part of the world hence I cannot consult him :) 
However in the only other spec I authored (rfc9068) I did use quotes 
for every claim occurrence in the text, hence I am confident we can do 
the same here. Thanks for the catch!


Since the same comment was raised also for DPoP, my two cents on this:

We discussed this very topic when finalizing RFC9207. Back then, we 
noticed that when using the correct markup in the XML (), the HTML 
renders fine (gray background, monospaced font) but depending on how the 
textual format is created, there may or may not be quotes around the 
parameter. Adding quotes manually in the XML source does not make too 
much sense as they'll needlessly show up in the HTML as well. IIRC there 
was some version of xml2rfc that added quotes around  parts but that 
was removed again.


So the consensus was that prioritizing proper HTML output makes sense 
and we did not add any quotes (with the blessing of the RFC editor).


-Daniel





On Wed, Apr 12, 2023 at 9:59 PM Murray Kucherawy via Datatracker 
 wrote:



  This message originated outside your organization.


Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-step-up-authn-challenge-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

for more information about how to handle DISCUSS and COMMENT
positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/



--
COMMENT:
--

Thanks to Robert Sparks for the ARTART reviews and Mark Nottingham
for the
HTTPDIR review.  Please make sure the former was fully addressed
before
proceeding.

The SHOULD at the top of Section 4 is bare.  What happens if I
don't do that?
Or should this really be a MUST?

Same question for the first SHOULD in Section 5.  Is there ever a
legitimate
reason not to do what it says?

I feel that claim names such as "acr" should be quoted.  They look
like
misspelled words otherwise.




___
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] OAuth 2.0 Proof-of-Possession (PoP) Security Architecture

2023-04-03 Thread Daniel Fett


Hi Nat,

after reading through the PoP architecture document again, my impression 
is that this document had a lot of value before MTLS and DPoP came 
along. But when thinking about what an updated version could look like, 
and considering that it is unlikely for the moment that many other PoP 
methods will be standardized soon, I wonder if it wouldn't be a mostly 
theoretical discourse today.


-Daniel

Am 10.02.23 um 17:23 schrieb Nat Sakimura:

Hi

OAuth 2.0 Proof-of-Possession (PoP) Security Architecture[1] has not 
progressed and expired since 2017.


[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture-08


I just noticed it because I wanted to refer to it in one of the 
papers I am involved with. IMHO, it has got good information worth 
making referencable. Has it been an explicit decision to abandon the 
document, or is it just the result of the priority of the editors and 
this WG shifted away? Is there an appetite to progress it?


Best,
--
Nat Sakimura

___
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] OAuth WG Agenda @ IETF116

2023-03-21 Thread Daniel Fett


Thank you, Rifaat!

I see the side meetings listed at 
https://wiki.ietf.org/meeting/116/sidemeetings for Wednesday and 
Thursday, 10-11:30. Is that final?


-Daniel

Am 21.03.23 um 13:35 schrieb Rifaat Shekh-Yusef:


*Tuesday
*
Chairs update – Rifaat/Hannes (10 min)
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01

SD-JWT – Kristina/Daniel – (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

Browser-based Apps – Aaron (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

OAuth 2.1 – Aaron (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

Client/Trust Management – Kristina/Torsten (20 min)

Protected Resource Metadata – Mike (15 min)
https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata

OAuth & SPIFFE – Evan/Pieter (15 min)
https://spiffe.io/



*Friday
*
JWT Embedded Tokens – Rifaat/Dick (15 min)
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

Cross Device Flow – Pieter (15 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

Identity Chaining – Rifaat/Pieter (20 min)

Native Apps UX – Aaron/Pieter (20 min)

Authorization Server Discovery – Aaron/Ben (20 min)
https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/

PoP Security Architecture – Nat (15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture

Power of Attorney (PoA) Grant Type – Olov (15 min)
https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/

Regards,
 Rifaat & Hannes


___
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] Call for adoption: Cross-Device Flows

2022-11-23 Thread Daniel Fett


I support adoption of this document.

-Daniel

Am 15.11.22 um 15:43 schrieb Rifaat Shekh-Yusef:

All,

During the IETF meeting last week, there was a strong support for 
the adoption of the following document as a WG document:

https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/

This is to start a call for adoption for this document.
Please, provide your feedback on the mailing list on whether you 
support the adoption of this document as a WG or not, by *Nov 29th*.


Regards,
 Rifaat & Hannes



___
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] Alternative social event today

2022-11-08 Thread Daniel Fett


Hi all,

for those at IETF115 that don't have a social event ticket, let's meet 
at 6pm at the IETF registration desk and find a nice place for dinner.


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

Re: [OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53

2022-10-26 Thread Daniel Fett


Hi Christian,

thanks for bringing this to our attention! I think the recommendations 
in the PR are very helpful and we will consider adding the text to the 
document.


-Daniel

Am 25.10.22 um 15:37 schrieb Christian Mainka:

Hi,

we would like to request the inclusion of _in-browser communication 
security considerations_ in the OAuth security topics.


We found that in-browser communications like the postMessage API is 
widely used by Clients and Authorization Servers as an alternative to 
the standardized HTTP redirects.
If these techniques are used insecurely, OAuth token leaks and 
injections are possible.


We publish our results soon at ACM CCS in November 2022.
The paper is accessible [1].

We think that the paragraph about in-browser communications should be 
added to the security topics.
We created a pull request [2] to help developers in understanding the 
risks and best practices of using in-browser communications in OAuth.


We are happy to discuss the idea here or directly in the pull request.

Best regards
Christian

[1]: "DISTINCT: Identity Theft using In-Browser Communications in 
Dual-Window Single Sign-On, https://distinct-sso.com/paper.pdf


[2]: 
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/53
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - IPR Disclosure

2022-08-12 Thread Daniel Fett

I am not aware of any IPR relating to this document.  

-Daniel


Am 10. August 2022 23:37:20 MESZ schrieb Rifaat Shekh-Yusef 
:
>Daniel, Brian, John, Torsten, Mike, and David,
>
>As part of the shepherd write-up for the *DPoP* document, there is a need
>for an IPR disclosure from the authors.
>https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
>Are you aware of any IPRs associated with this document?
>
>Regards,
> Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT

2022-08-05 Thread Daniel Fett

It's not that the people I have spoken to didn't like the idea of SD-JWT. It's 
just on a different layer than JWPs, using a different approach, different 
crypto, providing different features, and on a different timeline. There's no 
compelling reason to have both in the same WG. There are nonetheless good 
reasons to have SD-JWT. Having SD-JWT in OAuth WG is not an attempt to 
"backdoor" anything in!

I also didn't say that we should adopt SD-JWT because it has been implemented. 
You took my statement out of context. I wanted to underline that the spec is 
practically feature-complete and can be implemented today, providing the 
features promised. Meanwhile, JWP is not there yet.

But, SD-JWT is not in production yet. If the OAuth WG decides that substantial 
changes are required, now is the best time for that.

Also, I wanted to highlight with my statement that SD-JWT is easy to implement 
due to its simplicity. 

-Daniel

Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad 
:
>Maybe they have a good reason for not wanting it, and then we shouldn't be
>the WG that backdoor's it in. Also: "other people have already implemented
>it" is a cognitive fallacy, so let's not use that as a justification we
>have to make the standard.
>
>We should get a concrete reason why a WG that seems like the appropriate
>one, thinks it wouldn't make sense. If it is just a matter of timing, then
>whatever. But if there are concrete recommendations from that group, I
>would love to hear them.
>
>On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett 40danielfett...@dmarc.ietf.org> wrote:
>
>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>
>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>> that WG once created
>>
>> Why?
>>
>> For the reasons listed, I guess?
>>
>> Also, mind the "As far as I am aware" part, but I don't remember any
>> discussions in that direction at IETF114.
>>
>> -Daniel
>>
>> ___
>> 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] Call for adoption - SD-JWT

2022-08-05 Thread Daniel Fett


Am 05.08.22 um 10:22 schrieb Warren Parad:
> and nobody involved in the JWP effort thinks that SD-JWT should be in that WG 
once created


Why?


For the reasons listed, I guess?

Also, mind the "As far as I am aware" part, but I don't remember any 
discussions in that direction at IETF114.


-Daniel

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

Re: [OAUTH-WG] Call for adoption - SD-JWT

2022-08-05 Thread Daniel Fett


Hi Jaimandeep,

Am 04.08.22 um 20:39 schrieb Jaimandeep Singh:

Dear All,
My compliments to all the collaborators including David for making 
efforts in answering the queries. However, I am of the opinion that we 
need to answer some of the more fundamental questions before arriving 
at any decision.


Let us first discuss if SD-JWT even meets the charter of the Working 
Group. We can divide the charter into smaller chunks and try to 
address each of them.



(...)


I am of the opinion that SD-JWT meets none of the objects set forward 
by the WG. Let us ask some further questions


I don't think that the list of topics the WG is working on is meant as 
an exhaustive list. JWTs were originally specified here, as well as a 
lot of work based on JWTs. SD-JWT is a generic mechanism expanding what 
can be done with JWTs.





Q1. What is the need of this feature?
We have a client application that registers the scopes with the 
Authorization Server in the first place. We have a resource owner 
(end-user) who authorizes such claims. With the introduction of SD-JWT 
we are again going back the full circle and asking client applications 
as to what scopes it deems fit to disclose to the outside world, why 
on the earth it asked for the scopes that it never needed in the first 
place.


Q2. It might not even meet the legal scrutiny. Why?
Ans. When the user has authorized some scopes it is equivalent to 
'click agreement'. Now, we are modifying those scopes with or without 
consent of the user. The client application is not bound to ask the 
user before preferring the SD-JWT claims to the Resource Server. Here 
we are challenging the complete concept of OAuth 2.0.


You seem to be missing that whatever an AS releases or allows is not 
touched by SD-JWT. When used for identity claims, SD-JWT allows the 
end-user to release *less* than what was put into a credential by an 
identity provider to the relying party. Other use cases are conceivable, 
e.g., for access tokens, but the point here is that for the selective 
disclosure aspect, user and whatever software they use both have an 
interest to release *less* data to whoever gets the data.





Q3. Is adoption of SD-JWT recommended in any of the draft documents 
like OAuth 2.1 or Best Security Practices?
Ans. As of now we have not found any suitable place for introducing it 
into the ecosystem.


The question you ask is misleading. Both OAuth 2.1 and the Security BCP 
not only predate SD-JWT by years, they are also concerned with 
traditional OAuth deployments. SD-JWT is a new feature for new 
deployments with specific requirements. Most deployments will not have 
any use for SD-JWT, and we will not bother them with adopting it, but 
for those that do, SD-JWT is an excellent alternative to other existing 
approaches. We will for sure not recommend SD-JWT as a mechanism for all 
OAuth setups, but SD-JWT will help to establish OAuth/OIDC in SSI and 
similar use cases.





Q3. Is there any other WG which is trying to solve the similar problem 
of SD-JWT?
Ans. Yes, WG-JWP (JSON Web Proofs) may be a more suitable place for 
the adoption of SD-JWT as they are working on a similar set of 
problems. They are actively seeking participation in the area of SD-JWT.


JWPs use advanced cryptography and a completely new format to solve the 
selective disclosure problem, but also many more things that SD-JWT 
cannot do. However, SD-JWT is available today, with four running 
implementations already, it is designed to be easily understood and 
implemented, and based on existing mechanisms (essentially, JWTs + 
hashing). As far as I am aware, a JWP WG is not chartered yet, and 
nobody involved in the JWP effort thinks that SD-JWT should be in that 
WG once created.





In my opinion, the SD-JWT is well thought out and a lot of hard work 
has gone behind it. However, this WG is not the right place for 
adoption as we have to work on more serious and immediate issues at 
hand. We may consider its adoption at a later time frame when we gain 
more maturity on how things are going forward.


You seem to imply that adopting SD-JWT would slow down work on other 
topics considerably. I don't think that that would be the case, given 
that other work in this group will not depend on SD-JWT. Also, with 
large projects world wide looking for credential formats such as SD-JWT, 
I think this is a somewhat serious and immediate topic.


-Daniel




Regards and Best Wishes
Jaimandeep Singh

On Thu, Aug 4, 2022 at 9:17 PM David Chadwick 
 wrote:


Answers inline below

On 03/08/2022 14:57, Torsten Lodderstedt wrote:



Am 02.08.2022 um 19:30 schrieb David Chadwick

:



Hi Torsten

your use case sounds like an online use case, not an offline
one. So its a question of balancing a long lived SD-JWT along
with a revocation mechanism vs a short lived minimal JWT
containing just the claims that are needed.

Re: [OAUTH-WG] Call for adoption - SD-JWT

2022-07-29 Thread Daniel Fett

+1 for obvious reasons.

Am 28. Juli 2022 21:12:49 GMT-04:00 schrieb Brian Campbell 
:
>I support adoption.
>
>On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef 
>wrote:
>
>> All,
>>
>> This is a call for adoption for the *SD-JWT* document
>> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>>
>> Please, provide your feedback on the mailing list by *August 12th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>-- 
>_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>material for the sole use of the intended recipient(s). Any review, use, 
>distribution or disclosure by others is strictly prohibited.  If you have 
>received this communication in error, please notify the sender immediately 
>by e-mail and delete the message and any file attachments from your 
>computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - Document Shepherd Review

2022-07-27 Thread Daniel Fett

Apologies accepted! :-)

Am 28.07.22 um 01:11 schrieb Brian Campbell:
I need to make one more apology - this time for the incorrect spelling
of Dr. Fett's name (should be Daniel not Danial). My apologies.

On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell
wrote:

Thanks Rifaat and others for the vibrant* discussions about the
DPoP draft in the side meeting yesterday.

I thought it'd be appropriate to share/reiterate the three action
items we'd agreed on during the meeting (as I remember anyway):

1. Justin to review the text about why we have the AT hash and
either create a PR adding additional motivations or say that
what we have is already sufficient
2. Danial to add some text to further explain decisions with
respect to PAR
3. Brian (aka me) to add a parenthetical remark to the Signature
Algorithms subsection listing 'ES256'

PR's for the latter two are here
and here
respectively.
And yes, this message is, at least in part, a passive-aggressive
reminder to Justin about #1.

The slides that I used to try and help guide the discussions are
attached. They are admittedly rather suboptimal but I'm including
them for the sake of transparency (and because they have a couple
of photos).

* my apologies for being overly vibrant at times

On Wed, Jul 6, 2022 at 4:32 PM Brian Campbell
wrote:

Thanks Rifaat!
I will make those changes in the document source and come to
Philly prepared to discuss the other items. One of the side
meetings seems like a good forum for that, good idea.

On Tue, Jul 5, 2022 at 11:14 AM Rifaat Shekh-Yusef
wrote:

Thanks Brian!
See my replies inline below.

On Thu, Jun 30, 2022 at 6:52 PM Brian Campbell
wrote:

Thanks for shepherding Rifaat. And apologies for the
slow reply. My attempts at answering questions and
responding to comments are inline below.

On Fri, Jun 3, 2022 at 11:55 AM Rifaat Shekh-Yusef
wrote:

The following is my review as a document shepherd:

Section 4.3

Last sentence

Since the document uses “SHOULD”, this implies
that there are some valid cases where this is not
needed.

Should a text be added to explain when this is not
needed?

What about giving a bit more context about why they
should? Changing that sentence to say, "To reduce the
likelihood of false negatives, servers SHOULD employ
Syntax-Based Normalization (Section 6.2.2
of [RFC3986]) and
Scheme-Based Normalization (Section 6.2.2
of [RFC3986])
before comparing the |htu| claim." And also maybe
changing it to a little "should".

Yes, that works.
I suggest keeping it as "SHOULD" to encourage implementers
to use this, unless they have a really good reason not to.

Section 6.1

First sentence - what is the reason for using
“SHOULD”, instead of “MUST” in this case?

Good question. I think it was a bit of carryover from
OAuth in general not strictly defining access token
format or content. And wanting to not encroach on
that. But that's kinda covered/allowed for in general
by Section 6 already. And Section 6.2 is effectively
the same as 6.1 but for introspection and it doesn't
use "SHOULD". I think the “SHOULD” in the first
sentence of 6.1 should be removed thereby making it an
implicit must - like "when using JWT, this is how it
is". That would align with the way it's described for
introspection. Also leaves some room for hash
algorithm agility via a new confirmation method member
(described in

https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-09.html#name-access-token-and-public-key)
without going against a "MUST"

I am fine with removing the "SHOULD" to make it an
implicit must.

The DPoP Proof contains a hash of the Access
Token, and the Access Token contains a hash of
the public key in the DPoP Proof.

Why do you need both? Would one

[OAUTH-WG] SD-JWT - New version - Call for adoption?

2022-07-11 Thread Daniel Fett


  
  
Hi all,
Kristina and I have just uploaded the latest
version of draft-fett-oauth-selective-disclosure-jwt. In
  this version, we address issues raised both in this working group
  and by other interested parties. Other issues are still under
  discussion in the issue
tracker.

Although the draft is relatively fresh, we have already seen a
  tremendous interest in this spec from various sides, including EU
  and US-based initiatives, governments, and large companies. Many
  projects already consider SD-JWT a serious alternative to more
  complex credential formats.
We think that this working group is an excellent place for the
  further development of the draft. After all, SD-JWT is based on
  JWT that was defined in this working group, and is expected to be
  widely used in OAuth and OAuth-based technologies. We would
  therefore like to ask the working group chairs to consider a Call
  for Adoption. 

While we know of four implementations already, the draft is (to
  our knowledge) not yet being used in production. Should the
  working group decide that substantial changes are required, now
  would be a good time for that.
-Daniel


  


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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett


Hi Nikos,

Am 28.06.22 um 13:22 schrieb Nikos Fotiou:


Hi Daniel,

I just want to reverse your arguments and I will stop spamming. I will 
focus on your “sub” example.


When a VC is encoded as a JWT, and according to specs 
(https://www.w3.org/TR/vc-data-model/#proof-formats) “sub MUST 
represent the id property contained in the credentialSubject” and the 
VC must be


signed. Similarly,  RFC 7253 JWT requires the “sub” claim to exist and 
the token to be signed. By moving “sub” to “sd_digests” you don’t have 
a valid VC or JWT. Similarly, by merging “the released claims into the 
plain-text claims and produce a plain-text JSON”  also results in 
non-valid VCs/JWTs since signature verification will fail.



There is no need to move sub to sd_digests, it can be left outside.

The signature verification obviously must be done by the verification 
algorithm before the merging. I don't imagine that the output of the 
verification algorithm will be a signed JWT (since it can't produce the 
signature), but just the payload. So instead of, for regular JWTs,


receive JWT -> check signature -> extract payload -> work with payload,

you would here have

receive SD-JWT -> check signature -> verify SD claims -> merge payload 
-> work with payload.


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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett

Hi Nikos,

the requirement for putting the claims into a separate structure becomes
more obvious from your example.

On the surface, you can see that the data types don't match the
specifications - the email address is not an email address, the phone
number is not a phone number, the address even has a completely
different data type.

Digging a bit deeper, the JWT in your example suggests that the issuer
attests that the user has the sub
'LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04' and the given_name
'fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs'. This is absolutely not
what the issuer wants to attest, but not clearly communicated in the
JWT. This is ambgiuous to anyone interpreting the JWT, especially if
they are unaware of the SD-JWT format, and various security problems can
arise from that. Putting the claims into a separate container makes the
distinction explicit.

Conversely, there is not really much to gain here by adhering - on the
surface! - to an existing structure. We are messing up types, as
described above, and contents. Anybody interpreting an SD-JWT needs to
implement verification logic anyway, so why bother hiding the
differences behind a familiar looking structure? I don't think that this
impedes integration, but rather fosters clean implementations.

A verification algorithm can merge the released claims into the
plain-text claims and produce a plain-text JSON that can then be fed
into whatever algorithm uses the contents. This is a trivial programming
exercise.

Regarding your proposal with the array below: This format does not work
well with structured claims (see Examples 2 and 3).

-Daniel

Am 28.06.22 um 10:30 schrieb Nikos Fotiou:

> If the SD-JWT-R does not contain all claim names, the verifier might
not be able to tell whether a particular claim is an SD claim or a
plain-text claim.

It is not obvious (at least to me) why the verifier needs to know
that. Moreover, I agree that this approach is unambiguous but, IMHO,
it is not clean and it impedes integration (e.g., as I wrote in the
previous email example 4 is (probably) wrong). If a verifier really
needs to know which claim is an SD claim, I believe a cleaner approach
is to indicate this using out-of-band mechanisms, e.g., provide this
information in a schema, in a VC “context”, documentation.
Alternatively, `sd_digests` can be just as an array that indicates
the SD claims, e.g., example 1 in section 5.2 could be:

{

"iss": https://example.com/issuer <https://example.com/issuer>,

"sub_jwk": {

"kty": "RSA",

"n":
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",

"e": "AQAB"

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",

"birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U",

"sd_digests":["sub", "given_name", "family_name", "email",
"phone_number", "address", "birthdate"]

}

Best,

Nikos

*From:*OAuth *On Behalf Of *Daniel Fett
*Sent:* Tuesday, June 28, 2022 10:30 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,

I was wondering what is the reason for introducing the sd_digests
claim. I think it complicates integration with existing systems.
For example, I am pretty sure that the VC included in Example 4 is
wrong. Since the verifier can learn from the SD-JWT-RELEASE which
claims are hashed, why is it necessary to nest them under the
sd_digests claim?

The idea is to have a clean, unambiguous seperation between the two.
If the SD-JWT-R does not contain all claim names, the verifier might
not be able to tell whether a particular claim is an SD claim or a
plain-text claim.

Also a small detail: if you decode the token at the end of section
5.2, instead of "sd_digests" it uses "_sd"

Good catch, we'll update the examples. We have opened an issue for
that:
https://github.com/oauthstuff/draft-se

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett


Hi Neil,

thanks for your feedback! The security considerations are certainly far 
from complete in this first draft (and didn't intend to be). Your 
comments will help us to improve this part of the draft.


Am 23.06.22 um 20:52 schrieb Neil Madden:
I’m not entirely sure the OAuth WG is a suitable venue for this kind 
of document. It should at least get some review from CFRG, to get 
feedback on the crypto aspects.


That would certainly be appropriate!



I have some initial comments about the cryptography being used.

Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE), 
but this does not necessarily commit the sender to CLAIM-VALUE. In 
section 7.4, I think you need to say that HASH must be collision 
resistant - otherwise the user can find two (salt, claim-value) pairs 
that collide and get the issuer to sign one and then reveal the other 
pair to the downstream party.

+1


The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length 
extension attacks is also troubling, even if I can’t see an immediate 
attack. But it’s a weird property that Bob, for example, could make a 
commitment to some extension of one of Alice’s claims without actually 
knowing her claim value.

That would mean the Bob would need to be an issuer in this case?


You can address both of these issues by instead using a compactly 
committing PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) 
rather than simple prefix hash.

Given the advantages, we will consider using an HMAC.


It doesn’t seem great to say that you can use any hash algorithm in 
the IANA registry, but then to rule out half of them as being not 
suitable in the security considerations - this list may go out of date 
as other hash algorithms are broken. Is it possible to update the IANA 
registry with a Recommended Y/N column? Also, shake128 and shake256 
are not collision-resistant hash functions, they are XOFs that can 
produce any length of output - e.g. shake128 with a 32-bit output 
would not be collision-resistant and thus would not be at all suitable 
for this usage. Given these considerations, I might be tempted to 
create a new IANA registry, or perhaps just pick one good hash 
function. (Or maybe just use the same hash algorithm as the signature?)


I don't know of such a registry, but I'm certain the current limitations 
in our spec are not sufficient and we need to improve this.


-Daniel

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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett


Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?
The idea is to have a clean, unambiguous seperation between the two. If 
the SD-JWT-R does not contain all claim names, the verifier might not be 
able to tell whether a particular claim is an SD claim or a plain-text 
claim.

Also a small detail: if you decode the token at the end of section 5.2, instead of 
"sd_digests" it uses "_sd"


Good catch, we'll update the examples. We have opened an issue for that: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79


Thanks,
Daniel



Best,
Nikos
--
Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr


On 23 Jun 2022, at 7:32 PM, Daniel Fett  
wrote:

All,

Kristina and I would like to bring to your attention a new draft that we have been 
working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original signed 
JWT instead of releasing all the claims to every verifier.

https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to hear from the 
working group with the eventual goal of asking for working group adoption.

Issues are tracked in our GitHub 
repository:https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues

The approach to selective disclosure described in the document is based on 
salted hashes. We have discussed and explored other approaches based on 
encryption as well. If you are interested in following this discussion, we 
would like to invite you to read this 
issue:https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30

One main goal with this work is that the format should be easy to implement, requiring little more than a regular JWT library. Three working implementations show that this goal has been achieved:https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations  


We are looking forward to your feedback!

-Daniel


___
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread Daniel Fett


All,

Kristina and I would like to bring to your attention a new draft that we 
have been working on with many others over the past weeks. "Selective 
Disclosure JWT (SD-JWT)" describes a format for signed JWTs that support 
selective disclosure (SD-JWT), enabling sharing only a subset of the 
claims included in the original signed JWT instead of releasing all the 
claims to every verifier.


https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to hear from 
the working group with the eventual goal of asking for working group 
adoption.


Issues are tracked in our GitHub repository: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues


The approach to selective disclosure described in the document is based 
on salted hashes. We have discussed and explored other approaches based 
on encryption as well. If you are interested in following this 
discussion, we would like to invite you to read this issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30


One main goal with this work is that the format should be easy to 
implement, requiring little more than a regular JWT library. Three 
working implementations show that this goal has been achieved: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 



We are looking forward to your feedback!

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

Re: [OAUTH-WG] Security BCP Review

2022-04-11 Thread Daniel Fett


Hi Rifaat,

Am 14.02.22 um 22:26 schrieb Rifaat Shekh-Yusef:


As part of the preparation for the shepherd write-up, I reviewed the 
document and have the following comments:


https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html 





General comment

The document refers to a number of drafts that are not active anymore, 
e.g., token binding, pop key distribution, signing http requests, etc.


What is the reason behind including these in this document?

The reason is to provide a general idea of other approaches that have 
been conceived and to discuss various approaches to specific problems. 
It may be helpful to the reader to see that sometimes, a certain 
solution has been discussed already, even when it was not pursued further.




Section 4.5.4

I am not clear on how the attacker can do that. Let’s take the 
code_challenge example. Wouldn’t the AS be able to detect this attack 
because it gets the *code verifier* associated with the *original code 
challenge* from the Client?


Yes, but this can be circumvented if the attacker can modify the 
authorization request from the client to the AS before it reaches the 
AS. In this case, the attacker can define the code_challenge in the 
request such that it works with the code_verifier that will be sent 
later on.



Nits

Section 2.1, 3rd paragraph, 3rd sentence: “MAY rely the” to “, MAY 
rely on the”


Section 2.3, second paragraph: replace ietf-oauth-resource-indicators 
with RFC8707


Section 4.1.3. Last paragraph: replace the jwsreq and PAR draft 
references with rfc9101 and rfc9126 respectively.



Who might want to sweep through the document and update the various 
references, as there seem to be too many old references



Thanks, we will fix this for the next revision and update the references.

-Daniel

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

Re: [OAUTH-WG] WGLC for DPoP Document

2022-03-30 Thread Daniel Fett


I also support publication.

-Daniel

Am 29.03.22 um 23:20 schrieb David Waite:

I also support publication of this specification

-DW

On Mar 29, 2022, at 3:12 PM, Mike Jones 
 wrote:


I support publication of the specification.
-- Mike
*From:*OAuth *On Behalf Of*Rifaat Shekh-Yusef
*Sent:*Monday, March 28, 2022 5:01 AM
*To:*oauth 
*Subject:*[OAUTH-WG] WGLC for DPoP Document
All,

As discussed during the IETF meeting in*Vienna*last week, this is 
a*WG Last Call*for the *DPoP*document:

https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, provide your feedback on the mailing list by April 11th.

Regards,
 Rifaat & Hannes
___
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


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

Re: [OAUTH-WG] WGLC for DPoP Document

2022-03-29 Thread Daniel Fett


+1

Am 29.03.22 um 15:10 schrieb Justin Richer:
And this is exactly the problem with the “collaborating clients” 
attack, as has been pointed out any number of times it’s been brought 
up before. If two clients are willingly collaborating in this way, 
they do not need to share any cryptographic material and impersonate 
each other.


You don’t need to steal my license if I’m willing to just go buy you beer.

The DPoP draft does address signed request re-use, which some see as a 
feature to be carefully applied.


 — Justin


On Mar 28, 2022, at 1:04 PM, Steinar Noem  wrote:

Interesting, but won't two collaborating clients just pass any data 
they want to each other? Why would these collaborating clients go 
through the trouble of exchanging private keys, dpop proofs or 
tokens? Could you elaborate some more on the scenario?


S

man. 28. mar. 2022 kl. 16:29 skrev Denis :

Rifaat & Hannes,

Hereafter are my comments:

The introduction states :

   Recipients of such tokens are then able to verify the
binding of the token to the key pair thatthe client has demonstrated
   that it holds via the DPoP header, thereby providing some
assurance that the client presenting the token also possesses the
private key.

   In other words, the legitimate presenter of the token is
constrained to be the sender that holds and can prove possession
of the private part of the key pair.

The client presenting the token *does not necessarily possess the
private key*. The client presenting the token has been able to use
the results of some cryptographic functions using the private
part of the key pair.

These results may be communicated by one client to another
client, if the two clients agree to collaborate. This statement
will be added later on.

Proposed rewording:

   Recipients of such tokens are then able to verify the
binding of the token to the key pair thatthe client has demonstrated
   that it holds via the DPoP header, thereby providing some
assurance that the client presenting the token *either *also
possesses
   the private key *or* has been able to use the result of
cryptographic computations from another client that possesses the
private key.

   In other words, the presenter of the token can prove that
it has been able to use the results of cryptographic computations
performed
   by using the private part of the key pair.

The objectives states

   The primary aim of DPoP is to prevent unauthorized or
illegitimate parties from using leaked or stolen access tokens,
   by binding a token to a public key upon issuance and
requiring that the client proves possession of the corresponding
   private key when using the token.

DPoP does not prevent unauthorized or illegitimate parties from
using access tokens, as soon as two clients agree to collaborate.

Proposed rewording:

   The primary aim of DPoP is to bind a token to a public key
upon issuance and requiring that the client proves possession
   of the corresponding private key when using the token.This
does not demonstrate that the client presenting the token is
   necessarily the legitimate client. In the case of
non-collaborating clients, DPoP prevents unauthorized or
illegitimate parties
   from using leaked or stolen access tokens. In the case of
collaborating clients, the security of DPoP is ineffective
   (see section 11.X).

Section 11 is about "Security Considerations" and addresses the
following topics:

11.1.DPoP Proof Replay
11.2.DPoP Proof Pre-Generation
11.3.DPoP Nonce Downgrade
11.4.Untrusted Code in the Client Context
11.5.Signed JWT Swapping
11.6.Signature Algorithms
11.7.Message Integrity
11.8.Access Token and Public Key Binding
11.9.Authorization Code and Public Key Binding

The case of collaborative clients should be addressed within
section 11.

Text proposal.

11.X. Collaborative clients

    DPoP demonstrates that the client presenting the
token has been able to use the results of some cryptographic
functions
using the private part of the key pair.

If a client agrees to collaborate with another client, the
security of DPoP is no longer effective.When two clients agree to
collaborate,
these results of the cryptographic computations performed by one
client may be communicated to another client.

Even if the private key used for DPoP is stored in such a way
that it cannot be exported, e.g., in a hardware or software
security module,
the client can perform all the cryptographic computations needed
by the other client to create DPoP proofs.

The client can easily create new DPoP proofs as long as the other
client is online.

Note: There exist other

[OAUTH-WG] OAuth Security BCP Github

2022-03-22 Thread Daniel Fett


Since this was asked at the meeting, the OAuth Security BCP lives here:

https://github.com/oauthstuff/draft-ietf-oauth-security-topics

-Daniel

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

Re: [OAUTH-WG] OAuth Security Workshop 2022 - Tickets now available

2022-03-11 Thread Daniel Fett


Hi everyone,

as a quick reminder, there's less than a week left to book early bird 
tickets. If you want to submit a session proposal, please do so until 
March 23.


Thanks,
Daniel

Am 11.02.22 um 22:27 schrieb Daniel Fett:


Hi everyone,

I'm pleased to announce that the website for the OAuth Security 
Workshop 2022 is now up: https://oauth.secworkshop.events/osw2022


The three-day event takes place in Trondheim, Norway, from May 4 to 
May 6, 2022.


This workshop will *not* be a hybrid event. We might provide 
recordings or a live stream, but to ask questions and partake in 
discussions, on-site participation is required.


Please visit the website for

 * tickets - a limited amount of early bird tickets is available until 
no later than March 17

 * the Call for Sessions
 * venue and schedule information
 * hotel deals
 * travel information
 * sponsoring opportunities

If you have any questions, feel free to contact me!

-Daniel


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


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

Re: [OAUTH-WG] proof of access token possession using client secret

2022-03-02 Thread Daniel Fett


What exactly is the attack that you're trying to prevent?

If the clients share the access tokens, they might as well share access 
to the resource server (forwarding requests and responses). You can't 
really prevent that.


DPoP or MTLS, potentially with non-exportable keys, might be a better 
approach, but it depends on the attack you have in mind.


-Daniel

Am 02.03.22 um 16:58 schrieb Nikos Fotiou:

Hi all,

I am working on a use case where the Authorization Server and the Resource Server are the same 
entity. I would like to prevent clients from sharing their access tokens. I am wondering if 
requiring clients to include the "client secret" in the resource access request (in 
addition to the access token) is a valid strategy. This way clients would have to share their 
"client secret" in addition to the access token. Would that work?

Best,
Nikos
--
Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr


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


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

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

2022-03-02 Thread Daniel Fett

e of it is OAuth specific. Most of 
it is "Add an authorization header" or "call this specific endpoint 
one time". A couple of lines in the documentation is sufficient for 
handling this. Which leaves "How to verify an OAuth token". Having 
built a library for tons of languages to handle not just OAuth but 
other things, the challenge here isn't the OAuth part. Sure there is 
some knowledge around how to convert the *issuer* to the JWK using the 
discovery document, but a library only marginally improves the state. 
And the amount of work for branded libraries to add this in is still 
trivial. The real problem with these is that the crypto communities in 
different languages don't make it easy to do this. If you think 
explaining OAuth is challenging, try to explain libsodium 
requirements, they don't care, and we can't fix that with a library. 
We can fix that by contributing to the available crypto tools so OAuth 
verification can be easier. Thankfully we don't have to, because the 
branded products will release their open source version implementing 
or fixing these because they are motivated to do so.


Machine clients might need to use MTLS, DPoP, or something similar. 
There is value in a library for machine clients as well. And since this 
use case is often more or less a subset of interactive clients, I would 
expect that most libraries will support both anyway.





Now I get to the OAuth user-agent/facing clients. Web apps complexity 
here is usually the framework, and dance around, what do I do with the 
state, and the redirect so the user ends up in the right place. A 
library isn't going to fix that, and even if it did, it isn't OAuth 
that is the issue here, it is a lack of good browser apis to support 
easy navigation.


Which leaves us with, are we talking about mobile apps or desktop 
clients? Because we are talking about one of these other categories, 
there isn't enough value in there to list them any more than there is 
value in listing OIDC providers that support OAuth. Being met with a 
list of hundreds of libraries and packages doesn't make for a good 
experience, and do those same developers know if they need PKCE, EdDSA 
signatures, a library that supports mTLS, probably not.


That's why I'm advocating for a profile that covers many use cases. If I 
can tell a developer to go and find a library that supports 
OAuth-Modern-Feature-Set®, and it would be common for libraries to 
advertise their support for that, the problem would be much smaller.


-Daniel




- Warren



Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a service. Implement 
Authress <https://authress.io/>.



On Wed, Mar 2, 2022 at 4:33 PM Sascha Preibisch 
 wrote:


Hello Daniel!

Some time ago I started an open source project: Loginbuddy.
Loginbuddy is a tool that mainly supports OpenID Connect based
logins.

It can be deployed as a standalone service or be used as a
side-car next to other docker containers in the same network.

Although it is not necessarily a library, it may be worth looking
into it. I could imagine that Loginbuddy would also be a good
starting point for extensions that serve more flows and more
general features of OAuth/ OpenID Connect. With more contributors
I see a chance for Loginbuddy to be more widely used and help
address your concerns.

Please have a look here:
https://loginbuddy.net

I just updated the web site. Or visit the GitHub project:
https://github.com/SaschaZeGerman/loginbuddy

In any case, that is my current contribution to the developer
community.

Thanks,
Sascha

On Tue, Mar 1, 2022 at 9:18 AM Daniel Fett  wrote:

**

*Hi all,*

*

While helping clients to onboard into the yes ecosystem, in my
consulting work, and in discussions with developers
implementing OAuth 2.0, one topic comes up increasingly often:
The (somewhat frustrating) lack of good, modern, and universal
OAuth libraries.


Many of the libraries out there have one or more of the
following drawbacks:


 * They are not maintained any longer

 * They are not well documented (e.g., it is often unclear
which specifications are supported)

 * They support only a subset of the OAuth 2.0 specification

 * They work only with selected providers (e.g., Google,
Facebook, etc.)

 * It is unclear whether they follow recent security
recommendations

 * They do not support modern features, such as PKCE, AS
Metadata, MTLS, etc.


Exceptions exist, of course, like Filip's Node.js
implementation and the nimbus library for Java. But apart from
those rare cases, when a developer asks me what library to
use, my answer is often: "I don't think there's a good one in
your l

[OAUTH-WG] OAuth: The frustrating lack of good libraries

2022-03-01 Thread Daniel Fett


**

*Hi all,*

*

While helping clients to onboard into the yes ecosystem, in my 
consulting work, and in discussions with developers implementing OAuth 
2.0, one topic comes up increasingly often: The (somewhat frustrating) 
lack of good, modern, and universal OAuth libraries.



Many of the libraries out there have one or more of the following drawbacks:


 * They are not maintained any longer

 * They are not well documented (e.g., it is often unclear which 
specifications are supported)


 * They support only a subset of the OAuth 2.0 specification

 * They work only with selected providers (e.g., Google, Facebook, etc.)

 * It is unclear whether they follow recent security recommendations

 * They do not support modern features, such as PKCE, AS Metadata, 
MTLS, etc.



Exceptions exist, of course, like Filip's Node.js implementation and the 
nimbus library for Java. But apart from those rare cases, when a 
developer asks me what library to use, my answer is often: "I don't 
think there's a good one in your language". It is a telltale sign that 
many providers of OAuth protected APIs also provide a custom OAuth 
implementation in their SDKs, which they then often have to maintain for 
a number of languages. This creates unnecessary costs and friction, 
e.g., when introducing new security features.



At the same time, practically every language/framework comes with a TLS 
stack and making HTTPS requests is often just a few lines of code. Why 
aren't we there yet with OAuth? I'm well aware that OAuth 2.0 is a 
framework, not a single protocol like TLS, but the mentioned libraries 
show that this does not preclude a comprehensive library support.



If I had to speculate about the reasons for this mess, I'd say that 
there are three:



 * The core of OAuth is easy to implement. The need to create or use a 
library might not be obvious to developers. Of course, if you want a 
proper implementation with correct error handling, observing all the 
security recommendations, etc., the effort is huge. But just getting 
OAuth to work for one specific use case is relatively easy.



 * OAuth is traditionally hard to configure: authorization and token 
endpoint URLs, client id and secret, supported scopes (and claims for 
OIDC), supported response types and modes, and required security 
features are just some of the things a developer has to figure out - 
often from the API's documentation - to get everything up and running. 
Even though configuration is not the same as implementation, I imagine 
that this complexity can lead to the perception that there are barely 
any commonalities between different OAuth flows. There might be no 
value, after all, in an OAuth library, if I have to provide so many 
details myself.



 * With many extensions and specifications to choose from, it can be 
hard to select a reasonable subset to support.



What can we do about this?


I'm not sure, but I have a few ideas.


 * Of course, one step would be to increase visibility and 
documentation for existing implementations: Beyond listing libraries 
(like the list on oauth.net), it would be great to have a place to go to 
to find libraries based on their feature support. I'm sure there are 
more good libraries out there.


 * The OpenID Foundation has a great set of conformance tests for OIDC, 
FAPI and other stuff. Creating conformance tests for OAuth would be 
harder, given that the framework leaves many options for implementers to 
choose from. I’m not sure if running a conformance programme would be in 
the scope of IETF, but it can be worthwhile to think about if we could 
support such an endeavor.


 * The single most important thing to do would, in my opinion, be to 
set a goal: Tell library developers and language maintainers what can be 
expected from a good, modern, and universal OAuth library. Such a 
recommendation would shine a light on the most important extensions for 
OAuth like PKCE and might even be a prerequisite for conformance tests. 
It may turn out to be OAuth 2.1 or something else. For me, this would in 
any case include AS Metadata, as that is the single most valuable 
building block we have to address configuration complexity.



I would be interested to hear what others think about this. Is this a 
problem worth addressing? Are there other solutions? Is this out of 
scope of our work here?



-Daniel
*

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-05.txt

2022-02-19 Thread Daniel Fett

This version brings a lot of changes to DPoP, but we're also hoping to 
get closer to a final version. As usual, your feedback is appreciated!


-Daniel


Changelog:

-05

 * Added Authorization Code binding via the dpop_jkt parameter.
 * Described the authorization code reuse attack and how dpop_jkt
   mitigates it.
 * Enhanced description of DPoP proof expiration checking.
 * Described nonce storage requirements and how nonce mismatches and
   missing nonces are self-correcting.
 * Specified the use of the use_dpop_nonce error for missing and
   mismatched nonce values.
 * Specified that authorization servers use 400 (Bad Request) errors to
   supply nonces and resource servers use 401 (Unauthorized) errors to
   do so.
 * Added a bit more about ath and pre-generated proofs to the security
   considerations.
 * Mentioned confirming the DPoP binding of the access token in the
   list in Section 4.3.
 * Added the always_uses_dpop client registration metadata parameter.
 * Updated references for drafts that are now RFCs.

Am 19.02.22 um 21:42 schrieb internet-dra...@ietf.org:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

 Title   : OAuth 2.0 Demonstrating Proof-of-Possession at the 
Application Layer (DPoP)
 Authors : Daniel Fett
   Brian Campbell
   John Bradley
   Torsten Lodderstedt
   Michael Jones
   David Waite
Filename: draft-ietf-oauth-dpop-05.txt
Pages   : 42
Date: 2022-02-19

Abstract:
This document describes a mechanism for sender-constraining OAuth 2.0
tokens via a proof-of-possession mechanism on the application level.
This mechanism allows for the detection of replay attacks with access
and refresh tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-05


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] DPoP proof and the public key

2022-02-17 Thread Daniel Fett


Hi George,

the main reason for this is to facilitate a client implementation that 
always sends the same kind of proof. For the client, there's no need to 
distinguish between token request, resource request, or even PAR 
request. Even though the key would only be needed once, of course.


-Daniel

Am 17.02.22 um 14:57 schrieb George Fletcher:

Hi,

I'm going to expose my ignorance here... but what is the rationale for 
requiring the public key in every DPoP proof? Is there a security 
reason? or is it for ease of development? If large RSA keys are being 
used, that public key is rather large for sending with every request 
when even a fingerprint of the key would suffice to identify it.


From my reading of the spec, there isn't a way for a server that wants 
to remember the public key in backend session state to optimize the proof.


Thanks,
George

___
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] OAuth Security Workshop 2022 - Tickets now available

2022-02-11 Thread Daniel Fett


Hi everyone,

I'm pleased to announce that the website for the OAuth Security Workshop 
2022 is now up: https://oauth.secworkshop.events/osw2022


The three-day event takes place in Trondheim, Norway, from May 4 to May 
6, 2022.


This workshop will *not* be a hybrid event. We might provide recordings 
or a live stream, but to ask questions and partake in discussions, 
on-site participation is required.


Please visit the website for

 * tickets - a limited amount of early bird tickets is available until 
no later than March 17

 * the Call for Sessions
 * venue and schedule information
 * hotel deals
 * travel information
 * sponsoring opportunities

If you have any questions, feel free to contact me!

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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

2022-01-05 Thread Daniel Fett

Hi Benjamin,

thanks for bringing this up!

What you describe is essentially a downgrade from PKCE to a non-PKCE flow.

Nov Matake pointed out this possibility in an earlier discussion:
https://mailarchive.ietf.org/arch/msg/oauth/qrLAf3nWRt8HAFkO49qGrPRuelo/

We therefore added this attack to the Security BCP:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#page-28

As countermeasures, the BCP lists

   Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure
   that if there was no code_challenge in the authorization request, a
   request to the token endpoint containing a code_verifier is rejected.

   Note: AS that mandate the use of PKCE in general or for particular
   clients implicitly implement this security measure.

-Daniel



Am 04.01.22 um 11:45 schrieb Benjamin Häublein:
>
> Hello everyone,
>
> I think RFC 7636 “Proof Key for Code Exchange by OAuth Public
> Clients”, section 4.6. “Server Verifies code_verifier before Returning
> the Tokens” leaves a tiny gap regarding the handling of verification
> when no code challenge was present in the authorization request:
>
>    Upon receipt of the request at the token endpoint, the server
>
>    verifies it by calculating the code challenge from the received
>
>    "code_verifier" and comparing it with the previously associated
>
>    "code_challenge", after first transforming it according to the
>
>    "code_challenge_method" method specified by the client.
>
> It is unspecified how the server should behave when “code_verifier” is
> present, but “code_challenge” and “code_challenge_method” were not set
> in the initial authorization request.
>
> The following example worked for three well-known authorization
> servers where the client was configured in a way that PKCE could be
> used, but was not enforced:
>
> Authorization Request:
>
> https:///auth?client_id=_type=code=openid+profile_uri=https://localhost
> <https:///auth?client_id=_type=code=openid+profile_uri=https://localhost>
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request.
>
>  
>
> Many applications consider the usage of PKCE as enough protection from
> Login-CSRF and do not use state or nonce (for example this blog entry
> by Daniel Fett
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
> <https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/>
> suggests, that neither state nor nonce are necessary when PKCE is
> used). However, when the authorization server is not configured to
> require a specific code_challenge_method from the client and the
> authorization behaves as described in the example, PKCE does not
> protect from Login-CSRF.
>
> I think the following mitigations are possible:
>
>   * Enforce usage of PKCE in the client configuration in the
> Authorization Server
>   * Implementation of the authorization server returns an error in the
> Access Token Response when code_verifier is present in the token
> request, but no code_challenge and code_challenge_method is
> present in the authorization request.
>   * Additionally, when the behavior of an AS is correct (verification
> of code_verifier fails when no code_challenge was present), a
> client that relies on PKCE for CSRF protection must always include
> a code_verifier parameter in the token request (even if no
> code_verifier is present on the client side).
>
>  
>
> Best regards,
>
>  
>
> Benjamin Häublein
> Senior Consultant
>
> cirosec GmbH
> Ferdinand-Braun-Strasse 4
> 74074 Heilbronn
> Germany
> Phone: +49 (7131) 59455-74
> Fax: +49 (7131) 59455-99
> Mobile: +49 (151) 122414-74
> www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
>  
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Francesca Palombini's Discuss on draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)

2021-12-02 Thread Daniel Fett

Hi Francesca, Warren, Brian,

we have modified the IANA Considerations section in the just uploaded
version -04 according to your feedback.

-Daniel

Am 30.11.21 um 19:42 schrieb Francesca Palombini:
>
> Hi Warren, Brian,
>
>  
>
> Thanks for your feedback, and for confirming that the semantics of the
> existing “iss” match those of the draft. In that case, I agree with
> you that the best resolution is to merge the two (so – update the
> existing registration so that it also points to this document, and
> indicates it can also appear in the authorization response).
>
>  
>
> I’ll remove my DISCUSS when the IANA update is done.
>
>  
>
> Thanks,
> Francesca
>
>  
>
> *From: *Brian Campbell 
> *Date: *Tuesday, 30 November 2021 at 19:32
> *To: *Francesca Palombini 
> *Cc: *The IESG , oauth@ietf.org ,
> draft-ietf-oauth-iss-auth-r...@ietf.org
> , oauth-cha...@ietf.org
> 
> *Subject: *Re: [OAUTH-WG] Francesca Palombini's Discuss on
> draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)
>
> I strongly believe the use of 'iss' as the parameter name here is
> correct and appropriate. This draft isn't using it for something
> different - the parameter carries an identifier for the sender of the
> message, which is consistent in the context of use with the existing
> registry entry. 
>
>  
>
> Codifying the parameter name is central to the value of this draft and
> there are existing implementations/deployments using it. Changing the
> name now would be a breaking change with significant ramifications on
> interoperability.
>
>  
>
> The organization of the registry is arguably less than ideal, yes. But
> that shouldn't force an unnecessary and costly change onto this simple
> draft that's addressing a real need. This draft should update the
> existing entry for 'iss' rather than replace it.
>
>  
>
> On Mon, Nov 29, 2021 at 2:21 PM Francesca Palombini via Datatracker
> mailto:nore...@ietf.org>> wrote:
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-oauth-iss-auth-resp-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
> 
> for more information about how to handle DISCUSS and COMMENT
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> 
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Julian Reschke for the ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/XfLbtK1eLb7s0Z6e_AqGgkoWny0/
> .
>
> I have one DISCUSS point that has to do with IANA considerations,
> and is
> hopefully easy to resolve.
>
> Francesca
>
> 1. -
>
> FP: I am sure the Designated Expert will bring this up, but "iss"
> is already
> defined as a OAuth Parameter, for authorization requests. I don't
> think it's a
> good idea to use the same parameter name, although in a different
> message of
> the exchange, for something different, as the registration defined
> in Section
> 5.2 seems to imply. I strongly recommend to change the name in
> this document.
> Or, if we can agree that the meaning is similar enough to the
> original "iss",
> merge the two IANA registrations (this would not be my preferred
> choice).
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
> */CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./*
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

2021-12-02 Thread Daniel Fett

Hi Murray,

thanks for your review and feedback.

We have just uploaded version -04 which includes a fix for the missing
quotation marks (which were not added by xml2rfc automatically for an
unknown reason).

-Daniel

Am 02.12.21 um 07:01 schrieb Murray Kucherawy via Datatracker:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-oauth-iss-auth-resp-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
>
>
>
> --
> COMMENT:
> --
>
> I support Francesca's DISCUSS.
>
> I also concur with Eric's observations about the shepherd writeup.  Those
> important details are missing.
>
> Please quote "iss" wherever you use it.  Every time I ran into it, my first
> thought was that it's a typo and I had to re-parse it a couple of times.
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

2021-12-01 Thread Daniel Fett

+1 to what Neil and Aaron said.

dpop_jkt effectively creates a client authentication mechanism with an
ad-hoc identifier for the client.

I'm wondering if dynamic registration plus an asymmetric client
authentication scheme doesn't already solve the problem.

-Daniel

Am 01.12.21 um 01:05 schrieb Aaron Parecki:
> I tend to agree with Neil here. I'm struggling to see the relevance of
> this attack. 
>
> It seems like the PDF writeup describes two possible reasons an
> attacker could get access to the authorization code and PKCE code
> verifier.
>
> 1. The attacker has access to the logs of the token endpoint.
> 2. The attacker can intercept HTTPS connections between the client and
> AS (VPN, corporate network proxy, etc)
>
> For 1, the solution is to stop logging the contents of the POST body,
> and secure your infrastructure. I don't think making the client jump
> through extra hoops is a good solution if you are already logging more
> than you should be or you don't trust the people who have access to
> the infrastructure. If this really is a concern, I suspect there are a
> lot more places in the flow that would need to be patched up if you
> don't trust your own token endpoint.
>
> For 2, if the attacker can intercept the HTTPS connection, then the
> proposed solution doesn't add anything because the attacker could
> modify the requests before it hits the authorization server anyway,
> and change which DPoP key the token gets bound to in the first place.
> Plus, the attacker would also have access to anything else the client
> is sending to the AS, such as the user's password when they
> authenticate at the AS.
>
> Are there other attack vectors I'm missing that might actually be
> solved by this mechanism?
>
> Aaron
>
>
> On Tue, Nov 30, 2021 at 12:40 PM Neil Madden
> mailto:neil.mad...@forgerock.com>> wrote:
>
> Sadly I couldn’t make the DPoP session, but I’m not convinced the
> attack described in the earlier message really needs to be
> prevented at all. The attack largely hinges on auth codes not
> being one-time use, which is not a good idea, or otherwise on poor
> network security on the token endpoint. I’m not convinced DPoP
> needs to protect against these things. Is there more to this?
>
> The proposed solutions also seem susceptible to the same problems
> they attempt to solve - if an attacker is somehow able to
> interrupt the client’s (TLS-protected) token request, why are they
> somehow not able to interrupt/modify the (far less protected)
> redirect to the authorization endpoint?
>
> — Neil
>
>> On 30 Nov 2021, at 20:15, Mike Jones
>> > > wrote:
>>
>> As described during the OAuth Security Workshop session on DPoP,
>> I created a pull request adding the dpop_jkt authorization
>> request parameter to use for binding the authorization code to
>> the client’s DPoP key. 
>> Seehttps://github.com/danielfett/draft-dpop/pull/89
>> .
>>  
>> This is an alternative
>> to https://github.com/danielfett/draft-dpop/pull/86
>> , which
>> achieved this binding using a new DPoP PKCE method.  Using this
>> alternative allows PKCE implementations to be unmodified, while
>> adding DPoP in new code, which may be an advantage in some
>> deployments.
>>  
>> Please review and comment.  Note that I plan to add more of the
>> attack description written by Pieter Kasselman to the security
>> considerations in a future commit.  This attack description was
>> sent by Pieter yesterday in a message with the subject
>> “Authorization Code Log File Attack (was DPoP Interim Meeting
>> Minutes)”.
>>  
>>    -- Mike
>>  
>> ___
>> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Invitation: OAuth Security Workshop 2021

2021-11-15 Thread Daniel Fett

Hi all,

this is just a reminder that the OAuth Security Workshop 2021 takes
place in a little more than two weeks. You can still register for the
event and propose sessions at https://barcamps.eu/osw2021
<https://barcamps.eu/osw2021>.

-Daniel

Am 23.08.21 um 10:46 schrieb Daniel Fett:
>
> Hi all,
>
> I would like to invite you to the OAuth Security Workshop 2021, a
> fully-virtual, two-day event on
>
>  *November 30 and December 1, 2021 (UTC).*
>
> The OAuth Security Workshop (OSW) aims to improve the security of
> OAuth, OpenID Connect, GNAP and related Internet protocols by
> facilitating direct exchange among academic researchers,
> standardization group members and industry experts.
>
> For this edition of the OSW, we use a simplified submission process:
> Session proposals will be collected online before the event. The
> schedule will be assembled by the organziation committee from these
> session proposals.
>
> Please submit a session proposal if
>
>  * you want to give a talk or tutorial,
>  * you are interested in convening a working session on a topic,
>  * or if you want to discuss a topic or question, whether you are an
> expert in that topic or not.
>
> Every participant can propose and conduct a session. We explicitly
> invite newcomers to submit a session proposal.
>
> OSW welcomes all topics that roughly fit into the areas OAuth, OpenID
> Connect, and GNAP, be it from a standardization, application, or
> research perspective.
>
> Thanks to our sponsor yes.com, the event will be free of charge. A
> prior registration is required.
>
> Please find more information at https://oauth.secworkshop.events.
>
> -Daniel
> m...@danielfett.de
>
>
> -- 
> https://danielfett.de
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

2021-10-18 Thread Daniel Fett

Am 16.10.21 um 01:41 schrieb Mike Jones:
>
> As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.
>
It only looks like an attack when the code has actually arrived at the
token endpoint on the first try (which the client cannot know, of course).

I think Annabelle's proposal of allowing reuse-on-error has its merits.
The AS can still reject the code when it has seen the same code already,
and the client can then fall back to starting a new authorization request.

-Daniel


>  
>
> Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that
> we can’t distinguish from attacks.
>
>  
>
> The prohibition on clients reusing an authorization code needs to remain.
>
>  
>
>   -- Mike
>
>  
>
> *From:* Vittorio Bertocci 
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle 
> *Cc:* Mike Jones ; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
> OAuth 2.1
>
>  
>
> I am a fan of this approach. It feels pretty empty to cast people out
> of compliance just because they are handling a realistic circumstance,
> such as network failures, that we know about beforehand. 
>
> In addition, this gives us a chance to provide guidance on how to
> handle the situation, instead of leaving AS implementers to their own
> device.
>
>  
>
> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle
>  > wrote:
>
>     The client MUST NOT use the authorization code more than once.
>
>  
>
> This language makes it impossible to build a fault tolerant, spec
> compliant client, as it prohibits retries. We could discuss
> whether a retry really constitutes a separate "use", but
> ultimately it doesn't matter; multiple presentations of the same
> code look the same to the AS, whether they are the result of
> retries, the client attempting to get multiple sets of tokens, or
> an unauthorized party trying to replay the code.
>
>  
>
> I think we can have a fault tolerant, replay-proof implementation,
> but it takes some effort:
>
>  
>
>  1. The AS can prevent the authorized client from using one code
> to get a bunch of independent refresh and access token pairs
> by either re-issuing the same token (effectively making the
> token request idempotent) or invalidating previously issued
> tokens for that code. (Almost but not quite
> idempotent…idempotent-adjacent?)
>  2. The AS can prevent unauthorized parties from replaying snooped
> codes+PKCE by requiring stronger client authentication:
> implement dynamic client registration and require a
> replay-resistant client authentication method like
> `jwt-bearer`. The AS can enforce one-time use of the client
> credential token without breaking fault tolerance, as the
> client can easily mint a new one for each retry to the token
> endpoint.
>
>  
>
> Yes, I know, this is way more complex than just a credential-less
> public client doing PKCE. Perhaps we can have our cake and eat it
> too with language like:
>
>  
>
> The client MUST NOT use the authorization code more than once,
> unless retrying a token request that failed for reasons beyond
> the scope of this protocol. (e.g., network interruption,
> server outage) Refer to [Fault Tolerant Replay Prevention] for
> guidance.
>
>  
>
> …where Fault Tolerant Replay Prevention is a subsection under
> Security Considerations. I don't think this wording is quite
> right, as the guidance is really going to be for the AS, not the
> client, but hopefully it's enough to get the idea across.
>
>  
>
> —
>
> Annabelle Backman (she/her)
>
> richa...@amazon.com 
>
>  
>
>  
>

-- 
https://danielfett.de

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

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

2021-10-15 Thread Daniel Fett

I don't think that a MAY is appropriate here.

I wasn't in the call yesterday, so I hope I don't miss anything here, but...

Even with PKCE, the one-time use requirement of the code is still
important. First and foremost, if we allow unlimited re-use of the same
code, even just as an option, we change the semantics of this artifact.
I guess there are many examples where this causes issues, but one would
be DPoP. It assumes that there is only one (successful) token request
and in that request, the token is bound to a specific key. If there can
be more than one successful token request, all it takes is
code_challenge and the code sitting around somewhere in accessible
memory and an XSS attacker can exfiltrate them and use them on his own
device, binding the resulting token to an attacker-controlled key. This
is the attack outcome against which we introduced the nonce in DPoP.
(Probably we should add this thought as a security consideration to
DPoP, but that is a different topic.) I guess we can come up with many
other mechanisms and mitigations that depend on code being one-time use.

The attack described also shows nicely that code replay protection and
PKCE serve similar purposes, but are not the same thing.

The Security BCP introduces a second layer of defense at pretty much all
the critical places in the protocol, because practice shows that a
single defense can break too easily. For example, an attacker with
read-only access to the token request would be pretty bad without code
replay protections in place. Such attackers are considered in FAPI.
(Somebody capable of reading system logs at the client or server, proxy
logs at the client or server, browser logs, etc.)

Therefore, in my opinion, the code MUST be short-lived and at least
SHOULD, better MUST be one-time use.

And ideally, the code SHOULD also be invalidated if the PKCE verifier
does not match, not sure if that is in the current text or not.

-Daniel

Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place
> for implementors as they weigh the risks. Reducing it to MAY risks
> diluting it too much.
>
>  
>
> *From:*OAuth  *On Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman 
> *Cc:* IETF oauth WG 
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>  
>
> I wouldn't be against lowering it to MAY but only if we stipulate a
> SHOULD on an expected lifetime of an authorization code. I think
> sending the message that these should be one time use except in
> exceptional circumstances.
>
>
>   
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service.
> Implement Authress
> .
>
>  
>
>  
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman
>  > wrote:
>
> Any weakening of the requirement should include a clear outline of
> the risks to help implementors make informed decisions.
>
>  
>
> *From:*OAuth  > *On Behalf Of *Ash Narayanan
> *Sent:* Friday 15 October 2021 01:51
> *To:* Aaron Parecki mailto:aa...@parecki.com>>
> *Cc:* IETF oauth WG mailto:oauth@ietf.org>>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse
> and OAuth 2.1
>
>  
>
>
>   
>
> You don't often get email from ashvinnaraya...@gmail.com
> . Learn why this is important
> 
>
>   
>
> Yes, as I said before, authorization servers are free to
> enforce one-time use of the authorization code even if there
> isn't a requirement to. The proposal is just to remove the
> *requirement* of authorization servers enforcing it.
>
>  
>
> I agree, and therefore I think what it really ought to be is "MAY".
>
>  
>
> Annabelle said:
>
> There are legitimate use cases for a client to replay an
> authorization code. Connection failures happen. Servers fall
> over before completing requests. Users hit browser refresh
> buttons. Permitting replay of authorization codes (assuming
> valid PKCE, client creds, etc.) allows clients to handle these
> failure modes simply and gracefully via retries.
>
>  
>
> Couldn't agree more. Having experienced these exact use-cases, I
> can honestly say that denying users a smooth experience just to be
> compliant with the spec, which offers no additional security if
> PKCE is also

Re: [OAUTH-WG] Shepherd writeup for draft-ietf-oauth-iss-auth-resp

2021-10-08 Thread Daniel Fett

Hi Rifaat,

looks good to me!

-Daniel

Am 08.10.21 um 15:13 schrieb Rifaat Shekh-Yusef:
> All,
>
> The following is the first version of the shepherd writeup for
> the draft-ietf-oauth-iss-auth-resp document.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/shepherdwriteup/
> 
>
> Please, take a look and let me know if I missed anything.
> I plan to ship it to the IESG next week.
>
> Regards,
>  Rifaat
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] self-issued access tokens

2021-09-29 Thread Daniel Fett

That very much sounds like a static string as the access token plus DPoP.

-Daniel

Am 29.09.21 um 03:54 schrieb toshio9@toshiba.co.jp:
> Hi OAuth folks,
>
> I have a question. Is there (or was there) any standardizing effort for
> "self-issued access tokens"?
>
> Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 
> 2014
> [*1]. It's an Access Token issued by the Client and sent to the Resource 
> Server.
> The token is basically a signed document (e.g. JWT) by the private key of the
> Client. The Resource Server verifies the token with the public key, which is
> provisioned in the RS in advance.
>
> I think self-issued access tokens are handy replacement for Client Credentials
> Grant flow in simple deployments, where it's not so necessary to separate AS 
> and
> RS. In fact, Google supports this type of authentication for some services
> [*2][*3]. I'm wondering if there are any other services supporting self-signed
> access tokens.
>
> Any comments are welcome.
>
> [*1]: 
> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
> [*2]: 
> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
> [*3]: https://google.aip.dev/auth/4111
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification

2021-09-11 Thread Daniel Fett

Hi Rifaat,

not sure why, but I totally missed that first email. Thanks for the
reminder!

I am not aware of any IPR related to the OAuth 2.0 Authorization Server
Issuer Identification draft.

-Daniel

Am 08.09.21 um 18:44 schrieb Rifaat Shekh-Yusef:
> Karsten, Daniel,
>
> Any update on this?
>
> Regards,
>  Rifaat
>
>
> On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef
> mailto:rifaat.s.i...@gmail.com>> wrote:
>
> Authors,
>
> As part of the shepherd write-up, all authors of the document must
> confirm that any and all appropriate IPR disclosures required for
> full conformance with the provisions of BCP 78 and BCP 79 have
> already been filed.
>
> Please, reply to this email on the mailing list and indicate if
> you are aware of any IPRs associated with this document.
>
> Regards,
>  Rifaat
>

-- 
https://danielfett.de

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

[OAUTH-WG] Invitation: OAuth Security Workshop 2021

2021-08-23 Thread Daniel Fett

Hi all,

I would like to invite you to the OAuth Security Workshop 2021, a
fully-virtual, two-day event on

 *November 30 and December 1, 2021 (UTC).*

The OAuth Security Workshop (OSW) aims to improve the security of OAuth,
OpenID Connect, GNAP and related Internet protocols by facilitating
direct exchange among academic researchers, standardization group
members and industry experts.

For this edition of the OSW, we use a simplified submission process:
Session proposals will be collected online before the event. The
schedule will be assembled by the organziation committee from these
session proposals.

Please submit a session proposal if

 * you want to give a talk or tutorial,
 * you are interested in convening a working session on a topic,
 * or if you want to discuss a topic or question, whether you are an
expert in that topic or not.

Every participant can propose and conduct a session. We explicitly
invite newcomers to submit a session proposal.

OSW welcomes all topics that roughly fit into the areas OAuth, OpenID
Connect, and GNAP, be it from a standardization, application, or
research perspective.

Thanks to our sponsor yes.com, the event will be free of charge. A prior
registration is required.

Please find more information at https://oauth.secworkshop.events.

-Daniel
m...@danielfett.de


-- 
https://danielfett.de

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

[OAUTH-WG] High-quality OAuth client libraries

2021-08-04 Thread Daniel Fett

Hi all,

I'd like to draw your attention to a discussion that came up in the
OpenID Foundation's FAPI working group.

As you know, FAPI mostly builds upon standardized OAuth and OIDC
features. Nonetheless, it is hard to find client libraries that can be
used "out of the box" with a FAPI. Many client libraries only support a
very limited subset of features, lacking support even, for example, for
PKCE. And for many common languages or frameworks, only one or two
maintained libraries exist at all.

This means that many client implementers still have to roll their own
code for OAuth and OIDC integrations, with the well-known consequences
for security and interoperability.

As Dave pointed out on today's FAPI call, high-quality libraries would
likely be a huge boost for security in the OAuth/OIDC space.

I'd like to invite you to join the discussion over at the FAPI working
group:
https://bitbucket.org/openid/fapi/issues/433/track-fapi-compliant-rp-libraries

-Daniel

-- 
https://danielfett.de

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

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

2021-05-10 Thread Daniel Fett

Hi Neil,

I'm not sure - maybe others can chime in here as well - if a discussion
relating to an expired previous draft is something one would expect in
the spec.

For the record, the client_id does not provide any additional security.
The key to mitigating Mix-Up is that the "honest AS" ensures that the
code issued at its token endpoint is sent to the honest IdP's token
endpoint, and not to the attacker IdP's token endpoint. This is ensured
by the iss parameter. The client_id would maybe be relevant if the
honest AS sends different issuer values for different client_ids - I
have not heard of such a constellation. I'm not sure why the client_id
was included in the previous draft.

-Daniel


Am 10.05.21 um 14:57 schrieb Neil Madden:
> I have also read it and it looks good to me. It might be worth
> explicitly discussing how it relates to the older draft [1] (that we
> implemented at the time). That older draft also included a client_id
> parameter in the response, so it would be good to clarify if that is
> actually needed to prevent the attack or not.
>
> [1]: 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mix-up-mitigation-01
>  
>
> Kind regards,
>
> Neil
>
>> On 15 Apr 2021, at 08:04, Karsten Meyer zu Selhausen
>> > > wrote:
>>
>> Hi all,
>>
>> the latest version of the security BCP references
>> draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks.
>>
>> There have not been any concerns with the first WG draft version so
>> far: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
>>
>> I would like to ask the WG if there are any comments on or concerns
>> with the current draft version.
>>
>> Otherwise I hope we can move forward with the next steps and
>> hopefully finish the draft before/with the security BCP.
>>
>> Best regards,
>> Karsten
>>
>> -- 
>> Karsten Meyer zu Selhausen
>> Senior IT Security Consultant
>> Phone:   +49 (0)234 / 54456499
>> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, 
>> Security Training
>>
>> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of 
>> mix-up attacks? Learn how to protect your client in our latest blog post on 
>> single sign-on:
>> https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>>
>> Hackmanit GmbH
>> Universitätsstraße 60 (Exzenterhaus)
>> 44789 Bochum
>>
>> Registergericht: Amtsgericht Bochum, HRB 14896
>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
>> Christian Mainka, Dr. Marcus Niemietz
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ForgeRock values your Privacy 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-18.txt

2021-04-13 Thread Daniel Fett

Hi all,

This version includes some minor editorial fixes and a new wording for
disallowing insecure redirect URIs, as discussed on yesterday's call.

I would kindly ask the chairs to start a WGLC on this version.

Given the nature of a Best Current Practice document and the relatively
broad topic, there will always be more things to add to this document.
In order to deliver this document, it would be great if we could come to
the consensus that after this WGLC any attacks, mitigations, and
security topics not covered in draft-ietf-oauth-security-topics-18 go
into a future update of the BCP. Exceptions would be grave oversights in
proposed mitigations, factual errors, and anything coming up in the IETF
process after WGLC, of course.

Cheers,
Daniel

Am 13.04.21 um 16:34 schrieb internet-dra...@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : OAuth 2.0 Security Best Current Practice
> Authors : Torsten Lodderstedt
>   John Bradley
>   Andrey Labunets
>   Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-18.txt
>   Pages   : 53
>   Date: 2021-04-13
>
> Abstract:
>This document describes best current security practice for OAuth 2.0.
>It updates and extends the OAuth 2.0 Security Threat Model to
>incorporate practical experiences gathered since OAuth 2.0 was
>published and covers new threats relevant due to the broader
>application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-18.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-18
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

2021-04-12 Thread Daniel Fett

Am 12.04.21 um 16:56 schrieb Denis:
> Hi  Daniel,
>
>> (...)

 As I'm sure you have noticed, we have updated Section 3 following
 your last input. It now explicitly says:

     Attackers can collaborate to reach a common goal.

 It also says

    Note that in this attacker model, an attacker (see A1) can be a
 RO or
    act as one.  For example, an attacker can use his own browser to
    replay tokens or authorization codes obtained by any of the attacks
    described above at the client or RS.

 Your scenario is therefore covered. It was already before, but that
 was obviously too implicit, so we made it more clear with the
 recent update.

>>> [Denis] I don't believe that the scenario is covered with the above
>>> sentences.
>>>
>> I don't understand. This is not about believing, it is written very
>> clearly and conclusively in the text of the current draft.
>>
>> We've had this discussion before, and, although irrelevant for the
>> meaning of the BCP itself, I would like to refer you again to the
>> formal model in our research paper, which the BCP attacker model is
>> based on. It has a *very* precise definition of the attacker model
>> that does not leave room for interpretation. The natural-language
>> description in the BCP, as usual, is more fuzzy than the formal
>> definition, but both attacker models include clients cooperating.
>>
> [Denis]. Your very last sentence is finally using two magic words that
> are not present anywhere in the BCP: "*clients cooperating*".
> However, *clients collusion* or *clients collaboration* would be more
> accurate.
>


   *  (A1) Web Attackers that can set up and operate an arbitrary number
  of network endpoints including browsers and servers (except for
  the concrete RO, AS, and RS).  Web attackers may set up web sites
  that are visited by the RO, operate their own user agents, and
  participate in the protocol.

  Web attackers may, in particular, operate OAuth clients that are
  registered at AS, and operate their own authorization and resource
  servers that can be used (in parallel) by the RO and other
  resource owners.

(...)

  Attackers can collaborate to reach a common goal.




>>
> Finally, section 4 (Attacks and Mitigations) should include an
> additional subsection, e.g. section 4.16, addressing the case of a
> collaboration attack
> between clients against a RS.
>
 If I remember correctly, you first presented this attack at the
 OAuth Security Workshop in 2017.
 Since then, it has been brought up countless times on this mailing
 list, both with regards to the Security BCP as well as for the JWT
 Token draft.

 There has been practically no positive resonance at the meeting
 2017 or here on the mailing list as to including this in either of
 the drafts.

 A number of reasons come to mind, but first and foremost, I think
 that what you describe is not perceived as an attack, or, worded
 differently,
 it is obvious that what you describe in the "attack" is possible.

>>> [Denis] Here after comes the important sentence which is wrong:
>>>
>>>
 *There is no expectation that OAuth would defend against this kind
 of thin**g*,
 just as there is no mitigation against password sharing in
 password-based authentication.

>>> [Denis] In the section 4.16.2 there is a clear proposal that
>>> explains how *"OAuth can successfully defend against this kind of
>>> thin**g"*. *So* *there **IS **a solution*.
>>>
>> I did not say that there is no solution.
>
> [Denis] Well, ... ask anybody else how he would interpret your statement.
>
Feel free.
>
>>> Currently, when reading the text, an implementer might consider to
>>> deliver an access token that contains a claim such as "older the 18"
>>> without any "sub" or equivalent claim.
>>> Such an access token would be transferable to anyone and the RS
>>> would not be able to identify the attack.
>>>
>> Your proposed solution does not enable an RS to identify the attack
>> unless used together with some form of authentication way outside the
>> scope of OAuth.
>>
> [Denis] I never said that there is "some form of authentication". The
> word "authentication" is not present in my text proposal.
>
> At the moment (/and this is a topic of its own that could be discussed
> later on/), a "sub" claim present in an access token is unrelated to
> any identifier
> used during an authentication exchange between an end-user and a RS.
>
It is very much possible that I did not understand your proposed
solution correctly. Part of the problem is that a concise and concret
attack description is missing (where end-user and clients are not
conflated). If you could provide such a description, in the style of the
mix-up attack description (i.e., using concrete protocol participants
and protocol messages), that would greatly benefit

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

2021-04-12 Thread Daniel Fett

Hi Denis,

Am 12.04.21 um 14:57 schrieb Denis:
>>
>>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker
>>> Model) clearly states:
>>>
>>>     " In the following, this attacker model is updated (...) to
>>> include new types of attackers and to define the attacker model more
>>> clearly".
>>>
>>> Section 3 should include the case of a collusion or a collaboration
>>> attack between clients against a RS, where one of them is a
>>> legitimate client
>>> voluntarily "helping" another client to use or to request access
>>> tokens that would normally "belong" to the legitimate client.
>>>
>>
>> As I'm sure you have noticed, we have updated Section 3 following
>> your last input. It now explicitly says:
>>
>>     Attackers can collaborate to reach a common goal.
>>
>> It also says
>>
>>    Note that in this attacker model, an attacker (see A1) can be a RO or
>>    act as one.  For example, an attacker can use his own browser to
>>    replay tokens or authorization codes obtained by any of the attacks
>>    described above at the client or RS.
>>
>> Your scenario is therefore covered. It was already before, but that
>> was obviously too implicit, so we made it more clear with the recent
>> update.
>>
> [Denis] I don't believe that the scenario is covered with the above
> sentences.
>
I don't understand. This is not about believing, it is written very
clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the
meaning of the BCP itself, I would like to refer you again to the formal
model in our research paper, which the BCP attacker model is based on.
It has a *very* precise definition of the attacker model that does not
leave room for interpretation. The natural-language description in the
BCP, as usual, is more fuzzy than the formal definition, but both
attacker models include clients cooperating.


>
>>> Finally, section 4 (Attacks and Mitigations) should include an
>>> additional subsection, e.g. section 4.16, addressing the case of a
>>> collaboration attack
>>> between clients against a RS.
>>>
>> If I remember correctly, you first presented this attack at the OAuth
>> Security Workshop in 2017.
>> Since then, it has been brought up countless times on this mailing
>> list, both with regards to the Security BCP as well as for the JWT
>> Token draft.
>>
>> There has been practically no positive resonance at the meeting 2017
>> or here on the mailing list as to including this in either of the
>> drafts.
>>
>> A number of reasons come to mind, but first and foremost, I think
>> that what you describe is not perceived as an attack, or, worded
>> differently,
>> it is obvious that what you describe in the "attack" is possible.
>>
> [Denis] Here after comes the important sentence which is wrong:
>
>
>> *There is no expectation that OAuth would defend against this kind of
>> thin**g*,
>> just as there is no mitigation against password sharing in
>> password-based authentication.
>>
> [Denis] In the section 4.16.2 there is a clear proposal that explains
> how *"OAuth can successfully defend against this kind of thin**g"*.
> *So* *there **IS **a solution*.
>
I did not say that there is no solution.
>
> Currently, when reading the text, an implementer might consider to
> deliver an access token that contains a claim such as "older the 18"
> without any "sub" or equivalent claim.
> Such an access token would be transferable to anyone and the RS would
> not be able to identify the attack.
>
Your proposed solution does not enable an RS to identify the attack
unless used together with some form of authentication way outside the
scope of OAuth.

Again, this also goes deeply into OIDC territory.

> I therefore propose to proceed with the Security BCP *with the
> inclusion of this attack*.
>
>> Even though the Security BCP attacker model includes the general
>> setting required for the attack, the attack does not violate an
>> expected security property.
>>
>> I therefore propose to proceed with the Security BCP without
>> including this attack.
>>
>> -Daniel
>>
> [Denis] Since you have deleted the remaining of my email, I copy it
> again. If you respond to this email, please DO NOT delete it.
>
I deleted the remainder of the mail as it was not relevant to my answer
(see RFC1855, Section 3.1.1). Everybody can access your original mail on
the mailing list.

-Daniel

-- 
https://danielfett.de

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

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

2021-04-12 Thread Daniel Fett

Denis,

I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
> The case where two clients collude to mount an attack against a RS is
> not addressed. It now needs to be addressed.
>
>
> This should be added in section 1 ( Introduction)
>
No.


> The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model)
> clearly states:
>
>     " In the following, this attacker model is updated (...) to
> include new types of attackers and to define the attacker model more
> clearly".
>
> Section 3 should include the case of a collusion or a collaboration
> attack between clients against a RS, where one of them is a legitimate
> client
> voluntarily "helping" another client to use or to request access
> tokens that would normally "belong" to the legitimate client.
>

As I'm sure you have noticed, we have updated Section 3 following your
last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was
obviously too implicit, so we made it more clear with the recent update.

>
> Finally, section 4 (Attacks and Mitigations) should include an
> additional subsection, e.g. section 4.16, addressing the case of a
> collaboration attack
> between clients against a RS.
>
If I remember correctly, you first presented this attack at the OAuth
Security Workshop in 2017. Since then, it has been brought up countless
times on this mailing list, both with regards to the Security BCP as
well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or
here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that
what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible. There
is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in
password-based authentication. Even though the Security BCP attacker
model includes the general setting required for the attack, the attack
does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including
this attack.

-Daniel


-- 
https://danielfett.de

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

2021-04-08 Thread Daniel Fett

Hi George,

client impersonation is covered extensively in RFC6749 already, with
further recommendations in RFC6819. The basics of this attack have not
changed since public clients where introduced, but, as you mention, on
mobile operating systems we see new mechanics for authenticating clients
(or the lack thereof).

I worked together with Joseph Heenan and Fabian Hauck to develop new
best practices in this area [1]. I feel that the complexity of this
whole topic would be much better dealt with in an update to BCP 212 (RFC
8252).

Since the basics have been covered elsewhere, I do not see an immediate
need to update the security BCP and quite frankly, I fear that this
would set us back at least another year or so.

-Daniel


[1] https://danielfett.de/2020/11/27/improving-app2app/



Am 07.04.21 um 22:06 schrieb George Fletcher:
> While this is mostly covered in section 8.6 of RFC 8252 for native
> apps, I wonder if we shouldn't mention "Client Impersonation" in this
> doc as well in that any public client can be easily impersonated.
> Mobile OS's are providing additional mechanisms for "authenticating"
> the client but it's unclear whether those will be made available in
> desktop environments where native apps also exist. At this stage
> Universal Links (iOS) and App Links (Android) should be best practice
> for any mobile native app. Best practice for desktop apps is less clear.
>
> Impersonating a public client is very easy especially if the only
> mechanism available for the callback is a custom scheme URL.
>
> Thoughts?
>
> On 4/6/21 9:15 AM, Daniel Fett wrote:
>> Hi all,
>>
>> this version most importantly updates the recommendations for Mix-Up
>> mitigation, building upon
>> https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The
>> description of Mix-Up attacks has also been improved.
>>
>> Smaller changes:
>>
>>    * Make the use of metadata RECOMMENDED for both servers and clients
>>    * Make announcing PKCE support in metadata the RECOMMENDED way
>> (before: either metadata or deployment-specific way)
>>    * AS also MUST NOT expose open redirectors.
>>    * Mention that attackers can collaborate.
>>    * Make HTTPS mandatory for most redirect URIs.
>>
>> I'll present more details in the interim meeting next monday.
>>
>> As always, your feedback is appreciated. We hope that we can proceed
>> to a WGLC for this document soon.
>>
>> -Daniel
>>
>> Am 06.04.21 um 15:06 schrieb internet-dra...@ietf.org:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>
>>> Title   : OAuth 2.0 Security Best Current Practice
>>> Authors : Torsten Lodderstedt
>>>   John Bradley
>>>   Andrey Labunets
>>>   Daniel Fett
>>> Filename: draft-ietf-oauth-security-topics-17.txt
>>> Pages   : 52
>>> Date: 2021-04-06
>>>
>>> Abstract:
>>>This document describes best current security practice for OAuth 2.0.
>>>It updates and extends the OAuth 2.0 Security Threat Model to
>>>incorporate practical experiences gathered since OAuth 2.0 was
>>>published and covers new threats relevant due to the broader
>>>application of OAuth 2.0.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> -- 
>> https://danielfett.de
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
https://danielfett.de

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

2021-04-06 Thread Daniel Fett

Hi all,

this version most importantly updates the recommendations for Mix-Up
mitigation, building upon
https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The
description of Mix-Up attacks has also been improved.

Smaller changes:

   * Make the use of metadata RECOMMENDED for both servers and clients
   * Make announcing PKCE support in metadata the RECOMMENDED way
(before: either metadata or deployment-specific way)
   * AS also MUST NOT expose open redirectors.
   * Mention that attackers can collaborate.
   * Make HTTPS mandatory for most redirect URIs.

I'll present more details in the interim meeting next monday.

As always, your feedback is appreciated. We hope that we can proceed to
a WGLC for this document soon.

-Daniel

Am 06.04.21 um 15:06 schrieb internet-dra...@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : OAuth 2.0 Security Best Current Practice
> Authors : Torsten Lodderstedt
>   John Bradley
>   Andrey Labunets
>   Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-17.txt
>   Pages   : 52
>   Date: 2021-04-06
>
> Abstract:
>This document describes best current security practice for OAuth 2.0.
>It updates and extends the OAuth 2.0 Security Threat Model to
>incorporate practical experiences gathered since OAuth 2.0 was
>published and covers new threats relevant due to the broader
>application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

2021-03-25 Thread Daniel Fett

Hi Hannes,

as mentioned by Brian, the yes Signing Flow is based on PAR and
therefore implemented by our banks (> 1000).

A python client for the yes signing flow is publicly available that uses
PAR: https://github.com/yescom/pyyes

-Daniel


Am 24.03.21 um 20:53 schrieb Hannes Tschofenig:
>
> Hi all,
>
>  
>
> I am working on the shepherd writeup and I need information about the
> implementation status of this specification.
>
>  
>
> Can you share whether you are implementing, or planning to implement
> this specification? If there is open source, please drop a link to the
> mailing list. If you implement it in your product, please let us know
> as well.  
>
>  
>
> This information helps the steering committee to judge the quality and
> maturity of the work.
>
>  
>
> Ciao
>
> Hannes
>
>  
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

2020-12-08 Thread Daniel Fett

Hi Warren,

Am 08.12.20 um 20:15 schrieb Warren Parad:
> As an implementer on both sides of the issue I'm struggling to
> understand how this problem would occur. I'm finding issues with the
> proposed problems:
>
>  1. Honest AS is compromised, assuming this does happen details on why
> adding iss to the AS response would prevent attacks is necessary
> for me. In other words, how would an AS be compromised in a way
> that would be identifiable through the issuer value? (my ignorant
> assumption is that a compromised AS is compromised enough that an
> attacker would be able to send the correct ISS)
>
If an AS is compromised, we can't do much for it anyway. We must assume
that all credentials from this AS can be stolen or forged and that
resource servers relying on this AS have a big problem, too. The Mix-Up
Attack is about attacking *other* (uncompromised) AS using the client's
trust in the compromised AS.

For clarification, in our slides we refer to

- an uncompromised AS as H-AS (honest AS) - this is the AS which issues
the credentials the attacker wants to read, and
- a compromised AS as A-AS - this may have been uncompromised previously
or may have been introduced into the ecosystem for the sole purpose of
running the mix-up attack.

In the mix-up attack, the client assumes that it is talking to A-AS but
actually received the authorization response from H-AS. This is why the
iss parameter helps: It always comes from H-AS (together with the
authorization code) and therefore cannot be modified by the attacker.
(If the attacker would be able to intercept/tamper with this
communiction, there would be no need to run a mix-up attack in the first
place.)

>  1. Attacker AS is registered. I fully support the idea that this can
> and will happen, however from attempting to test-implement this
> proposal, I can't see how the authorization would be sent to the
> wrong token endpoint. Since there is no information in the AS auth
> code response, the client must already have the knowledge of where
> they are going to send the token, no mix-up can be executed.
>
The assumption in the mix-up attack is that the client stores where to
send the authorization code, for example in a session bound to the
resource owner's browser. This would always be the token endpoint of the
attacker (A-AS) in the mix-up attack, either because the user selected
A-AS as the AS or because the attacker had an opportunity to modify the
user's choice.
>
>  1. I would argue, if anything, adding the ISS parameter would open a
> new attack surface by providing clients an opportunity to
> blatantly trust the ISS parameter as the honest AS and thus
> actually sending the code there instead of sending it to one
> specified in the metadata document.
>
As far as I can see, the potential attacks from such a bug on the
client's side would not be worse than mix-up, at least. It would
undermine session integrity probably, in that an attacker-AS would be
able to steer the client to send the code to H-AS. I'll take a closer
look at this.
> My confusion is the following:
>
>   * Are multi AS services utilizing authorization codes in a way where
> there could be a mix up attack for #2.
>   * Is there a #3 that I'm missing which even in light of #1 & #2 I
> brought up that would still make this change valuable?
>
I'm not sure if I could help to clear up the confusion a bit. I'd
recommend that you take a look at Section 3.3.2. of this document [1]
which provides a more detailed description of the mix-up attack and why
the defense mechanism works.

-Daniel

[1]
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf




>   
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
> On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt  > wrote:
>
> +1
> ᐧ
>
> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
> mailto:rifaat.s.i...@gmail.com>> wrote:
>
> All,
>
> This is a call for adoption for the following AS Issuer
> Identifier in Authorization Response as a WG document:
> 
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>
> Please, provide your feedback on the mailing list by Dec 22nd.
>
> Regards,
>  Rifaat & Hannes
> ___
> 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 mailing list
> OAuth@ietf.org
>

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

2020-12-08 Thread Daniel Fett

Obviously, +1.

Am 08.12.20 um 13:50 schrieb Rifaat Shekh-Yusef:
> All,
>
> This is a call for adoption for the following AS Issuer Identifier in
> Authorization Response as a WG document:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>
> Please, provide your feedback on the mailing list by Dec 22nd.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

2020-12-01 Thread Daniel Fett

So what you are proposing is that the time window in which an RS accepts
the DPoP proof is defined by the expiration time of the access token?

DPoP proofs are intended to be generally be short-lived and fresh for
each request in order to provide some level of replay protection. There
is no point in making the time window as long as the (typically longer)
time window in which an AT would be accepted. A DPoP proof that is valid
for 12 hours would not provide much replay protection.

The time window is left unspecified because it is only meant to account
for clock differences and network latency. Its precise value can depend
on deployment considerations. It is not intended to give the client an
option to re-use proofs, which is prevented together with the jti.

Also this would introduce new, unwanted and potentially surprising
dependencies between token lifetimes and the DPoP usage.

And finally, as discussed before, not all access tokens are JWTs and we
are not going to mandate JWT access tokens in this spec.

-Daniel


Am 01.12.20 um 09:54 schrieb Denis:
> Hi  Brian,
>
>> Hi Denis,
>>
>> The choice to use "iat" vs. "exp" was made in the summer of last
>> year. You can see some of the discussion from then in
>> https://github.com/danielfett/draft-dpop/issues/38.
>> I believe it pretty well has consensus at this point and thus
>> unlikely to be changed.
>
> I fear that you misread my email or read it too fast. My point had
> nothing to do whether using *either *of "iat" *o**r* "exp" in the DPoP
> proof JWT sent by the client.
>
> The first sentence of my email was: "One comment on slide 5 about the
> /time window/". So the topic was all about how the RS SHALL handle the
> "jti" claim included
> in the DPoP proof JWT when using a time window.
>
>
>> While I do believe there are reasonable arguments that can be made on
>> both sides of using either of "iat" or "exp", it's difficult (and
>> honestly time consuming and very frustrating) to try and have such
>> discussions or even respond in a coherent way when fundamental
>> aspects of the draft are misrepresented or misunderstood. For
>> example, the DPoP proof JWT is created by the client not the AS so
>> the advantages you put forward are nonsensical in the context of the
>> actual workings of the draft.
>
> Section 8.1 addresses the topic of the /time window/, but this topic
> should not /only /be addressed in the "Security Considerations" section
> but in the main body of the document, since some checks MUST be done
> by the RS. "Security Considerations"are intended to provide
> explanations but are not intended to be normative.
>
> Section 8.1 states:
>
>    " If an adversary is able to get hold of a DPoP proof JWT, the
> adversary could replay that token at the same endpoint (the HTTP
>    endpoint and method are enforced via the respective claims in the
> JWTs).  To prevent this, servers MUST only accept DPoP proofs
>    for a limited time window after their "iat" time, preferably only
> for a relatively brief period. 
>
>    Servers SHOULD store, in the context of the request URI, the "jti"
> value of each DPoP proof for the time window in which the respective
>    DPoP proof JWT would be accepted and decline HTTP requests to the
> same URI for which the "jti" value has been seen before.  In order
>    to guard against memory exhaustion attacks a server SHOULD reject
> DPoP proof JWTs with unnecessarily large "jti" values or store only
>    a hash thereof.
>
>    (...) ".
>
> The previous text makes the assumption that RSs MUST only accept DPoP
> proofs for a relatively brief period after their "iat" time included
> in the DPoP proof JWT. This assumption is rather restrictive. A client
> might get an access token and associate it with DPoP proof JWT that
> could be used during, e.g., 12 hours. A DPoP proof JWT/ access token
> JWT pair could thus be used by a client during, e.g., one day for
> several sessions with a RS.
>
> The /time window/ is currently left at the discretion of each RS and
> is supposed to be short (without stating explicitly what "short" may
> mean)..
>
> It would be possible to mandate in the JWT the inclusion of the exp
> (Expiration Time) Claim. (I am _not_ advocating the inclusion of the
> "exp"
> claim in the DPoP proof JWT).
>
> In this way, for a RS, the /time window /would be defined using the
> "iat" claim defined in the DPoP proof JWT and the "exp" claim defined in
> the JWT.
>
> Such a description should not be done in section 8, but in a section
> earlier in the main body of the document.
>
> This would have the following advantages:
>
>   * The RS would be able to better manage the "jti" claim values,
> because it would be able to discard "jti" claim values as soon as
> they are
> outside the time window as defined above.
>
>   * The client would know whether a DPoP proof JWT/ access token JWT
> pair is still usable, in particular using the "expires_in" status code
> returned in case of a successful

Re: [OAUTH-WG] Token substitution in DPoP

2020-11-24 Thread Daniel Fett

Thanks Justin for bringing this to our attention.

Right now, I don't think that this is a big problem and I wasn't able to
come up with a way to improve the attack. I hope that it doesn't come
back to haunt us when somebody does a more in-depth analysis...

That said, the lack of binding to the access token makes it easier to
precompute proofs if somebody has a limited code execution opportunity
in the client. We have this paragraph in the spec:

   Malicious XSS code executed in the context of the browser-based
   client application is also in a position to create DPoP proofs with
   timestamp values in the future and exfiltrate them in conjunction
   with a token.  These stolen artifacts can later be used together
   independent of the client application to access protected resources.
   The impact of such precomputed DPoP proofs can be limited somewhat by
   a browser-based client generating and using a new DPoP key for each
   new authorization code grant.

The recommendation could be to use a fresh key pair for each token request.

-Daniel


Am 20.11.20 um 20:26 schrieb Justin Richer:
> While working on an implementation of DPoP recently, I realized that the 
> value of the access token itself is not covered by the DPoP signature at all. 
> What I’m wondering is whether or not this constitutes an attack surface that 
> we care about here. Here’s how it works:
>
>
> Let’s say that a client creates a DPoP key and uses that key to request two 
> tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is 
> malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s 
> token value, T2, through some means. Normally DPoP wouldn’t let Alice create 
> a new request using T2 since Alice doesn’t have the client’s key. However, if 
> Alice gets the client to create a request for her using T1, she can copy the 
> signature from that request onto a new request using T2. Since the signature 
> doesn’t cover the token value and the key is the same, the RS should accept 
> both requests, right?
>
> An important aspect is that the parts needed to make this attack work are a 
> little weird: you’d need access to a valid signed request from the client 
> with T1 as well as access to a valid T2 attached to the same key in order to 
> make this substitution. However, this is effectively the same attack area 
> that bearer tokens have in a lot of ways, since it doesn’t require the 
> attacker gaining access to the singing key to generate or modify a signature, 
> nor does it require the attacker to generate or modify an access token 
> (merely obtain one).
>
>
> I’d like to understand if this is an actual attack against DPoP. If it isn’t, 
> how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? 
> I didn’t see a mention of it there. If it’s not, should we discuss it there?
>
>
> The old OAuth PoP draft mitigates this attack by putting the access token 
> itself inside the signature body instead of a second header. Another option 
> would be to include a hash of the token value (such as OIDC’s “at_hash” 
> method used in ID Tokens) in the DPoP payload. With either of these 
> approaches, Alice having access to T1, T2, and a signed message for T1 does 
> not allow her to use T2 effectively.
>
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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

1 2 3 >

1 - 100 of 202 matches

Mail list logo