03032r13P802-15 TG3-SB1-running-comment-resolutions
100 Pages
English

03032r13P802-15 TG3-SB1-running-comment-resolutions

-

Downloading requires you to have access to the YouScribe library
Learn all about the services we offer

Description

February, 2003 IEEE P802.15-03/032r131IEEE P802.152Wireless Personal Area Networks 345Project IEEE P802.15 Working Group for Wireless Personal Area Networks 67(WPANs)89Title TG3 SB1 comment resolution1011Date [13 February, 200312Submitted1314Source [James P. K. Gilb] Voice: [858-485-6401]15[Appairent Technologies] Fax: [858-485-6406] 16[15373 Innovation Drive, #210, E-mail: [gilb@ieee.org] 1718San Diego, CA 92129]1920Re: []2122Abstract [This document is a record of comment resolutions for SB1.]2324Purpose [To provide a record of the comment resolution for SB1.]25Notice This document has been prepared to assist the IEEE P802.15. It is 2627offered as a basis for discussion and is not binding on the contributing 28individual(s) or organization(s). The material in this document is subject 29to change in form and content after further study. The contributor(s) 3031reserve(s) the right to add, amend or withdraw material contained herein.32Release The contributor acknowledges and accepts that this contribution 3334becomes the property of IEEE and may be made publicly available by 35P802.15. 36373839404142434445464748495051525354Submission 1 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r131 1. Conference calls231.1 Thursday, 13 February 200345Agenda67 - Roll call8 - Resolution for CID 45, 82 (see below)9 - Security issues10 - Starting value of SECID (CID 18)11 ...

Subjects

Informations

Published by
Reads 24
Language English

February, 2003 IEEE P802.15-03/032r13
1IEEE P802.15
2
Wireless Personal Area Networks 3
4
5
Project IEEE P802.15 Working Group for Wireless Personal Area Networks 6
7(WPANs)
8
9Title TG3 SB1 comment resolution
10
11Date [13 February, 2003
12Submitted
13
14Source [James P. K. Gilb] Voice: [858-485-6401]
15
[Appairent Technologies] Fax: [858-485-6406] 16
[15373 Innovation Drive, #210, E-mail: [gilb@ieee.org] 17
18San Diego, CA 92129]
19
20Re: []
21
22Abstract [This document is a record of comment resolutions for SB1.]
23
24Purpose [To provide a record of the comment resolution for SB1.]
25
Notice This document has been prepared to assist the IEEE P802.15. It is 26
27offered as a basis for discussion and is not binding on the contributing
28individual(s) or organization(s). The material in this document is subject
29
to change in form and content after further study. The contributor(s) 30
31reserve(s) the right to add, amend or withdraw material contained herein.
32
Release The contributor acknowledges and accepts that this contribution 33
34becomes the property of IEEE and may be made publicly available by
35
P802.15. 36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Submission 1 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
1 1. Conference calls
2
3
1.1 Thursday, 13 February 20034
5
Agenda6
7
- Roll call8
- Resolution for CID 45, 82 (see below)9
- Security issues10
- Starting value of SECID (CID 18)11
- Other security issues (see below).12
- Draft status13
- Assignments for review14
- Adjourn15
16
Attendees: James Gilb, Ari Singer, John Barr, Allen Heberling, Bill Shvodian, Dan Bailey, Jay Bain, John17
Sarallo18
19
Meeting called to order at: 9:08 am, PST.20
21
CID 45 - A total of three octets would be used for DEV capabilities. Part of one would include the fragmen-22
tation preference (as for the 2.4GHz PHY). The other two would have additional PHY characteristics. For23
now, the rate bits would be aligned to the right of the 16 bits available. The three octets would be in 7.4.12,24
7.5.1.1, and 7.5.4.2. For 7.4.4, the octet with the frag preference would not be present so the total there25
would be two octets instead of the current single octet.26
27
I believe the change is only within clause 7.28
29
OK, current fields stay the same number of bits, the rest are reserved.30
31
CID 82 - The change for the remote scan remains that text in clause 7 would allow for an IE to be located32
within the remote scan result command. It would not be present for this PHY. Again, the change is local to33
clause 7.34
35
Add an IE, specified to be used for future extensions. Currently ignored by the PNC and set to the36
undefined element ID, xref table 50, with zero length.37
38
39 1.2 Security issues
40
41 CID 18 - What is the SECID when the piconet starts? What about the key? What if no one is in it?
42
43 Add text that says when the piconet is started and it is operating in mode 1, the PNC selects a SECID
44 and key to be used for beacon protection, even though this key is not sent to any other DEV. Add to
45 end of 9.3.9 Selecting SECID for new keys.
46
47 From John Barr:
48
49 Page 231, lines 3-7: Delete "Recognizing the diversity ... cryptography." and "The instantiation ... suite." and
50 "The background ... Annex C.1." Replace with "This standard supports the implementation of an authentica-
51 tion protocol between DEVs and between a DEV and the PNC. It also supports protection of command and
52 data frames using an 128-bit AES security suite, and the distribution of keys for command and data frame
53 protection." You might want to elaborate, but this is better than what is there.
54
Submission 2 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
Wireless networks face unique security challenges and piconets are no exception. Recognizing the 1
diversity of piconet applications and entities, this standard supports two different modes of security, 2
no security and the use of strong cryptography. The standard support the protection of command and 3
data frames using an 128-bit AES security suite, and the distribution of keys for command and data 4
frame protection. 5
6
The background assumptions used in designing this security solution are outlined in Annex B.1. 7
8
Change 9.1 "Security services" to "Security Mechanisms". Change "services are protections offered on com- 9
munications" to "mechanisms are available for use". 10
11
Accept. 12
13
Delete section 9.1.1 entirely 14
15
Accept. 16
17
Lines 23-24: Change "An authentication protocol ... within a piconet. This protocol" to "The authentication 18
and challenge commands". 19
20
Subclause deleted. 21
22
Line 33: Change "Authentication methods" to "Authentication protocols and policies". 23
24
Subclause deleted 25
26
Lines 37-38: Change "of a shared key or keys" to "of management and payload protection keys". 27
28
Subclause deleted. 29
30
Page 232, Line 26: Change "key(s)" to "key". Only the management key is used to protect commands. 31
32
Accept. Fixed everywhere it occurs in the draft where appropriate. 33
34
Delete last paragraph, lines 47-51. No such thing as an ACL any longer in the MAC. 35
36
Accept. 37
38
Page 233, lines 1-7: The new MAC does not differentiate between security suites. Only mode that is really 39
defined is symmetric security for command and data protection. We don’t get into how a security suite/sys- 40
tem performs authentication. 41
42
Accept in principle, only ref symmetric key security operations. 43
44
Delete sections 9.2.2.1 and 9.2.2.2. 45
46
Put information from 9.2.2.1 into Annex C, if not already there. 47
48
Line 26: Change "Security policies" to "Security Support" 49
50
Accept. 51
52
Line 29: Change "requirements and recommendations for the use of security in the piconet." to "now this 53
standard can be used to support specific security policies." 54
Submission 3 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
1 ‘The following sub-clauses specify the methods that are provided in this standard to support specific
2 security policies.’
3
4 Line 33: Delete "provided by this standard"
5
6 Accept
7
8 Line 49: Change "Sound security practice indicates that only" with "Only"
9
10 Accept.
11
12 Line 49: Change "piconet would be" to "piconet should be"
13
14 Accept in principle ‘piconet are’
15
16 Page 234, lines 7-11: Is this policy or a mechanism.
17
18 Text OK as is, this behavior is required.
19
20 Lines 13-20: No more ACL. We have security information instead.
21
22 Accept. Change to Security Information, Security Information Request and security information.
23
24 Line 42: Not sure "device shall be associated" is correct. What does this have to do with setting the SEC field
25 to 0?
26
27 Sentence deleted.
28
29 Line 49: Change "the DEV should initiate" to "the DEV shall initiate"
30
31 Accept in principle, see new text: ‘After the DEV has associated and exchanged the desired informa-
32 tion with the PNC, the DEV shall establish secure membership. The process by which secure mem-
33 bership is established is outside of the scope of this standard.’
34
35 Section 9.3.6: Most of this paragraph seems right, but at the end I am left with the question of just what does
36 the standard provide for implementation of an authentication protocol. I think we should be answering
37 "What can be done by an external DME to implement an authentication protocol?" We have the authentica-
38 tion request/reply and the challenge request/reply messages that can be used as part of the authentication
39 protocol.
40
41 Accept in principle, Vendor Specifics commands have been allowed for this process.
42
43 Page 239, line 47: Is it a "Security suite" or a "Security system" that is identified by an OID? Two DEVs
44 need to agree on which security system they are going to use for a security relationship. Once decided, the
45 two security systems communicate via the authentication/challenge commands. If a DEV supports more
46 than one security system, the OID will need to be included in those commands to make sure the MAC passes
47 the command frame information to the right security system manager.
48
49 Subclause 9.4 deleted.
50
51 Page 240, lines 3-23: Are these sections really needed? They don’t really define how the MAC interoperates.
52 If we think of just providing what a security system requires as a special communications path, we don’t
53 really need to know what the data formats, protocol operations, and cryptographic implementations are. We
54 just provide a container to carry information between the client and server parts.
Submission 4 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
Subclause 9.4 deleted. 1
2
Why is more than one key implied? Page 142, Line 49: "The integrity code is generated using the manage- 3
ment keys that are shared ..." Page 143, Line 20: "This command shall be protected using the management 4
keys that are shared ..." Page 143, Line 36: ibid. In the definition of the symmetric security suite the manage- 5
ment key (singular) is the only key defined. Change all occurrences of keys and key(s) regarding manage- 6
ment key usage to be singular instead of plural. 7
8
Accept. In some locations both keys (data and management) are referred to and in others it refers to 9
keys in a general fashion. 10
11
Page 240, line 42: "The protocols in this clause are algorithm independent and may be used for any security 12
suite". This sentence is left over from earlier. It is my understanding that we are using AES-128 symmetric 13
keys as the management key and the data protection key. Delete the line. 14
15
Accept. 16
17
Page 240, Line 52-53: Delete ", but it does not need to store the public keys of these DEVs". Change "keys" 18
to "key" in the first part of this sentence as well. 19
20
Accept. 21
22
Page 241+: Using "key(s)" in various places. I think we need to clearly state which key is used for what if 23
"key(s)". It is not clear which keys are being use. We only have a management key and a data protection key. 24
25
Accept. 26
27
Pages 240-244: Delete clauses 9.5, 9.6, and 9.7. Update clause 9.8 to use same notation as in clauses 6, 7, 28
and 8 instead of introducing an extremely confusing and possibly incorrect intermediate notation. 29
30
Delete 9.5, 9.6, 9.7, 9.8.4, 9.8.5, Table 70, Table 71, Table 72, Table 73, Figure 157, Figure 160 31
32
Page 244: Delete lines 29-33: Again the setup tables and capabilities tables are redundant and not required. 33
Just confusing. 34
35
Deleted as above. 36
37
Page 244, Lines 40-43: Delete sentence "Therefore it is assumed ... in the MAC PIB." Implementation spe- 38
cific which is out of our scope. 39
40
Delete ‘through information stored in the MAC PIB.’ 41
(all edits up to this point have been applied). 42
43
Page 245, clause 9.8.2.1: Figure 152 has an interface to the MLME and the state machines. This clause talks 44
about frames, but there are no connections in Figure 152 to obtain frames. I think we have a much simpler 45
architecture now and clause 9 does not reflect this simplicity. For example: 46
47
Unassociated -> associated/unauth upon completion of association protocol (clause 8) 48
49
associated/unauth -> associated/authenticated upon receipt of successful authentication response and 50
SECID_UPDATE command from MLME. 51
52
associated/authenticated -> associated/unauthenticated upon receipt of valid 53
54
Submission 5 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
deauthentication command. 1
2
All commands are formed based on current associated and authenticated state using the management 3
(SECID_UPDATE) or data protection (Distribute_Key or Request_key response) key information main- 4
tained in the MAC. 5
6
A new data protection key is established upon receipt of a Distribute_Key command from a valid key origi- 7
nator. The MAC has the management key from a SECID_UPDATE. A new data protection key can also be 8
established using the Request_Key protocol when a SECID gets changed. 9
10
The changes required should be easy for someone familiar with the secure exchange of keys and such. Right 11
now I think it is much too complicated and it needs to be rewritten before final approval. 12
13
14
15
Stopped here, meeting adjourned at 10:40 am PST. 16
17
Page 244, Lines 23-25: Delete "The algorithm choices for each operation in the protocols are determined by 18
the selected security suites, which are specified in clause 10." We only have a single symmetric security suite 19
defined. 20
21
22
23
Page 274, Lines 43-45: Delete "All of the sub-suites defined in this standard perform symmetric operations 24
in the same manner as specified in this subclause." No sub-suites defined any more, just the symmetric suite. 25
26
27
28
Page 61+, clause 6.3.14: "ACL information retrieval" should be changed to "Security Information 29
Exchange". Please correct as agreed in Ft. Lauderdale. 30
31
32
33
Clause 4: Remove ACL Acronym from list. 34
35
36
37
Page 16, Lines 9-11: Change "The PNC is allowed to use an access control list (ACL) to admit or deny entry 38
to the piconet. The PNC uses the address of the DEV to determine if it will be allowed access to the piconet." 39
to "The PNC allows the DME to determine whether any DEV is allowed to be a member of the piconet." 40
41
42
43
Page 55, Line 7: We no longer have an ACL, only a table of SECIDs. Change "find the designated key in the 44
ACL" to "resolve the SECID". 45
46
47
48
Page 56, line 18: Change "find an appropriate key in the ACL" to "match the received SECID with a known 49
SECID". 50
51
52
53
54
Submission 6 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
Page 56, Line 20-21: Change "according to the security suite or for which the DEV is unable to find the des- 1
ignated key in the ACL" to "or for which the DEV does not have a known SECID matching the received 2
SECID". 3
4
5
6
Page 137, table 52: Update to replace ACL with Security Information. 7
8
9
10
Page 147, clauses 7.5.4.3 and 7.5.4.4 need to be updated to remove ACL and replace with the agreed on 11
security information formats. 12
13
14
15
Page 168, line 13-14: Change "ACL handover" to "Security information handover" 16
17
18
19
Page 175, lines 3-7: Change "The PNC may maintain an access control list (ACL) of DEV addresses that are 20
allowed to join the piconet. If the ACL is in use, when the PNC receives an association request command, 21
the PNC shall consult the ACL to determine if the DEV address in the request is included in the ACL. If the 22
DEV address is not in the ACL, the PNC shall send an association response command with the reason code 23
set to "association denied", 7.5.1.2, indicating that the association failed." to "The PNC allows the DME to 24
selectively deny association of any DEV. If the DME denies the association of any DEV, the PNC shall send 25
an association response command with the reason code set to "association denied", 7.5.1.2, indicating that 26
the association failed." 27
28
29
30
Clauses 9.2.2, 9.3.4, 9.8.3 also contain references to ACL that need to be changed to Security Information. 31
32
33
34
Page 351, lines 40-21: ACL information request and ACL information need to be changed to security infor- 35
mation in table E-3. 36
37
38
39
page 355, line 44-45: ACL info handover should be Security info handover in table E-5. 40
41
42
1.3 Tuesday, 11 February 2003 43
44
Agenda: 45
46
- Roll call 47
- Editorial issues 48
- New probe command 49
- Security issues (ref 03/032r11 and email from A. Singer) 50
-References to security suites and OIDs in the draft, without making any statements about what 51
they are or how they work exactly. 52
- Changes proposed in 334 and 336, right/left first/last in describing bit ordering. 53
54
Submission 7 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
- There are some security policies that are included with the words "may" or "should" in clause 1
9 to give some guidance to implementers on how to use the MAC commands. Are these appropriate? 2
- Text CID 340. 3
- Is CID 342 resolved the way the group wants? The sections describing security analysis for 4
the public-key stuff were removed. 5
- The resolution for CID 345 should be changed to indicate that the entire sub-clause was 6
removed. 7
- Merge Annex B and Clause 10 since they are both 8
reasonably small now and cover related topics? 9
- Draft status and schedule 10
- Next meeting 11
- Adjourn 12
13
Attendees: James Gilb, Ari Singer, Jay Bain, Bill Shvodian, Allen Heberling, Rene Struik, Dan Bailey, John 14
Sarallo. 15
16
Meeting called to order at 8:10 am PST. 17
18
1.3.1 Editorial issues: (all E comments) 19
20
CID 440 - Rename MLME-ASIE-CREATE to MLME-ASIE-UPDATE? 21
22
Reject, keep current naming. 23
24
CID 217 - Apparently, IntServ - type QoS might be able to be supported, beyond 802.1p. Please state such. 25
26
‘802.15.3 only has the priorities as a parameter. It doen’ t specify a bandwidth manager nor does it 27
have policing, shaping or other IntServ stuff. It doesn’ tt even specify the jitter for reasons that are 28
fairly obvious in wireless design. 29
30
It is true that it is possible to pass IntServ data packets over a piconet, but so you can with any other 31
data, be it Diffserv, RSVP, 1394.... 32
33
Accept in principle: ‘An implementer is allowed to send IntServ packages and define IntServ policy 34
functions in the FCSL, but that it would be out of scope of the standard. Other QoS services would 35
also be supported, e.g. Diffserv, RSVP, 1394, etc.’ ” 36
37
1.3.2 New probe commands? 38
39
CLAUSE 3 CHANGES 40
41
Page 6 Line 5: 42
43
Replace 44
45
“A beacon followed by one or more broadcasted probe commands from the piconet controller.” 46
47
with 48
49
“A beacon followed by one or more broadcasted Announce commands from the piconet controller.” 50
51
CLAUSE 5 CHANGES 52
53
Page 16 Line 33: 54
Submission 8 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
Replace 1
2
“ The beacon consists of the beacon frame, 7.3.1, as well as any Probe commands sent by the PNC as 3
a beacon extension, 8.6.3.” 4
5
with 6
7
“ The beacon consists of the beacon frame, 7.3.1, as well as any Announce commands sent by the 8
PNC as a beacon extension, 8.6.3.” 9
10
Page 18 Line 32: 11
12
Replace 13
14
“ This standard supports three methods for discovering information about other DEVs in the piconet: 15
the PNC information request command, the Probe command and the piconet services information 16
element.” 17
18
with 19
20
“ This standard supports four methods for discovering information about other DEVs in the piconet: 21
the PNC Information Request command, the Probe Request command, the Announce command and 22
the Piconet Services IE.” 23
24
Page 18 Line 46: 25
26
Replace 27
28
“A DEV uses the Probe command, 8.9.2, to find out more detailed information about other DEVs in 29
the piconet. This command allows the originating DEV to retrieve any valid information element, 30
7.4, from a target DEV in the piconet. In addition, the target DEV is able to request information from 31
the originating DEV during this process.” 32
33
with 34
35
“A DEV uses the Probe Request command, 8.9.2, to find out more detailed information about other 36
DEVs in the piconet. This command allows the originating DEV to retrieve any valid information 37
element, 7.4, from a target DEV in the piconet.” 38
39
CLAUSE 6 CHANGES 40
41
Table 3: 42
43
Replace 44
45
46
47MLME-PROBE 6.3.16.1 6.3.16.2 6.3.16.3 6.3.16.4
48
49
50
with
51
52
Page 66 Line 24:
53
54
Submission 9 James P. K. Gilb, Appairent TechnologiesFebruary, 2003 IEEE P802.15-03/032r13
1
MLME-PROBE 6.3.16.1 6.3.16.2 6.3.16.3 6.3.16.4
2
MLME-ANNONUCE {xref} {xref} {xref} 3
4
5
Replace 6
7
“ If the request fails, the PNC DME may decide to send the ASIE with the Probe command, 7.5.4.5. 8
It also may try to send the ASIE in another beacon.” 9
10
with 11
12
“ If the request fails, the PNC DME may decide to send the ASIE with the Announce command, 13
7.5.4.5. It also may try to send the ASIE in another beacon.” 14
15
Page 67 Line 1: 16
17
Replace Clause 6.3.16 with the following: 18
19
(begin new text) 20
21
1.3.3 Peer information retrieval 22
23
The MLME-PROBE primitives are used to request information about other DEVs in the piconet. The param- 24
eters used for the MLME-PROBE primitives are defined in Table 1. 25
26
27
Table 1— MLME-PROBE primitive parameters 28
29
30Name Type Valid range Description
31
TrgtID Integer Any valid DEVID as Specifies the DEVID of the target of the 32
defined in 7.2.3. MLME request. 33
34OrigID Integer Any valid DEVID as Specifies the DEVID of the DEV that ini-
35defined in 7.2.3. tiated the MLME request.
36
InformationRequested 4 octets As defined in {xref}. Indicates which information elements are 37
requested as defined in {xref}.
38
InformationElements Variable number As defined in {xref}. The information elements sent or received 39
of octets. in the Probe command, as defined in 40
{xref}. 41
42ProbeTimeout Duration 0-65535 The time in milliseconds by which the
operation initiated by the MLME request 43
needs to be completed before responding 44
with a ResultCode of TIMEOUT. 45
46ResultCode Enumeration SUCCESS, TIMEOUT Indicates the result of the MLME request.
47
48
49
50
51
52
53
54
Submission 10 James P. K. Gilb, Appairent Technologies