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
<[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/6lowpan
>
>
_______________________________________________
6lowpan mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lowpan
--
Robert Cragie
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>
_______________________________________________
6lowpan mailing list
[email protected]
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:[email protected]
There's no limit to what can be accomplished if it doesn't matter who
gets the credit
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
