IFX Mail Archive: IFX> Rewrite of IFX security considerations

IFX Mail Archive: IFX> Rewrite of IFX security considerations

IFX> Rewrite of IFX security considerations

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu May 20 2004 - 16:57:13 EDT

  • Next message: Gail Songer: "IFX> Updated IPPFax protocol document"

    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