[Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

Toerless Eckert <tte@cs.fau.de> Sat, 27 June 2020 05:41 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1D6333A0D46 for <anima@ietfa.amsl.com>; Fri, 26 Jun 2020 22:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id R7iSw0IFZZZY for <anima@ietfa.amsl.com>; Fri, 26 Jun 2020 22:41:03 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCED3A0D45 for <anima@ietf.org>; Fri, 26 Jun 2020 22:41:02 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1C0A9548440; Sat, 27 Jun 2020 07:40:56 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 11F25440043; Sat, 27 Jun 2020 07:40:56 +0200 (CEST)
Date: Sat, 27 Jun 2020 07:40:56 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Russ Housley <housley@vigilsec.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org, Ben Kaduk <kaduk@mit.edu>
Message-ID: <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de>
References: <11428.1592266833@localhost> <a0face89-da68-f75d-4a57-4deb9d0f244d@gmail.com> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/COZXa3ImhPmT8RHCEyTt42W-fL0>
Subject: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document
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: Sat, 27 Jun 2020 05:41:05 -0000


Top posting re. your ACP vs. ACME question.

ACP rfc822name are meant to be under control of the ACP network operations.
aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using
ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control
the acp.example.com MTA.  Just no need/benefit to do this now IMHO:

An ACP is a private network which is ideally isolated from other
ACP networks by use of private TA. Using the ACME rfc822name scheme would
IMHO create a lot of attack components (all the MTA in the mail path
and domain names) if used acros the Internet - without benefits for
ACP. Of course, if it was all a private ACME setup within an enterprise,
and using mailboxes and ACME is a popular choice - sure, why not.
But for private CA setups there are existing IMO easier options
(private CA VMs using EST or the like).

IMHO public ACME CAwith S/MIME authenitcation could  make sense 
in the future to enable authentication across different ACP domains.

Any network has links into other domains and today they are usually
unauthenticated, that could be solved IMHO fairly easily.

"private" CA of ACP domain , lets call it acpCA signs all ACP certs.
Its own cert is not self-signed, but signed by ACME CA via S/MIME,
 maybe email is rfcSELF@example.com (no ACP IPv6 address in it)

Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA.
After IKEv2 authenticates neigbor the followup ACP domain membership
step checks if the TA of the peer is acpCA. If yes, then peer
becomes ACP member, otherwise we have an authenticated signalling
channel to an interdomain / different CA peer. And that of course
would enable better/secure auto-configuration of such interdomain

This gives me good mix of security: Its still only relying on
well controlled private TA to get into ACP, but also doubles
at less secure but best available "Internet/Interdomain"


On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote:
> > On Jun 21, 2020, at 12:28 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> > 
> > 
> > Russ Housley <housley@vigilsec.com> wrote:
> >> One cannot send email to the character string in this specification, so
> >> it should not be carried in the rfc822name.
> > 
> > You can send email to that character string if you configure the MX.
> > It was designed specifically to accomodate that.
> > 
> > I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon
> > was going to have to send/receive email.
> > 
> > But, Toerless was paranoid that if we did anything at all out of the
> > ordinary, that the corporate CA people, in order to protect their fiefdom,
> > would freak out and throw some huge roadblock in the way of deploying the ACP.
> > 
> > And, now have an ACME method past WGLC that does certificate validation by
> > SMTP.
> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol.  How do you see it working?
> Russ

> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima