|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 27, 2007.
Copyright © The Internet Society (2006).
The NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) defines an access control list model that is close to how access control lists work on Windows. POSIX [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) defines a file access control mechanism, and mechanisms which can be used to extend it. The NFSv4 specification does not specify in sufficient detail how NFSv4 ACLs map to POSIX. This draft fills this gap by defining the additional concepts and mechanisms needed to achieve a functional and correct mapping.
The NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) defines its own access control list model, including ACL semantics. The model chosen is much closer to Windows ACLs than to how the POSIX permission model works. POSIX compliant systems that implement a permission model richer than POSIX permissions must do so within the extension mechanisms that POSIX allows in order not to violate assumptions that POSIX applications may rightfully make about the system behavior; violating these assumptions would lead to potential security holes. Unfortunately, the definitions in the NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.), while sufficient for specifying the interactions with systems that do not go beyond the POSIX permission model, are not fully consistent with the extension mechanisms POSIX defines, which has lead to confusion and subtly POSIX non-compliant implementations.
The purpose of this document is to clarify the relationship between NFSv4 ACLs and POSIX. Since understanding the POSIX file access control mechanisms is key to understanding this relationship, Section 3 (POSIX Definitions) repeats the definitions of POSIX 1003.1-2004 [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) relevant to file access control, before the following sections go on to discuss how NFSv4 ACLs relate to these concepts. This is followed by implementation considerations, and some notes on the interoperability between NFSv4 ACLs, “POSIX” ACLs, and Windows ACLs.
This document is a work in progress; part of the text still needs to be written, particularly towards the end of the document. The document is being made available in this form because most of the concepts underlying the design are already sufficiently well described, to provide some details on the design of the Linux prototype implementation, and in order to facilitate further discussion.
The text representation used for ACLs in this document consists of one ACE per line, and a colon separated list of the who, access mask, flag, and type ACE fields on each line.
The ACE who field is represented by a literal who string (e.g., OWNER@, GROUP@, user@domain, group@domain).
The ACE access mask field is represented by a list of slash separated access mask names (e.g., READ_DATA/WRITE_ACL/EXECUTE).
The ACE flag field is represented by a list of slash separated flag names (e.g., FILE_INHERIT_ACE/IDENTIFIER_GROUP).
The ACE type field is represented by a type name (ALLOW, DENY, AUDIT, or ALARM).
Masks as introduced in Section 4.5 (Effective vs. Disabled Access Mask Flags) are sets of ACE access mask bits. (They are not implemented as ACEs.) They are represented by a list of slash separated access mask names, like ACE access mask fields.
It is instrumental to understand the POSIX permission model and the extension mechanisms POSIX defines in order to discuss how the different aspects of ACLs fit into this framework. In this section we give the literal definitions from POSIX 1003.1-2004 [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.), to refer to in the next sections.
- File Permission Bits
- Information about a file that is used, along with other information, to determine whether a process has read, write, or execute/search permission to a file. The bits are divided into three parts: owner, group, and other. Each part is used with the corresponding file class of processes. These bits are contained in the file mode.
- File Owner Class
- The property of a file indicating access permissions for a process related to the user identification of a process. A process is in the file owner class of a file if the effective user ID of the process matches the user ID of the file.
- File Group Class
- The property of a file indicating access permissions for a process related to the group identification of a process. A process is in the file group class of a file if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. Other members of the class may be implementation-defined.
- File Other Class
- The property of a file indicating access permissions for a process related to the user and group identification of a process. A process is in the file other class of a file if the process is not in the file owner class or file group class.
- Additional File Access Control Mechanism
- An implementation-defined mechanism that is layered upon the access control mechanisms defined [in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.)], but which do[es] not grant permissions beyond those defined [in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.)], although they may further restrict them.
- Alternate File Access Control Mechanism
- An implementation-defined mechanism that is independent of the access control mechanisms defined [in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.)], and which if enabled on a file may either restrict or extend the permissions of a given user. IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and when they are disabled.
- File Access Permissions
- The standard file access control mechanism uses the file permission bits, as described below.
- Implementations may provide additional or alternate file access control mechanisms, or both. An additional access control mechanism shall only further restrict the access permissions defined by the file permission bits. An alternate file access control mechanism shall:
Whenever a process requests file access permission for read, write, or execute/search, if no additional mechanism denies access, access shall be determined as follows:
- Specify file permission bits for the file owner class, file group class, and file other class of that file, corresponding to the access permissions.
- Be enabled only by explicit user action, on a per-file basis by the file owner or a user with the appropriate privilege.
- Be disabled for a file after the file permission bits are changed for that file with chmod(). The disabling of the alternate mechanism need not disable any additional mechanisms supported by an implementation.
Otherwise:
- If a process has the appropriate privilege:
- If read, write, or directory search permission is requested, access shall be granted.
- If execute permission is requested, access shall be granted if execute permission is granted to at least one user by the file permission bits or by an alternate access control mechanism; otherwise, access shall be denied.
- The file permission bits of a file contain read, write, and execute/search permissions for the file owner class, file group class, and file other class.
- Access shall be granted if an alternate access control mechanism is not enabled and the requested access permission bit is set for the class (file owner class, file group class, or file other class) to which the process belongs, or if an alternate access control mechanism is enabled and it allows the requested access; otherwise, access shall be denied.
The definitions in Section 3 (POSIX Definitions) define the framework within which ACLs may grant or deny permissions on POSIX compliant systems. ACLs go beyond the POSIX permission model. We must determine which aspects of ACLs map onto which POSIX concepts, and how they can extend the POSIX permission model without violating POSIX assumptions.
POSIX defines additional and alternate file access control mechanisms. Alternate file access control mechanisms my only be enabled by explicit user action, on a per-file basis, and must be disabled by chmod(). In particular, this means that alternate file access control mechanisms must be disabled for new files, while additional file access control mechanisms may be enabled for new files, and after chmod(). In order to make ACLs useful on POSIX compliant systems, we must ensure that as large a subset of ACLs falls into the additional category as possible.
The sets of POSIX file permission bits can be thought of as ACEs, with
one ACE per file class. At the same time, these sets define the maximum
permissions that may be granted to the file owner, group, and other
classes under an additional file access control mechanism. In order to
determine which set of file permission bits limits which ACEs, we must
assign each ACE to one of the three classes. We define the following
mapping:
| ACE who | POSIX File Class |
|---|---|
| OWNER@ | Owner Class |
| GROUP@ | Group Class |
| EVERYONE@ | Other Class |
| Everything else | Group Class |
| Table 1: Classification of ACEs into File Classes |
This definition is consistent with POSIX: The owner class relates to the permissions granted to the owner. The group class related to the permissions granted to the owning group and to other implementation-defined members. The other class relates to the permissions granted to all other users. It is both reasonable and within the bounds of POSIX to classify ACEs other than OWNER@ and EVERYONE@ as being in the file group class because they are not others in the sense of not being mentioned in the ACL.
RFC 3530 [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) defines that the group file permission bits be in sync with the access mask flags of GROUP@ ACEs. This conflicts with the requirement of additional file access control mechanisms that such mechanisms must not grant permisions beyond those defined in POSIX [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.): under the classification given, this definition requires that the file group permissions be a superset of the permissions granted by all ACEs other than OWNER@ and EVERYONE@ ACEs.
Under POSIX, each process is either the owner, a member in the owning group, or neither the owner nor a member in the owning group. This determines which set of file permission bits applies to the process, and which file class the process is in. Even if a process is both the owner and member of the owning group, it will only be granted the owner permissions, etc. With ACLs, permissions from multiple ACEs accumulate until all permissions are granted, or access is denied by an explicit DENY entry or by reaching the end of the ACL. The EVERYONE@ ACE who matches literally everyone, including all users in the file owner and file group classes.
This means that with ACLs, permissions from multiple file classes may accumulate. Because permissions are only granted to a POSIX process from one file class and the class file permission bits define the maximum permissions that a process in this class may be granted, this mechanism can be used to restrict permissions (e.g., by giving fewer permissions to the file group class than to others). ACLs may grant principals more permissions than what POSIX would grant in this case, so they would go beyond additional file access control mechanisms. This is a structural problem of ACLs, and we will see in Section 4.3 (Well-formed ACLs and Non-monotonic File Permissions) which properties ACLs must fulfill to prevent accumulation of permissions across classes, so that this classification will meet the goal of making as large a subset of ACLs available as an additional file access control mechanism as possible.
In Section 4.2 (Accumulation Of Permissions), we have seen that for strict POSIX compliance, we must make sure that ACLs will not grant a principal permissions from more than one file class. While it may be suitable to give up strict POSIX compliance in specific situations, a generic mapping between ACLs and POSIX must be capable of offering strict compliance.
We may define that a principal is in the owner class which is granted permissions from owner class ACEs, that a principal is in the group class which is granted permissions from group class ACEs but not from owner class ACEs, and that a principal is in the other class which is not granted permissions from owner class or group class ACEs. Under this definition, well-formed ACLs have the property that they will not grant any principal permissions from any other class that the principal is not also granted from its own class.
An interesting observation is that ACLs which are not well-formed cannot grant permissions to classes other than a principal's class if the file mode permission bits are monotonically descreasing (i.e., the owner class permissions are equal to or a superset of the group class permissions, and the group class permissions are equal to or a superset of the other class permissions). This means that well-formed ACLs are only required with file mode permission bits that are not monotonically decreasing (“non-monotonic”).
Well-formed ACLs can be enforced either at acl SETATTR time, or when a non-monotonic mode is applied to a file either at file create or mode SETATTR time. Note that with acl SETATTR time enforcement, the effective as well as the file and directory inheritable ACLs must be checked.
Implementations that choose to enforce well-formed ACLs when a non-monotonic mode is applied to a file should convert arbitrary ACLs into well-formed ones in a way that will not fail: many applications will not expect a mode SETATTR or file create to fail because of a non-monotonic mode.
Implementations should support full POSIX compliance by offering enforcement of and/or conversion to well-formed ACLs. This mechanism may be active by default, and it is recommended that it can be deactivated by an implementation-defined mechanism.
ACLs offer an extended set of access mask flags that goes beyond what can be expressed with the POSIX read, write, and execute permissions. Some of these flags are always allowed under POSIX, some correspond closely with a POSIX permission or are subset of a POSIX permission, and some have no POSIX equivalent.
It was stated above that POSIX allows additional file access control
mechanisms to further restrict a given user's permissions, while
alternate file access control mechanisms may restrict or extend them.
We define the following classification of access mask flags into file
access control mechanism and POSIX permission:
| Access Mask Flag | File Access Control Mechanism (Permission) |
|---|---|
| READ_DATA | Additional (Read) |
| LIST_DIRECTORY | Additional (Read) |
| WRITE_DATA | Additional (Write) |
| ADD_FILE | Additional (Write) |
| APPEND_DATA | Additional (Write) |
| ADD_SUBDIRECTORY | Additional (Write) |
| READ_NAMED_ATTRS | Implementation Defined |
| WRITE_NAMED_ATTRS | Implementation Defined |
| EXECUTE | Additional (Execute) |
| DELETE_CHILD | Additional (Write) |
| READ_ATTRIBUTES | Always Allowed |
| WRITE_ATTRIBUTES | Alternate |
| DELETE | Alternate |
| READ_ACL | Always Allowed |
| WRITE_ACL | Alternate |
| WRITE_OWNER | Alternate |
| SYNCHRONIZE | Always Allowed |
| Table 2: Classification of Access Mask Flags into File Access Control Mechanisms and Permissions |
Flags classified as additional are equivalent to or a subset of the designated POSIX permission. If the file class of an ACE (see Section 4.1 (Mapping ACEs to File Classes)) includes this permission, the ACE may grant this permission as part of an additional file access control mechanism. Flags classified as alternate must be disabled for new files and after a chmod(). Flags classified as always allowed are always allowed under POSIX. An implementation may choose to implicitly set those flags in ACLs, deny the access if the principal requesting the access is not granted the flag, or implicitly allow the access.
Note that some of the access mask flags in Section 4.1 (Mapping ACEs to File Classes) apply both to non-directories and directories, while others only apply to either non-directories or directories.
The READ_NAMED_ATTRS and WRITE_NAMED_ATTRS flags are classified as implementation defined. They may either be additional or alternate, depending on how access to the objects exposed through named attributes is controlled on the server: if the read and write permissions determine access, the two flags should be classified as additional (read) and additional (write), respectively. If other means such as file ownership determines access, the two flags should be classified as alternate.
POSIX requires that alternate file access control mechanisms be disabled for new files and upon chmod(), and that additional file access control mechanisms only further restrict the permissions granted to processes by the file classes. This could be achieved by removing alternate access mask bits and additional access mask bits from ALLOW ACEs that go beyond the file classes, by temporarily disabling them, or by replacing the ACL with a new one that only grants the permissions implied by the new mask.
Removing access mask bits or replacing entire ACLs is destructive: a chmod() to a more restrictive mode and back to the original mode will result in fewer permissions being granted, and creat() with a restrictive create mode followed by a chmod() to a less restrictive mode will result in fewer permissions being granted than if a less restrictive create mode had been used. Temporarily disabling access mask bits that POSIX disallows and later re-enabling them does not have this disadvantage, and therefore this is the preferred solution.
To achieve this behavior, we introduce a file owner mask, file group mask and file other mask. The three masks correspond to the file owner class, file group class, and file other class, respectively. Access mask flags in ALLOW ACEs are effective only if they are set both in the ALLOW ACE and in the associated file mask. Permissions that are not effective are disabled. We extend the NFSv4 file permission check algorithm to only grant effective permissions.
This design allows us to temporarily and selectively disable additional and alternate access mask flags as required, and to selectively re-enable them later is desired: alternate access mask flags may be re-enabled by explicit user action, while additional access mask flags may be re-enabled either explicitly or implicitly by file permission changes.
When the permissions of a file are set, either when a new file is created or in a mode SETATTR, the three file masks are updated as follows: for each file mask, set all mask bits that map to one of the active permissions in the corresponding file class in Table 2 (Classification of Access Mask Flags into File Access Control Mechanisms and Permissions), and clear all others. (Without loss of information, implementations may choose to only set flags in the file masks that are used in ALLOW ACEs of the ACL.)
When an ACL is set, the file masks may or may not be set in the same operation. If they are not set in the same operation, each file mask shall implicitly be set to the union of the mask bits of all ACEs that are in the corresponding file class according to Table 1 (Classification of ACEs into File Classes).
When a file mask is set, either explicitly or implicitly by setting an ACL, all permissions that active file mask bits correspond to in Table 2 (Classification of Access Mask Flags into File Access Control Mechanisms and Permissions) shall be set, and all other permissions shall be cleared.
When file mode permission bits are applied to a file, either when a new file is created or in a mode SETATTR, it may seem a good idea to update the OWNER@, GROUP@, and EVERYONE@ ACEs, and set them to allow the mask bits corresponding to the new file permission bits: setting the file permission bits will also automatically update the file masks, and so if we would update the OWNER@, GROUP@, and EVERYONE@ entries as well, the owner, owning group, and others were automatically granted the permissions set in the file mode (provided that the ACL contains the appropriate ACEs). This would reflect the traditional POSIX behavior without ACLs, and it would avoid potential user surprise when some permissions are not granted after a mode SETATTR due to a restrictive ACL. This approach has two significant drawbacks:
For these reasons, setting the file permission bits or changing the file modes must not change any ACE access mask fields. We must ensure that changing the file mode permissions from one mode to another and back will result in the same, or fewer, permissions being granted than before those changes.
POSIX defines the concept of umask which determines bits in the create mode to be removed by the kernel at file and directory create time: each POSIX process is associated with a umask. Applications usually specify a create mode of 0666 (rw-rw-rw-) when creating new files, and 0777 (rwxrwxrwx) when creating new directories. The kernel sets the new object's permissions to (create mode & ~umask): with a umask of 022, the file permission bits would end up as 0644 (rw-r--r--) for files, and as 0755 (rwxr-xr-x) for directories, etc. This gives users the ability to control which permissions new files will end up with without having to set permissions individually on each new file.
ACL inheritance provides a different mechanism to define which permissions new files and directories shall end up with. The withdrawn POSIX 1003.1e draft 17 [3] (Portable Applications Standards Committee of the IEEE Computer Society, “Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - System Application Program Interface,” October 1997.) which the “POSIX” ACL implementations on many UNIX-like systems are based on defines that the umask is to be ignored for files that inherit an ACL. The reason for choosing this behavior given in the Rationale section of the draft is this (default ACLs are the equivalent of inheritable ACEs in the NFSv4 ACL model):
If umask were used when a default ACL exists, then the user is likely to set a very permissive umask to permit the full utilization of the default ACL. This permissive umask would be inappropriate in a directory without a default ACL. The chosen solution allows umask and default ACLs to co-exist.
[...]
The only disadvantage recognized by the working group for this algorithm is that the umask is not taken into consideration when creating files in a directory with a default ACL. This solution gives the user little protection against a program that specifies an unwise create mode when creating a file in a directory with an inappropriate default ACL. Another possible approach is to ignore both the mode parameter of the creat() function and the umask value if a default ACL entry exists. This approach was considered because it gives the directory owner complete control over newly created objects in her/his directory. Allowing the directory owner to have control over the permissions of newly created objects is a logical extension. This solution also supports the contention that the directory owner knows how to set up the permissions for newly created objects in a particular hierarchy. This algorithm was not selected because the directory owner can override the program’s advice about the use of a newly created object, i.e., override the create mode. Traditionally, the creator of an object has complete control over the mode of a newly created object. This solution would completely usurp that control from the creator.
In order to allow NFSv4 servers to apply or ignore the umask, clients would have to pass both the original create mode and the umask to the server. The NFSv4 protocol instead specifies that the client should apply the umask to the create mode before sending the create mode to the server. This prevents the POSIX ACL behavior from being implemented over NFSv4.
It is recommended that the server ignore the umask when a new file inherits an ACL in cases where the server knows both the original create mode and the umask, such as with POSIX processes running locally on the server.
The concept of file masks introduced in Section 4.5 (Effective vs. Disabled Access Mask Flags) does not exist in current NFSv4 implementations. We recommend to implement the three file masks as a single optional file_masks attribute of type acemask4[3]. The attribute shall contain the file owner mask, file group mask, and file other mask, in this order. The file mask values shall use the same flag bitmap values as the ACE access masks. To prevent clients from checking for file_masks support for each individual file, the attribute shall either be supported for all files in a filesystem, or for none.
To ensure backwards compatibility, the server shall remove all disabled ACE mask bits from ALLOW ACEs to clients which perform an acl GETATTR without requesting the file_masks attribute in the same operation. When an acl SETATTR is requested without also setting the file_masks attribute, the server shall assume a file_masks attribute where each of the file masks is the union of the ACE access mask flags of all the ACEs in the corresponding file class.
Access to files on POSIX compliant systems for which no additional or alternate access file access are in effect is entirely controlled by the file permission bits, along with a few other mechanisms such as permissions that are implicitly granted to file owners, and the restricted deletion flag bit (S_ISVTX) for directories. POSIX does not allow files without access control.
The permissions granted by the POSIX file mode permission bits are represented with the following five-entry ACL, with mask set to what all the POSIX permissions map to in Table 2 (Classification of Access Mask Flags into File Access Control Mechanisms and Permissions) (i.e., READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE for non-directories and LIST_DIRECTORY/ADD_FILE/ADD_SUBDIRECTORY/EXECUTE/DELETE_CHILD for directories, and possibly additional implementation defined access mask flags):
OWNER@:mask::ALLOW OWNER@:mask::DENY GROUP@:mask::ALLOW GROUP@:mask::DENY EVERYONE@:mask::ALLOW
The file owner, group, and other masks are set to reflect the file permission bits as described in Section 4.6 (Setting File Permissions, File Masks, and ACLs), which means that only the appropriate access mask flags in the ACL will be effective, and all others will be disabled.
For example, a regular file with mode 0644 (rw-r--r--) would end up with a READ_DATA/WRITE_DATA/APPEND_DATA owner mask and READ_DATA group and other masks, and so the owner would be granted READ_DATA/WRITE_DATA/APPEND_DATA, and the owning group and others would be granted READ_DATA. A directory with a non-monotonic mode of 0705 (rwx---r-x), would end up with a LIST_DIRECTORY/ADD_FILE/ADD_SUBDIRECTORY/EXECUTE/DELETE_CHILD owner mask, an empty group mask, and a LIST_DIRECTORY/EXECUTE other mask, and so the owner would be granted LIST_DIRECTORY/ADD_FILE/ADD_SUBDIRECTORY/EXECUTE/DELETE_CHILD access, the owning group would be granted no access, and everyone except the owner and the owning group would be granted LIST_DIRECTORY/EXECUTE access.
Implementations may leave out DENY ACEs and access mask flags from ACLs representing the mode attribute as long as leaving out these ACEs does not change the permissions granted by the ACL.
Some details in the above sections, and several additional sections have not been written, yet. The topics not discussed include:
| [1] | Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” RFC 3530, April 2003. |
| [2] | Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” IEEE Standard 1003.1, December 2004. |
| [3] | Portable Applications Standards Committee of the IEEE Computer Society, “Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - System Application Program Interface,” October 1997. |
| Andreas Gruenbacher | |
| SUSE Labs, Novell | |
| Email: | a.gruenbacher@computer.org |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright © The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.