Re: [6lowpan] IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved

[Robert Moskowitz <[e-mail]>]

On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote:
> Excellent points that will make the PAR stronger.
>
> Many on this list have been through the IEEE 802 project process, but 
> for those that may not have it might help to explain the purpose of 
> the PAR, which is to ask IEEE-SA to authorize a new project, in this 
> case a recommended practice. The scope clause defines the direction of 
> the project and can be thought of as the 'normative' part of the PAR.  
> The other clauses provide the New Standards committee (NesCom) 
> background, and not in any way limitations.
>
> I see positive potential for the project. As Robert points out there 
> are many security methods applied over and with 802.15 standards and 
> for some (like me) it can be a mystifying topic.  I am looking to TG9 
> to help.
>
> As currently drafted the scope is not limited to the particular 
> protocols mentioned as examples. The 802.15 operating procedures allow 
> a very open process and input is welcome from all that choose to 
> participate. If/when it is approved the first steps will be to define, 
> within the scope of the project, what specific protocols are relevant 
> to the RP.  I commend Bob for reaching out at this early stage to 
> solicit input on the project, and encourage continued participation.   
> The experience of those that have used 802.15.4 and other standards in 
> the 802.15 family will be of great value.
>
> So as a potential user of the RP (who isn't qualified to contribute 
> much beyond desire ;-), thanks all for the help on the PAR and I look 
> forward to continued contributions!

Oh, you are going to contribute, but as a MAC expert.  I THINK I have 
the Frame Control bits figured out and the use of the Payload IE over 
the Header IE, but not only does this need to be worked out but consider 
a controller that is receiving a string of datagrams with Forced ACKs 
for sensor 1 when sensor 2 starts sending a chain.  Does the controller 
NAK sensor 2 until it finishes with sensor 1?  Should KMP processing be 
single-threaded?  What about timeouts if the sensor moves out of range 
during the KMP exchange then moves back within range.  Well within the 
KMP this SHOULD be handled but the chaining?  Both sides SHOULD flush 
out partial transmit/receive sequences on the same timing.  And this is 
only 15.4, I need some senior guidance in cracking 15.7.

There are other points for discussion as well.  All this is JUST to open 
up 802.15 to workable security solutions independent of the higher layer 
selection.

>
> -B
>
>
>> Bob,
>>
>> I have to say I object to the following statement in the PAR:
>>
>> "Lack of key management support in IEEE Std 802.15.4 and IEEE Std 
>> 802.15.7 results in weak keys which is a common avenue for attacking 
>> the security system."
>>
>> "results in weak keys" implies this is always the case, which is 
>> simply not true. This should be rephrased as "may result in weak 
>> keys". Users of 802.15.4 such as ZigBee have put in place a KMP which 
>> does not result in weak keys,
>>
>> And I agree with Alper - if you are mentioning IETF and 802.1X, you 
>> really have to mention PANA as it is entirely relevant.
>>
>> Robert
>>
>> On Mon, Nov 14, 2011 at 4:46 PM, Robert Moskowitz 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     On 11/14/2011 03:17 PM, Alper Yegin wrote:
>>     >
>>
>>
>>
>>     > Hi Bob,
>>
>>
>>
>>     >
>>
>>
>>
>>     > This PAR document still does not refer to
>>     IETF's PANA (IETF
>>
>>     RFC that
>>
>>
>>
>>     > is already adopted by the Zigbee IP spec.) I'm
>>     hoping the PAR
>>
>>     changes
>>
>>
>>
>>     > you are referring are already addressing that.
>>     Please let us
>>
>>     know.
>>
>>     It was a procedural question as to what is 'wanted' here. 
>>     Strictly IEEE standards or broader interpretation?  The 802EC
>>     clearified that a broader inclusion was desired so words have
>>     been added to point out that Zibgee IP has addressed this within
>>     their upper layer.  A 'literal' interpretation was that 802.1X
>>     does not work over 802.15.4 or 15.7 so there was no comparable
>>     standard.
>>
>>     Also 802.1 pointed out the need to include the potential need of
>>     an Registry Authority (6.1b) and that too was added.  The final
>>     posted PAR will reflect these two changes.
>>
>>
>>     >
>>
>>
>>
>>     > Thanks.
>>
>>
>>
>>     >
>>
>>
>>
>>     > Alper
>>
>>
>>
>>     >
>>
>>
>>
>>     >
>>
>>
>>
>>     > On Nov 11, 2011, at 10:00 PM, Robert Moskowitz
>>     wrote:
>>
>>
>>
>>     >
>>
>>
>>
>>     >> The IEEE 802ec approved the PAR this
>>     afternoon. The PAR
>>
>>     documents
>>
>>
>>
>>     >> are at:
>>
>>
>>
>>     >>
>>
>>
>>
>>     >>
>>
>>     https://mentor.ieee.org/802.15/dcn/11/15-11-0613-05-0kmp-key-management-protocol-par.doc
>>
>>
>>
>>     >>
>>
>>
>>
>>     >>
>>     https://mentor.ieee.org/802.15/dcn/11/15-11-0665-05-0kmp-kmp-5c-draft.doc
>>     >>
>>
>>
>>
>>     >> We did agree to two procedural changes in
>>     the PAR, so
>>
>>     there will be
>>
>>
>>
>>     >> a rev 6 posted sometime soon.
>>
>>
>>
>>     >>
>>
>>
>>
>>     >>
>>
>>
>>
>>     >>
>>     _______________________________________________
>>     6lowpan
>>
>>     mailing
>>
>>
>>
>>     >> list [e-mail] <mailto:[e-mail]>
>>
>>
>>
>>
>>     >> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>>
>>
>>     >
>>
>>
>>
>>     >
>>
>>
>>     _______________________________________________
>>     6lowpan mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/6lowpan
>>
>>
>>
>>
>> -- 
>>
>> Robert Cragie
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> [phone]
>> [phone]
>> http://www.gridmerge.com <http://www.gridmerge.com/>
>>
>>
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>

-- 
Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit