Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Feb 2018 17:46:24 -0500

Fries, Steffen <[email-masked]> wrote:
    > The current BRSKI draft addresses the bootstrapping of a secure
    > infrastructure based on existent manufacturer certificates. This is for
    > sure a basic requirement in industrial applications to enable secure
    > service deployment or device integration. The current document utilizes
    > EST to provide a realization example for the BRSKI approach. This
    > already fits perfect for the energy automation domain, as EST is
    > already been envisioned/utilized as enrollment protocol in IEC defined
    > security. As we experience, there are other scenarios like industrial
    > automation or intelligent traffic systems, which feature different
    > enrollment approaches, like CMP, but could leverage the generic BRSKI

Just to be sure, you are talking about: https://tools.ietf.org/html/rfc4210

    > approach, we would like to propose to also consider CMP as further
    > example for BRSKI. In contrast to EST, CMP builds on a self-contained
    > container, which are independent from the transport. Hence, they can be
    > easily processed in online (connected) or offline scenarios, even if no
    > direct network access is possible. As CMP is very versatile, there is
    > the option to profile the protocol to only support the features needed
    > for a specific application. The LTE profile of CMP is one example of
    > "simplifying" CMP by requiring only 3 Handshake messages to be
    > supported. This profiling reduces the burden on the device implementing
    > CMP to not support all of its features.

    > Even though the BRSKI document is already advanced, we would like to
    > propose to also include CMP as further example for certificate
    > enrollment in BRSKI. This inclusion would make it also easier for other
    > standards or frameworks to consider security bootstrapping based on
    > BRSKI.

I think that it would be very difficult to hack CMP into the BRSKI document
at this point.

    > I hope it is okay to raise the question of scope enhancements of BRSKI
    > in terms of mapped enrollment protocols on the mailing list and not
    > wait till the next IETF meeting regarding a discussion. If this
    > proposal is accepted, we are very eager on providing a mapping section
    > for the draft using a similar approach as section 5 takes for defining
    > BRSKI as extension to EST.

    > Any thoughts regarding such an enhancement?

    > Best regards Steffen

    > --
    > Steffen Fries Siemens AG Corporate Technology Research and Development
    > for Digitalization and Automation IT Security CT RDA ITS Otto-Hahn-Ring
    > 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000
    > mailto:[email-masked]
    > www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>

    > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
    > Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief
    > Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina
    > Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices:
    > Berlin and Munich, Germany; Commercial registries: Berlin
    > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

    > _______________________________________________ Anima mailing list
    > [email-masked] https://www.ietf.org/mailman/listinfo/anima

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 14:06:42 +1300

On 01/03/2018 11:46, Michael Richardson wrote:
...
> I think that it would be very difficult to hack CMP into the BRSKI document

As a matter of principle, it seems better to get BRSKI published as quickly
as possible to meet the WG milestone, and then publish any extensions as
separate documents.

It seems like a good idea to work on such extensions. But one step
at a time :-).

    Brian

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 1 Mar 2018 06:36:56 +0000

> On 28. Feb 2018, at 23:46, Michael Richardson <[email-masked]> wrote:
> 
Yes, exactly. It is utilized by most (if not all) of the CAs I’m aware of. 
> I think that it would be very difficult to hack CMP into the BRSKI document
Based on CMPs complexity? That was the reason to mention the LTE profile. Not as a transport for CMP but rather as example how to streamline CMP to the functionality needed. 

Or was it based on the timeline for the BRSKI document?

Best regards
Steffen

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 1 Mar 2018 06:45:27 +0000

> On 1. Mar 2018, at 02:06, Brian E Carpenter <[email-masked]> wrote:
> 
I was looking into the charter and based on the date of the initial draft of the document I somehow feared that the document is already in the final state. I did not find an expected timeline on when the draft is expected to be finalized. 

> It seems like a good idea to work on such extensions. But one step
We came up with the proposal as the current title of the document gives the impression, that BRSKI would solely work with EST as it is the only example stated. As we see different use cases, which already target CMP, we thought it would be good to cover it in the base document. If the schedule of the document is that tight, then an extension in terms of a separate document might be the way to go.

Steffen