Re: [Ace] draft-ietf-ace-cmpv2-coap-transport-00.txt - do not mention V" of CMP in the document

[David von Oheimb <[e-mail]>]

Hi Mohit,

thanks a lot for providing that draft. It looks very good already.

Good point by Hendrik to replace "CMPv2" by "CMP" since the version
really does not matter here.

I'd suggest dropping the hyperlinked reference from the abstract and
a couple of further adaptations to the abstract, such that it becomes

   This document specifies use of the Constrained Application Protocol
   (CoAP) for transferring Certificate Management Protocol (CMP) messages.
   It details the respective option mentioned in the Lightweight CMP Profile.
   CMP defines the interaction between various PKI entities for certificate
   enrollment and management.  CoAP is an HTTP-like client-server protocol
   for use in constrained devices in IoT space.

Further mostly very minor improvement suggestions are given below.

Cheers,
    David


Section 1:

transport -> transfer (several times)
encryption of messages -> protection of messages
between CAs -> between RAs

Section 2:

PKIMesssage -> PKIMesssages


I do not understand what you want so say here:
> An EE MUST verify the configured Root CA
> certificate against the Root CA certificate of the discovered entity
Likely you meant:

An EE MUST verify the certificate of the discovered entity
against a configured trust anchor (Root CA certificate)


The URI's for CoAP resources should start ->
The only difference is that the URIs for CoAP resources MUST start

should return a "2.05 Content" ->
MUST return a "2.05 Content"
(or are there other options in case of success?)

application/pkixcmp -> "application/pkixcmp"

for the possible changes -> for potential changes

Block Wise -> Block-Wise (in title of 2.6)
Block Wise -> block-wise (in body of 2.6)

header body and optional fields ->
header, body, protection, and extraCerts including many optional and
potentially bulky fields

outgoing interface -> interface
(because this may also happen for responses)

maybe leave out?   that are exchanged between EEs and RAs or CAs

maybe weaken?:   mode MUST be used -> mode SHOULD be used

then, it -> then it

Proxy opens -> the proxy opens

maybe leave out?   from EEs to RAs or from EEs to CAs

Section 3:

the encryption and authentication of the messages but in cases when ->
protecting message contents, in case

7.1 and 7.2 -> 7.2 and 7.3
(for draft 03 at least)

overhead of using DTLS connection -> overhead of setting up DTLS connections

Sections 4 and 5:

CoAP to HTTP -> CoAP-to-HTTP
(several times)

significant changes -> changes

Announcements Messages -> announcement messages

MUST be positioned -> SHOULD be positioned
(else the recommendation given next makes no sense)

between CAs and RAs -> between RAs and CAs

UDP based -> UDP-based
(two times)

CoAPs to HTTPS -> CoAPS-to-HTTPS

HTTPS protocol, -> HTTPS.

however client SHOULD be configured to trust the CA certificate used by
proxy to sign the Man in the Middle (MITM) certificate for certificate
chain validation ->
The client SHOULD be configured with a trust anchor suitable for
validating the DTLS server certificate used by the proxy

I doubt if the paragraph
>    However, the CoAP protocol which
>    uses UDP as layer 4 transport is vulnerable to many issues due to the
>    connectionless characteristics of UDP itself.  The Security
>    considerations for CoAP protocol are mentioned in the [RFC7252 <https://tools.ietf.org/html/rfc7252>].
>    Using a CoAP to HTTP proxy mitigates some of the risks as the
>    requests from the EE's can terminate inside the trusted network and
>    will not require the server to listen on a UDP port making it safe
>    from UDP based address spoofing, Denial of Service, and amplification
>    attacks due to the characteristics of UDP.
makes sense because, as you wrote before, CMP is already self-contained
in terms of security.
Therefore I think it should be sufficient to say for instance:

Therefore security issues of CoAP due to using UDP do not carry over to the CMP layer 
except for the vulnerability to Denial-of-Service attacks.


Section 6:

content-type application/pkixcmp -> content type "application/pkixcmp".



On 10.03.21 19:44, Mohit Sahni wrote:
> Hi Hendrik
> Thanks for the update, I will make changes to remove the CMP version
> references from the document. I think we can exclude CMPv1 from the
> scope as it will obsolete soon.
>
> Thanks
> Mohit
>
> On Fri, Mar 5, 2021 at 9:36 AM Brockhaus, Hendrik
> <[e-mail]> wrote:
>> Mohit
>>
>>
>>
>> We introduced V3 of CMP in draft-ietf-lamps-cmp-updates-08 Section 2.15. The version of CMP is not relevant to the CoAP transport, I guess. Therefore, I suggest to  remove references to the CMP version from your draft, especially from the title. If you want to exclude CMP V1 as specified in RFC 2510 from the scope of your draft, this is fine with me as well.
>>
>>
>>
>> Hendrik