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

[Kathleen Moriarty <[e-mail]>]

Hi Justin,

Thanks for your quick response!

On Thu, Nov 20, 2014 at 3:47 PM, Richer, Justin P. <[e-mail]> wrote:
> Sorry, a sentence trailed off -- I meant to say:
>
>
> 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
>
>
> ... 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 <[e-mail]> wrote:
>
> Kathleen, thanks for your review. Responses inline.
>
> On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty
> <[e-mail]> wrote:
>
> 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.
>
>
> 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:
>
>    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] 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
>    6176 [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] 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 [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].




>
> Sect 6 paragraph 5
> Why are the security recommendations listed as 'could'?
>
>
> 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.

>
> Do you have any other specific parts that you think would have privacy
> 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

>
>  -- Justin
>
>
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>



-- 

Best regards,
Kathleen