Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

[Brian Campbell]

inline below

On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman  wrote:

> There are some extra things we could do if we attached type-specific
> semantics to the matching (e.g. DNS wildcarding etc), however I think
> that continuing to use the values as opaque identifiers would get us
> most of what we need while keeping things simple.
>

Agreed.


I am far from an authority here, but it is my understanding that one
> of the primary drivers in supporting SAN over Subject is that the
> values are strongly typed. While some of the advantages gained from
> this may be less useful in our own context, I feel that it make sense
> to keep the values separate and not overload a single value.


I'm likewise no authority but have a similar understanding. Because the
advantages of a typed name are less clear in this context is why I've been
wanting to simplify with an overloaded parameter. But that's probably
ultimately a bad idea. So yeah, I'm agreeing that separating the types is
the way to go.


Whether
> that means dedicated metadata parameters or a structured parameter
> value, I am not sure what the tradeoffs would be, but both options
> sound suitable to me.
>

Seems like it's largely an esthetic thing but perhaps the benefits or
drawbacks of one over the other will become more apparent as we dig into it
more.

Great. I will work on some sample text since it sounds like that would
> be generally helpful
>

I think it would, yes. Thank you!

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

[Brian Campbell]

Sure, I think they could be treated as different different
client_auth_methods. But there is a lot more commonality than differences
to the point where I think it makes sense to keep it all in a single
document and under a single client auth method with just the variation on
which name is being used.

On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer  wrote:

> Would it make sense for these to be a different client_auth_method
> entirely? Much the same way that we have private_key_jwt and
> client_secret_jwt today, both of which use the JWT assertion framework but
> have very different keying and security assumptions. In the same way, here
> you’re still validating the cert but the means by which it’s validated is
> different, so the auth method is arguably not going to benefit from being
> overloaded. Caveat, I’ve not built out a system using SANs in any
> meaningful way.
>
> If we were to do that, this draft could go forward as-is (since it’s
> fairly done in my opinion) and a new document could better define the
> semantics for the various SAN types, but while building on the framework
> and concepts listed in here.
>
> — Justin
>
> On Nov 6, 2018, at 3:52 PM, Evan Gilman  wrote:
>
> Response(s) inline
>
> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden 
> wrote:
>
>
> Is there an intention that any semantics are attached to the SAN being a
> URI or DNS name or IP or ...? Or is it still intended to be an opaque
> identifier?
>
>
> There are some extra things we could do if we attached type-specific
> semantics to the matching (e.g. DNS wildcarding etc), however I think
> that continuing to use the values as opaque identifiers would get us
> most of what we need while keeping things simple.
>
> On 6 Nov 2018, at 01:55, Brian Campbell <
> bcampbell=40pingidentity@dmarc.ietf.org> wrote:
>
> Thanks Evan for bringing this to the WG's attention. More or less the same
> question/issue was raised yesterday in the area director's review of the
> document as well. I plan to bring this up as a discussion item in the
> meeting today. But my sense from some early discussions is that there is
> likely to be (rough) consensus to make some change in order to allow a SAN
> to be specified as the certificate subject identifier in the PKI client
> auth mode. We'll need to figure out the specifics of how that works. I
> don't think there are significant drawbacks to extending the number of
> client registration metadata parameters per se. I guess I've just been
> attracted to the idea of overloading the existing value because that felt
> like maybe a less invasive change. But perhaps that's shortsighted. And
> there's nothing inherently wrong with additional client metadata parameters.
>
> I don't know if we could get away with a single new parameter that could
> carry the value for any SAN type. Something like, { ...
> "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I
> feel like that'd probably be okay but in theory there's the potential for
> confusion of the value across different types. So probably there's a need
> to indicate the SAN type too. Either with more client metadata parameters
> like tls_client_auth_san_uir, tls_client_auth_san_email,
> tls_client_auth_san_ip, etc. or maybe with a structured value of some sort
> like {... "tls_client_auth_san": {"type":"URI", "value":"
> spiffe://trust-domain/path"} ... }. And then deciding which types to
> support and if/how to allow for the extensible types.
>
>
> I am far from an authority here, but it is my understanding that one
> of the primary drivers in supporting SAN over Subject is that the
> values are strongly typed. While some of the advantages gained from
> this may be less useful in our own context, I feel that it make sense
> to keep the values separate and not overload a single value. Whether
> that means dedicated metadata parameters or a structured parameter
> value, I am not sure what the tradeoffs would be, but both options
> sound suitable to me.
>
> Anyway, those are just some thoughts on it. And it'll be discussed more
> today. Suggested/proposed text is always helpful though (even if it's not
> used directly it can help move the conversation forward and/or help
> editor(s) to have prospective wording).
>
>
> Great. I will work on some sample text since it sounds like that would
> be generally helpful
>
> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman  wrote:
>
>
> Hello everyone..
>
> Very excited to see this draft. It helps tremendously in addressing
> use cases around oauth client management in machine-to-machine
> scenarios. Particularly, the PKI authentication method.
>
> In reviewing the document, I noticed that the only supported method
> for identifying a client using the PKI authentication method is by
> referencing its distinguished name. This caught me a bit by surprise -
> many newer projects aimed at automating X.509 issuance in the
> datacenter utilize SAN extensions rather than distinguished name in
> order to encode ide

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Joseph Heenan]

Hi Aaron,

Thanks for putting this document together, I think this kind of guidance is 
invaluable.

It may be worth slightly rewording 7.2 as it may encourage a growing 
misconception that all native apps must be public clients. With many devices 
now having embedded HSMs, we’ve seen increasing interest in mobile apps being 
dynamically (per-install) registered oauth2 private clients, and that model has 
a lot of advantages. (I’m not sure if we might see a similar model evolving for 
web apps.) 

The BCP for native apps does allow 
this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph





> On 6 Nov 2018, at 10:13, Aaron Parecki  wrote:
> 
> Thanks Hannes,
> 
> Since I wasn't able to give an intro during the meeting today, I'd like to 
> share a little more context about this here as well.
> 
> At the Internet Identity Workshop in Mountain View last week, I led a session 
> to collect feedback on recommendations for OAuth for browser based apps. 
> During the session, we came up with a list of several points based on the 
> collective experience of the attendees. I then tried to address all those 
> points in this draft.
> 
> The goal of this is not to specify any new behavior, but rather to limit the 
> possibilities that the existing OAuth specs provide, to ensure a secure 
> implementation in browser based apps.
> 
> Thanks in advance for your review and feedback!
> 
> Aaron Parecki
> aaronpk.com 
> 
> 
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig  > wrote:
> Hi all,
> 
> Today we were not able to talk about 
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for 
> Browser-Based Apps".
> 
> Aaron put a few slides together, which can be found here:
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>  
> 
> 
> Your review of this new draft is highly appreciated.
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> -- 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Simon Moffatt]

It's an interesting topic.  I think there is a definitely a set of
options and considerations for this.  Namely operational.  For example,
hugely popular mobile apps (multi-million downloads across different
OS's) using dynamic reg with per-instance private creds requires the AS
to be able to store and index those client profiles easily.  Smaller
scale custom built authorization servers are not necessarily going to be
able to handle that - hence the popularity of assuming everything is
generic and public coupled with PKCE.

On the other hand, if a less popular first-party app used internally for
employees for example, might well go for secure element integration on
the appropriate mobile OS.

So, I guess options are needed and best practice for a few subtly
different scenarios.

Regards

Simon



On 07/11/18 15:20, Joseph Heenan wrote:
> Hi Aaron,
>
> Thanks for putting this document together, I think this kind of
> guidance is invaluable.
>
> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in
> mobile apps being dynamically (per-install) registered oauth2 private
> clients, and that model has a lot of advantages. (I’m not sure if we
> might see a similar model evolving for web apps.) 
>
> The BCP for native apps does allow
> this:https://tools.ietf.org/html/rfc8252#section-8.4
>
> Cheers,
>
> Joseph
>
>
>
>
>
>> On 6 Nov 2018, at 10:13, Aaron Parecki > > wrote:
>>
>> Thanks Hannes,
>>
>> Since I wasn't able to give an intro during the meeting today, I'd
>> like to share a little more context about this here as well.
>>
>> At the Internet Identity Workshop in Mountain View last week, I led a
>> session to collect feedback on recommendations for OAuth for browser
>> based apps. During the session, we came up with a list of several
>> points based on the collective experience of the attendees. I then
>> tried to address all those points in this draft.
>>
>> The goal of this is not to specify any new behavior, but rather to
>> limit the possibilities that the existing OAuth specs provide, to
>> ensure a secure implementation in browser based apps.
>>
>> Thanks in advance for your review and feedback!
>>
>> Aaron Parecki
>> aaronpk.com 
>>
>>
>>
>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig
>> mailto:hannes.tschofe...@arm.com>> wrote:
>>
>> Hi all,
>>
>> Today we were not able to talk about
>> draft-parecki-oauth-browser-based-apps-00, which describes 
>> "OAuth 2.0 for Browser-Based Apps".
>>
>> Aaron put a few slides together, which can be found here:
>> 
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>>
>> Your review of this new draft is highly appreciated.
>>
>> Ciao
>> Hannes
>> IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the
>> intended recipient, please notify the sender immediately and do
>> not disclose the contents to any other person, use it for any
>> purpose, or store or copy the information in any medium. Thank you.
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> -- 
>> 
>> Aaron Parecki
>> aaronparecki.com 
>> @aaronpk 
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock   *Simon Moffatt*
Technical Director Product Management  |  ForgeRock
*t* (44) 7903 347 240  |  *e* simon.moff...@forgerock.com

*twitter* @simonmoffatt  |  *web* www.forgerock.com




NOTICE: This message, including any attachments, may contain
confidential information. If you are not the intended recipient, please
advise the sender immediately and destroy all copies of this message and
any attachments. ForgeRock Ltd may monitor email traffic data and also
the content of email transmitted over its network for security purposes.
No employee or agent is authorized to conclude any binding agreement on
behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd
is a limited company registered in England and Wales; its registered
address is 60 Queen Square, Bristol, BS1 4JZ; and its registration
number is 7227664.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

> On Nov 7, 2018, at 9:08 AM, Simon Moffatt  wrote:
> 
> It's an interesting topic.  I think there is a definitely a set of options 
> and considerations for this.  Namely operational.  For example, hugely 
> popular mobile apps (multi-million downloads across different OS's) using 
> dynamic reg with per-instance private creds requires the AS to be able to 
> store and index those client profiles easily.  Smaller scale custom built 
> authorization servers are not necessarily going to be able to handle that - 
> hence the popularity of assuming everything is generic and public coupled 
> with PKCE.
> 
Having unique client identifiers does provide some niceties. As examples: it 
gives a user a chance to administer/revoke those clients, and it gives the AS 
an opportunity to do behavioral analysis with a per-client rather than per-user 
granularity.

It also allows you to track user-granted consent per client. There are very 
limited options (really, just id_token_hint from OIDC) to indicate when hitting 
the authorization endpoint that you have prior consent.

In any case, the ability to work with public clients or the need to do dynamic 
client registration is AS policy, not something clients typically have the 
power to decide.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-13.txt

[George Fletcher]

Have we considered replacing the device_code logic with PKCE now that 
PKCE exists? At the time we started this spec I'm not sure PKCE was 
around, but now that it exists and is required (practically speaking) 
for mobile apps, should we look at using it instead of device_code to 
protect this flow?


I'm assuming that most of these devices can not protect secrets and 
hence are effectively "public" clients.


If this has already been considered and I missed it, I'm sorry for the 
noise :)


Thanks,
George

On 10/19/18 5:14 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

 Title   : OAuth 2.0 Device Flow for Browserless and Input 
Constrained Devices
 Authors : William Denniss
   John Bradley
   Michael B. Jones
   Hannes Tschofenig
Filename: draft-ietf-oauth-device-flow-13.txt
Pages   : 21
Date: 2018-10-19

Abstract:
This OAuth 2.0 authorization flow is designed for devices that either
lack a browser to perform a user-agent based OAuth flow, or are
input-constrained to the extent that requiring the user to input a
lot of text (like their credentials to authenticate with the
authorization server) is impractical.  It enables OAuth clients on
such devices (like smart TVs, media consoles, digital picture frames,
and printers) to obtain user authorization to access protected
resources without using an on-device user-agent, provided that they
have an Internet connection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AS Discovery in Distributed Draft

[George Fletcher]

Related to this discussion of AS discovery... what is the value of using 
the Link response header over just returning the variables in the 
WWW-Authenticate header? Could we not use...


WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", 
error="invalid_token", rs_uri="https://api.example.com/resource";, 
as_uri="https://as1.example.com,https://as2.example.com";


Thanks,
George

On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight I brought up a response to the question of 
whether to have full URL or plain issuer for the auth server in the RS 
response’s header. My suggestion was that we have two different 
parameters to the header to represent the AS: one of them being the 
full URL (as_uri) and one of them being the issuer to be constructed 
somehow (as_issuer). I ran into a similar problem on a system that I 
built last year where all of our servers had discovery documents but 
not all of them were easily constructed from an issuer style URL 
(using OIDC patterns anyway). So we solved it by having two different 
variables. If the full URL was set, we used that; if it wasn’t, we 
tried the issuer; if neither was set we didn’t do any discovery.


I’m sensitive to Torsten’s concerns about complexity, but I think this 
is a simple and deterministic solution that sidesteps much of the 
issue. No pun intended.


— Justin



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AS Discovery in Distributed Draft

[Phil Hunt]

I’m seeing broader need for discovery of OAuth infrastructure for APIs in 
general now that APIs are being deployed by many parties:
* based on a standard (e.g. SCIM, IMAP, SMTP)
* Implemented in open source and deployed by many (e.g. K8S and its various 
components).
* Services like streaming (Kakfa) 
* Serverless/microservices APIs

I agree, that having some process where the RS can indicate to a client where 
to go do discovery would be helpful.  The issue is somewhat complex and we have 
talked about some of this before. For example, an RS may have multiple AS’s it 
accepts tokens from. Does the RS indicate many or specific discovery endpoint 
that may or may not involve registration (in order to determine the appropriate 
AS)?  How is the metadata secured?  How do we ensure we haven’t opened up an 
automated attack point (e.g. a MITM’d RS gives a client false discovery 
information).

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com phil.h...@oracle.com 


> On Nov 7, 2018, at 1:08 PM, George Fletcher 
>  wrote:
> 
> Related to this discussion of AS discovery... what is the value of using the 
> Link response header over just returning the variables in the 
> WWW-Authenticate header? Could we not use...
> 
> WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", 
> error="invalid_token", rs_uri="https://api.example.com/resource"; 
> , 
> as_uri="https://as1.example.com,https://as2.example.com"; 
> 
> 
> Thanks,
> George
> 
> On 11/6/18 12:19 AM, Justin P Richer wrote:
>> In the meeting tonight I brought up a response to the question of whether to 
>> have full URL or plain issuer for the auth server in the RS response’s 
>> header. My suggestion was that we have two different parameters to the 
>> header to represent the AS: one of them being the full URL (as_uri) and one 
>> of them being the issuer to be constructed somehow (as_issuer). I ran into a 
>> similar problem on a system that I built last year where all of our servers 
>> had discovery documents but not all of them were easily constructed from an 
>> issuer style URL (using OIDC patterns anyway). So we solved it by having two 
>> different variables. If the full URL was set, we used that; if it wasn’t, we 
>> tried the issuer; if neither was set we didn’t do any discovery.
>> 
>> I’m sensitive to Torsten’s concerns about complexity, but I think this is a 
>> simple and deterministic solution that sidesteps much of the issue. No pun 
>> intended.
>> 
>> — Justin
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth