Re: [6tsch] (note on HIP-DEX) Re: Feedback on draft-ohba-6tsch-security-00

[Rafa Marin Lopez <[e-mail]>]

Hi Rene: 

Thanks for these thoughts. I think they are important to promote valuable discussion. Please see my comments inline.

El 08/07/2013, a las 18:01, Rene Struik escribió:

> Perhaps, also good to send to the mailing list (although somewhat esoteric for general discussion).
> 
> Best regards, Rene
> 
> 
> -------- Original Message --------
> Subject:	(offline note) Re: [6tsch] Feedback on draft-ohba-6tsch-security-00
> Date:	Fri, 05 Jul 2013 14:30:09 -0400
> From:	Rene Struik <[e-mail]>
> To:	Rafa Marin Lopez <[e-mail]>
> CC:	Subir Das, Ph.D. <[e-mail]>, Yoshihiro Ohba <[e-mail]>, Pascal Thubert (pthubert) <[e-mail]>
> Hi Rafa:
> 
> Indeed, my comments in the previous email related to my original feedback.
> 
> Here is my staccato assessment of HIP-DEX: it does not provide native support for certificate-based public-key key agreement, does not provide for perfect forward secrecy (which means that if a device gets compromised, then one might expose data backwards), white listing breaks down if the public key is changed (since tied to identity), the puzzle element does not really protect against DoS attacks (due to asymmetry in terms of resources between constrained node and powerful attacker), and key computations have to be computed serially, rather than in parallel. Moreover, according to the Q2SWinet 2011 paper you referenced, HIP DEX aims to offer hop-by-hope protection, which raises the question as to whether this can be used for end-to-end secure channel set-up (e.g., at application layer) as well. 

It is true that it may not be perfect, but we have to take into account the restrictions we have in term of resources. So a tradeoff between security and deployability would be nice. In fact, the reference I provided concludes "it is worth to consider bootstrapping security association using HIP DEX for WSNs in the future" (It does not mean that others may think different though)

Having said that, it is also true that HIP-DEX is considered as hop-by-hop protection. In fact, in the draft, it is considered a phase 2 KMP (not as a phase 3 KMP). For end-to-end, the paper suggests SSL/TLS as you pointed out.

What seems clear is that, in the end, we may need a protocol for establishing hop-by-hop security (phase 2 KMP). So, we can of course discuss the advantages and disadvantages of using one option or other (or even designing a new protocol if existing choices are broken or not suitable for our environment and, of course, they do not imply to re-inventing the wheel)


> 
> Ideally, one would have a "Swiss army knife" scheme that does it all (at least on the crypto front, where one implements a scheme once and for all on a device and where the only difference in invocations would be packet formatting and parsing).

To understand you better, do you suggest to use the same crypto suite for all KMPs though protocols may be different? 

I also extract from your words you would rather see a single protocol for hop-by-hop and end-to-end.

> This could conceivably help in keeping RAM/ROM figures in check...

Clearly promoting the re-use of components in all KMPs can reduce RAM/ROM requirements.

> 
> Perhaps, this explains me raising the question as to whether what could be used also should be used.  (If I may misinterpret some details, please let me know: it is very hard to distill design objectives from IETF docs and presentations on HIP in the past have not given me too clear a picture). 

In general, I understand your point. Moreover, there have been discussion also about the possibility of having profiles that define different security requirements and, in consequence (that is my understanding), protocols to be used.

Best regards.

> 
> Best regards, Rene
> 
> [excerpt S2SWinet 2011 paper]
> 
> HIP DEX aims to offer hopby-hop protection in multihop WSNs, while SSL/TLS attempts to provide end-to-end security at the edge of WSNs between the base station and sensor nodes. Therefore, they fit different WSN architectures
> 
> On 7/5/2013 1:39 PM, Rafa Marin Lopez wrote:
>> Hi Rene:
>> 
>> El 05/07/2013, a las 18:51, Rene Struik escribió:
>> 
>>> Hi Rafa:
>>> 
>>> Thanks for your note. Some brief feedback below.
>> 
>> Mine are also below
>> 
>>> 
>>> Buen fin de semana.
>> 
>> Gracias!
>> 
>>> 
>>> Rene
>>> 
>>> On 7/5/2013 12:15 PM, Rafa Marin Lopez wrote:
>>>> 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.
>>> 
>>> 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:
>>>> 
>>>> "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.
>> 
>>> 
>>> 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.).
>> 
>> 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.
>> 
>> 
>>> <<RS
>>> 
>>> 
>>>> 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?
>>>>> 
>>>>> 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:
>>>>>> 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: [phone] for the San Jose/Milpitas area and [phone] 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:[phone]x206802913
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 6tsch mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>> 
>>>>> 
>>>>> -- 
>>>>> email: [e-mail] | Skype: rstruik
>>>>> cell: [phone] | US: [phone]
>>>>> _______________________________________________
>>>>> 6tsch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>> 
>>>> -------------------------------------------------------
>>>> Rafael Marin Lopez, PhD
>>>> Dept. Information and Communications Engineering (DIIC)
>>>> Faculty of Computer Science-University of Murcia
>>>> 30100 Murcia - Spain
>>>> Telf: [phone] Fax: [phone] e-mail: [e-mail]
>>>> -------------------------------------------------------
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> email: [e-mail] | Skype: rstruik
>>> cell: [phone] | US: [phone]
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>> 
>> -------------------------------------------------------
>> Rafael Marin Lopez, PhD
>> Dept. Information and Communications Engineering (DIIC)
>> Faculty of Computer Science-University of Murcia
>> 30100 Murcia - Spain
>> Telf: [phone] Fax: [phone] e-mail: [e-mail]
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
> 
> 
> -- 
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
> 
> 
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch

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