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
