Hi folks, Thursday (20 May 2004)
Below is a rewrite of section 8 "Security Considerations".
Note that all of the _correct_ security statements from the former
version have been preserved.
I added this new high-level warning paragraph at the beginning:
Warning: If an implementation of a secure IPPFAX Receiver is enabled on
a single network host system simultaneously with another traditional
print protocol (e.g., IPP/1.1 [RFC2911]), new security threats appear.
Administrators and users are warned that this configuration facilitates
denial-of-service attacks and and local file system attacks against the
network host system (and thus against the IPPFAX service). Beware.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
[change log]
(1) Deleted all former tables (all of which had technical errors).
(2) Moved former sections 8.1 and 8.2 to new sections 8.5.1 and 8.5.2.
(3) Moved former sections 8.3 and 8.3 to new sections 8.6.1 and 8.6.2.
(4) Deleted former section 8.5 (now redundant).
(5) Deleted former section 8.6 (technically wrong entirely).
(6) Deleted former section 8.7 (technically wrong entirely).
(7) Added new sections 8.1, 8.2, 8.3, and 8.4 for Internet, Enterprise,
Mobile, and HTTP threat models and Sender and Receiver requirements
(derived from similar PSI/1.0 security considerations section).
------------------------------------------------------------------------
8. Security Considerations
This section describes the security threats against IPPFAX/1.0 Senders
and Receivers. This section also addresses the security-related
attributes of Printer objects (i.e., protocol endpoints of Receivers).
This section specifies the security conformance requirements and
recommendations for IPPFAX/1.0 Sender and Receiver implementations,
largely by reference to applicable underlying protocol specifications,
for example, IPP/1.1 [RFC2911], HTTP/1.1 [RFC2616], and TLS/1.0
[RFC2246].
Warning: If an implementation of a secure IPPFAX Receiver is enabled on
a single network host system simultaneously with another traditional
print protocol (e.g., IPP/1.1 [RFC2911]), new security threats appear.
Administrators and users are warned that this configuration facilitates
denial-of-service attacks and and local file system attacks against the
network host system (and thus against the IPPFAX service). Beware.
8.1 Internet Threat Model
This section is adapted from section 3 of IETF Guidelines for Writing
RFC Text on Security Considerations [RFC3552].
In the Internet threat model, we assume that the end systems engaging in
a protocol exchange have not themselves been compromised. Protecting
against an attack when either of the end systems has itself been
compromised is extraordinarily difficult.
By contrast, we assume that the attacker has nearly complete control
of the communications channel over which the end systems communicate.
This means that the attacker can read any PDU (Protocol Data Unit) on
the network and undetectably remove, change, or inject forged packets
onto the wire. This includes being able to generate packets that
appear to be from a trusted machine. Thus, even if the end-system
with which you wish to communicate is itself secure, the Internet
environment provides no assurance that packets which claim to be from
that system in fact are.
The meaning of a PDU changes at different protocol layers. At the IP
layer [RFC791], it's an IP packet. At the TCP layer [RFC793], it's a
TCP segment. At the IPP/1.1 [RFC2911] application layer, it's a single
IPP operation request or response.
8.1.1 Passive Attacks
In a passive attack, the attacker reads packets off the network but
does not write them. On most common LAN configurations, including
Ethernet, 802.3, and FDDI, any machine on the wire can read all traffic
destined for any other machine on the same LAN. Note that switching
hubs make this sort of sniffing substantially more difficult, since
traffic destined for a machine only goes to the network segment that
machine is located on.
Wireless communications channels deserve special consideration,
especially with the recent and growing popularity of wireless-based
LANs, such as those using 802.11. Since the data is simply broadcast
on well known radio frequencies, an attacker simply needs to be able
to receive those transmissions. Such channels are especially
vulnerable to passive attacks. Although many such channels include
cryptographic protection, it is often of very poor quality.
Senders and Receivers MUST support TLS/1.0 and MUST always use at least
TLS/1.0 data integrity services for protection against the following
passive attacks described in [RFC3552]:
(1) Confidentiality Violations - Senders and Receivers MUST support
and MAY use TLS/1.0 data privacy services for protection against
exposure of private business data.
(2) Password Sniffing - Senders and Receivers MUST NOT transfer any
cleartext passwords over unencrypted channels (TLS/1.0 data privacy
services or HTTP/1.1 Digest Authentication over TLS/1.0 data
integrity services MAY be used instead).
8.1.2 Active Attacks
In an active attack, the attacker writes packets to the network and may
read responses from the network. Active attacks that involve sending
forged packets but not receiving any responses are called "blind
attacks".
When IP [RFC791] is used without IPsec [RFC2401], there is no
authentication for the packet source address. Active attacks that
involve forging an IP packet with a false source address are called
"spoofing attacks".
Senders and Receivers MUST support TLS/1.0 and MUST always use at least
TLS/1.0 data integrity services for protection against the following
active attacks described in [RFC3552]:
(1) Message Replay Attacks
(2) Message Insertion Attacks
(3) Message Deletion Attacks
(4) Message Modification Attacks
(5) Man-In-The-Middle Attacks
8.2 Enterprise Threat Model
In the enterprise threat model, we can no longer assume that the
end systems engaging in a protocol exchange have not themselves been
compromised. Physical security of workstations and network printers in
an enterprise network is often the weakest point of security defenses.
And IPPFAX jobs typically produce hardcopy, which an inside attacker can
simply steal.
Network security problems are actually worse inside an enterprise
network. Firewalls and border routers no longer provide any useful
protection.
Users and administrators who deploy IPPFAX products in enterprise
networks MUST enforce the use of TLS/1.0 and SHOULD consider the use of
strong Client and Server Authentication during TLS/1.0 startup.
8.3 Mobile Threat Model
In the mobile threat model, we can no longer defend against attackers
based on network topology. Mobile clients may access home, business,
or commercial IPPFAX products via:
(1) Public Wireless - Cellular ISPs, IEEE 802.11 wireless Ethernet "hot
spots" in airports, etc.
(2) Local Wireless - Bluetooth/IRDA-enabled laptops and printers, etc.
Users and administrators who deploy IPPFAX products in mobile networks
MUST enforce the use of TLS/1.0 and SHOULD consider the use of strong
Client and Server Authentication during TLS/1.0 startup. IPsec
[RFC2401] also offers significant security advantages in mobile
networks.
8.4 HTTP Threat Model
Senders and Receivers are vulnerable to the following HTTP threats
described in section 15 "Security Considerations" of HTTP/1.1 [RFC2616]:
(1) Personal Information Attacks - HTTP/1.1 clients and servers in
Sender and Receiver implementations MUST protect sensitive personal
information, such as name, email address, etc. (see section 15.1 of
[RFC2616]).
(2) Filename and Pathname Attacks - HTTP/1.1 servers in Receiver
implementations MUST NOT expose "nearby" resources that were NOT
explicitly configured for network access by administrators (see
section 15.2 of [RFC2616]).
(3) DNS Spoofing Attacks - HTTP/1.1 clients and servers in Sender and
Receiver implmentations SHOULD NOT cache DNS name resolution results
beyond their time-to-live value (see section 15.3 of [RFC2616]).
(4) HTTP Location Header Spoofing Attacks - HTTP/1.1 servers in
Receiver implementations MUST verify the validity of Location and
Content-Location header data when supporting multiple trust domains
(see section 15.4 of [RFC2616]).
(5) HTTP Content-Disposition Headers Attacks - HTTP/1.1 servers in
Receiver implementations MUST defend against Content-Disposition
header attacks (see section 15.5 of [RFC2616]).
(6) Retention of Authentication Credentials Attacks - HTTP/1.1 clients
in Sender implementations SHOULD NOT retain cached user
authentication credentials beyond an administratively configured
idle client time (see section 15.6 of [RFC2616]).
(7) HTTP Proxy Attacks - HTTP/1.1 servers in Receiver implementations
SHOULD take active measures to defend against distributed
denial-of-service attacks (see section 15.7 of [RFC2616]).
8.5 TLS Security Services
8.5.1 Data Integrity and Authentication
Senders and Receivers MUST immediately perform TLS/1.0 startup [RFC2246]
on all new transport layer connections, _prior_ to establishing HTTP/1.1
session layer connections. Senders and Receivers MUST successfully
establish TLS/1.0 data integrity services or else MUST abort the TLS
connection.
A Receiver MUST have a TLS certificate. A Sender MUST authenticate
the Sender using TLS Server Authentication. Therefore, a Sender MUST
have the public keys of the top-level public key Certificate Authorities
(as current browsers do). If a Sender gets a public key from a Receiver
that is doesn't recognize, then the Sender MUST inform the Sending User
that data integrity has been lost and MUST abort the TLS connection.
A Sender MAY have a TLS certificate for TLS Client Authentication. A
Receiver MAY reject TLS/1.0 connections from Senders that
do not have a TLS certificate.
A Sender MAY use its own TLS certificate or it MAY use one associated
with the Sending User.
The method of distribution of private keys to Senders or Receivers is
outside the scope of this document, but if it is done over the network,
it MUST be done over a secure channel. See Internet Key Exchange (IKE)
[RFC2409].
8.5.2 Data Privacy
A Sender or a Receiver MAY negotiate TLS data privacy services (i.e.,
encryption) as defined in TLS/1.0 [RFC2246].
8.6 IPPFAX Printer Security Attributes
8.6.1 uri-authentication-supported (1setOf type2 keyword)
This attribute (see [RFC2911] section 4.4.2) identifies the Client
Authentication mechanism associated with each URI listed in the
"printer-uri-supported" attribute (see section 5.1).
Senders MUST support the values 'none' and 'digest' and SHOULD support
the value 'certificate'. Receivers MUST support the values 'none',
'digest', and 'certificate'. Senders and Receivers MUST NOT support the
values 'basic' (due to cleartext passwords) or 'requesting-user-name'
(due to no password).
8.6.2 uri-security-supported (1setOf type2 keyword)
This attribute (see [RFC2911] section 4.4.3) identifies the security
mechanisms (for data integrity and data privacy) used for each URI
listed in the "printer-uri-supported" attribute (see section 5.1).
Senders MUST support the value 'ssl3' and/or 'tls'. Receivers MUST
support the value 'tls' and SHOULD support the value 'ssl3' (for best
interworking). Senders and Receivers MUST NOT support the values 'none'
or 'ssl2' (to avoid compromised data integrity).
This archive was generated by hypermail 2b29 : Thu May 20 2004 - 16:57:32 EDT