# Main

Comment:
SDL not included. SDL should be informative instead of normative.

SuggestedRemedy:
Add high level SDL for all mandatory portions for the specification.

Response:
The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
This annex is marked as NORMATIVE, yet nothing is present.  Any change to this section will be a significant technical change and require a new letter ballot not a recirculation.  If there are large holes like this in a draft, then it should not be even motioned to working group letter ballot. I have provided three suggested remedies.

SuggestedRemedy:
1) Remove the annex, but since the annex is normative. Note: this is a significant change removing somthing that is normative.  2) Changing the annex, from normative to informative.  Note: this does not solve the problem as it is still empty.  Even if SDLs are proposed as part of someone else's comments, I will consider these significant enough to warrant a new ballot. 3) Add the missing SDLs.  Note: this is a substantial technical change and will require a new ballot.

Response:
PROPOSED ACCEPT IN PRINCIPLE.   The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
SDL is not defined and is not normative.

SuggestedRemedy:
Change normative to informative and get some SDL to put in here.  Or just delete the entire clause.

Response:
PROPOSED ACCEPT. The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
Without SDL there is an higehr risk of non-interoperable implementations

SuggestedRemedy:
Provide formal description of the MAC and PHY. SDL can be one option.

Response:
PROPOSED REJECT. The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
There are no SDL's.  This is not a valid letter ballot with normative sections missing from the draft.

SuggestedRemedy:
The SDLs should not be considered normative and should be completely removed from the document.


Response:
PROPOSED ACCEPT IN PRINCIPLE.  The committee does not want to add normative content that may conflict with the other clauses. Informative content will not be available until at least 3 months after the final draft has been approved. 
SDL clause will be removed from the draft and left for a follow on project.


Comment:
PICS not defined. PICS section should be informative since it repeats items defined in earlier clauses and only servers to determine what portions of the specification to which paticular implementation conforms.

SuggestedRemedy:
Add PICS based on final content of the specification.

Response:
PROPOSED ACCEPT. PICS content will be added as an informative clause as derived from the normative portion of the draft.


Comment:
This annex is marked as NORMATIVE, yet nothing is present.  Any change to this section will be a significant technical change and require a new letter ballot not a recirculation.  If there are large holes like this in a draft, then it should not be even motioned to working group letter ballot. I have provided two suggested remedies. A PICS is not to contain any requirements that cannot be found in the descriptive text.  It has been my experience that this is not the case.  TG1's draft 802.15.1 is the best example of where a PICS makes requirements that are not part of the descriptive text.  The PICS in this case has become a product implementation time line, which marks items as optional, if the feature is not to be supported as a first released product.  A standard is never to be written as phases of a product roll out.  Requirements must be set and options well marked.  This is what a PICS contains.  If this is true that a PICS contains only what is fully stated in the text, then why could the PICS not have been part of the balloted text at this time?  Could it be that the requirements and options are not yet finalize in the text?  If this is the case then why was this draft motioned to working group letter ballot?

SuggestedRemedy:
1) Remove the annex, but since the annex is normative. Note: this is a significant change removing somthing that is normative.  2) Add the missing PICS.  Note: this is a substantial technical change and will require a new ballot.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  PICS content will be added as an informative clause as derived from the normative portion of the draft.


Comment:
The PICS are derived from the text and so are informative rather than normative.

SuggestedRemedy:
Change the annex designation from normative to informative and add the PICS tables.


Comment:
Without PICS there is an higehr risk of non-interoperable implementations

SuggestedRemedy:
Provide PICS for implementation description of the MAC and PHY.


Comment:
There are no PICs.  This is not a valid letter ballot with normative sections missing from the draft.


Comment:
"Papoulis" should be "Athanasios Papoulis"


Comment:
"Stallings" should be "William Stallings"


SuggestedRemedy:
fill in proper number for "ZZZ" in lines 5 and 6


SuggestedRemedy:
fill in proper number for "#HMAC" in lines 9 and 10


Comment:
There are no coexistence study so far regarding the coexistence property of a device implementing this specification. It is well known problem that 2.4GHz ISM band is already crowded with WLAN and BT devices. It is important to show that devices implementing this draft can coexist with the incumbent.

SuggestedRemedy:
1. Get TG2 involved in evaluating the coexistence property of the draft. 2. Add sections in the draft to explain what are the tools that can be used to have better coexistence properties. For instance, channel assessment and selection, power control, etc.

Response:
PROPOSED ACCEPT IN PRINCIPLE.  The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. TG2 has been consulted and they will help with analysis.


Comment:
Despite the fact that 802.15.3 is described as a WPAN under the umbrella of the WPAN working group (802.15), there is no mention of interference, interoperability, or coexistence with the only other WPAN standard to go through letter ballot, 802.15.1.  This specification has no mention of how it will maintain QoS in the presence of significant other interference in the same band: Bluetooth, microwave ovens, etc.  Even in the "802.11b coexistence" mode, there is no method described that says how the 802.15.3 system will be placed in this channel plan. While older specifications such as 802.11b could have been developed without recognition of other users of the band, IEEE would do the industry a disservice by publishing specifications whose ability to coexist with other IEEE wireless standards was unknown (at best) or poor (at worst).

SuggestedRemedy:
The specification needs a coexistence section that describes: a) mechanisms for QoS maintenance in the presence of interference (with informative sections that quantify the problem), b) coexistence mechanisms for 802.15.1/Bluetooth, and c) channel selection algorithms that not only address 802.11b coexistence in an automatic way, but also describe avoidance mechanisms for microwave ovens and other types of interference (both periodic and non-periodic).

Response:
PROPOSED ACCEPT IN PRINCIPLE. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. Accept informative text provided by the commenter on QoS issue.


Comment:
The current TG3 draft does not address the issue of coexistence between 802.15.3 devices and other devices in the band such as 802.11b and Bluetooth.

SuggestedRemedy:
1) Add a clause or subclause that describes the interference problem resulting from having 802.15.3 devices co-located with 802.11b, Bluetooth devices. Performance results quantifying the impact of interference can be added as well. 2) Include solutions to remedy the problem.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. In addition the informative Annex will have information regarding performance.


Response:
PROPOSED ACCEPT. Resolved in comments 296.


Response:
PROPOSED ACCEPT IN PRINCIPLE. Clause 9 has been deleted. TBD has been removed.


Response:
PROPOSED ACCEPT.  Backwards compatibility is explained in the draft text to be added to the draft found in 00000r0P802-15-3-Annex_Coexistence.pdf. Interoperability is not mandated, and not prohibited.


Response:
PROPOSED ACCEPT IN PRINCIPLE. Clause has been deleted.Also closes 1744, 1779, 1753, 1788.


Comment:
One distinguishes communication behavior and security associations within a piconet (ordinary devices, security managers, and piconet controller), between different piconets (piconet, child piconet, neighbor piconet), and between devices and the external trusted party. The term 'DEV' could therefore be occasionally used to denote things that are not a device, but, e.g., a neighbor piconet, thus causing confusion. Moreover, devices can have different roles. Adopting a more general term avoids this confusion.

SuggestedRemedy:
Replace the concept 'DEV' by 'entity' or a similarly appropriate term throughout the clause.


Comment:
The list of editorial attributions must be changed to include the following contributors as follows:Gregg Rasor, Security and Privacy Committee ChairAri Singer, Security and Privacy Assistant EditorRene Struik, Security and Privacy Assistant Editor


Comment:
If disassociation request by a particular device would be automatically honored without evidence regarding the authenticity of this request, one can launch a simple denial of service attack on each device in the piconet.

SuggestedRemedy:
The details of the disassociation request initiated by the device itself should be specified.Specify the disassociation request protocol in such a way that honoring this request is subject to positive evidence as to the identity of the originator of that request (data origin authentication).

Response:
PROPOSED REJECT. Until there is a valid and implementable documented proposal, this cannot be considered.


Comment:
Statically identifying the device Id with the IEEE MAC address gives rise to anonymity concerns, since then the device Id identifies the device in a static and traceable way. One distinguishes a number of issues, including (1) Tracking of devices and thereby their users; (2) trace-ability of the manufacturer of the WPAN-chip, which might lead to passively monitoring which devices are owned by whom (e.g., for device theft). (Note: lack of anonymity was a major criticism of the original Bluetooth specification. It led to a change requirement by Ericcson, after this privacy issue had been advertised on the front cover of the NY Times).

SuggestedRemedy:
Do not statically identify the device Id with the IEEE MAC address. Instead, add a separate section on how the device Id should be interpreted.  Add a separate section on how the device Id should be interpreted, thus leaving room for dynamic linkage of the device Id to a (pseudonym) of the IEEE MAC address of the device. As for now, this section would just describe that the device Id equals the IEEE MAC address (so, we have compliance with the current draft and formats). If anonymity concerns give rise to a change requirement, one only needs to change this added section to cater for the anonymity requirement, not all occurrences of the device Id throughout the whole standard (i.e., it is acts as an abstract module). Of course, we should give the proper format and, in particular, the required length of the device Id proper consideration. The current 48-bit device Id might not be enough to provide anonymity guarantees (if these are required).

Response:
PROPOSED REJECT. The changes required at this time will be similar to any changes required when it is necessary to implement this capability.


Comment:
3.	(E) Page 184, line 27: replace 're-initialization' by 're-initialization of the device'.


Comment:
4.	(E) Page 185, line 44: replace 'provided' by 'indeed provided'


Comment:
5.	(E) Page 185, line 52: replace 'life cycle' by 'life time'.


Comment:
6.	(E) Page 185, line 2: replace 'part of hereof' by 'part hereof'.


Comment:
7.	(TR) Page 185, line 6: in front of the sentence 'To facilitate…' insert the following sentence: 'It will accept any commands from an authenticated device.' Comment: the current text does not cover the consequences of a successful authentication.

Response:
PROPOSED ACCEPT IN PRINCIPLE. Page 185, line 6: in front of the sentence 'To facilitate…' insert the following sentence: 'It will accept any commands from an authenticated device.'


Comment:
In Figure 48 (Distribute Key Format), the DistributeKeyTimeout parameter is included. I don't think it should be passed in the frames, just used in the MAC to timeout a pending command that may not come back within the allotted time. I don't see any reason why the other MAC could make any use of this value since it the entity which is producing the result.

SuggestedRemedy:
Remove the timeout parameter from the frame.


Comment:
The characteristics of the 802.15.3 WPAN define the context and the constraints the security framework has to live with. In itself issues like communication bandwidth are not related to security, but do impose restrictions here on (e.g., selected encryption mechanisms must guarantee sufficient throughput).


Comment:
Add that the nodes operate on close distance from one another.


Comment:
The PNC has local address 0, neighbor piconets and child piconets have local addresses 0xFA-0xFC, and one has reserved addresses for broadcast (0xFF), temporary during association (0xFE), and for multicast (0xFD). Thus, the range of local addresses assigned to entities in a piconet setting is 0x00-0xFC, which adds up to 253 (254, if one includes the temporary local address).


Comment:
The current wording does not cover the admission of devices to a piconet and the handling of child and neighbor piconets.

SuggestedRemedy:
Replace 'This standard describes only the communication behavior between DEVs in the piconet' by 'This standard describes only the communication behavior between WPAN-enabled devices and -entities'.


Comment:
One might need a different identifying string than the IEEE MAC address, in the event that anonymity of devices is required as an additional security objective.


Comment:
The current wording does not cover, e.g., neighbor and child piconets.


SuggestedRemedy:
Replace ' between DEVs in the piconet' by 'between WPAN-enabled devices and -entities'.


Comment:
The current wording is not stated as a time-invariant property and does not cover the admission of child and neighbor piconets. Moreover, it conflicts with the intended operation described in Sub-clause 10.3.4.2.1 (Page 185, lines 11-13), since there unauthenticated devices are only denied time-slots and not denied association per se. Last, but not least, the security requirement should not specify which device (here, the PNC) should regulate the admission policy; this should rather depend on the role(s) associated with the devices (as elaborated upon in Sub-clause 10.3.2).

SuggestedRemedy:
Change Item 1 to the following: 'Joining of authenticated entities only. At any given moment of time, effective admission of an entity to the piconet (authenticated association) must be based upon evidence regarding its true identity and proof that the device itself corroborated this evidence. Here, effective admission refers to allocation of time slots to an associated device, and distribution of keying material hereto.'


Comment:
Currently, no mentioning is made to the peer-to-peer scenario, thus conflicting Sub-clause 10.1.1, Page 177, lines 25-26 (which specifies both peer-to-peer and broadcast communications); this should be corrected.

SuggestedRemedy:
Item 2 should make more precise what is meant by a 'group' of piconet devices. As a minimum, this should include peer-to-peer (end-to-end) communication, and broadcasting. Ideally, this should include multicasting to any subset of the devices that constitute the piconet.


Comment:
For the security architecture, the mapping between devices and their roles is essential. The security events trigger actions depending upon the role of a device. Without this role model, the security architecture is completely inflexible and security policy cannot be described correctly. Given the importance of this role model, rated this comment as a TR rather than 'Editorial' only.

SuggestedRemedy:
Replace 'security assumptions and' by 'security assumptions, a classification of devices according to role(s) these assume, and'.


Comment:
Add the following (informative) sentence hereafter: 'The actual procedure by which public key pairs are generated has important practical consequences, since it determines to what extent devices can be re-initialized after manufacturing and influences the level of trust required in the external trusted party. A more detailed discussion is beyond the scope of this document.'


Comment:
Add the following sentence 'For details, we refer to Item 3 of 10.1.2.'


Comment:
The wording 'validity' implies a judgement. A mere enumeration is all that is needed here.

SuggestedRemedy:
Replace 'The following roles of DEVs are valid within the piconet setting' by 'One distinguishes the following roles of entities within the piconet setting'.


Comment:
The potential mapping of security functionality to the PNC is addressed in Sub-clause 10.3.2.2, and should not be addressed here; moreover, other mappings are conceivable. Given the importance of separating the role(s) of devices from the actual implementation hereof and avoiding confusion here, this comment is rated TR rather than 'Editorial' only.

SuggestedRemedy:
Delete the complete sentence 'The security manager shall be hosted by the current PNC'.

Response:
ACCEPT IN PRINCIPLE.  Delete the sentence in 10.3.2.1, line 25, and change "assumes" to be "shall assume" in 10.3.2.2, lines 15 and 16 (two places total).


SuggestedRemedy:
Delete the complete sentence 'The PNC hosts … security manager.'

Response:
ACCEPT IN PRINCIPLE.   Delete the sentence in 10.3.2.1, line 25, and change "assumes" to be "shall assume" in 10.3.2.2, lines 15 and 16 (two places total).


Comment:
The question whether this role is present in the piconet or not depends on the mapping of roles to devices and is addressed in Sub-clause 10.3.2.2, and should not be addressed here. Given the importance of separating the role(s) of devices from the actual implementation hereof and avoiding confusion here, this comment is rated TR rather than 'Editorial' only.

SuggestedRemedy:
Change 'If present, this entity ensures' by 'This entity is the sole source that ensures'.


Comment:
Replace 'Since this standard address PANs' by 'Since this standard addresses communications between WPAN-enabled devices and -entities only'.


Comment:
Item 2 of the current paragraph (on PNCs) confuses the role model with the mapping of roles to devices (as addressed in Section 10.3.2.2) and violates the security invariant formulated in the security model (as discussed in Section 10.3.2.2). Given the importance of separating the role(s) of devices from the actual implementation hereof and given the importance of sticking to a carefully defined security policy and avoiding any confusion here, a total rewrite of this paragraph is required.

SuggestedRemedy:
Replace this entire paragraph by a more appropriate text as follows:The role model is motivated as follows:1.	The roles in the security model are formulated in such a way as to allow a distributed implementation. In particular, there might be more than 1 piconet controller, more than 1 security manager, and more than 1 external trusted party. What is important is that these roles may conceptually be thought of as being centralized.2.	The roles in the security model are independent of the way these are actually implemented. In particular, this means that different roles may be implemented in a single device. An example of the latter would be the creation of a single device that assumes both the role of piconet controller and that of security manager.3.	The roles in the security model are separated from the actual devices that assume these roles, thus allowing for a dynamic mapping of roles to devices. An example of the latter would be changes to the piconet controller and to the security manager.4.	The roles in the security model are separated from the actual devices that assume these roles, thus allowing different devices to associate different roles with the same device, depending on their individual view on the role(s) this particular device should play. An example of the latter would be a device that assumes the role of security manager for one device and that of ordinary device for another device.5.	The piconet controller (PNC) need not be fixed in time and space. Since the device that is assigned the role of PNC might vary over time, it is not convenient to a priori assign any security functionality to it (for otherwise, trust might need to be established over and over again, at each change of PNC).6.	The external trusted party is assumed to be the sole source of global trust, since it is a party that is external to the network and might have facilities that are deemed necessary for proper key management (e.g., secure key generation facilities, proper authentic storage of keying material, availability, etc.).


Comment:
Replace 'exclusion' by 'to the exclusion'. Similarly, replace 'An example is' by 'An example hereof is'.


Comment:
The current wording does not cover a device that will assume the (for him new) role of PNC.

SuggestedRemedy:
Replace 'a change of role of the PNC' by 'a role change from PNC to ordinary device, or vice versa'.


Comment:
Without this additional sentence, the effect of composite security events is not defined.

SuggestedRemedy:
Add the following sentence hereafter: 'Simultaneous changes of the group structure and of the role are conceptually thought of as to take place subsequently, e.g., if the current PNC simply vanishes, this can be thought of as to have occurred in the order 'change role to ordinary device'; 'vanish'.'


Comment:
This illuminates that a change of role as PNC to that of ordinary device (rather than the other way around).

SuggestedRemedy:
Replace 'PNC hand over' by 'PNC hand over (sign out)'.


Comment:
Currently, this security relevant event is lacking; this should be corrected.

SuggestedRemedy:
5Add the following item hereafter: '(2) PNC takeover (sign in). This refers to an alternate PNC device assuming the role of piconet controller'.

Response:
ACCEPT IN PRINCIPLE. Add an enumeration item as "2) PNC promotion. This refers to a PNC-capable DEV assuming the role of PNC."


Comment:
Add the following (informative) sentence hereafter: 'Compliance with the key storage rule rests upon 'benign' devices implementing this rule; it cannot be enforced upon devices. This provided yet another reason that the security rule should be strictly adhered to.'


Comment:
In the current draft, a change of PNC unnecessarily triggers a re-authentication procedure. This expensive (!) procedure is not required by the security policy, since the role change does not invoke a change to the key-sharing group, and should therefore be skipped. Granted, I also first thought otherwise. One can explain the phenomenon as follows in a more informal way. If one has a PNC hand over and encryption is on, the only devices that can read encrypted traffic are those that already had been authenticated by the previous PNC (otherwise, they had no way of getting any keying material, except by 'force' (breaking open the supposedly trusted module). Hence, one can safely continue broadcasting messages using these keys, since only those previously already authenticated devices can read traffic. If only authentication is on, then things might get tricky, since it depends on the proper and authentic hand over of the list of authenticated devices from the old PNC to the new one (This is handled in Sub-clause 10.3.4.2.3). To avoid confusion and violation of the security policy, a total rewrite of this paragraph is required.

SuggestedRemedy:
Replace this entire sub-clause by a more appropriate text as follows:'We consider the effect of changes to the roles of devices in the scenario where information shared between members of a group is secured via a common (symmetric) group key.A change of the role of the piconet controller due to a PNC hand over has no effect on the group structure, so it does not impact the group key.'


Comment:
Keying material should be handled at the MAC layer only, unless this is technically unfeasible. Comment: Currently, all cryptographic operations seem to be handled outside the MAC layer (hence, all the MLME interfaces required). It seems that public key verification and execution of cryptographic protocols could be handled in the MAC layer only, thus making for a very thin interface with other layers (and allows use of 802.15.3 services without changes to the hardware and/or software at different layers).

SuggestedRemedy:
An example security architecture that allows for handling of all keying material and cryptographic operations at the MAC/PHY layer will be presented during the Dallas meeting, January 2-25, 2002. (Document No: 02029r0, 02030r0).


Comment:
Each of the communicating parties should provide evidence that it corroborated evidence regarding its true identity itself.

SuggestedRemedy:
Replace 'public keys' by 'public keys and evidence that each of these parties have access to the corresponding private keys'.


Comment:
The current text does not cover the consequences of the execution of an authentication protocol.

SuggestedRemedy:
Include the following paragraph hereafter:  "The piconet controller will reject any commands other than an authentication request from associated devices for which the authentication protocol was not completed successfully. It will accept any commands from a positively authenticated device."


Comment:
This is an obvious error in the current text.

SuggestedRemedy:
Replace 'piconet' by 'piconet controller'.


Comment:
Include the following text herefore: "Special attention should be given to the fact that not all communication might be realized online, since one cannot assume that all devices are aware of each other (dormant mode)."


Comment:
In the current draft, the change of PNC automatically triggers a re-authentication procedure. This (expensive!) re-authentication procedure is not required by the security policy (10.3.3), since the role change does not invoke a change to the key-sharing group, and should therefore be avoided altogether.

SuggestedRemedy:
Replace this entire sub-clause by a more appropriate text as follows:"A change of piconet controller is based on the election of an alternate piconet controller.The parting piconet controller transfers the list of authenticated piconet devices to the new piconet controller. If this list is received in proper order, the new piconet controller will take this list as to represent the authenticated devices in the piconet and will act accordingly. Hence, it will reject any commands other than an authentication request from associated devices that are not listed as being authenticated and it will accept any commands from a device that is listed as being authenticated. If this list of authenticated devices is not received properly, e.g., if the parting piconet controller has vanished, all devices must be assumed to be unauthenticated, thus requiring the piconet controller to engage in the same communications as described in §10.3.4.2.1 and re-authenticate each of the other devices in the piconet."


Comment:
Symmetric keys of a particular type shall be used for the associated usage only, e.g., keys intended for securing the exchange of data keys shall not be used for securing the exchange of user data, and vice versa. Symmetric keys of a particular usage type shall be used for the associated usage only, e.g., keys intended for usage with an encryption algorithm shall not be used with a keyed hash function, and vice versa. Public keys of a particular type shall be used for the intended usage only, e.g., public keys intended for securing the establishment of symmetric keying material shall not be used for authenticity verification purposes, and vice versa. Expired or archived keys should not be used for, e.g., encryption and for the provision of data integrity any more, but might still be used for, e.g., decryption and for the verification of data integrity. The type of keying material, its intended usage, and the status as to its life cycle should become available during the generation or during the transfer of the key. Subsequent versions of the same key should be distinguishable via a key sequence number, such as to prevent the usage of old keys, when new keys have been issued, or vice versa. At any moment of time, the binding between the key value and all the key aspects discussed above should be stored in an authentic way.

SuggestedRemedy:
Incorporate a classification of key life cycle and key usage aspects, both for public keying material and for symmetric keying material, and adapt key data objects accordingly.

Response:
PROPOSED ACCEPT IN PRINCIPLE. We need to add the possibility of tieing key generation to authentication. Change all text to informative language and place in ANNEX B.3.


Comment:
Currently, the mapping of roles to devices that is in effect is static in nature (see 10.3.2.2 on Page 182). Moreover, the role of the security manager is identified with that of the current piconet controller. This approach, although simple, has its drawbacks, since it assumes each device to trust the piconet controller and, more importantly, to trust each subsequent piconet controller for its security needs. This might be especially undesirable in the event of an automatic piconet hand over, since the devices constituting the piconet exercise no control over the election process of the new piconet controller. From an implementation viewpoint, the drawback is that each change of the piconet controller now invokes by definition a change of security manager, thus potentially requiring an expensive re-establishment of keying relationships between all devices and the new security manager.

SuggestedRemedy:
Incorporate a more flexible security model.  Currently, all trust in the piconet is concentrated in a single device, the PNC, which poses some restrictions one should be very well aware of. A more general security model will be presented during the Dallas meeting, January 2-25, 2002. (Document No: 02029r0, 02030r0). This more general security model prevents the disadvantages of the approach we had to take in draft D09, while still allowing that approach, as a special case. The general security model allows for a relaxation of the amount of trust that needs to be concentrated in a single device while at the same time allowing a speed up of authentication and a more robust architecture, if the PNC changes.


Comment:
Currently, only the broadcast communication scenario is being elaborated upon. This conflicts with Sub-clause 10.1.1, Page 177, lines 25-26 (which specifies both peer-to-peer and broadcast communications); this should be corrected.

SuggestedRemedy:
Incorporate a mechanism for secure multicasting within the piconet setting.   A general solution the multicasting communication scenario (i.e., communication for any specified subset of the devices that constitute the piconet) will be presented during the Dallas meeting, January 2-25, 2002. (Document No: 02029r0, 02030r0).


Comment:
Currently, anonymity is not considered in the draft. Lack of anonymity was a major criticism of the original Bluetooth specification. It led to a change requirement by Ericcson, after this privacy issue had been advertised on the front cover of the NY Times). One distinguishes a number of anonymity issues, including (1) tracking of devices and thereby their users; (2) trace-ability of the manufacturer of the WPAN-chip, which might lead to passively monitoring which devices are owned by whom (e.g., for device theft).

SuggestedRemedy:
Investigate whether anonymity would be required (e.g., as a distinguishing feature for WPAN vs. Bluetooth). Investigate how this could be realized technically, if at all, and what changes this would require to the specification of the security framework and of data objects (device Id format and the-like).


Comment:
Admission to a piconet is now based on evidence regarding the true identity (device Id) of a communicating party only (via an authentic public key). Since this is the Id of a chip that could potentially be used in a wide variety of devices (invisible to the user), the user is left pretty much in the dark on what device capabilities are present in the piconet and whom (i.e., which human operators of the devices) it is actually talking to. This might lead to inclusion of devices one does not want to participate in communications. Instead, access control should be based on the actual user or usages of the device.

SuggestedRemedy:
Incorporate a more refined access control mechanism than presently described in the draft.  One also has to associate users or usages with the device Id, rather than just a public key. Moreover, one has to incorporate access control lists based on these. I will try and sketch how the user or the usage of a device could be securely associated with the Id of the device, thus defining the relationship User/usage - Device Id - Public key in a more explicit way. This would also allow access control lists to be implemented based on the user's attributes associated with the device Id in question.One distinguishes the following entities:·	physical device;·	device Id;·	public key; ·	user;·	user and device attributes.One distinguishes the following bindings at the device level:·	Device & device Id: physical tying of the device to its identity (to prevent identity theft)·	User & device: binding between the device and its user, via authentication techniques (e.g., PIN code, password, biometrics).·	Device Id & public key: cryptographic binding of the device Id to the public key (e.g., via a public key certificate).·	Device Id & device attributes: binding between the device Id and personalization attributes (e.g., via attribute certificate).·	User & user attributes: binding between a user and personalization attributes hereof (e.g., via attribute certificate).Within the current specification, authentication is based on the proper Id of the device only. If each device has some device and user attributes associated with it, one can achieve a more refined access control as follows:At personalization of the device, one could securely associate device and user attributes with a device. At usage of a device, one could maintain an access control list of those devices that are allowed to communicate with it in a piconet. At device authentication, one also passes the attribute certificate that securely binds the device to user and device attributes. Access control is then based on these attributes as well, rather than on an authentic public key only. One can modify the access control list via a procedure similar to an 'address book' on a PDA. The implementation hereof requires a user interface. If one has no user interface (e.g., 'speaker-receiver'-type application), the access control list might be established via an automatic mechanism, e.g., during set-up of this equipment.The specification should provide the mechanisms and formats to allow implementation of dynamic access control lists and of user and device attributes and the like. Currently, this is completely lacking in the draft.


Comment:
Currently, there are no references to communication behavior and security associations with child and neighbor piconets.

SuggestedRemedy:
Incorporate communication behavior and security associations with child piconets and neighbor piconets.


Comment:
Add the following (informative) paragraph hereafter:"First, however, we give a general overview.The system comprises of ordinary devices, a single piconet controller, and a fixed external trusted party (see the mapping of roles to devices as defined in 10.3.2.2). The piconet controller acts as the security manager of the operational network. As such, it authenticates devices that would like to join the piconet and facilitates the distribution of data keys, to be used for securing communications between devices in the piconet. In addition, it allocates time slots for these message exchanges to each piconet device (see the role model of 10.3.2.1). Finally, it enforces the security rules as formulated in 10.3.3. Device authentication and the initial establishment of keying material are based on public key techniques. Evidence regarding the authenticity and validity of these public keys is corroborated via the external trusted party, who facilitates the generation of authentic public keying material for each device and the verification hereof during system operations (see 10.3.1.3 and 10.3.2.1). The role of the external trusted party is limited to the system initialization phase." Comment: this informative text illuminates some of the design rationale behind the current security architecture and should prove useful, esp. to non-specialists.


Comment:
Not enough details on security/authentication

SuggestedRemedy:
Specify enough details on security/authentication that vendors can build 802.15.3 devices that can communicate securely while being interoperable with other vendor's products. This includes the choice of a mandatory cipher suite as required by the vote in Austin.


Response:
ACCEPT IN PRINCIPLE. The three TBDs have been removed.  See the resolution for comments 296 (TBD on page 107), 294 (TBD on page 133) and 1744 (TBD on page 175).


Comment:
What does older revision of the standard mean?


Comment:
The document does not fully address coexistence in the 2.4 GHz band.

SuggestedRemedy:
Fully address coexistence in the 2.4 GHz band.

Response:
PROPOSED ACCEPT IN PRINCIPLE. The proposed informative Annex (00000r0P802-15-3-Annex_Coexistence.pdf) has a description of the coexistence methods that are available in the draft. Also see 02/041r2 for a presentation and additional text on this issue. For 802.15.4 compatibility see subclause 6.9 in 00000D13P802-15-4__Draft_Standard.pdf. TG2 has been consulted and they will help with analysis.


Comment:
Whereby, I support the fact the specification is required by applications and Industry, and needs to be published within the normal process timeframes, I believe that the current 802.15.3 base specification does not fully address my concerns with regards to coexistence with other published IEEE 802 Wireless Standards.

SuggestedRemedy:
More consideration needs to be applied to this complex interaction before my NO vote is changed to a YES vote.

Response:
ACCEPT IN PRINCIPLE. The committee has developed analysis and text that describe the capabilities for coexistence and interoperability for 802.15.3 and 802.15.1 and 802.11b.  The relevant documents are 00000P802-15-3-Annex_Coexistence.pdf and 01/041r2.


# TypeList

TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In("C", "Z")


TypeList:
[CommentType] = "TR" AND [ResponseStatus] = "W"  AND [CommentStatus] In ("A","R")

Header:
Thank you for your participation in the recent IEEE 802.3ae ballot. We have received your ballot.
not yet received an email from you confirming your reaction to the committee's 
proposed responses to your comments. Please take the time to let us know, 
for each item, whether each response, in your judgement, satisfactorily 
resolves your comment(s). 

If you would like, you may simply insert the word APPROVE, or DISAPPROVE, 
next to each comment and return this file.  That is all that is required.

In those instances where you indicate that you APPROVE or DISAPPROVE the committee's 
proposed response, our records will be updated. In those instances where you 
do not indicate a response, your vote will stand as previously submitted.

Thank you for your assistance.

Sincerely,
Dr. Howard Johnson, 
Chief Technical Editor of IEEE P802.3z Gigabit Ethernet

----**<copy of proposed committee responses attached>**----
>
>


TypeList:
[CommentType] In ("T","E") AND [CommentStatus] In ("A","R") AND [ResponseStatus] In ("W")

Comment:
The report "close T and E" will change these response statuses to "C"


TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In ("C","Z")


