Re: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile

"Fries, Steffen" <steffen.fries@siemens.com> Wed, 03 April 2019 19:06 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954E1120180 for <spasm@ietfa.amsl.com>; Wed, 3 Apr 2019 12:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ELXC_jLf7kKG for <spasm@ietfa.amsl.com>; Wed, 3 Apr 2019 12:06:02 -0700 (PDT)
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 7B64E120167 for <spasm@ietf.org>; Wed, 3 Apr 2019 12:06:02 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x33J5tYV021981 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2019 21:05:55 +0200
Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x33J5siD019262 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2019 21:05:55 +0200
Received: from DENBGAT9ERLMSX.ww902.siemens.net (139.22.70.146) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.435.0; Wed, 3 Apr 2019 21:05:54 +0200
Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.162]) by DENBGAT9ERLMSX.ww902.siemens.net ([139.22.70.146]) with mapi id 14.03.0435.000; Wed, 3 Apr 2019 21:05:53 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Jim Schaad <ietf@augustcellars.com>
CC: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile
Thread-Index: AdTpEqMJe7nRixUIQJ2pi62nhzW52wAYoVsAACq2+aAABn4sAAAFkTzD
Date: Wed, 3 Apr 2019 19:05:52 +0000
Message-ID: <4EAA90F4-E8E1-4FE4-B0C9-1D814E49E30C@siemens.com>
References: <BF6D964D-BE83-430A-97CD-48BE51CA1BBD@siemens.com> <027301d4e985$efd03970$cf70ac50$@augustcellars.com> <E6C9F0E527F94F4692731382340B33781542BE13@DENBGAT9EJ5MSX.ww902.siemens.net>, <001a01d4ea4a$c27453b0$475cfb10$@augustcellars.com>
In-Reply-To: <001a01d4ea4a$c27453b0$475cfb10$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/iKaF_vWRvp9nQe9zzzHZgaCA9d0>
Subject: Re: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 19:06:06 -0000


> On 3. Apr 2019, at 20:26, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Fries, Steffen
>> Sent: Wednesday, April 3, 2019 9:12 AM
>> To: Jim Schaad <ietf@augustcellars.com>om>; spasm@ietf.org
>> Subject: Re: [lamps] Seeking guidance on proceeding with question from
>> IETF-104 presentation on lightweight CMP profile
>> 
>> Hi Jim,
>>> This is a quick walk through what you have below.  It would have been
>>> helpful to have pointers to the sections/bullet points where things are
>> meant to be modified.
>> First of all, thank you for the walk through. I made some comments to your
>> questions.
>> 
>>>> Hi,
>>>> 
>>>> during the LAMPS session in IETF-104 we presented a draft for a
>>> lightweight
>>>> industrial CMP profile. The document as such bases on CMP and
>>>> targets to simplify the very versatile CMP.
>>>> 
>>>> During the presentation we have been asked to also talk to the ACE
>>>> WG
>>> chair
>>>> regarding potential interest in this work, as it was not sure if
>>>> LAMPS is
>>> the
>>>> right home. I talked to Jim Schaad and as we only work on CMP
>>>> directly,
>>> not
>>>> with the transport nor specific considerations for constraint
>>>> devices, ACE
>>> may
>>>> not be the right home. Also, Jim was asking if the draft needs to be
>>>> a standards track RFC and thus be adopted in a WG. An alternative
>>>> approach could also be an independent submission. To make this
>>>> decision, we need some guidance.
>>>> 
>>>> For this, let me enumerate the main points we addressed in the draft:
>>>> - Generally Section 1.4 enlists the exceptions from the mandatory
>>>> CMP Profile as defined in RFC4210 Appendix D:
>>>> o  signature-based protection is the default protection; initial
>>> transactions may also use HMAC,
>>> 
>>> Depending on what is being proven this is reasonable.  I would
>>> consider this to be profiling
>>> 
>>>> o  certification of a second key pair within the same transaction is
>>>> not
>>> supported,
>>> 
>>> I would consider this to be profiling
>>> 
>>>> o  proof-of-possession (POPO) with self-signature of the
>>>> certTemplate
>>> according to [RFC4211] section 4.1 clause 3 is the only supported POPO
>>> method,
>>> 
>>> I would consider this to be profiling
>>> 
>>>> o  confirmation of newly enrolled certificates may be omitted, and
>>> especially
>>> 
>>> I would consider this to be profiling
>>> 
>>>> o  all transactions consist of request-response message pairs
>>>> originating
>>> at the end entity (EE), i.e.,  announcement messages are omitted.
>>> 
>>> I would consider this to be profiling
>>> 
>>>> - In section 4.1.5 the proceeding of central key generation needed
>>>> extensions at least for ECC key pairs.
>>> 
>>> Not sure what you think falls here and the document is not forth coming.
>>> This may have already been done.
>> Our understanding was that the current approach in RFC 4210 requires at
>> least some support for RSA even if the generated key pair is ECDSA. This
> is
>> due to the statement for encrypting the private key when sending the
>> generated material back to the client. Here, the encryption key is to be
>> encrypted with a short term asymmetric key of the client.
> 
> Profiling to use EncryptedKey rather than EncryptedValue would deal with
> this issue.  It would also provide all of the other good things that might
> show up in the future such as quantum crypto as they would be done for the
> CMS work.  This would not change any existing implementations that are still
> RSA.

That is a nice approach not requiring own additions and using what is already there. Much appreciated.


>>> 
>>>> - In section 4.4.1 the RootCAUpdate is specified as request-response
>>>> transaction and differs from the announcement message as specified
>>>> in
>>>> RFC4210 section 4.4 and Appendix E.
>>> 
>>> Depending on how this is done, it will require an update of RFC 4211.
>>> I believe that this means it must be an IETF consensus document and may
>> need to be standards track.
>> The intention here was to avoid the announce messages for the RootCA
>> update completely to better support application in constraint devices,
> which
>> may be temporarily offline or my not feature a server part listening for
>> announce messages. Using a request response allows the client to simply
> ask
>> for an update.
>> Why do you think this will influence also RFC 4211?
> 
> Typo - I think of RFC4210 and RFC 4211 as being together and had both open.
> I meant to type RFC 4210.
> 
> I am not sure how much this is needed depending on how often this is used
> and why you think this is needed.  If you have a directory or similar then
> pointers to where they can be found.
> 
We just wanted to avoid that a client has to listen for the announce messages. Pointing to a directory would then be out of the definition from CMP and rather a client side configuration? Yes, this could be done. Alternatively the CMP request/response may be used.
>> 
>>> 
>>>> - In section 5 the new Extended Key Usages id-kp-cmpRA is introduced
>>>> to indicate that a key pair is entitled to be used by an LRA/RA for
>>> signature-
>>>> based protection of a CMP message.
>>> 
>>> This can be considered to be a profile.
>>> 
>>>> - Generally further topics to clarify CMP or CRMF may come up during
>>>> WG review.
>>>> 
>>>> Based on this list, are these point to be handled as profiling of
>>>> the base protocol or are they rather seen as technical
>> change/enhancement?
>>>> My understanding is that for profiling an independent RFC would be
>>>> fine,
>>> as
>>>> the base spec can be normatively referenced by other standards. In
>>>> this
>>> case
>>>> the CMP profile document can be informational.
>>>> If some of the points listed qualify rather for technical changes of
>>>> the
>>> base
>>>> protocol, my understanding is that we need to find a home for the
>>>> draft
>>> and
>>>> target the standard track. @Jim, I hope my conclusion based on our
>>>> conversation is right.
>>>> 
>>>> Regarding interest in the resulting RFC there is work ongoing in
>>>> ANIMA WG and EAP WG, that can directly leverage the lightweight CMP.
>>> 
>>> Have either of these groups expressed any active interest in this work?
>>> This is not something that EAP would normally be looking at as far as
>>> I know as they normally consider the act of setting up the EAP
> credentials
>> to be a "Not My Problem" space.
>> Both groups are not active regarding CMP adaptation to my knowledge. But
>> there are documents discussed (currently individual submissions and not WG
>> items), which can leverage a lightweight CMP without the need of
> specifying
>> something by their own.
>> In EAP draft-pala-eap-creds targets enrollment over EAP and specifically
>> addresses CMP. We also talked to Max (the author) and he is interested in
>> utilizing a lightweight CMP for this.
>> In ANIMA, we proposed BRSKI-AE to allow for enrollment in domains, which
>> are not always online or which do not feature an on-site PKI. Here, self-
>> contained objects are necessary to bind the initial authentication of an
>> enrolling device to the certification request directly, instead of binding
> it to
>> the underlying transport protocol. CMP would be applicable as one option
> for
>> providing such a self-contained object.
> 
> Ok - I was just making sure it was real.  I don't remember the draft from
> Max.
> 
We had some conversation with Max regarding the profiling and he was in favor as it eases the application over EAP to only the necessary exchanges.

Best regards
Steffen


> Jim
> 
>> 
>> Best regards
>> Steffen
>> 
>>> 
>>> Jim
>>> 
>>> 
>>>> 
>>>> In either case your view is appreciated.
>>>> 
>>>> Best regards
>>>> Steffen
>>>> 
>>>> _______________________________________________
>>>> Spasm mailing list
>>>> Spasm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spasm
>> 
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>