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

[Justin Richer <[e-mail]>]

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] <mailto:[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/ <https://datatracker.ietf.org/group/gnap/about/>
> 
> [2] https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xauth-dick-hart-00 <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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> -- 
> Txauth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth