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

Gilb

Informations

• Publié par: Undoe
• Nombre de lectures: 24
• Langue: English

Extrait

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: [[e-mail]] 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