Internet DRAFT - draft-wu-paws-secutity

draft-wu-paws-secutity






PAWS                                                               Y. Wu
Internet-Draft                                                    Y. Cui
Intended status: Informational                                    Huawei
Expires: April 25, 2013                                 October 22, 2012


    Protocol to Access White Space Database:Security Considerations
                     draft-wu-paws-secutity-01.txt

Abstract

   This document analyses common security threats of the Protocol to
   Access White Space database (PAWS), and describes their potential
   impacts on message exchanges between master device and white space
   database when implementing PAWS.  Meanwhile, the corresponding
   countermeasures are also introduced in this document.  The PAWS is
   used for retrieving the available white space information at a given
   location and time from a white space database.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Wu & Cui                 Expires April 25, 2013                 [Page 1]

Internet-Draft        PAWS security considerations          October 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and terminology  . . . . . . . . . . . . . . . . .  3
     2.1.  Conventions used in this Document  . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  PAWS Security Threat Overview  . . . . . . . . . . . . . . . .  4
   4.  Detailed Threat Description  . . . . . . . . . . . . . . . . .  4
     4.1.  Impersonation of Master Device . . . . . . . . . . . . . .  4
     4.2.  Impersonation of Database  . . . . . . . . . . . . . . . .  5
     4.3.  MitM Attack between Master Device and Database . . . . . .  5
     4.4.  Attacks on the Link of master Device and Database  . . . .  5
     4.5.  Attacks on the Master Device Itself  . . . . . . . . . . .  6
     4.6.  Other Potential attacks(To Be Added) . . . . . . . . . . .  6
   5.  Security Schemes . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Security Countermeasures . . . . . . . . . . . . . . . . .  6
     5.2.  Security Features  . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Analysis of Security Schemes . . . . . . . . . . . . . . .  7
       5.3.1.  Brief Introdution of TLS Protocol  . . . . . . . . . .  7
       5.3.2.  Mutual Authentication  . . . . . . . . . . . . . . . .  9
       5.3.3.  Drawbacks of TLS Protocol  . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Normative Reference  . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13









Wu & Cui                 Expires April 25, 2013                 [Page 2]

Internet-Draft        PAWS security considerations          October 2012


1.  Introduction

   Portions of the radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  To maximize utilization of these
   white space spectrum, the concept of allowing secondary transmissions
   (licensed or unlicensed) in these spectrum is proposed.  The widely
   accepted approach of sharing white space spectrum without
   interference is by querying the database and the corresponding
   protocol "Protocol to Access White space database" is defined.

   In PAWS protocol, a master device connects to a database using White
   Space (WS) interface.  There are much sensitive information, such as
   location information and/or identities of master devices, which MAY
   be transmitted between the WS interface of the master device and the
   database when the PAWS is implemented.  If an attacker can have full
   access to the network medium between the master device and the
   database, the attacker may deploy varieties of attacks on the network
   using the sensitive information if there is lack of suitable security
   mechanism.Therefore, the messaging interface between the master
   device and the database needs to be secured.  Meanwhile, to guarantee
   a legitimate and authorized master device connects to the proper
   database, the mutual authentication is required before the security
   association established.

   In this document, the security threats, the security features and the
   security mechanism for protecting the PAWS are discussed in details.


2.  Conventions and terminology

2.1.  Conventions used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT","RECOMMEND", "MAY", and "OPTIONANL" that
   appear in this document are to be interpreted as described in
   [RFC2119].

2.2.  Terminology

   The Terminology Section of the latest version of [I-D.ietf-paws-
   problem-stmt-usecases-rqmts] shall be included by reference.

   WS interface

   The interface between master device and Database specifies data model
   and process of PAWS in this document.




Wu & Cui                 Expires April 25, 2013                 [Page 3]

Internet-Draft        PAWS security considerations          October 2012


   Database or white space database

   That provides white space spectrum information to master device.

   Master device

   A device is able to query a database for available white space
   spectrum using location information.


3.  PAWS Security Threat Overview

   PAWS protocol defines an approach to share the white space spectrum
   for secondary transmissions, enabling a master device to acquire
   available white space spectrum information from a database, and
   specifies the use of HTTP/TLS as transport for the protocol.

   According to PAWS protocol, a master device sends a request that
   contains its location information and any parameters required by the
   regulatory rules (such as device identifier, capabilities, and
   characteristics) to database for the available spectrum.  If the
   request is valid, the database returns a response that includes an
   available frequency list and related information.

   An adversary has several way of harming this progress: it can
   masquerade as another valid device, eavesdrop on any communications
   between the master device and the database, and replay or modify the
   request or response message and so on.  These attacks are presented
   in detail in section 4.

   The different ways of attacking this querying progress may eventually
   lead to unauthorized use of channels by an uncertified device, an
   authorized device receives a malicious response and result in the
   master device causing interference to primary user of the spectrum,
   tracking of master device locations and identity.


4.  Detailed Threat Description

   For each threat, described in the below, a description of the
   corresponding attack is given as follows.

4.1.  Impersonation of Master Device

   If there is no authentication of the master device, the white space
   database cannot detect the rogue master device, and the available
   white space channel list will be passed to the Rogue master device.
   This enables a rogue master device to use the available channels.



Wu & Cui                 Expires April 25, 2013                 [Page 4]

Internet-Draft        PAWS security considerations          October 2012


   Besides, the rogue master device can connect to the white space
   database by using the registration exchanges, the DoS type attacks
   may be initiated.  This shows that it is essential to perform some
   type of authentication of master device.

4.2.  Impersonation of Database

   If there is no authentication of the database, an attacker may
   attempt to spoof a white space database and provide responses to a
   master device which are malicious and result in the master device
   causing interference to the primary user of the spectrum.  At the
   same time, the attacker also can retrieve an available white space
   channel list from a legal database using the registration exchanges,
   which received from the authorized master device.

4.3.  MitM Attack between Master Device and Database

   A man in the middle (MitM) node is inserted between the master device
   and database, which can be considered to be a variant of the above
   attacks.  The real master device will connect to the MitM node and
   the MitM node can connect to the real database.  The MitM node can
   transparently transmit, receive, view, and modify the traffic between
   the real master device and the database without either of those nodes
   being aware of it.  The important security point illustrated by this
   attack is that not only is it essential to perform mutual
   authentication of the master device and the white space database, it
   is important to ensure that all security tunnels from the master
   device terminate in the trusted white space database instead of in a
   MitM node.

4.4.  Attacks on the Link of master Device and Database

   The link between the master device and the white space database can
   be wired or wireless.  An attacker may wiretap the communication
   between a valid master device and database.  The threats are as
   follows:

   1) Steal the confidential data transmitted in the packet payload,
   such as utilize the information about available channels by utilizing
   those channels.  The result of such an attack is unauthorized use of
   channels by an unauthorized device.

   2) The location/identity information can be gleaned by an
   eavesdropper and be used for tracking purposes.

   3) An attacker could falsify the communication between the master
   device and the database.  The channel information and some other type
   parameters could be modified by an attacker which may result in



Wu & Cui                 Expires April 25, 2013                 [Page 5]

Internet-Draft        PAWS security considerations          October 2012


   interference to the primary user of that channel.  Alternatively the
   attacker may indicate no channel availability at a location resulting
   in a denial of service to the master device.

4.5.  Attacks on the Master Device Itself

   The master device may be deployed in vulnerable locations, and the
   less trusted types of transmission links will be used to interconnect
   that equipment to the database.  Breaking the master device to get
   sensitive data is theoretically possible.  The attacker may dig out
   the master device-database shared secret or a long term certificate
   from the master device and tries to add another master device.

4.6.  Other Potential attacks(To Be Added)


5.  Security Schemes

5.1.  Security Countermeasures

   To mitigate the above threats, the security countermeasures below
   should be used.  Namely:

   1) The master device shall be authenticated based on a globally
   unique and permanent master device identity before it can obtain the
   service from a suitable database.

   2) The master device shall authenticate the identity of database to
   guarantee the connected database is proper.

   3) The master device and the white space database shall also check
   that both of them are authorized by the regulator body of white
   space.

   4) Sensitive data including authentication credentials, user
   information, cryptographic keys shall not be transmitted between the
   master device and the white space database in plaintext in
   unauthorized access.  It means that the transport of data over the
   interface between the master device and the database shall be
   integrity, confidentiality, and replay protected from unauthorized
   access.

   5) The master device should have a secure module to store long term
   keys or certificates.  The identity of master device could be stored
   in a trusted physical module and/or a possible non-removable
   smartcard.





Wu & Cui                 Expires April 25, 2013                 [Page 6]

Internet-Draft        PAWS security considerations          October 2012


5.2.  Security Features

   To satisfy the security countermeasures, the security mechanism shall
   be able to provide the following features:

   1) Mutual authentication

   Mutual authentication between the master device and the database
   shall be performed before the service can be transmitted using
   certificates or pre-shared keys or some other methods.  Besides, the
   database shall further check whether the master device is authorized
   by Regulatory Body of White Space (RBWS) due to the fact that some
   device may be not allowed to use the white space spectrum.  The
   credentials and critical security functions for authentication shall
   be protected inside physically secure environment, such as Trusted
   Environment (TrE).

   2) The protection mechanisms of the data

   The data over the interface between the master device and the
   database shall be protected for integrity, confidentiality and anti-
   replay from unauthorized parties.

   3) Trusted environment

   The TrE shall be a logical entity which provides a trustworthy
   environment for the execution of sensitive functions and the storage
   of sensitive data.  All data produced through execution of functions
   within the TrE shall be unknowable to unauthorized external entities.

5.3.  Analysis of Security Schemes

   There are several possible alternative schemes can be considered to
   provide the security features detailed in section 5.2, such as TLS
   and IPsec.  In this document only TLS is introduced due to the fact
   that the HTTP protocol is used for PAWS and the cost of IPsec is
   higher.

5.3.1.  Brief Introdution of TLS Protocol

   TLS protocol provides the communications privacy over the internet
   which is composed of two layers: the TLS Record Protocol and the TLS
   Handshake Protocol.

   1) The TLS Handshake Protocol is responsible for negotiating a
   session, which is used to allow peers to agree upon security
   parameters for the record layer, authenticate themselves, instantiate
   negotiated security parameters, and report error conditions to each



Wu & Cui                 Expires April 25, 2013                 [Page 7]

Internet-Draft        PAWS security considerations          October 2012


   other.

   a)The peer's identity can be authenticated using asymmetric, or
   public key, cryptography (e.g., RSA, DSA, etc).  X509 certificate is
   recommended.  When the certificate is used to authenticate the
   identity of the entity, each party shall verify the other's
   certificate whether it is valid and has not expired or revoked.

   b)According the [RFC5246], RSA or Diffie-Hellman can be used for
   authentication and key exchange.

   c)A pre_master_secret is created by key exchange process in TLS
   handshake protocol, which will be used to generate the master_secret.
   The master secret is required to generate the encryption keys and
   integrity keys.

   2) The TLS Record Protocol takes messages to be transmitted,
   fragments the data into manageable blocks, optionally compresses the
   data, applies a MAC, encrypts, and transmits the result.  Received
   data is decrypted, verified, decompressed, and reassembled, then
   delivered to higher level clients.  Two basic security properties are
   as follows:

   a)Confidentiality: symmetric cryptography is used for data encryption
   (e.g., AES, etc).  The derivation of encryption keys are based on a
   secret negotiated by the TLS handshake protocol.

   b)Integrity: A keyed MAC is used to message integrity check.  Secure
   hash functions (e.g., SHA-1, etc) are used for MAC generated.

   When the TLS protocol is choose to protect the communication, all
   HTTP data between master device and the white space database must be
   sent as TLS "application data".  Normal HTTP behavior should be
   followed.  It means that security association shall be set up by
   using TLS protocol before establishment of the HTTP connection.  The
   master device acting as the HTTP client should also act as the TLS
   client.  It should initiate a connection to the white space database
   on the appropriate port and then sent the TLS ClientHello to begin
   the TLS handshake.

   The following TLS handshake procedures shall be implemented first
   before the master device contacts to the database using a well-
   defined access method when it has determined a relevant white space
   database.

   a)The first stage: security capabilities including protocol version,
   session ID, cipher suite, compression method, and initial random
   numbers are established;



Wu & Cui                 Expires April 25, 2013                 [Page 8]

Internet-Draft        PAWS security considerations          October 2012


   b)The second stage: certificate of the database, key exchange, and
   request certificate shall be sent by database;

   c)The third phase: master device sends certificate if requested.  Key
   exchange and certificate verification may be sent by master device;

   d)The last phase: change cipher suite and finish handshake protocol.

   In above procedure, the database server shall be authenticated,
   whether the master device is authenticated or not in TLS handshake
   protocol should be considered separately in the below.

5.3.2.  Mutual Authentication

   For business reasons or ease of management, databases may be deployed
   by a different third-party that is authorized by RBWS.  And the
   master devices are deployed by the third-party and authorized by the
   RBWS to use the white space spectrum.  For this reason, there may be
   two cases needed to consider how the master device authentication
   should be implemented because the RBWS may not allow the database to
   do this.  One case is that the credential of the master device is
   authenticated by the database, and the other case is that the RBWS
   insures whether the master device is a valid device.  The nuts and
   bolts of these two architectures are described as follows:

   1.  Master device is authenticated by database

   At this situation, the mutual authentication will be implemented
   between the master device and database.  How the identity of master
   device is authenticated can be divided into following two situations.

   1)if only a legal master device is able to connect to the database,
   the database can determine whether a device is a master device or
   not, then the mutual authentication should be finished in procedure
   of TLS secure channel establishment for ease of operating.  When the
   certificates are used to authenticate each other, the certificate
   message shall provide a valid certificate chain leading to an
   acceptable certificate authority.  They are responsible for verifying
   that the other's certificate is valid and has not expired or been
   revoked.  When the pre-shared keys (PSK) are chosen to authenticate
   each other, there are three sets of ciphersuits specified in
   [RFC4279] for supporting authentication based on pre-shared keys.
   The first set of ciphersuites uses only symmetric key operations for
   authentication, the second set uses a Diffie-Hellman exchange
   authenticated with PSK, and the last set combines public key (RSA)
   authentication of database with PSK authentication of the master
   device.




Wu & Cui                 Expires April 25, 2013                 [Page 9]

Internet-Draft        PAWS security considerations          October 2012


   2)The other situation is that only unilateral authentication is
   needed in TLS handshake protocol when the master device
   authentication is running within TLS secure tunnel.  The
   authentication procedure using mixed mode is given in figure 1.  In
   this scene, the database is authenticated using a valid certificate
   signed by a trusted certificate authority.  When the TLS tunnel is
   established, the protocol used to authenticate the master device is
   tunneled within the existing TLS tunnel.  The credential of the
   master device can also be the pre-shared key or certificate or some
   other schemes.  Legacy protocols provide a preferred means for master
   device authentication due to their existing key management
   infrastructure and widespread deployment.  However, when run in the
   open environment they may be vulnerable to identity spoofing and
   other attacks against protocol exchange messages.  In practical
   situations, this mixed mode usage is not recommended because of its
   possibility to lead in a man-in-the-middle attack, as noted in
   [RFC4169].

               +-------------+                         +--------+
               |master device|                         |database|
               +-----+-------+                         +----+---+
                     |                                      |
               |-----|--------------------------------------|------|
               | Establishing a TLS tunnel(database authenticated) |
               |     |------------------------------------->|      |
               |     |                                      |      |
               |     |<---TLS-protocol based on database--->|      |
               |     |                                      |      |
               |     |<------Request/Identity message-------|      |
               |-----|--------------------------------------|------|
               |-----|--------------------------------------|------|
               |     |Secured by TLS tunnel                 |      |
               |     |<----legacy protocol for master------>|      |
               |     |        device authentication         |      |
               |-----|--------------------------------------|------|
                     |                                      |
                     |                                      |


     Figure 1: Mater device is authenticated by database using a mixed
                                   mode

   2.  Master device is authenticated by RBWS

   In this case, the credential of master device shall be authenticated
   by RBWS through the TLS secure tunnel or in procedure of the TLS
   handshake protocol.  The notable difference between the two cases is
   that the credential of master device shall be transported to RBWS by



Wu & Cui                 Expires April 25, 2013                [Page 10]

Internet-Draft        PAWS security considerations          October 2012


   database which is connected to the RBWS in latter case.  The data
   transport between the database and RBWS shall be protected which is
   out of the scope of this document.  It also contains two possible
   authentication architectures: one is that mutual authentication
   implementing in TLS establishment procedure, the other is using a
   mixed mode which procedure can be depicted in figure 2.

         +-------------+                         +--------+    +----+
         |master device|                         |database|    |RBWS|
         +-----+-------+                         +----+---+    +--+-+
                |                                     |           |
         |------|-------------------------------------|-------|   |
         | establishing a TLS tunnel(database authenticated)  |   |
         |      |------------------------------------>|       |   |
         |      |                                     |       |   |
         |      |<---TLS-protocol based on database-->|       |   |
         |      |             certificate             |       |   |
         |      |                                     |       |   |
         |      |<-----Request/Identity message-------|       |   |
         |------|-------------------------------------|-------|   |
                |                                     |           |
         |------|-------------------------------------|-----------|--|
         |      |Secured by TLS tunnel                |           |  |
         |      |                                     |           |  |
         |      |<------ Lagency protocol formaster device------->|  |
         |      |                   authentication    |           |  |
         |------|-------------------------------------|-----------|--|
                |                                     |           |


    Figure 1: Mater device is authenticated by RBWS using a mixed mode

   3.  Analysis of methods for master device authentication

   In section 5.3.2, the master device can be authenticated by using
   symmetric pre-shared keys (PSKs) or by certificates.  In the PSK
   case, the shared key needs to be configured in advance among the
   master device and the database or RBWS.  When the PSK authentication
   is selected, the certificate and the certificate request payloads are
   omitted from the response; In the certificate case, the master device
   can obtain a certificate through the enrolment procedure or pre-
   configured.  The master device may enroll a device certificate
   according the certificate enrolment procedure prior to communicate
   with a proper database, the certificate may then be used for
   establishing a secure channel between the master device and database.
   The use of certificates has advantage that there is a standardized
   procedure for enrolling the private key corresponding to the
   certificate while the use of the PSK requires manual operation in



Wu & Cui                 Expires April 25, 2013                [Page 11]

Internet-Draft        PAWS security considerations          October 2012


   general for establishing the PSK.  The manually provisioned symmetric
   keys will severely limit the ability for master device to flexibly
   move from one database provider to another.  However, on the other
   hand, the use of a PSK has the advantage that no PKI is required and
   the procedure after pre-establishment of PSK is simple.

5.3.3.  Drawbacks of TLS Protocol

   Because the TLS runs over TCP, it is susceptible to a number of
   denial-of-service (DoS) attacks.  An attacker who initiates a large
   number of TCP connections can consume lots of computation resources
   of a server by doing RSA decryption.  Besides, attackers can forge
   TCP packets such as RSTs etc. or forge partial TLS records to
   terminate connections.  In this case, implementers or users who are
   concerned with this class of attack should use IPsec.


6.  Security Considerations

   All contents of this document are dealing with security.


7.  IANA Considerations

   There have been no IANA considerations so far in this document.


8.  Acknowledgments

   Thanks to Lei Zhu, Peter McCann and Xinpeng Wei for their sincerely
   help and comments when drafting this document.


9.  Normative Reference

   [I-D.ietf-paws-problem-stmt-usecases-rqmts]
              Probasco, S. and B. Patil, "Protocol to Access White Space
              database: PS, use cases and rqmts",
              draft-ietf-paws-problem-stmt-usecases-rqmts-03 (work in
              progress), February 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4169]  Torvinen, V., Arkko, J., and M. Naslund, "Hypertext
              Transfer Protocol (HTTP) Digest Authentication Using
              Authentication and Key Agreement (AKA) Version-2",
              RFC 4169, November 2005.



Wu & Cui                 Expires April 25, 2013                [Page 12]

Internet-Draft        PAWS security considerations          October 2012


   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", RFC 4279,
              December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Authors' Addresses

   Yizhuang Wu
   Huawei Technologies

   Email: wuyizhuang@huawei.com


   Yang Cui
   Huawei Technologies

   Email: cuiyang@huawei.com































Wu & Cui                 Expires April 25, 2013                [Page 13]