RFC 7545
Protocol to Access White-Space (PAWS) Databases
Pages: 90
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 66 to 90
7. HTTPS Binding
This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS) as the transfer mechanism for PAWS. TLS provides message integrity and confidentiality between the Master Device and the Database, but only when best current practices are adopted, including use of recommended cipher suites and modes of operation. Consequently, to improve PAWS security and interoperability, implementations of the Database and Master Device MUST follow best current practices defined by "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525]. Depending on a prior relationship between a Database and device, the server MAY require client authentication, as described in the "Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate
the device. When client authentication is required, the Database MUST specify, by prior arrangement, acceptable root Certification Authorities (CAs) to serve as trust anchors for device certificates. To enable Databases to handle large numbers of requests from large numbers of devices, the Database MAY support and devices SHOULD support "Stateless TLS Session Resumption" [RFC5077]. A PAWS request message is carried in the body of an HTTP POST request. A PAWS response message is carried in the body of an HTTP response. A PAWS response SHOULD include a Content-Length header. The POST method is the only method REQUIRED for PAWS. If a Database chooses to support GET, it MUST be an escaped URI, but the encoding of the URI is outside the scope of this document. The Database MAY refuse to support the GET request by returning an HTTP error code, such as 405 (method not allowed). The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by Section 6.4 of "HTTP/1.1: Semantics and Content" [RFC7231]). The Database MUST provide the redirect URI in the Location header of the 3xx response, and the device MUST handle redirects by using the Location header provided by the Database. When redirecting, the device MUST observe the delay indicated by the Retry-After header. The device MUST authenticate the Database that returns the redirect response before following the redirect. Also, the device MUST authenticate the Database indicated in the redirect. Since the device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the device MAY redirect without asking a user for confirmation, even thought it is in response to an HTTP POST method. The Database SHOULD use HTTP status code "307 Temporary Redirect" to indicate that the device SHOULD resubmit the same request to an alternate URI. The device MAY revert to the original URI for the very next request, or it MAY continue to use the alternate URI for a period of time, e.g.,: o For the remainder of its session, or o For a fixed period of time, or o Until power cycled, or o Until it receives another redirect However, the device does not need to modify its stored list of URIs.
For a minimum of two weeks before the URI of the Database changes permanently, it MUST use the database-change (DbUpdateSpec (Section 5.7)) mechanism to notify devices, as described in "Configuration Update: Database URI Changes" (Section 4.1.2). After the Database has moved, requests to the original URI MAY return HTTP status code 301 (Moved Permanently) to indicate that the device SHOULD resubmit the request, and all future requests, to the indicated alternate URI.8. Extensibility
This section describes procedures for extending PAWS. No extensions should be made that would return sensitive device-specific information in database responses.8.1. Defining Ruleset Identifiers
A ruleset represents a set of device-side requirements for which the device has been certified. It typically corresponds to, but is not limited to, a set of rules that govern a specific set of radio spectrum for a regulatory domain. Ruleset identifiers are defined and registered in the Ruleset ID Registry following the procedure in Section 9.1. Ruleset ID values MUST conform to the ruleset-id ABNF. If the Ruleset ID requires additional parameters, they are registered in the PAWS Parameters Registry, as described by Section 9.2. The ABNF syntax [RFC5234] is as follows. ruleset-id = 1*64ruleset-char ruleset-char = ALPHA / DIGIT / "_" / "." When defining a Ruleset ID: o It can be useful for the identifier to be descriptive of the set of rules that allow a device to operate within one or more regulatory domains. For example, it might include the name of a regulatory body or a certification process. o The identifier SHOULD include some sort of version information, such as a year and/or version number. o The maximum length of the identifier is 64 octets.
8.2. Defining New Message Parameters
New request or response parameters for use with PAWS are defined and registered in the parameters registry following the procedure in Section 9.2. Parameter names MUST conform to the param-name ABNF, and parameter values syntax MUST be well-defined (e.g., using ABNF or a reference to the syntax of an existing parameter). param-name = 1*64name-char name-char = ALPHA / DIGIT / "_" Parameter names use lowerCamelCase by convention. The maximum length of a name is 64 octets. Unregistered vendor-specific parameter extensions that are not commonly applicable and are specific to the implementation details of the Database where they are used SHOULD use a vendor-specific prefix that is not likely to conflict with other registered values (e.g., begin with 'companyname').8.3. Defining Additional Error Codes
Additional error codes can be registered to extend the set listed in Section 5.17, following the procedures in Section 9.3. If the error code requires additional response parameters, they are registered in the PAWS Parameters Registry, as described by Section 9.2. By convention, the error code is a negative integer value, using one of the range of values defined in Error Codes (Section 5.17). If an appropriate category does not exist, a value from a different range may be used.9. IANA Considerations
There are three registries associated with PAWS: o PAWS Ruleset ID Registry (Section 9.1) o PAWS Parameter Registry (Section 9.2) o PAWS Error Code Registry (Section 9.3) All registries use the Specification Required policy [RFC5226], with a Designated Expert appointed by the IESG. Specific criteria that the Designated Expert should use in assessing registrations are given below in the description of each registry. The Designated Expert
should take advice from the community through the paws@ietf.org mailing list, and the registrant is encouraged to post to the mailing list before formally requesting the registration from IANA. The intention is that new registrations will be accompanied by a published specification. But in order to allow for the allocation of values prior to publication of the specification, the Designated Expert can approve allocations once it seems clear that the specification will be published. Upon approval, IANA will post the registrations that are not intended to be published in an RFC.9.1. PAWS Ruleset ID Registry
This specification establishes the "PAWS Ruleset ID Registry". Ruleset type names for inclusion in PAWS messages are registered on the advice of one or more Designated Experts, with Specification Required [RFC5226]. The specification must include a reference to the regulatory domain to which it applies. To increase interoperability, it is more desirable to have fewer rulesets than to have many rulesets with small variations. Consequently, the Designated Expert should avoid duplication and should encourage the registrant to look for alternatives if there are only small variations from an existing ruleset. The Designated Expert should ensure that the proposed registration is complete with respect to its associated regulatory domain and may seek an expert familiar with those rules to participate in the review on the paws@ietf.org mailing list. The PAWS Ruleset ID Registry includes the following: 'Ruleset Identifier', 'Reference', and 'Template'. The Template column will include links to the registration templates, either posted by IANA or linked to the relevant sections of RFCs.9.1.1. Registration Template
Ruleset identifier: The name of the ruleset. See Section 8.1 of RFC 7545 for the format requirements of this identifier. Specification document(s): Reference to the document that specifies the parameter, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections also may be included but is not required.
Additional Parameter Requirements: Listing of additional parameter
requirements to associate with the ruleset. Note that new
parameters are registered separately in the PAWS Parameters
Registry, as described by Section 8.2. Two types of additional
parameter requirements are:
* Addition of new parameters to existing structures, or
modification of the REQUIRED and OPTIONAL requirements for
existing parameters.
* Modification of requirements to existing parameter values.
For adding new parameters or modifying requirements of existing
parameters, the registration should include a table for each
affected structure that lists the structure's parameter changes.
Each table should include a structure name in its heading and have
the following columns:
Parameter name: Name of the parameter added or modified.
Type: Data type of the parameter value.
Requirement: Whether the parameter is REQUIRED or OPTIONAL for
the ruleset.
Notes: Any additional notes that might be useful to implementors.
For modifying requirements to existing parameter values, the
registration should include a table for each affected structure
that lists the structure's parameter changes. Each table should
include a structure name in its heading and have the following
columns:
Parameter name: Name of the parameter.
Type: Data type of the parameter value.
Additional requirements: Additional requirements on the parameter
value.
IANA will post each registration template that is not intended to be
published in an RFC.
Note that the Additional Parameter Requirements section can be quite
extensive, so it will not appear directly in the IANA Ruleset ID
Registry table. The table, however, will contain a link to the full
registration template for easy access to the additional requirements.
9.1.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to support any regulatory domain and ruleset. The initial contents of the registry, however, include only FCC-specific and ETSI-specific entries, because, as of this writing, they are the only regulatory domains that have finalized rules. There is no intent to restrict the protocol to any particular set of authorities. The initial contents of the PAWS Ruleset ID Registry are listed below; each section corresponds to a single entry in the registry.9.1.2.1. Federal Communications Commission (FCC)
For the additional parameters that start with the "fcc" prefix, see PAWS Parameters Registry Initial Contents (Section 9.2.2) for more information. Ruleset identifier: FccTvBandWhiteSpace-2010 Specification document(s): This ruleset refers to the FCC rules for TV-band white-space operations established in the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H]. Additional Parameter Requirements Each of the following tables defines additional parameters for the indicated PAWS message. Note that the Requirement column lists FCC, not PAWS, requirements/optionality rules. The FCC requires registration of "Fixed Devices". Additionally, deviceOwner is required in the registration request: Registration Request (Section 4.4.1) +-------------+-------------------+-------------+-------------------+ | Parameter | Type | Requirement | Notes | | Name | | | | +-------------+-------------------+-------------+-------------------+ | deviceOwner | DeviceOwner | REQUIRED | For registering | | | (Section 5.5) | | Fixed Devices | +-------------+-------------------+-------------+-------------------+
Available Spectrum Request (Section 4.5.1)
+---------------+-----------------------------+-------------+-------+
| Parameter | Type | Requirement | Notes |
| Name | | | |
+---------------+-----------------------------+-------------+-------+
| deviceDesc | DeviceDescriptor (Section | REQUIRED | |
| | 5.2) | | |
+---------------+-----------------------------+-------------+-------+
Available Spectrum Batch Request (Section 4.5.3)
+---------------+-----------------------------+-------------+-------+
| Parameter | Type | Requirement | Notes |
| Name | | | |
+---------------+-----------------------------+-------------+-------+
| deviceDesc | DeviceDescriptor (Section | REQUIRED | |
| | 5.2) | | |
+---------------+-----------------------------+-------------+-------+
DeviceDescriptor (Section 5.2)
+-------------------+--------+-------------+------------------------+
| Parameter Name | Type | Requirement | Notes |
+-------------------+--------+-------------+------------------------+
| serialNumber | string | REQUIRED | Specifies a device's |
| | | | serial number. See |
| | | | Section 5.2. |
| fccId | string | REQUIRED | Specifies a device's |
| | | | FCC certification ID |
| | | | (Section 9.2.2.1). |
| fccTvbdDeviceType | string | REQUIRED | Specifies the FCC |
| | | | Device Type (Section |
| | | | 9.2.2.2) of TV-band |
| | | | white-space device, as |
| | | | defined by the FCC |
| | | | rules. |
+-------------------+--------+-------------+------------------------+
The following table lists additional requirements for DeviceOwner (Section 5.5) parameter values. DeviceOwner (Section 5.5) +-----------+-------+-----------------------------------------------+ | Parameter | Type | Additional Requirement | | Name | | | +-----------+-------+-----------------------------------------------+ | owner | vCard | The owner is required to contain the | | | | formatted name of an individual or | | | | organization using the "fn" property. When | | | | the name is that of an organization, the | | | | entry also is required to contain the "kind" | | | | property, with a value of "org". | | operator | vCard | The operator entry is required to contain the | | | | following properties for the contact person | | | | responsible for the device's operation: "fn", | | | | "adr", "tel", and "email". | +-----------+-------+-----------------------------------------------+9.1.2.2. European Telecommunications Standards Institute (ETSI)
For the additional parameters that start with the "etsi" prefix, see PAWS Parameters Registry Initial Contents (Section 9.2.2) for more information. Ruleset identifier: ETSI-EN-301-598-1.1.1 Specification document(s): This ruleset refers to the ETSI Harmonised Standard [ETSI-EN-301-598] established by ETSI. Additional Parameter Requirements Each of the following tables defines additional parameters for the indicated PAWS message. Note that the Requirement column lists ETSI, not PAWS, requirements/optionality rules.
+-------------------------------------------------------------------+ | Parameter Name | | Type | | Requirement | | Notes | +-------------------------------------------------------------------+ | serialNumber | | string | | REQUIRED | | Specifies a device's serial number (Section 5.2). | | | | manufacturerId | | string | | REQUIRED | | Specifies a device's manufacturer's identifier | | (Section 5.2). | | | | modelId | | string | | REQUIRED | | Specifies a device's model identifier (Section 5.2). | | | | etsiEnDeviceType | | string | | REQUIRED | | Specifies the device's ETSI device type (Section 9.2.2.3). | | | | etsiEnDeviceEmissionsClass | | string | | REQUIRED | | Specifies the device's ETSI device emissions class | | (Section 9.2.2.4). | | | | etsiEnTechnologyId | | string | | REQUIRED | | Specifies the device's ETSI technology ID (Section 9.2.2.5). | | | | etsiEnDeviceCategory | | string | | REQUIRED | | Specifies the device's ETSI device category (Section 9.2.2.6). | +-------------------------------------------------------------------+
AVAIL_SPECTRUM_REQ (Section 4.5.1)
+-------------+--------+-------------+------------------------------+
| Parameter | Type | Requirement | Notes |
| Name | | | |
+-------------+--------+-------------+------------------------------+
| requestType | string | OPTIONAL | Modifies the available- |
| | | | spectrum request type. If |
| | | | specified, the only valid |
| | | | value is, "Generic Slave", |
| | | | and the Database is required |
| | | | to respond with generic |
| | | | operating parameters for any |
| | | | Slave Device. |
+-------------+--------+-------------+------------------------------+
Available Spectrum Batch Request (Section 4.5.3)
+-------------+--------+-------------+------------------------------+
| Parameter | Type | Requirement | Notes |
| Name | | | |
+-------------+--------+-------------+------------------------------+
| requestType | string | OPTIONAL | Modifies the available- |
| | | | spectrum request type. If |
| | | | specified, the only valid |
| | | | value is, "Generic Slave", |
| | | | and the Database is required |
| | | | to respond with generic |
| | | | operating parameters for any |
| | | | Slave Device. |
+-------------+--------+-------------+------------------------------+
The following tables define additional requirements for the
DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6)
parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.5.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) messages. Note that this
means the Database is modifying the DeviceDescriptor sent by the
Master Device to return device-specific restrictions.
+-------------------------------------------------------------------+ | Parameter Name | | Type | | Requirement | | Notes | +-------------------------------------------------------------------+ | needsSpectrumReport | | boolean | | REQUIRED | | The Database is required to set this to true to indicate that | | the device must report spectrum usage. | | | | maxTotalBwHz | | float | | REQUIRED | | Specifies a constraint on total allowed bandwidth. | | | | maxContiguousBwHz | | float | | REQUIRED | | Specifies a constraint on total allowed contiguous | | bandwidth. | | | | etsiEnSimultaneousChannelOpera | | string | | REQUIRED | | Specifies a constraint on simultaneous channel operation | | (Section 9.2.2.7). If it is not provided, the default value | | is "0". | +-------------------------------------------------------------------+ RulesetInfo (Section 5.6) +-------------------+-------+-------------+-------------------------+ | Parameter Name | Type | Requirement | Notes | +-------------------+-------+-------------+-------------------------+ | maxLocationChange | float | OPTIONAL | Specifies a constraint | | | | | on maximum location | | | | | changes. | +-------------------+-------+-------------+-------------------------+
9.2. PAWS Parameters Registry
This specification establishes the "PAWS Parameters Registry". Additional parameters for inclusion in PAWS requests, responses, or sub-messages are registered on the advice of one or more Designated Experts, with Specification Required [RFC5226]. The Designated Expert should avoid duplication, i.e., avoid adding a new parameter when an existing one suffices. When a set of parameters is added in support of a new ruleset (Section 9.1), the parameters should share a common prefix that reflects the ruleset ID. The prefix may be omitted, of course, if a parameter has more general applicability. Similarly, when a parameter is not associated with a ruleset, the Designated Expert should ensure that the parameter name does not have a prefix that is used by existing ruleset parameters (e.g., "fcc", "etsi") or that is the initials of an organization that has not yet registered anything, but reasonably might. The PAWS Parameters Registry includes the following: 'Parameter name', 'Parameter usage location', and 'Specification document(s)'.9.2.1. Registration Template
Parameter name: The name of the parameter (e.g., "example"). Parameter usage location: The location(s) where the parameter can be used. The possible locations are the named structures defined in "Protocol Functionalities" (Section 4) and "Protocol Parameters" (Section 5). Specification document(s): Reference to the document that specifies the parameter, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections also may be included, but is not required.9.2.2. Initial Registry Contents
The PAWS Parameters Registry enables protocol extensibility to support any regulatory domain and ruleset. The initial contents of the registry, however, include only FCC-specific and ETSI-specific entries, because, as of this writing, they are the only regulatory domains that have established rules. There is no intent to restrict the protocol to any particular set of authorities. The initial contents of the PAWS Parameters Registry are listed below; each section corresponds to a row of the registry.
9.2.2.1. FCC ID
Parameter name: fccId Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): This document. Specifies the device's FCC certification identifier. A valid FCC ID is limited to 19 characters in the ASCII value range, as proposed in FCC Administration Topics Review [FCC-Review-2012-10]. For the purposes of the PAWS protocol, the maximum length of the fccId value is 32 octets.9.2.2.2. FCC Device Type
Parameter name: fccTvbdDeviceType Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): This document. Specifies the TV-band white-space device type, as defined by the FCC. Valid values are "FIXED", "MODE_1", and "MODE_2".9.2.2.3. ETSI Device Type
Parameter name: etsiEnDeviceType Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): Specifies the white-space device type, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid values are single-letter strings, such as "A", "B", etc. Consult the documentation for details about the device types.9.2.2.4. ETSI Device Emissions Class
Parameter name: etsiEnDeviceEmissionsClass Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): Specifies the white-space device emissions class, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598], that characterizes the out-of-block emissions of the device. The values are represented by numeric strings, such as "1", "2", "3", etc. Consult the documentation for details about emissions classes.
9.2.2.5. ETSI Technology Identifier
Parameter name: etsiEnTechnologyId Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): Specifies the white-space device technology identifier, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The maximum length of the string value is 64 octets. Consult the documentation for valid values.9.2.2.6. ETSI Device Category
Parameter name: etsiEnDeviceCategory Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): Specifies the white-space device category, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid values are the strings "master" and "slave". It is case insensitive.9.2.2.7. ETSI Simultaneous Channel Operation Restriction
Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec (Section 5.9) Specification document(s): Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The values are represented by numeric strings, such as "0", "1", etc. Consult the documentation for the specification of the power constraint corresponding to each parameter value.9.3. PAWS Error Code Registry
This specification establishes the "PAWS Error Code Registry". Additional error codes for inclusion in PAWS error messages are registered on the advice of one or more Designated Experts, with Specification Required [RFC5226]. Error codes are intended to be used for automated error handling by devices. Before approval, the Designated Expert should consider whether a device would handle the new error code differently from an
existing error code, or whether the difference could be communicated effectively to the end-user via the "reason" parameter of the Error (Section 5.17) object. The PAWS Error Code Registry includes the following: 'Code', 'Name', 'Description and Additional Parameters', and 'Specification Document(s)'.9.3.1. Registration Template
Code: Integer value of the error code. The value MUST be an unassigned value in the range -32768 to 32767, inclusive. Name: Name of the error. Description and Additional Parameters: Description of the error and its associated parameters, if any. It also lists additional parameters that are returned in the data portion of the error (see Section 5.17). New parameters MUST be registered separately in the PAWS Parameters Registry, as described by Section 9.2.9.3.2. Initial Registry Contents
Initial registry contents are defined in the Error Codes Table (Table 1). The registry will also include the error-code categories describing -100s, -200s, and -300s as a note (see "Error Codes" (Section 5.17)).10. Security Considerations
PAWS is a protocol whereby a Master Device requests a schedule of available spectrum at its location (or location of its Slave Devices) before it (they) can operate using those frequencies. Whereas the information provided by the Database must be accurate and conform to the applicable ruleset, the Database cannot enforce, through the protocol, that a client device uses only the spectrum it provided. In other words, devices can put energy in the air and cause interference without asking the Database. Hence, PAWS security considerations do not include protection against malicious use of the white-space spectrum. For more detailed information on specific requirements and security considerations associated with PAWS, see "Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements" [RFC6953].
By using PAWS, the Master Device and the Database expose themselves
to the following risks:
o Accuracy: The Master Device receives incorrect spectrum-
availability information.
o Privacy:
* An unauthorized entity intercepts identifying data for the
Master Device or its Slave Devices, such as serial number and
location.
* Where Databases are required to take device registrations and/
or maintain request logs, there could be unauthorized access to
such information.
Protection from these risks depends on the success of the following
steps:
1. The Master Device must determine the address of a proper
Database.
2. The Master Device must connect to the proper Database.
3. The Database must determine or compute accurate spectrum-
availability information.
4. PAWS messages must be transmitted unmodified between the Database
and the Master Device.
5. PAWS messages must be encrypted between the Database and the
Master Device to prevent exposing private information.
6. For a Slave Device, the spectrum-availability information also
must be transmitted unmodified and securely between the Master
Device and the Slave Device.
7. When a Listing Server is required, any attack that would prevent
reaching a Listing Server would result in all devices relying on
that Listing Server ceasing their use of any white space.
8. No future extensions to PAWS can allow the return of sensitive
information, such as device information or logs.
9. The Database must not allow unauthorized access to device
information and request logs and should publish and implement
privacy policies regarding their use.
Of these, only steps 1, 2, 4, 5, and 8 are within the scope of this document. This document addresses step 1 by allowing static provisioning of one or more trusted Databases; dynamic provisioning is out of scope. Step 3 is dependent on specific database implementations and rulesets and is outside the scope of this document. Step 6 requires a protocol between master and slave devices and is thus outside the scope of this document. Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not compromised, ensures steps 2, 4, and 5, as detailed in the following sections: o "Assurance of Proper Database" (Section 10.1) o "Protection against Modification" (Section 10.2) o "Protection against Eavesdropping" (Section 10.3) Any specification for an alternate transport MUST define mechanisms that ensure each of these steps. In addition to the privacy risks described above, information provided in DeviceDescriptor (Section 5.2) and DeviceOwner (Section 5.5), along with device location, may allow a database administrator to track the activity and location of a device and its user over time. Risks of secondary use of such tracking information, including sharing with third parties, require out-of-band mitigation, such as public statements or contractual terms. Furthermore, while it is understandable that regulators require DeviceOwner information for higher-power fixed white-space devices, for privacy concerns, regulators should not require DeviceOwner information for mobile devices. Similarly, regulators should require, and implementations should provide, device location at a level of granularity only as precise as necessary to support accurate database responses.10.1. Assurance of Proper Database
This document assumes that the Database is contacted using a domain name or an IP address. Using HTTP over TLS, the Database authenticates its identity, either as a domain name or IP address, to the Master Device by presenting a certificate containing that identifier as a "subjectAltName" (i.e., as a dNSName or IP address). If the Master Device has external information as to the expected identity or credentials of the proper Database (e.g., a certificate fingerprint), checks of the subjectAltName MAY be omitted. Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. In particular, the validation path of the certificate must end in one of the client's
trust anchors, even if that trust anchor is the Database's certificate. A Master Device should allow for the fact that a Database can change its Certification Authorities (CAs) over time.10.2. Protection against Modification
To prevent a PAWS response message from being modified en route, messages must be transmitted over an integrity-protected channel. Using HTTP over TLS, the channel will be protected by appropriate cipher suites.10.3. Protection against Eavesdropping
Using HTTP over TLS, messages protected by appropriate cipher suites are also protected from eavesdropping or otherwise unrestricted reading by unauthorized parties en route.10.4. Client Authentication Considerations
Although the Database can inform a device of available spectrum it can use, the Database cannot enforce that the Master Device uses only (or any of) those frequencies. Indeed, a malicious device can operate without ever contacting a Database. Note also that, whereas a malicious device may send fraudulent SPECTRUM_USE_NOTIFY (Section 4.5.5) messages, in the regulatory domains that have established rules, such notifications do not change the available- spectrum answers, so no harm can result from such messages. Consequently, client authentication is not required for the core PAWS (although it may be required by specific regulatory domains). Depending on a prior relationship between a Database and Master Device, the Database MAY require client authentication. TLS provides client authentication, but there are some considerations: o The Database must nominate acceptable CAs, and the Master Device must have a certificate rooted at one of those CAs. o As indicated in Section 3.2 of "HTTP Over TLS" [RFC2818], the TLS client authentication procedure only determines that the device has a certificate chain rooted in an appropriate CA (or a self- signed certificate). The Database would not know what the client identity ought to be, unless it has some external source of information. Distribution and management of such information, including revocation lists, are outside the scope of this document.
o Authentication schemes are secure only to the extent that secrets
or certificates are kept secure. When there are a vast number of
deployed devices using PAWS, the possibility that device keys will
not leak becomes small. Implementations should consider how to
manage the system in the eventuality that there is a leak.
11. References
11.1. Normative References
[JSON-RPC]
"JSON-RPC 2.0 Specification",
<http://www.jsonrpc.org/specification>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, <http://www.rfc-editor.org/info/rfc5491>. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <http://www.rfc-editor.org/info/rfc6350>. [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <http://www.rfc-editor.org/info/rfc7095>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.11.2. Informative References
[ETSI-EN-301-598] European Telecommunication Standards Institute (ETSI), "ETSI EN 301 598 (V1.1.1): White Space Devices (WSD); Wireless Access Systems operating in the 470 MHz to 790 MHz TV broadcast band; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive", April 2014, <http://www.etsi.org/deliver/ etsi_en/301500_301599/301598/01.01.01_60/ en_301598v010101p.pdf>. [FCC-CFR47-15H] U. S. Government, "Electronic Code of Federal Regulations, Title 47, Part 15, Subpart H: Television Band Devices", December 2010, <http://www.ecfr.gov/cgi-bin/ text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[FCC-Review-2012-10] Federal Communications Commission, "Administration Topics Review", October 2012, <http://transition.fcc.gov/bureaus/oet/ea/presentations/ files/oct12/2b-TCB-Admin-Issues-Oct-2012-GT.pdf>. [ISO3166-1] "Country Codes", <http://www.iso.org/iso/country_codes.htm>. [RFC6953] Mancuso, A., Ed., Probasco, S., and B. Patil, "Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements", RFC 6953, DOI 10.17487/RFC6953, May 2013, <http://www.rfc-editor.org/info/rfc6953>. [RFC7459] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)", RFC 7459, DOI 10.17487/RFC7459, February 2015, <http://www.rfc-editor.org/info/rfc7459>. [WGS-84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", NIMA TR8350.2, Third Edition, Amendment 1, January 2000, <http://earth-info.nga.mil/GandG/publications/tr8350.2/ tr8350_2.html>.
Appendix A. Database Listing Server Support
As discussed in "Database Discovery" (Section 4.1), some regulatory domains support the preconfiguration of devices with the URI of a listing server, to which devices can connect to obtain a list of Databases certified by the regulatory domain. Regulatory domains may require the device to periodically contact the Database Listing Server to validate and/or update its list of certified Databases. If the device is unable to validate its list of certified Databases within the required period, regulatory rules may require the device to treat this inability as equivalent to the device having no available spectrum. A sample JSON response from a Database Listing Server might be represented as follows: { "lastUpdateTime": "2014-06-28T10:00:00Z", "maxRefreshMinutes": 1440 "dbs": [ { "name": "Some Operator", "uris": [ { "uri": "https://example.some.operator.com", "protocol": "paws" }, ... ] }, ... ] } The parameters in this sample message are: lastUpdateTime: The time at which the database entries were last updated. maxRefreshMinutes: The maximum interval, expressed in minutes, that is allowed between device requests to the Database Listing Server. dbs: A list of entries for certified Databases, each containing the following name: The name of the database operator.
uris: One or more URIs for each Database, allowing a Database to
support more than one protocol.
uri, protocol: Each protocol supported by a certified Database is
associated with a separate URI (PAWS protocol URI shown).
Acknowledgments
The authors gratefully acknowledge the contributions of: Gabor Bajko,
Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
Harasty, Michael Head, Jussi Kahtava, Kalle Kulsmanen, Warren Kumari,
Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
Juan Carlos Zuniga.
Contributors
This document draws heavily from draft-das-paws-protocol and
draft-wei-paws-framework. The editor would like to specifically call
out and thank the contributing authors of those two documents.
Donald Joslyn
Spectrum Bridge Inc.
1064 Greenwood Blvd.
Lake Mary, FL 32746
United States
EMail: d.joslyn@spectrumbridge.com
Xinpeng Wei
Huawei
Phone: +86 13436822355
EMail: weixinpeng@huawei.com
Authors' Addresses
Vincent Chen (editor) Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States EMail: vchen@google.com Subir Das Applied Communication Sciences 150 Mount Airy Road Basking Ridge, NJ 07920 United States EMail: sdas@appcomsci.com Lei Zhu Huawei Phone: +86 13910157020 EMail: lei.zhu@huawei.com John Malyar iconectiv (formerly Telcordia Interconnection Solutions) 444 Hoes Lane/RRC 4E1106 Piscataway, NJ 08854 United States EMail: jmalyar@iconectiv.com Peter J. McCann Huawei 400 Crossing Blvd, 2nd Floor Bridgewater, NJ 08807 United States Phone: +1 908 541 3563 EMail: peter.mccann@huawei.com