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 protected]> wrote:
>
>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 protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
