Hi folks, Sunday (21 October
2003)
Below is draft text for inclusion in the PSI/10 protocol spec for:
- Section 11 "PWG and IANA Considerations"
- Section 12 "Internationalization Considerations"
- Section 13 "Security Considerations"
- Additions to "Normative References"
- Additions to "Informative References"
Dave - the following section numbers are probably wrong after our
face-to-face move of some sections to the 'Conformance' section.
Dave - there are a number of normative (MUST or SHOULD) requirements
in
this new Section 13 "Security Considerations". I suggest we simply
add
a pointer to these requirements to Section xx 'Conformance'. OK?
Comments?
Cheers,
- Ira McDonald, contributing editor to PSI/1.0
High North Inc
----------------------------------------------------------------------
--
11. PWG and IANA Considerations
This document does not require any new PWG or IANA registration
support.
The following paragraphs describe some existing PWG, IANA, W3C, and
ISO
registered standard elements used in PSI/1.0:
This PSI/1.0 document uses the existing standard elements of Job and
Document objects defined in the PWG Semantic Model [PWG-SM].
The accompanying PSI/1.0 WSDL references schema defined in [PWG-SM].
The [XML] 'encoding' attribute contains a 'charset tag' [RFC2978].
New standard values may be registered according to [RFC2978] in the
IANA
Registry of Charset Tags [IANA-CHAR].
The [XML] 'lang' attribute contains a 'language tag' [RFC3066],
i.e., a 'language code' [ISO639] optionally followed by a hyphen and
a
'country code' [ISO3166]. New standard values (other than existing
[ISO639] registrations) may be registered according to [RFC3066] in
the
IANA Registry of Language Tags [IANA-LANG].
The [PWG-SM] 'DocumentNaturalLanguage' element also contains a
'language
tag' [RFC3066].
The [PWG-SM] 'DocumentFormat' element contains a MIME (content) media
type [RFC2046]. New standard values may be registered according to
[RFC2048] in the IANA Registry of Media Types [IANA-MIME].
----------------------------------------------------------------------
--
12. Internationalization Considerations
PSI/1.0 implementations conform to all the best practice
recommendations
in "IETF Policy on Character Sets and Languages" [RFC2277].
PSI/1.0 implementations exchange [XML] information based on XML
Schema
[XSD] defined in the PWG Semantic Model [PWG-SM].
The [XML] 'encoding' attribute (which MUST be supplied by PSI/1.0
Clients) SHOULD be set to 'utf-8' [RFC2279], as recommended by
[RFC2277].
The [XML] 'lang' attribute (which SHOULD be supplied by PSI/1.0
Clients)
SHOULD be set to a value conforming to [RFC3066], as recommended by
[RFC2277].
The [PWG-SM] 'DocumentNaturalLanguage' element (which SHOULD be
suppled
by PSI/1.0 Clients) SHOULD be set to a value conforming to [RFC3066],
as
recommended by [RFC2277].
----------------------------------------------------------------------
--
13. Security Considerations
This section describes the security threats against PSI/1.0 clients
and
servers. This section specifies the security conformance
requirements
and recommendations for PSI/1.0 implementations. This section
addresses
most security issues by reference to applicable underlying protocol
specifications, for example, [SOAP1.1], [HTTP1.1] and [TLS].
13.1 Internet Threat Model
This section is adapted from section 3 of "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 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.
It's important to realize that the meaning of a PDU is different at
different levels. At the [IP] level, a PDU means an IP packet. At
the
TCP level, it means a TCP segment. At the application layer, it
means some kind of application PDU. For instance, at the level of
[SOAP1.1], it means a single SOAP request or response message, while
at
the [HTTP1.1] level, it means a single HTTP request or response
message.
13.1.1 Passive Attacks
In a passive attack, the attacker reads packets off the network but
does not write them. The simplest way to mount such an attack is to
simply be on the same LAN as the victim. 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.
Passive attacks described in [RFC3552] and considered in PSI/1.0 are:
(1) Confidentiality Violations - PSI/1.0 implementations MUST support
[TLS] for protection against exposure of private business data.
(2) Password Sniffing - PSI/1.0 implementations MUST support [TLS]
and
MUST NOT transfer cleartext passwords over unencrypted channels.
(3) Offline Cryptographic Attacks - PSI/1.0 implementations MUST
support
[TLS] to protect against dictionary attacks against password-
based
challenge/response protocols [HTTPAuth].
13.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], there is no authentication
for
the sender address. Active attacks that involve forging an IP packet
with a false source address are called 'spoofing attacks'.
An IP packet with a forged source address may sometimes be screened
out
by the network infrastructure. For instance, many packet filtering
firewalls screen out all packets with source addresses on the
internal
network that arrive on the external interface. Note that this
provides
no protection against an attacker who is inside the firewall. In
general, protocol designers should assume that attackers can forge IP
packets.
Not all active attacks require forging addresses. For example, the
TCP
SYN denial of service attack does not require disguising the sender's
address. However, it is common practice to disguise one's address in
order to conceal one's identity if an attack is discovered.
Active attacks described in [RFC3552] and considered in PSI/1.0 are:
(1) Message Replay Attacks - PSI/1.0 implementations MUST support
[TLS]
and SHOULD always use at least [TLS] data integrity services for
protection against [SOAP1.1] transaction replays by an attacker
who
has recorded a sequence of messages off the wire.
(2) Message Insertion Attacks - PSI/1.0 implementations MUST support
[TLS] and SHOULD always use at least [TLS] data integrity
services
for protection against message insertion by an attacker. PSI/1.0
implementations over [HTTP1.1] MUST take active measures to
protect
against denial-of-service attacks (for example, numerous incoming
[TCP] connections from the same remote host or remote domain).
(3) Message Deletion Attacks - PSI/1.0 implementations MUST support
[TLS] and SHOULD always use at least [TLS] data integrity
services
for protection against message deletion by an attacker.
(4) Message Modification Attacks - PSI/1.0 implementations MUST
support
[TLS] and SHOULD always use at least [TLS] data integrity
services
for protection against message modification by an attacker.
(5) Man-In-The-Middle Attacks - PSI/1.0 implementations MUST support
[TLS] and SHOULD always use at least [TLS] data integrity
services
and both Client and Server Authentication during [TLS] startup
for protection against man-in-the-middle attacks.
13.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 print jobs typically produce hardcopy, which an inside attacker
can
simply steal.
Network security problems are actually worse in an enterprise
network.
Firewalls and border routers no longer provide any useful protection.
Users and administrators who deploy PSI/1.0 products in enterprise
networks SHOULD enforce the use of [TLS] and SHOULD enforce the use
of
strong Client and Server Authentication during [TLS] startup.
13.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 PSI/1.0 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 PSI/1.0 products in mobile
networks
SHOULD enforce the use of [TLS] and SHOULD enforce the use of strong
Client and Server Authentication during [TLS] startup. [IPSec] also
offers significant security advantages in mobile networks.
13.4 HTTP Threat Model
PSI/1.0 implementations are vulnerable to the following HTTP threats
described in section 15 'Security Considerations' of [HTTP1.1]:
(1) Attacks on personal information - [HTTP1.1] clients and servers
in
PSI/1.0 implementations MUST protect sensitive personal
information,
such as name, email address, etc. (see section 15.1 of
[HTTP1.1]).
(2) Attacks based on file and path names - [HTTP1.1] servers in
PSI/1.0
implementations MUST NOT expose 'nearby' resources that were NOT
explicitly configured for network access by administrators (see
section 15.2 of [HTTP1.1]).
(3) Attacks based on DNS spoofing - [HTTP1.1] clients and servers in
PSI/1.0 implementations SHOULD NOT cache DNS name resolution
results
beyond their time-to-live value (see section 15.3 of [HTTP1.1]).
(4) Attacks based on Location header spoofing - [HTTP1.1] servers in
PSI/1.0 implementations MUST verify the validity of Location and
Content-Location header data when supporting multiple trust
domains
(see section 15.4 of [HTTP1.1]).
(5) Attacks based on Content-Disposition headers - [HTTP1.1] servers
in
PSI/1.0 implementations MUST defend against Content-Disposition
header attacks (see section 15.5 of [HTTP1.1]).
(6) Attacks based on retention of authentication credentials -
[HTTP1.1]
clients in PSI/1.0 implementations SHOULD NOT retain cached user
authentication credentials beyond an administratively configured
idle client time (see section 15.6 of [HTTP1.1]).
(7) Attacks on HTTP Proxies - [HTTP1.1] servers in PSI/1.0
implementations SHOULD take active measures to defend against
man-in-the-middle attacks and single source or distributed
denial-of-service attacks (see section 15.7 of [HTTP1.1]).
----------------------------------------------------------------------
--
[for addition to Normative References section]
[IANA-CHAR] IANA Registry of Charset Tags, archived at:
ftp://ftp.iana.org/assignments/character-sets
[IANA-LANG] IANA Registry of Language Tags, archived at:
ftp://ftp.iana.org/assignments/language-tag-info
[IANA-MIME] IANA Registry of Media Types, archived at:
ftp://ftp.iana.org/assignments/media-types
[IP] Postel, J. "Internet Protocol", RFC 791, September 1981.
[IPSec] Kent, S., Atkinson, R. "Security Architecture for the
Internet
Protocol", RFC 2401, November 1998.
[SOAP1.2] See [SOAP1.2-0], [SOAP1.2-1], and [SOAP1.2-2].
[SOAP1.2-0] "SOAP Version 1.2 Part 0: Primer",
W3C Recommendation, June 2003.
[SOAP1.2-1] "SOAP Version 1.2 Part 1: Messaging Framework",
W3C Recommendation, June 2003.
[SOAP1.2-2] "SOAP Version 1.2 Part 2: Adjuncts",
W3C Recommendation, June 2003.
[TCP] Postel, J. "Transmission Control Protocol", RFC 793, September
1981.
[WSDL1.2] See [WSDL1.2-1], [WSDL1.2-2], and [WSDL1.2-3] below.
[WSDL1.2-1] "Web Services Description Language (WSDL) Version 1.2 --
Part 1: Core Language", W3C Working Draft, June 2003.
[WSDL1.2-2] "Web Services Description Language (WSDL) Version 1.2 --
Part 2: Message Patterns", W3C Working Draft, June 2003.
[WSDL1.2-3] "Web Services Description Language (WSDL) Version 1.2 --
Part 3: Bindings", W3C Working Draft, June 2003.
[XML] See [XML1.0] and [XML1.1] below.
[XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)",
W3C Recommendation, October 2000.
[XML1.1] "Extensible Markup Language (XML) 1.1",
W3C Candidate Recommendation, October 2002.
[XSD] See [XSD-1] and [XSD-2] below.
[XSD-1] "XML Schema Part 1: Structures", W3C Recommendation, May
2001.
[XSD-2] "XML Schema Part 2: Datatypes", W3C Recommendation, May
2001.
[for addition to Informative References section]
[ISO639] See [ISO639-1] and [ISO639-2] below.
[ISO639-1] "Codes for the Representation of Names of Languages --
Part 1: Alpha-2 Code", ISO/IEC 639-1, 2000.
[ISO639-2] "Codes for the Representation of Names of Languages --
Part 2: Alpha-3 Code", ISO/IEC 639-2, 1998.
[ISO3166] See [ISO3166-1] and [ISO3166-2] below.
[ISO3166-1] "Codes for the Representation of Names of Countries and
their Subdivisions, Part 1: Country Codes", ISO/ISO 3166-
1,
1997.
[ISO3166-2] "Codes for the Representation of Names of Countries and
their Subdivisions, Part 2: Country Subdivision Codes",
ISO/ISO 3166-2, 1998.
[RFC2046] Freed, N., Borenstein, N. "MIME Part Two: Media Types",
RFC 2046, November 1996.
[RFC2048] Freed, N., Borenstein, N. "MIME Part Four: Registration
Procedures", RFC 2048, November 1996.
[RFC2277] Alvestrand, H. "IETF Policy on Character Sets and
Languages",
RFC 2277, January 1998.
[RFC2279] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2978] Freed, N., Postel, J. "IANA Charset Registration
Procedures",
RFC 2978, October 2000.
[RFC3066] Alvestrand, H. "Tags for the Identification of Languages",
RFC 3066, January 2001.
Ira McDonald (Musician / Network Software Architect)
Blue Roof Music / High North Inc
PO Box 221
Grand Marais, MI 49839
Phone: +1-906-494-2434
Email: imcdonald at sharplabs.com