Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446B61A90F7 for ; Thu, 4 Jun 2015 13:14:53 -0700 (PDT) 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 0uvQms6ECZW6 for ; Thu, 4 Jun 2015 13:14:49 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47A1A90F3 for ; Thu, 4 Jun 2015 13:14:49 -0700 (PDT) X-AuditID: 12074422-f79c36d000000db3-66-5570b1b87ba7 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.E6.03507.8B1B0755; Thu, 4 Jun 2015 16:14:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t54KElbb013498; Thu, 4 Jun 2015 16:14:47 -0400 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 t54KEhfs029671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jun 2015 16:14:44 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <55707A56.5000105@bbn.com> Date: Thu, 4 Jun 2015 16:14:42 -0400 Message-Id: <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu> References: <556CACEC.2030501@bbn.com> <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> <55707A56.5000105@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTYRjmOzubZ7ojx+Ptc2bWwegiWkLF0hSDCP3Xj/YnoTpuX264GztT VCLNitJUStLMMi/T1BS8gLQU1EaMtMILSjrSvFDCTJBA0cjsnG1q0L/nfZ7nfd7343sJEf1L LCe0BgsyG1gdI/HFaWlwdIyty6Q8UXKfVrSW23wUTW9mxYquZ0CxWj+PJ+MpFSPKFGv3gCSl sXETS2lem8Mv4pd9z6qRTpuNzMeTrvlqfoy34KbeIZBT4XSAArBaC4qBlIDUSXivacWLQ+Do bIekGPgSNGXF4PRYA/AUnQC2Vb73FnMYbGhfw4WWQEoBF/s33ZikYuHCt0UfwSSiHgNYWNUi 8uTKYeGywz1DQh2Cta1OTMBS6jC0Od9JBIxTUfCjc9DNiygLrHniAp7QeLg9N+TmacoER6eW fAQcREXCdUcPP5jg8yPgWs/+hyCg+p81qv9do9odmw5/3m0We3A0fFm/7OWPwoEHzfj//BFY tP7I64+Er1eee/kz0Pp0yutPhM6yOsyDk+BCZYO4Dvi9AhFqfV6MntXqOKSK4VSswYDMMadi 9VpLLFJndQPhW33OMzaw+ZaxA4oAjIxUOIxKWsxmc7l6OwgjMCaYVHaYlLR/ulGdq2E5zVVz lg5xdhDFz1robBsFctxgNCAmiBy/yftINZubh8zGHVs4gTOhZPeG/yWaymAtKBMhEzLvqPsI goEk6uQbA8woA+Vc1+osezJGSO0AEjI+XCV4SM7E6jlthkcfBgfloeRtQaAEQZNl2O3dOVkX COWfFUhaBZeMP+jdbhcfjPHBn8XuYAu7J8kLgDwfk4ZoA/uM+ZPc8sj3+VsXBhlp6wBXVtlC 96ctnZ7culPsytCmTia0NG8t5YXFNemotiuJsxt+576ONdi2J3JlshtZqTXTwRMfhjscHaXh qOmLsaS6/MVA5HZpXVpCUec66q2a6Q2dSTNk2lXJ7a4+x58DjCpb/8nvty6ewTkNG3dMZObY v31I9MKNAwAA Archived-At: Cc: secdir Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 20:14:53 -0000 --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313 Content-Type: multipart/alternative; boundary="Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F" --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, > On Jun 4, 2015, at 12:18 PM, Stephen Kent wrote: >=20 > Justin, >=20 >=20 >> Stephen, thanks for the review. Comments inline. >>=20 >>> ... >>> The text says: >>>=20 >>>=20 >>> The introspection endpoint MUST be protected by a transport-layer = security mechanism as described in Section 4. >>>=20 >>>=20 >>> It might be clearer to say here that the token endpoint MUST = communicate security with the introspection endpoint, and that TLS 1.2 = is the mandatory-to-implement mechanism for such security. Also, the = text should be clearer about the relationship between an authorization = server and an introspection endpoint. In some places the two terms seem = to be used interchangeably. >>>=20 >>=20 >> This language was imported from the soon-to-be-published OAuth = Dynamic Registration drafts, including the forward reference. We don=E2=80= =99t want to repeat the requirement text. > I didn't review the dynamic registration docs, or I would have made = the same comment there :-). >=20 > If you don't want to repeat requirements text, then I suggest you = might re-word the sentence > I cited so that it's clearer. Saying that an endpoint must be = protected by a transport layer security mechanism seems needlessly = ambiguous. The section pointed to in the forward reference in that sentence has the = details. If you have a better way to word this, please suggest text. >=20 >=20 >> ... >>>=20 >>> How does a protected resource know which other parameters an = introspection endpoint requires/accepts? >>>=20 >>>=20 >>>=20 >>=20 >> We=E2=80=99re assuming it would be either an extension or = deployment-specific. > an extension to what? >=20 An extension to this specification that defines other parameters and = their meanings. > it seems that a primary motivation for this document is to fix = problems that arose > because of inadequate specifications for OAuth token syntax. In that = light, this description > of "other parameters" seems to perpetuate this sort of problem. I wouldn=E2=80=99t call OAuth having =E2=80=9Cinadequate=E2=80=9D token = syntax specification, it has *no* token syntax, and that=E2=80=99s on = purpose. This specification actually doesn=E2=80=99t define a token = syntax, either, but it defines a web API for getting token information = regardless of the token syntax. The token itself can still be a signed = JWT, or a UUID, or a random hex blob; OAuth doesn=E2=80=99t care, and = that=E2=80=99s a good thing. >>=20 >>=20 >>>=20 >>> This section mandates (MUST) protection against =E2=80=9Cunauthorized = token scanning=E2=80=9D but mandates no standard way to do so. [Also, = when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)] >>>=20 >>>=20 >>=20 >> Is there something more specific we can recommend here? Perhaps in = the security considerations section. > yes, the SC section is where there should be suggestions on how to = protect against such attacks. if you can't recommend something specific, = then mandating that something be > done seems possibly vacuous, a MUST that will never be realized in = practice (see RFC 6919). OK, we=E2=80=99ll try to add some more examples. Cute reference. >>=20 >> And the attack could actually take place where an authorized = protected resource goes fishing for other valid tokens. The = attack isn=E2=80=99t authorized, but the client is =E2=80=A6 and yes = that=E2=80=99s not what we meant but I=E2=80=99m sticking to it. ;) > so, as I said, the attack is not authorized, and the phrase = "unauthorized attack" will > make most security experts cringe. is cringing a goal? We can change the wording to reduce the cringe level. >>=20 >>> ... >>> IANA must only accept registry updates from the Designated Expert(s) >>>=20 >>> and should direct all requests for registration to the review = mailing >>>=20 >>> list. >>>=20 >>>=20 >>> How about: >>>=20 >>>=20 >>> IANA MUST accept registry updates only from the Designated Expert(s) >>>=20 >>> and SHOULD direct all requests for registration to the review = mailing >>>=20 >>> list. >>>=20 >>=20 >>=20 >> This text was imported from a template, I=E2=80=99d be glad to change = it if there=E2=80=99s a better one. > one should not assume that a doc that has made it through the RFC = approval process > is perfect. >>=20 >>>=20 >>> Section 3.1.1 >>>=20 >>>=20 >>> If a proposed Name matches one already registered as per 7519, ought = it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2=80= =9D) definition if it is to be accepted? >>>=20 >>>=20 >>>=20 >>=20 >> It really is comparable, since the contexts are pretty different. > if the contexts are so different, and thus the semantics are not = equivalent, why is the reuse of the name, and the potential confusion = acceptable? Besides, if we simply prohibit reuse of the name, we=E2=80=99ll have = similar-but-confusing names, like =E2=80=9Cexpires=E2=80=9D vs. = =E2=80=9Cexp=E2=80=9D, in the two different places. The meanings are = close enough, with the details being context-specific, that the names = should be the same. Previously it was the same registry, but that was = causing even more confusion. >>=20 >>>=20 >>> Section 4 >>>=20 >>>=20 >>> The text lists four checks to be performed by an authorization = server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80= =9D A more normative introduction would seem appropriate here. I realize = that the text says that not all of these checks may be applicable in all = OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the = token =E2=80=A6=E2=80=9D isn=E2=80=99t that a sufficient caveat? >>>=20 >>>=20 >>>=20 >>=20 >> This is not a normative requirement, since everything is contextual = to the nature of the tokens issued by the authorization server. > so you're saying that there is no set of checks that every = authorization server > can be expected to perform? not even token expiration? >=20 That=E2=80=99s correct. Not all tokens expire, so it doesn=E2=80=99t = make sense to mandate checking for expiration. Every recommendation here = is something that at least one known implementation of this protocol = already does in the wild, but not every implementation does every check = because it simply doesn=E2=80=99t make sense to do so. That=E2=80=99s = why the checks are phrased as =E2=80=9Cif the token=E2=80=9D and the = list is given as a =E2=80=9Cfor instance=E2=80=9D example of what to do. = We would also expect a server implementation to implement any other = checks that it might have in store, like =E2=80=9Cis my database online = and can I find the token in the these-are-valid-tokens table=E2=80=9D. =E2=80=94 Justin >=20 > Steve >=20 --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stephen,

On Jun 4, 2015, at 12:18 PM, = Stephen Kent <kent@bbn.com> wrote:

=20
Justin,


=20 Stephen, thanks for the review. Comments inline.

...

The = text says:   =

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It = might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.


This language was imported from the = soon-to-be-published OAuth Dynamic Registration drafts, including the forward reference. We don=E2=80=99t want to repeat the requirement = text.
I didn't review the dynamic registration docs, or I would have made the same comment there :-).

If you don't want to repeat requirements text, then I suggest you might re-word the sentence
I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous.

The section pointed to in the forward reference in = that sentence has the details. If you have a better way to word this, = please suggest text.



...

 

How does a protected resource know = which other parameters an introspection endpoint requires/accepts?

 


We=E2=80=99re assuming it would be either an = extension or deployment-specific.
an extension to what?


An extension to this specification that defines = other parameters and their meanings.

it seems that a primary motivation for this document is to fix problems that arose
because of inadequate specifications for OAuth token syntax. In that light, this description
of "other parameters" seems to perpetuate this sort of problem.

I = wouldn=E2=80=99t call OAuth having =E2=80=9Cinadequate=E2=80=9D token = syntax specification, it has *no* token syntax, and that=E2=80=99s on = purpose. This specification actually doesn=E2=80=99t define a token = syntax, either, but it defines a web API for getting token information = regardless of the token syntax. The token itself can still be a signed = JWT, or a UUID, or a random hex blob; OAuth doesn=E2=80=99t care, and = that=E2=80=99s a good thing.




 

This = section mandates (MUST) protection against =E2=80=9Cunauthorized token scanning=E2=80=9D = but mandates no standard way to do so. [Also, when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)]



Is there something more specific we can = recommend here? Perhaps in the security considerations section.
yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be
done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919).

OK, = we=E2=80=99ll try to add some more examples. 

Cute reference.


And the attack could actually take place where = an authorized protected resource goes fishing for other valid tokens. The attack isn=E2=80=99t authorized, but the client = is =E2=80=A6 and yes that=E2=80=99s not what we meant but I=E2=80=99m = sticking to it.  ;)
so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will
make most security experts cringe. is cringing a goal?

We = can change the wording to reduce the cringe level.


...
=

IANA must only accept registry = updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How about:

 

IANA MUST accept registry = updates only from the Designated Expert(s)

and SHOULD direct all requests for registration to the review mailing

list.



This text was imported from a template, I=E2=80=99= d be glad to change it if there=E2=80=99s a better one.
one should not assume that a doc that has made it through the RFC approval process
is perfect.

 

Section 3.1.1

 

If a proposed Name matches one = already registered as per 7519, ought it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2= =80=9D) definition if it is to be accepted?

 


It really is comparable, since the contexts = are pretty different.
if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable?

Besides, if we simply prohibit reuse of the name, = we=E2=80=99ll have similar-but-confusing names, like =E2=80=9Cexpires=E2=80= =9D vs. =E2=80=9Cexp=E2=80=9D, in the two different places. The meanings = are close enough, with the details being context-specific, that the = names should be the same. Previously it was the same registry, but that = was causing even more confusion.


 

Section 4

 

The text lists four checks to be = performed by an authorization server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80=9D A = more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the token =E2=80=A6= =E2=80=9D isn=E2=80=99t that a sufficient caveat?

 


This is not a normative requirement, since = everything is contextual to the nature of the tokens issued by the authorization server.
so you're saying that there is no set of checks that every authorization server
can be expected to perform? not even token expiration?


That=E2=80=99s correct. Not all tokens expire, so = it doesn=E2=80=99t make sense to mandate checking for expiration. Every = recommendation here is something that at least one known implementation = of this protocol already does in the wild, but not every implementation = does every check because it simply doesn=E2=80=99t make sense to do so. = That=E2=80=99s why the checks are phrased as =E2=80=9Cif the token=E2=80=9D= and the list is given as a =E2=80=9Cfor instance=E2=80=9D example of = what to do. We would also expect a server implementation to implement = any other checks that it might have in store, like =E2=80=9Cis my = database online and can I find the token in the these-are-valid-tokens = table=E2=80=9D. 

 =E2=80=94 = Justin


Steve


= --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F-- --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313 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----- iQEcBAEBCAAGBQJVcLGzAAoJEDPAngkbd+w9wpMIAJzawC33msxV5MTEaOUyhD2t oVmX+mSsnL+tOCBw3H88bOZAl7lOLyRL31Q4xSqeJaTMfkISyg+SAtayY705VH8U Rnez9RrP/cE0ElbQSDoaROTh4oaVDBYUwzcVXp1WrhPwUAYgA9f35qOf1dZhQJH4 aBp4IniNoE3GSmnqQDf2BKOAXiWWebwK8C8RNsW2729/sgujYVq+U2BpMBYrG93H skeCOLlcO5S2eo1iZHzenSo2FftlhZan3Q/2jv3dET7rTiJtQOYJgEpGgwRUL6Tf cD1aGPj5H+mo5gNaBJgyh5MizvIQZ995Z+C903siA/aYR/A1WOxPQKXYikp86O0= =G/1V -----END PGP SIGNATURE----- --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313--