Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply

[Rifaat Shekh-Yusef <[e-mail]>]

Hi Ben,

Thanks for the detailed and comprehensive review.
I will try to address the DISCUSS in this email with my inline comments
below.

Regards,
 Rifaat


On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-sipcore-sip-token-authnz-13: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I support Roman's Discuss.
>
>
> The "Bearer" authentication challenge includes the address (or name?) of an
> authorization server to contact to obtain tokens, as mentioned in multiple
> places in the document (noted in the COMMENT section).  Our experience in
> the OAuth world has shown that several classes of vulnerabilities are
> possible when the client blindly attempt to use any provided AS, and that a
> whitelist of "allowed" or "trusted" ASes is needed for secure operation.  I
> believe that the same is true for the SIP usage, and we should mention this
> requirement explicitly.
>
>  Yeah, good point. I will add some text to address that.


> Section 1.2 tries to apply the OAuth confidential/public client distinction
> to SIP UACs, but it does so in a non-analogous fashion: the OAuth
> distinction is for the client's ability to protect credentials that
> identify
> the client itself; the usage in this document refers to protecting *user*
> credentials and obtained tokens.  I don't think that it's appropriate to
> invoke the OAuth terminology when using it for a different meaning.
> Both Public and Confidential OAuth clients are capable of providing the
> necessary protections for *user* credentials (though they are of course not
> guaranteed to do so), which leaves me unclear on what the intended
> requirements actually are.
>
> Well, a browser-based client apps do not have client credentials at all,
and they are considered public clients.
I think the clarification needed here is to make it clear that we are
talking about persistent storage of credentials.
What I am trying to do with these two definitions is to differentiate
between a browser-based UAC and non-browser based UAC.
Because a browser-based UAC should be using a different flow, the
authorization code grant flow, which is not covered by this document.
Would adding such clarification address this comment?


>
> Section 2.3 states that:
>
>    When a proxy wishes to authenticate a received request, it MUST
>    search the request for Proxy-Authorization header fields with 'realm'
>    parameters that match its realm.  It then MUST successfully validate
>
> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not
> expected to have a sequence or list of Proxy-Authorization header fields
> present in a single request that are intended to be interpreted by
> different
> proxies.  Is this text compatible with that part of RFC 7235?  Furthermore,
> I didn't find much guidance in 7235 or 3261 about when to include the
> "realm" parameter in Proxy-Authorization; do we want to give any guidance
> here?  (That is to say, I almost didn't find where it was even defined as
> possible to do so...)
>
> There is a separate thread already on this one.


>
> I'm also not sure if we're attempting to profile RFC 6749 and always
> require
> a refresh token to be issued, or just have some editorial tweaks to make to
> avoid suggesting that we do have such a requirement (noted in the COMMENT).
>
> This part is out of scope for this document, as it is related to the
interaction between the UAC and the AS.
This document is not trying to deviate from the OAuth 2.0 recommendations;
we will clarify this.