Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

[Toerless Eckert <[e-mail]>]

Inline.

On Wed, Dec 09, 2015 at 06:49:37PM -0500, Michael Richardson wrote:
> 
> Toerless Eckert (eckert) <[e-mail]> wrote:
> 
>     > a) Lets assume we're talking bout announcements by Bob/Eve to connect to their ACP.
> 
>     > Minimally, Alice has no idea whom it wants to connect to. So it simply starts
>     > let's say dTLS to Bob and Eve. Alice will then figure out whether Bob and.or
>     > Eve have domain certs for the same domain Alice is in. If not, Alice (or Bob/Eve)
>     > will drop the dTLS connection.
> 
> I don't know why you write *TLS here. There is no specification for running
> IPv6 over TLS.

This is in the realm of ACP spec to resolve i think. Let me just remove this discussion
from this thread here by saying we firsst set up a TLS connection for GRASP, then
GRASP negotiates the secure transport for ACP packets, eg: MTI is IPsec. (I prefer
dTLS for ACP packets because of code size, but that's yet another derailing discussion).

It is now the TLS security exchange that will make Alice trust Bob/Eve and vice versa. Or
not, in which case the connection would be dropped. 

And, oh, by the way. Here is more generically how i think of "optional" parameters
for the discovery:

There are things that would make the TLS connection setup fail. Alice vs. Bob/Eve
could be in different domains. Or Bob/Eve certificate might have changed, or
Bob/Eve had a broken clock backup battery and thinks its 1990. Or there was an
internal redundancy failover that was not completely stateful, so Bob/Eve would like
connections rebuilt. If any of this gets fixed/changed, Bob/Eve would hope that Alice
will try to reconnect periodically after it failed.

Now, if Bob/Eve want to be friendly, they could
try to figure out if any relevant elements for the successfull mutual TLS set have
changed (such as above), and if they have changed, they will signal in their discovery that
there was change. In Multicast PIM we call this parameter of discovery (Hello) a GenID. 
There it was pec'ed only for internal redundancy failover or reboot, but IMHO its a more
generally applicable concept.  It's just a number thats changed. Eg: Timestamp of 
relevant last change.

In result, Alice would not need to periodically try to reconnect, but only when there is a 
GenID change. And of course we would need to specify a minimum interval for reconnection 
attempts in case Bob/Eve are evil and continuosly change change GenID. Maybe Alice wants 
to even do backoff in case a candidate neighbor connection fails, its GenID changes,
connection attempt still fails. And maybe still do a periodic re-connection attempt
after a longer period even if GenID has not changed.

Instead of letting the sending node figure out itself all the possible changes
it has had into a single GenID, it could also explicitly announce those parameter
values, like explicitly announcing domain name into discovery. But the goal would just
be to further optimize the non-need for another TLS connection attempt by Alice. SO
we can discuss if thats worth it.

In summary: I think what we put as parameters into the discovery only serves to
manage how to do re-connects of the following (TLS) security association. 

>     > b) Lets assume we're talking about announcements by Bob/Eve to be enrollment proxies.
> 
>     > So now Alice is not in a domain and will set up ESP "randomnly" to Bob and/or Eve.
> 
> I think you mean, EST?

ETYPO. Thanks.

>     > If we do not have a MASA, then Alice is really at the mercy of
>     > The guy who plugs Alice's cable into some network connection.
>     > "Do not plug into an untusty socket".
> 
> We can do things without a MASA, but the certificate validation chain is more complex.

Well, lets not call it MASA for a second but let me just generalize the two
conditions:

Alice was sold to some owner X. IN general, it can not have a trust point for
an arbitrary owner X. Instead it can only have trust-points for eg: its manufacturer
and whatever trusted third-parties the manufacturer burned trustpoints into Alice's firmware.

In the "insecure" case, the manufacturer and its trusted third-parties are too lazy to
set up any backend functions to make Alice confident that it belongs to X (which in
Max'es definition really is "Alice feels confident that its manufacturer or one of
its trusted henchmen will remember that Bob/Eves domain claims to own Alice). In the
"secure" case, they do this. These backend functions could be a MASA or maybe something
else. But i thought the way Max has defined MASA it should be a good superset of
any possible ways to give Alice this confidence. Not sure though. Hopefully Max will
chime in.

>     > Aka: Both Bob and Eve belong to friendly domains only accepting devices
>     > they know they own.
> 
>     > If we do have a MASA, Alice can feel more secure. So it connects to Eve,
>     > and Eve 's domain registrar wants to have Alice - even thoug alice doesn't below
>     > to Eves domain, but Eve is evil in this case. Alice will only accept enrollment
>     > when Eve is producing to Alice a ticket from the MASA stating that Alice belongs
>     > to Alices domain. And Alice trusts this ticket because it ultimately came from
> 
> Here, where you write "Alices domain", you mean "Eve's domain"

Right.

>     > I can't see how Bob/Eve announcing their certs here would help Alice at all
>     > before establishing the EST connection.
> 
> It could help if both Bob and Eve are part of the same domain, and so after a
> failure with Bob, Alice would know to go on to Frank, skipping Eve.

There are probably like for ACP also for bootstrap reasons for it to fail via Bob
that would not apply to Eve even if Bob/Eve are in the same domain.

> But, I agree that it doesn't in general help, because neither Bob nor Eve's
> certificate has any verifiable meaning to Alice.

Right.

Cheers
    Toerless

> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap


-- 
---
Toerless Eckert, [e-mail]