[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
SIP                                                         J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: December 21, 2006                                 June 19, 2006


             Coexistence of P-Asserted-ID and SIP Identity
              draft-rosenberg-sip-identity-coexistence-00

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 December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Two mechanisms have been defined to support forms of authenticated
   caller identity in the Session Initiation Protocol (SIP).  The first,
   specified in RFC 3325, is the P-Asserted-ID header field.  The
   second, termed "SIP Identity", defines the Identity and Identity-Info
   header fields and provides cryptographically verifiable identities.
   This document discusses how to use these mechanisms together.






Rosenberg               Expires December 21, 2006               [Page 1]


Internet-Draft            Identity Coexistence                 June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   3.  User Agent Behavior  . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Registration . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Generating a Request . . . . . . . . . . . . . . . . . . .  6
     3.3.  Receiving a Request  . . . . . . . . . . . . . . . . . . .  6
   4.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Egress Proxy . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Ingress Proxy  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Interactions with B2BUAs . . . . . . . . . . . . . . . . . . .  8
   6.  Interactions with Privacy  . . . . . . . . . . . . . . . . . .  8
   7.  P-header or not? . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.2. URI Parameter  . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14


























Rosenberg               Expires December 21, 2006               [Page 2]


Internet-Draft            Identity Coexistence                 June 2006


1.  Introduction

   One of the most important security features in the Session Initiation
   Protocol (SIP) [1] is the ability to convey the identity of the
   initiating party of a request.  This feature, sometimes known as
   "secure caller ID", has been the discussion of much discussion, and
   is supported by numerous specifications.

   The first work in secure caller ID is within RFC 3261 itself.  SIP
   provides support for S/MIME.  This allows for the initiator of a SIP
   request to sign the request with their private key, which can then be
   verified by the recipient using their public key.  This mechanism,
   while very secure, has seen little implementation and no deployment.
   It requires an easy to use certificate enrollment system by which end
   users can obtain, store, and manage certificates.  To date, systems
   for providing certificates for end users have proven difficult if not
   impossible to deploy.

   Consequently, implementations relied on the From header field in the
   SIP request, unsigned, to obtain the identity of the sender.  This is
   easily spoofable and a clear risk.  To combat it, the P-Asserted-ID
   header field was developed [6].  With this mechanism, the originating
   domain of the requestor authenticates them, typically using
   traditional SIP digest mechanisms.  Once authenticated, the SIP proxy
   inserts a header field - the P-Asserted-ID header field - containing
   the authenticated identity of the request originator.  This header
   field is not signed in any way.  Instead, the header field is only
   conveyed between domains that have a specific trust relationship.
   Domains receiving requests with this header field from domains they
   don't trust remove the header field.  Furthermore, the link between
   proxies in different domains is secured with SIP over TLS, allowing
   domains to mutually authenticate each other.

   Due to its requirement for bilateral trust agreements between
   domains, RFC 3325 is only applicable to closed-knit communities of a
   small number of relatively large providers.  For this reason, the
   P-Asserted-ID header field was granted "P-header" status [7], and was
   subsequently adopted by the 3gpp for use in the Internet Multimedia
   Subsystem (IMS).

   However, it was recognized by IETF that this mechanism was a short-
   term solution, and a longer term one was required.  It consequently
   developed the "SIP identity" mechanism [4].  The SIP identity
   mechanism defines the Identity and Identity-Info header field.  As in
   RFC 3325, an originating proxy in the domain of the requestor
   authenticates the user, typically using SIP digest.  Once
   authenticated, the originating proxy checks if the From header field
   value matches the authenticated identity.  If it does, it signs



Rosenberg               Expires December 21, 2006               [Page 3]


Internet-Draft            Identity Coexistence                 June 2006


   certain header fields, including the From header field, and places
   the result into the Identity header field.  The proxy then populates
   the Identity-Info header field with a URI that can be used to obtain
   the certificate for the domain.

   The SIP identity mechanism provides a far superior technical solution
   to secure caller ID than RFC 3325.  Its cryptographically verifiable
   identies are the cornerstone of anti-spam mechanisms [8], which will
   not work properly with RFC 3325.

   Unfortunately, deployment of SIP identity appears problematic due to
   several practical considerations.  Firstly, RFC 3325 has enjoyed
   widespread deployment.  It is build into numerous proxy and
   application server products, and is also widely used in end user
   devices.  Many IP phones or adaptors will look for the P-Asserted-ID
   header field as the source for secure caller ID.  To bring the SIP
   identity mechanism into the mix, the caller, proxy, and
   unfortunately, called party must all be upgraded to support it.
   Neither the originating proxy or the calling party have any way to
   know whether the called party supports RFC 3325 or SIP identity,
   making it difficult to know which to use.  To maximize
   interoperability, it is more cost effective to use the mechanism that
   is most likely to work - RFC 3325.  This produces a chicken-and-egg
   problem that will substantially hamper the deployment of SIP
   identity.

   Secondly, the SIP identity mechanism provides a signature over the
   request which covers key parts of it, including the body.  This means
   that any elements on the request path between the originating proxy
   and the terminating user agent which modify the body in any way will
   invalidate the signature.  Though proxies are not supposed to modify
   the body, the industry has seen widespread usage of back-to-back user
   agents with media (B2BUA).  These components, to facilitate NAT
   traversal, call admission control, and other functions, modify the
   body of SIP requests.  SIP identity will not function with such
   elements on the request path.  This adds further to the difficulties
   in deploying SIP identity.

   To combat this problem, this document defines a mechanism for co-
   existence of SIP identity and P-Asserted-ID which greatly reduces the
   barriers to deployment for SIP identity.


2.  Overview of Operation

   The essential idea is to use the SIP identity mechanism between
   proxies, rather than P-Asserted-ID, but to retain the use of
   P-Asserted-ID as the mechanism for transfer of asserted identity



Rosenberg               Expires December 21, 2006               [Page 4]


Internet-Draft            Identity Coexistence                 June 2006


   within a domain.  The overall architecture is shown in Figure 1.


                Originating Domain             Terminating Domain
       ...............................    .................................
       .                             .    .                               .
       .          +------+  +------+ .    .  +------+  +------+           .
       .          |      |--|Egress|---------|Ingres|--|      |           .
       .         /|      |  |Proxy | .    .  |Proxy |  |      |\          .
       .        / +------+  +------+ .    .  +------+  +------+ \         .
       .       /                     .    .                      \        .
       .    +------+                 .    .                  +------+     .
       .    | Edge |                 .    .                  |      |     .
       .    |Proxy |                 .    .                  |      |     .
       .    +------+                 .    .                  +------+     .
       .     /                       .    .                      \        .
       ...../.........................    ........................\........
           /                                                       \
        +------+                                                  +------+
        |      |                                                  |      |
        | UAC  |                                                  | UAS  |
        +------+                                                  +------+

   Figure 1

   When a UA initiates a request, it is authenticated by the originating
   edge proxy.  Once the originator has been authenticated, the edge
   proxy inserts the P-Asserted-ID header field, per RFC 3325.  This
   header field remains in the request as long as it stays within the
   domain of the originator.  Once the request reaches the last proxy in
   the originating domain (the egress proxy), the egress proxy checks
   the P-Asserted-ID header field against the From header field.  If
   they match, the egress proxy removes the P-Asserted-ID header field,
   and adds an Identity and Identity-Info header field per [4].  This is
   sent to the proxy at the edge of the terminating domain (the ingress
   proxy).  The ingress proxy will verify the signature, and if it
   validates, insert the P-Asserted-ID header field containing the
   identity in the From header field.  However, the Identity and
   Identity-Info header fields remain in the request.

   When the request arrives at the terminating UA, it first checks for
   the Identity and Identity-Info header fields.  If present, the
   identity in the From header field is used as the caller ID.  If not
   present, but P-Asserted-ID is present, the UA uses the P-Asserted-ID
   header field as the caller ID.

   In order for a UA to determine if its domain supports the mechanisms
   in this specification, a UA will include a Supported header field in



Rosenberg               Expires December 21, 2006               [Page 5]


Internet-Draft            Identity Coexistence                 June 2006


   its REGISTER request with the option tag "id-coexist".  If the domain
   also supports the mechanism, it will include the same option tag in
   the REGISTER response.


3.  User Agent Behavior

3.1.  Registration

   When a UA compliant to this specification generates a REGISTER
   request, it SHOULD include a Supported header field in the request
   with the option tag "id-coexist".  When it receives a successful
   response to its registration, it checks for the Supported header
   field and the presence of this option tag.  If present, the UA knows
   that its domain supports the mechanisms of this specification.  This
   information is used in subsequent processing.

   OPEN ISSUE: this is a little hoakey.  We're using the option tag
   returned from a registrar to infer the behavior of a different
   element - the ingress proxy.  Is that OK?

3.2.  Generating a Request

   When originating a request besides a REGISTER, there is no special
   processing required.

3.3.  Receiving a Request

   When receiving an incoming request, the UA first checks for the
   presence of the Identity and Identity-Info header fields.  If
   present, the UA verifies the signature per [4].  If it verifies, the
   identity in the From header field is used as the identity of the
   sender.  If it does not verify, but its domain supports the
   coexistence mechanism (based on presence of the id-coexist option tag
   in the REGISTER response) and the request contained a P-Asserted-ID
   header field, the UA interprets this as the presence of a B2BUA with
   media in the terminating domain.  It uses the identity in the
   P-Asserted-ID header field as the identity of the sender.

   If the request did not contain either the Identity or Identity-Info
   header fields, but did contain the P-Asserted-ID header field, that
   identity is used as the identity of the sender if the clients domain
   supports the coexistence mechanism.  If the domain of the client
   doesn't support the co-existence mechanism, but the P-Asserted-ID
   header field is present, the identity of the sender of the request
   SHOULD be considered suspect.  This specification makes no normative
   recommendations on how to treat the request.  However,
   implementations should consider that, in this case, the identity



Rosenberg               Expires December 21, 2006               [Page 6]


Internet-Draft            Identity Coexistence                 June 2006


   cannot be trusted unless all of the conditions in the limited scope
   of applicability of RFC 3325 apply.

   If the request did not contain the Identity or Identity-Info header
   fields, and did not contain a P-Asserted-ID header field, the
   identity of the sender of the request SHOULD be considered suspect.
   The From header field, without a verified Identity header field, is
   extremely susceptible to spoofing.


4.  Proxy Behavior

4.1.  Edge Proxy

   An edge proxy is one that authenticates the originating party and
   asserts their identity.  An edge proxy SHOULD follow the procedures
   of RFC 3325, with one addition.  If there is no P-Preferred-ID header
   field in the request, it SHOULD use the From header field as the
   preferred ID.

4.2.  Egress Proxy

   An egress proxy is one that meets the following conditions:

   o  The next hop proxy is in a different administrative domain.

   o  The domain of the proxy matches the domain in the From header
      field of the request.

   If a request contains a P-Asserted-ID header field, and is received
   from a proxy inside of its domain, an egress proxy SHOULD act as an
   authentication service per [4].  It SHOULD use the P-Asserted-ID
   header field as the identity of the sender, rather than attempting to
   authenticate the request using SIP digest or some other mechanism.
   The ingress proxy SHOULD remove the P-Asserted-ID header field before
   forwarding the request.

4.3.  Ingress Proxy

   An ingress proxy is one whose previous hop was not in the same
   administrative domain.  When an ingress proxy receives a request, it
   MUST remove the P-Asserted-ID header field if present.  This is done
   regardless of the trust relationship with the originating domain, and
   is different from the procedures in RFC 3325, where the P-Asserted-ID
   is retained if it comes from a trusted peer.  Once removed, the
   ingress proxy checks for the presence of the Identity and Identity-
   Info header fields.  If present, the ingress proxy SHOULD verify the
   identity of the sender using the procedures in [4].  If the identity



Rosenberg               Expires December 21, 2006               [Page 7]


Internet-Draft            Identity Coexistence                 June 2006


   is verified, the ingress proxy SHOULD insert a P-Asserted-ID header
   field containing the identity contained in the From header field of
   the request.  The proxy SHOULD NOT remove the Identity and Identity-
   Info header fields.  This allows for SIP networks where there are
   more than two administrative domains in a request path, and also
   allows for a UA to verify the signature on its own if it should
   desire.


5.  Interactions with B2BUAs

   By using the SIP identity mechanism between domains, it will continue
   to work in the presence of Contact or body-modifying B2BUAs in the
   request path.  In particular, any B2BUA on the request path prior to
   the egress proxy, and any B2BUA on the request path subsequent to the
   ingress proxy in the domain of the UAS, will not cause the mechanism
   described here to fail.  Note that, in cases where a proxy serves as
   both a B2BUA and an egress proxy, it MUST perform the B2BUA function
   prior to the egress functions described here.  Similarly, in cases
   where a proxy serves as a B2BUA and an ingress proxy, it MUST perform
   the B2BUA function after the ingress functions described here.

   It is important to note that the mechanism described here will not
   work properly in transit networks that contain a B2BUA.  A transit
   network is defined as a SIP domain that is between the domain of the
   originator and the domain of the terminating UA.  If a B2BUA in a
   transmit network touches the fields covered by the signature,
   verification will fail at the ingress proxy in the termindating case.


6.  Interactions with Privacy

   Privacy has always been a complicated issue with the various identity
   mechanisms.  The privacy specification, RFC 3323 [2] is used by RFC
   3325.  However, it has a significant problem in that a UAS cannot
   differentiate between a private caller (where the P-Asserted-ID has
   been removed from the request) and identity unavailable (where the
   domain of the originator didn't support P-Asserted-ID, or where the
   originating network was the PSTN and no identity could be obtained).
   The interactions with SIP identity and privacy are even more
   complicated.  RFC 3323 does not work with SIP identity; this is
   documented in detail in [5].

   Combining together RFC 3325 and SIP identity requires privacy
   mechanisms to be combined as well.

   A UA wishing to be anonymous would include an anonymous URI in the
   From header field.  This specification proposes that an anonymous



Rosenberg               Expires December 21, 2006               [Page 8]


Internet-Draft            Identity Coexistence                 June 2006


   identity be indicated with the "user=anonymous" URI parameter,
   extending the existing "user" URI parameter with this value.  A UA
   can either obtain an anonymous URI from its domain with mechanisms
   TBD, or merely make up a random value for the user part of the URI,
   using a domain of "anonymous.invalid".

   The edge proxy would authenticate the request, and insert
   P-Asserted-ID as normal.  This would be stripped by the egress proxy.
   If the From header field contained an anonyous URI that matched the
   P-Asserted-ID header field (possible only if the anonymous URI had
   been obtained from its domain), the egress proxy would sign the
   request using SIP identity.  Otherwise, it would not.

   At the ingress proxy, the signature is verified if present.  If not
   present, no P-Asserted-ID is inserted.  At the receiving UAS, if a
   P-Asserted-ID was present, the "user=anonymous" URI parameter tells
   the UAS that the requestor is anonymous and verified.  If a
   P-Asserted-ID is not present, the presence of the "user=anonymous"
   URI parameter tells the UAS that the requestor is anonymous, and that
   its identity is unverified.  It can then render "Anonymous" or
   whatever is appropriate for the user interface.

   TODO: fold in the normative recommendations here into the UA and
   proxy behaviors described above.


7.  P-header or not?

   With the recommendations in this document, we believe that the
   applicability of P-Asserted-ID is now no longer limited.  It becomes
   applicable within the intra-domain signaling of any SIP domain.  This
   begs the question of whether the header field name should now be
   changed to "Asserted-ID".  The answer is an emphatic no!  One of the
   benefits of the coexist mechanism is that it is backwards compatible
   with RFC 3325, which uses the P-Asserted-ID header field.  This
   exposes a weakness in the concepts in RFC 3427, since we will now
   have a header with the P prefix which is not actually a P-header.

   Procedurally, we'd recommend that, if this document moves forward, it
   be done as an update to both SIP identity and RFC 3325, and be at
   proposed standard status.  Indeed, it should probably be done as an
   actual revision to RFC 3325.


8.  Benefits

   This mechanism brings many benefits:




Rosenberg               Expires December 21, 2006               [Page 9]


Internet-Draft            Identity Coexistence                 June 2006


   o  Does not require the originating domain to know whether the
      terminating domain supports the mechanism.

   o  Works in the presence of B2BUAs in the originating and terminating
      domains.

   o  Makes P-Asserted-ID applicable only in intra-domain environments,
      eliminating its primary security weakness

   o  Provides the cryptographic strengths of SIP identity to the
      terminating domain, so that mechanisms such as spam detection can
      be effective.

   o  The proposed privacy solution clearly defines a URI as anonymous
      independent of the locale and language of the terminating domain

   o  The proposed privacy solution clearly differentiates an anonymous
      request (one whose From header field contains the user=anonymous
      parameter) from one where identity could not be provided


9.  Security Considerations

   The combination of RFC 3325 with SIP identity provides a mechanism
   that is, overall, less secure than just SIP identity alone.  With SIP
   identity, the signature is inserted by the first hop proxy (edge
   proxy) which performs the authentication.  This allows all other
   proxies in the originating domain to determine the identity of the
   originator by verifying the signature.  With the mechanism proposed
   here, proxies within the domain of the originator would use the
   P-Asserted-ID header field, which lacks any cryptographic signature.
   This requires a greater degree of trust within the proxies of the
   domain.  A rogue proxy in the domain of the originator could insert a
   fake P-Asserted-ID header field, and it would not be caught by the
   coexist mechanism.

   In addition, the mechanism here relies on a UAS to trust its
   terminating domain to follow the procedures defined here and verify
   the signature in the Identity header field.  If a rogue proxy in the
   terminating domain should insert a fake P-Asserted-ID header field,
   this would not be caught by the coexist mechanism.

   Though its overall security is weaker than SIP identity, we fear that
   the perfect is the enemy of the good.  Without changes, SIP identity
   will be undeployable, and the industry will instead stick with the
   much-worse P-Asserted-ID solution.  The coexist mechanism trades some
   security in exchange for a mechanism that is far more deployable.




Rosenberg               Expires December 21, 2006              [Page 10]


Internet-Draft            Identity Coexistence                 June 2006


   As with RFC 3325, the links over which P-Asserted-ID is transmitted
   SHOULD be secured with SIP over TLS.  This prevents against MITM
   attacks.


10.  IANA Considerations

   This specification defines a new SIP option tag and a new SIP URI
   parameter.

10.1.  Option Tag

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of RFC 3261.

   Name: id-coexist

   Description: This option tag is used to identify the ID coexist
      mechanism.  It is primarily used to tell a UA that its domain
      supports mechanisms which allow for the coexistence of
      P-Asserted-ID and SIP identity.

10.2.  URI Parameter

   This specification extends the value of the user URI parameter, as
   per the registry created by [3].

   Name of the Parameter: user

   Predefined Values: anonymous

   RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
      RFC number of this specification.]]


11.  References

11.1.  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Peterson, J., "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", RFC 3323, November 2002.

   [3]  Camarillo, G., "The Internet Assigned Number Authority (IANA)
        Uniform Resource Identifier (URI) Parameter Registry for the



Rosenberg               Expires December 21, 2006              [Page 11]


Internet-Draft            Identity Coexistence                 June 2006


        Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
        December 2004.

   [4]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation  Protocol (SIP)",
        draft-ietf-sip-identity-06 (work in progress), October 2005.

   [5]  Rosenberg, J., "Identity Privacy in the Session Initiation
        Protocol (SIP)", draft-rosenberg-sip-identity-privacy-00 (work
        in progress), July 2005.

11.2.  Informative References

   [6]  Jennings, C., Peterson, J., and M. Watson, "Private Extensions
        to the Session Initiation Protocol (SIP) for Asserted Identity
        within Trusted Networks", RFC 3325, November 2002.

   [7]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
        Rosen, "Change Process for the Session Initiation Protocol
        (SIP)", BCP 67, RFC 3427, December 2002.

   [8]  Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam",
        draft-ietf-sipping-spam-02 (work in progress), March 2006.




























Rosenberg               Expires December 21, 2006              [Page 12]


Internet-Draft            Identity Coexistence                 June 2006


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net








































Rosenberg               Expires December 21, 2006              [Page 13]


Internet-Draft            Identity Coexistence                 June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg               Expires December 21, 2006              [Page 14]