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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Sat, 17 March 2018 17:41 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 0141212711E for <ace@ietfa.amsl.com>; Sat, 17 Mar 2018 10:41:24 -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 1NTRr_Jq0ZwP for <ace@ietfa.amsl.com>; Sat, 17 Mar 2018 10:41:22 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E0C12025C for <ace@ietf.org>; Sat, 17 Mar 2018 10:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3291; q=dns/txt; s=iport; t=1521308482; x=1522518082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T6eAKq2pdL4PhJobmAaj5JvKIjoHk2jf7b0vl5tyi5Y=; b=DbGX46K5DvVLuih0UArEELUjEccPAPFFBtqs+X72VJBVpv9jHtxpbx/I kbIbSJJ77ht+i6gfrqU2hKBwW58a0NcBmbeT8nmN5HkEHjsebm0Oz4agk uJ90s7Tk2NrfAR8QTajxLL+BNKPN/wWipdQNUwTCnBMhMRdTv+MBwd28j A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAAB0Uq1a/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNQZnIoCo1tjXiCA4EWlACCEgsYC4RtAoM1ITQYAQIBAQEBAQE?= =?us-ascii?q?CayiFJQEBAQQBATg0BAcMBAIBCBEEAQEBHgkHJwsUCQgBAQQBDQUIhRAPriWIV?= =?us-ascii?q?YIJBYUzghWBVYFUgyCDHgEBgVCFfwOROYZ9CQKPJY03kA4CERMBgSkBHjiBUnA?= =?us-ascii?q?VOoJDkGt0jweBGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.48,321,1517875200"; d="scan'208";a="85513323"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2018 17:41:21 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w2HHfLF2013162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 17 Mar 2018 17:41:21 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 17 Mar 2018 12:41:20 -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; Sat, 17 Mar 2018 12:41:20 -0500
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, "Michael Richardson" <mcr+ietf@sandelman.ca>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] draft-ietf-ace-coap-est-00
Thread-Index: AdO4tMNz0JYN1PFNQaWsBOIkt90Z7QBTmT+AAFp7tAgAPCRUgAAEht0AAGivJ+A=
Date: Sat, 17 Mar 2018 17:41:20 +0000
Message-ID: <9cdd4bec69e643f88d4ca1767ed2c6f8@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>
In-Reply-To: <00435523cc9b3c1969a026200260a373@xs4all.nl>
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.248.2]
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/Osqh24_bwd36dxyglGzmEEyUiVk>
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: Sat, 17 Mar 2018 17:41:24 -0000

Sorry, getting to this late. 

Thank you Jim for the feedback.

I think an good point comes out of this discussion. We need to articulate the RA role that could at the same time act as a proxy. An RA usually performs authentication/authorization before relaying to the CA that already has a predetermined relationship with. A proxy acts as a plain COAP2HTTP translator that does not necessarily perform any authentication or authorization of the client. In either case ESP PoP cannot be performed as DTLS to the client is terminated in the middle. 

In summary, reading this discussion I see these things to improve in the draft 
- Clarify DTLS 1.2 and 1.3 in the DTLS section.
- Clarify the use of COSE or CMS for server-side keys and chose the MTI. I don't think COSE just for the keys while we use ASN.1 DER for ca/enrolled certs will buy us much. And it will alter server-side key generation messages defined in RFC7030. I think introducing COSE for these messages is fine as long as it is conveyed in the response headers and they key establishment is clear. Given that we have a way of doing it based on RFC7030, I think this falls out of scope for this draft. 
- Add text about short and long names
- Proxy and RA clarification in Section 6.
- Be explicit about the proxy getting the whole message before forwarding in Section 6. 

Rgs,
Panos


-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: Thursday, March 15, 2018 6:11 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-coap-est-00



Michael Richardson schreef op 2018-03-15 09:00:
> peter van der Stok <stokcons@xs4all.nl> wrote:
>     >> >> DTLS connection is going to be required to act as an RA.  RAs
>     >> are required
>     >> >> to have the entire request for adding authentication as 
> necessary.
>     >>
>     >> > This is visible in the figure of section 6, but needs 
> elaboration in
>     >> the
>     >> > text.
>     >>
>     >> I don't understand why we have that paragraph.
>     >> An end point that terminates the Pledge (D)TLS connection and 
> acts as
>     >> an RA *IS* a Join Registrar, not a Proxy.
>     >>
> 
>     > Thus is outside the BRSKI context, and thus a proxy with RA 
> (separate or not)
> 
> 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?

Peter



_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace