SIPPING WG C. Jennings
Internet-Draft Cisco Systems, Inc.
Expires: October 31, 2002 May 2, 2002
Extensions to the Session Initiation Protocol (SIP) for Network
Asserted Identity within Trusted Networks
draft-jennings-sipping-nai-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
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/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 October 31, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes extensions to SIP that enable a network of
trusted SIP servers to assert the identity of end users or end
systems, and to convey indications of end-user requested privacy.
The use of these extensions are only applicable inside an
administrative domain, or among federations of administrative domains
with previously agreed-upon policies for usage of such information.
This document does NOT offer a general privacy or identity model
suitable for inter-domain use or use in the Internet at large.
Jennings Expires October 31, 2002 [Page 1]
Internet-Draft SIP Network Asserted Identity May 2002
Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 6
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 The Network-Asserted-ID Header . . . . . . . . . . . . . . . 6
7.2 The "nai" Privacy Type . . . . . . . . . . . . . . . . . . . 7
7.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3.1 Network Asserted Identity passed to trusted gateway . . . . 7
7.3.2 Network Asserted Identity withheld . . . . . . . . . . . . . 9
8. Comparison to Requirements . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
10.1 Registration of "Network-Asserted-ID" SIP header . . . . . . 12
10.2 Registration of "nai" privacy type for SIP Privacy header . 12
11. Open Issues: . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . 13
Informational References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
Jennings Expires October 31, 2002 [Page 2]
Internet-Draft SIP Network Asserted Identity May 2002
1. Applicability Statement
This document describes extensions to SIP [1] that enable a network
of trusted SIP servers to assert the identity of end users or end
systems, and to convey indications of end-user requested privacy.
The use of these extensions are only applicable inside an
administrative domain, or among federations of administrative domains
with previously agreed-upon policies for usage of such information.
Such a "network" is explicitly trusted by its users and end-systems
to either publicly assert the identity of each party, or be
responsible for withholding that identity outside of the trusted
domain or federation of domains if privacy is requested. The means
by which the network determines the identity to assert is outside the
scope of this document.
This document does NOT offer a general privacy or identity model
suitable for inter-domain use or use in the Internet at large. Its
assumptions about the trust relationship between the user and the
network may not apply in many applications. For example, these
extensions do not accommodate a model whereby end users can
independently assert their identity by use of the extensions defined
here. Furthermore, since the asserted identities are not
cryptographically certified, they are subject to forgery, replay, and
falsification in any architecture that does not provide full
transitive trust. The asserted identities also lack an indication of
who is asserting the identity, and therefore the assertions are not
useful outside of the federation of domains, where such information
would be crucial in order to determine the validity or value of the
assertion.
Despite these limitations, there are sufficiently useful specialized
deployments that meet the assumptions described above, and can accept
the limitations that result, to warrant publication of this
mechanism. An example deployment would be a closed network which
emulates a traditional circuit switched telephone network.
It should be noted, that the mechanisms described in this draft are
not intended to be used for user-asserted identity. As described
above, the mechanisms are merely intended to enable trusted
intermediaries to assert an identity for users.
2. Conventions
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 [3].
For the purpose of definitions within this document, trust is a
Jennings Expires October 31, 2002 [Page 3]
Internet-Draft SIP Network Asserted Identity May 2002
transitive property. If A trusts B and B trusts C, then A,B, and C
are all in the same trust domain.
For one node to consider another node trusted, it means that the node
is willing to delegate to all the nodes in that trust domain the
requirements and responsibilities that this draft specifies. It also
means the node is willing to share the private network identity
information with all the nodes in the trust domain. For one node to
trust another node, it must be sure that it is communicating with the
correct node, that this node has been administratively added to the
trust domain, and that this communication can not be intercepted,
modified, or replayed by any node that is not part of the trust
domain.
Throughout this document requirements for or references to proxy
servers or proxy behavior apply similarly to other intermediaries
(ex: B2BUAs).
3. Introduction
Various providers which attempt to offer a telephony service over IP
networks have selected SIP as a base protocol. These environments
require a way for trusted network elements (for example SIP proxy
servers) to communicate the identity of users using such a service,
yet also need to withhold this information from untrusted entities
under certain circumstances. Such networks typically assume some
level of transitive trust.
These networks need to interoperate with some basic telephony
services and meet basic regulatory and public safety requirements.
These include Calling Identity Delivery services, Calling Identity
Delivery Blocking, and the ability to trace the originator of a call.
While baseline SIP can support each of these services independently,
certain combinations cannot be supported. For example, a caller that
wants to maintain privacy and consequently provides unintelligible
information in the SIP From header field will not be identifiable to
SIP entities that do not directly perform SIP authentication.
However, this will prevent certain services, e.g., call trace, from
working in the PSTN or being performed at intermediaries not privy to
the authenticated identity of the user.
This document attempts to address this requirement using a very
limited, simple mechanism, based on requirements in [5]. A previous
attempt to solve this problem ([6]), from which this work was
derived, has not generated working group consensus. A more
comprehensive mechanism ([7]) which uses cryptography to address this
problem is the subject of future analysis by the SIP working group.
Jennings Expires October 31, 2002 [Page 4]
Internet-Draft SIP Network Asserted Identity May 2002
Providing privacy in an IP network is more complicated than in the
PSTN. In IP networks the participants in a session will normally
exchange IP traffic directly. The IP addresses used for these
sessions may themselves reveal some privacy. A general purpose
mechanism for providing privacy in a SIP environment is discussed in
[2]. This document extends these mechanism to compensate for the
information it adds.
4. Overview
The mechanism proposed in this draft results in a header that looks
like:
Network-Asserted-ID: "Cullen Jennings" <fluffy@cisco.com>
An authenticating proxy which receives a message can authenticate the
user associated with the UAC using an appropriate mechanism (for
example: Digest authentication, or TLS mutual authentication). The
proxy then inserts a Network-Asserted-ID header in the message and
forwards it on to other trusted proxies. A proxy that is about to
forward a message to an untrusted proxy or UA, removes the Network-
Asserted-ID header if the user requested that this information be
kept private. Users can request this type of privacy by including a
Privacy header with the "nai" privacy type in their request.
5. Proxy Behavior
When a proxy receives a message it may be from a trusted or untrusted
SIP entity. When a proxy receives a request from a untrusted
element, the proxy SHOULD authenticate the user, and using the
identity which results from this authentication it MAY insert a
Network-Asserted ID header. If a Network-Asserted-ID header is
already present in the message, the proxy MAY use this information as
a hint suggesting which of multiple valid identities for the
authenticated user should be asserted. If such a hint does not
correspond to any valid identity known to the proxy for that user,
the proxy MUST discard the user-provided Network-Asserted-ID header.
In this case, the proxy MAY add a Network-Asserted-ID header of its
own construction, or it MAY refuse to forward the request and return
a 403 Forbidden response instead. If no Network-Asserted-ID header
is present in the request, and the user has multiple valid identities
known to the proxy server, the proxy MAY use the From header as a
similar hint.
If the proxy receives a message (request or response) from a trusted
element, it MAY use the information in the Network-Asserted-ID header
as if it had authenticated the user itself. For the received message
to be trusted, the receiving proxy MUST be sure it came from a
Jennings Expires October 31, 2002 [Page 5]
Internet-Draft SIP Network Asserted Identity May 2002
trusted SIP element, and that the message was not tampered with in
transit.
When a proxy forwards a message to another element, it must first
determine if that element is trusted or untrusted. If the element is
trusted, the proxy MAY include the Network-Asserted-ID header. If
the element is not trusted, then the proxy MUST examine the Privacy
header (if present) to determine if the user requested that this
information be kept private by specifying the "nai" privacy type. If
so, the proxy MUST remove the Network-Asserted-ID header. In
addition, for backward compatibility, the proxy SHOULD examine the
From field for an anonymous value and similarly use this as an
indication that the user would like this information to remain
private. Otherwise the proxy is encouraged to remove the Network-
Asserted-ID header but MAY choose not to.
6. User Agent Behavior
In general, a User Agent Client does not need to insert a Network-
Asserted-ID header. If a UAC is confident that it is sending a
request to a trusted outbound proxy, and it has multiple possible
network asserted identities, it MAY place the identity that it wishes
the proxy to assert for it as a hint in a Network-Asserted-ID header.
TLS server authentication provides one possible mechanism by which
the UAC can determine that the message is going to the correct proxy.
If a User Agent Server receives a message from an untrusted previous
hop, it SHOULD ignore any Network-Asserted-ID header, but it MAY
present the information to the user in the same manner as an
unverified From address, with a warning that this information is not
verified in any way. If a UAS receives a Network-Asserted-ID from a
trusted entity, then it MAY use the information but it MUST ensure
that it does not forward the information to any untrusted element.
For example, in the case of an anonymous call going to a PSTN
gateway, the gateway MAY pass the Network-Asserted-ID information to
the PSTN but it must make sure the call is appropriately signaled so
that this information will not be leaked outside of an appropriate
trust boundary.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [4].
7.1 The Network-Asserted-ID Header
The Network-Asserted-ID header is used among trusted SIP entities
(typically intermediaries) to carry the identity of the user sending
Jennings Expires October 31, 2002 [Page 6]
Internet-Draft SIP Network Asserted Identity May 2002
a SIP message as it was verified by authentication with a trusted
entity.
NetworkAssertedID = "Network-Asserted-ID" HCOLON ( name-addr / addr-spec )
A Network-Asserted-ID header MUST contain exactly one name-addr or
addr-spec. Only a single Network-Asserted-ID header can be present
in a SIP message. It is worth noting that Proxies can (and will) add
and remove this header.
This document adds the following entry to Table 2 of [1]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Network-Asserted-ID adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
7.2 The "nai" Privacy Type
This specification adds a new privacy type ("priv-value") to the
Privacy header, defined in [2]. The presence of this privacy type in
a SIP Privacy header indicates that the user would like the Network
Asserted Identity to be kept private with respect to SIP entities
outside the trust domain or trust federation with which the user
authenticated. Note that a user requesting multiple types of privacy
MUST include all of the requested privacy types in its Privacy
header.
priv-value = "header" / "session" / "nai" / token
Example:
Privacy: nai
7.3 Examples
7.3.1 Network Asserted Identity passed to trusted gateway
In this example, proxy.cisco.com creates a Network-Asserted-ID header
from an identity it discovered from SIP Digest authentication. It
Jennings Expires October 31, 2002 [Page 7]
Internet-Draft SIP Network Asserted Identity May 2002
forwards this information to a trusted proxy which forwards it to a
trusted gateway.
* F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: nai
* F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: nai
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4 proxy.cisco.com -> proxy.pstn.net (trusted)
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
Via: SIP/2.0/TCP proxy.cisco.com
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
Network-Asserted-ID: "14085264000" <sip:fluffy@cisco.com>
Jennings Expires October 31, 2002 [Page 8]
Internet-Draft SIP Network Asserted Identity May 2002
Privacy: nai
* F5 proxy.pstn.net -> gw.pstn.net (trusted)
INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
Via: SIP/2.0/TCP proxy.cisco.com
Via: SIP/2.0/TCP proxy.pstn.net
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
Network-Asserted-ID: "14085264000" <sip:fluffy@cisco.com>
Privacy: nai
7.3.2 Network Asserted Identity withheld
In this example, the User Agent provides a hint to its first hop
proxy, which it uses after verifying this identity with SIP Digest
authentication. The first proxy creates a Network-Asserted-ID header
and forwards it to a trusted proxy (outbound.cisco.com). The next
proxy removes the Network-Asserted-ID header, and the request for
Privacy before forwarding this request onward to the untrusted
biloxi.com proxy server.
* F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: nai
* F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
Jennings Expires October 31, 2002 [Page 9]
Internet-Draft SIP Network Asserted Identity May 2002
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: nai
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4 proxy.cisco.com -> outbound.cisco.com (trusted)
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
Via: SIP/2.0/TCP proxy.cisco.com
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: nai
* F5 outbound.cisco.com -> proxy.biloxi.com (untrusted)
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
Via: SIP/2.0/TCP proxy.cisco.com
Via: SIP/2.0/TCP outbound.cisco.com
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
* F6 proxy.biloxi.com -> bobster.biloxi.com
INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com
Via: SIP/2.0/TCP proxy.cisco.com
Via: SIP/2.0/TCP outbound.cisco.com
Via: SIP/2.0/TCP proxy.biloxi.com
Jennings Expires October 31, 2002 [Page 10]
Internet-Draft SIP Network Asserted Identity May 2002
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 67
8. Comparison to Requirements
Some other approaches have suggested that the header should also
include information about who asserted it. Inside the trust domain,
this is well known, the trust domain asserted it. Outside the trust
domain, this information can not be trusted and therefore should not
be used. Since there was no use for it in either case, it was not
included.
The requirements request that the identity of the calling and the
called users are supported. This is determined from the context of
the messages. If the message is going from the UAC to the UAS, then
the network-ID header asserts the identity of the UAC while for
messages going the other direction it asserts the identity of the
UAS.
The requirements only require the ability to assert a single identity
though they mention it may be possible to extend to more later. This
was explicitly not done in this document because it is unnecessarily
complicated.
9. Security Considerations
The mechanism provided in this document is a partial consideration of
the problem of identity and privacy in SIP. For example, these
mechanisms provide no means by which end users can conceal their
identities from the network. Information which the user designates
as 'private' can be inspected by any intermediaries participating in
the trusted network. This information is passed by transitive
trust, which is only as reliable as the weakest link in the chain of
trust.
When a trusted entity has determined the identity information for a
user that wishes to remain private, and the trusted entity then sends
a message to any destination with that party's identity in a Network-
Asserted-ID header, the entity MUST take precautions to protect the
identity information from eavesdropping and interception to protect
the confidentiality and integrity of that identity information. The
Jennings Expires October 31, 2002 [Page 11]
Internet-Draft SIP Network Asserted Identity May 2002
use of transport or network layer hop-by-hop security mechanisms,
such as TLS or IPSec, can satisfy this requirement.
Finally, a user agent or proxy can only assume that a privacy request
will be honored if it is sent to a trusted entity. Thus, if a user
agent or proxy does not know if its SIP message (request or response)
is sent to a trusted entity (proxy or UA), it should assume that a
privacy request for that message will not be honored.
10. IANA Considerations
10.1 Registration of "Network-Asserted-ID" SIP header
Name of Header: Network-Asserted-ID
Short form: none
Registrant: Cullen Jennings
fluffy@cisco.com
Normative description: section 7.1 of this document
10.2 Registration of "nai" privacy type for SIP Privacy header
Name of privacy type: nai
Short Description: Privacy requested for the Network-Asserted-ID header
Registrant: Cullen Jennings
fluffy@cisco.com
Normative description: section 7.2 of this document
11. Open Issues:
Should an options tag be required so that the UA knows the proxy will
support this? It seemed like if you know you could trust the proxy
you would already know this so it did not seem valuable.
Should a proxy sending a message to a untrusted element be REQUIRED
to remove the Network-ID header?
Would "Proxy-From" be a better name for this header?
Jennings Expires October 31, 2002 [Page 12]
Internet-Draft SIP Network Asserted Identity May 2002
12. Acknowledgments
Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5],
and Jon Peterson [7] for authoring drafts which represent the bulk of
the text making up this document.
Normative References
[1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
February 2002.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work in
progress), April 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Informational References
[5] Watson, M., "Short Term Requirements for Network Asserted
Identity", draft-watson-sipping-nai-reqs-00.txt (work in
progress), May 2002.
[6] Marshall, W., "SIP Extensions for Network-Asserted Caller
Identity and Privacy within Trusted Networks", draft-ietf-sip-
privacy-04 (work in progress), March 2002.
[7] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-
peterson-sip-identity-00 (work in progress), April 2002.
Author's Address
Cullen Jennings
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: fluffy@cisco.com
Jennings Expires October 31, 2002 [Page 13]
Internet-Draft SIP Network Asserted Identity 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.
Jennings Expires October 31, 2002 [Page 14]