One document matched: draft-wu-paws-secutity-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY PAWS-REQ PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-paws-problem-stmt-usecases-rqmts-03.xml'>
]>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-wu-paws-secutity-00.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="PAWS security considerations">
Protocol to Access White Space database: security considerations
</title>
<author initials="Y.Wu" surname="Wu" fullname="Yizhuang Wu">
<organization abbrev="Huawei">Huawei Technologies </organization>
<address>
<email> wuyizhuang@huawei.com </email>
</address>
</author>
<author initials="Y.Cui" surname="Cui" fullname="Yang Cui">
<organization abbrev="Huawei">Huawei Technologies </organization>
<address>
<email> cuiyang@huawei.com </email>
</address>
</author>
<date month="July" year="2012" />
<area>Application</area>
<workgroup>PAWS</workgroup>
<abstract>
<t>
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.
</t>
<t>
The present document describes the security threats to the current framework of PAWS, and meanwhile proposes the corresponding countermeasures.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
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.
</t>
<t>
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.
</t>
<t>
In this document, the security threats, the security features and the security mechanism(TLS) are discussed in details.
</t>
</section>
<section title="Conventions and terminology">
<section title="Conventions used in this Document">
<t>
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].
</t>
</section>
<section title="Terminology">
<t>
The Terminology Section of the latest version of [I-D.ietf-paws-problem-stmt-usecases-rqmts] shall be included by reference.
</t>
<t>
WS interface
</t>
<t>
The interface between master device and Database specifies data model and process of PAWS in this document.
</t>
</section>
</section>
<section title="Overview of Security threats and Requirements">
<section title="Fundamental system architecture of PAWS">
<t>
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:
</t>
<figure align="center">
<artwork><![CDATA[
\|/ ----------
| .---. |Database|
| ( ) /---------
|-|---------| / \ /
| Master | ( Internet )
| device |========( insecure )
|-----------| \ link) /
( )
(----)
]]>
</artwork>
<postamble>
Figure 1: system architecture of PAWS
</postamble>
</figure>
<t>
Description of system architecture:
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
4) The master device queries the white space database for available white space channel lists.
</t>
</section>
<section title="Security threats">
<t>
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:
</t>
<section title="Impersonation of a master device">
<t>
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.
</t>
</section>
<section title="Impersonation of database">
<t>
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.
</t>
</section>
<section title="MitM on the interface between master device and database">
<t>
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.
</t>
</section>
<section title="Attacks on the link of interface between master device and database">
<t>
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:
</t>
<t>
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.
</t>
<t>
2) The location/identity information can be gleaned by an eavesdropper and be used for tracking purposes.
</t>
<t>
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.
</t>
</section>
<section title="Attacks on the master device itself">
<t>
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.
</t>
</section>
<section title="Other potential attacks(To be added)">
</section>
</section>
<section title="Security countermeasures">
<t>
To mitigate the above threats, the security countermeasures below should be used. Namely:
</t>
<t>
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.
</t>
<t>
2) The master device shall authenticate the identity of database.
</t>
<t>
3) The master device and the white space database shall check that both of them are authorized by the regulator body of white space.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Security schemes">
<section title="Overview">
<t>
According to the previous analysis, the security mechanism shall be able to provide the following security features:
</t>
<t>
1) Mutual authentication
</t>
<t>
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).
</t>
<t>
2) The protection mechanisms of the data
</t>
<t>
The data over the interface between the master device and the database shall be protected for integrity, confidentiality and anti-replay from unauthorized parties.
</t>
<t>
3) Trusted environment
</t>
<t>
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.
</t>
</section>
<section title="Analysis of security schemes">
<t>
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.
</t>
<section title="Databases deployed by third-party">
<t>
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 white space database which are provided by different trusted authorities. There are two possible authentication models which are showed as follow:
</t>
<t>
Model 1
</t>
<figure align="center">
<artwork><![CDATA[
+-----------------------------------------------+
| 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 |
+--------------------------------------------------+
]]>
</artwork>
<postamble>
Figure 2: authentication model 1
</postamble>
</figure>
<t>
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).
</t>
<t>
Under this circumstance, the whole querying procedure of white space channels can be showed as followed:
</t>
<figure align="center">
<artwork><![CDATA[
+-------------+ +--------+ +----+
|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 | |
|<--------------------->| |
| | |
| | |
]]>
</artwork>
<postamble>
Figure 3: procedure of querying database
</postamble>
</figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
Finally, only when the twice mutual authentications are both passed, the master device can query the database for available white space channels.
</t>
<t>
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.
</t>
<t>
Model 2
</t>
<figure align="center">
<artwork><![CDATA[
+-----------------------------------------------+
| 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 |
+--------------------------+
]]>
</artwork>
<postamble>
Figure 4: authentication model 2
</postamble>
</figure>
<t>
In this model, the master device and database both can connect to regulatory body of white space.
</t>
<t>
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 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.
</t>
</section>
<section title="Databases deployed by regulatory body of white space">
<t>
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:
</t>
<figure align="center">
<artwork><![CDATA[
+-----------------------------------------------+
| The credentials of master device and database |
| which is used for authentication are provided |
| by trusted authority of RBWS |
+-----------------------------------------------+
/
/
+--------+ / +--------+
| master |----------------------| |
| |<--------secure------>|Database|
| device |----------------------| |
+--------+ +--------+
]]>
</artwork>
<postamble>
Figure 5: authentication model 3
</postamble>
</figure>
<t>
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.
</t>
<t>
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 TLS is introduced in this document.
</t>
</section>
</section>
<section title="TLS protocol">
<section title="Brief introduction of TLS protocol">
<t>
TLS protocol provides the communications privacy over the internet which is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
b) According the [RFC5246], RSA or Diffie-Hellman can be used for authentication and key exchange.
</t>
<t>
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.
</t>
<t>
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:
</t>
<t>
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.
</t>
<t>
b) Integrity: A keyed MAC is used to message integrity check. Secure hash functions (e.g., SHA-1, etc) are used for MAC generated.
</t>
</section>
<section title="Security establishment procedure between master device and database">
<t>
In related reference of PAWS, TCP and HTTP are recommended to be used to load the messages in the interface between the master device and the database.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
1) The procedure of TLS handshake protocol can be described as follows which is based on the [RFC5246]£¬it contains four stages:
</t>
<t>
a) The first stage: security capabilities including protocol version, session ID, cipher suite, compression method, and initial random numbers are established
</t>
<t>
b) The second stage: certificate of the database, key exchange, and request certificate shall be sent by database
</t>
<t>
c) The third phase: master device sends certificate if requested. Key exchange and certificate verification may be sent by master device
</t>
<t>
d) The last phase: change cipher suite and finish handshake protocol
</t>
<t>
2) Authentication methods
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
3) Security protection
</t>
<t>
For the completion of the TLS handshake protocol, the integrity¡¢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.
</t>
</section>
<section title="Drawbacks of TLS protocol ">
<t>
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.
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>
All contents of this document are dealing with security.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
There have been no IANA considerations so far in this document.
</t>
</section>
<section title="Acknowledgments">
<t>
Thanks to my colleagues for their sincerely help and comments when drafting
this document.
</t>
</section>
</middle>
<back>
<references title="Normative Reference">
&RFC2119;
&PAWS-REQ;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:50 |