Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B851A8AC2 for ; Wed, 11 Feb 2015 20:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF0mnNdyIjm4 for ; Wed, 11 Feb 2015 20:31:51 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789791A8A6A for ; Wed, 11 Feb 2015 20:31:51 -0800 (PST) X-AuditID: 1209190e-f79bb6d0000030e8-db-54dc2cb5ff39 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B5.BA.12520.5BC2CD45; Wed, 11 Feb 2015 23:31:50 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1C4Vnjb009965; Wed, 11 Feb 2015 23:31:49 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1C4VleJ032745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Feb 2015 23:31:48 -0500 Message-ID: <54DC2CB1.8090400@mit.edu> Date: Wed, 11 Feb 2015 23:31:45 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty , "oauth@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040401060801000606090601" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT192mcyfEYHoPk0XDznyLk29fsTkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGf0velgK5h1mrHjYtpapgfFxL2MXIyeHhICJ xKMHn6BsMYkL99azgdhCAouZJNoWJnYxcgHZGxklzn05zw7h3GaSeD55FzNIFa+AmsS+BZfB OlgEVCWWfJgPFmcDsqevaWECsUUFoiRmn3/AClEvKHFy5hMWEFtEIEXicu8TsHphAXOJ/w/u ANVzAC0IkNjzTRIkzCkQKLH02BywVmaBMInlPx+zT2Dkn4Vk0iwkKQjbVuLO3N3MELa8xPa3 c6BsXYlF21aww8Sbt85mXsDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMo sDkl+XYwfj2odIhRgINRiYfXY+utECHWxLLiytxDjJIcTEqivHPl7oQI8SXlp1RmJBZnxBeV 5qQWH2KU4GBWEuFlYgLK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8K7WBmoULEpNT61Iy8wpQUgzcXCCDOcBGi6tAzK8uCAxtzgzHSJ/ilFRSpw3G6RZACSRUZoH 1wtLPK8YxYFeEebNBKniASYtuO5XQIOZgAZPnHEbZHBJIkJKqoHRbYehG7frwyfnSxftb+FN cTi3IrdVynZBcdZrr2eSSluOuK76NCfSJZrb7tS9Y8mFjvEKd7YIm2RMvntIcFIOi8ex/EmC HemlXKJWhYeSZuUafj8heeh87TWHmZs2f23QiH7o96b6otcHjuk62t82zPKtv3tlV8+DuO9f 1fQYrt/btJpNdPInJZbijERDLeai4kQA3M+9BxcDAAA= Archived-At: Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 04:31:57 -0000 This is a multi-part message in MIME format. --------------040401060801000606090601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Kathleen, thanks for the review. Responses inline, though I'm going to let the other authors talk about their sections (deployment org, software version, etc) directly. On 2/11/2015 6:06 PM, Kathleen Moriarty wrote: > Thank you for your work on this draft and sorry for the delay in my > review. Before we progress to IETF last call, I'd like to see what we > can resolve from the list below. I am looking at the IPR issues to > see if we can resolve the outstanding questions as well. > > The Shepherd report says the following: > The document shepherd has raised concerns regarding the fuzzy > description > of the actors (deployment organization, software API publisher, client > developer) and their impact on the protocol execution. The working > group did not seem to worry about these aspects though. > > I can see the point after reading the draft. The interactions are > written much more clearly in the security considerations section than > where the flows are described. Can something be done to address these > concerns? > > Section 1.2 > Deployment Organization definition: > I highly recommend replacing the phrase "simple cloud deployment" with > a description that accurately reflects what is intended. If that's > within a single service provider's network, a single data center, or a > single hosted data center, I think it would be more clear. > > Section 1.2 nit: > Add the word "be" into the following term definition after "may": > Software API Publisher > The organization that defines a particular web accessible API that > may deployed in one or more deployment environments. [deferred to original author of this text Phil et. al for better wording] > > Section 2: > > Why isn't a more secure option offered and set as the default for > authentication types? I know I've asked this before and the answer was > just that you can add something to the registry, but setting HTTP > Basic as the default seems like a really bad choice. HOBA is on it's > way to becoming an RFC from the HTTPAuth working group. HTTPAuth also > has an updated version of Basic that is in IETF last call, but I know > you are pointing to the OAuth 2.0 document, so it would be that > document that gets updated and not this draft. The new version of > HTTP Basic fixes some internationalization problems and spells out the > security issues much more clearly, so it probably doesn't matter too > much to update the reference, but maybe makes it more clear that basic > is not a secure form of authentication. > > Can you provide some justification as to why this is okay to set basic > as the default and add that to the draft? Section 2.3.1 of OAuth 2.0 > just says this MUST be implemented, but that any HTTP schemes can be > used. Why not register another method and use that instead as the > default? You could use digest and there is library support. It's not > a great answer, but slightly better than passwords with basic. You > could register HOBA and use that instead, the only downside is limited > library support at the moment. It was our intent to document the methods already defined for use with OAuth and provide a registration mechanism for distinguishing between them, not to create new client authentication mechanisms. Digest and HOBA simply aren't defined for use with OAuth clients yet. It would be simple to do: put the client id in the "username" field and the client secret in the "password" field of both algorithms. However, I don't believe it's a good idea to conflate those two goals in a single specification. We actually had other, more secure definitions in an earlier draft of this document (using a JWT signed with a private key or a JWT signed with a shared key, specifically), but those were removed in order to focus on solving just the client registration problem. I agree with that decision of the WG. As other methods of client authentication are defined in the OAuth ecosystem, they can register as valid values in the registry. I think it would be a valuable output of this WG to define other client authentication mechanisms as a separate draft or an eventual update to RFC6749 (or both?). > > Section 2: Contacts: > > I noticed privacy is not dealt with until you get to the security > considerations section. I'd prefer to see it with the definition, > stating the address should be a general help address at the domain > rather than directly to an identifiable individual. It may be good to > set a default for what this should be for consistency or give an > example (think back to abuse@domain.com )? The problem that I see with putting it inside the definition is that it makes the definition text very long, as the definition sits in a list of other metadata items. We could add a forward pointer and an example easily enough, though. Or we could move the privacy considerations section up as a subsection here, though I don't know if that runs afoul of the RFC style guidelines for this new section. > > Software_id and software_version: > Are there any guidelines as to how these should be represented? There > are several specifications on software_id (and platform). Does > consistency here matter or is this just meant to be human readable? > Section 2.2 specifies some metadata values that are to be human > readable, should the above be in the list? I would expect this list > to be comprehensive for clarity, rather than just examples since there > aren't too many defined here. > [mostly deferred to Phil et. al, but note that software_id and software_version are not intended to be human readable and don't need the multi-language support] > Section 3.2.1 & Privacy section > For client_name and client_id and associated information, how is user > privacy affected and what can be done to mitigate concerns? The > definition should state that this is a public value and that it is > specific to the software, not a person. You have to get to the > security consideration section before that is clear. References are > fine too, but some more information is needed in the privacy section. > I'm left with a bunch of questions: > Can the client_name and client_id be tied to a person? The client name is common across all copies of the software (usually), so no worries there. The ID represents an individual piece of software, not a person, though if that person is the sole user of the instance of software then I believe you're right that there are some privacy considerations that we should point that out. However, dynamic registration can actually help mitigate this as well, since in the normal case (with no software statements) there's no way to correlate instances of clients with each other. > Can the person be tracked by this? > Can other information be gathered about a system (and it's user) > during this process? Nothing gathered about the user during registration, as this happens in the back channel outside the user's purview. > The information is used to dynamically register clients, what is logged? > What data is aggregated? > What can you tell about a client (time, location, travel, other > personal details that may be considered sensitive)? I don't think > this was covered in the OAuth 2.0 RFC. > How is this addressed at the authorization server and other points? > The Security considerations talks about client_id as being short > lived, so they expire, but are these event logged or is that prohibited? Many of these questions seem to be completely dependent on the implementation of the authorization server, and I'm not really sure how (or if) to address them in this draft. Any suggestions would be welcomed here. The client_id *could* be short lived, but they usually aren't. I don't see any particular logging or tracking concerns using a dynamic OAuth client above using any other piece of software, ever. As such, I don't think it requires special calling out here. > > 5. Security considerations > The first paragraph is a repeat of text. Can this just be in one > place and use a pointer to the full text? I like the requirement, but > reading it once is enough. I think it was less onerous of a repeat when both simply said "use TLS", so some refactoring after the expansion of the text makes sense to me. Would it be better to have it upfront in the endpoint definition, or in the security considerations? > > -- > > Best regards, > Kathleen Thanks again for your review! -- Justin > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040401060801000606090601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Kathleen, thanks for the review. Responses inline, though I'm going to let the other authors talk about their sections (deployment org, software version, etc) directly.

On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
Thank you for your work on this draft and sorry for the delay in my review.  Before we progress to IETF last call, I'd like to see what we can resolve from the list below.   I am looking at the IPR issues to see if we can resolve the outstanding questions as well.

The Shepherd report says the following:
   The document shepherd has raised concerns regarding the fuzzy description
   of the actors (deployment organization, software API publisher, client 
   developer) and their impact on the protocol execution. The working 
   group did not seem to worry about these aspects though.

I can see the point after reading the draft.  The interactions are written much more clearly in the security considerations section than where the flows are described.  Can something be done to address these concerns?

Section 1.2
Deployment Organization definition:
I highly recommend replacing the phrase "simple cloud deployment" with a description that accurately reflects what is intended.  If that's within a single service provider's network, a single data center, or a single hosted data center, I think it would be more clear.

Section 1.2 nit:
Add the word "be" into the following term definition after "may":
  Software API Publisher
      The organization that defines a particular web accessible API that
      may deployed in one or more deployment environments.

[deferred to original author of this text Phil et. al for better wording]


Section 2:

Why isn't a more secure option offered and set as the default for authentication types? I know I've asked this before and the answer was just that you can add something to the registry, but setting HTTP Basic as the default seems like a really bad choice. HOBA is on it's way to becoming an RFC from the HTTPAuth working group.  HTTPAuth also has an updated version of Basic that is in IETF last call, but I know you are pointing to the OAuth 2.0 document, so it would be that document that gets updated and not this draft.  The new version of HTTP Basic fixes some internationalization problems and spells out the security issues much more clearly, so it probably doesn't matter too much to update the reference, but maybe makes it more clear that basic is not a secure form of authentication.  

Can you provide some justification as to why this is okay to set basic as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just says this MUST be implemented, but that any HTTP schemes can be used.  Why not register another method and use that instead as the default?  You could use digest and there is library support.  It's not a great answer, but slightly better than passwords with basic.  You could register HOBA and use that instead, the only downside is limited library support at the moment.

It was our intent to document the methods already defined for use with OAuth and provide a registration mechanism for distinguishing between them, not to create new client authentication mechanisms. Digest and HOBA simply aren't defined for use with OAuth clients yet. It would be simple to do: put the client id in the "username" field and the client secret in the "password" field of both algorithms. However, I don't believe it's a good idea to conflate those two goals in a single specification. We actually had other, more secure definitions in an earlier draft of this document (using a JWT signed with a private key or a JWT signed with a shared key, specifically), but those were removed in order to focus on solving just the client registration problem. I agree with that decision of the WG.

As other methods of client authentication are defined in the OAuth ecosystem, they can register as valid values in the registry. I think it would be a valuable output of this WG to define other client authentication mechanisms as a separate draft or an eventual update to RFC6749 (or both?).


Section 2: Contacts:

I noticed privacy is not dealt with until you get to the security considerations section.  I'd prefer to see it with the definition, stating the address should be a general help address at the domain rather than directly to an identifiable individual.  It may be good to set a default for what this should be for consistency or give an example (think back to abuse@domain.com)?

The problem that I see with putting it inside the definition is that it makes the definition text very long, as the definition sits in a list of other metadata items. We could add a forward pointer and an example easily enough, though. Or we could move the privacy considerations section up as a subsection here, though I don't know if that runs afoul of the RFC style guidelines for this new section.


Software_id and software_version:
Are there any guidelines as to how these should be represented?  There are several specifications on software_id (and platform).  Does consistency here matter or is this just meant to be human readable?
Section 2.2 specifies some metadata values that are to be human readable, should the above be in the list?  I would expect this list to be comprehensive for clarity, rather than just examples since there aren't too many defined here.


[mostly deferred to Phil et. al, but note that software_id and software_version are not intended to be human readable and don't need the multi-language support]

Section 3.2.1 & Privacy section
For client_name and client_id and associated information, how is user privacy affected and what can be done to mitigate concerns?  The definition should state that this is a public value and that it is specific to the software, not a person.  You have to get to the security consideration section before that is clear.  References are fine too, but some more information is needed in the privacy section.  I'm left with a bunch of questions:
  Can the client_name and client_id be tied to a person?
The client name is common across all copies of the software (usually), so no worries there. The ID represents an individual piece of software, not a person, though if that person is the sole user of the instance of software then I believe you're right that there are some privacy considerations that we should point that out. However, dynamic registration can actually help mitigate this as well, since in the normal case (with no software statements) there's no way to correlate instances of clients with each other.
  Can the person be tracked by this?
  Can other information be gathered about a system (and it's user) during this process? 
Nothing gathered about the user during registration, as this happens in the back channel outside the user's purview.
  The information is used to dynamically register clients, what is logged?
  What data is aggregated?
  What can you tell about a client (time, location, travel, other personal details that may be considered sensitive)?  I don't think this was covered in the OAuth 2.0 RFC.
  How is this addressed at the authorization server and other points?
  The Security considerations talks about client_id as being short lived, so they expire, but are these event logged or is that prohibited?

Many of these questions seem to be completely dependent on the implementation of the authorization server, and I'm not really sure how (or if) to address them in this draft. Any suggestions would be welcomed here.

The client_id *could* be short lived, but they usually aren't. I don't see any particular logging or tracking concerns using a dynamic OAuth client above using any other piece of software, ever. As such, I don't think it requires special calling out here.


5. Security considerations
The first paragraph is a repeat of text.  Can this just be in one place and use a pointer to the full text?  I like the requirement, but reading it once is enough.

I think it was less onerous of a repeat when both simply said "use TLS", so some refactoring after the expansion of the text makes sense to me. Would it be better to have it upfront in the endpoint definition, or in the security considerations?


--

Best regards,
Kathleen

Thanks again for your review!

 -- Justin



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

--------------040401060801000606090601--