Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

From: [email-masked]
Date: Fri, 17 May 2019 08:30:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.

        Title           : EST over secure CoAP (EST-coaps)
        Authors         : Peter van der Stok
                          Panos Kampanakis
                          Michael C. Richardson
                          Shahid Raza
	Filename        : draft-ietf-ace-coap-est-11.txt
	Pages           : 48
	Date            : 2019-05-17

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-11
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 17 May 2019 15:35:55 +0000

Hi all, 

This latest update addresses feedback while in WGLC" 
- the comments by Hannes and Esko related to RNG and server-side key gen. It aims to prevent misunderstandings that random numbers are not needed any more if server-side key gen is used. 
- the nits with "/crt" instead of "/crts" pointed out by Esko. 

The diff is here https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11.txt 

Thanks,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, May 17, 2019 11:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Esko Dijk <[email-masked]>
Date: Mon, 20 May 2019 06:31:25 +0000

Thanks,

A few comments I had still on the discovery section - sorry to be late post-WGLC with this:

- page 10 bottom mentions "management data" - should say "management resources", or "EST resources" perhaps?
- page 10 bottom: " Upon success, the return payload will contain the root resource of the EST resources." - this is not true, since only the individual supported resources are returned. The root (e.g. "/est" in the examples) can be deduced from the response but it is never returned as one link format entry.
- page 11 top: the example is only correct for a secure (coaps://) discovery GET request, I think this could be mentioned in text or indicated in the request line.
- page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available  EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources.  So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address.  Hope this is clear enough in the text and intended?
- page 11 bottom: "he supports" -> "it supports"
- page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not.

Best regards
Esko

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, May 17, 2019 17:36
To: [email-masked]
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hi all, 

Thanks,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, May 17, 2019 11:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Abstract:

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 20 May 2019 15:31:15 +0000

Thanks Esko. 

Addressed in https://github.com/SanKumar2015/EST-coaps/blob/84ce0c1d5e768d40e97184214bae404da21bd050/draft-ietf-ace-coap-est.xml Two comments: 

> page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available  EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources.  So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address.  Hope this is clear enough in the text and intended?

There are optional resources like /att, /skg and /skc that the server does not have to support, so that is what this sentence was referring to. 

> page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not.

The text says that the server MUST support the default /.well-known/est root resource and it SHOULD support resource discovery for non-default URIs (like /est or /est/ArbitraryLabel) or ports. In the latter case it is up to the server to decide the paths he makes its resources available at. That is what this sentence was referring to. But you are right; I realized that this sentence is redundant so I only kept "Throughout this document the example root resource of /est is used."

Will reupload the next iteration in a few days. 

Rgs,
Panos

-----Original Message-----
From: Esko Dijk <[email-masked]> 
Sent: Monday, May 20, 2019 2:31 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Thanks,

Best regards
Esko

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, May 17, 2019 17:36
To: [email-masked]
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hi all, 

Thanks,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, May 17, 2019 11:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Abstract:

---

From: Esko Dijk <[email-masked]>
Date: Tue, 21 May 2019 22:30:36 +0000

Hello Panos,

For the draft text I have a couple of more review remarks:

* page 8 first bullet: a previously issues client certificate could also expire, in some cases even without the client knowing. If the client then performs simple re-enrollment -- using its previous operational cert as authentication, what would happen?  I would expect the server MAY also want to use this certificate to authenticate the client. Because the purpose of the client connecting again to the EST server is to do simple re-enrollment, to get a new certificate.   Suppose a case where the handshake to the EST server fails because the EST server rejects the expired operational cert:  what would the client do now? It could be a certificate_expired message.  RFC 7030 provides no guidance in this matter; would EST-coaps need to define this? E.g. client SHOULD retry using the bullet #2 certificate (e.g. IDevID)?

* page 8 middle: "CoAP and DTLS can provide proof-of-identity for EST-coaps clients and servers with simple PKI messages as described in Section 3.1 of [RFC5272] "
Looking up this section it says: "The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included."   This seems to say the opposite of the above text?  This requires at least some more explanation.

* page 8 middle: "Moreover, channel-binding information for linking proof-of-identity with connection-based proof-of-possession is OPTIONAL for EST-coaps"  -> is it OPTIONAL for client, server, or both? I would assume it is OPTIONAL for both. If the (light-weight) client does not implement it and if the server does mandate it, the client can not connect to that server if its policy is set to "linking POP/identity required".

* page 14 top bullet: "The CoAP Options used are .... " 
  -> the item Block could be expanded to "Block1, Block2" to capture the actual Option names.
  -> Location-Path is never used in any of the CoAP interactions defined; should be removed.

* Page 14 first 5.5 paragraph: "Similarly, 2.01, 2.02 or 2.04 MUST be used in response to EST POST requests"
  -> 2.01 Created is like HTTP 201, which is not used in EST - so can be removed here.
  -> 2.02 Deleted has no HTTP equivalent, so is not used in EST. It should be removed here.
  -> that leaves only 2.04 responses. However the text should say this is for successful (HTTP 200 or 202 in EST) responses , so suggestion is to change above sentence to: "Similarly, 2.04 MUST be used in a response to a successful EST POST request"

* page 14 bottom: "EST makes use of HTTP 204 and 404 responses when a resource is not  available for the client.  The equivalent CoAP codes to use in an EST-coaps responses are 2.04 and 4.04.  "
  -> CoAP 2.04 can only be used in responses to POST or PUT requests, not for GET responses.
  -> so in CoAP the server could either return 2.05 with empty payload (equivalent to HTTP 204), or return 4.04 (equivalent to HTTP 404)

* page 15 bottom: "The EST-coaps client and server MUST support Block2.  Block1 MUST be supported for EST-coaps enrollment requests that exceed the Path MTU."
  -> could be clarified better, I expect a EST-coaps server MUST support Block1 because that server doesn't know in advance how big the client's request payload is going to be and whether that client will use Block1.
  -> e.g. "The EST-coaps client and server MUST support Block2.  The EST-coaps server MUST support Block1. The EST-coaps client MUST support Block1 if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU."

* page 16 example: the payloads are not indicating that each "{CSR req}" payload is different. I.e., a different block. It would be more clear if that is shown e.g. "{CSR 1}", "{CSR 2}", ... up to "{CSR N1+1}". The "req" string is not needed since the R in CSR already stands for request.

* page 17 example: see above payloads remark; and the following:
  --> what I find strange here is that a blockwise POST request ends with a 5.03 response, and then the same request after that gives a 2.01 response. In CoAP AFAIK, one request can never give 2 responses in sequence.
  --> once a response is delivered back to the client piggybacked on an ACK, the server closes the transaction normally and no further state for the transaction is kept.
  --> normally if a server sends 5.03 with Max-Age the client needs to send a new request i.e. retry with a new request after this waiting time.   That implies the client would need to resend the entire request: all blocks of it!
  --> I do realize that resending all blocks is very inefficient ; but at the same time the example also seems incompatible with CoAP specs.
  --> another question is why does the server use Block2 option in the 5.03 response that has no payload. In RFC 7959 Section 2.1, "the Block2 Option pertains to the response payload" and "payload-bearing responses". So it should be just left out in the response without payload I think.
  --> I understand this sequence of messages was tested using interops/code; was a specific CoAP library used that exhibits this behavior? I would be interested to understand better why this works.

Hope these comments can still be used for improvement of the spec. I will send further review comments in a next email: still need to write these down.

Best regards
Esko

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Monday, May 20, 2019 17:31
To: Esko Dijk <[email-masked]>; [email-masked]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Thanks Esko. 

Rgs,
Panos

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Sat, 25 May 2019 04:47:38 +0000

Hi Esko,

Thank you again. Again a very elaborate review and found some good nits in the Delayed responses section. To make it easier I logged the issues and fixes here https://github.com/SanKumar2015/EST-coaps/issues/145 

The updated doc is here https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt and the diffs are here https://github.com/SanKumar2015/EST-coaps/commit/4ad5210faf624c67e1998da75ea051de616e91b1#diff-3a712edb43f6eace7fb1667328d65307  

Rgs
Panos

-----Original Message-----
From: Esko Dijk <[email-masked]> 
Sent: Tuesday, May 21, 2019 6:31 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hello Panos,

Best regards
Esko

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Monday, May 20, 2019 17:31
To: Esko Dijk <[email-masked]>; [email-masked]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Thanks Esko. 

Rgs,
Panos