septembre 2010 jin-meng ho, texas instruments. doc.: ieee 802. 15-10-0676-00-0006 slide 1submission...

Septembre 2010

Jin-Meng Ho, Texas Instruments.

doc.: IEEE 802. 15-10-0676-00-0006

Slide 1Submission

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: Proposed Resolutions to Security Related CommentsDate Submitted: September 6, 2010

Source: Jin-Meng Ho

Texas Instruments, 12500 TI Blvd, Dallas, TX, USA

214-480-1994

[email protected]

Re: LB#55 comment resolution

Abstract: This presentation provides and explains proposed resolutions to most security related LB#55 comments on subclauses 3-8 of IEEE P802.15.6/D01. Some of the resolutions were already made at the July IEEE session but are recaptured here for clarity. Some proposed resolutions are only outlined in this presentation due to the broad extent of the required changes; the full changes are found and tracked in the corresponding subclauses of a separately submitted document, doc. IEEE 802.15-10-0678-00-0006.

Purpose: To facilitate resolution of LB#55 comments

Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P802.15

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 2Submission

S6-492, S8-6, S8-39, S8-46, 484

• Subclause 6.2.1.1.3, 1, Line 9, Editorial.

• Comment: In general, it is not clear which frame types and frame transactions need to be, or can be, secure. This needs to be defined for each frame type. Is there any security for ACK and Poll type frames?

• Proposed change: Add a table that defines Security options and requirements for different frame types.

• Resolution: Accepted in principle: (1) Accept the resolution proposed by Jin-Meng and sent to the TG6 reflector. Jin-Meng will provide the text and table (with typos corrected) to Daniel. (2) In line 19, page 27, change "either" to "if it is not secured, but still has a MAC frame body containing the Security Sequence Number and MIC fields if it is secured".

• Note: The resolution was made by the MAC-Security subgroup at the July IEEE session, and has been incorporated in subclauses 6.2.2.2 and 8.3 of doc. IEEE 802.15.10-0678-00-0006.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 3Submission

S6-56

• Subclause 6.3.2, 1, Line 15, Technical.

• Comment: The length of the Security Association Date field in Figure 17 is marked greater than or equal to 0, however in Figure 19 page 19 the field is fixed with a size of 72.

• Proposed change: Correct inconsistency by changing greater than or equal to 0 to 72.

• Resolution: Rejected. Figure 17 is correct showing greater than or equal to zero as general case.

• Note: The resolution was made by the MAC-Security subgroup at the July IEEE session.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 4Submission

S6-17, S6-185, S6-230

• Subclause 6.3.2.3, Page 32, Lines 1-9, Editorial.

• Comment: Simplify naming.

• Proposed change: (1) Delete "Required" from the "Security Level Required" field in Figure 18. (2) In lines 7-8, delete "Required". (3) In Table 6's heading, change "required" to "Level".

• Resolution: Accepted.

• Note: The resolution was made by the MAC-Security subgroup at the July IEEE session, and has been incorporated in doc. IEEE 802.15.10-0678-00-0006.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 5Submission

S6-113

• Subclause 6.3.2.3.1, Page 32, Line 5, Technical.

• Comment: "being run" is ambiguous.

• Proposed change: Change "being run" to "type“.

• Resolution: Accepted in principle. Edit lines 4 and 5 to read "... to Table 5 to indicate the security association protocol."

• Note: This comment was editorial. The resolution was made by the MAC-Security subgroup at the July IEEE session, and has been incorporated in doc. IEEE 802.15.10-0678-00-0006.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 6Submission

S6-397


• Comment: This Security Level Required field is a repeat of what is in MAC Header, so can it be removed from frame payload? It would only be needed in both places if a security association was allowed in the connected state to change an existing level with the current level carrried in the MAC Header and new level in frame payload?

• Proposed change: Remove this field from the Security Association Payload or update state machine to allow update of Security Association.

• Resolution: Rejected. Field is needed. This field in the MAC header reflects the security level for the frame itself. The field in question here is used to select a security level for both devices.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 7Submission

S6-447

• Subclause 6.3.2.3.2, Page 32, Table 6, Technical.

• Comment: Clause 6.3.2.3.2, p. 32, Table 6: The security level options seem too limited. Moreover, this would benefit from making this dependent on frame type/subtype in question, so as to allow more flexibility (this is also done in 802.15.4-2006).

• Proposed change: Implement accordingly.

• Resolution: Rejected. Security levels options are sufficient. Dependency upon frame type/subtype has been specified in response to previous comment S6-492.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 8Submission

S6-19, S6-187, S6-232, S6-57

• Subclause 6.3.2.3.4, Page 32, Line 15, Editorial.

• Comment: "Protocol" is not part of the field anymore. (Header is not consistent with name in Figure 18.)

• Proposed change: Delete "Protocol" from the heading.

• Resolution: Editorial.

• Note: The proposed change has been incorporated in doc. IEEE 802.15.10-0678-00-0006.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 9Submission

S6-454


• Comment: Don’t we need to say something about this field? That the node needs to use the cipher function indicated in this field in the frame received from the hub?

• Proposed change: If we agree this is an application problem, then that is fine.

• Resolution: Rejected. This is addressed in clause 6.1, page 19, lines 24-26.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 10Submission

S6-262

• Subclause 6.3.2.3.4, Page 32, Lines 16-17, Technical.

• Comment: Clause 8 does not specify the Camellia-128 forward cipher function (as illustrated in Table 7).

• Proposed change: Add descriptive text for the Camellia-128 forward cipher function in clause 8 or delete as an option from Table 7.

• Resolution: Rejected. Reference to Camellia-128 can be found on page 3. Robert Moskowitz offered to provide additional descriptive text.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 11Submission

S6-371

• Subclause 6.3.2.3.4, Page 33, Line 1, General.

• Comment: Most important requirements for BAN are low-cost and low-power/energy, so efficient cryptographic algorithms in terms of these criteria should be considered. In ISO/IEC JTC 1/SC27, ISO/IEC 29192 (lightweight cryptography) is developed, and it is suitable in particular for constrained environments (i.e. low cost, low energy consumption). The scope of ISO/IEC 29192 includes health-care systems (e.g. Body Area Networks) and sensor networks. ISO/IEC 29192 should be considered in doc. IEEE802.15.6.

• Proposed change: As in comment.

• Resolution: Rejected. Presentation has not been made to TG6 showing applicability of ISO/IEC 29192 to BAN.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 12Submission

S6-448

• Subclause 6.3.2.3.4, Page 33, Table 7, Technical.

• Comment: No clue where Camilia comes from. While this was a 2nd round AES Candidate block cipher, everyone else in the world who specified something post 2001 uses AES-128 (a.k.a. Rijndael). There do not seem to be any advantages in introducing this somewhat arbitrary other cipher and lots of disadvantages: lack of compatibility, higher implementation cost, control traffic cost, key management cost.

• Proposed change: Remove Camilia from the list and make everything except AES-128 a reserved value.

• Resolution: Rejected. Group has agreed to include Camellia-128 as an optional cipher algorithm. Robert Moskowitz offered to provide additional descriptive text.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 13Submission

S6-449

• Subclause 6.3.2.3.5, Page 33, Figure 19, Technical.

• Comment: The protocol messages should also include a protocol identifier (e.g., to logically group different protocol flows corresponding to a single protocol invocation).

• Proposed change: implement accordingly (1-octet field seems sufficient).

• Resolution: Rejected. This distinction is already present via the Security Suite Selector and Security Association Protocol fields within the same frame. Refer to Figures 17 and 18.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 14Submission

S6-114


• Comment: "PkY" case.

• Proposed change: Change to "PKx".

• Resolution: Rejected. The proposed change includes a typographical error, citing "x" rather than "y". See S6-379.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 15Submission

S6-379


• Comment: Sub-clause title font.

• Proposed change: Change "PKY" to PKY with subscript y.

• Resolution: Accepted. Make a similar change to line 3 on page 34 and change "x" a subscript.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 16Submission

S6-58


• Comment: Use subscript for the Y.

• Proposed change: Beacon Shifting Sequence.

• Resolution: Rejected. The proposed change includes a typographical error, citing irrelevant "beacon shifting sequence". See S6-379.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 17Submission

S6-487

• Subclause 6.2, Page 20, Figure 8, Technical.

• Comment: When authenticity is provided, there is no added value in having an FCS field as well.

• Proposed change: Elide the FCS field if data authenticity is already provided.

• Proposed resolution: Rejected. (1) Not having an FCS field would cause false security alarms – pure channel errors would be interpreted as security violations. (2) The proposed change would require a device to validate the MIC before returning an I-Ack or B-Ack frame, thus entailing a much more stringent timing requirement on MAC processing. No popular wireless LAN/PAN standards – such as 802.11 and 802.15.4 – have followed the proposed change. (3) The proposed change would involve fundamental changes to the PHYs as well, which always assume there is a 2-octet FCS following the MAC frame body.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 18Submission

S6-442• Subclause 6.2.2, Page 26, Figure 12, Technical.

• Comment: The MIC subfield should not be visible, since the CCM construct is a “black box” construct”, where one does not have to have any insight on where the data authenticity bits show up in the frame. Besides, with CCM, the MIC is actually a truncated CBC-MAC code that is subsequently encrypted using a stream cipher. Since I am sure hardly anyone who implements the specification does understand the sentence above, I would strongly suggest keeping the internal workings of the cryptographic mode of operation (here: CCM mode, but could be something else) abstract and non-visible to people interested in frame layouts.

• Proposed change: Remove MIC subfield and add language that Frame Payload may be secured, depending on setting of security level indicator.

• Proposed resolution: Rejected. (1) “I am sure hardly anyone who implements the specification does understand the sentence above” – Quite a few people do understand it. (2) This field needs to be visible to “people interested in frame layouts”, since it helps them in knowing upfront the overhead added by security and hence in their MAC architecture design, transmission time calculation, etc., even and especially if they are not the ones implementing the “internal workings of the cryptographic mode of operation”. (3) If it ain’t broke, don’t fix it.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 19Submission

S6-443

• Subclause 6.2.2.1, Page 26, Line 25 Technical.

• Comment: The requirement that the frame counter (Security Sequence Counter) is incremented by one is too strict and unobservable by other nodes.

• Proposed change: Replace this by “incremented (by at least one)”.

• Proposed resolution: Rejected. Incrementing by at least one would use up the security sequence numbers faster causing faster PTK renewals – and at the same time. Nodes with low duty traffic would be required to renew their PTKs much more frequently as a result of other nodes having frequent frame transfers. See also S6-444.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 20Submission

S6-444• Subclause 6.2.2.1, Page 26, Line 26, Technical.

• Comment: This suggests that one needs to store a frame counter for every key, which seems wasteful: a sender only needs to store one frame counter for outgoing traffic and just increments this along the way, independent of frame type and keying material in question.

• Proposed change: Each device should only use one frame counter (Security Sequence Counter) for outgoing frames. Similarly, a recipient only needs to store one frame counter per device it receives frames from (so as to implement replay protection).

• Proposed resolution: Rejected. (1) A node communicates with a hub only, and hence needs to maintain only one security sequence counter according to the current draft. (2) Should a hub maintain only one security sequence counter for all outgoing traffic, it would use up the security sequence numbers faster, thereby causing more frequent PTK renewals at all the nodes and at the same time, even at those nodes with low duty traffic. Having to renew the PTKs with all the associated nodes within the BAN before the hub may reuse the security sequence counter is not a trivial task.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 21Submission

S6-445

• Subclause 6.2.2.1, Page 27, Line 27, Technical.

• Comment: This suggests that the SSN frame counter is incremented even in case of resends. If so, this thwarts the security service of replay protection (since now, a device can send the same frame twice, but with different SSN numbers).

• Proposed change: Resends should use the same frame counter.

• Proposed resolution: Rejected. (1) The comment is incorrect. The commenter is referred to 8.3.2 for the functional specification of replay protection. (2) The proposed change is technically flawed. It would lead to security breaks in block transmissions with block acknowledgment policy and in other scenarios such as the following one, where a sender may send a frame (A), send some other frames of a different frame type or subtype, and then re-send the earlier frame (A), all to the same recipient. (3) The working of the MAC protocol needs to be considered in specifying MAC sublayer security, as is the case here.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 22Submission

S6-396

• Subclause 6.3.2, Page 31, Technical.

• Comment: What happens if one end refuses a security association – is it to send a disassociation? PTK missing/invalid is shown in the state machine on P 24, but no message is defined to carry this status and there is no field to carry it in a security disassociation frame either?

• Proposed change: Clarify failure procedure for security disassociation and possibly add status/error code to security disassociation.

• Proposed resolution: Accepted in principle. (1) The commenter was a bit confused among different security frames, but the comment is a valid one and applies to both Security Association and PTK frames and their corresponding procedures. (2) Create and define a Status field in those frames in 6.3.2 and 6.3.4, and revise the definitions for some other fields of these frames to support the different statuses now defined. (3) Revise 8.1 and 8.2 to clarify the functional behaviors corresponding to different statuses. (4) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 23Submission

S6-446• Subclause 6.3.2.3.1, Page 32, Table 5, Technical.

• Comment: This suggests that the particular protocols for a fixed field value are fixed (and as defined in Clause 8, with only 80-bit crypto strength). What about algorithm agility here? Why is there no public-key based authenticated key agreement scheme with certificates? What about a proper symmetric-key based authenticated key agreement scheme?

• Proposed change: Allow much more flexibility in terms of schemes supported (algorithm agility!).

• Resolution: Deferred.

• Note: The resolution was deferred by the MAC-Security subgroup at the July IEEE session.

• Proposed resolution: Rejected. (1) There are reserved values for the Security Association Protocol field to accommodate additional protocols in the future. (2) No one proposed to TG6 any public-key based authenticated key agreement scheme with certificates during the proposal submission stage. (3) These are protocols for activating a pre-shared master key or generating a new master key (without assuming the knowledge of an existing symmetric key). For the former, a “a proper symmetric-key based authenticated key agreement scheme” is indeed provided (see PTK creation related subclauses).

.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 24Submission

S6-450• Subclause 6.3.3.1, Page 36, Technical.

• Comment: The extended addresses seem to be EUI-48 addresses. This seems to be too short, given the potential number of devices in body area networks. Why not use an EUI-64, so as to be sure to have globally unique device identifiers? This would allow not running out of space and would also allow device certificates based on this address issued by a CA.

• Proposed change: Use EUI-64 addresses, rather than 48-bit entries.

• Proposed resolution: Rejected. (1) Considering that this is a low data rate BAN, changing from 6 to 8 bytes would add non-negligible overheads to some frame transmissions. (2) The EUI-48 space is not expected to run out by 2100. (3) Certificates are not limited to only EUI-64 based devices – it contradicts with the reality that there are far more EUI-48 based devices than EUI-64 based ones that use certificates.

• Note: (1) “EUI-48” is now used instead of “IEEE MAC address” per IEEE, so replace all instances of “IEEE MAC address” with “EUI-48” throughout the draft. (2) The transmit order of EUI-48 is most-significant byte first, so change “0-5” to “5-0” above the “Sender Address” or “Recipient Address” field of all MAC frames containing such a field throughout clause 6. (3) To highlight this “unconventional” transmit order, add the following as a new paragraph under line 15, page 19: “In a field containing an EUI-48, the three octets specifying the organizationally unique identifier (OUI) contain the most-significant bits of the field, and the other three octets specifying the organization’s selected extension identifier contain the most-significant bits of the field.” (4) See Clause 6 in doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 25Submission

S6-59


• Comment: Wrong level of indent.

• Proposed change: Change level of indent to same as the other four fields from figure 20.

• Resolution: Accepted. Editorial.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 26Submission

S6-367


• Comment: Would the interval be more precisely stated as [0, 2^128). That is, a semi closed interval.

• Proposed change: Change to [0, 2^128). Same on page 37 line 29.

• Resolution: Deferred. The zero value could lead to a degenerate result and is intentionally excluded. Open interval is correct as written.


• Proposed resolution: Rejected. (1) As noted by the MAC-Security subgroup at the July IEEE session, the zero value could lead to a degenerate result and was intentionally excluded. (2) The zero value is now used for the case of aborting the current security procedure, as a result of S6-396. (3) This subclause, and hence the line under comment, is removed as a result of S6-451.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 27Submission

S6-451• Subclause 6.3.3.2.1, Page 36, Technical.

• Comment: Randomness of the sender nonce does not provide any freshness/liveness/timeliness assurances to the recipient (since not a proper challenge response protocol).

• Proposed change: Make this a proper challenge response protocol. I would be happy to help with this.

• Resolution: Deferred. References on page 3, line 19-20 and 29 provide standards and guidance on such number generations.


• Proposed resolution: Accepted in principle: (1) Remove the Sender Nonce field from the Security Disassociation frame in Figure 20 and from the calculation of the DA_KMAC in subclause 8.1.6 and Figure 95. No freshness is needed here. Rather, only possession of the master key needs to be confirmed – through DA_KMAC. (2) Delete subclause 6.3.3.2.1. (3) Delete the last sentence on page 119. (4) Revise subclause 8.1.6 and Figure 95 accordingly. (5) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 28Submission

S6-59


• Comment: Wrong level of indent.

• Proposed change: Change level of indent to same as the other four fields from figure 20.

• Resolution: Accepted. Editorial.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 29Submission

S6-61

• Subclause 6.3.4.4, Page 37, Line 18, Technical.

• Comment: Is this index a single bit or multiple bits? Line 18 indicates that one can subtract 1 for the value, while line 22 indicates that it has a value of zero or one only.

• Proposed change: Fix inconsistency.

• Resolution: Accepted in principle. Change text on line 18-19 to "…is set to the modulo-2 sum of one plus its value used…". Editorial.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 30Submission

S6-280, S6-62• Subclause 6.3.4.4, Page 37, Line 22, Technical.

• Comment: PTK Index field is defined as a one octet field but takes only values of 0 or 1. This is an inefficient use of frame payload format for PTK frames.

• Proposed change: Message Number field is also defined as a one octet field but takes values of only 0 to 3. As such, it could be represented as a 4 bit field. Change both PTK Index and Message Number fields to be 4 bits long and share a single octet.

• Resolution: Deferred. Need change in Figure 21 and text to separate the reserved bits. Refer to lines 22-24.


• Proposed resolution: Accepted in principle. (1) Replace the Message Number and PTK Index fields with a PTK Control field, which comprises a 2-bit Message Number field, a 1-bit PTK Index field, a 1-bit Reserved field, and a 4-bit PTK Creation Status field, the latter being a result of S6-396. (2) A similar change needs to be made to the GTK frame. (3) Revise subclauses 6.3.4, 6.3.5, and 8.2 accordingly. (4) This proposed resolution supersedes that for S6-61. (5) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 31Submission

S6-452• Subclause 6.3.5, Page 38, Figure 22, Technical.

• Comment: The structure of the group temporal key is unclear. Is this supposed to specify the structure of keying material? If so, where are the policy fields, such as key validity period, key usage, etc? Moreover, how does the MAC even know about these (generally) higher-layer concepts? Shouldn’t the sender address be the address of the key originator instead? What about SSN: shouldn’t this be a key serial number instead (cf., e.g., corresponding notions for public keys with X509 as specified with RFC 5280)?

• Proposed change: Please clarify intent, since this is highly unclear now.

• Proposed resolution: Rejected. (1) The structure and concept of the group temporal key transport are nothing new, but merely follow the model of IEEE 802.11i and other wireless networking standards such as those for UWB and Wireless USB. They are for the distribution of a group temporal key chosen by the originator, an age old model. (2) The commenter asked about a few things which were not part of the key structure and which he questioned if the MAC could even know. (3) The sender address is indeed the address of the key originator. (4) The SSN is for replay protection, as described in 8.3.2.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 32Submission

S6-467

• Subclause 6.3.7.3, Page 43, Table 8, Technical.

• Comment: To use the value 6 in status code field: to indicate to unconnected node in the unsecure communication the following status “rejected hub operating in secure mode” in Connection Assignment frame.

• Proposed change: To use the reserved value 6 of table 8 to indicate the status: “rejected hub operating in secure mode”.

• Proposed resolution: Alternative solution: (1) Add the following statement to the end of the first paragraph (created as a result of S6-492): A node or a hub shall ignore received frames secured or unsecured unexpectedly, except for returning an acknowledgment if required by the acknowledgment policy and for taking an appropriate defensive measure against potential security violations. (2) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 33Submission

S6-408

• Subclause 6.6.1.0, Page 55, Technical.

• Comment: Should there be Capability fields related to Security, e.g based on encodings for security level and cipher function?

• Proposed change: As per comment on revising MAC Capability to define commands in an IE.

• Proposed resolution: Rejected. (1) Both security capability and security requirement fields were defined in the MedWiN proposal 0327-01, but the security capability field was subsequently removed in the merger process. (2) A node or a hub is expected to have very few optional security capabilities, so security requirements (in terms of the security suite selector) are supposed to be more to the point and handle the security negotiations efficiently enough. (3) See also the proposed resolution to S8-63.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 34Submission

S8-52

• Clause 8, Page 119, Line 2, Editorial.

• Comment: Move period before Figure 5 to after.

• Proposed change: Move period before Figure 5 to after.

• Proposed resolution: Accepted. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 35Submission

S8-49, S8-53, S8-56, S8-62

• Clause 8, Page 119, Line 12, Editorial.

• Comment: Missing introduction to 8.4.

• Proposed change: After line 12 add a new paragraph: Support for mandatory and optional cipher functions is clarified in 8.4.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 36Submission

S8-51, S8-55, S8-58

• Clause 8, Page 119, Editorial.

• Comment: This comment applies to all the equations in Clause 8. All these math equations need to be in italic font.

• Proposed change: Technical Editor, please make all the equations (but not the equation numbers) throughout Clause 8 in italic font.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 37Submission

S8-59• Subclause 8.1, Page 119, Line 13, Technical.

• Comment: Susceptibility of key distribution/association schemes defined in clause 8.1.

• Proposed change: The key distribution/association schemes are aligned (or closely similar to) with Bluetooth. Unfortunately, there have been a lot of papers on shortcomings of even the latest Bluetooth (v2.1 security). Recommend the proposers of security mechanisms in 802.15.6 draft a whitepaper outlining the attacks on Bluetooth and why their proposal is not susceptible.

• Proposed resolution: Accepted in principle, with no action to take for the revision of the TG6 draft. (1) Whitepaper – not part of this draft but nice to have as a separate tutorial document. (2) Bluetooth uses an elliptic curve public key size of 160 bits, equivalent to 80 bits of security strength for symmetric key cryptography. The elliptic curve key size for this draft is changed to 256 bits, equivalent in security strength to AES under 128-bit keys, subject to the approval for the proposed resolution to S8-83. (3) To our knowledge, the latest Bluetooth (v2.1) security has (fundamental) technical flaws in its passkey entry (i.e., password based) association model, which we also discovered independently while initially considering the new Bluetooth security models as potential security candidates for TG6. Those flaws resulted from the exposure or revealing of one bit of the passkey during each round of message exchanges between the two parties at the first authentication stage. The whole passkey can thus be determined by an eavesdropper recording all the (20) rounds of authentication message exchanges. The password based association protocol in the TG6 draft is a zero-knowledge password authentication protocol, where "zero knowledge" means that the password authentication messages do not leak to a third party any information that can be used to guess the password by any means other than brute force exhaustive search (which is unavoidable with any security protocol). Thus, the TG6 password protocol is not susceptible to the password attacks on the Bluetooth passkey model.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 38Submission

S8-50, S8-54, S8-57

• Subclause 8.1, Page 119, Line 17, Editorial.

• Comment: Missing comma.

• Proposed change: Insert a comma after the closing parenthesis.

• Proposed resolution: Accepted. Also change “where” to “with” on the same line. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 39Submission

S8-61

• Subclause 8.1, Page 119, Line 19, Editorial.

• Comment: FIPS Pub 186-2 is not mentioned in the reference list.

• Proposed change: Cross-reference to FIPS Pub 186-3 instead.


Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 40Submission

S8-60• Subclause 8.1, Page 119, Technical.

• Comment: For constrained platforms, prime curves are much less efficient than binary curves, esp. in hardware-assisted implementations. This is the more so, since binary field arithmetic can be implemented using shift registers, for which support is already required to implement the error detecting code CRC-16 and the channel hopping (via the use of LFSR).

• Proposed change: Pick a corresponding binary curve instead, preferably from the list of NIST approved curves (Koblitz curves are most efficient here, cf., e.g., specification with ZigBee and ISA SP100.11a). I would be happy to help here.

• Proposed resolution: Rejected. (1) "Prime curves" may be less efficient than "binary curves" if the chosen prime does not have a special form. If the chosen prime is a quasi Mercenne number as is the case here, the statement is no longer true, as fast algorithms are available for performing modulo reductions with respect to such a prime. (2) "Binary curves" involve polynomial arithmetic, whereas "prime curves" operate on numbers directly. It is grossly oversimplified to state that binary field arithmetic can be implemented using shift registers. (3) CRC-16 and channel hopping each takes only 16 registers, but the number of registers needed for implementing ECC is more than ten times more. The connections of these registers are also completely different. Support of the former means little for the latter.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 41Submission

S8-84• Subclause 8.1, Page 119, Line 21, Editorial.

• Comment: The prime p used with the P-192 curve specified is more conveniently specified as p=2192-264-1.

• Proposed change: include this more convenient specification of the prime field size underlying the curve in question.

• Proposed resolution: Accepted in principle: (1) Add the special form to the equation without replacing the current decimal form which is what is represented in the cited reference. (2) Both forms have different values now as a result of S8-83. (3) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 42Submission


• Comment: The elliptic curve domain parameter a is ambiguously defined, since defined as a representative of an equivalence class, rather than as integer.

• Proposed change: Define this integer uniquely as a = p-3.

• Proposed resolution: Accepted. Also make p italic. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 43Submission

S8-86• Subclause 8.1, Page 119, Line 29, Editorial.

• Comment: Replace the phrase “two communicating parties” by “two communicating parties (A and B)”.

• Proposed change: Implement as suggested.

• Proposed resolution: Accepted in principle. In line 29, after "a node" insert "(party A)", and after "a hub" insert "(party B)".. Also make p italic. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 44Submission


• Comment: The notion of “fresh” 128-bit random integer can only be realized if one stores all previously generated random integers, a clear impracticality. Hence, one has the weaker notion of randomness, where one can statistically expect no collisions between properly generated random numbers from a huge set.

• Proposed change: Remove the word “fresh” here, since this leads to unlimited storage requirements.

• Proposed resolution: Rejected. (1) The word "fresh" does not mean "unique" as suggested in the comment. It is synonymous to "new", but is the word used in the security literature in the context of this comment. (2) It is essential to keep this word here; otherwise the fundamental requirement on freshness in key generation would not be met.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 45Submission

S8-83• Subclause 8.1, Page 119, Technical.

• Comment: The elliptic curve specified is the so-called P-192 NIST curve and is also used with Bluetooth. These curve parameters are too small, in light of NIST recommended key sizes, cf., e.g., NIST SP800-56 and SP800-57, since these only offer 80-bit cryptographic key strength (which is to be phased out by 2010). Considering the longevity of key protection lifetime to be expected with healthcare applications, one should design for cryptographic key strength well beyond 2030 and use 128-bit crypto strength as design goal. This requires use of one of the NIST curves B-283, P-256, or K-283. Considering implementation cost, the binary Koblitz curve would be the preferred choice here.

• Proposed change: Pick a curve with 128-bit crypto strength, preferably from the list of NIST approved curves. I would be happy to help here.

• Proposed resolution: Accepted in principle. (1) Replace P-192 with P-256 and change the domain parameters accordingly in subclause 8.1. (2) Modify Figure 19 accordingly to reflect the changed key lengths. (3) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 46Submission

S8-88• Subclause 8.1, Page 120, Lines 4-6, Technical.

• Comment: It is unclear why there would be a need to specify the CMAC mode of operation, since one a keyed hash function arises by invoking the combined encryption and authentication mode of operation CCM in a particular way. Having more than one construct only drives up implementation cost and adds to key management cost, without any security benefit.

• Proposed change: Just use the CCM mode of operation instead and invoke in particular way so as to realize a keyed hash function. I would be happy to help here.

• Proposed resolution: Rejected. The comment is incorrect. (1) The CMAC “mode” is essentially the “authentication mode” (i.e., CBC mode) of CCM, with additional security tightening. Both are based on the CBC mode and the same underlying cipher function (AES), but CCM requires a 13-octet nonce construct and hence does not reduce implementation complexity compared to CMAC. (2) WiMedia MAC and WUSB Specifications took the suggested approach at the time when CMAC was not specified by NIST yet, but that approach is not simpler than using CMAC. (3) What matters most is the reuse of the underlying AES forward cipher function.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 47Submission


• Comment: It is not a priori clear that truncation of the output of a keyed hash function (in casu: the CMAC authentication code) does not have undesirable security implications (i.e., what is impact on security bounds in attack models?).

• Proposed change: Only use keyed hash functions with output size “tweaks” that were explicitly considered during the cryptographic design hereof. Since CMAC does not seem to be designed with this consideration in mind, this mode should be abandoned (otherwise, please provide solid evidence).

• Proposed resolution: Rejected. The comment is incorrect. (1) As noted in the proposed resolution to S8-88, the CMAC “mode” is essentially the “authentication mode” (i.e., CBC mode) of CCM which the commenter recommended in that comment, with additional security tightening. Both are based on the CBC mode. (2) FIPS Pub 186-2 or 186-3 does specify the CMAC with truncated output size “tweaks” as keyed message authentication codes of variable length.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 48Submission

S8-63• Subclause 8.1.1, Page 120, Lines 20-23, Technical.

• Comment: (Also with all public-key based schemes in Clause 8.1 described further on). The specification suggests that if both parties have different security suite recommendations, then the initiating device should abort operation and try again, potentially with reconciled security suite. This seems to be unnecessarily restrictive, since (a) this necessitates generation of a new random number by either party (esp. computationally intensive if public-key based schemes are used and a new ephemeral key needs to be generated); (b) this could be prevented if one would communicate a set of acceptable security suites instead (and just proceed with one in the intersection, if not the empty set).

• Proposed change: Use set of security suites instead and clearly specify conditions under which ephemeral keys may be reused without impact on security properties of the scheme. I would be happy to help here.

• Proposed resolution: Accepted in principle: (1) In subclause 6.3.2 add explicit provisions to lift the hub (party B) from the burden of generating a random number, a private and public key pair, and a DH key in the case of aborting the association procedure. Revise 8.1 accordingly. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes. (2) It is not expected that BAN nodes are to frequently roam away from home hubs to foreign hubs and have to frequently associate with hubs without knowing the security capabilities and requirements of the other side. It will be practically rare that a node needs to abort an association procedure and start a new one because its selected security suite as defined in the current draft is not supported by the other side (hub). Thus, it is not worth creating an exception that the node does not generate a fresh random number after aborting an association procedure. (3) A node does not, and actually cannot, compute a DH key in an aborted procedure according to the current draft. Hence, no DH key is computed by either the node or the hub, and it is moot to specify conditions for its reuse. (4) See also the proposed resolution to S6-408.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 49Submission

S8-64• Subclause 8.1.1, Page 120, Technical.

• Comment: It is unclear what the cryptographic assurances are that are provided by the described protocol. As an example, where is the entity authentication step (C/R protocol) that I would have expected).

• Proposed change: Replace this scheme by a proper symmetric-key authenticated key agreement scheme (offering entity authentication and explicit key authentication and avoiding unilateral key control). I would be happy to help here.

• Proposed resolution: Rejected. (1) This simple two-way handshake protocol is to support an important case where both parties already have a pre-shared master key. (2) Symmetric key based authentication is then performed during the PTK creation procedure that follows, as is specified elsewhere in the current draft.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 50Submission

S8-65• Subclause 8.1.2, Page 121, Lines 2-4, Technical.

• Comment: This scheme seems to come down to a variant of the so-called ephemeral Diffie-Hellman scheme. However, it seems to discard that cryptographic protocols may provide some security assurances, but can never yield a verdict on the question as to whether one really wishes to admit the other device to the network (except when encoded in attributes of certificates in pre-arranged fashion). Thus, the claim that no human interaction is required results in each pair of devices that executes this protocol to indeed establish a secure (non-authenticated) channel. This could lead to serious Denial of Service attacks on the system and lots of non-desired links, with associated impact on storage cost, computational burden, etc...

• Proposed change: This protocol should be accompanied by an authorization step, during which a verdict is reached on whether one indeed wishes to have a secure channel with the other communicating party

• Proposed resolution: Rejected. (1) This is the well-known unauthenticated Diffie-Hellman key agreement protocol. The opening paragraph specifically notes that this protocol runs "without the benefit of keeping third parties from launching impersonation attacks". (2) Denial of service attacks may be mounted even on authenticated association protocols, and hence are not an issue unique to this protocol. (3) That "no human interaction is required" is true for the execution of the protocol. This protocol, or any other association protocol, could be selected only after the human has already authorized its use.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 51Submission


• Comment: The protocol lacks some safeguards that are essential for the security of the protocol, viz.: (a) checking that the ephemeral point received from the other party is indeed a non-trivial point on the P-192 curve specified; (b) checking that the resulting key DHKey is not the point of infinity.

• Proposed change: Clearly and unambiguously specify the checks that need to be performed here, including the two referred to above.

• Proposed resolution: Accepted in principle: (1) The current draft (page 119, lines 33-35) states the safeguard (a) for all the DH key agreement protocols specified in this draft. However, it is worth emphasizing this in the functional specification of each protocol. Hence, revise subclause 8.1 and its subclauses accordingly. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes. (2) Step (b) is not needed because step (a) along with the private key selection statement in lines 28-30, page 119, guarantees that the resulting DHKey is not the point of infinity for the chosen elliptic curve (which has a cofactor h = 1).

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 52Submission


• Comment: The computed key DHKey is not random (since roughly half of the 192-bit key strings are not a point on the curve P-192). For this reason, all schemes I am aware of apply a key derivation function to this computed elliptic curve point and use the output hereof as keying material for subsequent processes.

• Proposed change: Use proper key derivation function to derive keying material, as outlined above.

• Proposed resolution: Rejected. (1) “Half” means one bit less (than the DHKey bit length – 192 for curve P-192 and 256 for curve P-256). Besides, to determine and exploit that “half” entails checking the quadratic residuosity modulo p of essentially every 256-bit integer, which is even harder than directly guessing a 128-bit master key by brute force. Thus, DHKey is practically random. (2) The DTCP (Digital Transmission Content Protection) standard, which has been around for over a decade, does extract a key by simply truncating the derived DHKey, without applying a key derivation function. (3) A key derivation function is needed if the entropy of DHKey (i.e., the number of possible DH keys) is significantly less than the bit length of DHKey. This is not the case here but is for many multiplicative groups of integers modulo p, wherein the order of the generator may be only 160 but the bit length of p may be 1024. In the latter case, if a 1024-bit DHKey is simply truncated to a 128-bit key, then the entropy (“randomness”) of the truncated key is about only 160*128/1024 = 20 bits, so many less than the ideal 128 bits. That is, a third party could guess the truncated key from a total of 2^20, but not close to 2^128, 128-bit candidate bit strings. On the other hand, a key derivation function can “compress” a 1024-bit DHKey with an entropy of 160 to a 128-bit key with a maximum 128-bit entropy, since the function “randomly” transforms the 2^160 possible DHKey input bit strings to all possible 128-bit output bit strings.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 53Submission


• Comment: The protocol in Clause 8.1.1 introduced an index so as to distinguish different protocol flows in the key agreement scheme, but this seems to be missing in Clause 8.1.2 ff (cf. P_2, P_3, etc.), without clear justification.

• Proposed change: Introduce proper protocol flow labels, so as to ensure that reflection attacks, etc., cannot occur.

• Proposed resolution: Rejected. Each association protocol may be initiated only by a node, but not by a hub, and has the full addresses of both parties bonded to authentication, thereby thwarting reflection attacks.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 54Submission


• Comment: (Also with other protocols) The CMAC message authentication code requires as input a random key that “fits” with the underlying block-cipher. Since AES-128 has 128-bit keys, the key DHKey is drawn from a much larger set (and not random either), this does not fit the mechanics (nor the requirements) of the CMAC construct, as defined in NIST SP800-38B. This could be remedied by introducing the derivation function, as also suggested to be used in another comment.

• Proposed change: Fix this. I would be happy to help here.

• Proposed resolution: Accepted in principle: (1) Extract the keys for the CMAC functions by truncating the DHKey to 128 bits. No key derivation function needs to be applied for this key extraction as explained in the proposed resolution to “another comment”, S8-68. (2) Correct the notation errors for a CMAC function (truncation is already built in the NIST specification of the CMAC, hence no need for applying a separate truncation function LMB_n or RMB_n). (3) See 8.1 and its subclauses of doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 55Submission

S8-70• Subclause 8.1.2, Page 121, Line 31, Technical.

• Comment: It is unclear whether truncation of the keyed hash function outputs P_2 and P_3 does not have undesirable security side effects.

• Proposed change: Provide convincing rationale here.

• Proposed resolution: Rejected. These are keyed message authentication codes, which are typically truncated outputs of keyed hash functions. See FIPS Pub 186-2 or 186-3 for additional explanations.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 56Submission


• Comment: The identifiers of the communicating parties are not included with the DHKey computation, but only included with the keyed hash function computations. It is not a priori clear whether this precludes certain subtle attacks here, as have been known for other public-key key agreement schemes that initially did not include this information (e.g., unknown key-share attack, etc.).

• Proposed change: Please provide convincing rationale here.

• Proposed resolution: Rejected. (1) By definition, the DHKey is equal to the multiplication of one party’s own private key and the other’s public key. This is true in most security specs. (2) What did not initially include the information of the identifiers of the two parties as alluded to in the comment was the computation of the message authentication codes (and the digital signatures of the public keys which are not employed here). This is not the case here: The identifies (full addresses) are indeed bonded to the message authentication codes, thereby preventing unknown key-share attacks, reflection attacks, etc.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 57Submission

S8-72• Subclause 8.1.2, Page 123, Figure. 92 Technical.

• Comment: The protocol flows indicated suggest that the second protocol flow includes both the ephemeral key contribution by the responder and the keyed hash function (so as to provide key confirmation). This protocol flow arrangements forces serialized key computations, rather than parallel ones if either element would be communicated separately, thus potentially causing a computational performance degradation of a factor 2x. This seems to be extremely wasteful for constrained networks, with limited computational resources and still reasonable expectations of time latency.

• Proposed change: Split the second protocol flow, so as to allow either side to do key computations in parallel. I would be happy to help here.

• Proposed resolution: Accepted in principle. (1) Split the second Security Association frame into two frames – the second and third Security Association frames, respectively. The new third frame is exactly the same as the current second one, and the new second frame is the same as the current one except that the MK_KMAC field is set to 0. Renumber the current third Security Association frame as the fourth one. (2) Apply these changes to all security association protocols except the master key pre-shared association one. (3) Revise subclauses 6.3.2 and 8.1.2 – 8.1.5 accordingly. (4) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 58Submission


• Comment: It is entirely unclear how the “out of band” transfer of public keys is supposed to happen.

• Proposed change: Please explain carefully how this works and elaborate on why one cannot use other hidden association schemes.

• Proposed resolution: Rejected. (1) The description of “out of band” transfer of the node’s public key is an implementation issue and hence is out of scope of this spec, just as the description of how a master key is pre-shared between a node and a hub. (2) The spec does not preclude use of “other hidden association schemes”, whatever they might be. It merely specifies a public key hidden association scheme.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 59Submission


• Comment: It is entirely unclear what the benefit of introducing the scalar M_X+1 is (in half the cases the value is 1; in a quarter of the cases 2, etc.).

• Proposed change: Remove this scalar (and replace by the constant value ‘1’).

• Proposed resolution: Rejected. (1) It would not be prudent to remove something the commenter asks to remove but whose benefit the commenter says is entirely unclear (to him?). (2) A password integer PW and an adjacent integer, such as PW+1, could map to the same point Q(PW), and hence without the scalar MX+1 would result in the same PK'A and PKA. Consequently, a third party (an adversary) could rule out two or more guesses (instead of only one) at each impersonated run of the protocol with a legitimate party. While this might not be practically significant, it should nevertheless be prevented. SRP-6 has replaced SRP-3 for a similar reason.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 60Submission

S8-75• Subclause 8.1.4, Page 126, Lines 10-11.

• Comment: Most password-based schemes I am aware of (e.g., SPEKE, EKE) hash the password prior to mapping this to an elliptic curve point. With the scheme presented here, this is not the case, however, which makes one wonder about evidence regarding security provided. Moreover, the probabilistic trial-and-error method of mapping a string to a point has been improved upon and replaced by a deterministic one.

• Proposed change: Provide evidence that this protocol is secure.

• Proposed resolution: Rejected. (1) Neither SPEKE (especially in the commonly known full constrained form) nor EKE (such as the one first proposed by Bellovin and Merritt) hashes the password in a password authenticated key exchange. (2) Password hashing is used in such cases where the password is mapped to a generator (G for elliptic curves). (3) In the case here, the elliptic curve point Q(PW) mapped from the password is at party A added to, and hence masked by, the secret public key PKA which is randomly any point on the elliptic curve (due to the random nature of the private key SKA). Thus, the statistical distribution of PKA (see Eq. 28) is computationally indistinguishable regardless of whether Q(PW) is mapped directly from a password or indirectly from a password hash, just as that of y = x + c is if x is a uniform random variable regardless of whether c is a constant or any random variable. Similarly, the statistical distribution of MK_KMAC (see Eqs 30-34) computed from the DHKey which is the password descrambled public key PKA multiplied, and hence, masked, by B’s private key SKB is computationally indistinguishable regardless of whether Q(PW) is mapped directly from a password or indirectly from a password hash. Note that only PK'A and MK_KMAC parameters that depend on the password are exposed and could be used to search for the password. Also recall that a hash applied to a relatively short password would not add any entropy. In summary, this protocol is as secure as if the password were hashed to produce an elliptic curve point.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 61Submission


• Comment: The size of the display message (16-bit) seems to be too small, since it seems to afford a birthday-paradox style attack that requires a workload of roughly only a factor 256x more than that of the communicating BAN-nodes (thus, taking a second on a computing device).

• Proposed change: Please explain why this protocol is secure.

• Proposed resolution: Rejected. The comment is flawed. (1) A birthday attack could happen only if an adversary were free to choose two numbers displayed at parties A and B. This is not the case here. Regardless of how many other nodes might be around, as far as the association between A and B is concerned, display verification is made of the number displayed at party A and the number displayed at party B. (2) By design, an adversary cannot choose the two displayed numbers through intercepting and injecting messages during the protocol run. In fact, an adversary cannot even fix one displayed number by design.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 62Submission


• Comment: There is no need to include the y-coordinate of the elliptic curve point, since it can only assume two values.

• Proposed change: Remove y-coordinate from equation.

• Proposed resolution: Accepted in principle: To align with other association protocols which each have four messages exchanged between the two parties as a result of S8-72, this protocol now no longer uses the Witness nor hides the sender nonce in the first message. Instead, the displayed number is computed at the end from an output of a CMAC function with nonce B as the key and nonce A and DHKey as the argument. It is computationally infeasible to choose nonce B for the CMAC key or B’s private key for the “right” DHKey such that the output of the CMAC function matches a given value, hence the removal of Witness.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 63Submission


• Comment: It is unclear what function the nonce value Nonce_A has, since it does not provide timeliness/liveness assurances to any other party.

• Proposed change: Replace by proper unilateral entity authentication (C/R) protocol.

• Proposed resolution: See S6-451.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 64Submission

S8-79• Subclause 8.3.1.1, Page 135, Figure 98, Technical.

• Comment: The nonce construction may yield re-use of nonces, due to use of short addresses (which may cycle), rather than globally unique ids. Besides, the MAC header is 7 octets and not 6 octets, so that formats do not “fit”.

• Proposed change: Please fix this, e.g., by adopting CCM* mode of operation of 802.15.4-2006, 802.11i, or NIST SP800-38C, Appendix A.

• Proposed resolution: Rejected. (1) Reuse of nonces will not occur with the same PTK or GTK per the current draft. (2) Reuse of nonces with different PTKs or GTKs is not an issue. (3) This format follows that adopted in some existing wireless networking standards (such as those for UWB and Wireless USB).

• Note: The length of the MAC Header was corrected prior to, but not reflected in, this draft. It needs to be corrected, along with the length of the first field (2 octets only).

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 65Submission

S8-80• Subclause 8.3.1.2 – 8.3.1.5, PP. 135-139, Technical.

• Comment: The CCM mode of operation description could just copy the specification with 802.15.4-2006 and save lots of pages and add clarity. That specification has been used with ZigBee, ISA SP100.11a, and IETF RoLL as well. Besides, it would untangle transmit order/bit/octet order discussions and would add more flexibility as to length of authenticity tag options supported.


• Proposed resolution: Rejected. (1) The frame format and hence the formats for the nonce and the authentication and encryption blocks are all different. Hence a quick copy and paste would not work. (2) It would reduce the flexibility of a TG’s spec to fix its message security operation on another TG’s spec. (3) The 802.15.4-2006 CCM specification essentially copies RFC 3610; so it would probably be a questionable precedent to copy a spec which in turn copies another one. (4) The CCM operation was specified in IEEE 802.11i and implemented for WPA II before the appearance of 802.15.4-2006, but the latter did not copy the former. (5) Unlike 802.15.4, this draft has a fixed length for the authentication tag, just as IEEE 802.11i does, to preclude user’s confusion.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 66Submission


• Comment: Replay protection relies on checking whether the received counter value (SSN) is at least equal to the “lexicographically first” (i.e., smallest) value stored on the recipient device. The current draft seems to adopt counter increments that were originally with 802.15.4-2003 and that led to lots of confusion and incorrect implementations. Suggestion is to adopt the much cleaner version as codified with 802.15.4-2006, Clause 7.5.8.2.1 and Clause 7.5.8.2.3. This would include initializing this value at zero (rather than 1, as is done in Clause 6.2.2.1 of Draft D1) and explicitly stipulating that the value 0xffffffff represents the value infinity.


• Proposed resolution: Rejected. (1) IEEE 802.15.4-2006 seems to adopt counter increments as well. (2) The replay protection model here follows that adopted by IEEE 802.11i, which has been widely used.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 67Submission


• Comment: There seems to be merit in flagging replayed frames, so as to allow some remedial action by a subsequent process, so silently discarding these seems to preclude useful I/O.

• Proposed change: Report a failed status code for any incoming frame that does fail security processing.

• Proposed resolution: Accepted in principle. (1) Add to the end of the line the following statement: Appropriate precautions should be taken against excessive detected replays. (2) See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 68Submission


• Comment: It is hard to see any practical justification of offering more than one cipher suite (except for built-in algorithm agility), since this does not serve any security purpose, drives up implementation cost, and hampers interoperability. Besides, it requires control traffic so as to indicate which cipher suites devices support. Bad idea!

• Proposed change: Define one crypto primitive for every purpose, unless there is a clear reason not to do so. Just allow some reserved bit(s) for algorithm agility.

• Proposed resolution: Accepted in principle, with no action to take for the revision of the TG6 draft. (1) AES-128 forward cipher function is the only mandatory crypto primitive per the current draft. As noted for S6-448, TG6 has agreed to include Camellia-128 as an optional cipher algorithm. (2) Reserved bits are indeed available for future algorithm extension.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 69Submission

S8-1, S8-2, S8-3, S8-4, S8-5, S8-7, S8-8, S8-9, S8-10, S8-11, S8-12, S8-13, S8-14, S8-15, S8-16, S8-17, S8-18, S8-19, S8-20, S8-21, S8-22, S8-23, S8-24, S8-25, S8-26, S8-27, S8-28, S8-29, S8-30, S8-31, S8-32, S8-33, S8-34, S8-35, S8-36, S8-37, S8-38, S8-40, S8-41, S8-42, S8-43, S8-44, S8-45, S8-47, S8-48,

• All minor editorial comments on Clause 8.

• Proposed resolution: All accepted in principle. See doc. IEEE 802.15.10-0678-00-0006 for full, tracked changes.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 70Submission

S14-43• Clause 4, Pages 10-12, Technical.

• Comment: There is a plethora of acronyms related to security, including AES, AES-128 CCM, CCM, CBC, CMAC, GTK, KCK, KMAC, MIC, MK, PTK, TK. There seems to be room for some clean-up of acronyms here, as well as better clarification (elsewhere) or the relationship between acronyms with this alphabet soup, since now this is utterly confusing. This remark also applies to error detection code-related acronyms, including FCS, CRC, etc.

• Proposed change: Define concise set of acronyms that covers required functionality. No need to refer to AES-128 CCM, CBC, CMAC (cf. comments), one of KMAC or MIC, and some of the key types, my thinks.

• Proposed resolution: Rejected. (1) The comment does not identify which acronym is not needed. (2) IEEE 802.11 has more security acronyms. (3) FCS and CRC are traditionally used in IEEE 802.11 and 802.15 standards.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 71Submission


• Comment: It is suggested that key management functionality could be MAC functionality. This is a clear layer violation, since management functionality is higher-layer end-to-end functionality. Besides, if this would “live” at the MAC, then one would have to specify the structure of keying material, including key value, key originator, key validity period, and other attributes the MAC may not even know about. With 802.15.3 standard, Paul Nikolic ruled all this key management functionality out of scope of WPAN efforts (in March 2003).

• Proposed change: Remove all key management functionality (except for key usage) from the specification.

• Proposed resolution: Rejected. (1) What is suggested is key generation, not key management. No key management functionality is specified in this draft. (2) Key generation is extensively specified in IEEE 802.11, through IEEE 802.11i and 802.11s.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 72Submission

S14-37• Subclause 5.5, Page 15, Figure 4, Technical.

• Comment: The state diagrams seem to be inconsistent, since the unsecured state diagram does not arise easily from the secured one.

• Proposed change: Define state diagram consistently, so that unsecured state transitions are just more lax than secured state transitions, but certainly not inconsistent herewith.

• Proposed resolution: Rejected. It is already the case that unsecured state transitions are more lax than secured state transitions – the former does not go through the two middle states which the latter has to go through.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 73Submission

S14-37• Subclause 5.5.1.1, Page 16, Technical.

• Comment: The order of association and authentication seems to be off: one would expect a device to first associate (and thereby getting a temporary lease of life to communicate and consume resources) and, depending on whether security is required, engage in additional security protocols (e.g., to authenticate itself, to set up a secure and authentic channel to be used for key distribution or for secure data transfer). Now, it seems that a device can only get to an associated state with master keys from orphan state. Why not associate, followed by limited allowance for unsecured traffic if frames in question are related to some higher-layer key agreement scheme??

• Proposed change: Redefine security model, so that specific frames can only be communicated if cryptographic keying material there and security processing on frames used.

• Proposed resolution: Rejected. (1) There is not a separate authentication state. Entity authentication, if required, is part of security association. (2) All traffic is indeed unsecured until the Secured state is reached, as explicitly stated in 5.5.1.1, 5.5.1.2, and 5.5.1.3.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 74Submission

S14-40• Subclause 5.5.1.2, Page 16, Line 18, Technical.

• Comment: It is unclear whether “repealing” a security association is tied to aliveness/timeliness guarantees. If not, the disassociation can be replayed at a later moment in time (or delayed, if recipient device temporarily offline/asleep, etc.)

• Proposed change: Please provide timeliness/aliveness with this disassociation command.

• Proposed resolution: Rejected. (1) Replay is not an issue here, since once a node is disassociated, a replay of an earlier Security Association frame would be simply ignored – the node and the hub are already disassociated from each other. (2) If the node and the hub reassociate and hence establish a new master key, a replay of an earlier Security Association frame based on a repealed key would fail the security check with the new master key. (3) In summary, aliveness/timeliness is provided by possession of the valid master key.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 75Submission


• Comment: It is unclear why encryption and authentication could not be provided for control frames, nor why the actual combination of security services provided should not be allowed to depend on the frame type/subtype in question (and potentially configured, depending on application scenario at hand). Now, lots of security services seem to be cast in stone, irrespective of potentially widely varying application scenarios.

• Proposed change: Allow more flexibility as to particular combination of security services offered (e.g., what about more than 32-bit authenticity tags?) and as to flexibility as function of frame type in question. This could easily be accommodated by indexing the particular combination of security services in the frame itself (or storing as side information on recipient device).

• Proposed resolution: Rejected. (1) Authentication is provided for control type frames – as is stated by lines 31-32 (a node and a hub jointly select … whether to require authentication for control frames. Encryption of control type frames is not needed, since some of them do not have a frame payload and hence would not be encrypted anyway. (2) The widely used IEEE 802.11i approach of having a fixed length authentication tag is followed in this draft. (3) Control type frames do have a choice of being secured or not, so security service is already a function of frame type/subtype.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 76Submission

S14-42• Subclause 5.6, Line 39, Technical.

• Comment: The notion of “session” during which a temporal key is valid is poorly explained. This seems to require a relative notion of time between communicating devices and, with keys, in general a more absolute notion of time.

• Proposed change: Please explain carefully. See also previous comment on timeliness and notion of time.

• Proposed resolution: Rejected. (1) The explanation is technically valid. (2) The suggested remedy does not offer an improved or specific explanation.

Septembre 2010


doc.: IEEE 802. 15-10-0676-00-0006

Slide 77Submission


• Comment: This suggests only a relative notion of time, thereby not facilitating security services, such as delay protection. The latter could be useful if one relays information at a later time in the network, with devices that were not around or asleep earlier on, just processing this, even if the frames in question may have “aged”. This could also be relevant in terms of keying material, which is now claimed to be valid during a “session” (Clause 5.6, p. 17, l. 39), which seems to require a notion of time.

• Proposed change: Consider a more absolute notion of time, so as to facilitate detection of stale frames and stale data in tables.

• Proposed resolution: Rejected. (1) The time reference alluded to in the comment is for medium access. (2) No absolute notion of time is identified to be needed for the security services specified in this draft.

septembre 2010 jin-meng ho, texas instruments. doc.: ieee 802. 15-10-0676-00-0006 slide 1submission...

Documents