IETF Logo Mail Archive

Re: [Anima] [Ace] est-coaps clarification on /att and /crts

"Max Pritikin (pritikin)" <pritikin@cisco.com> Wed, 12 December 2018 00:52 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67233129C6A; Tue, 11 Dec 2018 16:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level:
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ih50og4ZTzbg; Tue, 11 Dec 2018 16:52:03 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381D5127598; Tue, 11 Dec 2018 16:52:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9850; q=dns/txt; s=iport; t=1544575923; x=1545785523; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TNb0supGxN3wSnMe2Rn4hSzkyIAh+6di0SdaU8MfIFE=; b=QPAn+1NvpZRZl3o76eiNQSlJuZABeYlm2YU3NHqduI6ec2FjviwDJijz Rvqy7wFFcytnAGCOwq1TqDpu+Ji2+XVpnfFyeRzeH7KhFfbBQl2qfkFl8 2WfC+kf1TKFAr82atfjnJKUUC43K1L8MlXrILUNhese0Uw8/sV4Cz7v1c I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAAlWxBc/5RdJa1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDcYgZjBKUBoVZgXoLAQEngVCCdQIXglUiNAkNAQMBAQIBAQJtHAyFPQYjVhACAQg/AwICAjAUEQIEDgWDIQGBHWQPpgSBL4oqBYw7F4F/gTgfgkyDHgEBAgGBSIMaMYImAolRgVqDfJFUCQKHB4pIGJFAjhaKdgIRFIEnHziBVnAVZQGCQYIiBReIXoU/QTEBiR8rgQGBHwEB
X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208,217";a="211767364"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 00:52:02 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wBC0q2nA011229 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 00:52:02 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 18:52:01 -0600
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 18:52:01 -0600
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Jim Schaad <ietf@augustcellars.com>, "ace@ietf.org" <ace@ietf.org>, "anima@ietf.org" <anima@ietf.org>, Peter van der Stok <stokcons@bbhmail.nl>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Thread-Topic: [Ace] est-coaps clarification on /att and /crts
Thread-Index: AQHUkW6wpKPGP7xkTEa+IFO1X4G7f6V6NZcAgABKjQCAACtXgA==
Date: Wed, 12 Dec 2018 00:52:01 +0000
Message-ID: <B4901FFA-18C1-4B85-8B7A-60DD98A8D521@cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com> <3831.1544545763@localhost> <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> <26234.1544566610@localhost>
In-Reply-To: <26234.1544566610@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.99.106.3]
Content-Type: multipart/alternative; boundary="_000_B4901FFA18C14B858B7A60DD98A8D521ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/JhIPXK_Cv8NBSCExwjhhp8giBiQ>
Subject: Re: [Anima] [Ace] est-coaps clarification on /att and /crts
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 00:52:06 -0000


On Dec 11, 2018, at 3:16 PM, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:


Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
Clarification requested - exactly what element is the Registrar?

It's an EST RFC7030 term, but essentially it's the server that connects to
(or is) the CA.

The Registrar terminology is from the Anima working group and is closely analogous to the “Registration Authority” we know and love from the PKI space.


   Join Registrar (and Coordinator):  A representative of the domain
      that is configured, perhaps autonomically, to decide whether a new

      device is allowed to join the domain.  The administrator of the


      domain interfaces with a "join registrar (and coordinator)" to
      control this process.  Typically a join registrar is "inside" its
      domain.  For simplicity this document often refers to this as just
      "registrar".  Within [I-D.ietf-anima-reference-model<https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-17#ref-I-D.ietf-anima-reference-model>] this is
      refered to as the "join registrar autonomic service agent".

It terminates the BRSKI protocol from the new device and, after processing and decisions, forwards messages to a manufacturer authorized signing authority to obtain vouchers and ensure records/audit-logs are kept. It also pulls those audit logs to make additional decisions. It is responsible for making the authorization decision concerning if the new device should be allowed to join the network.

It also optionally doubles as a enrollment over secure transport (RFC7030) registration authority in the normal PKI sense. This is recommended in that BRSKI recommends that devices go on to enroll and obtain a certificate.

- max


The one item that I can generally think of that might be a problem is that
the answers to /att and /crts may differ based on the entity that is asking
the question.  In this case not having the entity being validated means that
the "wrong" answer may be returned or different answers would be returned
before and after validation.

Yes, I agree: it should be restricted.

I think that it should be restricted. Partly, I'm just not sure where the
text should go, or if it needs to be said at all.

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

v2.23.0 | Report a Bug | By Email