[OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 21 August 2014 18:39 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 507DE1A0316 for <oauth@ietfa.amsl.com>; Thu, 21 Aug 2014 11:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 PBoZe3PKI99Z for <oauth@ietfa.amsl.com>; Thu, 21 Aug 2014 11:39:24 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3511A6FA8 for <oauth@ietf.org>; Thu, 21 Aug 2014 11:39:12 -0700 (PDT)
Received: from [172.16.254.100] ([80.92.114.249]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lfppu-1WZrr92aoU-00pJt4; Thu, 21 Aug 2014 20:38:57 +0200
Message-ID: <53F63F82.9070508@gmx.net>
Date: Thu, 21 Aug 2014 20:50:42 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="3okbeOiMqO6P6H51hFGAsbtoFfxemd6UX"
X-Provags-ID: V03:K0:yLLcxcfw+SA2nxEv3m7LIFix/qHKAm+HiOBqnWvF26yfUxQaeqh 3eKk2caez0vswi57j/RHCfbUtJB3a++mNLo5PXzYhg/edQKyf/1+fcA6mtQJT2e67N+FeWS oaY5qdxYCUDMFAb4FdXBMYmVtpbEA+P5aFBFqAd+jArWvMYs5mRZH1IoL/P1x8oQRY6a0GI Ld2ofVFqMuOgSQOOSqbWg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6GzptCFocJN93IJMX4d8vM-N6mY
Cc: sperreault@jive.com, draft-ietf-tram-turn-third-party-authz@tools.ietf.org, "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
Subject: [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01
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, 21 Aug 2014 18:39:26 -0000
Hi all, Simon asked us (Derek and myself) to do a quick review of this document developed within another working group that happens to use OAuth. * Background TURN is a special tunnelling gateway (very much like an IPsec gateway would be) but designed specifically to relay voice/video traffic. To prevent attacks a TURN client (such as a VoIP phone) uses a shared secret (username & password) with the TURN server (=gateway). So, if Alice calls Bob and uses a TURN server then her VoIP client uses SIP or WebRTC (as a signaling protocol) to establish the necessary communication so that voice packets can be exchanged between the two VoIP clients with the help of the TURN server. The main idea of this document is to re-use OAuth to authorize the use of this TURN server. * The Design I would have used OAuth as is (or maybe selected a specific grant type) to obtain an access token. Then, I would have defined how the access token is carried in the TURN protocol. This is a bit similar what we have already done with the OAuth SASL draft where we defined a new way to convey the access token from the SASL client to the SASL server. How did the authors solve that problem? They pretty much did what I just explained. Since TURN does not use DTLS (or TLS) the proof-of-possession security work we are doing becomes relevant (namely the symmetric key-based part). Putting discovery information in-band into the exchange is also find (which is what we did in the SASL document). Instead of using the JWT access token format the authors have defined a new, binary encoding to keep the size smaller. The OAuth framework allows other token formats to be used - so that's fine as well. (As a minor remark, I would use AEAD ciphers here since that's what everyone is doing noways.) Two things surprised me: a) The spec leaves the way to obtain the access token pretty much open. A big benefit from using OAuth is that there is a protocol mechanism defined for getting the access token. You could, for example, recommend using authorization code flow. This concerns the text written in Section 4. b) You describe a key establishment scheme to be used between the resource server and the authorization server. What assumption do you make about the relationship between the authorization server and the resource server? Are they supposed to have a business relationship or some other relationship with each other? Minor aspects: * Would the TURN server name really be an email alike address rather than a URI? * Would you use Dynamic Client Registration to provision the client with the necessary parameter? Is there the expectation that random clients would work with random authorization servers? * Wouldn't you want to define a scope value for use with the TURN service so that the authorization server is able to restrict the access token for use with TURN only? * Crypto algorithm negotiation: would you expect the authorization server to tell the client what crypto algorithms to use (since the authorization server not only needs to share a key with the resource server but also needs to have knowledge about the supported cryptographic algorithms)? * In your TURN <-> OAuth terminology mapping you say that the resource owner corresponds to the RTCWeb server. I don't think that's true. The resource owner is the user but I believe you are trying to say that the user grants authorization implicitly by making a WebRTC call. Ciao Hannes
- [OAUTH-WG] Review of draft-ietf-tram-turn-third-p… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-tram-turn-thi… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Review of draft-ietf-tram-turn-thi… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-tram-turn-thi… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Review of draft-ietf-tram-turn-thi… Eve Maler
- Re: [OAUTH-WG] [tram] Review of draft-ietf-tram-t… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] [tram] Review of draft-ietf-tram-t… Brandon Williams