IETF Logo Mail Archive

Re: [Ace] [OAUTH-WG] New OAuth client credentials RPK and PSK

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 13 May 2017 10:00 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4EA12955A; Sat, 13 May 2017 03:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.279
X-Spam-Level: *
X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 TqcPHygGsH_s; Sat, 13 May 2017 03:00:11 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDEF1293DF; Sat, 13 May 2017 02:58:04 -0700 (PDT)
Received: from [80.187.102.33] (helo=[10.155.159.117]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1d9ToH-0007sD-TK; Sat, 13 May 2017 11:58:02 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <CAF2hCbZpWTCMg617dK7D+F+0w=hxrz4VNdsFZHPGM1rZy+K3TA@mail.gmail.com>
Date: Sat, 13 May 2017 11:58:01 +0200
Cc: "<oauth@ietf.org>" <oauth@ietf.org>, ace <Ace@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <22C1AD59-1B76-4596-AAFB-2CF1770FA58B@lodderstedt.net>
References: <CAF2hCbZpWTCMg617dK7D+F+0w=hxrz4VNdsFZHPGM1rZy+K3TA@mail.gmail.com>
To: Samuel Erdtman <samuel@erdtman.se>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ZmIIVWE2UxCvtRrfZXjOrGwQCFg>
Subject: Re: [Ace] [OAUTH-WG] New OAuth client credentials RPK and PSK
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 May 2017 10:00:14 -0000

Hi Samuel,

as far as I understand your draft, it utilizes results of the (D)TLS client authentication for authentication towards the tokens endpoint - similar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you intend to also utilize the binding of the access token to a certain key pair as described in oauth-ietf-mtls?

best regards,
Torsten.

> Am 12.05.2017 um 10:03 schrieb Samuel Erdtman <samuel@erdtman.se>:
> 
> Hi ACE and OAuth WGs,
> 
> I and Ludwig submitted a new draft yesterday defining how to use Raw Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.
> 
> We think this is valuable to the ACE work since the ACE framework is based on OAuth, but client credentials as defined in the OAuth framework are not the best match for embedded devices.
> 
> We think Raw Public Keys and Pre Shared Keys are more suitable credentials for embedded devices for the following reasons:
> * Better security by binding to transport layer.
> * If PSK DTLS is to be used a key need to be distributed any way, why not make use of it as credential.
> * Client id and client secret accommodates for manual input by a humans. This does not scale well and requires some for of input device.
> * Some/many devices will have crypto-hardware that can protect key material, to not use that possibility would be a waste.
> * There are probably more reasons these was just the once on top of my head.
> 
> This is not the first resent initiative to create new client credential types, the OAuth WG adopted a similar draft for certificate based client credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That work is also valuable to ACE but not all devices will be able to work with certificates or even asymmetric cryptos .
> 
> Please review and comment.
> 
> Cheers
> //Samuel
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email