Dear Michael:

Please find below my suggested resolution of your comments related to 
security.

Best regards, Rene

On 2/19/2015 7:34 AM, Michael Richardson wrote:
> {I fat-fingered this to the wrong list last night.}
>
>
> My appologies for the lateness of this review.
> One good point is that it's been 10 weeks since I read the document
> From=20beginning to end, and some things stick out that did not bother me
> before.
>
> My tl;dr> conclusion is that the document is not ready to proceed as is.
> If it is going to proceed in volumes (I suggest "editions" is the correct
> term), then I think that most things which are speculation should
> either be removed to a later edition, or something specific should be
> said, with the understanding that it might change later.
> Presciption rather than speculation should be the goal.
>
>
>
> 5) the security words include: "will be studied in the next round of this d=
> ocument."
>     and I'm not sure what a reader should make of this.  Perhaps it should
>     simply summarize section 13 in one sentence and say that PANA is a
>     possibility, but that the choice of protocol is out of scope for this
>     document.
>     (well, 5.0 then explains about volumes.  So perhaps the explanation
>     about volumes should go much earlier, most probably into the abstract as
>     well.  Also, will the volumes build on the previous work, or will they
>     replace it?  if they will replace it, then I think correct word is "edit=
> ion")
RS>>
I suggest we replace p. 7, 2nd para by the following text: "Security 
aspects of the join process are discussed in Section 13." This also 
avoids any conflicts with the text in Section 13.
<<RS

9) I am happy with the paragraph on join security in section 5.RS>>
I suggest to remove p.9, 4th para entirely (it conflicts with elements 
of Section 13, which section reflects confirmed consensus in the 6TiSCH 
security design team [see also minutes conf call of January 22, 2015: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html]).
<<RS

20) last comment on section 13. (the bullet (*) has become an ASCII "A", 
the high bit was likely removed)RS>>
The article is not wrong, but having dashes, stars, etc., instead (as 
the suggestion seems to be) is also okay. {BTW - I checked the XML file, 
which showed "a"}.
<<RS
>     Device Authentication:  The JN and the JA mutually authenticate each
>           other and establish a shared key, so as to ensure on-going
>           authenticated communications.  This may involve a server as a
>           third party.
>
>     I again say that this is incorrect, the JA will never be able to
>     authenticate *itself* to the JN.  It may be able to present some
>     *authorization* from the *network owner*, that the JA is authorized
>     to act on behalf of the network owner.
RS>>Please note that the scenario described assumes as particular 
initial set-up requirements (see p. 32, 2nd para) that devices have 
certs and access to each other's CA root key. Under those condition, any 
authenticated public-key key agreement scheme results in mutual 
authentication of the parties involved in that protocol (here, joining 
node and join assistant). So, your absolute statement is incorrect. This 
being said, the text also pays homage to the scenario where this initial 
set-up requirement might not be satisfied: please see p. 33, 1st and 2nd 
para (those paras discuss what happens in case, e.g., a device does not 
have a cert or encounters another out-of-sync behavioral state). In my 
mind, no changes are required.

Please note that the scenario where the JA might assume a role beyond 
simply being a relay station was extensively discussed during 6TiSCH 
security calls [see, e.g., the minutes of the Dec 16, 2014 call: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00383.html 
{in which you also participated}].
<<RS

>     Unless you consider un-authenticated DH exchange "authentication",
>     or you decide that it's okay for the JA to just not accept any
>     public (some kind of leap of faith), the JA will not have an
>     identity that a JN will accept.
RS>> This seems to confuse authorization and authentication. As already 
said, if devices have certs, the authenticated key agreement scheme 
automatically (and mechanically) results in mutual authentication. 
Whether this identity should be accepted is the object of authorization 
policies; hence, the authorization language in, e.g., p. 32, 3rd para 
and earlier on p. 32, with description of authorization phase. In my 
mind, no changes are required.
<<RS
>     I have also repeatedly complained that figure 10 is inaccurate,
>     because it fails to depict that authorization begins before
>     authentication finishes.  Perhaps the second two unidirectional
>     arrows are part of the authentication phase, I don't know.
RS>>
Please note that one figures cannot depict all aspects of the join 
process; it is only there to support the text in Section 13.1. The 
current text reflects confirmed consensus in the 6TiSCH security design 
team [see also minutes conf call of January 22, 2015: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html] 
{in which you also participated}). The figure indicates that 
authentication from the joining node JN starts prior to the initial 
authorization frame being sent to the JCE (after all, the JN initiates 
the join protocol). The communication messages between JN and JA include 
multiple protocol flows, as also depicted in the figure, where the last 
authentication message (from JCE to JN) takes place after the initial 
authorization message to the JCE. This is reflected in the figure. 
Besides, logically, it cannot be any other way, since authentication by 
the JCE to the JN should depend on some inputs from the JN. In my mind, 
no changes are required.
<<RS
>     I suggest that the sentence:
>
>     "The join protocol consists of three phases:"
>
> be replaced with:
>
>     "The join protocol has three major activities:"
>     ("phases" implies some ordering such that one phase might finish
>     before the next begins, while activities implies no such ordering
RS>> The description of the three phases of the join process (p. 32, 1st 
para) does not include any language that suggests such ordering (there 
is no mentioning of "in order", etc.). When describing a process as the 
composition of several subprocesses, without restricting language, it is 
common usage that any interleaving is possible, subject to logical 
events in one subprocess being a precondition for ones in a different 
subprocess). In my mind, no change is required.
<<RS
>     I suggest that figure 10 be omitted.
RS>>
In my mind, this figure correctly reflects the join process, at the 
right level of detail one may expect at this stage of the design 
process. Please note that the current text of Section 13 (minus the 2nd 
para) reflects confirmed consensus in the 6TiSCH security design team 
[see also minutes conf call of January 22, 2015: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html] 
{in which you also participated}]. At the time, you expressed full 
consensus then and also did not raise these issues when asking for 
approval of the minutes.
<<RS

>
>
>
>
> --
> Michael Richardson<mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch


-- 
email:rstruik.ext@gmail.com  | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363