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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Mon, 19 March 2018 02:55 UTC

Return-Path: <pkampana@cisco.com>
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 A00D2126BFD for <ace@ietfa.amsl.com>; Sun, 18 Mar 2018 19:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ALsK5ZrWMWuw for <ace@ietfa.amsl.com>; Sun, 18 Mar 2018 19:55:32 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBA4124BE8 for <ace@ietf.org>; Sun, 18 Mar 2018 19:55:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2119; q=dns/txt; s=iport; t=1521428132; x=1522637732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mktw9JnM5Bh+7wnIOMwq4xe8EiCHyFMxDRITe3FNg2A=; b=erlrUqoQcMKvbeLM8Blw4wXHmCN2bgyjd5HcOZGG+5RTxkZbbMm2WWbv dUN/ULFsZXe01jcp1nwBmvwYG26efeInhxT8pQNBYT5j0EZOQ3WUoUkU0 qiJyDCMMEE+Luv6XCDqoB71UwM0aTBf6kh5VPU0WFTbrCPqGA5oxT0TvV 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAQC4Ja9a/4kNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYNQZnIoCo1tjXiCA4EWlACCEgsfgVyDFQKDNSE0GAECAQEBAQEBAmsohSUBAQEDATo/DAQCAQgRBAEBAR4JBzIUCQgCBAENBQiFCAirNYhVgg6FM4IVgVWBVIMgim8DmDYJAo8ljTeQDgIREwGBKQEeOIFScBWCfQmQYnSPJ4EYAQEB
X-IronPort-AV: E=Sophos;i="5.48,328,1517875200"; d="scan'208";a="85409346"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2018 02:55:31 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w2J2tVnB029065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2018 02:55:31 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 18 Mar 2018 21:55:30 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Sun, 18 Mar 2018 21:55:30 -0500
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] draft-ietf-ace-coap-est-00
Thread-Index: AdO4tMNz0JYN1PFNQaWsBOIkt90Z7QBTmT+AAFp7tAgAPCRUgAAEht0AAJSvhwAAGsDXAA==
Date: Mon, 19 Mar 2018 02:55:30 +0000
Message-ID: <51de58f8d5ad4e0e97d84fbe39a921ae@XCH-ALN-010.cisco.com>
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> <30521.1521364074@dooku.sandelman.ca>
In-Reply-To: <30521.1521364074@dooku.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.244.54]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/oq54dA7ft2SFNNfSthd6xoaJBzw>
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: Mon, 19 Mar 2018 02:55:35 -0000

I think this is a terminology fix. Let's address it in the next iteration.

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Sunday, March 18, 2018 5:08 AM
To: consultancy@vanderstok.org
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-coap-est-00


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>, Sandelman Software Works  -= IPv6 IoT consulting =-