A few responses and comments are inline below...
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, February 12, 2015 11:47 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Feb 11, 2015, at 8:31 PM, Justin Richer <jric...@mit.edu> wrote:
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]
[Phil] Agreed with Kathleen's suggestion.
I also agree that the wording of the definitions could be clarified. Justin,
do you want to take a first pass at this or would you like to take lead on
this, Phil?
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?).
HTTP Basic is set to the default because that's the default in RFC 6749 and
this specification is about registering clients for use with RFC 6749. Trying
to change the RFC 6749 default really isn't within the scope of this work. (If
that's done, it should probably be done in an http6749-bis spec.) However, the
spec does define a registry that new methods like HOBA can be registered in
when people want to use them. (And if HOBA finishes before Dynamic
Registration, I'm fine adding a registry entry for it in this spec.)
If you're interested in the client_secret_jwt and private_key_jwt client
authentication methods that Justin alluded to, these are defined in Section 9
of OpenID Connect Core
http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.
In relation to your internationalization comments Kathleen, note that Section
2.3.1 of RFC 6749 explicitly provides a mechanism for encoding international
strings for use with HTTP Basic. This was added under the supervision of
Julian Reschke, I believe as a result of his WGLC comments. So whether this is
the same as what the new version of HTTP Basic does or not, OAuth 2.0 already
does provide a standard way to use internationalized strings with HTTP Basic
for OAuth client authentication.
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 ab...@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]
We should probably say that in the draft then.
[Phil]
I've added some more explanatory text. Note...some of this may be better put
elsewhere.
As to whether the values are human readable, I have no opinion. What matters
most is unique matching.
software_id
A unique identifier (e.g. UUID) assigned by the developer or software
publisher
used by registration endpoints to identify client software to be
dynamically registered.
Unlike "client_id", which is issued by the authorization server and
varies between
instances of software, the "software_id" SHOULD remain the same for all
client software
instances. The "software_id" SHOULD remain the same across multiple
software updates
or versions.
I'd revise the last two sentences of this as follows:
Unlike "client_id", which is issued by the authorization server and may
vary between
instances of a piece of software, the "software_id" SHOULD remain the
same for all instances
of a piece of software. The "software_id" SHOULD remain the same across
multiple software updates
or versions of the same piece of software.
software_version
A version identifier for the software identified by "software_id". The
value of this field is a string that is intended to be compared
using string equality matching. Unlike "software_id", the value of the
"software_version" SHOULD change on any update to the client
software. A service provider MAY use "software_id" and
"software_version" to
recognize approved software and version combinations approved for
dynamic registration.
Let me know if you want more background.
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?
Justin, do you want to make specific rewording proposals for this and the other
editorial issues that were identified?
--
Best regards,
Kathleen
Thanks again for your review!
-- Justin
Thanks all,
-- Mike
