On Tue, Nov 01, 2022 at 05:14:23PM +0000, Esko Dijk wrote: > The Pledge here is not using unsecured CoAP towards the Join Proxy - the Join > Proxy is using unsecured CoAP towards the "Registrar-Proxy" that is situated > on a specific port on the Registrar host. > So there should be no big security issues for rogue Pledges.
Ah. Right. The pledge is out of the picture wrt to header parameter choice proxy/registrar. I was confused. So wrt to security we're unchanged from our pre-coap solution, e.g: needs to depend on ny underlying security of the mesh network, including e.g.: ACP if its an ANI thats providing registar/proxy connectivity. > We could of course explain in the Security Considerations section that the > "Registrar-Proxy" needs to (or must) support only one CoAP resource for the > Registrar-Proxy functionality and not accept requests to arbitrary other > resources. Just to be complete. Right. > Suppose that a Pledge would try to send unsecured CoAP to a Join Proxy: > * if sent to the Join Proxy port (i.e. the DTLS port), the Join Proxy would > just forward this as a data blob as usual and eventually the Registrar will > try to parse the CoAP message as "DTLS" and fail. > * if sent to any other port, the Join Proxy must discard the data since it is > not using the proper encryption of the (mesh) network. The JP only has a > port "open to the outside world" to relay DTLS data blobs and other ports are > not open. Yes. > On the one hand if we decide to use CoAP for a particular function then we > may expect implementers need to know CoAP as well and e.g. read RFC 7252. > Including thinking about security issues of unsecured-CoAP. The benefit or > re-use comes with that responsibility as well as the CoAP protocol is far > more rich/complex than what we actually need. Well, in the case of ACP (RFC8994) i was put by security AD under a good amount of discus' etc. to detail all the profile detail of TLS, DTLS and IPsec in ACP. And i for each of the protocol pieces i choose either to specify a manually defined very lightweight MTI profile to make implementation as lihtweight as possible or was referring to some pre-existing profile guidance rfc. Which i think are fairly big set of options. But i choose all of that only for the pieces i thought where "non-constrained", aka: can have a lot of TLS/... code for all the different crypto etc. So, for our CoAP/CoAPs i am quite clueless whether a) the RFCs (CoAP) we're referring to has a single MTI profile that will ensure all possible independent proxy and registrar implementations will interoperate b) That profile will allow proxies not to have more code than what you would like there to be (for CoAP/CoAPs) to be implementable only whatever you think the most lightweight proxy is that you're interested in. This is now a more generic review comment than my misguided URI comment. If we're fine on this a) and b) thats great. > But if we fear that implementers not versed in CoAP are going to mess things > up, we may want to write some additional guidance. Like how to deal with the > various options the client may include. Don't do unreasonavble stuff for me. If the above a) and b) makes sense and is solbed by existing text, we're done on this piece i think. > The forward/reverse proxy we tried to explain in > https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-07#section-3.5 > (in the context of CoAP group communication). No pictures there > unfortunately. Ok, will check in detail. Thanks Toerless > Esko > > -----Original Message----- > From: Toerless Eckert <t...@cs.fau.de> > Sent: Tuesday, November 1, 2022 16:21 > To: Michael Richardson <m...@sandelman.ca> > Cc: Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org; c...@ietf.org > Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP > > Our proxy is an application using CoAP. In that respect it is IMHO not a bad > idea to be explicit in what options are and what options are not to be > included > in the CoAP headers, and not expect that implementers should/could figure this > all out by themselves. Especially, when there are options whose inclusion and > reaction to could create a security risk. > > I guess i do not understand CoAP well enough, but the wy it sounds to me, > unclusion of the Uri option would be a security risk, because it would > allow the Pledge to indicate to the constrained proxy which registrar/proxy to > connect to, right ? Which a pledge shuoldn't be able to know anyhow, but if it > was including it, it could make the proxy select a registrar proxy that it > shouldn't use. > > If we do not document this, how would an implementer be supposed to come to > the conclusion of what E.g.: Esko wrote in his reply, e.g.: that an error > would be raised (which seems what we should do). > > Whats even all this terminology - forward/reverse proxy... Is there a simple > picture anyhwere in any of the RFC references explaining this ? > > Thanks! > Toerless > > On Mon, Oct 31, 2022 at 03:30:09PM +0100, Michael Richardson wrote: > > Toerless Eckert <t...@cs.fau.de> wrote: > > > Can we make sure that the text does explain why the field is not > > > inclueded, and explain that the packet MUST be rejected if it was > > > included ? > > > > Why should we reject if it is included? > > > > > Seems like: > > > > > Field is not included and would cause rejection of the packet if it > > was > > > present, because it is inappropriate for the initiator to choose the > > > next hop after the proxy not only because the Pledge would not know > > it, > > > but because it is also not appropriate for security purposes for the > > > Pledge to choose it. > > > > > Do i correctly understand this ? > > > > I don't think it's about the initiator choosing the next proxy. > > -- > --- > t...@cs.fau.de > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
