[Anima] GRASP securty/transport substrate alternatives (was: Re: Discovery of proxy/registrar insufficient ...) more).

[Toerless Eckert <[e-mail]>]

Changing subject as this is not directly related to the current constrained-brski drafts..

On Thu, Apr 28, 2022 at 02:13:40PM +1200, Brian E Carpenter wrote:
> > Yes, was thinking of that, but instead of trying to invent what i'd call a new lightweight
> > crypto header just use DTLS and TLS. So some similar or rewrite of that proposal.
> 
> TLS for the GRASP TCP sessions should be fine. The reason I did QUADS was because people told me that multicast DTLS was not a thing, but GRASP depends on multicast UDP.

But we only need unsecured link-local multicast fo DULL GRASP, but no other multicast.

And instead of TLS we just use DTLS everywhere for GRASP, e.g.: 
- link-local p2p DTLS insted link-local TCP over ACP secure channel 
  (because we have no ACP secure channel in such constrained networks)
- end-to-end p2p DTLS instead of end-to-end TLS over ACP secure channel

If we had a non-constrained network without ACP, we would do the same with TLS,
because ultimately DTLS is not less overhead than TLS, its just a religion
by some IoT folks.

Aka: just to recreate the ACP-GRASP experience without an ACP we could just
specify such a "constrained" DTLS and "unconstrained" TLS substrate option.

This is maybe a bit spec-it-and-hope-they-will-come, but obviously, the
overhead of a whole separate ACP is orders of magnitude higher than this
simple application-layer-only "service-management-daemon" (one way to sell GRASP).

The not-as-easy-resolved-issue is IMHO selecting some way to authenticate
GRASP messages, e.g.: optional JOSE field in GRASP messages or the like.
And defining maybe some ACP certificate property that authorizes the
node to announce services. Those type of better-than-group-security would
be likely highly needed in those non-ACP deployments.

Cheers
    Toerless

>    Brian
> 
> > 
> > > That work is not ready for the standards track but it shows proof of concept, if you accept the need for a shared secret.
> > 
> > Given how we would be pitching it to networks where devices are enrolled with a certificate,
> > we would get zero-touch deployment by using that certificate. And we given how we wouldn't
> > want to do address assignment, we might get away with non-enhanced certificates.
> > 
> > Its really the question where/how those constrained vouchers would be used in mesh networks and what
> > gaps those mesh networks might have.
> > 
> > 6TISCH for example seems like not having something useful for discovery right now if i correctly
> > extrapolate MichaelR's last reply here.
> > 
> > CHeers
> >      Toerless
> > 
> > > 
> > > Regards
> > >     Brian
> > > 
> > > On 26-Apr-22 12:16, Toerless Eckert wrote:
> > > > On Wed, Apr 13, 2022 at 01:19:21PM -0400, Michael Richardson wrote:
> > > > 
> > > > (1)
> > > > 
> > > > > Yes, you are right, we need to have a new objective to announce.
> > > > > I guess that we don't really think about the constrained-join-proxy really
> > > > > being used in an ACP context, but we really should that right.
> > > > 
> > > > I don't think this is true. As soon as EST-COAPS proliferates as an RFC,
> > > > the choice of TLS vs. COAPS becomes not only a necessity for constrained
> > > > devices, but also a preference choice by solution designers. Less code
> > > > modules etc.
> > > > 
> > > > Also, RFC8995 promised the COAPS solution as part of ANI (the way i see it).
> > > > 
> > > > I always imagined in-ceiling network switches that do full ACP but
> > > > are also gateways to IoT edge networks as a good size candidate market example.
> > > > 
> > > > (2)
> > > > 
> > > > Separate question: Do we have a good understanding which solution
> > > > that needs the constrained proxy will use which discovery mechanism ?
> > > > 
> > > > I am asking because if/where there are gaps in supported discovery mechanisms,
> > > > we might be able to suggest GRASP without ACP. Which would be somewhat of another
> > > > draft..
> > > > 
> > > > > https://github.com/anima-wg/constrained-join-proxy/issues/17
> > > > > 
> > > > >       > Note that it is not sufficient to delta RFC8995 and mention
> > > > >       > "EST-COAPS", because the GRASP objective also needs to indicate UDP
> > > > >       > instead of TCP. Even though it is longer, it would IMHO be prudent to
> > > > >       > copy the whole GRASP objectives and examples from RFC8995 and
> > > > >       > accordingly modify them, so that the constrained-proxy draft is
> > > > >       > "standalone" in this respect (even if a page longer).
> > > > > 
> > > > > I think you are asking us to show an example that advertises both RFC8995,
> > > > > and the constrained version, correct?
> > > > 
> > > > (3)
> > > > 
> > > > No. The example does not need to show both. Just constrained version as a
> > > > standalone GRASP objective IMHO. I would suggest to clone the text from
> > > > RFC8995 and accordingly modify it.
> > > > 
> > > > >       > Isn't there the thought that some other variations of BRSKI will use
> > > > >       > protocol variations, such as not CBOR+JSON ? some other "CMP" encoding
> > > > >       > ?
> > > > > 
> > > > > We decided that Registrars will be responsible for interoperation, and will
> > > > > support all protocols the operator expects to use.   If you buy a Registrar
> > > > > that does not do X and a pledge that only does X, then it fails, and you were
> > > > > stupid.
> > > > 
> > > > (4)
> > > > 
> > > > In the first place this needs to be written down.
> > > > 
> > > > But i'd rather like to argue it away because i think it is an unnecessary
> > > > constraining "hack".
> > > > 
> > > > Why have all this discovery mechanisms when they are not even used correctly.
> > > > Underspecifying the exact service(s) a Registrar offers is like announcing
> > > > "Oh, go to google for the WHATEVER services".
> > > > 
> > > > I don't see that implementations would get more complex, but rather
> > > > simpler if we simply are able to distinguish the different protocol options
> > > > by their service name/parameters and have proxies/clients be able to select
> > > > them.
> > > > 
> > > > At least thats my opening offer, lets discuss ;-) But see below.
> > > > 
> > > > >       > I am asking, because it seems to me we need to be aware, that the
> > > > >       > constrained-proxy is logically "just" a DTLS proxy, but once we have
> > > > >       > more than one DTLS BRSKI variation, we still need to be able for
> > > > >       > pledges to connect to registrar(s) that talk the BRSKI variation that
> > > > >       > the pledge supports. What we define here initially is effectively
> > > > >       > proxy/registrar for EST-COAPS. So let's assume, we get another
> > > > >       > protocol, OTHER1-DTLS. The constrained proxy continues to work, but it
> > > > >       > would now need to discover the OTHER1-DTLS Registrar, allocate a new
> > > > >       > UDP port number on which to offer proxy services for OTHER1-DTLS and
> > > > >       > announce that to pledges.
> > > > > 
> > > > > You aren't wrong, but you also aren't right.
> > > > > Pledges are expected to try all options (possibly concurrently if they have
> > > > > CPU/ram) until they find one that works.    There is no reason the join proxy
> > > > > needs to know the details of the Registrar supports, only that they support a
> > > > > way to talk to it.
> > > > 
> > > > (5)
> > > > 
> > > > That "trial&error" too should be described if its here to stay. Even if just
> > > > through a reference to an appropriate section in 8995 (if its in there, not sure).
> > > > 
> > > > (6)
> > > > 
> > > > How about cert renewal, did you folks discuss if this would ever be something
> > > > pledges would want to do through the proxy ? In the case of ACP we did
> > > > discuss this, and i thinkit's in 8994 as well. E.g.: when cert is expired, so
> > > > the enrolled device can not wield its cert for secure network access, but its
> > > > still good enough for renewal.
> > > > 
> > > > >       > I wonder if the names choosen for est-coaps discovery, brski.jp and
> > > > >       > brski.rjp are ideal indicative of the fact that we're rather defining
> > > > >       > brski-est-coaps.jp and brski-est-coaps.rjp. I guess beauty/explicitness
> > > > > 
> > > > > Fair point.
> > > > 
> > > > (7)
> > > > 
> > > > I guess a compromise for (4) would be new text that leaves the decision for
> > > > how to deal with the next enrollment protocol/encoding to such a followu draft:
> > > > 
> > > > IF implementers of a new variant feel that all existing/deployed registrars
> > > > will and should be able to support the new protocol variant (e.g.: brski-xmp-xyz),
> > > > then that protocol option does not need to come up with a new variation.
> > > > 
> > > > IF implementers feel that is not appropriate, then:
> > > > a) A new set of service names is required (brski-xmp-xyz.jp/rjp or the like)
> > > > b) constrained proxies supporting both the new and the old will have to
> > > >      effectively run separate instances for them, e.g.: each instance having
> > > >      a separate UDP port number towards the pledge and using separate
> > > >      service names from registrar and to proxy.
> > > > 
> > > > >       > 3. 6tisch discovery
> > > > > 
> > > > >       > [I-D.ietf-6tisch-enrollment-enhanced-beacon] is now RFC9032, please
> > > > >       > update draft accordingly.
> > > > > 
> > > > >       > Upon quick browse of RFC9032 i fail to see how/where RFC9032 would be
> > > > >       > able to deal with more than one discovery protocol. E.g.: How would we
> > > > >       > discover BRSKI-EST-COAPS-REGISTRAR BRSKI-EST-COAPS-PROXY
> > > > >       > OTHER1-DTLS-REGISTRAR OTHER1-DTLS-PROXY
> > > > > 
> > > > > Yes, are you right.
> > > > > RFC9032 does not support DTLS at all.
> > > > > It supports RFC9031 only.
> > > > > Perhaps we should simply indicate that we don't support 6TISCH.
> > > > 
> > > > No opinion. Sounds like the easiest solution, unless you do want some
> > > > way to support 6TISCH ?
> > > > 
> > > > >       > 4. Stateful vs. stateless proxy discovery
> > > > > 
> > > > >       > How do i know as a customer of equipment know that all my
> > > > >       > pledges/proxies/registrars will interoperate in the face of those
> > > > >       > devices seemingly being able to freely pick stateful and/or stateless
> > > > >       > mode of operations ?
> > > > > 
> > > > > Because, we defined the proxy to have a standard interface.
> > > > 
> > > > What does that mean ? Do all proxies need to support both modes, or
> > > > is there only the requirement for one mode, but some undefined entity has to
> > > > figue out what registrar/proxies in some network should decide to use ?
> > > > 
> > > > > (Except for CoAP/OSCORE vs CoAPS above)
> > > > 
> > > > OSCORE = ?
> > > > 
> > > > > How the join proxy keeps state (in memory or in the network) is a private
> > > > > matter between the JP and the Registrar, and does not concern the pledge.
> > > > 
> > > > Cheers
> > > >       Toerless
> > > > 
> > > > > --
> > > > > ]               Never tell me the odds!                 | ipv6 mesh networks [
> > > > > ]   Michael Richardson, Sandelman Software Works        | network architect  [
> > > > > ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> > > > > 
> > > > > 
> > > > > --
> > > > > Michael Richardson <[e-mail]>, Sandelman Software Works
> > > > >    -= IPv6 IoT consulting =-
> > > > 
> > > > _______________________________________________
> > > > Anima mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/anima
> > > > 
> > 

-- 
---
[e-mail]