[Ace] draft-erdtman-ace-rpcc and RFC7521

Samuel Erdtman <samuel@erdtman.se> Thu, 17 August 2017 09:14 UTC

Return-Path: <samuel@erdtman.se>
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 A4C3B13281A for <ace@ietfa.amsl.com>; Thu, 17 Aug 2017 02:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
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 X_r0l2Lbuuw2 for <ace@ietfa.amsl.com>; Thu, 17 Aug 2017 02:14:24 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D3A13281D for <Ace@ietf.org>; Thu, 17 Aug 2017 02:14:22 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id t80so11444563pgb.5 for <Ace@ietf.org>; Thu, 17 Aug 2017 02:14:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LgmQdfraPoMGYELOHapmgystoHsqp4Z3jMKUUiCm45A=; b=hPo0vXRLWJoOuSrJ4+mjg1mMvmoiTIADtqFtJqjCaO7+K+vjOAgVWdGAp5Nq/HNpTK t/ufq3ODpcdssTmO5sxIq0Djit0wdyrdVRzoFasbMC4nsletVUcz001vFewpVSxMVzRA k9smYg6hbqy+OPPjw4Xjd2b4KIDCbML/plKJtj+FPRTOsmaWs/jib7o9kQjbEPy0tmhQ Ra+PKuBBYdH5n1KcUHnEq19wZFXAUYylW37Q+Zp3X0X3EwU6aHxBreDECAb4bp1Bh33u kVtG1t1bmiOtkvQ+kWMub/h7YB25oNvgYAAoAPZbxq1aNlKfzZIpHla/eAbD+8G4kH+v hvng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LgmQdfraPoMGYELOHapmgystoHsqp4Z3jMKUUiCm45A=; b=FhQ3FQ/vTmdqE44w9ZyBQqnjCImIfsb1ssTa3PkzRRzff5d/pqqHP5J4s/1hJ0xUK8 iV8syT9en23NJyJ0Y0IlaqVEut8h1y5rIDgeOXYRtQH+tOPfkZMJP9i58SDbRJoSDiAt QLt37XQEGloaxug2cT6W0HUPRZCeeJm/+yEVmAlNwccwNkMz0ZNiGScq9hD4WT7VIlTM eS2C3ii12sUdVlw+t7DoZEfdg73W7XH3IjMO1fDlRzbYEc492KczuWDwpaZ+SosMy2Eg sexbaSrBx1y4C/qVhAiMXbyE6iRcZCmC6Ytfzt3RQE3en1fJh6XDesWM66qUM+WfzTfJ JDfw==
X-Gm-Message-State: AHYfb5iyqn5AEwV8PXI0IbcfB8gYY2O8k0WL4l4ve4Fgy46Pk+XYbAIb hEOtSSUORnUCNwQS/agCnPeT8+bKRl/+r9uofg==
X-Received: by 10.98.198.72 with SMTP id m69mr4571375pfg.188.1502961261600; Thu, 17 Aug 2017 02:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.151.67 with HTTP; Thu, 17 Aug 2017 02:14:21 -0700 (PDT)
From: Samuel Erdtman <samuel@erdtman.se>
Date: Thu, 17 Aug 2017 11:14:21 +0200
Message-ID: <CAF2hCbaH6+zwXu=Aww_eSLuuzPn7RnqWXOu0YN91_p5KP+psYw@mail.gmail.com>
To: ace <Ace@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="94eb2c0c3e6c1bf92a0556ef706b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/oKH9i10fcU18m8jIT1P6bBcarpA>
Subject: [Ace] draft-erdtman-ace-rpcc and RFC7521
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: Thu, 17 Aug 2017 09:14:27 -0000

Hi Mike and others,

During the ACE session at the IETF meeting in Prague I presented
draft-erdtman-ace-rpcc and Mike asked how it relates to RFC7521.

Here comes a short summary, hope is clarify things.

One could probably achieve something similar to what we want by creating a
profile of the RFC7521 framework. However I think we would end up with
something much more complex than what we need with much more work.

The case we want to solve is authentication of the client for interactions
with endpoints such as token and introspection (with something more
suitable for constrained devices than client_secret i.e. a password).
We assume that the client has a key to use for the authentication a
Raw-Public-Key (RPK) or a Pre-Shared-Key (PSK)

If we look at draft-ietf-oauth-mtls it defines how to do client
authentication with a certificate. The functionality for client
authentication with certificates are wide spread and well understood, i.e.
cheep to implement.
In our case we similarly want to piggyback on the availability of RPK and
PSK authentication, we do not want to define a new Holder-of-Key schema and
put it on top of (D)TLS. RFC7521 does not define a solution for holder of
the Holder-of-Key Assertions, so we would have to do that.

Based on this we think it would be valuable to have a specification that
defines how to use RPK and PSK for client authentication before it becomes
defined in the wild (like with certificates).

Best regards
//Samuel