Subject: MIME Type Registration Request Approval: application/nss

From: IESG Secretary <[email-masked]>
Date: Wed, 23 Feb 2005 12:23:55 -0500

The IESG has approved a request to register the "application/nss"
MIME media type in the standards tree. This media type is a product of
ITU-T Study Group 11.

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

Encoding considerations: binary (Note: Data is in US-ASCII range.)

Security considerations: 

NSS has the potential to disclose private customer information
and the potential for modification of NSS bodies during message
transport to manipulate call setup, mid-call events, or call 
release. Modification means the addition of an NSS body where
none existed, the removal of an NSS body where one existed, or 
the changing of contents of existing NSS bodies in messages. 
NSS can reveal information about telephone subscribers that is 
requested to remain private. Security mechanisms must be 
provided to meet privacy agreements and regulations. 

NSS can be deployed as an interdomain signaling mechanism and 
may be subject to trust relationships and agreements between 
administrative domains as well as legal requirements in various 
jurisdictions. NSS can affect routing of telephone calls and 
associated billing. Security mechanisms must be provided to 
control fraud, malicious intents, and unintended consequences.

Such mechanisms include the ability to selectively filter or map
and forward each information element within NSS upon entry or exit
of an administrative domain. It is expected that nodes performing
such functions will be User Agents, such as gateway nodes or 
IP-based Application servers acting on behalf of users. Note that
RFC 3261 Section 16.6 says: "The proxy MUST NOT add to, modify, 
or remove the message body." That includes NSS bodies. All 
information from unauthenticated entities must be validated and 
authorized before being mapped and forwarded in subsequent signaling
messages. Such checks are particularly needed when information is 
mapped to/from SIP headers. Note, however, that the intent of NSS
is to carry data that would be mutually exclusive with the data 
capable of being carried in SIP headers.

When encapsulated by SIP, the integrity and confidentiality of SIP 
messages containing NSS bodies must be addressed. SIP mandates that 
Transport Layer Security (TLS) must be supported. The Internet 
Protocol Security (IPSEC) mechanisms may be used as an alternative 
on signaling hops between nodes trusted to handle PSTN signaling. 
TLS and IPSEC are discussed in Section 26 of the Session 
Initiation Protocol RFC 3261. However, trusted nodes would need 
to specify and agree on the security suites to be used with IPSEC.
See RFC 3324 for discussion on trust domains and related security
requirements.

When intermediate hops are not trusted, end-to-end integrity and 
confidentiality may be addressed using S/MIME:

RFC 3850, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.1 Certificate Handling", July 2004.

RFC 3851, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.1 Message Specification", July 2004.

RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004.

RFC 3853, "S/MIME Advanced Encryption Standard (AES) Requirement 
for the Session Initiation Protocol (SIP)", July 2004.

NSS MIME bodies should be secured using S/MIME to mitigate
concerns with authentication of the sender, integrity protection 
during transit, and confidentiality protection from disclosure to 
unauthorized third parties. NSS endpoints must support S/MIME 
signatures and should support S/MIME encryption. 

For H.323-based encapsulation of NSS bodies, the security mechanisms
of ITU-T Recommendation H.235, "Security and encryption for H-series
(H.323 and other H.245-based) multimedia terminals", August 2003, must 
be used to provide integrity and confidentiality.

NSS consists of well defined message types and parameters. Arbitrary 
content or directives within field values is not permitted.

NSS does not employ "active content."

NSS contains fields which instruct whether privacy data such as 
calling party's number is to be presented or restricted.

NSS is used without and is silent about compression. Use of compression 
in conjunction with NSS does not present any security issues.

Interoperability considerations: Compatibility mechanisms are 
defined in Q.1980.1.

Published specification: ITU-T Recommendation Q.1980.1, "The Narrowband 
Signalling Syntax (NSS) - Syntax Definition", December 2004. Link:

http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-Q
.1980.1

Applications which use this media type: Applications in PSTN
Gateways and call control application servers.

Additional Information:

Magic numbers: None

File Extensions: None

Macintosh File Type Codes: None

Object Identifiers: {itu-t(0) recommendation(0) q(17) 1980 1}
(0.0.17.1980.1)
See ITU-T Recommendation H.323 Annex M.4 "Tunneling of 
Narrowband Signalling Syntax (NSS) for H.323", December 2004.

Person to contact for further information:

Name: Michael Hammer
E-Mail: [email-masked]

Intended Usage: COMMON

Restrictions on usage: None

Author: ITU-T Study Group 11

Change controller: ITU-T Study Group 11

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce