Re: [Ace] draft-ietf-ace-coap-est-00

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 18 March 2018 09:08 UTC

Return-Path: <mcr@sandelman.ca>
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 37686127058 for <ace@ietfa.amsl.com>; Sun, 18 Mar 2018 02:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ADSVo_nZTztF for <ace@ietfa.amsl.com>; Sun, 18 Mar 2018 02:08:28 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5616B1200FC for <ace@ietf.org>; Sun, 18 Mar 2018 02:08:28 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 9313F1F95D; Sun, 18 Mar 2018 09:08:26 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0EFEA5F3; Sun, 18 Mar 2018 09:07:54 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: consultancy@vanderstok.org
cc: ace@ietf.org
In-reply-to: <00435523cc9b3c1969a026200260a373@xs4all.nl>
References: <001d01d3b8b4$f6e71600$e4b54200$@augustcellars.com> <e426d5786082bdc863fbe6a5960c112b@xs4all.nl> <24297.1520991636@obiwan.sandelman.ca> <d716e4e92bcd44b891469a7f6a92598d@xs4all.nl> <25902.1521100857@dooku.sandelman.ca> <00435523cc9b3c1969a026200260a373@xs4all.nl>
Comments: In-reply-to peter van der Stok <stokcons@xs4all.nl> message dated "Thu, 15 Mar 2018 11:10:34 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sun, 18 Mar 2018 09:07:54 +0000
Message-ID: <30521.1521364074@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/FrqQSS6bSVpnDHuU2IPy2QHOiqQ>
Subject: Re: [Ace] draft-ietf-ace-coap-est-00
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: Sun, 18 Mar 2018 09:08:30 -0000

peter van der Stok <stokcons@xs4all.nl> wrote:
    >> Let me delete "Join" from above sentence.
    >>
    >> A device that terminates the DTLS security (CoAPS) and then talks to the CA
    >> is a Registration Authority according to EST and RFC5280.  It's not a
    >> proxy.
    >> (And it doesn't matter if it speaks HTTPS or CMS or CMP or
    >> super-pigeon-telepathy
    >> to the CA)

    > A http/coap proxy  is specified in RFC8075. It explains "how an HTTP request
    > is mapped to
    > a CoAP request and how a CoAP response is mapped back to an HTTP
    > response".

    > In the est-coap draft DTLS and TLS connections are terminated in the
    > http/coap proxy, and the proxy is therefore connected to an RA (possibly
    > running on the same host as the proxy).

    > Where is my terminology going astray?

In the EST context, if it's a device with a (D)TLS connection to the Pledge
(the device enrolling) and a TLS connection to the PKI CA, then it's a
Registrar, not an http/coap proxy.   It may have the same apparent
connectors, but it processes the content.

I can't come with any pure-7030 situations where this official MITM
could be accomodated between the 7030 client and 7030-registrar.

Perhaps this represents that for generic-7030 use involving COAP+DTLS,
that a very clear applicability statement will need to detail what the
initial EST trust is.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-