Network Working Group M. Wahl INTERNET-DRAFT ISODE Consortium Expires in six months from 23 February 1996 Intended Category: Informational A MIME Content-Type for ASN.1 PDUs 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract The Basic Encoding Rules (BER) [1] are a transfer syntax used in several Internet communications protocols, including LDAP [2] and SNMP [3]. This document describes how a series of BER-encoded PDUs can be represented in a MIME [4] content type. This may be used to transport a side of a communications protocol over protocols which carry MIME contents, such as SMTP [5]. 3. MIME Type Registration To: ietf-types@uninett.no, IANA@isi.edu Subject: Registration of MIME Media Type application/ber-stream 3.1 MIME media type name application 3.2 MIME subtype name ber-stream 3.3 Required parameters protocol INTERNET-DRAFT A MIME Content Type for ASN.1 PDUs February 1996 3.3.1 Required parameter "protocol" The "protocol" parameter contains the dotted decimal representation of an OBJECT IDENTIFIER. The OBJECT IDENTIFIER uniquely identifies the protocol in which the types for the data values included in the content are defined. The OBJECT IDENTIFIER must be one that has been defined by one of the following procedures: - all existing protocols which operate directly above TCP or UDP with a well known port number assigned by the IANA have an identifier already defined. A protocol over TCP has an identifier of the form ., and a protocol over UDP has an identifier of the form ., where applTCPProtoID and applUDPProtoID are defined in RFC 1565 [6], and port is the TCP or UDP port number. For example, LDAP [2] would have the following protocol: 1.3.6.1.2.1.27.4.389 - an enterprise (e.g. an organization) which has been assigned a SMI network management private enterprise code by the IANA may use this as a prefix for defining their own protocols. For example, if an enterprise was assigned private enterprise code 1466 by IANA, they might define their protocols as 1.3.6.1.4.1.1466.1, 1.3.6.1.4.1.1466.2, 1.3.6.1.4.1.1466.3 etc. - Protocols assigned under arcs managed or delegated by ISO/ITU are also permitted. (E.g. An organization which has an ANSI OBJECT IDENTIFER assigned to it may use theirs as a prefix.) To aid interoperability, unassigned identifiers are not permitted, and nonnumeric string representations of identifier components must not be used. 3.4 Optional parameters references 3.4.1 Optional parameter "references" The "references" parameter contains a which is a Content-ID of another MIME content to which this one refers. This parameter is not the Content-ID of this content; the Content-ID of this content is carried in the "Content-ID" header field as is normal for MIME. If the protocol is a request-response interaction, in the request content the "references" parameter should be absent, and a Content-ID should be present, and in the response content the "references" parameter should hold the Content-ID of the request content. INTERNET-DRAFT A MIME Content Type for ASN.1 PDUs February 1996 3.5 Encoding considerations As specified by the Content-Transfer-Encoding header field. "application/ber-stream" will need a Content-Transfer-Encoding of base64 or quoted-printable when carried in 7-bit MIME, since the output of BER uses the full range of possible byte values. It is recommended that base64 be generated. 3.6 Security considerations Unless the content is protected using mechanisms such as those defined in MOSS [7], it is subject to viewing and modification in transit. If a request-response protocol is being used over mail, it will be subject to the same attacks as a connectionless transport mechanism (such as replay). 3.7 Interoperability considerations: The protocol which is referenced by the "protocol" parameter defines the ASN.1 types for the data values. It also defines the valid ordering of the data values in a content: for example that a bind PDU must come first, followed by zero or more request PDUs, followed by an unbind PDU. A protocol may also limit the subset of BER which may be used to encode the values. For example, the LDAP [2] protocol forbids a number of possible encodings, including constructed encodings for strings. 3.8 Published specification: The "application/ber-stream" contains a series of zero or more ASN.1 data values. Each data value is encoded according to the Basic Encoding Rules (BER). As each BER PDU is self-delimiting, multiple data values may be concatenated. Note however that when there is more than one encoded data value in a content, there is NO tag or length octets concerning the content as a whole. ASN.1 and BER are defined in International Standards and ITU Recommendations. 3.9 Person & email address to contact for further information: Mark Wahl ISODE Consortium Inc. 3925 West Braker Lane #333 Austin TX 78759 USA M.Wahl@isode.com 3.10 Author/Change controller: Mark Wahl ISODE Consortium Inc. 3925 West Braker Lane #333 Austin TX 78759 USA M.Wahl@isode.com INTERNET-DRAFT A MIME Content Type for ASN.1 PDUs February 1996 4. Example In this example an SNMP trap is carried as part of an email message. This protocol is identified by an OBJECT IDENTIFIER based on UDP port 162 (assigned in RFC 1157). The content of the application/ber-stream is the base64 representation of a BER encoding of a single ASN.1 data value, of type RFC1157-SNMP.Message. The Message.data would contain a "PDUs" value of choice "trap". To: manager@nic.any.net From: manager@nic.another.net Subject: FYI your router rebooted Content-Type: multipart/mixed; boundary="woowoo" MIME-Version: 1.0 --woowoo Content-Type: text/plain Your router rebooted yesterday. When it restarted it sent this trap to my management station. You may wish to take a look at it. --woowoo Content-Type: application/ber-stream; protocol="1.3.6.1.2.1.27.5.162" Content-Transfer-Encoding: base64 MB8CAQAEAKQYBgUownoFAUAEfwAAAQIBAAIBAEMBADAA --woowoo-- 5. Security Considerations Security considerations are discussed in the "Security considerations" section (3.6) of the MIME media type request. 6. Bibliography [1] Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). CCITT Recommendation X.209, 1988. [2] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995. [3] M. Schoffstall, M. Fedor, J. Davin, J. Case, "A Simple Network Management Protocol (SNMP)", RFC 1157, May 1990. [4] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. [5] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, August 1982. INTERNET-DRAFT A MIME Content Type for ASN.1 PDUs February 1996 [6] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC 1565, January 1994. [7] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security Services", RFC 1848, October 1995. 7. Author's Address Mark Wahl ISODE Consortium Inc. 3925 West Braker Lane #333 Austin TX 78759 USA Phone: +1 (512) 305 0280 Email: M.Wahl@isode.com