Gotcha, so you are describing a provisional DTLS connection at the server.
Just to give a bit more color, in a usecase we are working on right now the mesh network link rate <100Kbps. That network gets oversubscribed with legit cacert responses. I can only imagine how worse it would be if bad guys were allowed to send small /crt requests and trigger big cert responses. Just a 4.01 would not tell the client that he needs to send client certs for auth. In plain EST it would take an HTTP 401 with an WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge header in the response. Unless we replicate that a generic 4.01 would not be enough for the client to know what to do. Another issue is EST-coaps request pipelining. A cacerts could precede an enrollment in the same DTLS connection (for really constrained devices that don't want to establish two connections). This could be opening room for unauthenticated enrollments when pipelining is used. I think it is a good idea to not repeat the EST behavior in regards to /crt and /att. Provisional TLS at the server could have value in Constrianed-BRSKI/voucher though, for some situations though. > So I think that we need to say something in EST-COAPS to explain that we do > not see a use case for replying to /crts and /att for clients which are not > recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think? Currently we say that clients need to be authenticated in a DTLS connection before an EST-coaps request. Do you want to make it more explicit to say that even though EST allowed for it, EST-coaps does not allow unauthenticated /crt and /att? We can certainly add that. Rgs, Panos -----Original Message----- From: Michael Richardson <[email protected]> Sent: Tuesday, December 11, 2018 5:22 PM To: Panos Kampanakis (pkampana) <[email protected]>; [email protected]; [email protected] Cc: Peter van der Stok <[email protected]>; Max Pritikin (pritikin) <[email protected]> Subject: Re: est-coaps clarification on /att and /crts * PGP Signed by an unknown key Panos Kampanakis (pkampana) <[email protected]> wrote: > I thought about this for the EST-coaps draft. EST allowed for > unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as > you are suggesting. Exactly. > It is not as simple in EST-coaps. Two reasons: > 1) There are constrained networks where an easy amplification attack > could take place. For example the /crt request is very small and the > response can be big (a few KBs in the context of a constrained network > is big). If unauthenticated, then /crts could be an easy amplification > attack to saturate a constrained network. We don't want that to > happen. We want all our clients to be authenticated by DTLS before > they start loading up our RF network. I'm not suggesting that the DTLS be skipped, I'm suggesting that the client certificate presented might be meaningless to the EST server. As for amplication attacks, they usually depend upon forged source addresses, and in that case the DTLS wouldn't have completed. > 2) Additionally, there is a practical challenge of COAPS. When the > DTLS handshake is taking place the server does not know what the > request will be. In EST the server would send an HTTP WWW-Authenticate > header to ask the client to authenticate. Such a mechanism does not > exist in COAP, so it would not be straightforward unless we introduced > a bunch of new things into COAP. AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level authentication is specified in EST-COAPS. > I think it is still right to authenticate clients even for /crt and > /att in the EST-coaps context. Maybe that is something to be revisited > in Constrained-BRSKI/voucher, but not taken lightly. So I think that we need to say something in EST-COAPS to explain that we do not see a use case for replying to /crts and /att for clients which are not recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- * Unknown Key * 0xDDD0DD65 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
