Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

Justin Richer <jricher@mit.edu> Thu, 11 June 2015 20:05 UTC

Return-Path: <jricher@mit.edu>
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 4DE911B311B; Thu, 11 Jun 2015 13:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p6KqHhsL4nKw; Thu, 11 Jun 2015 13:05:07 -0700 (PDT)
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 347F31B30A0; Thu, 11 Jun 2015 13:05:06 -0700 (PDT)
X-AuditID: 12074423-f79496d000000d43-a7-5579e9f1ff1c
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-6.mit.edu (Symantec Messaging Gateway) with SMTP id DB.5B.03395.1F9E9755; Thu, 11 Jun 2015 16:05:05 -0400 (EDT)
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 t5BK54Y8015991; Thu, 11 Jun 2015 16:05:04 -0400
Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BK50PI014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 16:05:02 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CALaySJ+XpvcnStdK3JC_3j9ztQVaRVc0OK=hTOQB2eO06C_XZg@mail.gmail.com>
Date: Thu, 11 Jun 2015 13:04:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE7633AA-BC8A-4E16-B434-9B17D897AB82@mit.edu>
References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> <A62D61C9-C6A0-4988-B7DC-73B39F69FCD5@mit.edu> <CALaySJ+XpvcnStdK3JC_3j9ztQVaRVc0OK=hTOQB2eO06C_XZg@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixG6nrvvxZWWowa3VxhaHFl9itTi76Ta7 xYrl5RYvFu9ktpjxZyKzxe25K9ksTr59xebA7tGyqpfZY8mSn0wBTFFcNimpOZllqUX6dglc GS1NHUwFL0QrLryYxtLA2CHYxcjJISFgInH62TdGCFtM4sK99WxdjFwcQgKLmSS+35vLBOFs ZJSYdeY6O4Szlkni78T/YC3MAuoSf+ZdYgaxeQX0JB49fcwOYgsLpEscf/iWDcRmE1CVmL6m hQnE5hQIlOjc/5kVxGYBiq/Z/BpsHbPAL0aJ5p1fmSCGakssW/gaaqiVxL62qVBnbGGU+Lnz BNhUEQFNieefpwAlOIAOl5X4ulVuAqPgLCQ3zUJy0ywkYxcwMq9ilE3JrdLNTczMKU5N1i1O TszLSy3SNdPLzSzRS00p3cQIDnoX5R2Mfw4qHWIU4GBU4uGtOFERKsSaWFZcmXuIUZKDSUmU d/+NylAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzbrwLleFMSK6tSi/JhUtIcLErivJt+8IUI CaQnlqRmp6YWpBbBZGU4OJQkePOB0S0kWJSanlqRlplTgpBm4uAEGc4DNDwEpIa3uCAxtzgz HSJ/ilFRSpz35wughABIIqM0D64XlpReMYoDvSLMuwykigeY0OC6XwENZgIavJC5HGRwSSJC SqqBsSKSp3qPwU8/dctdNZ9nmd1nnKwmf0xW3DFYyVbareeC5lF/kUWnv7pvcxVhVG0/vFQ1 65OmwiH9rfsuTGnyYuznCdT62ROr1mbhFm/SM7l2/cYT10SVJlxK0Bf/+etkflnX/9niqskV io1aZ3bXmtqtWeOovy1CbGPc0qNG/5bJzbacs3yxEktxRqKhFnNRcSIAsFtdNiUDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/c8FYPrt30RtH-aBt9OE2s_qpoe4>
Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG <iesg@ietf.org>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 20:05:09 -0000

> On Jun 9, 2015, at 9:57 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
> Hi, Justin.  Thanks for the response and discussion.
> 
>>> -- Section 2 --
>>> 
>>>   The introspection endpoint MUST be protected by a transport-layer
>>>   security mechanism as described in Section 4.
>>> 
>>> I know what it means for a communication path to be protected by TLS, but
>>> I don't know what it means for an endpoint to be.  Can you explain that?
>> 
>> The gist is simple: It must be served over HTTPS, not HTTP.
> 
> Right; that's protecting the communication path.  So I suggest this
> (and it's a minor point; I'm OK with no further discussion, whether
> you agree with the change or not):
> 
> NEW
>   The introspection communication path MUST be protected by a
>   transport-layer security mechanism as described in Section 4.
> END
> 
>>> -- Section 2.1 --
>>> The server MUST support POST, and MAY support GET.  What's the value in
>>> that?  I don't see any way for a client (I mean HTTP client, not Oauth
>>> client, here) to know, so all clients will have to send POST to be sure
>>> it will work.  Are you really expecting to have clients that want to ask
>>> this, but that can't send POST?  Given that you call out privacy concerns
>>> with GET, I don't see why it's there at all.
>> 
>> GET is a deployment optimization that some servers will offer, and the
>> OAuth client will tell the HTTP client which verb to use. The OAuth client
>> might know through configuration (assuming a tighter coupling than
>> defined by the interoperable protocol)
> 
> Two things:
> 
> 1. Why is GET an optimization?  It has privacy disadvantages, and I
> don't see any advantages.
> 
> 2. This "tight coupling" thing is something that I think weakens the
> interoperability of the OAuth protocol in general, and I've never
> liked it.  In this case, in particular, I don't see any advantage to
> it, and I don't understand why it's useful to have an option that only
> works if you have inside knowledge, for no benefit.
> 
> Why is it ever good to have clients that only work with certain
> servers, when it's just as easy to make sure that all clients work
> with all servers?
> 
> Barry


I can see your point here, and others have raised it as well. Part of the reason the GET option is there is that most (if not all) of the existing implementations of this protocol enable it anyway. Having thought about this a bit, I would be fine with simply saying that POST is required and remaining silent on other methods in the main section. We can keep the warnings against also allowing GET in the security considerations. Will that work?

 — Justin