Subject: [6tsch] Agenda for the call on July 5

From: Thomas Watteyne <[email-masked]>
Date: Thu, 4 Jul 2013 22:20:58 -0700

All,

Below is the proposed agenda for the 6TSCH call tomorrow:

   - Approval minutes last call [1min]
   - draft-ohba-6tsch-security-00 [10min]
   - Simulator [10min]
   - Description of PCE [10min]
   - Preparing for the BOF [25min]
   - Re-organization Bitbucket [2min]
   - AOB [1min]

As usual, feel free to propose any changes to the agenda, also at the
beginning of the call.

Remember that this call will be recorded.

Pascal & Thomas

Topic: 6TSCH Weekly
Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 206 802 913
Meeting Password: sixtus

-------------------------------------------------------
To start the online meeting
-------------------------------------------------------
1. Go to
https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D

2. Log in to your account.
3. Click "Start Now".
4. Follow the instructions that appear on your screen.

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San
Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

To check whether you have the appropriate players installed for UCF
(Universal Communications Format) rich media files, go to
https://ciscosales.webex.com/ciscosales/systemdiagnosis.php

http://www.webex.com

CCM:+14085256800x206802913

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Jul 2013 14:10:00 +0000

J'ai inclus les slides de Yoshi et des commentaires a moi..

Je n'ai pas confirm que JP vient... Je suis sûr que Yoshi tiendra 20mn avec toutes ses slides !

: )
Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 5 juillet 2013 07:21
To: 6TSCH
Subject: [6tsch] Agenda for the call on July 5

All,

  *   Approval minutes last call [1min]
  *   draft-ohba-6tsch-security-00 [10min]
  *   Simulator [10min]
  *   Description of PCE [10min]
  *   Preparing for the BOF [25min]
  *   Re-organization Bitbucket [2min]
  *   AOB [1min]

As usual, feel free to propose any changes to the agenda, also at the beginning of the call.

Pascal & Thomas

Topic: 6TSCH Weekly

1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D

The affected toll free numbers are: (866) 432-9903<tel:%28866%29%20432-9903> for the San Jose/Milpitas area and (866) 349-3520<tel:%28866%29%20349-3520> for the RTP area.

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800<tel:%2B1.408.525.6800> RTP: +1.919.392.3330<tel:%2B1.919.392.3330>

US/Canada: +1.866.432.9903<tel:%2B1.866.432.9903> United Kingdom: +44.20.8824.0117<tel:%2B44.20.8824.0117>

India: +91.80.4350.1111<tel:%2B91.80.4350.1111> Germany: +49.619.6773.9002<tel:%2B49.619.6773.9002>

Japan: +81.3.5763.9394<tel:%2B81.3.5763.9394> China: +86.10.8515.5666<tel:%2B86.10.8515.5666>

To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ciscosales.webex.com/ciscosales/systemdiagnosis.php

http://www.webex.com<http://www.webex.com/>

---

From: Rene Struik <[email-masked]>
Date: Fri, 05 Jul 2013 10:56:38 -0400

Hi Yoshi:

I had a look at your draft and reflected somewhat on the requirements 
mentioned.

Initial feedback:

General remark:
1) The draft text seems almost independent of 802.15.4e behavior. While 
the security considerations make reference to the need to authenticate 
time synch and channel hopping info in beacon frames and refer to 
potential nonce "overflow" issues, it is not that easy to see how the 
mechanisms described in the draft address these 802.15.4e-specific 
considerations.
2) The draft seems to aim at providing both (a) key establishment 
functionality (setting up a secure peer-to-peer channel); (c) key 
distribution (handing out link keys, muulticast keys, network keys). It 
would be useful to organize the draft so as to separate these 
functionalities more clearly (e.g., Phase-II KMP vs. Phase-II Key 
Distribution). What about key updates?

Security Framework (Section 3):
a) The security framework (Phase-III) seems to require incremental 
roll-out/planning of the network, witness Fig. 2. If so, it would be 
good to indicate how devices transgress through the different "phases" 
defined and to what degree this requires planning/intervention by an 
operator.
b) The bootstrapping phase (Phase-I) suggests inline interaction of a 
device with an authentication server (which is assumed to mostly be the 
coordinator of the mesh network). Since bootstrapping only results in 
issuance of credentials to be used by devices for Link Establishment 
(Phase-II), I can imagine this step to be often organized differently 
than described, e.g., by embedding a device certificate with a device at 
device manufacturing. In that case, no inline interaction with an 
authentication server seems required, at least not for *authentication* 
purposes.

KMP Requirements (Section 4):
R1-1: The requirement for mutual authentication seems to rule out 
"resurrecting duckling" policy models. Is this correct? Moreover, this 
rules out one/two pass protocols.
R1-2: The requirement for stateless relay may not work within the 
802.15.4e context: if a device A talks with an authentication server T 
via its neighbor R, where R and T operate in a secured network (i.e., 
one where all communications are cryptographically secured), R needs to 
"remember" that it should initially communicate back to A without 
security (since A and R do not have a shared key yet). Thus, R needs to 
maintain state that communications to A have to be treated differently 
(in 802.15.4e speak: A has "exempt status"). Or, is the idea that R 
somehow encodes this exempt status into its relay messages, so that it 
can pass this "hot potato" along and receive this back via T?
R2-2: I can imagine other scenarios than pre-provisioning of credentials 
or passing these along via Phase-I KMP: wouldn't piggy-backing this info 
along communication flows of Phase-II KMP also be an option?

Candidate KMPs (Section 5):
a) PANA. With bootstrapping during manufacturing, Phase-I may be 
organized differently. It would be good to show how PANA can fit 
802.15.4e needs in a stateless fashion.
b) HIP-DEX. The draft suggests this protocol (an expired draft), but at 
the same time points out that it is deficient, since does not support 
carrying certificates. This is somewhat puzzling.

On 7/5/2013 1:20 AM, Thomas Watteyne wrote:
> The affected toll free numbers are: (866) 432-9903 
> <tel:%28866%29%20432-9903> for the San Jose/Milpitas area and (866) 
> 349-3520 <tel:%28866%29%20349-3520> for the RTP area.
>
> San Jose, CA: +1.408.525.6800 <tel:%2B1.408.525.6800> RTP: 
> +1.919.392.3330 <tel:%2B1.919.392.3330>
>
> US/Canada: +1.866.432.9903 <tel:%2B1.866.432.9903> United Kingdom: 
> +44.20.8824.0117 <tel:%2B44.20.8824.0117>
>
> India: +91.80.4350.1111 <tel:%2B91.80.4350.1111> Germany: 
> +49.619.6773.9002 <tel:%2B49.619.6773.9002>
>
> Japan: +81.3.5763.9394 <tel:%2B81.3.5763.9394> China: +86.10.8515.5666 
> <tel:%2B86.10.8515.5666>
>
> http://www.webex.com <http://www.webex.com/>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 5 Jul 2013 18:15:41 +0200

Hi Rene:

Thanks for your review. Let me provide some comments about your review in Section 5.

a) Regarding PANA, it is worth noting that the usage PANA here is for phase 2 KMP, which is different from phase 1. Here a node tries to establish a one hop link connection with another node. Then one acts as the PaC and the other PAA. That is why the text says:

"It is worth noting that, though this candidate solution leverages the PaC implementation from Phase-1, each node needs to deploy a PAA implementation, an EAP server and a specific EAP method, which may be different from the one used for Phase-1."

So here, you run PANA between both nodes and establish a key that you pass to IEEE 802.15.4e to protect the link. I assume you want more details about this particular point, don't you?
 
b) Regarding HIP-DEX, the text says that HIP-DEX would require to carry certificates and for that you need CERT parameter. So, in the end, my understanding is that HIP-DEX is not deficient to carry certificates since you would have the CERT parameter for that.

Best Regards.

El 05/07/2013, a las 16:56, Rene Struik escribió:

> Hi Yoshi:
> 
> I had a look at your draft and reflected somewhat on the requirements mentioned.
>  
> Initial feedback:
> 
> General remark:
> 1) The draft text seems almost independent of 802.15.4e behavior. While the security considerations make reference to the need to authenticate time synch and channel hopping info in beacon frames and refer to potential nonce "overflow" issues, it is not that easy to see how the mechanisms described in the draft address these 802.15.4e-specific considerations. 
> 2) The draft seems to aim at providing both (a) key establishment functionality (setting up a secure peer-to-peer channel); (c) key distribution (handing out link keys, muulticast keys, network keys). It would be useful to organize the draft so as to separate these functionalities more clearly (e.g., Phase-II KMP vs. Phase-II Key Distribution). What about key updates?
> 
> a) The security framework (Phase-III) seems to require incremental roll-out/planning of the network, witness Fig. 2. If so, it would be good to indicate how devices transgress through the different "phases" defined and to what degree this requires planning/intervention by an operator.
> b) The bootstrapping phase (Phase-I) suggests inline interaction of a device with an authentication server (which is assumed to mostly be the coordinator of the mesh network). Since bootstrapping only results in issuance of credentials to be used by devices for Link Establishment (Phase-II), I can imagine this step to be often organized differently than described, e.g., by embedding a device certificate with a device at device manufacturing. In that case, no inline interaction with an authentication server seems required, at least not for *authentication* purposes.
>  
> R1-1: The requirement for mutual authentication seems to rule out "resurrecting duckling" policy models. Is this correct? Moreover, this rules out one/two pass protocols.
> R1-2: The requirement for stateless relay may not work within the 802.15.4e context: if a device A talks with an authentication server T via its neighbor R, where R and T operate in a secured network (i.e., one where all communications are cryptographically secured), R needs to "remember" that it should initially communicate back to A without security (since A and R do not have a shared key yet). Thus, R needs to maintain state that communications to A have to be treated differently (in 802.15.4e speak: A has "exempt status"). Or, is the idea that R somehow encodes this exempt status into its relay messages, so that it can pass this "hot potato" along and receive this back via T?
> R2-2: I can imagine other scenarios than pre-provisioning of credentials or passing these along via Phase-I KMP: wouldn't piggy-backing this info along communication flows of Phase-II KMP       also be an option?
> 
> a) PANA. With bootstrapping during manufacturing, Phase-I may be organized differently. It would be good to show how PANA can fit 802.15.4e needs in a stateless fashion.
> b) HIP-DEX. The draft suggests this protocol (an expired draft), but at the same time points out that it is deficient, since does not support carrying certificates. This is somewhat puzzling.
> 
> 
> 
> 
>> Approval minutes last call [1min]
>> draft-ohba-6tsch-security-00 [10min]
>> Simulator [10min]
>> Description of PCE [10min]
>> Preparing for the BOF [25min]
>> Re-organization Bitbucket [2min]
>> AOB [1min]
>> 
>> The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. 
>> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Rene Struik <[email-masked]>
Date: Fri, 05 Jul 2013 12:51:05 -0400

Hi Rafa:

Thanks for your note. Some brief feedback below.

Buen fin de semana.

Rene

On 7/5/2013 12:15 PM, Rafa Marin Lopez wrote:
> a) Regarding PANA, it is worth noting that the usage PANA here is for 
> phase 2 KMP, which is different from phase 1.

RS>>
True, Section 5.2 refers to use of PANA with Phase-II key establishment; 
however, Section 5.1 refers to use with Phase-I as well. The more 
important question to explain would be how it can act in stateless manner.
<<RS
> Here a node tries to establish a one hop link connection with another 
> node. Then one acts as the PaC and the other PAA. That is why the text 
> says:
>
> "It is worth noting that, though this candidate solution leverages the 
> PaC implementation from Phase-1, each node needs to deploy a PAA 
> implementation, an EAP server and a specific EAP method, which may be 
> different from the one used for Phase-1."
>
> So here, you run PANA between both nodes and establish a key that you 
> pass to IEEE 802.15.4e to protect the link. I assume you want more 
> details about this particular point, don't you?
> b) Regarding HIP-DEX, the text says that HIP-DEX would require to 
> carry certificates and for that you need CERT parameter. So, in the 
> end, my understanding is that HIP-DEX is not deficient to carry 
> certificates since you would have the CERT parameter for that.
>
RS>>
My understanding of the text was that HIP DEX does not include CERTs, 
but admittedly I did not check the internet draft. (As an aside, I 
thought HIP IETF group was winding down and the draft has been expired 
for a while).

The text says this:
However, by just using
the value of the public key and the private key is not enough to
carry out the authentication between nodes. In particular, a node
A and node B should not be able to successfully finish HIP DEX
execution if they both have not been authenticated in Phase-1.
Thus, HIP DEX will require the inclusion of the certificate of
each node to achieve full mutual authentication. The information
in the certificate must ensure that the node was authenticated in
Phase-1. In consequence, HIP DEX must include a CERT parameter
for carrying this certificate.
<<RS

RS>>
On a general note, when reviewing the text, I mostly look at security 
properties and try and see how protocols would fit the bill. To me, it 
was not clear what makes using HIP-{DEX, BEX, other acronym} desirable 
to use (and I am not aware of too many people who seriously looked into 
this). I think it would be useful to articulate why one *should* use a 
particular protocol, rather than simply listing protocols one apparently 
*could* use, and to articulate metrics (security properties, protocol 
flows, communication/computational latency, etc.).
<<RS

>> 1) The draft text seems almost independent of 802.15.4e behavior. 
>> While the security considerations make reference to the need to 
>> authenticate time synch and channel hopping info in beacon frames and 
>> refer to potential nonce "overflow" issues, it is not that easy to 
>> see how the mechanisms described in the draft address these 
>> 802.15.4e-specific considerations.
>> distribution (handing out link keys, muulticast keys, network keys). 
>> It would be useful to organize the draft so as to separate these 
>> good to indicate how devices transgress through the different 
>> "phases" defined and to what degree this requires 
>> planning/intervention by an operator.
>> device with an authentication server (which is assumed to mostly be 
>> the coordinator of the mesh network). Since bootstrapping only 
>> results in issuance of credentials to be used by devices for Link 
>> Establishment (Phase-II), I can imagine this step to be often 
>> organized differently than described, e.g., by embedding a device 
>> certificate with a device at device manufacturing. In that case, no 
>> inline interaction with an authentication server seems required, at 
>> least not for *authentication* purposes.
>>
>> "resurrecting duckling" policy models. Is this correct? Moreover, 
>> this rules out one/two pass protocols.
>> 802.15.4e context: if a device A talks with an authentication server 
>> T via its neighbor R, where R and T operate in a secured network 
>> (i.e., one where all communications are cryptographically secured), R 
>> needs to "remember" that it should initially communicate back to A 
>> without security (since A and R do not have a shared key yet). Thus, 
>> R needs to maintain state that communications to A have to be treated 
>> differently (in 802.15.4e speak: A has "exempt status"). Or, is the 
>> idea that R somehow encodes this exempt status into its relay 
>> messages, so that it can pass this "hot potato" along and receive 
>> this back via T?
>> R2-2: I can imagine other scenarios than pre-provisioning of 
>> credentials or passing these along via Phase-I KMP: wouldn't 
>> piggy-backing this info along communication flows of Phase-II KMP 
>> also be an option?
>>
>> b) HIP-DEX. The draft suggests this protocol (an expired draft), but 
>> at the same time points out that it is deficient, since does not 
>> support carrying certificates. This is somewhat puzzling.
>>
>>
>>
>>
>>> Japan: +81.3.5763.9394 <tel:%2B81.3.5763.9394> China: 
>>> +86.10.8515.5666 <tel:%2B86.10.8515.5666>
>>>
>> email:[email-masked]  | Skype: rstruik
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 5 Jul 2013 19:39:19 +0200

Hi Rene:

> Thanks for your note. Some brief feedback below.

Mine are also below

> Buen fin de semana.

Gracias!

>> a) Regarding PANA, it is worth noting that the usage PANA here is for phase 2 KMP, which is different from phase 1.
> 
> RS>>
> True, Section 5.2 refers to use of PANA with Phase-II key establishment; however, Section 5.1 refers to use with Phase-I as well. The more important question to explain would be how it can act in stateless manner.

Not sure how "stateless" applies in phase 2. I mean in this case there is no relay in the middle. Just PaC and PAA and a direct link between two nodes. I guess your comment is more related with R1-2 in Section 4, right?.

> <<RS
>> Here a node tries to establish a one hop link connection with another node. Then one acts as the PaC and the other PAA. That is why the text says:
>> 
>> "It is worth noting that, though
>>           this candidate solution leverages the PaC implementation from
>>           Phase-1, each node needs to deploy a PAA implementation, an EAP
>>           server and a specific EAP method, which may be different from the one
>>           used for Phase-1."
>> 
>> 
>>         
>> So here, you run PANA
>>           between both nodes and establish a key that you pass to IEEE
>>           802.15.4e to protect the link. I assume you want more details
>>           about this particular point, don't you?
>>  
>> b) Regarding HIP-DEX, the text says that HIP-DEX would require to carry certificates and for that you need CERT parameter. So, in
>>           the end, my understanding is that HIP-DEX is not deficient to
>>           carry certificates since you would have the CERT parameter for
>>           that.
>> 
>> 
>>         
> RS>> 
> My understanding of the text was that HIP DEX does not include CERTs, but admittedly I did not check the internet draft. (As an aside, I thought HIP IETF group was winding down and the draft has been expired for a while). 

The text is right and so is your interpretation: CERT parameter is not defined in HIP DEX but in RFC 5201 and draft-ietf-hip-rfc5201-bis-12. However, I do not see any reason why HIP-DEX could not carry this parameter.

> On a general note, when reviewing the text, I mostly look at security properties and try and see how protocols would fit the bill. To me, it was not clear what makes using HIP-{DEX, BEX, other acronym} desirable to use (and I am not aware of too many people who seriously looked into this). I think it would be useful to articulate why one *should* use a particular protocol, rather than simply listing protocols one apparently *could* use, and to articulate metrics (security properties, protocol flows, communication/computational latency, etc.).

Regarding HIP-DEX, and just as an example, you would expect something like http://www.cs.helsinki.fi/u/gurtov/papers/hip_dex.pdf

In any case, I understand your point. I guess, in general, you would like to see this type of analysis for each of the alternatives, no?. 

Best regards.

---

From: <[email-masked]>
Date: Fri, 5 Jul 2013 18:05:53 +0000

Hi Rene,

Thank you very much for your feedback.  Please see my comments below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Friday, July 05, 2013 11:57 PM
To: ohba yoshihiro
Cc: 6TSCH
Subject: [6tsch] Feedback on draft-ohba-6tsch-security-00

Hi Yoshi:

Initial feedback:

General remark:
1) The draft text seems almost independent of 802.15.4e behavior. While the security considerations make reference to the need to authenticate time synch and channel hopping info in beacon frames and refer to potential nonce "overflow" issues, it is not that easy to see how the mechanisms described in the draft address these 802.15.4e-specific considerations.
[YO] We have identified issue with Enhanced Beacon frame security in Security Considerations section.  Once we agree on a solution framework to address the EB security issue we will describe it.

2) The draft seems to aim at providing both (a) key establishment functionality (setting up a secure peer-to-peer channel); (c) key distribution (handing out link keys, muulticast keys, network keys). It would be useful to organize the draft so as to separate these functionalities more clearly (e.g., Phase-II KMP vs. Phase-II Key Distribution). What about key updates?
[YO] We will describe two functionalities in Phase-2 description.  Key updates will use key distribution.

Security Framework (Section 3):
a) The security framework (Phase-III) seems to require incremental roll-out/planning of the network, witness Fig. 2. If so, it would be good to indicate how devices transgress through the different "phases" defined and to what degree this requires planning/intervention by an operator.
[YO] I am not sure if I understand your comment above, but Fig.2 shows how a mesh network is formed after devices are placed where they are expected to operate.

b) The bootstrapping phase (Phase-I) suggests inline interaction of a device with an authentication server (which is assumed to mostly be the coordinator of the mesh network). Since bootstrapping only results in issuance of credentials to be used by devices for Link Establishment (Phase-II), I can imagine this step to be often organized differently than described, e.g., by embedding a device certificate with a device at device manufacturing. In that case, no inline interaction with an authentication server seems required, at least not for *authentication* purposes.
[YO] Yes, that is why R2-2 says “Phase-2 KMP authentication credentials MAY be pre-provisioned or MAY be obtained via Phase-1 KMP.”

KMP Requirements (Section 4):
R1-1: The requirement for mutual authentication seems to rule out "resurrecting duckling" policy models. Is this correct?
[YO] Not necessarily, because we plan to add Phase-0 where implanting bootstrap credential is expected to happen.

Moreover, this rules out one/two pass protocols.
[YO] I am not sure what you meant by “one/two pass protocols”..

R1-2: The requirement for stateless relay may not work within the 802.15.4e context: if a device A talks with an authentication server T via its neighbor R, where R and T operate in a secured network (i.e., one where all communications are cryptographically secured), R needs to "remember" that it should initially communicate back to A without security (since A and R do not have a shared key yet). Thus, R needs to maintain state that communications to A have to be treated differently (in 802.15.4e speak: A has "exempt status").
[YO] We meant “stateless” in R1-2 is about state maintained above MAC layer.  If 802.15.4e requires to maintain state for unauthenticated nodes at MAC layer to communicate with them, then we should not try to change it in IETF.
Or, is the idea that R somehow encodes this exempt status into its relay messages, so that it can pass this "hot potato" along and receive this back via T?

[YO] I don’t understand how piggy-backing (i.e., use of P2 KMP to provide P2 KMP credentials) can work.

Candidate KMPs (Section 5):
a) PANA. With bootstrapping during manufacturing, Phase-I may be organized differently. It would be good to show how PANA can fit 802.15.4e needs in a stateless fashion.
[YO] Please see my comment above.

b) HIP-DEX. The draft suggests this protocol (an expired draft), but at the same time points out that it is deficient, since does not support carrying certificates. This is somewhat puzzling.
[YO] Please see Rafa’s comment on this.

Regards,
Yoshihiro Ohba

All,

Pascal & Thomas

Topic: 6TSCH Weekly

6tsch mailing list

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

--

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

---

From: Rene Struik <[email-masked]>
Date: Fri, 05 Jul 2013 15:27:52 -0400

Hi Yoshi:

Please see feedback below.

Best regards, Rene

On 7/5/2013 2:05 PM, [email-masked] wrote:
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Rene Struik
> *Sent:* Friday, July 05, 2013 11:57 PM
> *To:* ohba yoshihiro
> *Cc:* 6TSCH
> *Subject:* [6tsch] Feedback on draft-ohba-6tsch-security-00
>
> Hi Yoshi:
>
> refer to potential nonce "overflow" issues, it is not that easy to see
> how the mechanisms described in the draft address these
> */[YO] We have identified issue with Enhanced Beacon frame security in
> Security Considerations section. Once we agree on a solution framework
> to address the EB security issue we will describe it./*
>
> */[YO] We will describe two functionalities in Phase-2 description.
> Key updates will use key distribution. /*
>
> */[YO] I am not sure if I understand your comment above, but Fig.2
> shows how a mesh network is formed after devices are placed where they
> are expected to operate. /*
>
/**/RS>>
It seems very well possible that secure channels can be established
between devices in a less hierarchical fashion than suggested in Fig. 2.
As an example, B and D may set-up a secure channel locally ("Phase II"),
without B first having to perform a protocol with A ("Phase I"). This
ties into my question re the security model, where (in my mind, at
least) Phase-I may very well be superfluous, e.g., when devices already
have certs on board. In the model 3-phase model described in the draft,
however, every device first has to talk with the Mothership node A
(authentication server), thus forcing a hierarchical model. In short:
your picture seems to reflect a hierarchical trust model, which seems to
be a choice, rather than a necessity. If devices already have some
credentials on board, one seems to be able to collapse (1) and (2) and
remove (3); moreover, one could swap the order of the (1)-(2) tandem and
(4) then (at least from a secure channel set-up perspective).
<<RS
> *//*
> the coordinator of the mesh network). Since bootstrapping only results
> in issuance of credentials to be used by devices for Link
> */[YO] Yes, that is why R2-2 says “Phase-2 KMP authentication
> credentials MAY be pre-provisioned or MAY be obtained via Phase-1 KMP.”/*
>
RS>>
If a device already has a cert on board, Phase-I seems superfluous. If
you agree, I would suggest adding some language to that effect (right
now, the Phase-I, II, III sequence comes up all over the place in the
draft).
<<RS
> "resurrecting duckling" policy models. Is this correct?
>
> */[YO] Not necessarily, because we plan to add Phase-0 where
> implanting bootstrap credential is expected to happen./*
>
RS>>
My comment was on the current draft, so perhaps a future planned Phase-0
step would allow resurrecting duckling type configuration. That would be
good from a trust policy lifecycle management perspective.
<<RS
> *//*
> */[YO] I am not sure what you meant by “one/two pass protocols”./*.
>
RS>>
Mutual authentication (I presumed entity authentication) assumes each
party to provide cryptographic evidence based on an input received from
the other party, so requires more than two passes. If you meant mutual
authentication without aliveness guarantees, one may end up with replay
attacks.
<<RS
> one where all communications are cryptographically secured), R needs
> to "remember" that it should initially communicate back to A without
> security (since A and R do not have a shared key yet). Thus, R needs
> to maintain state that communications to A have to be treated
> differently (in 802.15.4e speak: A has "exempt status").
>
> */[YO] We meant “stateless” in R1-2 is about state maintained above
> MAC layer. If 802.15.4e requires to maintain state for unauthenticated
> nodes at MAC layer to communicate with them, then we should not try to
> change it in IETF./*
>
RS>>
The requirement for stateless behavior has much diminish meaning, if one
needs to maintain state at the MAC anyway (thus, should perhaps be
dropped). On a more general note, I would suggest checking the incoming
and outgoing frame processing sections of the 802.15.4 specification, to
see what state needs to be maintained for processing to work.
<<RS
>
> *//*
>
> Or, is the idea that R somehow encodes this exempt status into its
> relay messages, so that it can pass this "hot potato" along and
> receive this back via T?
>
>
> piggy-backing this info along communication flows of Phase-II KMP also
> be an option?
>
> *//*
>
> */[YO] I don’t understand how piggy-backing (i.e., use of P2 KMP to
> provide P2 KMP credentials) can work./*
>
RS>>
Something along these lines has been suggested in the context of 802.11
join protocols (between STA and AP). We can discuss offline.
<<RS
> *//*
> */[YO] Please see my comment above. /*
>
RS>>
As suggested before, Phase-I as described in the draft is not the only
way of doing things (and arguably an expensive way). One additonal note
on PANA: RFC 6786 uses a different nonce format when encrypting
attributes than 802.15.4 uses. Depending on hardware/software boundaries
of CCM impementations, this
could cause a problem.
<<RS
> *//*
> */[YO] /*Please see Rafa’s comment on this.
>
RS>>
See my separate email note on HIP-DEX to Rafa.
<<RS
>     ?Approval minutes last call [1min]
>
>     ?draft-ohba-6tsch-security-00 [10min]
>
>     ?Simulator [10min]
>
>     ?Description of PCE [10min]
>
>     ?Preparing for the BOF [25min]
>
>     ?Re-organization Bitbucket [2min]
>
>     ?AOB [1min]
>
>     <tel:%28866%29%20432-9903> for the San Jose/Milpitas area and
>     (866) 349-3520 <tel:%28866%29%20349-3520> for the RTP area.
>
>     To check whether you have the appropriate players installed for
>     UCF (Universal Communications Format) rich media files, go to
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

---

From: <[email-masked]>
Date: Sat, 6 Jul 2013 01:27:55 +0000

Hi Rene,

Now I understand your comments better.  Please see my comments below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Saturday, July 06, 2013 4:28 AM
To: ohba yoshihiro
Cc: [email-masked]
Subject: Re: [6tsch] Feedback on draft-ohba-6tsch-security-00

Hi Yoshi:

Best regards, Rene

On 7/5/2013 2:05 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi Rene,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Friday, July 05, 2013 11:57 PM
To: ohba yoshihiro
Cc: 6TSCH
Subject: [6tsch] Feedback on draft-ohba-6tsch-security-00

Hi Yoshi:

Initial feedback:

General remark:
1) The draft text seems almost independent of 802.15.4e behavior. While the security considerations make reference to the need to authenticate time synch and channel hopping info in beacon frames and refer to potential nonce "overflow" issues, it is not that easy to see how the mechanisms described in the draft address these 802.15.4e-specific considerations.
[YO] We have identified issue with Enhanced Beacon frame security in Security Considerations section.  Once we agree on a solution framework to address the EB security issue we will describe it.
2) The draft seems to aim at providing both (a) key establishment functionality (setting up a secure peer-to-peer channel); (c) key distribution (handing out link keys, muulticast keys, network keys). It would be useful to organize the draft so as to separate these functionalities more clearly (e.g., Phase-II KMP vs. Phase-II Key Distribution). What about key updates?
[YO] We will describe two functionalities in Phase-2 description.  Key updates will use key distribution.
Security Framework (Section 3):
a) The security framework (Phase-III) seems to require incremental roll-out/planning of the network, witness Fig. 2. If so, it would be good to indicate how devices transgress through the different "phases" defined and to what degree this requires planning/intervention by an operator.
[YO] I am not sure if I understand your comment above, but Fig.2 shows how a mesh network is formed after devices are placed where they are expected to operate.
RS>>
It seems very well possible that secure channels can be established between devices in a less hierarchical fashion than suggested in Fig. 2. As an example, B and D may set-up a secure channel locally ("Phase II"), without B first having to perform a protocol with A ("Phase I"). This ties into my question re the security model, where (in my mind, at least) Phase-I may very well be superfluous, e.g., when devices already have certs on board. In the model 3-phase model described in the draft, however, every device first has to talk with the Mothership node A (authentication server), thus forcing a hierarchical model. In short: your picture seems to reflect a hierarchical trust model, which seems to be a choice, rather than a necessity. If devices already have some credentials on board, one seems to be able to collapse (1) and (2) and remove (3); moreover, one could swap the order of the (1)-(2) tandem and (4) then (at least from a secure channel set-up perspective).
<<RS
[YO] While it is possible to swap the order from a secure channel set-up perspective, the swapping will cause higher-layer connectivity problem and is no good from  networking perspective.

b) The bootstrapping phase (Phase-I) suggests inline interaction of a device with an authentication server (which is assumed to mostly be the coordinator of the mesh network). Since bootstrapping only results in issuance of credentials to be used by devices for Link Establishment (Phase-II), I can imagine this step to be often organized differently than described, e.g., by embedding a device certificate with a device at device manufacturing. In that case, no inline interaction with an authentication server seems required, at least not for *authentication* purposes.
[YO] Yes, that is why R2-2 says “Phase-2 KMP authentication credentials MAY be pre-provisioned or MAY be obtained via Phase-1 KMP.”
RS>>
If a device already has a cert on board, Phase-I seems superfluous. If you agree, I would suggest adding some language to that effect (right now, the Phase-I, II, III sequence comes up all over the place in the draft).
<<RS
[YO] OK, we will add some language to indicate that Phase-I can be skipped if a device already has Phase-2 KMP credentials.

KMP Requirements (Section 4):
R1-1: The requirement for mutual authentication seems to rule out "resurrecting duckling" policy models. Is this correct?
[YO] Not necessarily, because we plan to add Phase-0 where implanting bootstrap credential is expected to happen.
RS>>
My comment was on the current draft, so perhaps a future planned Phase-0 step would allow resurrecting duckling type configuration. That would be good from a trust policy lifecycle management perspective.
<<RS

Moreover, this rules out one/two pass protocols.
[YO] I am not sure what you meant by “one/two pass protocols”..
RS>>
Mutual authentication (I presumed entity authentication) assumes each party to provide cryptographic evidence based on an input received from the other party, so requires more than two passes. If you meant mutual authentication without aliveness guarantees, one may end up with replay attacks.
<<RS
[YO] Now I understand.  Yes, mutual authentication  rules out one/two pass protocols (and nothing is wrong with it).

R1-2: The requirement for stateless relay may not work within the 802.15.4e context: if a device A talks with an authentication server T via its neighbor R, where R and T operate in a secured network (i.e., one where all communications are cryptographically secured), R needs to "remember" that it should initially communicate back to A without security (since A and R do not have a shared key yet). Thus, R needs to maintain state that communications to A have to be treated differently (in 802.15.4e speak: A has "exempt status").
[YO] We meant “stateless” in R1-2 is about state maintained above MAC layer.  If 802.15.4e requires to maintain state for unauthenticated nodes at MAC layer to communicate with them, then we should not try to change it in IETF.
RS>>
The requirement for stateless behavior has much diminish meaning, if one needs to maintain state at the MAC anyway (thus, should perhaps be dropped). On a more general note, I would suggest checking the incoming and outgoing frame processing sections of the 802.15.4 specification, to see what state needs to be maintained for processing to work.
<<RS
[YO] Even if MAC layer needs to maintain state, being stateless in authentication messaging over MAC layer is an important property for constrained devices.  Also seeing 802.15.4 specification, one could implement the 802.15.4 behavior around Exempt element in a stateless manner.

[YO] I don’t understand how piggy-backing (i.e., use of P2 KMP to provide P2 KMP credentials) can work.
RS>>
Something along these lines has been suggested in the context of 802.11 join protocols (between STA and AP). We can discuss offline.
<<RS

Candidate KMPs (Section 5):
a) PANA. With bootstrapping during manufacturing, Phase-I may be organized differently. It would be good to show how PANA can fit 802.15.4e needs in a stateless fashion.
[YO] Please see my comment above.
RS>>
As suggested before, Phase-I as described in the draft is not the only way of doing things (and arguably an expensive way). One additonal note on PANA: RFC 6786 uses a different nonce format when encrypting attributes than 802.15.4 uses. Depending on hardware/software boundaries of CCM impementations, this
could cause a problem.
<<RS

Regards,
Yoshihiro Ohba

Regards,
Yoshihiro Ohba

All,

Pascal & Thomas

Topic: 6TSCH Weekly

6tsch mailing list

--

--