[Anima] Questions raised during IETF 105 regarding BRSKI-AE

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 22 August 2019 10:38 UTC

Return-Path: <steffen.fries@siemens.com>
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 3397012081D for <anima@ietfa.amsl.com>; Thu, 22 Aug 2019 03:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o9N-9vDkc25b for <anima@ietfa.amsl.com>; Thu, 22 Aug 2019 03:38:12 -0700 (PDT)
Received: from lizzard.sbs.de (lizzard.sbs.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FC4120169 for <anima@ietf.org>; Thu, 22 Aug 2019 03:38:12 -0700 (PDT)
Received: from mail2.sbs.de (mail2.sbs.de []) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x7MAc7N7025487 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Aug 2019 12:38:07 +0200
Received: from DEFTHW99ER2MSX.ww902.siemens.net (defthw99er2msx.ww902.siemens.net []) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x7MAc6h9008286 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Aug 2019 12:38:06 +0200
Received: from DENBGAT9ER4MSX.ww902.siemens.net ( by DEFTHW99ER2MSX.ww902.siemens.net ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 22 Aug 2019 12:38:06 +0200
Received: from DEFTHW99EL1MSX.ww902.siemens.net ([]) by DENBGAT9ER4MSX.ww902.siemens.net ([]) with mapi id 14.03.0439.000; Thu, 22 Aug 2019 12:38:05 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: "anima@ietf.org" <anima@ietf.org>
CC: Eliot Lear <lear@cisco.com>
Thread-Topic: Questions raised during IETF 105 regarding BRSKI-AE
Thread-Index: AdVYNh7DQasumPNcQl+zj+APp3f5iQ==
Date: Thu, 22 Aug 2019 10:38:05 +0000
Message-ID: <E6C9F0E527F94F4692731382340B3378279CA683@DEFTHW99EL1MSX.ww902.siemens.net>
Accept-Language: en-US
Content-Language: en-US
x-document-confidentiality: NotClassified
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/mwzrBfjahxXOjC9z5t6mCq8GLSY>
Subject: [Anima] Questions raised during IETF 105 regarding BRSKI-AE
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: Thu, 22 Aug 2019 10:38:15 -0000


during IETF 105, there were several questions raised regarding motivation and approach in BRSKI-AE (https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ )
I just checked the recordings and would like to provide some answers. Thanks Eliot for presenting in the first place.

There was a question regarding the benefits on Full CMC (PKI) Request support in EST from Michael. One of the benefits of the Full CMC request is that it provides a way to bind the entity identification and authentication to the certification request. This can be achieved by an additional signature over the certification request with the IDevID EE cert of a pledge. The result is what we called in the draft a self-contained object with two signatures, one with the private key corresponding to the contained public key in the CSR, the second with the private key, which's corresponding certificate can be validated.  Maybe the term is misleading as the CSR is also self-contained. So we may need to fine a better term. 
Having this type of self-contained object comes with some advantages:
- It removes the strict binding of the  certification request with the pledge authentication in TLS using the tls-unique value in the CSR during the EST run. This is especially interesting for scenarios, in which the registrar (EST server) acts as LRA and has (temporarily) no connection to the issuing RA/CA. If it needs to store the CSR and forward it later on for further processing to the RA/CA, the information about the identity and authentication is not directly bound to the CSR and would require other mechanisms. 
- For the "no soup case - come back later" case (Eliot, I just borrowed your analogy)  it provides the advantage, if the tls-unique parameter is used in the CSR (BRSKI is open to this) to bind the CSR to a specific TLS connection. If the TLS connection between the pledge and the registrar was teared down, EST (in simple enroll/reenroll) requires to resent the CSR, which would require to include a new tls-unique number, which in turn would require rebuilding the CSR (also described in RFC 7030, section 4.2.3).

The advantages of self-containment (in the case of EST using the FullCMCrequest) are not generally necessary, but there are scenarios, in which the pure binding of the pledge authentication using its IDevID EE Cert to the transport is not sufficient (see also the examples in BRSKI-AE). Note that using self-containment also addresses the general case. From that point I would see BRSKI-AE as update/enhancement of the mechanisms currently used in BRSKI. From my understanding this was also the outcome of the conversation during the meeting. 

Best regards