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

[Tom Jones <[e-mail]>]

Your interpretation is correct. My statement is, and remains, that we
require jose encoding to build a token that can carry the little token
"niblets" within the AZ token that are jose encoded. Dick's broad statement
about encoding is problematic for us. I also jose encode the entire token,
but I admit that is merely a convenience for my own implementations. BTW -
other encodings, like cbor, are of interest, but somehow encoding must be
addressed and included in the spec so that any comformate token can be
appropriately handled. I see that the W3C CCG is struggling with this now.
I hope they are able to propose a meta-encoding that can be used here.
Peace ..tom


On Mon, Aug 10, 2020 at 7:21 AM Justin Richer <[e-mail]> wrote:

> Tom, could you expand why “JOSE encoding” is essential to your use case?
>
> From what I’ve read of your proposals, most of your work seems centered
> around claims in the access token itself that can be interpreted by the RS
> components in the system. GNAP is going to remain agnostic on the format of
> the access token, so JOSE can be used there as always.
>
> What’s being discussed below is using JOSE as the HTTP message body format
> for the requests from the client to the AS (and potentially return from the
> AS), not the token format or any kind of assertion format.
>
>  — Justin
>
> On Aug 6, 2020, at 4:15 PM, Tom Jones <[e-mail]>
> wrote:
>
> 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
>>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>