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

["Fries, Steffen" <[e-mail]>]

> On 3. Apr 2019, at 20:26, Jim Schaad <[e-mail]> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Fries, Steffen
>> Sent: Wednesday, April 3, 2019 9:12 AM
>> To: Jim Schaad <[e-mail]>; [e-mail]
>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spasm
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
>