Protocol to Access White Space database: security considerations
draft-wu-paws-secutity-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yizhuang Wu, Yang Cui | ||
| Last updated | 2012-07-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-paws-secutity-00
PAWS Y. Wu
Internet-Draft Y. Cui
Intended status: Informational Huawei
Expires: January 10, 2013 July 9, 2012
Protocol to Access White Space database: security considerations
draft-wu-paws-secutity-00.txt
Abstract
PAWS is an access protocol between the Master device and the White
Space(WS) Database. Master Devices connect to the white space
database directly using WS interface,but only authorized devices can
get the service from database.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 if there is
lack of security mechanism.
The present document describes the security threats to the current
framework of PAWS, and meanwhile proposes the corresponding
countermeasures.
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 January 10, 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
Wu & Cui Expires January 10, 2013 [Page 1]
Internet-Draft PAWS security considerations July 2012
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
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.
Wu & Cui Expires January 10, 2013 [Page 2]
Internet-Draft PAWS security considerations July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions used in this Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Security threats and Requirements . . . . . . . . 5
3.1. Fundamental system architecture of PAWS . . . . . . . . . 5
3.2. Security threats . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Impersonation of a master device . . . . . . . . . . . 6
3.2.2. Impersonation of database . . . . . . . . . . . . . . 6
3.2.3. MitM on the interface between master device and
database . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.4. Attacks on the link of interface between master
device and database . . . . . . . . . . . . . . . . . 6
3.2.5. Attacks on the master device itself . . . . . . . . . 7
3.2.6. Other potential attacks(To be added) . . . . . . . . . 7
3.3. Security countermeasures . . . . . . . . . . . . . . . . . 7
4. Security schemes . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Analysis of security schemes . . . . . . . . . . . . . . . 8
4.2.1. Databases deployed by third-party . . . . . . . . . . 8
4.2.2. Databases deployed by regulatory body of white
space . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. TLS protocol . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Brief introduction of TLS protocol . . . . . . . . . . 13
4.3.2. Security establishment procedure between master
device and database . . . . . . . . . . . . . . . . . 13
4.3.3. Drawbacks of TLS protocol . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative Reference . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Wu & Cui Expires January 10, 2013 [Page 3]
Internet-Draft PAWS security considerations July 2012
1. Introduction
Portions of the radio spectrums that are allocated to a licensed,
primary user but are unused or unoccupied at specific locations and
times are defined as "white space". The concept of allowing
secondary transmissions (licensed or unlicensed) in white space is a
technique to "unlock" existing spectrum. Currently, the widely
accepted scheme of utilizing white space is by querying the database
and the related protocol "Protocol to Access White Space database
(PAWS)" is proposed.
Entities of master device and Database, the interface between the two
entities would have been defined in PAWS. There are much sensitive
information, such as location and identity of master devices, which
MAY be transmitted between the interface of the master device and the
white space database when the PAWS is used. Attackers are able to
make various types of attack by using the sensitive information if
there is lack of security mechanism. Therefore, the messaging
interface between the master device and the database needs to be
secured. Meanwhile, the two entities SHALL be mutually authenticated
and they both MUST be authorized by authority of white space
management institution.
In this document, the security threats, the security features and the
security mechanism(TLS) 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 January 10, 2013 [Page 4]
Internet-Draft PAWS security considerations July 2012
3. Overview of Security threats and Requirements
3.1. Fundamental system architecture of PAWS
Figure 1 shows a common system model of PAWS, the master device is
connected to internet by any means other than using the white space
radio. More details of PAWS are described using the following steps:
\|/ ----------
| .---. |Database|
| ( ) /---------
|-|---------| / \ /
| Master | ( Internet )
| device |========( insecure )
|-----------| \ link) /
( )
(----)
Figure 1: system architecture of PAWS
Description of system architecture:
1) The master device needs to discover white space database in the
relevant regulatory domain by connecting to the internet by any means
other than using the white space radio.
2) The master device will connect to the white space database, the
link between master device and the white space database can be wired
or wireless and provide IP connectivity, which may be insecure.
3) The master device may register with the white space database
before the white space database provides information on available
white space radio channels according to regulatory domain
requirements. The information used in registration may include, but
is not limited to, the device ID, the device's location, serial
number assigned by the manufacturer and so on.
4) The master device queries the white space database for available
white space channel lists.
3.2. Security threats
If there is lack of security mechanism in above PAWS architecture,
various threats detailed in "ietf-paws-problem-stmt-use-cases-rqmts"
may exist, and the corresponding attacks can be deployed. It can be
summarized as follows from a security point of view:
Wu & Cui Expires January 10, 2013 [Page 5]
Internet-Draft PAWS security considerations July 2012
3.2.1. Impersonation of a 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.
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.
3.2.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 master device.
3.2.3. MitM on the interface between master device and database
A man in the middle (MitM) node is inserted in between the master
device and database, it 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.
3.2.4. Attacks on the link of interface between master device and
database
The link between the master device and the white space database can
be wired or wireless. An attacker may listen to the communication
between a valid master device and database. The threats of this are
as follows:
1) Steal the confidentiality of 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.
Wu & Cui Expires January 10, 2013 [Page 6]
Internet-Draft PAWS security considerations July 2012
2) The location/identity information can be gleaned by an
eavesdropper and be used for tracking purposes.
3) An attacker could modify 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
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.
3.2.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.
3.2.6. Other potential attacks(To be added)
3.3. Security countermeasures
To mitigate the above threats, the security countermeasures below
should be used. Namely:
1) The master device shall be authenticated by database based on a
globally unique and permanent master device identity when it wants to
establish connection with the database.
2) The master device shall authenticate the identity of database.
3) The master device and the white space database shall 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, confidentially, and replay protected from unauthorized.
5) The master device should have a secure module to store long term
key or certificate. The identity of master device could be stored in
a trusted physical module and/or a possible non-removable smartcard.
Wu & Cui Expires January 10, 2013 [Page 7]
Internet-Draft PAWS security considerations July 2012
4. Security schemes
4.1. Overview
According to the previous analysis, the security mechanism shall be
able to provide the following security features:
1) Mutual authentication
Mutual authentication between the master device and the database
shall be performed using certificates or pre-shared keys and so on.
Besides, the master device and the database shall further be
authenticated by the authority of regulatory body of white space to
ensure that they are both authorized by regulatory body of white
space due to the fact that the database may not be deployed by
regulatory body of white space. 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.
4.2. Analysis of security schemes
For business reasons or ease of management, databases may be deployed
by different third-party that is authorized by regulatory body of
white space. It means that there are two possible deployment cases:
one is that the databases deployed by the third-party which are
authorized by regulatory body of white space; the other is that the
databases are directly deployed by regulatory body of white space.
4.2.1. Databases deployed by third-party
In this scene, when the master device wants to query the database for
an available white space list, it shall be able to connect to the
database and also be authorized by regulatory body of white space to
use white space. It means that twice authentications shall be
implemented, two suits of credentials are stored in master device and
Wu & Cui Expires January 10, 2013 [Page 8]
Internet-Draft PAWS security considerations July 2012
white space database which are provided by different trusted
authorities. There are two possible authentication models which are
showed as follow:
Model 1
+-----------------------------------------------+
| The credentials of master device and database |
| which is used for the first authentication are|
| provided by trusted authority of third-party |
+-----------------------------------------------+
/
/
+--------+ / +--------+ +------+
| master |-------------| |------------| |
| |<---secure-->|Database|<---------->| RBWS |
| device |-----\-------| |-------/----| |
+--------+ \ +--------+ / +------+
\ /
\ /
+--------------------------------------------------+
| Through the secure channel,the authentication |
| information will be provided to database and then|
| forward to RBWS for the second authentication |
+--------------------------------------------------+
Figure 2: authentication model 1
In this model, the credentials of the master device and the database
for second authentication both shall be checked by authority of RBWS
after the master device successfully access to the white space
database whenever the master device query the database, but what the
database needs to do is able to establish connection with authority
of regulatory body of white space (RBWS).
Under this circumstance, the whole querying procedure of white space
channels can be showed as followed:
Wu & Cui Expires January 10, 2013 [Page 9]
Internet-Draft PAWS security considerations July 2012
+-------------+ +--------+ +----+
|master device| |database| |RBWS|
+-----+-------+ +----+---+ +--+-+
| | |
+---------------+ | first authentication | authorization |
| secure channel| /-->|<--------------------->| of database |
| established |/ | |<---------------->|
+---------------+ | authorization of|master device |
|<--------------------->|<---------------->|
+------------------+ /| | |
|authentication and| / | registration(optional)| |
|authorized by RBWS|/ |<--------------------->| |
+------------------+ | | |
| white space channel | |
| query | |
|<--------------------->| |
| | |
| | |
Figure 3: procedure of querying database
Firstly, the mutual authentication between the master device and the
database shall be supported based on the credentials which are
provided by an authority trusted by the third-party, e.g. the
authority of third-party or by another party trusted by the third-
party. Only the master device which has credentials with the third-
party that deployed the database can connect to the database. And
the master device also shall evaluate the connected database if it is
a trusted database where the master device is able to register and
receive service from the database. Namely the secure connectivity
between the master device and the database shall be established first
before the master device can query the available white space from the
database.
Secondly, following the above successful mutual authentication
between the master device and the database, they both shall also be
authenticated and authorized by regulatory body of white space. The
master device provides the information for authentication to database
through the WS interface and then forward to regulatory body of white
space by database. The credentials used for secondary authentication
shall be provided by authority trusted by regulatory body of white
space, e.g. the authority of regulatory body of white space or by
another party trusted by the regulatory body of white space.
Finally, only when the twice mutual authentications are both passed,
Wu & Cui Expires January 10, 2013 [Page 10]
Internet-Draft PAWS security considerations July 2012
the master device can query the database for available white space
channels.
In addition, the information which is used for second authentication
or for registration may be transmitted between master device and
database after the first successful authentication, these information
may contain sensitive data which shall not be known by others. So
the secure channel shall be established after the first
authentication which is used to provide security protection. The
master device and the database shall not engage in any communication
prior to the completion of the establishment of the secure channel
other than messages for establishing the secure channel.
Model 2
+-----------------------------------------------+
| The credentials of master device and database |
| which is used for the first authentication are|
| provided by trusted authority of third-party |
+-----------------------------------------------+
/
/
+--------+ / +--------+
| master |----------------------| |
| |<--------secure------>|Database|
| device |--------------\-------| |
+--------+ \ +--------+
\ \ /
\ \ /
\ \ /
\ \/+--------------------------+
\ +----------+ /\|The authorized information|
| RBWS | |assigned by RBWS will be |
+----------+ |exchanged after the second|
|successful authentication |
+--------------------------+
Figure 4: authentication model 2
In this model, the master device and database both can connect to
regulatory body of white space.
On this occasion, the credentials provided by trusted authority of
third-party are used to mutual authentication between the master
device and the database first. The master device and the white space
database must establish connection with RSWB respectively and
authenticated by the authority of RBWS when the previous mutual
Wu & Cui Expires January 10, 2013 [Page 11]
Internet-Draft PAWS security considerations July 2012
authentication is successful. Then the master device and database
shall check whether the authorized information assigned by regulatory
body of white space will be exchanged through the WS interface is
legal. Only the two authentication procedures are both successful,
the master device is able to query the database for available white
space channel.
4.2.2. Databases deployed by regulatory body of white space
In this scenario, the master device can directly query the connected
database for available white space lists when it is able to connect
to the trusted database due to the fact that the databases are
deployed by regulatory body of white space and the management of
white space is also by regulatory body of white space. Only one
credentials are needed, the credentials used to mutual authentication
between master device and database can be assigned by trusted
authority of regulatory body of white space, e.g. the authority of
regulatory body of white space or by another party trusted by the
regulatory body of white space. The security model can be showed as
followed:
+-----------------------------------------------+
| The credentials of master device and database |
| which is used for authentication are provided |
| by trusted authority of RBWS |
+-----------------------------------------------+
/
/
+--------+ / +--------+
| master |----------------------| |
| |<--------secure------>|Database|
| device |----------------------| |
+--------+ +--------+
Figure 5: authentication model 3
After the successful mutual authentication, the secure channel shall
be established to protect the communication between the master device
and the database. The master device and the database shall not
engage in any communication prior to the completion of the
establishment of the secure channel other than messages for
establishing the secure channel.
The TLS protocol depicted in section 4.3 can be considered to
establish the secure channel according to the above analysis.The
alternative security scheme IPsec can also be used in PAWS. But
since TCP and HTTP protocol are recommended to use for PAWS, only the
Wu & Cui Expires January 10, 2013 [Page 12]
Internet-Draft PAWS security considerations July 2012
TLS is introduced in this document.
4.3. TLS protocol
4.3.1. Brief introduction 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
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.
4.3.2. Security establishment procedure between master device and
database
In related reference of PAWS, TCP and HTTP are recommended to be used
Wu & Cui Expires January 10, 2013 [Page 13]
Internet-Draft PAWS security considerations July 2012
to load the messages in the interface between the master device and
the database.
When the TLS protocol is used, 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, and the mutual authentication
shall be implemented in TLS protocol.
The following procedures shall be implemented first before the master
device contacts to the database using a well-defined access method
when it has determined the relevant white space database.
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.
1) The procedure of TLS handshake protocol can be described as
follows which is based on the [RFC5246]GBP[not]it contains four
stages:
a) The first stage: security capabilities including protocol version,
session ID, cipher suite, compression method, and initial random
numbers are established
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
2) Authentication methods
In above establishment procedure of TLS secure channel, Public key
certificates or symmetric keys (namely pre-shared keys or PSKs) can
be used for the mutual authentication between master device and
database. In the PSK case, the shared key needs to be pre-configured
in the master device and in the database by manual operation; When
the PSK authentication is selected, the certificate and Certificate
Request payloads are omitted from the response. The detailed
procedure can reference the RFC4279. In the certificate case, the
master device and database can obtain an operator certificate through
the enrolment procedure.
Wu & Cui Expires January 10, 2013 [Page 14]
Internet-Draft PAWS security considerations July 2012
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 for
establishing the PSK. On the other hand, the use of PSK has
advantage that no PKI is required and the procedure after pre-
establishment of PSK is simple. When using certificate for mutual
authentication, a part of the usual certificate handling is replaced
by subscription handling.
3) Security protection
For the completion of the TLS handshake protocol, the
integrity![cents]confidentially and replay protected are all
activated, all communications between the master device and the
database shall be protected by the secure channel. The further
authentication of the master device and the white space database
should be protected by the secure channel if it needed.
4.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 cause a server to consume large amounts
of CPU for doing RSA decryption. Besides, attackers can forge RSTs,
thereby terminating connections, or forge partial TLS records,
thereby causing the connection to stall. In this situation,
implementers or users who are concerned with this class of attack
should use IPsec.
5. Security Considerations
All contents of this document are dealing with security.
6. IANA Considerations
There have been no IANA considerations so far in this document.
7. Acknowledgments
Thanks to my colleagues for their sincerely help and comments when
drafting this document.
Wu & Cui Expires January 10, 2013 [Page 15]
Internet-Draft PAWS security considerations July 2012
8. 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.
Authors' Addresses
Yizhuang Wu
Huawei Technologies
Email: wuyizhuang@huawei.com
Yang Cui
Huawei Technologies
Email: cuiyang@huawei.com
Wu & Cui Expires January 10, 2013 [Page 16]