Internet Engineering Task Force Geopriv
Internet Draft H. Tschofenig
J. Cuellar
Siemens
Document:
draft-tschofenig-geopriv-authz-policies-00.txt
Expires: December 2003 June 2003
Geopriv Authorization Policies
<draft-tschofenig-geopriv-authz-policies-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes authorization policies for usage with
Geopriv. It suggests using the eXtensible Access Control Markup
Language (XACML). XACML provides functionality required to express
policies for access to location information.
Tschofenig, Cuellar Expires - December 2003 [Page 1]
Geopriv Authorization Policies June 2003
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. The Process of Access Control.................................3
4. Features provided by XACML....................................6
4.1 Basic functionality of XACML..............................6
4.2 Combining Algorithms......................................7
4.3 Operators.................................................8
5. Examples......................................................9
5.1 Request Context Example 1.................................9
5.2 Policy Example 1.........................................10
5.3 Reponse Context Example 1................................12
6. Security Considerations......................................12
7. Open Issues..................................................13
8. Acknowledgments..............................................13
9. References...................................................13
Author's Addresses..............................................15
1. Introduction
Geopriv provides Location Information in a secure and private way.
A critical role is played by user-controlled Privacy Rules, which
describe the restrictions imposed or permissions given by the Rule
Maker. The Privacy Rules specify the necessary conditions that
allow a Location Server to forward Location Information to a
Location Recipient, and the conditions under which and purposes for
which the Location Information can be used.
One type of Privacy Rules specify in particular how location
information should be filtered, depending on who the recipient is.
Filtering is the process of reducing the precision or resolution of
the data. A typical rule may be of the form: "my location can only
be disclosed to the owner of such credentials in such precision or
resolution" (e.g., "my co-workers can be told the city I am
currently in").
The Location Object should be able to carry a limited but core set
of Privacy Rules.
The access to location information (as XML objects) can be
controlled by XACML policies. The same is true for writing and
deleting Geopriv rules themselves. The Geopriv working group can
benefit from reusing existing work on access control.
This document therefore aims to provide the following description:
Tschofenig, Cuellar Expires - December 2003 [Page 2]
Geopriv Authorization Policies June 2003
a) It introduces the reader to XACML and describes some of the
relevant features.
b) It explores how access control is accomplished in the Geopriv
environment.
c) It gives examples of access control policies.
2. Terminology
This draft uses terminology described in [CM+03] and in [XACML].
3. The Process of Access Control
Figure 1 gives an abstract overview of the interaction between the
participating entities. Different actions are performed by different
entities requesting access to different information items stored at
the location server. The location server needs to store information
about users, group of users (including pseudonyms and roles). These
entities are subject to authorization (among other attributes).
The request from an entity to the Policy Decision Point, which is in
this case the location server, is carried over a Geopriv 'using
protocol'. A number of protocols might serve as a using protocol
such as the Presence protocol as described in [Pet03]. Recently J.
Rosenberg published the XML Configuration Access Protocol (XCAP)
[XCAP] which describes how to read, write and delete application
configuration data stored in XML format. XCAP can also be used to
manipulate XML based location information (see [CG03]) and it is
therefore another building block on the way to complete the work on
the Geopriv framework. Instantiation of XCAP for usage with SIP in
the area of presence (e.g. modification of buddy lists) can be found
in [Ros03a] and in [Ros03b]. XCAP, however, does not describe how to
control access to perform certain operations on these documents in a
sophisticated fashion. This draft adds this missing piece.
After the request reaches the location server it is necessary to
compare the request with a number of policies deciding whether the
operation is permitted or denied. More information on this step is
given with the description of Figure 2 This verification requires
matching a request with a number of rules and some sort of conflict
resolution. For combining algorithms provided by XACML, the details
of conflict resolution are given in Section 4.2.
Access control policies for location information demand a flexible
language to express the different needs such as:
Tschofenig, Cuellar Expires - December 2003 [Page 3]
Geopriv Authorization Policies June 2003
- My boss should be granted access to my location (civil location,
building and room number only) only during working hours. My family
is always allowed to access my exact location.
- My students are allowed to access my location during the week if
they are in possession of an authorization token.
Furthermore it is necessary to specify policies even for access to
the policies itself. (But this MAY be out of scope of the Geopriv
WG).
Finally, it must be possible to cope with information stored in XML
format.
+-------------+
| | +---------------------------+
| | | |
| Rule | Rule Interface | Location Server |
| Holder +-------------------->+ |
| | | Various Databases |
| | | +-----------------------+ |
+-------------+ | | | |
| | User/Group Info | |
+-------------+ | | | |
| | | +-----------------------+ |
| | | +-----------------------+ |
| Location | Location | | Access Control | |
| Recipient +<------------------->+ | Policies | |
| | requests/responses | | | |
| | | +-----------------------+ |
+-------------+ | +-----------------------+ |
| | | |
+-------------+ | | Location Information | |
| | | | of different users | |
| Location | Location info | +-----------------------+ |
| Generator +<------------------->+ |
| | | |
+-------------+ +---------------------------+
Figure 1: Interaction between the participating Entities
Access control policies require a number of input parameters to
compute the authorization decision. Some of these input parameters
can be obtained from the request itself (i.e. from domain-specific
input). To be accessible to the policy engine (as described in the
policy rules) it is convenient to have the context request defined
in an XACML schema.
Based on Figure 2 of [XACML] the relationship to Geopriv is drawn.
Tschofenig, Cuellar Expires - December 2003 [Page 4]
Geopriv Authorization Policies June 2003
+------------------------------------------+
| Covered by XACML specification |
| |
| +--------------+ |
| | XACML Policy | |
| +--------------+ |
| ^ |
| | |
domain- | v | domain-
specific | +-------+ +---------------+ +--------+ | specific
input | |XACML | |Access Control | |XACML | | output
=============>|Context|=>|Engine at the |=>|Context |============>
| |Request| |Location Server| |Response| |
| +-------+ +---------------+ +--------+ |
| |
| |
| |
| |
+------------------------------------------+
Figure 2: XACML Context
The access control engine evaluates incoming requests from specific
subjects with specific actions (read, write, delete) for certain
objects. For Geopriv some of these objects are location information
"documents", as for example defined, in [CG03]. Location information
is stored in XML documents.
As shown in Figure 2 a native request is mapped into an XML request
(following a XACML schema) which allows the access control engine
and the policies to refer to certain items of the request. The XACML
Context Request identifies, for example, which elements the subject
wants to read. It provides information about the requesting entity
such as role, subject identity, information about the security
protocols used to authenticate, which credentials have been used,
etc. The Geopriv group might want to evaluate which information
items are typically associated with a request to re-evaluate the
XACL Context schema definition.
Note that attributes might appear in different envelopes such as
X.509 attribute certificates or as Security Assertion Markup
Language (SAML) assertions [SAML]. SAML allows distributing security
information. Thereby the security information is expressed as
assertions about subjects. These assertions carry information about
authentication acts, attributes and authorization decisions.
Conversion between the native format and the XACML context might be
specified with the help of the Extensible Stylesheet Language
Transformation [XSLT].
Tschofenig, Cuellar Expires - December 2003 [Page 5]
Geopriv Authorization Policies June 2003
4. Features provided by XACML
This section describes some of the features which make it an
attractive access control markup language for Geopriv policies.
Implementing a new access control markup language solely for Geopriv
without reusing existing systems requires recreating the same
functions and concepts. It seems that the solution space for
standardized languages is actually fairly small when designing a
flexible access control mechanism for XML based documents.
4.1 Basic functionality of XACML
Three top-level elements are defined in XACML [XACML]: <Rule>,
<Policy> and <PolicySet>
The policy language model is defined in [XACML], Section 3.3 (see
also Figure 3 there).
A <Rule> contains a Boolean expression and consists of the following
components:
- Target
- Effect and
- Condition
The rule target defines a set of resources, subjects and actions to
which the rule applies. The rule itself forms the basic building
block for a Policy.
The rule target consists of
- Resources
- Subjects and
- Actions
Subjects and resources might be internally structured. This allows
referencing them via an XPath [XPath] or XPointer [XPointer]
reference. Referring to resources could imply to
- refer to the content of the identified node itself
- refer to the content of the identified node and its immediate
child nodes or
- refer to the content of the identified node and all its descendant
nodes.
It is therefore also possible to base the authorization decision on
data contained in the resource to which access requested.
The effect describes the intended consequence of a "true"
evaluation. Two values are defined "permit" and "deny".
Tschofenig, Cuellar Expires - December 2003 [Page 6]
Geopriv Authorization Policies June 2003
The condition furthermore allows refining the applicability of a
rule. This element is optional.
Rules themselves are not exchanged between entities. Therefore
<Rules> are always embedded into a <Policy>. A <Policy> consists of
- a target
- a rule-combining algorithm id
- a set of rules and
- obligations.
<Policy> elements might additionally attach to an information
resource itself. One application would be to attach the policy
itself to Geopriv location object.
Obligations allow to enforce certain actions that must be performed
either instead or in addition to the actions that may be performed.
This functionality simulates the idea of a provisional action as
described in [Kudo00]. Provisions are attached to the access
decision.
An example for such an access decision might be a logging action or
the encryption of the objects returned in response.
A <PolicySet> again allows combining set of Policies together with
the following elements:
- a target
- a policy-combining algorithm id
- obligations.
4.2 Combining Algorithms
The rule-combining algorithm identifier is used to implement
conflict resolution (i.e. a mechanism for achieving a final
authorization decision after evaluating individual rules) with the
following standard algorithms:
* Deny-overrides
* Permit-overrides
* First applicable and
* Only-one-applicable
The policy-combining algorithm identifier enforces the same concept
as the rule-combining algorithm identifier but at a policy and not a
rule level.
Tschofenig, Cuellar Expires - December 2003 [Page 7]
Geopriv Authorization Policies June 2003
An example: The permit-overrides algorithm causes a "permit"
evaluation if a single rule (or policy) in the applicable policy is
found with a "permit" evaluation, regardless of other rules or
policies in the applicable policy.
New rule-combining algorithms (or policy-combining algorithms) can
be specified, if necessary.
4.3 Operators
In order to compute an authorization decision it is necessary to
perform operations on attributes of subjects and resources. XACML
defines a number of operators:
- Operators on numerical data types
Examples: integer-add, double-add, integer-subtract, integer-
multiply, double-mod, integer-divide, round, floor, integer-abs,
double-to-integer, etc.
Additionally arithmetic comparison functions are defined such as
integer-less-than, double-greater-than-or-equal, etc.
Various non-numeric comparison functions also exist such as string-
greater-than, string-less-than, time-less-than, date-greater-than,
etc.
- Operators on date, time and duration data types
Examples: dateTime-subtract-yearMonthDuration, dateTime-add-
dayTimeDuration, date-subtract-yearMonthDuration
- Operators on Boolean data types
Examples: and, or, not, n-of
These operators allow specifying logical combination of predicates
of a rule.
- Operators on sets
Examples: type-bag-size, type-is-in, type-intersection, type-union,
type-subset, type-set-equals, any-of, all-of, any-of-any, map, etc.
- Relationship operators
Examples: Equality and comparison on RFC 822 and X.500 name forms,
strings, URIs, etc. (string-equal, Boolean-equal, integer-equal,
date-equal, time-equal, X500Name-eqal, rfc822Name-equal, anyURI-
equal, etc.)
Tschofenig, Cuellar Expires - December 2003 [Page 8]
Geopriv Authorization Policies June 2003
Additionally it is possible to add non-standard functions.
5. Examples
This section shows some examples for the XACML policies. For this
version of the draft some very basic examples are provided.
Currently the examples are very much aligned to the examples in
Section 4 of [XACML]. Comments are inserted into the XML code within
"<!--" and "-->".
5.1 Request Context Example 1
The request in XACML for the first example might be stated as
follows:
"Jorge Cuellar wants to know (i.e. read) the location of Hannes
Tschofenig. Jorge Cuellar is identified with an RFC 822 type of
email address (for example obtained during the SIP authentication
procedure)".
This request therefore translates to the following XACML request
context:
<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:1.0:context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-
01.xsd">
<!-- These lines show the header of the request context. -->
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">
<AttributeValue>Jorge.Cuellar@siemens.com</AttributeValue>
</Attribute>
</Subject>
<!-- The <Subject> element describes information about the
requesting entity. Multiple subjects and multiple attributes per
subject are possible. -->
<Resource>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:ufs-path"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
Tschofenig, Cuellar Expires - December 2003 [Page 9]
Geopriv Authorization Policies June 2003
<AttributeValue>/geopriv/HannesTschofenig@siemens.com</AttributeValu
e>
</Attribute>
</Resource>
<!-- The <Resource> element indicates to which resource access is
requested. For this example it is assumed that the location
information is stored in a directory oriented (pathname /geopriv/
HannesTschofenig@siemens.com) fashion. To support compatibility it
is required to agree on a common structure for referencing the
required elements. -->
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
</Request>
<!-- The <Action> element describes the desired action. In this case
a "read" action is requested to retrieve location information. -->
5.2 Policy Example 1
The request described in Section 5.1 is then matched against a
policy at the location server. This policy might, for example, be
provided by the owner of the location itself.
<?xml version=1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy
http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-policy-
01.xsd"
PolicyId="identifier:example:GeoprivPolicy1"
RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-
overrides">
<!-- This part of the policy represents header information
containing information about the encoding, the URI to the XACML
policy schema, a unique policy identifier and finally the rule
combining algorithm identifier. The deny-overrides policy forces a
"deny" to be returned when any of the policy rules evaluates to
"deny". -->
<Description>
Tschofenig, Cuellar Expires - December 2003 [Page 10]
Geopriv Authorization Policies June 2003
Simple Geopriv policy.
</Description>
<!-- An optional description of the policy. -->
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<!-- The <Target> statement indicates to which policies this request
applies. It allows to create an index to policies. -->
<Rule
RuleId= "urn:oasis:names:tc:xacml:1.0:example:GeoprivRule1"
Effect="Permit">
<Description>
Every subject with an identifier in the siemens.com domain is
allowed to read the location.
</Description>
<!-- This XML text introduces a single rule which shows the effect
of a "true" evaluation of the rule. The effect of this rule is
"Permit". Again, the description is optional. -->
<Target>
<Subjects>
<Subject>
<SubjectMatch MatchId="
urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="urn:oasis:names:tc:xacml:1.0:data-
type:rfc822Name"/>
<AttributeValue
DataType="urn:oasis:names:tc:xacml:1.0:data-
type:rfc822Name">siemens.com
</AttributeValue>
</SubjectMatch>
</Subject>
</Subjects>
Tschofenig, Cuellar Expires - December 2003 [Page 11]
Geopriv Authorization Policies June 2003
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Actions>
</Target>
<!-- Similarly as above the <Target> statement describes to whether
the remainder of the rule have to be evaluated after matching the
subject, resource and action part of the <Target>. This rule matches
the subject-id of the requestor with "siemens.com". The
<SubjectMatch MatchId=...> specifies how matching should be
performed and what data types are expected. Furthermore it returns
"Permit" only if the requested action is "read". No restrictions are
made regarding the resources (i.e. any location information might be
accessed). -->
</Rule>
</xacml:Policy>
5.3 Reponse Context Example 1
The following XML text might represent a possible reponse context to
the request described in this example.
<?xml version="1.0" encoding="UTF-8"?>
<Response xmlns="urn:oasis:names:tc:xacml:1.0:context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-
01.xsd">
<!-- These lines show the header of the response context. -->
<Result>
<Decision>NotApplicable</Decision>
</Result>
<!-- These lines show the actual response after evaluation of the
request against the policy rules. -->
6. Security Considerations
<TBD>
Tschofenig, Cuellar Expires - December 2003 [Page 12]
Geopriv Authorization Policies June 2003
Refer to the threats doc here [DM+03]. There may be also some
additional threats to the xacml solution.
7. Open Issues
This draft is a first discussion starter. As such it creates a
number of open issues, such as:
- What attributes are useful for location requests? What information
should typically serve as input to the authorization engine?
- As soon as the work on the location object makes progress it is
necessary to describe how to access the attributes of the location
object.
- More sophisticated Geopriv example policies have to be added to
test the adequacy of the capabilities of XACML.
- Some data might not be available in form of a XML document - the
data might be computed on the fly (e.g. location information at a
different granularity). Another approach is to have all information
already available and to access as any other data item. Some
discussions might be required to determine the best approach
possible.
- How to structure access to location object information of
different entities? As mentioned in [XCAP] it is necessary to define
a schema for data used by a number of entities. One possible
approach is to access individual data items with the help of URIs.
In any case a naming convention for access to items of the location
objects and other information items has to be created.
8. Acknowledgments
We would like to thank Christian Guenther for his input to this
version of the draft.
This entire draft heavily borrows from the XACML [XACML]
specification. We would like to thank the authors of the [XACML]
specification for their excellent work.
9. References
[Kudo00] M. Kudo and S. Hada: "XML document security based on
provisional authorization", in: "Proceedings of the Seventh ACM
Tschofenig, Cuellar Expires - December 2003 [Page 13]
Geopriv Authorization Policies June 2003
Conference on Computer and Communications Security", Nov. 2000,
Athens, Greece, pp. 87-96.
[XPath] XML Path Language (XPath), Version 1.0, W3C Recommendation,
16 November 1999, Available at: http://www.w3.org/TR/xpath.
[XPointer] XML Pointer Language (XPointer), Version 1.0, W3C
Candidate Recommendation, 11 September 2001, Available at:
http://www.w3.org/TR/2001/CR-xptr-20010911.
[XSLT] XSL Transformations (XLT) Version 1.0, W3C Recommendation,
16 November 1999, Available at: http://www.w3.org/TR/xslt.
[XACML] The OASIS eXtensible Access Control Markup Language
(XACML), OASIS Standard, Version 1.0, 18 February, 2003, Available
at: http://www.oasis-open.org/committees/xacml.
[SAML] Security Assertion Markup Language, Available at:
http://www.oasis-open.org/committees/security/#documents.
[Pet03] J. Peterson: "A Presence Architecture for the Distribution
of Geopriv Location Objects", Internet Draft, Internet Engineering
Task Force, (work in progress), February 2003.
[CG03] J. Cuellar and C. Guenther: "Geopriv Location Object Markup
Language", Internet Draft, Internet Engineering Task Force, (work in
progress), June 2003.
[CM+03] J. Cuellar, J. Morris, D. Mulligan, J. Peterson and J.
Polk: "Geopriv requirements", Internet Draft, Internet Engineering
Task Force, (work in progress), March 2003.
[DM+03] M. Danley, D. Mulligan, J. Morris and J. Peterson: "Threat
Analysis of the Geopriv Protocol", Internet Draft, Internet
Engineering Task Force, (work in progress), February 2003.
[XCAP] J. Rosenberg: "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Internet Draft, Internet
Engineering Task Force, (work in progress), May 2003.
[Ros03a] J. Rosenberg: "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists",
Internet Draft, Internet Engineering Task Force, (work in progress),
May 2003.
[Ros03b] J. Rosenberg: "A Session Initiation Protocol (SIP) Event
Package for Modification Events for the Extensible Markup Language
(XML) Configuration Access Protocol (XCAP) Managed Documents",
Tschofenig, Cuellar Expires - December 2003 [Page 14]
Geopriv Authorization Policies June 2003
Internet Draft, Internet Engineering Task Force, (work in progress),
May 2003.
Author's Addresses
Hannes Tschofenig
Siemens AG
Corporate Technology
CT IC 3
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich
Germany
EMail: Jorge.Cuellar@siemens.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Tschofenig, Cuellar Expires - December 2003 [Page 15]
Geopriv Authorization Policies June 2003
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 assignees.
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.
Tschofenig, Cuellar Expires - December 2003 [Page 16]