Re: [GNAP] [Txauth] Kathleen's review

Tom Jones <thomasclinganjones@gmail.com> Thu, 06 August 2020 20:16 UTC

Return-Path: <thomasclinganjones@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC83C3A0EE5 for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 13:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BLkzl0tefd8J for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 13:16:00 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AC03A0EDB for <txauth@ietf.org>; Thu, 6 Aug 2020 13:16:00 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id b22so18115062oic.8 for <txauth@ietf.org>; Thu, 06 Aug 2020 13:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yNGheCYYHjMm5w2JojAcN8ZPs48dPN2b44PgAoo89jY=; b=gHHhXGEYMWh2oYkD2PsD4zf9/5mNvvCEjQ8J6fXxNq+BlIjNzhioyPp6BavqK4Qk5m ORqUJZu78KrLFLLm/Zs3IWACg0XJbQXZJtD6D/8Jo6HJI1gUSJVCp9rLvew7UNtplXux kRVLcaQz7//Lr9D4lv78qxKmDyB0gjn5zHfaMocttmZ1BbLKXKDZhJ2kvz/8xTJQqzCd GGhI6JAIiOOqVprmp7RsguoPyeA9UmcA0byqtadW2RcmWWo3BmQThQhjn0ygyUU2iY3K zI7M0tJP60K0NL0xjZgIcH939eczJZV7STAthMpWw0S6p7k0hOYTCWmyDuo8r3PVapBG zEiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yNGheCYYHjMm5w2JojAcN8ZPs48dPN2b44PgAoo89jY=; b=XkkINC88eSPt8WWct1OBAOUDVF66Q31YHm0wEwB4x6MZRUcEjtbG11phblYI7/P6cV okGty9KFwvDl4c6VNWBdoemlB68ACJteBot/Db3XrUEZHTeNE/FFvJxjxs0uxK3WHiFm mDylwu9/MoYJgRJj6Pvrb/Vv3NA8q1tNOhT8VShlfeI+KNYmNUjeQewX7V6NAbrKSbwF X+H1YRQWsRrMDgi9DVgxTKnKrvQTF1PgehkNJD43Xeqq/8bqELazR155UHX1Uo3EAQWL Ta7SJKGePnT4eXg+0w4acQAg9da+SezxH+jG3AHPYfVwrnvngcMxiLSmO0742cA1SXAz 7ELg==
X-Gm-Message-State: AOAM530IIEQYnbujHEjIZP4cEIGQcrUME/XIOpZ5a0FZtBuYivvCX7el fZ/VegrMOs40Q2ekD7WxnjLHNVcaqAClSZC8iT2DwQ==
X-Google-Smtp-Source: ABdhPJw/6U9i9i236zLqhDGDFnTTQ3HdMJlTb721FraJpOi86vCryN98PqI0oHgEySLhu9PGJ2TrP5B8R1oZy+wRgH8=
X-Received: by 2002:a54:448f:: with SMTP id v15mr8786366oiv.172.1596744959563; Thu, 06 Aug 2020 13:15:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-t5b7L_JJrtAYowXNDdTVopej-vCy=OoWEaawgBngKLJQ@mail.gmail.com> <CAHbuEH4fo+nCEMn7Dw5Gg6etWQruaXpsChr5gEXTQY6QRkpfjA@mail.gmail.com> <CAD9ie-u7uAr9it8Ezq6O0z45k5pzURXPsy-cBsy-zAVAcB93Vw@mail.gmail.com>
In-Reply-To: <CAD9ie-u7uAr9it8Ezq6O0z45k5pzURXPsy-cBsy-zAVAcB93Vw@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 6 Aug 2020 13:15:48 -0700
Message-ID: <CAK2Cwb7dzyUMokqAQBS6MCzLLojE3A=-+Ohz4LWGhsWm3F5CZw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c999e05ac3b2890"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/EuoHpujELNtR3814XKHsCMd-MP4>
Subject: Re: [GNAP] [Txauth] Kathleen's review
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 20:16:09 -0000

the only encoding that i care about is jose-encoding. Without it the doc
would just be advisory for my applications.
Peace ..tom


On Thu, Jul 30, 2020 at 1:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> (adding in a subject)
>
> Thanks for the clarification Kathleen!
>
> I fully agree with you that we want developers to think of security when
> reviewing the document.
>
> Ironically, I wanted to ensure a Client developer knew they needed to
> authenticate in all calls to the AS, and I had JOSE in every section in the
> first drafts I sent to Justin for feedback, and he suggested I factor it
> out into its own section, so that it would be easier to specify
> other client authentication mechanisms such as MTLS and http signing. I
> factored it into its own section, and then got feedback that people
> preferred the JOSE client authentication to be a separate document.
>
> In the milestones for the WG[1], the core delegation protocol is a
> milestone targeted for July 2021, and a key presentation mechanism is an
> independent milestone targeted for Oct 2021.
>
> In the charter we have anticipated having numerous key presentation
> mechanisms, so separating the key presentation documents from the core
> protocol seemed the right choice.
>
> Q: Are you suggesting we combine the documents? Or is there a different
> recommendation to overcome what you saw as a security deficiency in XAuth
> vs XYZ?
>
> As you know, there is much more to security than cryptography, and I
> considered how to encourage best practices in the design. One of those is
> the separation of concerns, which I wanted to encourage by using URIs and
> HTTP methods so that GS decomposition was straight forward per slides 11-13
> of my presentation [2].
>
> In contrast to XYZ, XAuth requires the Grant URI and AZ URI to start with
> the GS URI, so the Client has certainty on which GS a Grant or AZ is for on
> receipt, and when working with the URIs later on. An opaque token or handle
> stored in a database could be associated with any GS -- so a self
> describing URI can assist in detecting an error in which GS it belongs to.
> I think constraints like these improve security as more errors can be
> detected, and attack vectors are reduced.
>
> btw: A GS could have just one entry point if desired, the GS URI, and the
> Grant URI and AZ URI could be represented by query parameters.
>
> /Dick
>
> [1] https://datatracker.ietf.org/group/gnap/about/
>
> [2]
> https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xauth-dick-hart-00
>
>
> Would you confirm you were looking at -13 of XAuth? (The datatracker tools
> are confused and depending on how you land on the page, the latest version
> is not displayed)
>
> In my first drafts that I shared offline with Justin, I had JOSE client
> authentication throughout
>
> Put JOSE Client authentication into a separate document in version -08.
>
> WG deliverables -- authentication is a separate document.
>
>
>
>
> From a security perspective, I focussed on the protocol aspects rather
> than the security aspects.
>
> interaction modes
>
> URIs - based off of GS URI, methods and - decomposition
>
> client knows which GS a Grant or AZ came from
>
>
>
>
>
>
>
>
> On Thu, Jul 30, 2020 at 8:11 AM Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>> Hey Dick,
>>
>> Thanks for your questions and all of your hard work.  I'll respond inline
>> as not to miss anything.
>>
>> On Wed, Jul 29, 2020 at 1:07 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> Hey Kathleen
>>>
>>> A couple questions on your presentation:
>>>
>>> 1) Which versions of the documents did you review?
>>>
>> Your last posted version to the datatracker.
>> I had started with the latest in the datatracker for Justin, but switched
>> when he announced the update.  Although my skim on the datatracker one had
>> similar impressions in terms of structure, ease of use, etc.
>>
>>
>>>
>>> 2) Would you elaborate on your security comparisons of XAuth and XYZ? I
>>> want to make sure I understand the work you put into your review.  While
>>> reviewing your slides, I was not following a number of your statements. For
>>> example:
>>>
>>> In your first slide:
>>>
>>> A) you stated that "XAuth Relies heavily on OAuth2.0, using Bearer token
>>> and adding cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth
>>> and XYZ support bearer tokens for calling an RS. I'm not clear how this
>>> feature is different in XAuth.
>>>
>>
>> Sure, XAuth punts the use of security off in a section and is not more
>> integrated in the approach.  That's how OAUth is now and it's something
>> that really should be fixed.  Making it clear that security is an
>> afterthought makes it an afterthought for developer and implementers.
>> Industry is moving towards built-in intrinsic security.
>>
>> You can do this just as easily, but XYZ mentioned security in the
>> flows/sequences as an inherent part of each.   While it may not be perfect
>> yet, the theme was there.  The references to exchange of a key in section 2
>> and 3 with an editor note that this needs work are the first places the
>> idea of embedding begins.
>>
>> The value generated in the access token doesn't explicitly use crypto,
>> but could.  This is something to consider.
>> Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used.  This
>> is in the feedback I will be posting.
>>
>> Section 7 calls explicitly for use of a JWS and authorization values.
>>
>> Section 8 provides more explicit guidance for add-on, but it's not in a
>> registry or another draft - part of this work.
>>
>> Section 13 points to the need for more work, acknowledging multiple ways
>> to explore supporting security directly in the protocol.
>>
>>
>>
>>
>>
>>> B) What parts of XYZ did you view as "Builds security into the protocol
>>> as opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"?
>>>
>> See above.  It's a lot more clear than the single reference in XAuth.
>>
>>
>>>
>>> C) "Interaction flows defined, focus more on security with cryptographic
>>> requirements and examples included" -- there some cryptography in the
>>> redirect flow, but not in the others. In my opinion, the cryptography in
>>> the redirect flow does not add any value, and just complicates the
>>> protocol.
>>>
>>> Perhaps you can point to sections in each draft?
>>>
>> See above.
>>
>> Best regards,
>> Kathleen
>>
>>
>>>
>>> Thanks!
>>>
>>> /Dick
>>>
>>>
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>