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

[Phil Hunt <[e-mail]>]

See inline
Phil

@independentid
www.independentid.com
[e-mail]

> On Nov 25, 2014, at 7:20 PM, Justin Richer <[e-mail]> wrote:
> 
> Kathleen,
> 
> Thanks, we’ll incorporate these suggestions into a new draft soon. Details inline.
> 
> 
> On Nov 25, 2014, at 5:01 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
>> 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
> 
> OK, we’ll re-work the wording here to make it less mushy. Phil, any suggestions for the text here?

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.
> 
>> .
>>> 
>>> -- 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).
> 
> 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.
> 
>> 
>>> 
>>> 
>>> 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].
>> 
>> 
> 
> I’m not enough of a TLS specialist to make this determination, but this text is fine with me.
> 
>> 
>> 
>>> 
>>> 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.
> 
> That makes sense, we’ll add this in. Thanks!
> 
> — Justin
> 
> 
>>> 
>>> 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
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth