Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

[Brian Campbell]

Thought I was looking to get a sense of preference from the WG, I tend to
lean the same way as John. The issuer constraint is an optional thing
that's applied per client and the only use I can see in supporting more
than one is for the client to change issuers without updating it's
registration/configuration.

On Sat, May 20, 2017 at 8:44 AM, John Bradley  wrote:

> +1 for “tls_client_auth_root_dn"
>
> On making it an array, I think that adds complexity for little gain, and
> perhaps introduces new trust issues.
>
> I think it should be one trusted root or all the trusted roots.  If you
> only trust 5 then configure that in the AS.
>
> An array seems only useful where the client has a cert from x but may want
> to get the next one from y and not re-register.
> I think if the client or federation operator is locking itself down to
> specific issuers one per client should be fine.
> I expect that in most cases the issuer will need to be in the trust store
> of the AS anyway so this is just pinning the cert to one of a limited set.
>
> John B.
>
> On May 15, 2017, at 2:42 PM, Brian Campbell 
> wrote:
>
> I'll add text/clarification that the DN metadata fields being RFC4514
> string representations of DNs in the next draft.
>
> Given that this is a profile of use and the metadata fields are just one
> way to express the binding of certificate and client, and after thinking
> about it some more and not wanting to introduce too many variations, I feel
> that keeping tls_client_auth_subject_dn as the subject distinguished name
> of the client certificate is more straightforward and sufficient for this
> case.
>
> Is there rough consensus to change "tls_client_auth_issuer_dn" to
> "tls_client_auth_root_dn" as was suggested? The latter name makes sense to
> me but I don't want to make that change without a little more input or
> buy-in from the WG. So please respond one way or the other, if you've got
> an opinion.
>
> Similarly I'm looking for some rough consensus around if a single
> root/issuer is sufficient in the metadata before potentially making any
> changes. Should "tls_client_auth_issuer/root_dn" remain a single DN
> string value or should it be an array allowing for more than one?
>
>
>
> On Fri, Apr 21, 2017 at 6:18 PM, John Bradley  wrote:
>
>> I agree with Brian.
>>
>> Trying to do anything with PKIX opens up cans of worms.  One of the
>> reasons we have resisted to this point.
>>
>> However there are server to server use cases that legitimately need this.
>>
>> I agree that in general DN is a mess, I suspect that telling people to
>> directly use the DER encoded version wont fly, so my thought was to use the
>> RFC 4514 string representation that most tools produce.
>>
>> We did talk about subject alt DNS Names, however those may not be present
>> in eIDAS certificates that some people may need to use for legal reasons,
>> or if it is present it might be an email.
>>
>> I suspect that users of this will fall into two camps.  One that has a
>> small set of trusted CA that are configured out of band and any certificate
>> from those roots with the correct DN is OK.
>>
>> The other group will be trying to do something more dynamic with SSL
>> server certs (May or may not be EV)   I could see those people preferring
>> DNS Name subject alt, or using JWKS to publish there certs.
>>
>> The problem is finding the right balance of flexibility without too many
>> options to confuse people.
>>
>> I am inclined towards DN for those that are willing to suffer the pain,
>> and JWKS_uri for everyone else.   One advantage of the JWKS_URI approach is
>> that self signed certs should work just fine, that is something that the
>> R&E people will want if they use this.
>>
>> For most proof of possession we should be promoting token binding as the
>> most flexible approach as it also works with mobile without per instance
>> registration.
>>
>> John B.
>>
>>
>> On Apr 21, 2017, at 7:41 PM, Brian Campbell 
>> wrote:
>>
>> Thanks, James, for the adoption support as well as the review and
>> comments. I've tried to respond to the comments inline below.
>>
>> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <
>> james.h.man...@team.telstra.com> wrote:
>>
>>> I support adoption of draft-campbell-oauth-mtls.
>>>
>>> Now some comments on the doc:
>>>
>>> 1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified.
>>> Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]?
>>> Perhaps a base64url-encoding of a DER-encoded DN? It would actually be
>>> better to allow any subjectAltName to be specified, instead of a DN.
>>>
>>
>> How about calling it tls_client_auth_subject and defining it as a string
>> and allowing it to represent the expected subject which could be in the
>> cert as the subject DN or a subjectAltName? For Subject DN and DN
>> subjectAltNames it would be the "String Representation of Distinguished
>> Names" and an appropriate string for the other subjectAltName types (I'll
>> have to lo

[OAUTH-WG] Mirja Kühlewind's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-oauth-native-apps-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/



--
COMMENT:
--

Quick question just to double-check: should this document update RFC6749?


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

Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

[William Denniss]

Thanks for your review Zitao!

Version 12 addresses your comments. Detailed responses below:

On Sun, May 21, 2017 at 8:05 PM, wangzitao  wrote:

> Reviewer: Zitao Wang (Michael)
>
> Review result: Has Nits
>
>
>
> I have reviewed this document as part of the Operational
> directorate’s ongoing effort to review all IETF documents being processed
> by the IESG.  These comments were written with the intent of improving the
> operational aspects of the IETF drafts. Comments that are not addressed in
> last call may be included in AD reviews during the IESG review.  Document
> editors and WG chairs should treat these comments just like any other last
> call comments.
>
>
>
> Document reviewed:  draft-ietf-oauth-native-apps-10
>
>
>
> Summary:
>
>
>
> OAuth 2.0 authorization requests from native apps should only be made
>
> through external user-agents, primarily the user’s browser. This
>
> specification details the security and usability reasons why this is
>
> the case, and how native apps and authorization servers can implement
>
> this best practice.
>
>
>
> I think the document is written very clear, except some small nits:
>
> Page 3: The last sentence of introduction-- “This practice is also
> known as the AppAuth pattern”.
>
> I suggest adding a reference to explain the AppAuth pattern.
>
>
Done


> Page 3: Terminology -- "OAuth".
>
> I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.
> In this document, OAuth refers to OAuth 2.0 [RFC6749].
>
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization Framework
[RFC6749]."

The phrase "Web Authorization (OAuth) protocol" only seems to appear in our
WG Charter, and not general usage
.


> Page 4: Terminology -- "web-view"  A web browser UI component.
>
> Does it mean "User Information"?  Suggest expanding this abbreviation.
>
>
Done.


> Page 5: Figure 1.   Does the browser and authorization endpoint are
> some kinds of "external user-agent"? Suggest describing it more clearly.
>

Now states:
"illustrates the interaction of the native app with a browser
external user-agent to authorize the user. "

Page   9:   PKCE [RFC7636] details how this limitation can be used to
> execute a code interception attack (see Figure 1).
>
> Does the Figure 1 means “Figure 1 of RFC7636”?
>

Good catch. I delete the figure reference, since the entire spec talks
about this attack, which is likely sufficient.


>
> Page10: However, as the Implicit Flow cannot be protected by PKCE
>
> Seems here, the reference be omitted.
>

Added.


> A run of idnits revealed no errors, flaws. There were 1 warning and 1 
> comments though
>
>
>
>   == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
>
>  document.
>
>
>
>
I ran it myself with verbose output, and got:

tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN
'com.example.app' in position 5; this doesn't match RFC 2606's
suggested ".example" or ".example.(com|org|net)".


We are actually using a RFC2606 domain name here, but in reverse domain
name notation which is causing this warning.

No changes required.


>   Miscellaneous warnings:
>
>   
>
>
>
>   -- The document date (April 26, 2017) is 14 days in the past.  Is this
>
>  intentional?
>
>
>
>
>
>   Checking references for intended status: Best Current Practice
>
>   
>
>
>
>  (See RFCs 3967 and 4897 for information about using normative references
>
>  to lower-maturity documents in RFCs)
>
>
>
>  No issues found here.
>
>
>
>  Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
>
>
>
>
>
> ___
>
> OPS-DIR mailing list
>
> ops-...@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-oauth-native-apps-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/



--
COMMENT:
--

General
===
The thesis of this document seems to be that bad actors can access
authentication information that gives them broader or more durable
authorization than is intended; and appears to want to mitigate this
predominantly with a single normative statement in a BCP telling
potential bad actors to stop doing the one thing that enables their
shenanigans.  For those familiar with the animated series "The Tick," it
recalls the titular character yelling "Hey! You in the pumps! I say to
you: stop being bad!" -- which, of course, is insufficient to achieve the
desired effect.

I see that there is nevertheless "strong consensus" to publish the
document; in which case, I would encourage somewhat more detail around
what the rest of the ecosystem -- and the authentication server in
particular -- can do to mitigate the ability of such bad actors.
Specifically, section 8.1 has a rather hand-wavy suggestion that
authorization endpoints "MAY take steps to detect and block authorization
requests in embedded user agents," without offering up how this might be
done. The problem is that that the naïve ways of doing this (UA strings?)
are going to be easy to circumvent, and the more advanced ones (say,
instructing users to log in using a non-OAuth flow if the auth endpoint
detects absolutely no cookies associated with its origin) will have
interactions that probably warrant discussion in this document. (For
example, such an approach -- while potentially effective -- would
interact very poorly with the "SSO mode" described in section B.3;
although I think that recommending the use of "SSO mode" should be
removed for other reasons, described below).



Specific comments follow

The terminology section makes distinctions about cookie handling and
content access in generic definitions (embedded versus external UAs, for
example) but doesn't do the same for specific technologies. It is
probably worthwhile noting that the "in-app browser tab" prevents apps
from accessing cookies and content, while the "web-view" does not (I had
to infer these facts from statements much later in the document).

Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While
I'm sympathetic to the deployment challenges inherent in getting entire
network paths to upgrade to IPv6, this text discusses loopback
exclusively, which means that only the local operating system needs to
support IPv6. Since all modern operating systems have supported IPv6 for
well over a decade, I suggest that the use of IPv4 addresses for this
purpose should be explicitly deprecated, so as to avoid unnecessary
transition pain in the future. Minimally, the example needs to be
replaced or supplemented with an IPv6 example, as per
: "We recommend
that existing standards be reviewed to ensure they... use IPv6
examples."

Section 8.1 makes the statement that "Loopback IP based redirect URIs may
be susceptible to interception by other apps listening on the same
loopback interface." That's not how TCP listener sockets work: for any
given IP address, they guarantee single-process access to a port at any
one time. (Exceptions would include processes with root access, but an
attacking process with that level of access is going to be impossible to
defend against). While mostly harmless, the statement appears to be false
on its face, and should be removed or clarified.

Section 8.4 indicates that loopback redirect URIs are allowed to vary
from their registered value in port number only. If you decide not to
deprecate the use of IPv4 loopback, I imagine that servers should also
treat [::1] identical to 127.0.01 for this purpose as well.

Section 8.7 claims that users are likely to be suspicious of a sign-in
request when they should have already been signed in, and goes on to
claim that they will distinguish between completely-logged-out states and
logged-in-but-needing-reauth states, and may even take evasive action
based on associated suspicion. Based on what I know of user research for
security indicators, the chances of these statements being true for any
non-trivial portion of any user population is basically zero. I propose
that this section simply highlight that this is effectively an
intractable problem from 

Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

[wangzitao]

Cool! This changes/explains make sense to me.

Best Regards!
-Michael

发件人: William Denniss [mailto:wdenn...@google.com]
发送时间: 2017年5月23日 3:09
收件人: wangzitao
抄送: ops-...@ietf.org; oauth@ietf.org; 
draft-ietf-oauth-native-apps@ietf.org; i...@ietf.org
主题: Re: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

Thanks for your review Zitao!

Version 12 addresses your comments. Detailed responses below:

On Sun, May 21, 2017 at 8:05 PM, wangzitao 
mailto:wangzi...@huawei.com>> wrote:

Reviewer: Zitao Wang (Michael)

Review result: Has Nits



I have reviewed this document as part of the Operational directorate’s ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.



Document reviewed:  draft-ietf-oauth-native-apps-10



Summary:


OAuth 2.0 authorization requests from native apps should only be made
through external user-agents, primarily the user’s browser. This
specification details the security and usability reasons why this is
the case, and how native apps and authorization servers can implement

this best practice.


I think the document is written very clear, except some small nits:

Page 3: The last sentence of introduction-- “This practice is also known as 
the AppAuth pattern”.

I suggest adding a reference to explain the AppAuth pattern.

Done


Page 3: Terminology -- "OAuth".

I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.  In 
this document, OAuth refers to OAuth 2.0 [RFC6749].
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization Framework 
[RFC6749]."

The phrase "Web Authorization (OAuth) protocol" only seems to appear in our WG 
Charter, and not general 
usage.


Page 4: Terminology -- "web-view"  A web browser UI component.

Does it mean "User Information"?  Suggest expanding this abbreviation.

Done.


Page 5: Figure 1.   Does the browser and authorization endpoint are some 
kinds of "external user-agent"? Suggest describing it more clearly.

Now states:
"illustrates the interaction of the native app with a browser
external user-agent to authorize the user. "

Page   9:   PKCE [RFC7636] details how this limitation can be used to execute a 
code interception attack (see Figure 1).

Does the Figure 1 means “Figure 1 of RFC7636”?

Good catch. I delete the figure reference, since the entire spec talks about 
this attack, which is likely sufficient.


Page10: However, as the Implicit Flow cannot be protected by PKCE
Seems here, the reference be omitted.

Added.


A run of idnits revealed no errors, flaws. There were 1 warning and 1 comments 
though



  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the

 document.



I ran it myself with verbose output, and got:

tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN 
'com.example.app' in position 5; this doesn't match RFC 2606's suggested 
".example" or ".example.(com|org|net)".

We are actually using a RFC2606 domain name here, but in reverse domain name 
notation which is causing this warning.

No changes required.


  Miscellaneous warnings:

  



  -- The document date (April 26, 2017) is 14 days in the past.  Is this

 intentional?





  Checking references for intended status: Best Current Practice

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



 No issues found here.



 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).





___

OPS-DIR mailing list

ops-...@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir


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