Registration of media type "application/nss"

Mike Hammer mhammer at cisco.com
Thu Dec 30 19:52:31 CET 2004


This email requests that the IESG approve the assignment of the 
media subtype as described in the registration template below.

Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
            Media Type Specifications and Registration Procedures, 
            Section 5, Registration Procedures,
            Section 10, Registration Template.

To: ietf-types at iana.org
Subject: Registration of media type "application/nss"

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

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

Restrictions on usage: none

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.  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.

   When encapsulated by SIP, the integrity and confidentiality of SIP 
   messages containing NSS bodies MUST be addressed through the use of 
   Transport Layer Security (TLS) or Internet Protocol Security (IPSEC) 
   mechanisms as described in the Session Initiation Protocol RFC 3261
   on signaling hops between nodes trusted to handle PSTN signaling.  
   When intermediate hops are not trusted, end-to-end integrity and 
   confidentiality may be addressed using RFC 2633, "Secure/Multipurpose
   Internet Mail Extensions (S/MIME) Version 3 Message Specification", 
   June 1999.  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.

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 "Tunnelling of 
      Narrowband Signalling Syntax (NSS) for H.323", December 2004.

   Intended Usage:  COMMON

Person to contact for further information:

   Name:  Michael Hammer
   E-Mail:  mhammer at cisco.com
   Author/Change controller:  ITU-T Study Group 11

END


More information about the Ietf-types mailing list