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

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Nov 2011 15:00:09 -0500

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.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 14 Nov 2011 08:17:44 +0200

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.

Thanks.

Alper

On Nov 11, 2011, at 10:00 PM, Robert Moskowitz wrote:

> We did agree to two procedural changes in the PAR, so there will be a rev 6 posted sometime soon.
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Nov 2011 00:46:52 +0800

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.

> > _______________________________________________ 6lowpan mailing
> > list [email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Mon, 14 Nov 2011 17:30:13 +0000

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
<[email-masked]>wrote:

> **
> 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.
>

-- 

Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 14 Nov 2011 11:32:43 -0800

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!

-B

Bob,

"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 <[email-masked]>
wrote:

On 11/14/2011 03:17 PM, Alper Yegin
wrote:

> 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.

>> The IEEE 802ec approved the PAR this
afternoon. The PAR

documents

>> are at:

>> We did agree to two procedural changes in
the PAR, so

there will be

>> a rev 6 posted sometime soon.

6lowpan

mailing

6lowpan mailing list

[email-masked]

--

Robert Cragie

Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Nov 2011 14:19:05 +0800

On 11/15/2011 03:32 AM, Benjamin A. Rolfe wrote:
> 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.
>
> for some (like me) it can be a mystifying topic.  I am looking to TG9 
> to help.
>
> 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.
>
> 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.

>> "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
>>
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     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
>>
>>
>>
>>     >
>>
>>
>>
>>     >
>>
>>
>>
>>     >> list [email-masked] <mailto:[email-masked]>
>>
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>> http://www.gridmerge.com <http://www.gridmerge.com/>
>>
>>
>>

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

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

---

From: Rene Struik <[email-masked]>
Date: Tue, 15 Nov 2011 08:47:57 -0500

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:
>> 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)
> 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,
>>>
>>> keys". Users of 802.15.4 such as ZigBee have put in place a KMP
>>> which does not result in weak keys,
>>>
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363