IETF Logo Mail Archive

Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07

Jim Schaad <ietf@augustcellars.com> Tue, 15 January 2019 18:10 UTC

Return-Path: <ietf@augustcellars.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 ACFF7130F2C; Tue, 15 Jan 2019 10:10:50 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nxHlBchZLHI0; Tue, 15 Jan 2019 10:10:48 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A7A130F17; Tue, 15 Jan 2019 10:10:47 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 15 Jan 2019 10:10:41 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>
CC: draft-ietf-ace-coap-est@ietf.org, ace@ietf.org
References: <003b01d4abcd$1e2b0c10$5a812430$@augustcellars.com> <620.1547565175@localhost>
In-Reply-To: <620.1547565175@localhost>
Date: Tue, 15 Jan 2019 10:10:39 -0800
Message-ID: <026e01d4acfd$a0becff0$e23c6fd0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJJIhiUbSjnc+/xowD2+hleOkbe2gKyHt8kpLIkitA=
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1lokVW_p0KOiZVVMBIm9SnaX8Vs>
Subject: Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 15 Jan 2019 18:11:00 -0000


> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Tuesday, January 15, 2019 7:13 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
> Subject: Re: WGLC comments draft-ietf-ace-coap-est-07
> 
> 
> Jim Schaad <ietf@augustcellars.com> wrote:
>     > Section 11.1 - When changing from the implicit trust anchor to
explicit
>     > trust anchors, do you expect that the est server that you are going
to
>     > be talking to is generally going to change?  I think that it should
>     > probably be recommended that the DTLS connection NOT be persistent
>     > across a change in the trust anchors if they are different.
> 
> I'm trying to understand the question better.
> 
> To be clear:
>    - implicit trust anchors -- what the device was built with.
>    - explicit trust anchors -- what is returned from /cacerts|/crts
> 
> So after calling /cacerts, the client now can authenticate an EST server
with
> the domain registrar.  Beforehand, it has to use something built-in.

The question I was asking was more about the original enrollment rather than
renewal although it could come into question there as well.

- I have the implicit trust anchors and get a EST server URL.
- Call /cacerts
- I now have the explicit trust anchors but potentially have the same EST
server URL.
- Given that I have a NEW trust anchor, what do I do with the current DTLS
session?
- I now do an enrollment with the EST server to get a certificate.

One can say it is fine to use the implicit TA for that enrollment, but one
could also say that as the certificate chain is now different then the DTLS
session should be released and a new one established.

Jim

> 
> I think you are asking about whether or not the server identification
> (certificate) is different in the two cases?  If we could be sure that a
different
> EST server would be used for renewals of the certificate (LDevID), then
that
> EST server could have a locally anchored certificate.
> 
> I don't think we want to force this change of servers so the we must be
> prepared for a single EST server to do both initial enrollment and also
> renewal.
> 
> @Hannes, it would be good to have your opinion here.
> 
> This problem can be solved with correct use of SNI extension in DTLS, but
it is
> unclear how much detail we need to be explicit about.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>

v2.23.0 | Report a Bug | By Email