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

Benjamin Kaduk <kaduk@mit.edu> Mon, 27 April 2020 17:32 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC33A0B90; Mon, 27 Apr 2020 10:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBV1OlBAHVG8; Mon, 27 Apr 2020 10:32:31 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B313A1231; Mon, 27 Apr 2020 10:32:30 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RHWPKP014402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 13:32:27 -0400
Date: Mon, 27 Apr 2020 10:32:24 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE <sipcore@ietf.org>, Jean Mahoney <mahoney@nostrum.com>
Message-ID: <20200427173224.GA27494@kduck.mit.edu>
References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <CAGL6epJR916uMf-eeihvRyZRD3u-CR73v=C0pRGmbCi_tmbPEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAGL6epJR916uMf-eeihvRyZRD3u-CR73v=C0pRGmbCi_tmbPEw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/vLOoIku4rFTJhHH2KP-wND9trxM>
Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 17:32:34 -0000

On Sat, Apr 25, 2020 at 08:57:51AM -0400, Rifaat Shekh-Yusef wrote:
>    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
>    <noreply@ietf.org> 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.

Yes.

>    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?

Well, this paragraph leaves me confused as to what we're trying to convey.
To try to clarify my current understanding, let me consider the current
text in the -13, which talks about "user credentials and any tokens
obtained using these user credentials".  Splitting that apart, I assume
"user credentials" is a password or analogue, and the "tokens" are, well,
the OAuth/OIDC tokens this document uses.  My (admittedly not perfect)
understanding of analogous cases in stock OAuth is that for a browser-based
SPA the browser gets redirected to an IdP where the user enters credentials
to authenticate, and is returned to the SPA along with the token(s).  So in
that case the SPA has the tokens but not the user credentials.

Your paragraph quoted above seems to imply that the browser-based UAC would
not have the tokens, either?  But then how would anything work?
> 
>      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.

Okay, thanks.

-Ben