Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Mar 2023 13:12:46 -0700

On Wed, Mar 1, 2023 at 5:04 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >>>>  QMa1: General
> >>>>
> >>>>    As the document defines a new error code, and define new
> >>>>    WWW-Authenticate parameters, should the document not be an Update
> to
> >>>> RFC 6750?
> >>>>
> >>> It's a good point to consider. Our rationale is that this document
> >>> leverages
> >>> many different extension points baked in a number of existing specs,
> hence
> >>> it doesn't seem a slam dunk to determine which one we should "inherit"
> >>> from.
> >>
> >> Since the draft refers to RFC 6750 I would assume that is the spec at
> least
> >>being updated.
> >>
> >>But, if the draft also updates procedures etc of other specs I guess
> those
> >>may
> >>also be updated. I don't have the expertise to have an opinion on
> whether
> >>that
> >>is the case.
> >
> > The thrust there wasn't to suggest that this draft needs to update other
> > specs. Rather to say that this draft utilizes defined extension points
> > provided by a number of RFCs (like RFC6749, RFC6750, RFC7662, RFC7519)
> and
> > the associated registries where appropriate/needed. Those extension
> points
> > have been used by other specs already without the spec doing the
> extension
> > formally updating the RFC that it's using the extension points of.
> >
> > More generally, our rationale and attempt to follow precedent here was
> that
> > the utilization of defined extension points didn't warrant "Updates" to
> the
> > specs providing those extension points.
>
> Fair enough.
>
> I do agree that, in other protocols, defining new error codes etc do now
> always mean updating of specs.
>
> ---
>
> >>>>  QMa2: Section 4
> >>>>
> >>>>    The text defines the procedures for the client.
> >>>>
> >>>>    But, what if the client does not support the new error code and
> the
> >>>> new
> >>>>    WWW-A parameters? I think there should be some backward
> compatibility
> >>>>    text (or reference, if defined elsewhere).
> >>>>
> >>>>    Especially it should be clear that the server will not receive the
> >>>> WWW-A
> >>>>    parameters in the new request if the client does not support them.
> >>>
> >>> This is a tricky one. Technically, every extension starts its
> existence
> >>> with
> >>> zero support from existing clients.
> >>>
> >> Yes, and I have been in many situations where people argue on what is
> the
> >> correct behavior when one endpoint supports an extension, the other
> >> doesn't,
> >> and there are no defined backward compatibility procedures to refer to
> :)
> >>
> >>> Implementers should be familiar with this, and specs stipulate that any
> >>> entity receiving a parameter it doesn't understand to ignore that
> >>> parameter,
> >>> from which it follows that whatever semantic or directive that
> parameter
> >>> carries will remain not executed.
> >>> Saying in the document that clients not supporting the parameters we
> are
> >>> defining here will not achieve the goals of the spec seem somewhat
> >>> redundant. What do you think?
> >>
> >>I think it is more than just "not achieving the goals". Clients that do
> not
> >>support the extension may end up not getting any service at all, as they
> >>don't
> >>understand that the reason for rejection is not meeting the
> authentication
> >>requirements.
> >
> > Yes, clients that do not support the extension will not understand the
> new
> > error code and auth-params and won't know to act accordingly. That is
> the
> > nature of these
> > kinds of extension points. This draft can't change how the underlying
> specs
> > expose extensions (and I honestly wouldn't know how to do it differently
> > even if it could).
> > Of course, existing software that is unaware of this draft can't have
> any
> > behavior dictated by this draft. For the case where an entity doesn't
> > support the extension,
> > I don't see how this document could say anything meaningful about
> > compatibility. Other than to remark or reiterate that an entity that
> doesn't
> > understand the extension
> > will not understand it, which seems neither actionable nor useful in the
> > document. Honestly, what language would we even use here?
>
> I was thinking of e.g., a note that highlights the issue.
>
> But,  I do agree it should be obvious to people familiar with the specs,
> so if
> you don't think it is needed I will not argue against you :)
>
> I assume there will be no indicator in the initial request informing the
> server whether the client supports the feature or not?
>

Correct, there's no such indicator. I don't think it would help the
situation either - the resource server would still deny the request just
with a 'traditional' error code and less information about why it was
denied. And using such an indicator as input to access control decisions
would be introducing security issues, which we definitely don't want.

>
> ----
>
> Minor issues:
>
> >>>>  QMi1: Section 3
> >>>>
> >>>>    Can the new WWW-Authenticate parameters only be used with the new
> >>>> error
> >>>>    code? If so, please indicate it.
> >>> There doesn't seem to be any obvious reasons to ban future extensions
> from
> >>> using those parameters, nor there appear to be obvious scenarios where
> we
> >>> would proactively
> >>> suggest doing so: that's our rationale for not having commented on this
> >>> aspect in the document.
> >>
> >> One alternative would be to not ban, but to say that THIS spec only
> defines
> >> usage of the parameters with the new error code, but that future specs
> may
> >> define usage with other error codes.
> >
> > That seems like a worthwhile clarification to make. Thanks. We will
> > add/adjust some text accordingly.
>
> Thanks!
>
> Regards,
>
> Christer
>
>

-- 
_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._