Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Kathleen Moriarty <> Wed, 18 February 2015 14:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51CED1A8992 for <>; Wed, 18 Feb 2015 06:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5w9KgAUbdPd5 for <>; Wed, 18 Feb 2015 06:46:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4691E1A87D7 for <>; Wed, 18 Feb 2015 06:46:09 -0800 (PST)
Received: by labgq15 with SMTP id gq15so1575531lab.3 for <>; Wed, 18 Feb 2015 06:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YWe2RUDtK+/vCrC3HB3kuT5ZjqHGnkVNMGyci775TEI=; b=avYDMAmCSaZdPKu19ttZdHaJea4wvohrWIve52biN0Vgwog4ZkoNTxcict18RZZ8xO Hc5BqYPG8gfeW7TBrAzX3yum8Xnvterg1AQQs/fP9VxEy58bqWVgrRX9CRjUfcx1uaFU Ym9g8bkyxxBetCUT+37TyJe2Y7CFukscgEcTJoWgq3WwY74Q0CBxu87r1ixLZFDai2zT Ytzyxr4QK5KElCvUQPrS62PZLoUxB0gWp5QlFcOMr65fxsqr5fmgCc3DdBtdiZyTa9f/ fNgAHyKz763azsCJGwc/HL+brZEPr2WzzpGMBZ/9ta1+v/QX6cu5ThJi1Mq/8L29Sk3F cq9Q==
MIME-Version: 1.0
X-Received: by with SMTP id by1mr26508404lbb.113.1424270767709; Wed, 18 Feb 2015 06:46:07 -0800 (PST)
Received: by with HTTP; Wed, 18 Feb 2015 06:46:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 18 Feb 2015 09:46:07 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary="001a1133ae122c6450050f5de1c7"
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
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: Wed, 18 Feb 2015 14:46:19 -0000


On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones <>

> A few responses and comments are inline below...
> > From: OAuth [] On Behalf Of Phil Hunt
> > Sent: Thursday, February 12, 2015 11:47 AM
> > To: Justin Richer
> > Cc:
> > Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >
> >
> > Phil
> >
> > @independentid
> >
> >
> >
> > On Feb 11, 2015, at 8:31 PM, Justin Richer <> 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.

Thanks for the quick responses and sorry about my delay, it's a busy week!

> >
> > 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?).

A separate draft is fine and I'd like the WG to think about what more
secure options for authentication would be best to add in that draft and
into the registry.  With the popularity of Oauth, I think we could and
should be creating better options.

> 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.)
> Yep, I get this and stated I understood why this was the case in my
original message. I suggested HOBA because it is already in the RFC editor
queue, approved by the IESG.  The WG should discuss this and see how they
want to proceed.

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

I'll take a look, thanks.

> 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.
The new version of Basic cleans up Internationalization concerns and adds
text to say how bad the security problems of basic are.  That's all I was
saying, I was not asking for you to update anything in this draft except to
see if the updated version of HTTP Basic should be used.  It's backwards
compatible and still horribly insecure, not to worry.  It's on this week's
teelchat, so it is ahead of this draft in the queue.

> > 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
> >
> > 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.

I don't care about the length argument, I think someone else else had a
more reasonable explanation of why this should be left out and I was okay
with that.  At least a pointer would be good to the privacy section so
folks know to look at it.  I had the questions as soon as I read this text
and had to wait until the very end to see an answer, it would be good for
folks who don't know this is an issue to have the pointer.

> >
> >
> > 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.

Are there specific well-known formats that should be used?  If it's machine
parseable, how does one know which format is expected?  If it's just the
label sent by the application, then expect variance and issues as each
version might not be in a consistent format.  If it is a formatted
description like SWID, then that should be stated or if a mix of formats
are fine with no preference.

> > [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.

OK, can someone propose text?

> >
> >   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.

OK, please make that clear in the privacy considerations section.

> >
> >   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.

Help me understand why there should not be text that shows this is not an
issue or please propose some text.  This is bound to come up in IESG
reviews if not addressed up front.

> >
> >
> >
> > 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?

I'd put it int he security considerations and just have a pointer from the
earlier text so references are all in one place.

Thank you,

> 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
> _______________________________________________
> OAuth mailing list


Best regards,