[OAUTH-WG] Genart last call review of draft-ietf-oauth-native-apps-10

[Elwyn Davies]

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-native-apps-10
Reviewer: Elwyn Davies
Review Date: 2017-05-15
IETF LC End Date: 2017-05-16
IESG Telechat date: 2017-05-25

Summary: Almost ready.  A couple of simple minor issues could do with
addressing.

Major issues:
None.

Minor issues:
s3: "browser":  The browser that acts as the Oauth user-agent is
conflated with the user's choice of default browser.  Firstly this is
not something that is discussed in RFC 6749.  Secondly, the concept of
'default browser' would normally be thought of by users as the browser
that is used to display the content associated with hyperlinks rather
than providing Oauth services.  I suggest that the implication in the
body of the draft that 'the browser' is the user selected or system
selected default browser needs to be at least discussed explicitly
rather than buried in the terminology definitions in s3.  I wonder
whether ths connection is something that should be made by a separate
OS setting or a setting in each native app rather than conflated with
the default browser.  The term "designated browser" might be useful.
In all cases there might be secuity implications if a bad actor could
subvert the designated browser setting.

s8.1, Requirement of use of PKCE in some cases:  This strict
requirement really needs to be introduced in the body of the
discussion rather than buried in the seurity considerations.

Nits/editorial comments: 

General: s/i.e./i.e.,/ (3 places)

Title and Abstract: s/apps/applications/g  (uses before we get to
terminology in s3)

s1, para 1:  Suggest the following to make it clear that the
definition is in RFC 6749 rather than here.
OLD:
 The OAuth 2.0 [RFC6749] authorization framework documents two
approaches in Section 9 for native apps to interact with the
authorization endpoint: an embedded user-agent, and an external user-
agent.
NEW:
The OAuth 2.0 [RFC6749] authorization framework defines "native
applications" in Section 9 of RFC 6749 (see also Section 3 below) and
documents two approaches by whch they can interact with the
authorization endpoint: an embedded user-agent, and an external
user-agent. 
END 

s1, para 2: s/apps/applications/(2places) .  For second case: s/native
apps/native applications (shortened to "native apps" or just "apps"
hereafter)/

s3, "native app": s/app/application/g in the definition.  After that
in the document "[native] app" is fine except for the definitions
mentioned in the next comment. Worth repeating the link to Section 9
of RFC 6749.

s3, All definitions after "app"; s/app/application/g in the
definitions as these are not restricted to (native) apps as defined
here.

s3, "embedded user-agent": s/modify/modifyng/

s4, last para: s/emcompasses/encompasses/

s4, last para: s/inter-process/inter-app/ (since this term is
defined)

s4, last para: Might be worth pointing to the 'SHOULD' about client
type assumptions in s2.1 of RFC 6749 withe reference to servers that
do make assumptions.

s4.1, para below figure 1: s/system browser/browser/ (or maybe
"designated browser").

s5, paras 1 and  2: Reword to clarify and remove 'we gain' usage (not
allowed in RFCs):
OLD:
   Just as URIs are used for OAuth 2.0 [RFC6749] on the web to
initiate
   the authorization request and return the authorization response to
   the requesting website, URIs can be used by native apps to
initiate
   the authorization request in the device's browser and return the
   response to the requesting native app.

   By applying the same principles from the web to native apps, we
gain
   benefits seen on the web, like the usability of a single sign-on
   session and the security of a separate authentication context.  It
   also reduces the implementation complexity by reusing similar
flows
   as the web, and increases interoperability by relying on
standards-
   based web flows that are not specific to a particular platform.
NEW:
   Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP protocol
on the web to initiate
   the authorization request and return the authorization response to
   the requesting website, URIs can be used by native apps to
initiate
   the authorization request in the device's browser and return the
   response to the requesting native app.

   By extending the techniques from the web to native apps, the
   benefits gained in the web context will also be reaped when using 
   OAuth with native apps; benefits include the usability of a single
sign-on
   session and the security of a separate authentication context.  Use
of
   the techniques also reduces implementation complexity by reusing
similar flows
   to those employ

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

[Brian Campbell]

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 look at what's there 'cause I don't know off hand and guidance or
> suggested text is always more than welcome).
>
>
>
>
>> 2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe
>> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too
>> easy to assume this pair refer to the issuer and subject fields of the cert.
>>
>
> The accompanying text tries to make it clear that it's the root issuer but
> the tls_client_auth_issuer_dn name can certainly be changed to
> tls_client_auth_root_dn or something along those lines, if folks think the
> name in -01 is liable to cause confusion?
>
>
>
> PKI chains can be complex so the expected root might not be such a stable
>> concept. For example, the Let's Encrypt CA chains to an ISRG Root and an
>> IdenTrust DST Root [https://letsencrypt.org/certificates/].
>>
>
> The goal was to provide a metadata field to express some constraint for
> what is kind of expected to be a common deployment of a number of entities
> participating in some OAuth API thing and are being issued certificates
> from a common issuer for the group of participants.
>
> Perhaps it should be an array of strings rather than a single value?
>
> Or do you have suggestions for s

Re: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK

[Adrian Imach]

Please unsubscribe me from your mailing list. Thank you ,

Adrian Imach

On 15 May 2017, at 09:52, Samuel Erdtman 
mailto:sam...@erdtman.se>> wrote:

In short this draft focuses on the C to AS connection and 
draft-gerdes-ace-dtls-authorize focuses on the C to RS connection.

This draft details on how to use RPK or PSK as client credentials to setup the 
(D)TLS between C and AS while draft-gerdes-ace-dtls-authorize provides details 
for how to use the RPK or PSK bound to an access token to setup the connection 
between C and RS.

//Samuel


On Sun, May 14, 2017 at 10:18 PM, Jim Schaad 
mailto:i...@augustcellars.com>> wrote:
How is this draft supposed to interact with draft-gerdes-ace-dtls-authorize?

Jim


From: Ace [mailto:ace-boun...@ietf.org] On Behalf 
Of Samuel Erdtman
Sent: Friday, May 12, 2017 1:03 AM
To: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>; ace 
mailto:a...@ietf.org>>
Cc: Ludwig Seitz mailto:ludwig.se...@ri.se>>
Subject: [Ace] New OAuth client credentials RPK and PSK

Hi ACE and OAuth WGs,
I and Ludwig submitted a new draft yesterday defining how to use Raw Public Key 
and Pre Shared Key with (D)TLS as OAuth client credentials, 
https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

We think this is valuable to the ACE work since the ACE framework is based on 
OAuth, but client credentials as defined in the OAuth framework are not the 
best match for embedded devices.
We think Raw Public Keys and Pre Shared Keys are more suitable credentials for 
embedded devices for the following reasons:
* Better security by binding to transport layer.
* If PSK DTLS is to be used a key need to be distributed any way, why not make 
use of it as credential.
* Client id and client secret accommodates for manual input by a humans. This 
does not scale well and requires some for of input device.
* Some/many devices will have crypto-hardware that can protect key material, to 
not use that possibility would be a waste.
* There are probably more reasons these was just the once on top of my head.

This is not the first resent initiative to create new client credential types, 
the OAuth WG adopted a similar draft for certificate based client credentials 
(https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That work is also 
valuable to ACE but not all devices will be able to work with certificates or 
even asymmetric cryptos .
Please review and comment.
Cheers
//Samuel


___
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] [Ace] New OAuth client credentials RPK and PSK

[Samuel Erdtman]

In short this draft focuses on the C to AS connection and
draft-gerdes-ace-dtls-authorize focuses on the C to RS connection.

This draft details on how to use RPK or PSK as client credentials to setup
the (D)TLS between C and AS while draft-gerdes-ace-dtls-authorize provides
details for how to use the RPK or PSK bound to an access token to setup the
connection between C and RS.

//Samuel


On Sun, May 14, 2017 at 10:18 PM, Jim Schaad  wrote:

> How is this draft supposed to interact with draft-gerdes-ace-dtls-
> authorize?
>
>
>
> Jim
>
>
>
>
>
> *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Samuel Erdtman
> *Sent:* Friday, May 12, 2017 1:03 AM
> *To:*  ; ace 
> *Cc:* Ludwig Seitz 
> *Subject:* [Ace] New OAuth client credentials RPK and PSK
>
>
>
> Hi ACE and OAuth WGs,
>
> I and Ludwig submitted a new draft yesterday defining how to use Raw
> Public Key and Pre Shared Key with (D)TLS as OAuth client credentials,
> https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.
>
>
>
> We think this is valuable to the ACE work since the ACE framework is based
> on OAuth, but client credentials as defined in the OAuth framework are not
> the best match for embedded devices.
>
> We think Raw Public Keys and Pre Shared Keys are more suitable credentials
> for embedded devices for the following reasons:
>
> * Better security by binding to transport layer.
>
> * If PSK DTLS is to be used a key need to be distributed any way, why not
> make use of it as credential.
>
> * Client id and client secret accommodates for manual input by a humans.
> This does not scale well and requires some for of input device.
>
> * Some/many devices will have crypto-hardware that can protect key
> material, to not use that possibility would be a waste.
>
> * There are probably more reasons these was just the once on top of my
> head.
>
>
>
> This is not the first resent initiative to create new client credential
> types, the OAuth WG adopted a similar draft for certificate based client
> credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html).
> That work is also valuable to ACE but not all devices will be able to work
> with certificates or even asymmetric cryptos .
>
> Please review and comment.
>
> Cheers
>
> //Samuel
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth