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

[Tom Jones <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>