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@sharplabs.com
This archive was generated by hypermail 2b29 : Sun Oct 19 2003 - 19:53:17 EDT