Hi Esko, I addressed all your responses to this thread. Check them out here https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497043624
Practically all your nits and suggestions were addressed. Specifically for swapping 2.01 with 2.04 throughout will be painful for interop implementers of the draft. I wish we had caught it earlier, but I saw your point and I made the change. The diffs are here https://github.com/SanKumar2015/EST-coaps/commit/ace75414ac21d2652d93ad1ab663a65772696817?diff=unified I am planning to submit a new version next Wednesday. Let me know if there is anything else. Panos -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Esko Dijk Sent: Tuesday, May 28, 2019 6:31 AM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt / additional review comments Hello, Thanks for the update! First, regarding the changes: * mapping of HTTP response codes to CoAP response codes. The success code in response to an EST-coaps GET request (/cacerts, /csrattrs), is 2.05. Similarly, 2.01 is used in response to EST-coaps POST requests (/simpleenroll, /simplereenroll, /serverkeygen). Section 7 of [RFC8075] maps 2.02 (Deleted) or 2.04 (Changed) to an HTTP 200 OK response, but 2.01 (Created) is more suitable for the creation of certificates in the context of EST-coaps. -> 2.01 Created is now used as POST response. While I agree that it sounds more logical to use 2.01 than 2.04 (since a certificate is created by the server, based on the CSR), there is the CoAP level expectation that when using 2.01 the resource is created at the location of the request - that is, for example, at /sen. So if the client would do a GET /sen it would get the actual previously created certificate. (Which is not the case.) The text in RFC 7252 that states this is "Otherwise, the resource was created at the request URI." So 2.01 is used to create new CoAP *resources* that can be found at the server using a subsequent GET request. And 2.04 is used to execute actions like 'create x' , the result of which is returned in the response but otherwise not available anywhere on the server anymore. The latter is the case in the EST-coaps protocol flow as there's no way to GET the resulting certificate later on. -> the resources in brackets should now be the short resource names, since we talk about EST-coaps resources not EST resources anymore. So "GET request (/crts, /att)" etc. * "EST makes use of HTTP 204 responses when a resource is not available for the client." -> EST states either 204 or 404 can be used; which in CoAP translates to 4.04 Not Found if the resource is not available to the client, i.e. does not exist. That seems the easiest translation here. Though the server could also send 2.05 with an empty zero-length payload, to express that it has that function available but there is "nothing" there for the client. * 2.04 SHOULD only be used in response to an EST-coaps POST when the response comes delayed in a separate (not Piggybacked) message after an empty 0.00 message (Section 5.7) -> this seems strange, the response code remains the same whether separate response or piggybacked response is used. At this level of request/response, there's no need to try to detail this. I feel it only makes it more complex; the base CoAP protocol should handle piggybacked vs separate for both client and server. (Without impact on response codes). * Table 3: the "4.xx" can be "4.xx / 5.xx" because the 5.xx failures can also occur in any CoAP server in principle. I don't really see why 4.02 should be mentioned separately? It again is defined in the base CoAP spec and not really of interest for EST-coaps, nor used by any definitions or examples in the current specification. Second, below a few more review comments on the -11 version: * End of Section 6: "If necessary, the EST-coaps-to-HTTP Registrar will support resouce discovery according to the rules in Section 5.1." -> what about (also added letter to 'resouce') "The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1." Because this Registrar operates to the CoAP client facing side exactly like a CoAP EST server. So it must support the same rules for discovery, or else it won't work (e.g. be not discoverable). * Section 9.1: "These have been registered provisionally in the Expert Review range (0-255)" -> "These have been registered provisionally in the IETF Review or IESG Approval range (256-9999)" * Section 10.1: A client that pipelines EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. -> does the last requirement mean new DTLS connections to the same EST server? Or, new DTLS connections to any EST server(s) in the future? -> it is also unclear here whether the updated Explicit TA needs to replace an existing configured Explicit TA (e.g. obtained from an ANIMA voucher or a previous /crts request. ). I would think not, especially given that the verification of it failed in above text? -> I wonder why the client would trust a new Explicit TA, if the EST server itself cannot be authenticated using that TA. It will disconnect and then upon next DTLS connection to the same server the handshake will fail against the new TA. And the client can't perform EST anymore until factory reset. Or is the expectation that it somehow will use another EST server for a second try? * Section 10.1: "depend in" -> "depend on" * Section 10.1: "especially since the practicality of such an attack would not expose any messages exchanged with EST-coaps." -> rather complex sentence, what about ""especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps." * Section 10.1: "Regarding the Certificate Signing Request (CSR), a CA is expected to be able to enforce policies to recover from improper CSR requests." -> should be "an EST-coaps server is expected to" ? Because this specification and 10.1 describes the EST-coaps server, not a CA. * Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server. Maybe this should become "it" (not a person). -----Original Message----- From: Panos Kampanakis (pkampana) <pkamp...@cisco.com> Sent: Saturday, May 25, 2019 06:48 To: Esko Dijk <esko.d...@iotconsultancy.nl>; ace@ietf.org Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt 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 <esko.d...@iotconsultancy.nl> Sent: Tuesday, May 21, 2019 6:31 PM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org Cc: draft-ietf-ace-coap-...@ietf.org Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt 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) <pkamp...@cisco.com> Sent: Monday, May 20, 2019 17:31 To: Esko Dijk <esko.d...@iotconsultancy.nl>; ace@ietf.org Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
