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 =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
