Subject: [OAUTH-WG] Review of dynamic registration draft

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Nov 2014 16:56:50 -1000

Hi,

I reviewed draft-Ietf-oauth-dyn-reg-20 and have the following questions before we move this to IETF last call.

Sect 2, Has there been any consideration in the WG of using alternate auth methods from HTTPAuth like HOBA?  I realize this is referencing Oauth defined methods from the framework draft, but would like to know what was considered or not.  HOBA is heading to IETF last call soon.

Section 6:  why is there a choice on TLS?  I'd recommend you make it require 1.2 unless there is a really compelling argument to have that must as either 1.2 or 1.0

Sect 6 paragraph 5
Why are the security recommendations listed as 'could'?

Sect 6 paragraph 7
What makes it 'valid and trusted'?  The flow of this paragraph could be improved so the terms valid and trusted are connected to earlier statements to separate it better from the plain JSON objects.

Please add a section or interspersed statements on privacy considerations.  Include text on what may be of concern (names, contacts, etc.) and what can be done to protect the values (interspersed may be easier) or that they may be left out to remove concerns.

Thank you,
Kathleen

Sent from my iPhone

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 20 Nov 2014 20:34:37 +0000

Kathleen, thanks for your review. Responses inline.

On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Nobody brought up HOBA in this working group. This field is intentionally extensible, so if there's interest in defining how to use HOBA for OAuth client authentication it will make a perfectly reasonable extension document.

We copied this text straight from RFC6749. I know that a similar section exists in JWS with updated language, and we could adopt that directly here:

   Which TLS version(s) ought to be implemented will
   vary over time, and depend on the widespread deployment and known
   security vulnerabilities at the time of implementation.  At the time
   of this writing, TLS version 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>] is the most recent
   version.

   To protect against information disclosure and tampering,
   confidentiality protection MUST be applied using TLS with a
   ciphersuite that provides confidentiality and integrity protection.
   See current publications by the IETF TLS working group, including RFC<https://tools.ietf.org/html/rfc6176>
   6176<https://tools.ietf.org/html/rfc6176> [RFC6176<https://tools.ietf.org/html/rfc6176>], for guidance on the ciphersuites currently considered
   to be appropriate for use.  Also, see Recommendations for Secure Use
   of TLS and DTLS [I-D.ietf-uta-tls-bcp<https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-37#ref-I-D.ietf-uta-tls-bcp>] for recommendations on
   improving the security of software and services using TLS.

   Whenever TLS is used, the identity of the service provider encoded in
   the TLS server certificate MUST be verified using the procedures
   described in Section 6 of RFC 6125<https://tools.ietf.org/html/rfc6125#section-6> [RFC6125<https://tools.ietf.org/html/rfc6125>].

Will that work?

Sect 6 paragraph 5

Things listed as 'could' in this section were seen to be non-normative recommendations of possible mitigating behaviors. In other words, not trying to be prescriptive with the actions here but providing guidance. Most of these were relaxed from normative requirements in earlier drafts from WG feedback

Sect 6 paragraph 7

On the first level, this includes validating the JWS on the statement itself, but as is usually the case, determining "trust" of a source is going to be very application specific. I'm not quite

Most of this protocol doesn't deal with any user information, and so I don't think there are any privacy considerations for most of the document. The one part of this protocol that I can see being a possible privacy consideration is the "contacts" meatadata field, which contains user contact information. Since this field is self-asserted by the client or developer (whoever's doing the registration) for the express purpose of providing a means of contacting the developer of the client, I'm not sure what concerns this might have, if any.

Do you have any other specific parts that you think would have privacy concerns that you'd like to address?

Thanks for the review and the thoughtful comments.

 -- Justin

Thank you,
Kathleen

Sent from my iPhone
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 20 Nov 2014 20:47:08 +0000

Sorry, a sentence trailed off -- I meant to say:

Sect 6 paragraph 7

... convinced that we can really do much more than that, though we can explicitly state that this is the case if that would help. I agree that "valid and trusted" is a bit vague.

-- Justin

On Nov 20, 2014, at 3:34 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Will that work?

Sect 6 paragraph 5

Sect 6 paragraph 7

 -- Justin

Thank you,
Kathleen

Sent from my iPhone

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Nov 2014 17:01:47 -0500

Hi Justin,

Thanks for your quick response!

On Thu, Nov 20, 2014 at 3:47 PM, Richer, Justin P. <[email-masked]> wrote:
> What makes it 'valid and trusted'?  The flow of this paragraph could be
> improved so the terms valid and trusted are connected to earlier statements
> to separate it better from the plain JSON objects.
>
>
> On the first level, this includes validating the JWS on the statement
> itself, but as is usually the case, determining "trust" of a source is going
> to be very application specific. I'm not quite
>
>
> ... convinced that we can really do much more than that, though we can
> explicitly state that this is the case if that would help. I agree that
> "valid and trusted" is a bit vague.

I'd prefer the use of other terms that mean what is actually intended
since trust is so mushy unless defined (which is not easy to do).  It
may be best to leave it to the explicit statement on validating the
JWS statement and change the wording to reflect that
.
>
> -- Justin
>
>
>
> On Nov 20, 2014, at 3:34 PM, Justin Richer <[email-masked]> wrote:
>
> On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>
> Hi,
>
> Sect 2, Has there been any consideration in the WG of using alternate auth
> methods from HTTPAuth like HOBA?  I realize this is referencing Oauth
> defined methods from the framework draft, but would like to know what was
> considered or not.  HOBA is heading to IETF last call soon.
>
>
> Nobody brought up HOBA in this working group. This field is intentionally
> extensible, so if there's interest in defining how to use HOBA for OAuth
> client authentication it will make a perfectly reasonable extension
> document.

OK, this could come up in IETF or IESG last call, so at least there is
an answer.  HTTPAuth will also have drafts updating basic and digest
soon, but since you reference the old one through the OAuth framework,
it may not be appropriate to update this.  Just mentioning this work
so folks are aware it is about ready (doesn't get any more secure
though).

>
>
> Section 6:  why is there a choice on TLS?  I'd recommend you make it require
> 1.2 unless there is a really compelling argument to have that must as either
> 1.2 or 1.0
>
>
> We copied this text straight from RFC6749. I know that a similar section
> exists in JWS with updated language, and we could adopt that directly here:
>
>    of this writing, TLS version 1.2 [RFC5246] is the most recent
>    version.
>
>    See current publications by the IETF TLS working group, including RFC
>    6176 [RFC6176], for guidance on the ciphersuites currently considered
>    of TLS and DTLS [I-D.ietf-uta-tls-bcp] for recommendations on
>    described in Section 6 of RFC 6125 [RFC6125].
>
> Will that work?

If it is simpler to just require 1.2, that would be easier.  The above
is a bit wordy and had been worked over a bit to get through hoops,
otherwise it might read a bit better.  Referencing RFC5246 and the
recommendations in I-D.ietf-uta-tls-bcp would be good.  There are some
differences in that the dyn-registration draft requires support of
TLS, whereas the JOSE specs just required it's use in certain cases.
I'd recommend something similar to the following...

Current text:

   The client
   registration endpoint MUST be protected by a transport-layer security
   mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246]
   and/or TLS 1.0 [RFC2246] and MAY support additional transport-layer
   mechanisms meeting its security requirements.  When using TLS, the
   client MUST perform a TLS/SSL server certificate check, per RFC 6125
   [RFC6125].

Suggested (or a variation):

   The client
   registration endpoint MUST be protected by a transport-layer security
   mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246]
   and MAY support additional transport-layer
   mechanisms meeting its security requirements.  When using TLS, the
   client MUST perform a TLS/SSL server certificate check, per RFC 6125
   [RFC6125].  Implementation security considerations can be found in
   Recommendations for Secure Use of TLS and DTLS [I-D.ietf-uta-tls-bcp].

> Things listed as 'could' in this section were seen to be non-normative
> recommendations of possible mitigating behaviors. In other words, not trying
> to be prescriptive with the actions here but providing guidance. Most of
> these were relaxed from normative requirements in earlier drafts from WG
> feedback

OK, WG feedback does help, this may come up again in IETF or IESG
reviews... I suspect it will get questioned.

>
>
> Sect 6 paragraph 7
> What makes it 'valid and trusted'?  The flow of this paragraph could be
> improved so the terms valid and trusted are connected to earlier statements
> to separate it better from the plain JSON objects.
>
>
> On the first level, this includes validating the JWS on the statement
> itself, but as is usually the case, determining "trust" of a source is going
> to be very application specific. I'm not quite

Answer is above with your additional response on this one.
>
>
>
>
>
>
>
> Please add a section or interspersed statements on privacy considerations.
> Include text on what may be of concern (names, contacts, etc.) and what can
> be done to protect the values (interspersed may be easier) or that they may
> be left out to remove concerns.
>
>
> Most of this protocol doesn't deal with any user information, and so I don't
> think there are any privacy considerations for most of the document. The one
> part of this protocol that I can see being a possible privacy consideration
> is the "contacts" meatadata field, which contains user contact information.
> Since this field is self-asserted by the client or developer (whoever's
> doing the registration) for the express purpose of providing a means of
> contacting the developer of the client, I'm not sure what concerns this
> might have, if any.

When this sort of information is exchanged or mentioned in our drafts
and protocols, we need to call out possible concerns and options that
folks can take to protect their privacy.  You can put the concerns in
that particular section or call them out in the Security
considerations section (they are considerations, not requirements) or
in a separate Privacy considerations section.  The developer may chose
to use a dedicated email address for this purpose to protect their
personal email (or work email) and it may also serve as an ongoing
contact email address if that developer moves on and someone else
takes over the responsibility.  This privacy information would be
geared toward the developer that is providing their information.

> concerns that you'd like to address?

My only concerns in reading the document were on the parts that
mentioned names and contact information.
> Thanks for the review and the thoughtful comments.

Glad they were helpful.

Thanks,
Kathleen

> [email-masked]

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 Nov 2014 22:20:57 -0500

Kathleen,

Thanks, we’ll incorporate these suggestions into a new draft soon. Details inline.

> JWS statement and change the wording to reflect that

OK, we’ll re-work the wording here to make it less mushy. Phil, any suggestions for the text here?

> so folks are aware it is about ready (doesn't get any more secure

This document’s purpose isn’t to define new client authentication mechanisms; instead, we should catalogue the mechanisms that are already defined and in use. If there’s interest in defining new client authentication mechanisms in extensions we can do it in different documents, or if there’s an RFC6749bis then we’ll likely see definitions of how exactly to use these newer auth methods as OAuth client authentication mechanisms in there. Either way we’ll see extensions of the token_endpoint_auth_method value set through the IANA registry.

>   Recommendations for Secure Use of TLS and DTLS [I-D.ietf-uta-tls-bcp].

I’m not enough of a TLS specialist to make this determination, but this text is fine with me.

> mentioned names and contact information.

That makes sense, we’ll add this in. Thanks!

 — Justin

---

From: Phil Hunt <[email-masked]>
Date: Tue, 25 Nov 2014 20:58:34 -0800

See inline
Phil

@independentid
www.independentid.com
[email-masked]

> On Nov 25, 2014, at 7:20 PM, Justin Richer <[email-masked]> wrote:
> 
> Kathleen,
> 

And here I thought “trusted” was a well accepted “fuzzy” term. :-)

Assuming this is the text you mean:
 Clients MAY use both the direct JSON object and the JWT-encoded
   software statement to present client metadata to the authorization
   server as part of the registration request.  A software statement is
   cryptographically protected and represents claims made by the issuer
   of the statement, while the JSON object represents the self-asserted
   claims made by the client or developer directly.  If the software
   statement is valid and trusted, the values of client metadata within
   the software statement MUST take precedence over those metadata
   values presented in the plain JSON object, which could have been
   modified en route.

Change to:
 Clients MAY use both the direct JSON object and the JWT-encoded
   software statement to present client metadata to the authorization
   server as part of the registration request.  A software statement is
   cryptographically protected and represents claims made by the issuer
   of the statement, while the JSON object represents the self-asserted
   claims made by the client or developer directly.  If the software
   statement is valid and signed by an acceptable authority (such as the Software API Publisher), the values of client metadata within
   the software statement MUST take precedence over those metadata
   values presented in the plain JSON object, which could have been
   modified en route.