Re: [Txauth] Kathleen's review

[Dick Hardt <[e-mail]>]

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