[6lowpan] (what is the problem statement) Re: IEEE 802.15.9 KMP over 802.15.4 and 802.15.7 approved

[Rene Struik <[e-mail]>]

Hi Robert:

Point of clarification:

ZigBee SE1.x and ISA SP100.11a implement an end-to-end key agreement
scheme (based on public keys and certificates) at a stack layer above
the MAC. This key agreement scheme consists of four message flows
between two parties A and B, where each party communicates a key
contribution and a key confirmation message, and where each message flow
fits within the maximum 802.15.4-2006 MAC frame size (of 127 octets), so
that no fragmentation occurs.

Question is what the problem is you are trying to solve that cannot be
addressed by a higher layer protocol and what the benefits are compared
to, e.g., the approach above. A table with features and benefits and
comparison along different dimensions would surely help.

Please note here that ZigBee SE1.x, ISA SP100.11a have been out there
for quite a while. A similar remark holds for wHART (IEC 62951), an
industrial control standard.

It would have great merit to the group to clarify the problem statement,
what is new, and what alleged benefits are, before diving into minutiae
of time-outs and in/out communication reach topics (which apply to most
management traffic, not just key management traffic, and - in fact - to
most traffic [after all, shouldn't traffic elicit a state change?]).

Best regards, Rene

On 15/11/2011 1:19 AM, Robert Moskowitz wrote:
> 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
>
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan


-- 
email: [e-mail]
Skype: rstruik
cell: [phone]
USA Google voice: [phone]