Re: [OAUTH-WG] OAuth Digest, Vol 173, Issue 21

[Jeffrey Victorino <[e-mail]>]

https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com

On Wed, Mar 8, 2023, 12:59 PM <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: redirect uri and portals (Jaimandeep Singh)
>    2. Re: [IANA #1264432] expert review for draft-ietf-oauth-dpop
>       (http-fields) (Mike Jones)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 8 Mar 2023 10:17:12 +0530
> From: Jaimandeep Singh <[e-mail]>
> To: Karsten Meyer zu Selhausen <[e-mail]>
> Cc: Yannick Majoros <[e-mail]>, OAuth WG <[e-mail]>
> Subject: Re: [OAUTH-WG] redirect uri and portals
> Message-ID:
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>          <CAODMz5GwPaXtG6ZuK0PLtQhJZPxgc=McrD7YSps=
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Yannick,
>
> 1. I agree with Neil and Hans. It's one hardened endpoint vs any other
> endpoint which may have inadvertent security issues. It substantially
> increases the attack surface.
>
> 2. Karsten has given a detailed explanation on the use of "state"
> parameters. However in my opinion this design pattern is very annoying for
> the end user. It results in delayed performance due to multiple redirects
> or 'the dance of redirects'. In some implementations, the hardened endpoint
> even displays content, which further adds to the unpleasant user
> experience. Also, the "state" parameter may result in unintended
> information disclosure and the encryption and signature validation does
> have its own performance overheads resulting in increased wait time
> especially when the end user is waiting at the screen for the process to
> end. So, as per my understanding, there are two issues here:
>
> (a) The url automatically changes, which makes the user scary as he does
> not know what is happening and does not seem to be incontrol of his
> actions.
> (b) The degraded performance due to reading and verification of "state"
> parameters.
>
> 3. I agree with Yannick that there is a definite need to look at other
> options in a standardized way which can substitute for "state" parameter
> design pattern. Especially in view of PCKE which was designed specifically
> to mitigate the misuse of leaked authz code. Yannick you may like to bring
> it up in the upcoming meeting and can request a time slot from Rifaat.
>
> Regards
> Jaimandeep Singh
>
> On Tue, 7 Mar, 2023, 8:30 pm Karsten Meyer zu Selhausen, <
> [e-mail]> wrote:
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>
> > The benefit of not storing the state of all users on the server-side is
> > still present. The client only needs to store and use *one *key-pair for
> > all JWTs.
> > On 07.03.2023 15:57, Yannick Majoros wrote:
> >
> > I'm still missing the point:
> > - any key used to sign or encrypt the state... is state itself
> > - if we can store that key (or anything, like an url to go back to after
> > login), why bother passing the state around?
> >
> >
> > Le mar. 7 mars 2023 ? 15:07, Hannes Tschofenig <
> [e-mail]>
> > a ?crit :
> >
> >> Hi Yannick,
> >>
> >>
> >> Am 07.03.2023 um 14:25 schrieb Yannick Majoros:
> >>
> >> One possible solution: Store the redirect information in a signed JWT
> and
> >> place the JWT in the state parameter. I don't think this is written
> >> somewhere in the security BCP but I think this is a solutions used in
> the
> >> wild by multiple clients.
> >>
> >>
> >> Section 4.7.1 of the security BCP lists this solution as one possible
> >> countermeasure:
> >>
> >>    -
> >>
> >>    If state is used for carrying application state, and integrity of its
> >>    contents is a concern, clients MUST protect state against tampering
> >>    and swapping. This can be achieved by binding the contents of state
> to the
> >>    browser session and/or signed/encrypted state values as discussed in
> the
> >>    now-expired draft [I-D.bradley-oauth-jwt-encoded-state
> >>    <
> https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >>    ].?
> >>    <
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.7.1-3.2.1
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >>
> >>
> >> The referenced draft has, however, expired:
> >>
> https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt
> >>
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >>
> >> Ciao
> >>
> >> Hannes
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Yannick Majoros
> > Valuya sprl
> >
> > --
> > Karsten Meyer zu Selhausen
> > Senior IT Security Consultant
> > Phone:        +49 (0)234 / 54456499
> > Web:  https://hackmanit.de | IT Security Consulting, Penetration
> Testing, Security Training
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  > Save the date: 11.-12.5.2023. Join us in celebrating the 5th
> anniversary of RuhrSec - the IT security conference in Bochum:
> https://www.ruhrsec.de/2023
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  > 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, Prof. Dr. Marcus Niemietz
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230308/ec4a3cd5/attachment.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 8 Mar 2023 04:58:18 +0000
> From: Mike Jones <[e-mail]>
> To: Mark Nottingham <mnot=[e-mail]>
> Cc: Brian Campbell <[e-mail]>, Amanda Baber via RT
>         <[e-mail]>, "[e-mail]"
>         <[e-mail]>, Roy Fielding <[e-mail]>
> Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for
>         draft-ietf-oauth-dpop (http-fields)
> Message-ID:
>         <
> [e-mail]
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks - will do.
>
> ________________________________
> From: Mark Nottingham <mnot=[e-mail]>
> Sent: Tuesday, March 7, 2023 7:55:29 PM
> To: Mike Jones <[e-mail]>
> Cc: Brian Campbell <[e-mail]>; Amanda Baber via RT <
> [e-mail]>; [e-mail] <[e-mail]>;
> Roy Fielding <[e-mail]>
> Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for
> draft-ietf-oauth-dpop (http-fields)
>
> Hi Mike,
>
> Thanks. I left a comment on the PR, suggesting two small tweaks.
>
> Cheers,
>
>
> > On 8 Mar 2023, at 2:33 pm, Mike Jones <Michael.Jones=
> [e-mail]> wrote:
> >
> > Hi Mark,
> >
> > I've created the pull request
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your
> suggestions.  Please also see some additional replies below, which are
> prefixed by "Mike>".
> >
> > Please let us know if you'd like to see any changes to the PR before we
> merge it and publish an updated draft incorporating your suggestions.
> >
> > Thanks,
> > -- Mike
> >
> > -----Original Message-----
> > From: Mike Jones
> > Sent: Monday, January 23, 2023 11:42 PM
> > To: 'Mark Nottingham' <mnot=[e-mail]>; Brian Campbell
> <bcampbell=[e-mail]>
> > Cc: Amanda Baber via RT <[e-mail]>;
> [e-mail]; Roy Fielding <[e-mail]>
> > Subject: RE: [OAUTH-WG] [IANA #1264432] expert review for
> draft-ietf-oauth-dpop (http-fields)
> >
> > Hi Mark,
> >
> > Like Brian, I appreciate your detailed review.  My thoughts on the
> review points are interleaved with the discussion text below.
> >
> >> Keep in mind that HTTP header fields are basically sets of constrained
> octets with weird combination rules; if you don't use SF, you should be
> specifying (for example) what happens when two header values (and/or
> fields) are present (as per below). SF does a lot of the legwork here, even
> if from a type system standpoint it's not a perfect fit.
> >
> > I agree that we should specify these things - probably using language
> parallel to that in the SF draft, where appropriate.  I also share your
> assessment that, unfortunately, the SF type system is not an ideal fit for
> the DPoP headers.
> >
> > Mike>
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs
> does include the validation check "there is not more than one DPoP HTTP
> request header field".  In the PR, I also explicitly added that the there
> is a single field value.
> >
> >> That said, personally I'd deconstruct the JWT and convey it as separate
> binary values, so that if binary structured headers ever does catch on, it
> can get the perf/compactness advantages of that.
> >
> > Deconstructing the JWT would entail defining a new JWT serialization
> (representation).  Currently there is exactly one JWT serialization and
> this specification uses it.  I suspect developers would like us to keep it
> that way.
> >
> > Only one of the fields of a signed JWT is actually binary (the
> signature); the header and payload are JSON.  All are encoded using the
> base64 URL-safe character set (letters, numbers, -, and _ with no trailing
> =s) for safe transmission with encoded fields separated by the also
> URL-safe character period.  Furthermore, the signature is computed over the
> base64url-encoded values of the first two fields with a period between
> them.  The base64url encoding and concatenation is integral to the
> computation of the signature.  Any different serialization would still have
> to perform these computations.
> >
> > (Note also that some JWTs have three base64url-encoded fields separated
> by period characters and some have five, depending upon whether they are
> signed (three) or encrypted (five); deconstructing a value with a variable
> number of non-independent fields seems like significant unnecessary
> complexity.)
> >
> >>> ABNF syntax for the nonce value is provided at
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9
> along with the description of its use in the DPoP exchange.
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >> I see. It'd be better if it were explicitly called out as the syntax
> for the field (ideally with a section title that makes this clear), rather
> than making the reader do that work.
> >
> > Mike> The nonce syntax ABNF now has its own section title in the PR.
> >
> > I'm fine with us making the editorial improvement that you suggest.
> >
> >>> I believe that the SF String type would accommodate the content we
> intended to allow servers to use for the nonce (it's basically a server
> chosen value that the client treats as opaque and sends back in subsequent
> DPoP proof JWTs). However, that would be a breaking change, which shouldn't
> be undertaken lightly.
> >
> >> Right. It really depends on how advanced deployment of this is; if
> there's only modest production use, it may still be reasonable to make such
> a change (especially keeping in mind that people who adopt drafts need to
> bear the consequences of doing so).
> >
> > I'm with Brian here.  I don't believe that the cost/benefit tradeoff of
> the breaking change versus using the SF String type is a good one.
> >
> >> To be concrete -- what should an implementation do when it receives two
> DPoP header fields, both with valid values? When it receives one with two
> comma-separated values?
> >
> > These are great questions.  I'll commit to us answering them in the next
> draft.
> >
> > Mike> Per my earlier comment about the validation rules, these issues
> are both addressed in the rules.
> >
> >>>> - The long line-wrapped example in Section 4.1 would benefit from
> RFC8792 encoding. In HTTP, a line-wrapped field like the one shown has
> whitespace inserted between each line, which is problematic here.
> >>
> >>> This is a bit of a stylistic preference thing. That example and others
> in the draft are intentionally similar (with a note about line breaks and
> extra space being for display purposes) to closely related and referenced
> documents like RFC7515, RFC7519, and RFC6749. The examples from these RFCs
> seem to have worked well for readers/implementers in practice, and so we'd
> prefer to keep the formatting conventions in this draft the same as in
> those.
> >>
> >> Consistency between documents that specify HTTP protocol elements is
> important, so I'd ask you to reconsider; while the community that has been
> developing and implementing the specification may already be familiar with
> it, aligning with other documents makes it easier for a broader audience.
> See, for example, the Signatures specification:
> https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-request-response-signature-
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  > I'm fine with us making this editorial change to the examples, since
> you feel that this would help some readers of the specification.
> >
> > Mike> I applied RFC 8792 '\' line wrapping.
> >
> > In closing, I'll say that I appreciate that the SF spec has done heavy
> lifting that we would do well to take advantage of.  I appreciate you
> bringing it to our attention.  That said, since SF's type system does not
> cleanly map to some of the DPoP fields, and since the use of SF is
> optional, I personally believe that the best route for us to take advantage
> of SF is to study it and ensure that the questions that SF answers for the
> field types that it defines are also answered for the fields defined by the
> DPoP draft.
> >
> > Best wishes,
> > -- Mike
> >
> > -----Original Message-----
> > From: OAuth <[e-mail]> On Behalf Of Mark Nottingham
> > Sent: Sunday, January 22, 2023 7:13 PM
> > To: Brian Campbell <bcampbell=[e-mail]>
> > Cc: Amanda Baber via RT <[e-mail]>;
> [e-mail]; Roy Fielding <[e-mail]>
> > Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for
> draft-ietf-oauth-dpop (http-fields)
> >
> > Hi Brian,
> >
> >> On 21 Jan 2023, at 5:46 am, Brian Campbell <bcampbell=
> [e-mail]> wrote:
> >>
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >>
> >> Hi Mark,
> >>
> >> Thanks for the review and feedback. I am aware of HTTP Structured
> Fields and certainly see value in it - even using it in some other work in
> which I'm involved. However, I'm unsure of its fit or utility for this
> draft. With that said, I've tried to reply more specifically to your
> comments inline below.
> >>
> >>
> >> On Wed, Jan 18, 2023 at 3:32 PM Mark Nottingham <mnot=
> [e-mail]> wrote:
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >> A few things caught my eye in this document:
> >>
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >> - Section 4.1 defines the DPoP header field as a JWT, which (as I
> understand it) is a base64-encoded string. If that's the case, I'd
> recommend making it a Structured Field Item (see RFC8941 s 3.3) with a
> fixed type of Byte Sequence (s 3.3.5). That will require changing the
> syntax to add a prefix and suffix of ":".
> >>
> >> As Justin pointed out, a JWT is three Base64url encoded segments
> delimited by the `.` period character, which means it can't be a SF Byte
> Sequence.  As DW pointed out, a JWT just happens to always start with a
> letter because the first segment is always encoded JSON, so will always
> start with 'ey'. So the DPoP header field value does just happen to fit the
> SF Token syntax, But the SF Token syntax does very little regarding the
> validity of the JWT.
> >
> > Keep in mind that HTTP header fields are basically sets of constrained
> octets with weird combination rules; if you don't use SF, you should be
> specifying (for example) what happens when two header values (and/or
> fields) are present (as per below). SF does a lot of the legwork here, even
> if from a type system standpoint it's not a perfect fit.
> >
> > That said, personally I'd deconstruct the JWT and convey it as separate
> binary values, so that if binary structured headers ever does catch on, it
> can get the perf/compactness advantages of that.
> >
> >
> >> - The DPoP-Nonce header field's syntax isn't obviously specified. It
> should be. I'd suggest a Structured Field Item with a fixed type of String
> (RFC 8941 s 3.3.3), which would surrounding the value with quotes.
> >>
> >> ABNF syntax for the nonce value is provided at
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9
> along with the description of its use in the DPoP exchange.
> >
> > I see. It'd be better if it were explicitly called out as the syntax for
> the field (ideally with a section title that makes this clear), rather than
> making the reader do that work.
> >
> >
> >> I believe that the SF String type would accommodate the content we
> intended to allow servers to use for the nonce (it's basically a server
> chosen value that the client treats as opaque and sends back in subsequent
> DPoP proof JWTs). However, that would be a breaking change, which shouldn't
> be undertaken lightly.
> >
> > Right. It really depends on how advanced deployment of this is; if
> there's only modest production use, it may still be reasonable to make such
> a change (especially keeping in mind that people who adopt drafts need to
> bear the consequences of doing so).
> >
> >
> >> - Neither header has interoperable parsing or serialisation specified;
> divergent error handling may cause interoperability problems. Adopting
> Structured Fields would address this.
> >>
> >> Both are composed of a narrow set of printable ASCII with parsing,
> validation, usage, and error handling specified at the application layer.
> I'm not going to claim that it's perfect by any means. But those
> interoperability problems seem conjectural and it's not obvious that
> adopting Structured Fields would add value in the context of this draft.
> >
> > To be concrete -- what should an implementation do when it receives two
> DPoP header fields, both with valid values? When it receives one with two
> comma-separated values?
> >
> >
> >> - See RFC9110 s 16.3.2 for things that should be considered when
> defining new HTTP fields. I suspect that the document needs to be more
> explicit about at least some of these items. Adopting Structured Fields
> would address some (but not all) of these questions.
> >>
> >> The authors (on-behalf-of and with the help of the WG) have endeavored
> to touch on all the considerations needed to ensure interoperability of the
> protocol overall as well as HTTP related (e.g. caching, applicability to
> request/response, prohibiting multiple occurrences, scope of
> applicability). However, the group clearly does not have your depth of HTTP
> expertise so may well have missed something. If that's the case, it would
> be very helpful for specifics to be raised.
> >>
> >> - See also <
> https://httpwg.org/admin/editors/style-guide#header-and-trailer-fields>
> for the preferred editorial style when defining new HTTP fields.
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >>
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >> - The long line-wrapped example in Section 4.1 would benefit from
> RFC8792 encoding. In HTTP, a line-wrapped field like the one shown has
> whitespace inserted between each line, which is problematic here.
> >>
> >> This is a bit of a stylistic preference thing. That example and others
> in the draft are intentionally similar (with a note about line breaks and
> extra space being for display purposes) to closely related and referenced
> documents like RFC7515, RFC7519, and RFC6749. The examples from these RFCs
> seem to have worked well for readers/implementers in practice, and so we'd
> prefer to keep the formatting conventions in this draft the same as in
> those.
> >
> > Consistency between documents that specify HTTP protocol elements is
> important, so I'd ask you to reconsider; while the community that has been
> developing and implementing the specification may already be familiar with
> it, aligning with other documents makes it easier for a broader audience.
> See, for example, the Signatures specification:
> >
> https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-request-response-signature-
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  > Cheers,
> >
> >
> >>
> >> Cheers,
> >>
> >>
> >>
> >>
> >>> On 19 Jan 2023, at 5:30 am, David Dong via RT <
> [e-mail]> wrote:
> >>>
> >>> Dear Mark Nottingham and Roy Fielding (cc: oauth WG),
> >>>
> >>> As the designated experts for the http-fields registry, can you review
> the proposed registration in draft-ietf-oauth-dpop for us? Please see:
> >>>
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> >>>
> >>> The due date is February 1st, 2023.
> >>>
> >>> If this is OK, when the IESG approves the document for publication,
> we'll make the registration at
> >>>
> >>> https://www.iana.org/assignments/http-fields/http-fields.xhtml
> >>>
> >>> We'll wait for both reviewers to respond unless you tell us otherwise.
> >>>
> >>> With thanks,
> >>>
> >>> David Dong
> >>> IANA Services Specialist
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> 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.
> >
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mailarchive.ietf.org/
> <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230308/07d48895/attachment.htm>

https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com

> arch/browse/oauth/attachments/
> <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230308/07d48895/attachment.htm>

https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com

20230308/07d48895/attachment.htm
> <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230308/07d48895/attachment.htm>
> >
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> https://developer.google.com/u/Profile/jeffreyvictorino92.com/https://E.g.victorinojeffrey92.com
>  ------------------------------
>
> End of OAuth Digest, Vol 173, Issue 21
> **************************************
>