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 286E41A014D for ; Sun, 30 Nov 2014 18:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RU55MCIotX1Y for ; Sun, 30 Nov 2014 18:22:00 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3C91A0055 for ; Sun, 30 Nov 2014 18:21:59 -0800 (PST) X-AuditID: 12074423-f79b86d000000cf5-a6-547bd0c67c4e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7A.F0.03317.6C0DB745; Sun, 30 Nov 2014 21:21:58 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sB12Lv6w008580; Sun, 30 Nov 2014 21:21:57 -0500 Received: from artemisia.richer.local (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 sB12Lsn4023018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Nov 2014 21:21:56 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_41375217-C74B-4C13-9A4F-005899761A21"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Justin Richer In-Reply-To: <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> Date: Sun, 30 Nov 2014 21:21:54 -0500 Message-Id: <4BFAB728-BF73-4213-8CDF-CC5080695C0F@mit.edu> References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLKsWRmVeSWpSXmKPExsUixG6nonvsQnWIwaz1ghZLd95jtTj59hWb A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRfHQie8GSu0wVE152sjcwXlvC1MXIySEh YCLx+eU5NghbTOLCvfVANheHkMBiJomN/zZDORsZJc6ffcUM4dxkkpj29BEriMMsMIlR4tyn 1awg/bwCBhJLdm1iBrGFBQIl1jfcAZvLJqAqMX1NC9g+TgFriXOLZwDVc3CwAMX3ra8ECTMD mV8WvGeCGGMlsX7qPHaIZRcYJd69mQM2U0TAUOL6zOmsELfKS3z4cJx9AqPALGR3zEJyxyyw wUkSv/c+YIWwtSWWLXwNFTeQeNr5Cou4vsSbd3OYIGx5ie1v50DFLSUWz7zBAmHbStzqWwBV YyfxaNoi1gWM3KsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCY85FeQfjn4NK hxgFOBiVeHgl5leHCLEmlhVX5h5ilORgUhLlPT0PKMSXlJ9SmZFYnBFfVJqTWnyIUQVo16MN qy8wSrHk5eelKonwnvMAquNNSaysSi3KhymT5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8Gh JME77TxQo2BRanpqRVpmTglCmomD8xCjBAcP0HAXkBre4oLE3OLMdIj8KUZFKXHepyAJAZBE RmkeXC8sVb5iFAd6S5hXG6SKB5hm4bpfAQ1mAhrM0FwJMrgkESEl1cB45PGP/Qrf56x7dEO1 u+TSMT7JCAZmnZm7J5wK7Uk7cKlEjXNx1I+nqsEt8d8vOGY93B/XKrTT85jZfZHLtgusYo+x /kg4sn+Pv9hKj1qHW11GxeuvnNV7uP9g1m7x+Trhn0SlPQwnH4hUUl7F8U85d8/B3zdYl7I/ Vc7JzuNff+Gb+brNCfMuKLEUZyQaajEXFScCAJU8NIBwAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GwhaL6x79N4JrumsSG7czwTEaPA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 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: Mon, 01 Dec 2014 02:22:08 -0000 --Apple-Mail=_41375217-C74B-4C13-9A4F-005899761A21 Content-Type: multipart/alternative; boundary="Apple-Mail=_BCB28D54-0A42-40FE-9D33-DB1A54E890EA" --Apple-Mail=_BCB28D54-0A42-40FE-9D33-DB1A54E890EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hannes, I=92ve had a chance to more thoroughly re-read both the drafts and your = notes, I think you=92re actually correct about the IANA registration. We = register =93client_id=94 and =93client_secret=94, even though they can=92t= be requested by the client. As such, we do need to register = =93registration_access_token=94 and the =93registration_client_uri=94 in = the registry. We=92ll make sure those are in the next revision of the = document. =97 Justin On Nov 26, 2014, at 8:32 AM, Justin Richer wrote: > And by =936790=94 below I obviously mean RFC6749. >=20 > (Note to self, don=92t write working group emails this early in the = morning.) >=20 > =97 Justin >=20 > On Nov 26, 2014, at 8:31 AM, Justin Richer wrote: >=20 >>=20 >> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig = wrote: >>=20 >>> Hi Justin, >>>=20 >>> thanks for your quick response. A few remarks below. >>>=20 >>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>> Hannes, thank you for the review. Answers inline. >>>>=20 >>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig >>>> wrote: >>>>=20 >>>>> Hi Justin, Mike, John, Maciej, >>>>>=20 >>>>> as part of my shepherd write-up I carefully read through=20 >>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the document is in >>>>> good shape but I have a few minor clarification questions that >>>>> should be resolved before the document goes to the IESG. >>>>>=20 >>>>> In Section 1.4. "Registration Tokens and Client Credentials" you >>>>> explain the different credential types and I was wondering why you >>>>> aren't issuing client_secrets to all clients instead of = introducing >>>>> another credential, the registration access token. While you try = to >>>>> explain the reasons those appear somewhat constructed. For = example, >>>>> you say that "not all types of clients have client credentials" = but >>>>> you are the author of the specification and you can essentially >>>>> decide what to do. The registration access token is essentially = the >>>>> same as the client credential since it is "is uniquely bound to = the >>>>> client identifier". >>>>>=20 >>>>> I believe we have discussed this issue in the past but I don't >>>>> remember what the reasoning was. Can you describe what your design >>>>> rational was (and add it to the document)? >>>>=20 >>>> That's exactly the question this section is trying to answer, and = if >>>> it can be made clearer then please suggest some text that will help >>>> that purpose. The rationale for the registration access token is = very >>>> simple: we want to have a means to call the management endpoint in = a >>>> protected manner, and treating the management endpoint as an OAuth >>>> Protected Resource makes a lot of sense. RFC6750 gives us the means >>>> to make an authorized call to an API endpoint, so we're re-using = that >>>> instead of trying to invent some other mechanism. Shouldn't we be >>>> helping the world get away from API passwords? >>>>=20 >>>> And it's very true that not every client is going to have a client >>>> secret to use at the token endpoint -- some will have no use of one >>>> (public and implicit clients) and some will be using TLS or >>>> asymmetric keys (JWT assertions, for instance) or other mechanisms = to >>>> authenticate that don't involve the secret. Instead of forcing = these >>>> clients to use a client secret for one new endpoint, or forcing = that >>>> endpoint to potentially support the infinite number of client >>>> authentication mechanisms, we decided to just use OAuth. These are >>>> OAuth clients, remember -- they will *all* have the ability to send >>>> OAuth tokens to a protected resource already built in. >>>>=20 >>>=20 >>> Here is the point I don't quite get: the registration access token = is >>> essentially the same as a client secret. You as a specification = author >>> essentially decides whether clients will get a client secret or a >>> registration access token. It is under your control. >>>=20 >>> To be more specific, here is what you could have done: >>>=20 >>> C -> S: Client Registration Request >>> C <- S: Client Information Response (with new client secret) >>>=20 >>> C -> S: Read or Update Request (with client id/client secret) >>> C <- S: Client Information Response >>>=20 >>> Instead, you currently have this exchange: >>>=20 >>> C -> S: Client Registration Request >>> C <- S: Client Information Response (with new reg. access token) >>>=20 >>> C -> S: Read or Update Request (with client id + reg. access token) >>> C <- S: Client Information Response >>>=20 >>> Do you see the similarity that I see? >>=20 >> For clients that use a client secret to authenticate to the token = endpoint, your point makes sense, but for clients who would not = otherwise have a client secret, it doesn=92t. You end up with a = confusing state where you=92re giving somebody a =93client_secret=94 = which is defined in 6790 to be used at the token endpoint but then = telling them not to use it at the token endpoint (where they use = something else or do=92t use it at all) but to use it at this new = endpoint instead. Can you see the confusion point here? I think it=92s = only going to get worse as we get more clients that use auth mechanisms = that don=92t depend on a shared secret (public key, TLS, etc.).=20 >>=20 >> Instead we=92re giving people an OAuth access token to access a = protected API, something that OAuth clients ought to know how to do = anyway. This mechanism also gives us an opportunity to potentially use = the new PoP tokens (once they=92re actually defined) in place of the = bearer credential that=92s defined today.=20 >>=20 >>>=20 >>>>>=20 >>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>>=20 >>>>> " The Authorization Server MAY rotate the client's registration >>>>> access token and/or client credentials (such as a "client_secret")=20= >>>>> throughout the lifetime of the client. " >>>>>=20 >>>>> You might want to add reasons why the authorization server may = want >>>>> to take this step. >>>>=20 >>>> OK, but there's nothing normative here in my view. It's basically = up >>>> to the auth server to say "well let's make a new credential". Can = you >>>> suggest text that would clarify this? >>>>=20 >>>=20 >>> What about making the spec simpler by not allowing credential = rotation? >>> Rekying is a useful concept under two circumstances, namely >>> * when they provide a performance improvement (such as it is the = case >>> with session resumption in TLS where you can do an abbreviated = handshake >>> without all the heavy public key crypto) >>> * when the entrophy of the key is exhausted, which typically happens = if >>> you exceed a number of data packets sent under a given key. Often = this >>> is tied to the way how freshness is ensured and the need to avoid >>> encrypting data with the same initialization vector/nonce twice. >>>=20 >>> Neither of these two cases seem to apply here (IMHO). >>=20 >>=20 >> Rekeying the client is useful in a whole lot more cases than these = two, and most of them boil down to =93Something seems fishy=94. I think = if anything we need to eventually figure out how to do *more* secret = rotation, including a proactive mechanism started by the client (as = Brian has mentioned, among others).=20 >>=20 >>>=20 >>>=20 >>>>>=20 >>>>> There are also a bit too many SHOULDs in the document. Every time >>>>> you write SHOULD you have to keep in mind to tell the reader what >>>>> happens in the other case. For example, in Section Section 1.4.1 >>>>> you write: >>>>>=20 >>>>> " The registration access token SHOULD be rotated only in response >>>>> to an update request to the client configuration endpoint, at >>>>> which point the new registration access token is returned to the >>>>> client and the old registration access token SHOULD be discarded = by >>>>> both parties. " >>>>>=20 >>>>> Here the question arises whether you are using the SHOULD to >>>>> indicate that the authorization server does not always need to >>>>> rotate the registration access token and if he does then is must >>>>> only happen in response to an update request or does it indicate >>>>> that the authorization server could also rotate it in response to >>>>> other calls? >>>>=20 >>>> It's more that the server SHOULD NOT throw out a registration = access >>>> token that a client still thinks is good without some way to >>>> communicate the new token to the client. Think of it this way, = you've >>>> got the token, the server decides to chuck it on you -- what do you >>>> do? You can try calling your READ or UPDATE operations to get the = new >>>> one but no dice, your token is bad. So what we're saying here is = not >>>> to throw out the client's only means of finding out if its keys are >>>> good anymore. >>>=20 >>> I think I got confused with the description of the state management = (as >>> described in the document). There is some fuzziness. >>>=20 >>> Here I would prefer to have either no rekeying (which would make the >>> issue go away) or a very deterministic way of rekeying. >>>=20 >>> I prefer the former. >>=20 >> I=92m not a fan of enforcing permanent credentials on the world. And = we have the same construct with refresh tokens today, for what it=92s = worth. >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> Also, in the second line one would wonder why the old registration=20= >>>>> access token isn't mandatorily discarded. If there are good >>>>> reasons, then tell the reader. >>>>=20 >>>> We've tried to put requirements on the server discarding tokens in >>>> the past, but there was significant pushback from providers who use >>>> non-revocable time-limited tokens. Maybe they won't be doing that >>>> here, for the reason above. >>>=20 >>>=20 >>> I wouldn't reflect that in the document. Of course, you can never be >>> sure that the implementation really discards any state but for the >>> purpose of the protocol state machine it is gone. >>>=20 >>>>=20 >>>>> Furthermore, the text in Section 2.2 seems to contract this >>>>> statement: " If the authorization server includes a new client >>>>> secret and/or registration access token in its response, the = client >>>>> MUST immediately discard its previous client secret and/or >>>>> registration access token. " >>>>=20 >>>> This is a requirement on the client, not the server, so it's not >>>> bound by the token lifetime restrictions above. We're telling the >>>> client to stop using a secret or token after it's been given a new >>>> one, that's fine. >>>=20 >>> OK >>>=20 >>>>=20 >>>>> In Section 2.2 you write: " However, since read operations are >>>>> intended to be idempotent, the read request itself SHOULD NOT = cause >>>>> changes to the client's registered metadata values. " >>>>>=20 >>>>> I am wondering whether this SHOULD NOT statement adds a lot of >>>>> value since you allow the request to change metadata values. >>>>=20 >>>> I think you're right, since the metadata values might have changed >>>> through outside forces since the client last read, and all the >>>> clients need to be able to deal with that. We can remove that line. >>>=20 >>> OK >>>=20 >>>>=20 >>>>> You also write the security consideration section: " the >>>>> registration access token MAY be rotated when the developer or >>>>> client does a read or update operation on the client's client >>>>> configuration endpoint. " >>>>>=20 >>>>> This means that the content of the registration access token may >>>>> also change with a read operation. >>>>=20 >>>> That's correct. >>>>=20 >>>>> Terminology: >>>>>=20 >>>>> Sometimes you write "Client Information Response" and sometimes >>>>> "client information response" The same with "Authorization Server" >>>>> and "authorization server" >>>>=20 >>>> They're all supposed to be lower cased, as is the style in RFC6749. = I >>>> tried to bump everything down in a previous edit but it looks like = I >>>> missed some. >>>>=20 >>>>> Typo: >>>>>=20 >>>>> " Some values in the response, including the "client_secret" and >>>>> r"egistration_access_token", MAY be ^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 >>>>> different from those in the initial registration response. " >>>>=20 >>>> Thanks, noted! >>>>=20 >>>>>=20 >>>>> In Section 2.4 "Client Delete Request" you write: >>>>>=20 >>>>> " The authorization server SHOULD immediately invalidate all >>>>> existing authorization grants and currently-active tokens >>>>> associated with this client. " >>>>>=20 >>>>> Under what circumstances wouldn't the authorization invalidate all=20= >>>>> grants and active tokens? >>>>=20 >>>> When it's using a non-revocable stateless token and it can't >>>> physically do that. Too bad 2119 doesn't have MUST IF POSSIBLE or >>>> equivalent. >>>=20 >>> Maybe it would be good to add this information. >>>=20 >>> It might also be worthwhile whether this notion of a non-vocable >>> stateless token actually exists in this context since we are really >>> talking about the same infrastructure here. This registration = management >>> mechanism is really very central to the authorization server (unlike >>> some other access token mechanisms where we talk about the resource >>> server, which may be in a different administrative domain even). >>=20 >> Why doesn=92t the existing SHOULD cover this? >>=20 >>>=20 >>>>=20 >>>>> You might also want to say what tokens you are talking about since >>>>> there are at least the following tokens around: - access tokens - >>>>> refresh tokens - registration access tokens - initial access token >>>>=20 >>>> OK, we can add that. >>>>=20 >>>>>=20 >>>>> " If the server does not support the delete method, the server >>>>> MUST respond with an HTTP 405 Not Supported. " >>>>>=20 >>>>> Why aren't you demanding that the server must support this method?=20= >>>>> This would essentially mean that there would be some cases where=20= >>>>> deregistration isn't possible. Of course, there may be the = question >>>>> how important deregistration actually is if the registration=20 >>>>> automatically expires. >>>>=20 >>>> Because delete is not always an easy operation to implement. The >>>> client should be able to call the endpoint with the DELETE verb and >>>> at least know if it's allowed to do that or not. >>>=20 >>> Hmmm. I didn't know that the delete method is difficult to = implement. >>=20 >> Depends on your infrastructure and how things get propagated between = components. >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> You write: " If the client does not exist on this server, the >>>>> server MUST respond with HTTP 401 Unauthorized and the = registration >>>>> access token used to make this request SHOULD be immediately >>>>> revoked. " >>>>>=20 >>>>> If the client does not exist and someone sends a request with a >>>>> random registration access token I am not sure what exactly you >>>>> want to revoke here. >>>>=20 >>>> It's not the case of a random token, it's the case of a client = having >>>> been deleted but using an otherwise valid access token. If the >>>> token's no good, you don't get this far -- you return a 401 as >>>> defined in RFC6750. >>>=20 >>> I guess it might make sense to add this information. >>=20 >> It=92s already in there, in the paragraph just before the one you = quoted: >>=20 >> If the registration access token used to make this request is not >> valid, the server MUST respond with an error as described in OAuth >> Bearer Token Usage [RFC6750]. >>=20 >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> In Section 3.1. "Client Information Response" you state the new >>>>> elements that are returned to the client. While the client_secret >>>>> has an expires_at field the registration_access_token doesn't. = Does >>>>> the expiry value of the client_secret_expires_at automatically >>>>> indicate the lifetime of the registration access token? I think >>>>> so. But what happens if the client_secret is not issued? To make = it >>>>> more complicated you write the following text in the security >>>>> consideration section: >>>>>=20 >>>>> " While the client secret can expire, the registration access >>>>> token SHOULD NOT expire while a client is still actively >>>>> registered. " >>>>=20 >>>> There isn't a separate expiration for the registration access token >>>> because it's not supposed to unceremoniously expire on a client. It >>>> should be good until it gets rotated out on a future read/update >>>> operation or the client's registration is no good anymore. >>>=20 >>> I think it might be good to have a small section that explains how = state >>> management works. >>=20 >> Can you suggest text for this beyond the paragraph that=92s already = there? >>=20 >>>>=20 >>>>>=20 >>>>> The IANA consideration section is empty. Wouldn't it be necessary >>>>> to register 'registration_access_token' and >>>>> 'registration_client_uri' into the OAuth Dynamic Registration >>>>> Client Metadata Registry? >>>>=20 >>>> No, these are not client metadata. The client can not send these in = a >>>> registration request, so they don't need to be in there. >>>=20 >>> Really? >>>=20 >>> I thought that the IANA registry created with Section 5.1 of >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was meant to = be >>> used with the Client Registration Request and the Client = Registration >>> Response exchange. The 'registration_access_token' and >>> 'registration_client_uri' parameters are used in the response. >>>=20 >>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an = inconsistency: >>> The protocol interaction should either be >>>=20 >>>=20 >>> C -> AS: Client Registration Request >>> C <- AS: Client Registration Response >>>=20 >>> OR >>>=20 >>> C -> AS: Client Registration Request >>> C <- AS: Client Registration Error Response >>>=20 >>> Currently, sometimes the term "Client Registration Response" or = "Client >>> Information Response" is used. We need to fix this since it spills = over >>> to the management API document as well. >>=20 >> Client Information Response and Client Error Response are sub-classes = of Client Registration Response. If that=92s not clear from the current = document, please suggest new wording to make it clearer. >>=20 >>>=20 >>> Also, I noticed that we say that the server MUST support TLS 1.2 RFC >>> 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 anymore. >>=20 >> Kathleen made a similar comment on dyn-reg and suggested text that = we=92ll incorporate (unless there are objections from others on the = list). >>=20 >>>=20 >>> In Figure 1 it might be useful to indicate that exchanges A, B, C, = and D >>> are inherited from the dynamic client registration document and only >>> step D is enhanced with additional parameters, as described in = Section >>> 3.1. Furthermore, I wonder whether it would make sense to somehow >>> indicate in the figure that the endpoints are actually part of the >>> Authorization Server. >>=20 >> While they usually are the same in practice, these endpoints might = not be part of the Authorization Server =97 they might be part of a = separate (but related) service that handles objects of various kinds = within a security domain. No reason to tie them together unnecessarily.=20= >>=20 >> =97 Justin >>=20 >>=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BCB28D54-0A42-40FE-9D33-DB1A54E890EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hannes,

I=92ve had a chance = to more thoroughly re-read both the drafts and your notes, I think = you=92re actually correct about the IANA registration. We register = =93client_id=94 and =93client_secret=94, even though they can=92t be = requested by the client. As such, we do need to register = =93registration_access_token=94 and the =93registration_client_uri=94 in = the registry. We=92ll make sure those are in the next revision of the = document.

 =97 Justin

On = Nov 26, 2014, at 8:32 AM, Justin Richer <jricher@MIT.EDU> wrote:

And by = =936790=94 below I obviously mean RFC6749.

(Note to = self, don=92t write working group emails this early in the = morning.)

 =97 = Justin

On Nov 26, 2014, at 8:31 AM, Justin = Richer <jricher@MIT.EDU> = wrote:


On Nov 26, 2014, at 2:35 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:

Hi Justin,

thanks for your quick response. A few = remarks below.

On 11/24/2014 10:11 PM, Richer, Justin P. = wrote:
Hannes, thank you for the review. = Answers inline.

On Nov 24, 2014, at 3:09 PM, Hannes = Tschofenig
<hannes.tschofenig@gmx.net>= ; wrote:

Hi Justin, Mike, John, = Maciej,

as part of my shepherd write-up I carefully read through =
draft-ietf-oauth-dyn-reg-management-05. Overall the document is = in
good shape but I have a few minor clarification questions = that
should be resolved before the document goes to the = IESG.

In Section 1.4. "Registration Tokens and Client = Credentials" you
explain the different credential types and I was = wondering why you
aren't issuing client_secrets to all clients = instead of introducing
another credential, the registration access = token. While you try to
explain the reasons those appear somewhat = constructed. For example,
you say that "not all types of clients have = client credentials" but
you are the author of the specification and = you can essentially
decide what to do. The registration access token = is essentially the
same as the client credential since it is "is = uniquely bound to the
client identifier".

I believe we have = discussed this issue in the past but I don't
remember what the = reasoning was. Can you describe what your design
rational was (and = add it to the document)?

That's exactly the question = this section is trying to answer, and if
it can be made clearer then = please suggest some text that will help
that purpose. The rationale = for the registration access token is very
simple: we want to have a = means to call the management endpoint in a
protected manner, and = treating the management endpoint as an OAuth
Protected Resource makes = a lot of sense. RFC6750 gives us the means
to make an authorized call = to an API endpoint, so we're re-using that
instead of trying to = invent some other mechanism. Shouldn't we be
helping the world get = away from API passwords?

And it's very true that not every client = is going to have a client
secret to use at the token endpoint -- some = will have no use of one
(public and implicit clients) and some will = be using TLS or
asymmetric keys (JWT assertions, for instance) or = other mechanisms to
authenticate that don't involve the secret. = Instead of forcing these
clients to use a client secret for one new = endpoint, or forcing that
endpoint to potentially support the = infinite number of client
authentication mechanisms, we decided to = just use OAuth. These are
OAuth clients, remember -- they will *all* = have the ability to send
OAuth tokens to a protected resource already = built in.


Here is the point I don't quite get: = the registration access token is
essentially the same as a client = secret. You as a specification author
essentially decides whether = clients will get a client secret or a
registration access token. It = is under your control.

To be more specific, here is what you = could have done:

C -> S: Client Registration Request
C = <- S: Client Information Response (with new client secret)

C = -> S: Read or Update Request (with client id/client secret)
C = <- S: Client Information Response

Instead, you currently have = this exchange:

C -> S: Client Registration Request
C <- = S: Client Information Response (with new reg. access token)

C = -> S: Read or Update Request (with client id + reg. access = token)
C <- S: Client Information Response

Do you see the = similarity that I see?

For clients = that use a client secret to authenticate to the token endpoint, your = point makes sense, but for clients who would not otherwise have a client = secret, it doesn=92t. You end up with a confusing state where you=92re = giving somebody a =93client_secret=94 which is defined in 6790 to be = used at the token endpoint but then telling them not to use it at the = token endpoint (where they use something else or do=92t use it at all) = but to use it at this new endpoint instead. Can you see the confusion = point here? I think it=92s only going to get worse as we get more = clients that use auth mechanisms that don=92t depend on a shared secret = (public key, TLS, etc.). 

Instead we=92re = giving people an OAuth access token to access a protected API, something = that OAuth clients ought to know how to do anyway. This mechanism also = gives us an opportunity to potentially use the new PoP tokens (once = they=92re actually defined) in place of the bearer credential that=92s = defined today. 



In Section 1.4.1. = "Credential Rotation" you write:

" The Authorization Server MAY = rotate the client's registration
access token and/or client = credentials (such as a "client_secret")
throughout the lifetime of = the client. "

You might want to add reasons why the authorization = server may want
to take this step.

OK, but = there's nothing normative here in my view. It's basically up
to the = auth server to say "well let's make a new credential". Can = you
suggest text that would clarify = this?


What about making the spec simpler by not = allowing credential rotation?
Rekying is a useful concept under two = circumstances, namely
* when they provide a performance improvement = (such as it is the case
with session resumption in TLS where you can = do an abbreviated handshake
without all the heavy public key = crypto)
* when the entrophy of the key is exhausted, which typically = happens if
you exceed a number of data packets sent under a given = key. Often this
is tied to the way how freshness is ensured and the = need to avoid
encrypting data with the same initialization = vector/nonce twice.

Neither of these two cases seem to apply here = (IMHO).


Rekeying the = client is useful in a whole lot more cases than these two, and most of = them boil down to =93Something seems fishy=94. I think if anything we = need to eventually figure out how to do *more* secret rotation, = including a proactive mechanism started by the client (as Brian has = mentioned, among others). 




There are also a bit too many SHOULDs in the document. = Every time
you write SHOULD you have to keep in mind to tell the = reader what
happens in the other case. For example, in Section = Section 1.4.1
you write:

" The registration access token = SHOULD be rotated only in response
to an update request to the client = configuration endpoint, at
which point the new registration access = token is returned to the
client and the old registration access token = SHOULD be discarded by
both parties. "

Here the question = arises whether you are using the SHOULD to
indicate that the = authorization server does not always need to
rotate the registration = access token and if he does then is must
only happen in response to = an update request or does it indicate
that the authorization server = could also rotate it in response to
other = calls?

It's more that the server SHOULD NOT throw = out a registration access
token that a client still thinks is good = without some way to
communicate the new token to the client. Think of = it this way, you've
got the token, the server decides to chuck it on = you -- what do you
do? You can try calling your READ or UPDATE = operations to get the new
one but no dice, your token is bad. So what = we're saying here is not
to throw out the client's only means of = finding out if its keys are
good anymore.

I think = I got confused with the description of the state management = (as
described in the document). There is some fuzziness.

Here = I would prefer to have either no rekeying (which would make the
issue = go away) or a very deterministic way of rekeying.

I prefer the = former.

I=92m not a fan of enforcing = permanent credentials on the world. And we have the same construct with = refresh tokens today, for what it=92s worth.




Also, in the second line one would wonder why the old = registration
access token isn't mandatorily discarded. If there are = good
reasons, then tell the reader.

We've tried = to put requirements on the server discarding tokens in
the past, but = there was significant pushback from providers who use
non-revocable = time-limited tokens. Maybe they won't be doing that
here, for the = reason above.


I wouldn't reflect that in the = document. Of course, you can never be
sure that the implementation = really discards any state but for the
purpose of the protocol state = machine it is gone.


Furthermore, the text in Section 2.2 seems to contract = this
statement: " If the authorization server includes a new = client
secret and/or registration access token in its response, the = client
MUST immediately discard its previous client secret = and/or
registration access token. "

This is a = requirement on the client, not the server, so it's not
bound by the = token lifetime restrictions above. We're telling the
client to stop = using a secret or token after it's been given a new
one, that's = fine.

OK


In Section 2.2 you write: " = However, since read operations are
intended to be idempotent, the = read request itself SHOULD NOT cause
changes to the client's = registered metadata values. "

I am wondering whether this SHOULD = NOT statement adds a lot of
value since you allow the request to = change metadata values.

I think you're right, since = the metadata values might have changed
through outside forces since = the client last read, and all the
clients need to be able to deal = with that. We can remove that = line.

OK


You also write the security = consideration section: " the
registration access token MAY be rotated = when the developer or
client does a read or update operation on the = client's client
configuration endpoint. "

This means that the = content of the registration access token may
also change with a read = operation.

That's correct.

Terminology:

Sometimes you write "Client = Information Response" and sometimes
"client information response" The = same with "Authorization Server"
and "authorization = server"

They're all supposed to be lower cased, as = is the style in RFC6749. I
tried to bump everything down in a = previous edit but it looks like I
missed some.

Typo:

" Some values in the response, including the = "client_secret" and
r"egistration_access_token", MAY be = ^^^^^^^^^^^^^^^^^^^^^^^^^^^
different from those in the initial = registration response. "

Thanks, = noted!


In Section 2.4 "Client = Delete Request" you write:

" The authorization server SHOULD = immediately invalidate all
existing authorization grants and = currently-active tokens
associated with this client. "

Under = what circumstances wouldn't the authorization invalidate all
grants = and active tokens?

When it's using a non-revocable = stateless token and it can't
physically do that. Too bad 2119 doesn't = have MUST IF POSSIBLE or
equivalent.

Maybe it = would be good to add this information.

It might also be = worthwhile whether this notion of a non-vocable
stateless token = actually exists in this context since we are really
talking about the = same infrastructure here. This registration management
mechanism is = really very central to the authorization server (unlike
some other = access token mechanisms where we talk about the resource
server, = which may be in a different administrative domain = even).

Why doesn=92t the existing = SHOULD cover this?



You might also want to say = what tokens you are talking about since
there are at least the = following tokens around: - access tokens -
refresh tokens - = registration access tokens - initial access = token

OK, we can add that.


" If the server does not support the delete method, = the server
MUST respond with an HTTP 405 Not Supported. "

Why = aren't you demanding that the server must support this method?
This = would essentially mean that there would be some cases where =
deregistration isn't possible. Of course, there may be the = question
how important deregistration actually is if the registration =
automatically expires.

Because delete is not = always an easy operation to implement. The
client should be able to = call the endpoint with the DELETE verb and
at least know if it's = allowed to do that or not.

Hmmm. I didn't know that = the delete method is difficult to = implement.

Depends on your = infrastructure and how things get propagated between = components.




You write: " If the = client does not exist on this server, the
server MUST respond with = HTTP 401 Unauthorized and the registration
access token used to make = this request SHOULD be immediately
revoked. "

If the client = does not exist and someone sends a request with a
random registration = access token I am not sure what exactly you
want to revoke = here.

It's not the case of a random token, it's the = case of a client having
been deleted but using an otherwise valid = access token. If the
token's no good, you don't get this far -- you = return a 401 as
defined in RFC6750.

I guess it = might make sense to add this = information.

It=92s already in = there, in the paragraph just before the one you = quoted:

   If the =
registration access token used to make this request is not
   valid, the server MUST respond with an error as described in OAuth
   Bearer Token Usage [RFC6750].





In Section 3.1. "Client = Information Response" you state the new
elements that are returned to = the client. While the client_secret
has an expires_at field the = registration_access_token doesn't. Does
the expiry value of the = client_secret_expires_at automatically
indicate the lifetime of the =  registration access token? I think
so. But what happens if the = client_secret is not issued? To make it
more complicated you write = the following text in the security
consideration section:

" = While the client secret can expire, the registration access
token = SHOULD NOT expire while a client is still actively
registered. = "

There isn't a separate expiration for the = registration access token
because it's not supposed to = unceremoniously expire on a client. It
should be good until it gets = rotated out on a future read/update
operation or the client's = registration is no good anymore.

I think it might be = good to have a small section that explains how state
management = works.

Can you suggest text for this = beyond the paragraph that=92s already there?



The IANA consideration section is empty. Wouldn't it = be necessary
to register 'registration_access_token' = and
'registration_client_uri' into the OAuth Dynamic = Registration
Client Metadata Registry?

No, these = are not client metadata. The client can not send these in = a
registration request, so they don't need to be in = there.

Really?

I thought that the IANA = registry created with Section 5.1 of
http://too= ls.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was meant to be
used = with the Client Registration Request and the Client = Registration
Response exchange. The  'registration_access_token' = and
'registration_client_uri' parameters are used in the = response.

Looking again at draft-ietf-oauth-dyn-reg-20 I noticed = an inconsistency:
The protocol interaction should either = be


C -> AS: Client Registration Request
C <- AS: = Client Registration Response

=            OR
C -> AS: Client Registration Request
C <- AS: Client = Registration Error Response

Currently, sometimes the term "Client = Registration Response" or "Client
Information Response" is used. We = need to fix this since it spills over
to the management API document = as well.

Client Information Response = and Client Error Response are sub-classes of Client Registration = Response. If that=92s not clear from the current document, please = suggest new wording to make it clearer.


Also, I noticed that we say that the server MUST = support TLS 1.2 RFC
5246 and/or TLS 1.0. We definitely cannot say TLS = 1.0 anymore.

Kathleen made a similar = comment on dyn-reg and suggested text that we=92ll incorporate (unless = there are objections from others on the list).


In Figure 1 it might be useful to indicate that = exchanges A, B, C, and D
are inherited from the dynamic client = registration document and only
step D is enhanced with additional = parameters, as described in Section
3.1. Furthermore, I wonder = whether it would make sense to somehow
indicate in the figure that = the endpoints are actually part of the
Authorization = Server.

While they usually are the = same in practice, these endpoints might not be part of the Authorization = Server =97 they might be part of a separate (but related) service that = handles objects of various kinds within a security domain. No reason to = tie them together unnecessarily. 

 =97 = Justin



Ciao
Hannes


-- = Justin


___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

_______________= ________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

_________= ______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_BCB28D54-0A42-40FE-9D33-DB1A54E890EA-- --Apple-Mail=_41375217-C74B-4C13-9A4F-005899761A21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUe9DCAAoJEDPAngkbd+w99TgIAKYEc+nbF7p11Cg9SR43I9sd sobRj2aY24ARNcTS59vhQq8OK+KjPO1Oi72RwV7q44RDOsvlYFCQcCYsBZ6uCJZ1 KgJreUD1xla43ovCZSsFcUkZtE2EqkYHQk4WKuuh9MjsETJRkoAUGwdX9xvftRoh DjKgtpORf6cpTNtJ0hODL22Jnk41F/teuozjxcyZ3A/sNTv3ANyWNeEwCaFE0q+K /hszxl1bsKITF5X9xYp5F/jySE+wj45Ku7vhKidda4MbIaFelVlULHHCieCc2D1/ q4WN4rAcHoQTFZMQbdBcKzacwk0RkFW5chvGY5EstwmDJWNtY0JzYFpTgLI0BI4= =pvOH -----END PGP SIGNATURE----- --Apple-Mail=_41375217-C74B-4C13-9A4F-005899761A21--