Subject: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Mar 2020 16:05:34 -0700

*Client Authentication / Proof of Possession*
XYZ
- client proves use of bound keys via general-purpose mechanisms, including
detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
- RS access via bearer token or proof-of-possession through any allowable
key binding mechanism

XYZ Rationale: choosing one auth method as a “default" makes too many
assumptions about client’s nature and deployment capabilities. AS should
support as many as it can (and possibly have an MTI requirement), client
supports whatever method makes the most sense for it. PoP mechanisms for RS
should be independent of mechanisms at AS.

XAuth
- client proves use of bounds keys through an auth mechanism at GS
- specifies default mechanism using JOSE for GS and RS proof-of-possession
calls
- RS access via bearer token just like OAuth 2.0
- extensions can define other mechanisms such as HTTP Sig or MTLS to
replace JOSE for either GS and/or RS calls

XAuth Rationale: having a Client Authentication mechanism defined and as
default removes burden of selecting mechanism for most deployments, and
ensures interop.
ᐧ

---

From: David Skaife <[email-masked]>
Date: Fri, 20 Mar 2020 21:02:57 +0000

Hi,

As requested by Dick in the parallel email chain, I'll see if this response
can start to kick off some discussion.

If I'm understanding this correctly, then the main difference here is the
debate around whether to have a "default" authentication method or not.
Both XYZ and XAuth appear to support having multiple different
authentication methods that the client can use (which I certainly agree is
sensible), but for XYZ this is part of the "core" protocol, whereas for
XAuth it's more of an extension.

My view is that I don't think the argument "*choosing one auth method as a
default makes too many assumptions about client’s nature and deployment
capabilities*" is necessarily a valid reason to avoid having a default.
Having a default perhaps makes assumptions about the most *common* use
cases and the most *common *clients, but it certainly doesn't prevent other
more niche clients and use cases from being able to use the protocol. I
share the concern raised in the XAuth rationale text that not having a
default mechanism places a burden on the clients to choose, which may be
off-putting or a distraction for some newcomers. I do however think the
availability of different authentication methods should be part of the core
protocol, to encourage each AS to implement as many different methods as
possible - which it would be in there interest to do so as it would enable
the AS to support more use cases.

So in summary, I'm in favour of the protocol supporting multiple different
authentication methods as part of the core protocol, but my preference
would be to have a default selected if the client doesn't want (or need) to
choose anything different. I don;t think having a default would be
restrictive, and I think when the protocol is eventually
launched/standardised in the future we'll have a clear view of what that
default should be to ensure that it's aligned to the most common use cases.

Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <[email-masked]> wrote:

> - client proves use of bound keys via general-purpose mechanisms,
> including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Vijay IETF <[email-masked]>
Date: Sat, 21 Mar 2020 03:16:27 +0530

Hi,

+1 for XYZ Rationale. I prefer de facto over de jure.

My understanding is that the AS is *not* preventing a client implementation
to choose a de facto auth method that supports the most common use cases.

I see no compelling need for the AS to implement a de jure default since
there will eventually be one or two popular and widely used client side
implementations that anyway will pick a de facto auth method for their
intended users/customers.

XYZ rational allows for AS to evolve independently without the burden of
supporting a default that may be onerous in constrained environments.

---
Vijay

PS: I am assuming top post is acceptable in this group. Let me know if
that's not the case.

On Sat, 21 Mar 2020 at 02:33, David Skaife <
[email-masked]> wrote:

> Hi,
>
> As requested by Dick in the parallel email chain, I'll see if this
> response can start to kick off some discussion.
>
> My view is that I don't think the argument "*choosing one auth method as
> a default makes too many assumptions about client’s nature and deployment
> cases and the most *common *clients, but it certainly doesn't prevent
> other more niche clients and use cases from being able to use the protocol.
> I share the concern raised in the XAuth rationale text that not having a
>> - specifies default mechanism using JOSE for GS and RS
>> proof-of-possession calls

---

From: Tobias Looker <[email-masked]>
Date: Sat, 21 Mar 2020 10:51:46 +1300

One of the questions I have about normatively defining a default is what
happens if that default becomes vulnerable in time and or the ecosystem
moves to a newer approach? Does having the default not cause all parties
then to have to carry that legacy? Although not a perfect analogy I think
there are some lessons from protocols like TLS that would be relivant here?
Would specifying this in a recommended implementation section not act as
enough of a forcing function for interoperability but also enable future
evolution?

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
[email-masked]
 <https://mattr.global> 
<https://www.linkedin.com/company/mattrglobal> 
<https://twitter.com/mattrglobal> 
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 17:29:55 -0700

Hi Vijay

wrt. constrained environments, as I noted in XAuth

https://tools.ietf.org/html/draft-hardt-xauth-protocol-05#section-11

Constrained environments could use CBOR [RFC7049] instead of JSON, and COSE
[RFC8152] instead of JOSE, and CoAP [RFC8323] instead of HTTP/2.

I would NOT expect a constrained environment to use the same mechanisms
that others use, for the same reasons CBOR, COSE, and CoAP exist.

wrt. a de jure default, it is not any more de jure than JSON, JOSE, or MTLS.

Both XYZ and XAuth use JSON for payloads and HTTPS for transport.

For some environments, MTLS will be a better choice, for others, JOSE will
be a better choice.

Myself, I think JOSE is easier for most environments (I'm not including
constrained environments in this argument for the reasons above) -- but I
would also be ok with a different mechanism as the default.

If all choices are equal (no default), then ALL the choices have to be
implemented in a general purpose implementation, which increases the attack
surface and vulnerability of an implementation, ie a coding error.

On Fri, Mar 20, 2020 at 2:46 PM Vijay IETF <[email-masked]> wrote:

> My understanding is that the AS is *not* preventing a client
> implementation to choose a de facto auth method that supports the most
> common use cases.
>
>> So in summary, I'm in favour of the protocol supporting multiple
>> different authentication methods as part of the core protocol, but my
>> preference would be to have a default selected if the client doesn't want
>> (or need) to choose anything different. I don;t think having a default
>> would be restrictive, and I think when the protocol is eventually
>>> - RS access via bearer token or proof-of-possession through any
>>> allowable key binding mechanism
>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 17:37:22 -0700

Hi Tobias

Good question about vulnerabilities. They could happen anywhere in the
protocol, not just in the client authentication mechanism.

There are likely some lessons from TLS on what worked, and what was
problematic. Let's learn from them (and others) and adopt what worked.

But just as TLS has evolved, rather than be replaced, I would expect that a
default mechanism would evolve, rather than be replaced.

And also like TLS, new crypto algorithms are introduced, and compromised
algorithms are deprecated. Crypto agility is built into both MTLS and JOSE,
which are two of the proposed client authentication mechanisms.

/Dick

On Fri, Mar 20, 2020 at 2:51 PM Tobias Looker <[email-masked]>
wrote:

> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>
>

---

From: Vijay IETF <[email-masked]>
Date: Sat, 21 Mar 2020 13:59:25 +0530

Hi Dick,

Thanks for the additional context for reasoning. My response inline.

On Sat, 21 Mar 2020 at 06:00, Dick Hardt <[email-masked]> wrote:

> <snip>
> surface and vulnerability of an implementation, ie a coding error.
I do not see how having a no default  implies all choices being equal. I am
missing the nuance here.

The +1 for xyz rationale was to favor implementations that have the freedom
to implement what they see fit and still be "compliant" with the protocol.
I am not a fan of bloated general purpose software implementations, so I
don't have much to comment on that. Sorry.

---
Vijay

---

From: Dick Hardt <[email-masked]>
Date: Sat, 21 Mar 2020 10:21:44 -0700

Hi Vijay

Thanks for asking for clarification.

If there is no default or minimum to implement (MTI) requirement, then for
interop to be guaranteed between a client and an AS, one of the parties
will need to support all of the choices since the other party could choose
to support only one of the choices. In this work, we have tended to push
complexity to the AS, so the AS would need to implement all choices to be
compliant.

If there is a default, then only the default MUST be implemented by both
parties to be compliant.

Of course, any bespoke implementation can do whatever they want.

While you may not personally be a fan of general purpose software, others
are, and as a group we need to anticipate the implications for all
implementors.

On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF <[email-masked]> wrote:

> I do not see how having a no default  implies all choices being equal. I
> am missing the nuance here.
>
> The +1 for xyz rationale was to favor implementations that have the
> freedom to implement what they see fit and still be "compliant" with the
> protocol. I am not a fan of bloated general purpose software
> implementations, so I don't have much to comment on that. Sorry.
>
> ---
> Vijay
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Mar 2020 13:58:50 -0400

Dick,

I think there’s a big difference between a “default” and “MTI”. If you mean that the protocol chooses one key proofing method as “MTI” for the AS, then I can maybe get behind that idea. I think the realm of MTI is something that we do need to decide as a group, but that goes for all of the various features and options in the protocol. I think OAuth 2 went too far into the “everything’s optional” world, but at the same time, we don’t want to go too far into the OAuth 1 world of “this is all mandatory because of one tiny use case”. 

Also, an observation - if we mandate discovery as you’ve proposed in XAuth, then doesn’t the argument for any MTI fall a little flat? Since a client can discover which methods are available, a smarter client can discover and configure itself based on that set of options. 

I contend that that clients, even general purpose ones, aren’t going to be very smart in that regard. I think it’s vanishingly rare for a piece of client software in the OAuth 2 world to call the discovery document and change which authentication method it’s going to use. Instead, this tends to be driven by the developer who’s configured the client software library to behave in a specific way. I think we’ll continue to see that pattern here with TxAuth, especially as things go to embedded systems that get hardcoded to work in one specific way.

 — Justin

> On Mar 21, 2020, at 1:21 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hi Vijay
> 
> If there is no default or minimum to implement (MTI) requirement, then for interop to be guaranteed between a client and an AS, one of the parties will need to support all of the choices since the other party could choose to support only one of the choices. In this work, we have tended to push complexity to the AS, so the AS would need to implement all choices to be compliant. 
> 
> If there is a default, then only the default MUST be implemented by both parties to be compliant.
> 
> While you may not personally be a fan of general purpose software, others are, and as a group we need to anticipate the implications for all implementors.
> 
> 
> 
> 
> 
> 
> On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dick,
> 
> On Sat, 21 Mar 2020 at 06:00, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> <snip> 
> If all choices are equal (no default), then ALL the choices have to be implemented in a general purpose implementation, which increases the attack surface and vulnerability of an implementation, ie a coding error.
> 
> 
> I do not see how having a no default  implies all choices being equal. I am missing the nuance here. 
> 
> The +1 for xyz rationale was to favor implementations that have the freedom to implement what they see fit and still be "compliant" with the protocol. I am not a fan of bloated general purpose software implementations, so I don't have much to comment on that. Sorry.
>  
> ---
> Vijay

---

From: Vijay IETF <[email-masked]>
Date: Sat, 21 Mar 2020 23:33:02 +0530

Hi Dick,

Thanks. I think I understand the concern now. Response inline.

> If there is a default, then only the default MUST be implemented by both

I get it.

IMHO, your concern if it were to be the case is a lazy/inefficient way to
handle/attain interop compliance. I believe there is another way. We could
take inspiration from [Bluetooth Profiles](
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles). Each profile
could then specify the defaults that client and AS need to agree on.

> are, and as a group we need to anticipate the implications for all
I hear you. I just didn't have any better way to state my bias towards
XYZ's rationale in this instance. And I don't agree with a "global" default
being the normative recommendation.

---
Vijay

---

From: Dick Hardt <[email-masked]>
Date: Sat, 21 Mar 2020 11:35:20 -0700

Discovery lets the client know what other mechanisms are available besides
the MTI mechanism.

If there is no MTI, then there is no interop unless ALL mechanisms are
implemented independent of discovery.

On Sat, Mar 21, 2020 at 10:58 AM Justin Richer <[email-masked]> wrote:

> Dick,
>
> I think there’s a big difference between a “default” and “MTI”. If you
> mean that the protocol chooses one key proofing method as “MTI” for the AS,
> then I can maybe get behind that idea. I think the realm of MTI is
> something that we do need to decide as a group, but that goes for all of
> the various features and options in the protocol. I think OAuth 2 went too
> far into the “everything’s optional” world, but at the same time, we don’t
> want to go too far into the OAuth 1 world of “this is all mandatory because
> of one tiny use case”.
>
> Also, an observation - if we mandate discovery as you’ve proposed in
> XAuth, then doesn’t the argument for any MTI fall a little flat? Since a
> client can discover which methods are available, a smarter client can
> discover and configure itself based on that set of options.
>
> I contend that that clients, even general purpose ones, aren’t going to be
> very smart in that regard. I think it’s vanishingly rare for a piece of
> client software in the OAuth 2 world to call the discovery document and
> change which authentication method it’s going to use. Instead, this tends
> to be driven by the developer who’s configured the client software library
> to behave in a specific way. I think we’ll continue to see that pattern
> here with TxAuth, especially as things go to embedded systems that get
> hardcoded to work in one specific way.
>
>  — Justin
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 21 Mar 2020 11:46:03 -0700

Hi Vijay

Profiles are needed for *frameworks*, since no interop is required -- both
parties need to support the same profile to interop.

The current charter is developing a *protocol*, which requires interop.

For example, SCIM does not specify which mechanism to use for the client to
authenticate, which makes SCIM deployments more challenging to setup. I
started the FastFed WG in the OpenID Foundation to deal with getting
enterprise federations setup because there is no MTI, and missing discovery
mechanisms.

I hear your concerns for constrained environments of not wanting any more
code than is needed, and that a given mechanism that is the better choice
for mobile and PCs may be problematic for a constrained environment.

On Sat, Mar 21, 2020 at 11:03 AM Vijay IETF <[email-masked]> wrote:

>> If there is no default or minimum to implement (MTI) requirement, then
>> for interop to be guaranteed between a client and an AS, one of the parties

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Mar 2020 20:24:03 +0200

Moreover, even if we have an MTI (which I support for the reasons Dick pointed out), a particular *deployment* may not support it, i.e. it may be disabled by the AS. “Must implement” does not mean “must use”.

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Saturday, March 21, 2020 at 20:36
To: Justin Richer <[email-masked]>
Cc: Vijay IETF <[email-masked]>, <[email-masked]>, David Skaife <[email-masked]>
Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession

Discovery lets the client know what other mechanisms are available besides the MTI mechanism. 

If there is no MTI, then there is no interop unless ALL mechanisms are implemented independent of discovery.

Dick,

 — Justin

Hi Vijay

 

 

Hi Dick,

<snip> 

 

---

Vijay

-- Txauth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth

---

From: Vijay IETF <[email-masked]>
Date: Tue, 24 Mar 2020 01:56:14 +0530

Hi Dick,

Bluetooth in my mind is a protocol. And it has profiles for various
applications. I was merely suggesting a way to satisfy different
applications (in various environments) of the client/server protocol
without having to specify a "global" default at the protocol layer that
*must* be implemented by all to be compliant.

Aside if two implementations of Bluetooth choose to implement the protocol,
say Link Management Protocol in the controller stack for instance
differently in a non-compliant manner, then profile or not there can be no
interop between those implementations.

So I am a bit lost on the distinction you make between frameworks and
protocols and using that to make the case to have a default for interop.

Your initial post in this series was to elicit preference among others. My
preference is for XYZ's rationale on this topic. I'll leave it there :-)

Cheers!
---
Vijay

On Sun, 22 Mar 2020 at 00:16, Dick Hardt <[email-masked]> wrote:

> Hi Vijay
>
> Profiles are needed for *frameworks*, since no interop is required --
> both parties need to support the same profile to interop.
>
> For example, SCIM does not specify which mechanism to use for the client
> to authenticate, which makes SCIM deployments more challenging to setup. I
>>> While you may not personally be a fan of general purpose software,
>>> others are, and as a group we need to anticipate the implications for all
>>> implementors.
>>>
>>>
>>>