summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3114.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3114.txt')
-rw-r--r--doc/rfc/rfc3114.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3114.txt b/doc/rfc/rfc3114.txt
new file mode 100644
index 0000000..0d9449c
--- /dev/null
+++ b/doc/rfc/rfc3114.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group W. Nicolls
+Request for Comments: 3114 Forsythe Solutions
+Category: Informational May 2002
+
+
+ Implementing Company Classification Policy
+ with the S/MIME Security Label
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document discusses how company security policy for data
+ classification can be mapped to the S/MIME security label. Actual
+ policies from three companies provide worked examples.
+
+1. Introduction
+
+ Security labels are an optional security service for S/MIME. A
+ security label is a set of security information regarding the
+ sensitivity of the content that is protected by S/MIME encapsulation.
+ A security label can be included in the signed attributes of any
+ SignedData object. A security label attribute may be included in
+ either the inner signature, outer signature, or both. The syntax and
+ processing rules for security labels are described in RFC 2634 [ESS].
+
+ The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
+ 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
+ document are to be interpreted as described in RFC 2119 [MUSTSHOULD].
+
+1.1 Information Classification Policies
+
+ Information is an asset, but not all information has the same value
+ for a business. Not all information needs to be protected as
+ strongly as other information.
+
+ Research and development plans, marketing strategies and
+ manufacturing quality specifications developed and used by a company
+ provide competitive advantage. This type of information needs
+
+
+
+
+Nicolls Informational [Page 1]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ stronger protective measures than other information, which if
+ disclosed or modified, would cause moderate to severe damage to the
+ company.
+
+ Other types of information such as internal organization charts,
+ employee lists and policies may need little or no protective measures
+ based on value the organization places on it.
+
+ A corporate information classification policy defines how its
+ information assets are to be protected. It provides guidance to
+ employees on how to classify information assets. It defines how to
+ label and protect an asset based on its classification and state
+ (e.g., facsimile, electronic transfer, storage, shipping, etc.).
+
+1.2 Access Control and Security Labels
+
+ "Access control" is a means of enforcing authorizations. There are a
+ variety of access control methods that are based on different types
+ of policies and rely on different security mechanisms.
+
+ - Rule based access control is based on policies that can be
+ algorithmically expressed.
+
+ - Identity based access control is based on a policy which applies
+ explicitly to an individual person or host entity, or to a defined
+ group of such entities. Once identity has been authenticated, if
+ the identity is verified to be on the access list, then access is
+ granted.
+
+ - Rank base access control is based on a policy of hierarchical
+ positions in an organization. It is based on who you are in the
+ company structure. A rank-based policy would define what
+ information that the position of Partner or Senior Consultant could
+ access.
+
+ - Role based access control is based on a policy of roles in an
+ organization. It may or may not be hierarchical. It is based on
+ who you are in the company. The role-based policy would define
+ what information that the role of Database Administrator, Network
+ Administrator, Mailroom Clerk or Purchaser could access.
+
+ Rule, rank and role-based access control methods can rely on a
+ security label as the security mechanism to convey the sensitivity or
+ classification of the information. When processing an S/MIME
+ encapsulated message, the sensitivity information in the message's
+ security label can be compared with the recipient's authorizations to
+ determine if the recipient is allowed to access the protected
+ content.
+
+
+
+Nicolls Informational [Page 2]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ An S/MIME security label may be included as a signed attribute in the
+ inner (or only) signature or the outer signature. In the case of a
+ triple-wrapped message as defined in RFC 2634, the inner signature
+ would be used for access control decisions related to the plaintext
+ original content, while the outer signature would be used for access
+ control decisions related to the encrypted message.
+
+1.3 User Authorizations
+
+ Users need to be granted authorizations to access information that
+ has been classified by an authority. The sending and receiving
+ agents need to be able to securely determine the user's
+ authorizations for access control processing.
+
+ X.509 [X.509] and the Internet profile for X.509 certificates
+ [CERTCRL] do not define the means to represent and convey
+ authorizations in a certificate.
+
+ X.501 [X.501] defines how to represent authorization in the form of a
+ clearance attribute. The clearance attribute identifies the security
+ policy in force to which a list of possible classifications and
+ security categories relates.
+
+ X.501 also notes two means for binding the clearance to a named
+ entity: an Attribute Certificate and a Certificate extension field
+ (e.g., within the subjectDirectoryAttribute extension).
+
+ RFC 3281 [AC509] defines a profile of X.509 Attribute Certificate
+ (AC) suitable for use with authorization information within Internet
+ Protocols. One of the defined attributes is Clearance, which carries
+ clearance (security labeling) information about the AC owner. The
+ syntax for Clearance is imported from X.501.
+
+2. Developed Examples
+
+2.1 Classification Policies
+
+ The following describes the information classification policies in
+ effect at 3 companies.
+
+2.1.1 Amoco Corporation
+
+ The description for the Amoco information classification policy was
+ taken from the Amoco Computer Security Guidelines. Amoco classifies
+ its information assets based on confidentiality and integrity and
+ defines 3 hierarchical classifications for each. The confidentiality
+
+
+
+
+
+Nicolls Informational [Page 3]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ and integrity polices are independent, so either or both may be
+ applied to the information. Amoco also defines an availability
+ classification for time critical information.
+
+ HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will
+ cause the company severe financial, legal or reputation damage.
+ Examples: Certain acquisitions, bid economics, negotiation
+ strategies.
+
+ CONFIDENTIAL - Information whose unauthorized disclosure may cause
+ the company financial, legal, or reputation damage. Examples:
+ Employee Personnel & Payroll Files, some interpreted Exploration
+ Data.
+
+ GENERAL - Information that, because of its personal, technical, or
+ business sensitivity is restricted for use within the company.
+ Unless otherwise classified, all information within Amoco is in this
+ category.
+
+ MAXIMUM - Information whose unauthorized modification and destruction
+ will cause the company severe financial, legal, or reputation damage.
+
+ MEDIUM - Information whose unauthorized modification and destruction
+ may cause the company financial, legal, or reputation damage.
+ Examples: Electronic Funds, Transfer, Payroll, and Commercial Checks.
+
+ MINIMUM - Although an error in this data would be of minimal
+ consequence, this is still important company information and
+ therefore will require some minimal controls to ensure a minimal
+ level of assurance that the integrity of the data is maintained.
+ This applies to all data that is not placed in one of the above
+ classifications. Examples: Lease Production Data, Expense Data,
+ Financial Data, and Exploration Data.
+
+ CRITICAL - It is important to assess the availability requirements of
+ data, applications and systems. A business decision will be required
+ to determine the length of unavailability that can be tolerated prior
+ to expending additional resources to ensure the information
+ availability that is required. Information should be labeled
+ "CRITICAL" if it is determined that special procedures should be used
+ to ensure its availability.
+
+2.1.2 Caterpillar, Inc.
+
+ The description for the Caterpillar information classification policy
+ is taken from the Caterpillar Information Protection Guidelines.
+ Caterpillar classifies its information assets based on
+ confidentiality and defines 4 hierarchical classifications.
+
+
+
+Nicolls Informational [Page 4]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ Caterpillar Confidential Red - Provides a significant competitive
+ advantage. Disclosure would cause severe damage to operations.
+ Relates to or describes a long-term strategy or critical business
+ plans. Disclosure would cause regulatory or contractual liability.
+ Disclosure would cause severe damage to our reputation or the public
+ image. Disclosure would cause a severe loss of market share or the
+ ability to be first to market. Disclosure would cause a loss of an
+ important customer, shareholder, or business partner. Disclosure
+ would cause a long-term or severe drop in stock value. Strong
+ likelihood somebody is seeking to acquire this information.
+
+ Caterpillar Confidential Yellow - Provides a competitive advantage.
+ Disclosure could cause moderate damage to the company or an
+ individual. Relates to or describes an important part of the
+ operational direction of the company over time. Important technical
+ or financial aspects of a product line or a business unit.
+ Disclosure could cause a loss of Customer or Shareholder confidence.
+ Disclosure could cause a temporary drop in stock value. A likelihood
+ that somebody could seek to acquire this information.
+
+ Caterpillar Confidential Green - Might provide a business advantage
+ over those who do not have access to the same information. Might be
+ useful to a competitor. Not easily identifiable by inspection of a
+ product. Not generally known outside the company or available from
+ public sources. Generally available internally. Little competitive
+ interest.
+
+ Caterpillar Public - Would not provide a business or competitive
+ advantage. Routinely made available to interested members of the
+ General Public. Little or no competitive interest.
+
+2.1.3 Whirlpool Corporation
+
+ The description for the Whirlpool information classification policy
+ is taken from the Whirlpool Information Protection Policy. Whirlpool
+ classifies its information assets based on confidentiality and
+ defines 3 hierarchical classifications. The policy states that:
+
+ "All information generated by or for Whirlpool, in whatever form,
+ written, verbal, or electronic, is to be treated as WHIRLPOOL
+ INTERNAL or WHIRLPOOL CONFIDENTIAL. Classification of information in
+ either category depends on its value, the impact of unauthorized
+ disclosure, legal requirements, and the manner in which it needs to
+ be used by the company. Some WHIRLPOOL INTERNAL information may be
+ authorized for public release."
+
+
+
+
+
+
+Nicolls Informational [Page 5]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information,
+ the unauthorized disclosure or compromise of which would likely have
+ an adverse impact on the company's competitive position, tarnish its
+ reputation, or embarrass an individual. Examples: Customer,
+ financial, pricing, or personnel data; merger/acquisition, product,
+ or marketing plans; new product designs, proprietary processes and
+ systems.
+
+ WHIRLPOOL INTERNAL - All forms of proprietary information originated
+ or owned by Whirlpool, or entrusted to it by others. Examples:
+ Organization charts, policies, procedures, phone directories, some
+ types of training materials.
+
+ WHIRLPOOL PUBLIC - Information officially released by Whirlpool for
+ widespread public disclosure. Example: Press releases, public
+ marketing materials, employment advertising, annual reports, product
+ brochures, the public web site, etc.
+
+ The policy also states that privacy markings are allowable.
+ Specifically:
+
+ For WHIRLPOOL INTERNAL, additional markings or caveats are optional
+ at the discretion of the information owner.
+
+ For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as
+ necessary to comply with regulatory or heightened security
+ requirements. Examples: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL,
+ ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____,
+ COVERED BY A NON-ANALYSIS AGREEMENT.
+
+2.2 S/MIME Classification Label Organizational Examples
+
+ RFC 2634 [ESS] defines the ESSSecurityLabel syntax and processing
+ rules. This section builds upon those definitions to define detailed
+ example policies.
+
+2.2.1 Security Label Components
+
+ The examples are detailed using the various components of the
+ eSSSecurityLabel syntax.
+
+2.2.1.1 Security Policy Identifier
+
+ A security policy is a set of criteria for the provision of security
+ services. The eSSSecurityLabel security-policy-identifier is used to
+ identify the security policy in force to which the security label
+ relates. It indicates the semantics of the other security label
+ components.
+
+
+
+Nicolls Informational [Page 6]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ For the example policies, the following security policy object
+ identifiers are defined:
+
+ -- S/MIME Working Group Object Identifier Registry
+ id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
+
+ -- S/MIME Test Security Policy Arc
+ id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
+
+ -- Test Security Policies
+ id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
+ id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
+ id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }
+
+2.2.1.2 Security Classification
+
+ The security classification values and meanings are defined by the
+ governing company policies. The security-classification values
+ defined are hierarchical and do not use integers 0 through 5.
+
+ Amoco-SecurityClassification ::= INTEGER {
+ amoco-general (6),
+ amoco-confidential (7),
+ amoco-highly-confidential (8) }
+
+ Caterpillar-SecurityClassification ::= INTEGER {
+ caterpillar-public (6),
+ caterpillar-green (7),
+ caterpillar-yellow (8),
+ caterpillar-red (9) }
+
+ Whirlpool-SecurityClassification ::= INTEGER {
+ whirlpool-public (6),
+ whirlpool-internal (7),
+ whirlpool-confidential (8) }
+
+2.2.1.3 Privacy Mark
+
+ Privacy marks are specified the Whirlpool policy. The policy
+ provides examples of possible markings but others can be defined by
+ users as necessary (though no guidance is given). The Whirlpool
+ policy provides the following examples: MAKE NO COPIES, THIRD PARTY
+ CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION
+ LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.
+
+
+
+
+
+
+Nicolls Informational [Page 7]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ The Amoco policy does not identify any privacy marks but the
+ classification labels defined for availability and integrity would be
+ most appropriately displayed here. The CRITICAL, MAXIMUM, MEDIUM,
+ and MINIMUM labels are examples of information classifications that
+ are not used for access control.
+
+ In general, the privacy marks should provide brief but clear
+ direction to the user on how to handle the information.
+
+2.2.1.4 Security Categories
+
+ Security categories or caveats are not specified in any of the sample
+ policies. However, they are used in at least 2 of the companies.
+ Though the security categories are not defined formally in their
+ security policies, once locally defined they are formal and are to be
+ enforced. The security categories are defined when necessary to
+ provide identifiable proprietary information more granular access
+ control. A category can be based organizationally or by project
+ (i.e., Legal Only or Project Vallor).
+
+2.2.1.4.1 Syntax
+
+ Security categories are represented in the RFC 2634 ESSSecurityLabel
+ (to specify the sensitivity of labeled data) and X.501 Clearance
+ attribute (to specify an entity's authorizations) using the following
+ syntax.
+
+ SecurityCategories ::= SET SIZE (1..ub-security-categories)
+ OF SecurityCategory
+
+ ub-security-categories INTEGER ::= 64
+
+ SecurityCategory ::= SEQUENCE {
+ type [0] OBJECT IDENTIFIER
+ value [1] ANY DEFINED BY type } -- defined by type
+
+ One example of a SecurityCategory syntax is SecurityCategoryValues,
+ as follows.
+
+ When id-securityCategoryValues is present in the SecurityCategory
+ type field, then the SecurityCategory value field could take the form
+ of:
+
+ SecurityCategoryValues ::= SEQUENCE OF UTF8String
+
+
+
+
+
+
+
+Nicolls Informational [Page 8]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+2.2.1.4.2 Use
+
+ An organization will define a securityCategoryType OID representing
+ the syntax for representing a security category value within their
+ security policy.
+
+ For the example security category syntax, a UTF8String is used to
+ convey the security category value that applies to the labeled
+ message. Access MUST be restricted to only those entities who are
+ authorized to access every SecurityCategoryValue. Access is
+ authorized if the ESSSecurityLabel SecurityCategoryValue EXACTLY
+ matches the Clearance SecurityCategoryValue.
+
+2.2.2 Attribute Owner Clearance
+
+ The security clearance and category authorizations for the user are
+ defined in the clearance attribute.
+
+2.2.2.1 Amoco User
+
+ Clearance:
+ policyId: 1 2 840 113549 1 9 16 7 1
+ classList: amoco-general (6),
+ amoco-confidential (7),
+ amoco-highly-confidential (8)
+
+2.2.2.2 Caterpillar User
+
+ Clearance:
+ policyId: 1 2 840 113549 1 9 16 7 2
+ classList: caterpillar-public (6),
+ caterpillar-confidential-green (7),
+ caterpillar-confidential-yellow (8),
+ caterpillar-confidential-red (9)
+
+2.2.2.3 Whirlpool User
+
+ Clearance:
+ policyId: 1 2 840 113549 1 9 16 7 3
+ classList: whirlpool-public (6),
+ whirlpool-internal (7),
+ whirlpool-confidential (8)
+
+
+
+
+
+
+
+
+
+Nicolls Informational [Page 9]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+2.2.3 Security Category Example
+
+ This section includes an example RFC 2634 ESSSecurityLabel including
+ the example Security Category syntax. This section also includes
+ example X.501 Clearance attributes. One of the example Clearance
+ attributes includes a set of authorizations that pass the access
+ control check for the example ESSSecurityLabel. The other example
+ Clearance attributes each include a set of authorizations that fail
+ the access control check for the example ESSSecurityLabel.
+
+ These examples use the id-tsp-TEST-Whirlpool OID defined in section
+ 2.2.1.1. Assume that the security policy identified by id-tsp-TEST-
+ Whirlpool defines one securityCategoryType OIDs as follows:
+
+ id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }
+
+ Example ESSSecurityLabel:
+ security-policy-identifier: id-tsp-3
+ security-classification: 8
+ privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
+ security-categories: SEQUENCE OF SecurityCategory
+
+ SecurityCategory #1
+ type: id-tsp-4
+ value: LAW DEPARTMENT USE ONLY
+
+ Example Clearance Attribute #1 (passes access control check):
+
+ Clearance:
+ policyId: id-tsp-3
+ classList BIT STRING: Bits 6, 7, 8 are set to TRUE
+ securityCategories: SEQUENCE OF SecurityCategory
+
+ SecurityCategory #1
+ type: id-tsp-4
+ value: LAW DEPARTMENT USE ONLY
+
+ Example Clearance Attribute #2 (fails access control check because
+ SecurityCategoryValues do not match):
+
+ Clearance:
+ policyId: id-tsp-3
+ classList BIT STRING: Bits 6, 7, 8 are set to TRUE
+ securityCategories: SEQUENCE OF SecurityCategory
+
+
+
+
+
+
+
+Nicolls Informational [Page 10]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+ SecurityCategory #1:
+ type: id-tsp-4
+ value: HUMAN RESOURCES USE ONLY
+
+2.2.4 Additional ESSSecurityLabel Processing Guidance
+
+ An implementation issue can be the mapping of the security label
+ values to displayable characters. This is an issue for users who
+ want to develop and retire their own classifications and categories
+ on a regular basis and when the values are encoded in non-human
+ readable form. Applications should provide a means for the
+ enterprise to manage these changes. The practice of hard coding the
+ mapping into the applications is discouraged.
+
+ This issue is viewed as local issue for the application vendor, as
+ the solution does not need to be interoperable between vendors.
+
+ An approach is the use of a Security Policy Information File (SPIF)
+ [ISO15816]. A SPIF is a construct that conveys domain-specific
+ security policy information. It is a signed object to protect it
+ from unauthorized changes and to authenticate the source of the
+ policy information. It contains critical display information such as
+ the text string for security classifications and security categories
+ to be displayed to the user, as well as additional security policy
+ information.
+
+ Another implementation issue can be obtaining the recipient's
+ certificate when sending a signed-only message with a security label.
+ Normally the recipient's certificate is only needed when sending an
+ encrypted message. Applications will need to be able to retrieve the
+ recipient's certificate so that the recipient's clearance information
+ is available for the access control check.
+
+3. Security Considerations
+
+ All security considerations from RFC 2630 [CMS] and RFC 2634 [ESS]
+ apply to applications that use procedures described in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nicolls Informational [Page 11]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+References
+
+ [AC509] Farrell, S. and R. Housley, "An Internet Attribute
+ Certificate Profile for Authorization", RFC 3281, April
+ 2002.
+
+ [CERTCRL] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
+ June 1999.
+
+ [ESS] Hoffman, P., Editor, "Enhanced Security Services for
+ S/MIME", RFC 2634, June 1999.
+
+ [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [X.501] "ITU-T Recommendation X.501: Information Technology -
+ Open Systems Interconnection - The Directory: Models",
+ 1993.
+
+ [X.509] "ITU-T Recommendation X.509 (1997 E): Information
+ Technology - Open Systems Interconnection - The
+ Directory: Authentication Framework", June 1997.
+
+ [ISO15816] "Information Technology - Security Techniques - Security
+ Information Objects for Access Control", ISO/IEC FDIS
+ 15816:2000.
+
+Acknowledgements
+
+ I would like to thank Russ Housley for helping me through the process
+ of developing this document, John Pawling for his technical
+ assistance and guidance, and Dan Quealy for his security policy
+ expertise. I would like to thank Ernst & Young LLP and Telenisus for
+ supporting the development of this document while I was employed
+ there. I would also like to thank the good people at Amoco (bp),
+ Caterpillar and Whirlpool who allowed me to use their policies as the
+ real examples that make this document possible.
+
+ Caterpillar and Whirlpool were each asked if they would like to
+ provide contacts in regards to their security policies, but declined
+ the offer.
+
+
+
+
+
+Nicolls Informational [Page 12]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+Author's Address
+
+ Weston Nicolls
+ Forsythe Solutions
+ 7500 Frontage Rd
+ Skokie, IL 60077
+
+ Phone: (847) 763-2370
+ EMail: wnicolls@forsythesolutions.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nicolls Informational [Page 13]
+
+RFC 3114 Implementing Company Classification Policy May 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nicolls Informational [Page 14]
+