Re: [Iot-onboarding] draft-sarikaya-t2trg-sbootstrapping-05 is really good

[Behcet Sarikaya <[e-mail]>]

Hi Michael, all,

Please see inline.


On Sun, Dec 2, 2018 at 2:38 PM Michael Richardson <[e-mail]>
wrote:

>
> B. Sarikaya, M. Sethi and D. Garcia-Carillo
> have done some very good work with
>
> https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping-05
>
> The intro section deals with "bootstrapping" vs "onboarding", and there is
> also the term "enrollment"...
>
> Section 3 does not mention BRSKI, and it probably should, but you mention
> it
> in section 4... not sure I understand why. I guess it is a managed method?
>
>
Now in Revision 06, it does.



>
> "Opportunistic and leap-of-faith methods"
>
> I think that this category should be split up, and distinguish between
> methods that are Opportunistic (no memory, no implied trust), those which
> are LoF followed by Trust on First Use.
>
>
Sure Rev. 06 will fix this.



>       Additionally, various
>       online services such as Gmail and Facebook allow anyone to create
>       a new identity during the initial setup and later only verify the
>       continuity of the same identity.
>
> Not sure I understand this, maybe a reference would be worth it.
> Since I don't understand it, I don't know if it fits.
>
>
This text will be removed in Rev. 06.


> section 4.1 lists a bunch of one-touch (1+) methods as managed,
> which I actually find puzzling.  I do not consider many of the methods
> listed
> as enrollment or onboarding methods.  (By the (a) defintion of
> Introduction)
> They are all (b) methods, yet you include BRSKI there.
>
>
Well they are mostly (b) methods. This draft historically was aimed at
documenting the existing (b) methods and the addition of (a) methods are
more recent, so we intended to do both.



> [I-D.ietf-netconf-zerotouch] is an RFC8366 based mechanism, similar to
> BRSKI,
> but using a different set of assumptions about communications, including
> none
> (USB key).
>
>
Sure, we add this text also in Rev. 06. Sorry we had missed the reference
of RFC 8366.




> 4.2: I'm told that Thread version n+1 uses BRSKI.
>
> DPP:    DPP (Device Provisioning Protocol) [dpp] is a 3 message
>    authentication protocol currently being standardized by the WiFi
>    Alliance for devices that rely on IEEE 802.11 link-layer for
>    communication.  The current DPP specification is only aimed at
>    networks that use WPA2-PSK (also known as WPA2-Home) for network
>    access authentication.
>
> I was unaware that it was limited WPA2-PSK networks. I don't think that is
> true. Maybe WPA2-PSK type networks are just the sweet spot where it makes
> most sense.
>
>
Now this is all fixed in Rev. 06.



> Generally, I really like your section 1,2.
> Section 3 could use a bit of work.
>
>
Regarding your comments below, here what our views are:

Your comments on the classification: we will add a few terms to the
terminology section.
Making it like RFC 7228 is a completely different endeavor, a completely
new draft.
But it is not in our draft's scope. We have targeted t2trg charter item
when we wrote Section 4. Actually this section already was revised in
response to the reviews made, including yours which was an in-depth review.

I am personally interested in co-authoring such a terminology for
onboarding draft.
Maybe we can undertake such an activity on the context of the new
onboarding effort in IETF.

Regards,
Behcet

Regarding his comments on the classification, I suggest that we add a few
definitions to the terminology section
in reply to his request.
Making it like RFC 7228 is a complete makeover and it would amount to a
completely new draft and is not in our draft's scope.
Maybe the new onboarding effort in IETF may target something like this.


I suggest that we reply to his Section 4 comments saying that there is a
T2TRG charter item on this and that is what our draft corresponds to.

> I don't think the survey in section 4 is worthwhile as is.
>
> What I'd like to see is a clear set of terminology (a la RFC7228) that we
> can
> subsequently use.  Some really clear clarification of what some terms mean.
> I don't care if due to clashes with other word uses, we "Property Red",
> "RFC89AB-bootstrapping"... (or use Caribean island names or whatever).
>
> We could stop at that point, and then let the various documents apply the
> terminology to themselves.
>    "According to RFC89AB terminology, BRSKI is has Property Red, and
>    should be categorized into the set of Jamaican-Zero-Touch protocols"
>
> I think that getting section 4 nailed down is not very useful in an IETF
> or IRTF specification.   It will take too long, and might cause arguments
> that can't be resolved, even in IETF publication time.
>
> Instead, write a survey article for a journal (the IETF Journal is always
> looking for stuff...) that applies your terminology to various protocols.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>