[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft submission: NETCONF access control framework
- To: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
- Subject: Draft submission: NETCONF access control framework
- From: Vincent Cridlig <vincent.cridlig@loria.fr>
- Date: Tue, 07 Nov 2006 16:45:41 +0100
- User-agent: Thunderbird 1.5.0.7 (X11/20061027)
Hi,
Please find the joint file draft-cridlig-netconf-rbac.txt. Any comments
are welcome.
I implemented this proposition in our Netconf agent prototype in Python
so it should be feasable in acceptable time also in other languages
and/or plateforms.
Here is a set of comments to open discussion:
1- The proposition is very strict with the default operation in
edit-config, because it is hard to anticipate what will be done exactly
without seeing the configuration data.
2- notify ("n") privilege could be easily added, and would allow to
filter the data sent in notifications in the same way as get-config
replies. As I am not very confident with the notification draft, I
prefer to omit notifications for now.
3- It is possible to extend the proposition with function-centric
approach, but still with more complexity and the possibility to
introduce inconsistencies: I was thinking of something like that:
<permission op="w">
<method name="create-vlan">
<scope>/foo/bar/vlan</scope>
<scope>/foo/bar/if</scope>
</permission>
Some parameters may be added as variables:
<permission op="w">
<method name="create-vlan">
<param>ifname</param>
</method>
<scope>/foo/bar/vlan</scope>
<scope>/foo/bar/if[name=$ifname]</scope>
</permission>
It describes the data involved in the function context.
4- For more security, the login/password and login/public-key tuples
should be stored in a certificate instead of within the policy. This is
to make sure that the proprietary of the public-key is really the
identity described by the login (using a third-party). Also the password
should be a hash of the password.
5- I can send some links to the most famous RBAC papers if needed.
Regards,
Vincent Cridlig
Network Working Group V. Cridlig
Internet-Draft November 7, 2006
Intended status: Standards Track
Expires: May 11, 2007
NETCONF access control framework
draft-cridlig-netconf-rbac.txt
Status of this Memo
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 May 11, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Cridlig Expires May 11, 2007 [Page 1]
Internet-Draft NETCONF access control framework November 2006
Abstract
This document defines a role-based access control framework for the
NETCONF configuration protocol.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. General overview . . . . . . . . . . . . . . . . . . . . . 4
2.2. Role-Based Access Control in NETCONF . . . . . . . . . . . 4
3. RBAC-related operations . . . . . . . . . . . . . . . . . . . 6
3.1. Activating a role . . . . . . . . . . . . . . . . . . . . 6
3.2. Deactivating a role . . . . . . . . . . . . . . . . . . . 7
3.3. Role (de)activation typical use case . . . . . . . . . . . 7
4. RBAC policy data model . . . . . . . . . . . . . . . . . . . . 9
4.1. RBAC components definition . . . . . . . . . . . . . . . . 9
4.2. RBAC policy example . . . . . . . . . . . . . . . . . . . 10
4.3. XML schema for RBAC . . . . . . . . . . . . . . . . . . . 12
4.4. Updating the RBAC policy . . . . . . . . . . . . . . . . . 15
5. Consequences on existing operations . . . . . . . . . . . . . 16
5.1. get and get-config operations . . . . . . . . . . . . . . 16
5.2. edit-config operation . . . . . . . . . . . . . . . . . . 16
5.3. copy-config operations . . . . . . . . . . . . . . . . . . 17
5.4. delete-config operations . . . . . . . . . . . . . . . . . 17
6. (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Cridlig Expires May 11, 2007 [Page 2]
Internet-Draft NETCONF access control framework November 2006
1. Requirements notation
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 [RFC2119].
Cridlig Expires May 11, 2007 [Page 3]
Internet-Draft NETCONF access control framework November 2006
2. Introduction
2.1. General overview
The current document defines an access control framework for NETCONF.
This framework relies on the Role-Based Access Control (RBAC) model
and intends to protect NETCONF manager access to resources. The
access control process intentionally removes the underlying protocol
options from the decisions. In particular, it does not depend on
whether the underlying protocol is BEEP, SSH or SOAP. It assumes
that this protocol is secure by especially providing authentication,
integrity and confidentiality. This choice was made because it is
not reasonable to have one access control policy for each of this
protocol and for each of their internal options or security services.
Another design choice is that each NETCONF agent stores its own
access control policy like in VACM. Consequently, the RBAC policy
remains customizable for each NETCONF agent in order to fulfill all
requirements and scenarii.
A NETCONF agent has one instance of the RBAC policy that applies to
all the supported datastores (running, candidate, startup).
2.2. Role-Based Access Control in NETCONF
The RBAC model has many advantages over the other access control
models. In particular, it is scalable in terms of maintainability
even with a huge number of users. RBAC helps to organize the
permissions into higher level job functions called roles. As an
example in the NETCONF context, a role can be a firewall management
role, a security management role, a routing management role. Roles
can be specialized in a hierarchy. For example, the security
management role can be a senior role of the firewall management role
and therefore, inherits the permissions of this junior role (firewall
management role). In the context of this document, an RBAC user is a
NETCONF manager. The latter can be assigned to one or several roles.
RBAC is fairly well adapted to Netconf because it includes the
concept of session, within which permissions can be activated
dynamically. An RBAC session is mapped to a NETCONF session.
The NETCONF agent stores an RBAC policy, containing the user, role
and permission definitions and their assignements.
Cridlig Expires May 11, 2007 [Page 4]
Internet-Draft NETCONF access control framework November 2006
Role-Based Access Control model
hierarchy
----
| |
|----------| |----------| |----------|
| User |------| Role |------|Permission|
|----------| |----------| |----------|
\ /
\ /
|----------|
| Session |
|----------|
Figure 1
This RBAC policy MAY be stored in an XML file and MAY be part of the
agent data model. Therefore the RBAC policy MAY be manageable
through NETCONF itself, as it is for VACM in SNMPv3. This allows a
large-scale deployement of the access control policy. This document
defines a XML-based data model to store the RBAC policy.
The specified model and the involved new operations defined in the
current document are covered by a new capability:
"urn:ietf:params:xml:ns:netconf:rbac:1.0", abbreviated as "#rbac" in
the rest of the document.
Cridlig Expires May 11, 2007 [Page 5]
Internet-Draft NETCONF access control framework November 2006
3. RBAC-related operations
In the dynamic RBAC model, roles must be activated at run time.
Indeed, the permissions of an RBAC user are not constantly available.
An RBAC user has to activate a role to be granted the related
permissions. This decreases misconfiguration risks since only a
subset of the configuration data is accessible at a given time.
However, this subset can be the whole configuration datastore if the
role allows it. Two operations are necessary to allow role
activation and deactivation. These operations are sent by the
manager to the agent and are wrapped into an <rbac> operation. The
<rbac> operation is a direct child of the NETCONF <rpc> operation.
3.1. Activating a role
<activate-role>
Description:
Activating a role allows a user to be granted the permissions
related to this role in the current NETCONF session. This
operation can happen at any time after the hello exchange is
done. The manager sends an activate-role operation containing
a specified role name to the agent. The agent checks its local
RBAC policy to decide whether the user can activate this role
or not. In order to activate a role, a user MUST be assigned
to this role and the role must be enabled. An enabled role is
a role that can be activated.
Parameters:
Role name:
The name of the role to be activated.
Positive Response:
If the user is assigned to the requested role, and the role is
not activated yet in the current session, then the agent sends
an <rpc-reply> containing an <ok> element.
Negative Response:
An <rpc-error> element is included within the <rpc-reply> if
the request cannot be completed for any reason. A role
activation will fail if the user is not assigned to the
requested role, or if the role is already activated or if any
other constraint prevents the user from activating the role.
Cridlig Expires May 11, 2007 [Page 6]
Internet-Draft NETCONF access control framework November 2006
3.2. Deactivating a role
<deactivate-role>
Description:
Deactivating a role allows a user to revoke the permissions
related to this role in the current NETCONF session. This
operation can happen at any time after the hello exchange is
done. The manager sends a deactivate-role operation containing
a specified role name to the agent. The agent checks its local
RBAC policy to decide whether the user can deactivate this role
or not.
Parameters:
Role name:
The name of the role to deactivate.
Positive Response:
If the role was activated in the current session, then the
agent sends an <rpc-reply> containing an <ok> element.
Negative Response:
An <rpc-error> element is included within the <rpc-reply> if
the request cannot be completed for any reason. A role
deactivation will fail if the user had not activate the role
previously in the session.
3.3. Role (de)activation typical use case
Cridlig Expires May 11, 2007 [Page 7]
Internet-Draft NETCONF access control framework November 2006
Role (de)activation process:
Manager Agent
| |
| <hello> exchange |
|<---------------------------->|
| |
| |
| <(de)activate-role> |
|----------------------------->|
| | check policy -----------
| |<--------------->| database |
| <ok/> | -----------
|<-----------------------------|
| |
| |
Figure 2
When a NETCONF session is terminated (for example, after a <close-
session> or a <kill-session>), then all active roles MUST be
deactivated within the current session.
When a NETCONF session is started (after the hello exchange), then a
set of default roles MAY be activated by default on a per-user base,
without requiring the <activate-role> operation. This default
activation on Netconf session startup saves some messages and avoid
the need of a user activity. The set of roles activated by default
MAY be chosen by the manager.
Cridlig Expires May 11, 2007 [Page 8]
Internet-Draft NETCONF access control framework November 2006
4. RBAC policy data model
This section defines an XML-based data model representing an RBAC
policy. It specifies the main components of RBAC: users, roles and
permissions. Sessions are not part of the saved data model, since it
is the dynamic part of RBAC. Sessions state (activated and
deactivated roles) always remains in memory.
4.1. RBAC components definition
The following items list the components of the RBAC model and their
internal relationships (assignments):
User: A user consists of the following attributes:
login: the name of the user.
password: the password of the user.
public-key: the public key of the user.
Role: A role consists of the following attributes:
name: the name of the current role.
junior-roles: a set of junior roles of the current role.
Permission: A permission consists of the following parameters:
scope: a representation of the protected resource, typically a
MIB name (could be an XPath expression for more granularity).
<scope> is a child of <permission>
operation: read (r), write (w) or notify (n).
Permission-to-Role Assignement (pra):
permRef: reference to a permission.
roleRef: reference to a role.
User-to-Role Assignement (ura):
userRef: reference to a user.
roleRef: reference to a role.
Cridlig Expires May 11, 2007 [Page 9]
Internet-Draft NETCONF access control framework November 2006
4.2. RBAC policy example
This example consists of 5 roles. RoutingManager role has read
access to the routing configuration. InteriorRoutingManager and
ExteriorRoutingManager roles inherit the privileges of
RoutingManager. InteriorRoutingManager can also write on OSPF and
RIP configurations. ExteriorRoutingManager can write on BGP
configuration. SuperRoutingManager inherits all previous roles and
can write on all routing configurations. SuperManager has full
privileges on all the configuration.
RBAC policy example
<?xml version="1.0" encoding="UTF-8"?>
<rbac xmlns="urn:loria:madynes:ensuite:yencap:module:RBAC:1.0">
<prefixes>
<prefix name="ycp"
value="urn:loria:madynes:ensuite:yencap:1.0"/>
<prefix name="bgp"
value="urn:loria:madynes:ensuite:yencap:module:BGP:1.0"/>
<prefix name="rip"
value="urn:loria:madynes:ensuite:yencap:module:RIP:1.0"/>
<prefix name="ospf"
value="urn:loria:madynes:ensuite:yencap:module:OSPF:1.0"/>
<prefix name="ac"
value="urn:loria:madynes:ensuite:yencap:module:RBAC:1.0"/>
</prefixes>
<users>
<user id="4">
<login>netconf</login>
<password>netconf</password>
<public-key keytype="rsa">AAAAB3NzaC1yc2E...
...50RfDJ6M=</public-key>
</user>
</users>
<roles>
<role id="1">
<name>RoutingManager</name>
</role>
<role id="2">
<name>InteriorRoutingManager</name>
<junior-roles>
<junior-role roleRef="1"/>
</junior-roles>
</role>
<role id="3">
Cridlig Expires May 11, 2007 [Page 10]
Internet-Draft NETCONF access control framework November 2006
<name>ExteriorRoutingManager</name>
<junior-roles>
<junior-role roleRef="1"/>
</junior-roles>
</role>
<role id="5">
<name>SuperRoutingManager</name>
<junior-roles>
<junior-role roleRef="2"/>
<junior-role roleRef="3"/>
<junior-role roleRef="4"/>
</junior-roles>
</role>
<role id="6">
<name>SuperManager</name>
<junior-roles>
<junior-role roleRef="5"/>
</junior-roles>
</role>
</roles>
<permissions>
<permission id="1" op="r">
<scope>/ycp:netconf/ycp:routing</scope>
</permission>
<permission id="2" op="w">
<scope>/ycp:netconf/ycp:routing/bgp:bgp</scope>
</permission>
<permission id="3" op="w">
<scope>/ycp:netconf/ycp:routing/rip:rip</scope>
</permission>
<permission id="4" op="w">
<scope>/ycp:netconf/ycp:routing/ospf:ospf</scope>
</permission>
<permission id="5" op="w">
<scope>/ycp:netconf/ycp:routing</scope>
</permission>
<permission id="6" op="rw">
<scope>/ycp:netconf</scope>
</permission>
<permission id="7" op="w">
<scope>/ycp:netconf/ycp:routing/ospf:ospf</scope>
</permission>
</permissions>
<uras>
<ura roleRef="5" userRef="4"/>
<ura roleRef="6" userRef="4"/>
Cridlig Expires May 11, 2007 [Page 11]
Internet-Draft NETCONF access control framework November 2006
</uras>
<pras>
<pra roleRef="1" permRef="1"/>
<pra roleRef="2" permRef="3"/>
<pra roleRef="2" permRef="4"/>
<pra roleRef="3" permRef="2"/>
<pra roleRef="5" permRef="5"/>
<pra roleRef="6" permRef="6"/>
</pras>
</rbac>
Figure 3
4.3. XML schema for RBAC
Here is the XML schema for the RBAC policy.
RBAC XML Schema
<xs:schema
targetNamespace="urn:madynes:params:xml:ns:netconf:rbac:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns="urn:madynes:params:xml:ns:netconf:rbac:1.0">
<xs:element name="rbac" type="rbacType"/>
<xs:complexType name="prefixesType">
<xs:sequence>
<xs:element name="prefix" type="prefixType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="prefixType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="userType">
<xs:sequence>
Cridlig Expires May 11, 2007 [Page 12]
Internet-Draft NETCONF access control framework November 2006
<xs:element name="login" type="xs:string"/>
<xs:element name="password" type="xs:string"/>
<xs:element name="public-key" type="public-keyType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
<xs:complexType name="public-keyType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="keytype" type="keytypeType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="keytypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="rsa"/>
<xs:enumeration value="dsa"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="roleType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="junior-roles" type="junior-rolesType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
<xs:complexType name="usersType">
<xs:sequence>
<xs:element name="user" type="userType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rolesType">
<xs:sequence>
<xs:element name="role" type="roleType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="permissionsType">
<xs:sequence>
<xs:element name="permission" type="permissionType" minOccurs="0"
Cridlig Expires May 11, 2007 [Page 13]
Internet-Draft NETCONF access control framework November 2006
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="permissionType">
<xs:sequence>
<xs:element name="scope" type="xs:string"/>
</xs:sequence>
<xs:attribute name="op">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="w"/>
<xs:enumeration value="rw"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
<xs:complexType name="urasType">
<xs:sequence>
<xs:element name="ura" type="uraType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="uraType">
<xs:attribute name="userRef" type="xs:string"/>
<xs:attribute name="roleRef" type="xs:string"/>
</xs:complexType>
<xs:complexType name="prasType">
<xs:sequence>
<xs:element name="pra" type="praType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="praType">
<xs:attribute name="permissionRef" type="xs:string"/>
<xs:attribute name="roleRef" type="xs:string"/>
</xs:complexType>
<xs:complexType name="rbacType">
<xs:sequence>
<xs:element name="prefixes" type="prefixesType"/>
<xs:element name="users" type="usersType"/>
Cridlig Expires May 11, 2007 [Page 14]
Internet-Draft NETCONF access control framework November 2006
<xs:element name="roles" type="rolesType"/>
<xs:element name="permissions" type="permissionsType"/>
<xs:element name="uras" type="urasType"/>
<xs:element name="pras" type="prasType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="junior-rolesType">
<xs:sequence>
<xs:element name="junior-role" type="junior-roleType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="junior-roleType">
<xs:attribute name="roleRef" type="xs:string"/>
</xs:complexType>
</xs:schema>
Figure 4
4.4. Updating the RBAC policy
Whenever an update is done in the RBAC policy, it MUST be immediately
applied to the current NETCONF sessions.
A user can be removed if and only if it does not appear in any user-
to-role assignement. A permission can be removed if and only if it
does not appear in any permission-to-role assignement. A role can be
removed if and only if it does not appear in any permission-to-role
and user-to-role assignement.
If a user is removed from the policy, all its current NETCONF
sessions must be killed. If a user-to-role assignement is removed
from the policy, this role must be deactivated in all sessions
belonging to this user where this role is active. If a permission-
to-role assignement is removed, the permission MUST be removed from
the set of active permissions in all NETCONF sessions having this
role or one of its senior role activated. If a permission-to-role
assignement is created, the permission must be activated in every
session where the related role or one of its senior role is active.
Cridlig Expires May 11, 2007 [Page 15]
Internet-Draft NETCONF access control framework November 2006
5. Consequences on existing operations
The #rbac capability does not require any change to the formats of
existing NETCONF operations. However, an additional processing is
required on the agent side when it receives some request. In all
cases, the agent MUST consider the active roles within the current
session. These active roles relate to permissions expressed as a
tuple (operation, scope). From the set of active permissions, the
agent is able to build the corresponding sets of authorized scopes
for read "r" and write "w" operations. Scopes are expressed as XPath
expressions.
5.1. get and get-config operations
When processing a get or get-config operation, some changes are
required due to the RBAC policy enforcement. After or before
applying the subtree filtering (or XPath) request to the desired
configuration, an additional processing MUST take place to apply the
RBAC policy. It consists of selecting the allowed XML nodes and
pruning the others depending on the currently active roles.
All children and parents of the selected nodes are marked as
authorized nodes. While the propagation to the top nodes is
necessary to keep the structure of the document, the propagation to
the children is a consequence of the subtree-based access control
arbitrary choice. It is more scalable to select subtrees rather than
individual nodes in the access control policy. Only positive
authorizations are allowed in order to avoid conflicts and to
constraint the security manager to explicitely give access to
resources, all remaining resource being unauthorized by default. All
nodes marked as authorized are kept in the XML reply. All other
nodes are pruned.
5.2. edit-config operation
As for the get/get-config, when a NETCONF manager is authorized to
write on an XML node, she is also allowed to modify the whole subtree
whose root is this XML node. On receipt of an edit-config request,
the agent applies the XPath expressions of the write "w" permissions
set on the request. All children and parents of the selected nodes
are marked as authorized nodes. If a "replace", "create", "delete",
or "merge" operation is set in one of the parents of the selected
nodes, access is denied. This requires to set the operation
attribute as close as possible to the node to update.
Cridlig Expires May 11, 2007 [Page 16]
Internet-Draft NETCONF access control framework November 2006
5.3. copy-config operations
To perform a copy-config operation, a NETCONF manager MUST have write
"w" access on the root node of the configuration datastore.
5.4. delete-config operations
To perform a delete-config operation, a NETCONF manager MUST have
write "w" access on the root node of the configuration datastore.
Cridlig Expires May 11, 2007 [Page 17]
Internet-Draft NETCONF access control framework November 2006
6. (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping
The SSH user name is directly mapped to the RBAC user name, whatever
is the authentication method (password or public/private key).
Cridlig Expires May 11, 2007 [Page 18]
Internet-Draft NETCONF access control framework November 2006
7. Security Considerations
None.
Cridlig Expires May 11, 2007 [Page 19]
Internet-Draft NETCONF access control framework November 2006
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cridlig Expires May 11, 2007 [Page 20]
Internet-Draft NETCONF access control framework November 2006
Author's Address
Vincent Cridlig
Cridlig Expires May 11, 2007 [Page 21]
Internet-Draft NETCONF access control framework November 2006
Full Copyright Statement
Copyright (C) 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cridlig Expires May 11, 2007 [Page 22]
begin:vcard
fn:Vincent Cridlig
n:Cridlig;Vincent
org:LORIA - INRIA Lorraine, France;Madynes
adr:;;;Nancy;;;France
email;internet:cridligv@loria.fr
title:PhD Student
tel;work:+33 (0)3 83 59 20 48
url:http://www.loria.fr/~cridligv
version:2.1
end:vcard