Subject: [Anima] Logging vouchers use case

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 8 Feb 2019 11:22:33 -0500

Hello,

I am reading the voucher artifact RFC 8366. I am confused about how the
"audit voucher" (page 6) is supposed to be used. Specifically, the text
says  " The registrar mitigates a MiTM registrar by auditing that an
unknown MiTM registrar does not appear in the log entries. " How can it do
this? Any concrete example that clarifies this use case would help me
understand.

I am not sure if this is the correct mailing list for this question. Thanks
in advance for your help.

Regards,

Ranga

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 8 Feb 2019 14:21:57 -0500

Clarification on question below:

> this? Any concrete example that clarifies this use case would help me
What is confusing me is the interpretation of the term "Man In The Middle"
(MiTM). Am I correct in assuming that this refers to previous registrars
where the device may have successfully registered?

> I am not sure if this is the correct mailing list for this question.
> Thanks in advance for your help.
>
> Regards,
>
> Ranga
>
> --
> M. Ranganathan
>
>

-- 
M. Ranganathan

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 19 Feb 2019 12:55:32 +0100

Ranga,

It depends ;-)

Pledge P registers at a specific registrar B. B examines the audit log and
determines that P was previously registered at another registrar A. Now
B can see from theidentity of A in the audit log if A belongs to the
same trust domain as B. If yes, then B would likely happily re-register
P. Use-case: A failed and was replaced by B, or multiple registrars in
the trust domain. Alternative, A is not known to be in the same trust
domain by B, so B would refuse to register P, probably raise an
exception to operations. In this case, i could come up with a range of
use case examples what operations would do next.

Does this help ?

Cheers
    Toerless

P.S.: Experimenting if the old alias for the co-authors still work. I
think IETF tools keep it alife for a few years.

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 19 Feb 2019 13:09:32 -0500

> use case examples what operations would do next.

HI Toerless,

Yes that clarifies things and in line with the mental picture I had built
in my mind. Perhaps it would be a good idea to clarify the document with an
explanation like you have stated above.

Thanks,

Ranga

-- 
M. Ranganathan

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Feb 2019 18:30:51 +0000

Hi Ranga,

The IETF doesn't have a good way to capture improvement suggestions such
as this.   Perhaps you could file an Errata suggesting a small tweak that would
improve the text a little.   Even if the errata is rejected, it will still live forever in
the tracker and undoubtedly reviewed if ever an update to the RFC is being
considered.

Kent // co-author

> On Feb 19, 2019, at 1:09 PM, M. Ranganathan <[email-masked]> wrote:
> 
> 
> 
> On Tue, Feb 19, 2019 at 6:55 AM Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
> Ranga,
> 
> It depends ;-)
> 
> Yes that clarifies things and in line with the mental picture I had built in my mind. Perhaps it would be a good idea to clarify the document with an explanation like you have stated above..
> 
> Thanks,
> 
> Ranga
> 
> 
> > On Fri, Feb 8, 2019 at 11:22 AM M. Ranganathan <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > > Hello,
> > >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> 
> 
> -- 
> M. Ranganathan 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Feb 2019 13:45:04 -0500

I'm not sure it matters that B is in the same trust domain as A, wrt the
audit log.
Maybe you meant to say:

    Pledge P registers at a specific registrar B.

    B examines the audit log and determines that P was previously registered
    at another registrar A.

    Now B can see that there is an A in the audit log.

    If A belongs to the same trust domain as B, then B would likely
    happily re-register P.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Feb 2019 15:00:32 +0100

> explanation like you have stated above.

Mcr at one time suggested an operational document for BRSKI. This
wouldn't even be specific to BRSKI but would equally apply to NetConf
with vouchers (i think). But in any case we'd need to createvely find a
new home for such explanations, because RFC8366 is done, and i'd in my
feeling rev'ing it right now wouldn't be the best new home for such
explanations.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Feb 2019 15:02:23 +0100

>     If A belongs to the same trust domain as B, then B would likely

I thought this is what i said ;-)

Cheers
    Toerless