Subject: [6tisch] Michael's comments on the security section

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Apr 2015 18:42:42 +0000

Dear all :

I published in the bucket an early version of archie 07 that takes care of most of Michael's comments (Michael please review my responses in the tickets and eventually propose a better stack figure).

But some comments on section 13 need some more attention, in particular from the security DT. Here they are:

------------

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.

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.

-----------

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.

I suggest that figure 10 be omitted.

---------
Comments?

Cheers,

Pascal

---

From: Rene Struik <[email-masked]>
Date: Tue, 07 Apr 2015 15:00:38 -0400

Hi Pascal:

Please note that I provided suggested dispositions of all 
security-related comments re draft-ietf-6tisch-architecture-05 roughly a 
month ago, on Thu March 5, 2015:

a) Suggested disposition of Jonathan Simon's comments:
Please see my email of  Thu March 5, 2015, 7.26pm EDT: 
http://www.ietf.org/mail-archive/web/6tisch/current/msg03020.html
Note: suggested disposition discussed (and formulated) during conf call 
with Kris Pister, who acted on Jonathan Simon's behalf.

b) Suggested disposition of Michael Richardson's comments:
Please see my email of  Thu March 5, 2015, 7.27pm EDT: 
http://www.ietf.org/mail-archive/web/6tisch/current/msg03021.html

c) Suggested disposition of my own comments:
Please see my email of  Thu March 5, 2015, 8:17pm 
EDT:http://www.ietf.org/mail-archive/web/6tisch/current/msg03022.html

I suggest you give this a look.

Best regards, Rene

On 4/7/2015 2:42 PM, Pascal Thubert (pthubert) wrote:
>
> Dear all :
>
> I published in the bucket an early version of archie 07 that takes 
> care of most of Michael’s comments (Michael please review my responses 
> in the tickets and eventually propose a better stack figure).
>
> But some comments on section 13 need some more attention, in 
> particular from the security DT. Here they are:
>
> ------------
>
> 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.
>
> 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.
>
> -----------
>
> 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.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Apr 2015 05:44:57 +0000

Hello René:

Thanks for this; indeed, I noted that you and Michael disagree on the questions I attached. So I'm looking for others to give their own point of view.
At the very least, I would expect that we define that the authentication of the JA really means that we validate that the JA pertains to the network that the node should join, as opposed to validate that the JA is whoever it claims, which is of secondary interest.

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]]
Sent: mardi 7 avril 2015 21:01
To: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [6tisch] Michael's comments on the security section

Hi Pascal:

Please note that I provided suggested dispositions of all security-related comments re draft-ietf-6tisch-architecture-05 roughly a month ago, on Thu March 5, 2015:

a) Suggested disposition of Jonathan Simon's comments:
Please see my email of  Thu March 5, 2015, 7.26pm EDT: http://www.ietf.org/mail-archive/web/6tisch/current/msg03020.html
Note: suggested disposition discussed (and formulated) during conf call with Kris Pister, who acted on Jonathan Simon's behalf.

b) Suggested disposition of Michael Richardson's comments:
Please see my email of  Thu March 5, 2015, 7.27pm EDT: http://www.ietf.org/mail-archive/web/6tisch/current/msg03021.html

c) Suggested disposition of my own comments:
Please see my email of  Thu March 5, 2015, 8:17pm EDT:http://www.ietf.org/mail-archive/web/6tisch/current/msg03022.html

Best regards, Rene

------------

-----------

---------
Comments?

Cheers,

Pascal

6tisch mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Apr 2015 13:13:57 -0400

I have reviewed your emails again, thank you for the links.

I wrote:
    mcr>    I have also repeatedly complained that figure 10 is inaccurate,
    mcr> because it fails to depict that authorization begins before
    mcr> authentication finishes.  Perhaps the second two unidirectional
    mcr> arrows are part of the authentication phase, I don't know.

To which you replied:

    rs>             Please note that one figures cannot depict all aspects
    rs> of the join process; it is only there to support the text in Section
    rs> 13.1. The current text reflects confirmed consensus in the 6TiSCH
    rs> security design team [see also minutes conf call of January 22,
    rs> 2015:
    rs> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html]
    rs> {in which you also participated}). The figure indicates that

It must be frustrating to have to repeat yourself over and over again.

    rs> authentication from the joining node JN starts prior to the initial
    rs> authorization frame being sent to the JCE (after all, the JN
    rs> initiates the join protocol). The communication messages between JN
    rs> and JA include multiple protocol flows, as also depicted in the
    rs> figure, where the last authentication message (from JCE to JN) takes
    rs> place after the initial authorization message to the JCE.

Well, my question above, was specifically, why is the first authorization
arrow indicated as <-> (implying multiple RTT), and is labelled, and then
authorization begins and completes, and then there are two unidirectional
arrows that depict another exchange, but they are unlabelled.

Your answer above suggests the second two unidirectional arrows are in fact
part of the authentication process.  If this is the case, then we are in
violent agreement.

It is precisely this point that I wanted clarified as I believe it is
architecturally critical that we understand that the authentication and
authorization processes, while perhaps seperable from a protocol point of
view, are intertwined from a join-assistant state machine point of view.

    rs> This is
    rs> reflected in the figure. Besides, logically, it cannot be any other
    rs> way, since authentication by the JCE to the JN should depend on some
    rs> inputs from the JN. In my mind, no changes are required.

I don't think that the figure reflects this. I think that the figure suggests
that authentication has completed before authorization begins.

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

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 23 Apr 2015 05:00:35 +0000

Hi Michael, Rene,

To close on the comment about Figure 10/join process, with the below
discussion are we ok to progress the draft or do you think we need to
label the picture better?
If we the comment is still open would the below labeling of the arrows
following authorization exchange b/n JA and JCE help resolve this comment?

   {joining node}     {neighbor}               {server, etc.}   Example:
   +---------+        +---------+                 +---------+
   | Joining |        |  Join   |              +--|    CA   |certificate
   |  Node   |        |Assistant|              |  +---------+   issuance
   +---------+        +---------+              |  +---------+
      |                    |                   +--|Authoriz.| membership
      |<----Beaconing------|                   |  +---------+ test (JCE)
      |                    |                   |  +---------+
      |<--Authentication-->|                   +--| Routing | IP address
      |                    |<--Authorization-->|  +---------  assignment
      |<---- AA* contd ----|                   |  +---------+
      |                    |                   +--| Gateway | backbone,
      |---- AA* contd ---->|                   |  +---------+    cloud
      |                    |<--Configuration-->|  +---------+
      |<-------------------|                   +--|Bandwidth|  PCE
                                                  +---------+  schedule
       .                    .                   .
       .                    .                   .
*Authentication/Authorization continued

    Figure 10: Network joining, with only authorization by third party

Thanks,
Shwetha

On 4/10/15 10:43 PM, "Michael Richardson" <[email-masked]> wrote:

>    rs> 
>http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html
>]