idnits 2.17.1 draft-wu-paws-secutity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-paws-problem-stmt-usecases-rqmts' is defined on line 548, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-paws-problem-stmt-usecases-rqmts-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS Y. Wu 3 Internet-Draft Y. Cui 4 Intended status: Informational Huawei 5 Expires: April 25, 2013 October 22, 2012 7 Protocol to Access White Space Database:Security Considerations 8 draft-wu-paws-secutity-01.txt 10 Abstract 12 This document analyses common security threats of the Protocol to 13 Access White Space database (PAWS), and describes their potential 14 impacts on message exchanges between master device and white space 15 database when implementing PAWS. Meanwhile, the corresponding 16 countermeasures are also introduced in this document. The PAWS is 17 used for retrieving the available white space information at a given 18 location and time from a white space database. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and terminology . . . . . . . . . . . . . . . . . 3 68 2.1. Conventions used in this Document . . . . . . . . . . . . 3 69 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. PAWS Security Threat Overview . . . . . . . . . . . . . . . . 4 71 4. Detailed Threat Description . . . . . . . . . . . . . . . . . 4 72 4.1. Impersonation of Master Device . . . . . . . . . . . . . . 4 73 4.2. Impersonation of Database . . . . . . . . . . . . . . . . 5 74 4.3. MitM Attack between Master Device and Database . . . . . . 5 75 4.4. Attacks on the Link of master Device and Database . . . . 5 76 4.5. Attacks on the Master Device Itself . . . . . . . . . . . 6 77 4.6. Other Potential attacks(To Be Added) . . . . . . . . . . . 6 78 5. Security Schemes . . . . . . . . . . . . . . . . . . . . . . . 6 79 5.1. Security Countermeasures . . . . . . . . . . . . . . . . . 6 80 5.2. Security Features . . . . . . . . . . . . . . . . . . . . 7 81 5.3. Analysis of Security Schemes . . . . . . . . . . . . . . . 7 82 5.3.1. Brief Introdution of TLS Protocol . . . . . . . . . . 7 83 5.3.2. Mutual Authentication . . . . . . . . . . . . . . . . 9 84 5.3.3. Drawbacks of TLS Protocol . . . . . . . . . . . . . . 12 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 88 9. Normative Reference . . . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Portions of the radio spectrum that are allocated to a licensed, 94 primary user but are unused or unoccupied at specific locations and 95 times are defined as "white space". To maximize utilization of these 96 white space spectrum, the concept of allowing secondary transmissions 97 (licensed or unlicensed) in these spectrum is proposed. The widely 98 accepted approach of sharing white space spectrum without 99 interference is by querying the database and the corresponding 100 protocol "Protocol to Access White space database" is defined. 102 In PAWS protocol, a master device connects to a database using White 103 Space (WS) interface. There are much sensitive information, such as 104 location information and/or identities of master devices, which MAY 105 be transmitted between the WS interface of the master device and the 106 database when the PAWS is implemented. If an attacker can have full 107 access to the network medium between the master device and the 108 database, the attacker may deploy varieties of attacks on the network 109 using the sensitive information if there is lack of suitable security 110 mechanism.Therefore, the messaging interface between the master 111 device and the database needs to be secured. Meanwhile, to guarantee 112 a legitimate and authorized master device connects to the proper 113 database, the mutual authentication is required before the security 114 association established. 116 In this document, the security threats, the security features and the 117 security mechanism for protecting the PAWS are discussed in details. 119 2. Conventions and terminology 121 2.1. Conventions used in this Document 123 The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT", 124 "SHOULD", "SHOULD NOT","RECOMMEND", "MAY", and "OPTIONANL" that 125 appear in this document are to be interpreted as described in 126 [RFC2119]. 128 2.2. Terminology 130 The Terminology Section of the latest version of [I-D.ietf-paws- 131 problem-stmt-usecases-rqmts] shall be included by reference. 133 WS interface 135 The interface between master device and Database specifies data model 136 and process of PAWS in this document. 138 Database or white space database 140 That provides white space spectrum information to master device. 142 Master device 144 A device is able to query a database for available white space 145 spectrum using location information. 147 3. PAWS Security Threat Overview 149 PAWS protocol defines an approach to share the white space spectrum 150 for secondary transmissions, enabling a master device to acquire 151 available white space spectrum information from a database, and 152 specifies the use of HTTP/TLS as transport for the protocol. 154 According to PAWS protocol, a master device sends a request that 155 contains its location information and any parameters required by the 156 regulatory rules (such as device identifier, capabilities, and 157 characteristics) to database for the available spectrum. If the 158 request is valid, the database returns a response that includes an 159 available frequency list and related information. 161 An adversary has several way of harming this progress: it can 162 masquerade as another valid device, eavesdrop on any communications 163 between the master device and the database, and replay or modify the 164 request or response message and so on. These attacks are presented 165 in detail in section 4. 167 The different ways of attacking this querying progress may eventually 168 lead to unauthorized use of channels by an uncertified device, an 169 authorized device receives a malicious response and result in the 170 master device causing interference to primary user of the spectrum, 171 tracking of master device locations and identity. 173 4. Detailed Threat Description 175 For each threat, described in the below, a description of the 176 corresponding attack is given as follows. 178 4.1. Impersonation of Master Device 180 If there is no authentication of the master device, the white space 181 database cannot detect the rogue master device, and the available 182 white space channel list will be passed to the Rogue master device. 183 This enables a rogue master device to use the available channels. 185 Besides, the rogue master device can connect to the white space 186 database by using the registration exchanges, the DoS type attacks 187 may be initiated. This shows that it is essential to perform some 188 type of authentication of master device. 190 4.2. Impersonation of Database 192 If there is no authentication of the database, an attacker may 193 attempt to spoof a white space database and provide responses to a 194 master device which are malicious and result in the master device 195 causing interference to the primary user of the spectrum. At the 196 same time, the attacker also can retrieve an available white space 197 channel list from a legal database using the registration exchanges, 198 which received from the authorized master device. 200 4.3. MitM Attack between Master Device and Database 202 A man in the middle (MitM) node is inserted between the master device 203 and database, which can be considered to be a variant of the above 204 attacks. The real master device will connect to the MitM node and 205 the MitM node can connect to the real database. The MitM node can 206 transparently transmit, receive, view, and modify the traffic between 207 the real master device and the database without either of those nodes 208 being aware of it. The important security point illustrated by this 209 attack is that not only is it essential to perform mutual 210 authentication of the master device and the white space database, it 211 is important to ensure that all security tunnels from the master 212 device terminate in the trusted white space database instead of in a 213 MitM node. 215 4.4. Attacks on the Link of master Device and Database 217 The link between the master device and the white space database can 218 be wired or wireless. An attacker may wiretap the communication 219 between a valid master device and database. The threats are as 220 follows: 222 1) Steal the confidential data transmitted in the packet payload, 223 such as utilize the information about available channels by utilizing 224 those channels. The result of such an attack is unauthorized use of 225 channels by an unauthorized device. 227 2) The location/identity information can be gleaned by an 228 eavesdropper and be used for tracking purposes. 230 3) An attacker could falsify the communication between the master 231 device and the database. The channel information and some other type 232 parameters could be modified by an attacker which may result in 233 interference to the primary user of that channel. Alternatively the 234 attacker may indicate no channel availability at a location resulting 235 in a denial of service to the master device. 237 4.5. Attacks on the Master Device Itself 239 The master device may be deployed in vulnerable locations, and the 240 less trusted types of transmission links will be used to interconnect 241 that equipment to the database. Breaking the master device to get 242 sensitive data is theoretically possible. The attacker may dig out 243 the master device-database shared secret or a long term certificate 244 from the master device and tries to add another master device. 246 4.6. Other Potential attacks(To Be Added) 248 5. Security Schemes 250 5.1. Security Countermeasures 252 To mitigate the above threats, the security countermeasures below 253 should be used. Namely: 255 1) The master device shall be authenticated based on a globally 256 unique and permanent master device identity before it can obtain the 257 service from a suitable database. 259 2) The master device shall authenticate the identity of database to 260 guarantee the connected database is proper. 262 3) The master device and the white space database shall also check 263 that both of them are authorized by the regulator body of white 264 space. 266 4) Sensitive data including authentication credentials, user 267 information, cryptographic keys shall not be transmitted between the 268 master device and the white space database in plaintext in 269 unauthorized access. It means that the transport of data over the 270 interface between the master device and the database shall be 271 integrity, confidentiality, and replay protected from unauthorized 272 access. 274 5) The master device should have a secure module to store long term 275 keys or certificates. The identity of master device could be stored 276 in a trusted physical module and/or a possible non-removable 277 smartcard. 279 5.2. Security Features 281 To satisfy the security countermeasures, the security mechanism shall 282 be able to provide the following features: 284 1) Mutual authentication 286 Mutual authentication between the master device and the database 287 shall be performed before the service can be transmitted using 288 certificates or pre-shared keys or some other methods. Besides, the 289 database shall further check whether the master device is authorized 290 by Regulatory Body of White Space (RBWS) due to the fact that some 291 device may be not allowed to use the white space spectrum. The 292 credentials and critical security functions for authentication shall 293 be protected inside physically secure environment, such as Trusted 294 Environment (TrE). 296 2) The protection mechanisms of the data 298 The data over the interface between the master device and the 299 database shall be protected for integrity, confidentiality and anti- 300 replay from unauthorized parties. 302 3) Trusted environment 304 The TrE shall be a logical entity which provides a trustworthy 305 environment for the execution of sensitive functions and the storage 306 of sensitive data. All data produced through execution of functions 307 within the TrE shall be unknowable to unauthorized external entities. 309 5.3. Analysis of Security Schemes 311 There are several possible alternative schemes can be considered to 312 provide the security features detailed in section 5.2, such as TLS 313 and IPsec. In this document only TLS is introduced due to the fact 314 that the HTTP protocol is used for PAWS and the cost of IPsec is 315 higher. 317 5.3.1. Brief Introdution of TLS Protocol 319 TLS protocol provides the communications privacy over the internet 320 which is composed of two layers: the TLS Record Protocol and the TLS 321 Handshake Protocol. 323 1) The TLS Handshake Protocol is responsible for negotiating a 324 session, which is used to allow peers to agree upon security 325 parameters for the record layer, authenticate themselves, instantiate 326 negotiated security parameters, and report error conditions to each 327 other. 329 a)The peer's identity can be authenticated using asymmetric, or 330 public key, cryptography (e.g., RSA, DSA, etc). X509 certificate is 331 recommended. When the certificate is used to authenticate the 332 identity of the entity, each party shall verify the other's 333 certificate whether it is valid and has not expired or revoked. 335 b)According the [RFC5246], RSA or Diffie-Hellman can be used for 336 authentication and key exchange. 338 c)A pre_master_secret is created by key exchange process in TLS 339 handshake protocol, which will be used to generate the master_secret. 340 The master secret is required to generate the encryption keys and 341 integrity keys. 343 2) The TLS Record Protocol takes messages to be transmitted, 344 fragments the data into manageable blocks, optionally compresses the 345 data, applies a MAC, encrypts, and transmits the result. Received 346 data is decrypted, verified, decompressed, and reassembled, then 347 delivered to higher level clients. Two basic security properties are 348 as follows: 350 a)Confidentiality: symmetric cryptography is used for data encryption 351 (e.g., AES, etc). The derivation of encryption keys are based on a 352 secret negotiated by the TLS handshake protocol. 354 b)Integrity: A keyed MAC is used to message integrity check. Secure 355 hash functions (e.g., SHA-1, etc) are used for MAC generated. 357 When the TLS protocol is choose to protect the communication, all 358 HTTP data between master device and the white space database must be 359 sent as TLS "application data". Normal HTTP behavior should be 360 followed. It means that security association shall be set up by 361 using TLS protocol before establishment of the HTTP connection. The 362 master device acting as the HTTP client should also act as the TLS 363 client. It should initiate a connection to the white space database 364 on the appropriate port and then sent the TLS ClientHello to begin 365 the TLS handshake. 367 The following TLS handshake procedures shall be implemented first 368 before the master device contacts to the database using a well- 369 defined access method when it has determined a relevant white space 370 database. 372 a)The first stage: security capabilities including protocol version, 373 session ID, cipher suite, compression method, and initial random 374 numbers are established; 375 b)The second stage: certificate of the database, key exchange, and 376 request certificate shall be sent by database; 378 c)The third phase: master device sends certificate if requested. Key 379 exchange and certificate verification may be sent by master device; 381 d)The last phase: change cipher suite and finish handshake protocol. 383 In above procedure, the database server shall be authenticated, 384 whether the master device is authenticated or not in TLS handshake 385 protocol should be considered separately in the below. 387 5.3.2. Mutual Authentication 389 For business reasons or ease of management, databases may be deployed 390 by a different third-party that is authorized by RBWS. And the 391 master devices are deployed by the third-party and authorized by the 392 RBWS to use the white space spectrum. For this reason, there may be 393 two cases needed to consider how the master device authentication 394 should be implemented because the RBWS may not allow the database to 395 do this. One case is that the credential of the master device is 396 authenticated by the database, and the other case is that the RBWS 397 insures whether the master device is a valid device. The nuts and 398 bolts of these two architectures are described as follows: 400 1. Master device is authenticated by database 402 At this situation, the mutual authentication will be implemented 403 between the master device and database. How the identity of master 404 device is authenticated can be divided into following two situations. 406 1)if only a legal master device is able to connect to the database, 407 the database can determine whether a device is a master device or 408 not, then the mutual authentication should be finished in procedure 409 of TLS secure channel establishment for ease of operating. When the 410 certificates are used to authenticate each other, the certificate 411 message shall provide a valid certificate chain leading to an 412 acceptable certificate authority. They are responsible for verifying 413 that the other's certificate is valid and has not expired or been 414 revoked. When the pre-shared keys (PSK) are chosen to authenticate 415 each other, there are three sets of ciphersuits specified in 416 [RFC4279] for supporting authentication based on pre-shared keys. 417 The first set of ciphersuites uses only symmetric key operations for 418 authentication, the second set uses a Diffie-Hellman exchange 419 authenticated with PSK, and the last set combines public key (RSA) 420 authentication of database with PSK authentication of the master 421 device. 423 2)The other situation is that only unilateral authentication is 424 needed in TLS handshake protocol when the master device 425 authentication is running within TLS secure tunnel. The 426 authentication procedure using mixed mode is given in figure 1. In 427 this scene, the database is authenticated using a valid certificate 428 signed by a trusted certificate authority. When the TLS tunnel is 429 established, the protocol used to authenticate the master device is 430 tunneled within the existing TLS tunnel. The credential of the 431 master device can also be the pre-shared key or certificate or some 432 other schemes. Legacy protocols provide a preferred means for master 433 device authentication due to their existing key management 434 infrastructure and widespread deployment. However, when run in the 435 open environment they may be vulnerable to identity spoofing and 436 other attacks against protocol exchange messages. In practical 437 situations, this mixed mode usage is not recommended because of its 438 possibility to lead in a man-in-the-middle attack, as noted in 439 [RFC4169]. 441 +-------------+ +--------+ 442 |master device| |database| 443 +-----+-------+ +----+---+ 444 | | 445 |-----|--------------------------------------|------| 446 | Establishing a TLS tunnel(database authenticated) | 447 | |------------------------------------->| | 448 | | | | 449 | |<---TLS-protocol based on database--->| | 450 | | | | 451 | |<------Request/Identity message-------| | 452 |-----|--------------------------------------|------| 453 |-----|--------------------------------------|------| 454 | |Secured by TLS tunnel | | 455 | |<----legacy protocol for master------>| | 456 | | device authentication | | 457 |-----|--------------------------------------|------| 458 | | 459 | | 461 Figure 1: Mater device is authenticated by database using a mixed 462 mode 464 2. Master device is authenticated by RBWS 466 In this case, the credential of master device shall be authenticated 467 by RBWS through the TLS secure tunnel or in procedure of the TLS 468 handshake protocol. The notable difference between the two cases is 469 that the credential of master device shall be transported to RBWS by 470 database which is connected to the RBWS in latter case. The data 471 transport between the database and RBWS shall be protected which is 472 out of the scope of this document. It also contains two possible 473 authentication architectures: one is that mutual authentication 474 implementing in TLS establishment procedure, the other is using a 475 mixed mode which procedure can be depicted in figure 2. 477 +-------------+ +--------+ +----+ 478 |master device| |database| |RBWS| 479 +-----+-------+ +----+---+ +--+-+ 480 | | | 481 |------|-------------------------------------|-------| | 482 | establishing a TLS tunnel(database authenticated) | | 483 | |------------------------------------>| | | 484 | | | | | 485 | |<---TLS-protocol based on database-->| | | 486 | | certificate | | | 487 | | | | | 488 | |<-----Request/Identity message-------| | | 489 |------|-------------------------------------|-------| | 490 | | | 491 |------|-------------------------------------|-----------|--| 492 | |Secured by TLS tunnel | | | 493 | | | | | 494 | |<------ Lagency protocol formaster device------->| | 495 | | authentication | | | 496 |------|-------------------------------------|-----------|--| 497 | | | 499 Figure 1: Mater device is authenticated by RBWS using a mixed mode 501 3. Analysis of methods for master device authentication 503 In section 5.3.2, the master device can be authenticated by using 504 symmetric pre-shared keys (PSKs) or by certificates. In the PSK 505 case, the shared key needs to be configured in advance among the 506 master device and the database or RBWS. When the PSK authentication 507 is selected, the certificate and the certificate request payloads are 508 omitted from the response; In the certificate case, the master device 509 can obtain a certificate through the enrolment procedure or pre- 510 configured. The master device may enroll a device certificate 511 according the certificate enrolment procedure prior to communicate 512 with a proper database, the certificate may then be used for 513 establishing a secure channel between the master device and database. 514 The use of certificates has advantage that there is a standardized 515 procedure for enrolling the private key corresponding to the 516 certificate while the use of the PSK requires manual operation in 517 general for establishing the PSK. The manually provisioned symmetric 518 keys will severely limit the ability for master device to flexibly 519 move from one database provider to another. However, on the other 520 hand, the use of a PSK has the advantage that no PKI is required and 521 the procedure after pre-establishment of PSK is simple. 523 5.3.3. Drawbacks of TLS Protocol 525 Because the TLS runs over TCP, it is susceptible to a number of 526 denial-of-service (DoS) attacks. An attacker who initiates a large 527 number of TCP connections can consume lots of computation resources 528 of a server by doing RSA decryption. Besides, attackers can forge 529 TCP packets such as RSTs etc. or forge partial TLS records to 530 terminate connections. In this case, implementers or users who are 531 concerned with this class of attack should use IPsec. 533 6. Security Considerations 535 All contents of this document are dealing with security. 537 7. IANA Considerations 539 There have been no IANA considerations so far in this document. 541 8. Acknowledgments 543 Thanks to Lei Zhu, Peter McCann and Xinpeng Wei for their sincerely 544 help and comments when drafting this document. 546 9. Normative Reference 548 [I-D.ietf-paws-problem-stmt-usecases-rqmts] 549 Probasco, S. and B. Patil, "Protocol to Access White Space 550 database: PS, use cases and rqmts", 551 draft-ietf-paws-problem-stmt-usecases-rqmts-03 (work in 552 progress), February 2012. 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext 558 Transfer Protocol (HTTP) Digest Authentication Using 559 Authentication and Key Agreement (AKA) Version-2", 560 RFC 4169, November 2005. 562 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 563 for Transport Layer Security (TLS)", RFC 4279, 564 December 2005. 566 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 567 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 569 Authors' Addresses 571 Yizhuang Wu 572 Huawei Technologies 574 Email: wuyizhuang@huawei.com 576 Yang Cui 577 Huawei Technologies 579 Email: cuiyang@huawei.com