[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jennings-sipping-certs) 00 01 02 03 draft-ietf-sip-certs

SIP                                                          C. Jennings
Internet-Draft                                             Cisco Systems
Expires: August 20, 2005                                     J. Peterson
                                                           NeuStar, Inc.
                                                       February 19, 2005


   Certificate Management Service for The Session Initiation Protocol
                                 (SIP)
                      draft-ietf-sipping-certs-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 20, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This draft defines a Credential Service that allows SIP User Agents
   to use a SIP package to discover the certificates of other users.
   This mechanism allows user agents that want to contact a given
   Address-of-Record (AOR) to retrieve that AOR's certificate by
   subscribing to the Credential Service.  The Credential Service also



Jennings & Peterson     Expires August 20, 2005                 [Page 1]


Internet-Draft              SIP Certificates               February 2005


   allows users to store and retrieve their own certificates and private
   keys.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   UA Behavior with Certificates  . . . . . . . . . . . . . . .   6
   5.   UA Behavior with Credentials . . . . . . . . . . . . . . . .   7
   6.   Credential Service Behavior  . . . . . . . . . . . . . . . .   8
   7.   Event Package Formal Definition for "certificate"  . . . . .   8
     7.1  Event Package Name . . . . . . . . . . . . . . . . . . . .   8
     7.2  Event Package Parameters . . . . . . . . . . . . . . . . .   8
     7.3  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .   9
     7.4  Subscription Duration  . . . . . . . . . . . . . . . . . .   9
     7.5  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .   9
     7.6  Subscriber Generation of SUBSCRIBE Requests  . . . . . . .   9
     7.7  Notifier Processing of SUBSCRIBE Requests  . . . . . . . .   9
     7.8  Notifier Generation of NOTIFY Requests . . . . . . . . . .  10
     7.9  Subscriber Processing of NOTIFY Requests . . . . . . . . .  10
     7.10   Handling of Forked Requests  . . . . . . . . . . . . . .  10
     7.11   Rate of Notifications  . . . . . . . . . . . . . . . . .  10
     7.12   State Agents and Lists . . . . . . . . . . . . . . . . .  11
     7.13   Behavior of a Proxy Server . . . . . . . . . . . . . . .  11
   8.   Event Package Formal Definition for "credential" . . . . . .  11
     8.1  Event Package Name . . . . . . . . . . . . . . . . . . . .  11
     8.2  Event Package Parameters . . . . . . . . . . . . . . . . .  11
     8.3  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  11
     8.4  Subscription Duration  . . . . . . . . . . . . . . . . . .  11
     8.5  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  12
     8.6  Subscriber Generation of SUBSCRIBE Requests  . . . . . . .  12
     8.7  Notifier Processing of SUBSCRIBE Requests  . . . . . . . .  13
     8.8  Notifier Generation of NOTIFY Requests . . . . . . . . . .  13
     8.9  Notifier Processing of PUBLISH Requests  . . . . . . . . .  13
     8.10   Subscriber Processing of NOTIFY Requests . . . . . . . .  14
     8.11   Handling of Forked Requests  . . . . . . . . . . . . . .  14
     8.12   Rate of Notifications  . . . . . . . . . . . . . . . . .  14
     8.13   State Agents and Lists . . . . . . . . . . . . . . . . .  14
     8.14   Behavior of a Proxy Server . . . . . . . . . . . . . . .  14
   9.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1  Encrypted Page Mode IM Message . . . . . . . . . . . . . .  14
     9.2  Setting and Retrieving UA Credentials  . . . . . . . . . .  15
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  16
     10.1   Certificate Revocation . . . . . . . . . . . . . . . . .  18
     10.2   Certificate Replacement  . . . . . . . . . . . . . . . .  19
     10.3   Trusting the Identity of a Certificate . . . . . . . . .  19
     10.4   Conformity to the SACRED Framework . . . . . . . . . . .  20



Jennings & Peterson     Expires August 20, 2005                 [Page 2]


Internet-Draft              SIP Certificates               February 2005


     10.5   Crypto Profiles  . . . . . . . . . . . . . . . . . . . .  20
     10.6   User Certificate Generation  . . . . . . . . . . . . . .  20
     10.7   Compromised Authentication Service . . . . . . . . . . .  20
   11.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  21
     11.1   Certificate Event Package  . . . . . . . . . . . . . . .  21
     11.2   Credential Event Package . . . . . . . . . . . . . . . .  22
     11.3   PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . .  22
   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  23
   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  23
   13.1   Normative References . . . . . . . . . . . . . . . . . . .  23
   13.2   Informational References . . . . . . . . . . . . . . . . .  24
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  26






































Jennings & Peterson     Expires August 20, 2005                 [Page 3]


Internet-Draft              SIP Certificates               February 2005


1.  Introduction

   SIP [6] provides a mechanism [17] for end-to-end encryption and
   integrity using S/MIME [16].  Several security properties of SIP
   depend on S/MIME, and yet it has not been widely deployed.
   Certainly, one reason is the complexity of providing a reasonable
   certificate distribution infrastructure.  This specification proposes
   a way to address discovery, retrieval, and management of certificates
   for SIP deployments.  It follows the Sacred Framework RFC 3760 [7]
   for management of the credentials.  Combined with the SIP Identity
   [2] specification, this specification allows users to have
   certificates that are not signed by any well known certificate
   authority while still strongly binding the user's identity to the
   certificate.  This mechanism allows SIP User Agents such as IP phones
   to enroll and get their credentials without any more configuration
   information than they commonly have today.  The end user expends no
   extra effort.

2.  Definitions

   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 [5].

   Certificate: An X.509v3 [15] style certificate containing a public
   key and a list of identities in the SubjectAltName that are bound to
   this key.  The certificates discussed in this draft are generally
   self signed and use the mechanisms in the SIP Identity [2]
   specification to vouch for their validity.

   Credential: For this document, credential means the combination of a
   certificate and the associated private key.

3.  Overview

   The general approach is to provide a new SIP service referred to as a
   Credential Service that allows SIP User Agents (UAs) to subscribe to
   some other user's certificate using a new SIP event package [4].  The
   certificate is delivered to the subscribing UA in a corresponding SIP
   NOTIFY request.  The identity of the certificate can be vouched for
   using the Authentication Service from the SIP Identity [2]
   specification, which uses the domain's certificate to sign the NOTIFY
   request.  The Credential Service can manage public certificates as
   well as the user's private keys.  Users can update their credentials,
   as stored on the Credential Service, using a SIP PUBLISH [3] request.
   The UA authenticates to the Credential Service using a shared secret
   when a UA is updating a credential.  Typically the shared secret will
   be the same one that is used by the UA to authenticate a REGISTER



Jennings & Peterson     Expires August 20, 2005                 [Page 4]


Internet-Draft              SIP Certificates               February 2005


   request with the Registrar for the domain (usually with SIP Digest
   Authentication).

   The following figure shows Bob publishing his credentials from one of
   his User Agents (ex: his laptop software client), retrieving his
   credentials from another of his User Agents (ex: his mobile phone),
   and then Alice retrieving Bob's certificate and sending a message to
   Bob.  SIP 200-class responses are omitted from the diagram to make
   the figure easier to understand.

                example.com domain
                ------------------
    Alice       Proxy  Auth   Cred               Bob1  Bob2
      |           |      |      | TLS Handshake    |    |
      |  [ Bob generates   ]    |<--------------------->|
      |  [ credentials and ]    | PUBLISH (credential)  |
      |  [ publishes them  ]    |<----------------------|
      |           |      |      | Digest Challenge      |
      |           |      |      |---------------------->|
      |           |      |      | PUBLISH + Digest      |
      |           |      |      |<----------------------|
      |           |      |      |                  |
      |           |      |      | time passes...   |
      |           |      |      |                  |
      |           |      |      | TLS Handshake    |
      |   [ Bob later gets ]    |<---------------->|
      |   [ back his own   ]    | SUBSCRIBE        |
      |   [ credentials    ]    | (credential)     |
      |   [ at another     ]    |<-----------------|
      |   [ User Agent     ]    | SUBSCRIBE+Digest |
      |           |      |      |<-----------------|
      |           |      |      | NOTIFY           |
      |           |      |      |----------------->|
      |           |      |      | Bob Decrypts key |
      |           |      |      |                  |
      |           |      |      |                  |
      | SUBSCRIBE (certificate) |    Alice fetches |
      |---------->|----->|----->|    Bob's cert    |
      |           |      |NOTIFY|                  |
      | NOTIFY+Identity  |<-----|                  |
      |<----------+------|      |  Alice uses cert |
      |           |      |      |  to encrypt      |
      | MESSAGE   |      |      |  message to Bob  |
      |---------->|------+------+----------------->|

   Bob's UA (Bob2) does a TLS [11] handshake with the credential server
   to authenticate that the UA is connected to the correct credential
   server.  Then Bob's UA publishes his newly created or updated



Jennings & Peterson     Expires August 20, 2005                 [Page 5]


Internet-Draft              SIP Certificates               February 2005


   credentials.  The Credential server digest challenges the UA to
   authenticate that the UA knows Bob's shared secret.  Once the UA is
   authenticated, the credential server stores Bob's credentials.

   Another one of Bob's User Agents (Bob1) wants to fetch its current
   credentials.  It does a TLS [11] handshake with the credential server
   to authenticate that the UA is connected to the correct credential
   server.  Then Bob's UA subscribes for the credentials.  The
   Credential server digest challenges the UA to authenticate that the
   UA knows Bob's shared secret.  Once the UA is authenticated, the
   credential server sends a NOTIFY that contains Bob's credentials.
   The private key portion of the credential may have been encrypted
   with a secret that only Bob's UA (and not the credential server)
   knows.  In this case, once Bob's UA decrypts the private key it will
   be ready to go.  Typically Bob's UA would do this when it first
   registered on the network.

   Some time later Alice decides that she wishes to discover Bob's
   certificate so that she can send him an encrypted message.  Alice's
   UA sends a SUBSCRIBE message to Bob's AOR.  The proxy in Bob's domain
   routes this to the credential server via an authorization service.
   The credential server returns a NOFITY that contains Bob's public
   certificate in the body.  This is routed through an authentication
   service that signs that this message really can validly claim to be
   from the AOR "sip:bob@example.com".  Alice's UA receives the
   certificate and can use it to encrypt a message to Bob.

   The mechanism described in this document works for both self signed
   certificates and certificates signed by well known certificate
   authorities; however, it is imagined that most UAs using this would
   only use self signed certificates, and would use an Authentication
   Service as described in [2] to provide a strong binding of an AOR to
   the certificates.

4.  UA Behavior with Certificates

   When a User Agent wishes to discover some other user's certificate it
   subscribes to the "certificate" SIP event package as described in
   Section 7 to get the certificate.  While the subscription is active,
   if the certificate is updated, the Subscriber will receive the
   updated certificate in a notification.

   The Subscriber needs to decide how long it is willing to trust that
   the certificate it receives is still valid.  If the certificate is
   revoked before it expires, the Notifier will send a notification with
   an empty body to indicate that the certificate is no longer valid.
   However, the Subscriber might not receive the notification if an
   attacker blocks this traffic.  The amount of time that the Subscriber



Jennings & Peterson     Expires August 20, 2005                 [Page 6]


Internet-Draft              SIP Certificates               February 2005


   caches a certificate SHOULD be configurable.  A default of one day is
   RECOMMENDED.

   Note that the actual duration of the subscription is orthogonal to
   the caching time or validity time of the corresponding certificate.
   Allowing subscriptions to persist after a certificate is not longer
   valid ensures that Subscribers receive the replacement certificate in
   a timely fashion.  In some cases, the Notifier will not allow
   unauthenticated subscriptions to persist.  The Notifier could return
   an immediate notification with the certificate in response to
   subscribe and then immediately terminate subscription, setting the
   reason parameter to "probation".  The Subscriber will have to
   periodically poll the Notifier to verify validity of the certificate.

   If the UA uses a cached certificate in a request and receives a 493
   (Undecipherable) response, it SHOULD remove the certificate it used
   from the cache, attempt to fetch the certificate again, and retry the
   original request again.  This situation usually indicates that the
   certificate was recently updated, and that the Subscriber has not
   received a corresponding notification.

      A UA that has a presence list MAY want to subscribe to the
      certificates of all the presentities in the list when the UA
      subscribes to their presence, so that when the user wishes to
      contact a presentity, the UA will already have the appropriate
      certificate.  Future specifications might consider the possibility
      of retrieving the certificates along with the presence documents.

5.  UA Behavior with Credentials

   UAs discover their own credentials by subscribing to their AOR with
   an event type of credential as described in Section 8.  After a UA
   registers, it SHOULD retrieve its credentials.

   There are several different cases in which a UA should generate a new
   credential:
   o  If the UA receives a NOTIFY for the credential package with no
      body.
   o  If the certificate has expired.
   o  If the certificate is within ten minutes of expiring, the UA
      SHOULD attempt to create replacement credentials.  The UA does
      this by waiting a random amount of time between 0 and 600 seconds.
      If no new credentials was received in that time, the UA creates
      new credentials to replace the expiring ones, and sends them in a
      PUBLISH request (with a SIP-If-Match header set to the current
      entity-tag).  This makes credential collisions both unlikely and
      harmless.




Jennings & Peterson     Expires August 20, 2005                 [Page 7]


Internet-Draft              SIP Certificates               February 2005


   o  If the user of the device has indicated via the user interface
      that they wish to revoke the current certificate and issue a new
      one.
   Credentials are created by creating a new key pair which will require
   appropriate randomness, creating a certificate as described in
   Section 10.6, and encrypting the private key with a pass phrase
   supplied by the user.  Then the UA can change the user's credential
   by sending the server a PUBLISH[3] with an event type of credential
   that contains a multipart/mixed containing both an
   application/pkix-cert and an application/pkcs8 body.  The PUBLISH
   request MUST include a SIP-If-Match header field with the previous
   entity-tag know to the subscriber.  This prevents multiple User
   Agents for the same AOR from publishing conflicting credentials.

   If a UA wishes to revoke the existing certificate without publishing
   a new one, it MUST send a PUBLISH with an empty body to the
   credential server.

6.  Credential Service Behavior

   The Credential Service stores credentials for users and can provide
   the credentials to other user agents belonging to the same user, and
   certificates to any user agent.  The credentials are indexed by a URI
   that corresponds to the AOR of the user.  When a UA requests a public
   certificate with a SUBSCRIBE, the server sends the UA the certificate
   in a NOTIFY and sends a subsequent NOTIFY any time the certificate
   changes.  When a credential is requested, the Credential Service
   digest challenges the requesting UA to authenticate it so that the
   Credential Service can verify that the UA is authorized to receive
   the requested credentials.  When a credential is published, the
   Credential Service digest challenges the requesting UA to
   authenticate it so that the Credential Service can verify that the UA
   is authorized to change the credentials.  This behavior is defined in
   Section 7 and Section 8.

7.  Event Package Formal Definition for "certificate"

7.1  Event Package Name

   This document defines a SIP Event Package as defined in RFC 3265 [4].
   The event-package token name for this package is:

          certificate


7.2  Event Package Parameters

   This package does not define any event package parameters.



Jennings & Peterson     Expires August 20, 2005                 [Page 8]


Internet-Draft              SIP Certificates               February 2005


7.3  SUBSCRIBE Bodies

   This package does not define any SUBSCRIBE bodies.

7.4  Subscription Duration

   Subscriptions to this event package can range from no time to weeks.
   Subscriptions in days are more typical and are RECOMMENDED.  The
   default subscription duration for this event package is one day.

   The Credential Service is encouraged to keep the subscriptions active
   for AORs that are communicating frequently, but the Credential
   Service MAY terminate the subscription at any point in time.

7.5  NOTIFY Bodies

   The body of a NOTIFY request for this package MUST either be empty or
   contain an application/pkix-cert body (as defined in [10]) that
   contains the certificate, unless an Accept header has negotiated some
   other type.  The Content-Disposition MUST be set to "signal".

   A future extension MAY define other NOTIFY bodies.  If no "Accept"
   header is present in the SUBSCRIBE, the body type defined in this
   document MUST be assumed.

   Implementations which generate large notifications are reminded to
   follow the message size restrictions for unreliable transports
   articulated in Section 18.1.1 of SIP.

7.6  Subscriber Generation of SUBSCRIBE Requests

   UAs discover certificates by sending a SUBSCRIBE with an event type
   of "certificate" to the AOR for which a certificate is desired.  In
   general, the UA stays subscribed to the certificate for as long as it
   plans to use and cache the certificate, so that the UA can be
   notified about changes or revocations to the certificate.

   Subscriber User Agents will typically SUBSCRIBE to certificate
   information for a period of hours or days, and automatically attempt
   to re-SUBSCRIBE just before the subscription is completely expired.

   When a user de-registers from a device (logoff, power down of a
   mobile device, etc.), subscribers SHOULD unsubscribe by sending a
   SUBSCRIBE message with an Expires header of zero.

7.7  Notifier Processing of SUBSCRIBE Requests

   When a SIP Credential Server receives a SUBSCRIBE request with the



Jennings & Peterson     Expires August 20, 2005                 [Page 9]


Internet-Draft              SIP Certificates               February 2005


   certificate event-type, it is not necessary to authenticate the
   subscription request.  The Notifier MAY limit the duration of the
   subscription to an administrator-defined period of time.  The
   duration of the subscription does not correspond in any way to the
   period for which the certificate will be valid.

   When the Credential Service receives a SUBSCRIBE for a certificate,
   it first checks to see if it has credentials for the requested URI.
   If it does not have a certificate, it returns a NOTIFY request with
   an empty message body.

7.8  Notifier Generation of NOTIFY Requests

   Immediately after a subscription is accepted, the Notifier MUST send
   a NOTIFY with the current certificate, or an empty body if no
   certificate is available for the target user.  In either case it
   forms a NOTIFY with the From header field value set to the AOR of the
   resource being subscribed to.  This server sending the NOTIFY needs
   either to implement an Authentication Service (as described in SIP
   Identity [2]) or else the server needs to be set up such that the
   NOFIFY will be sent through an Authentication Service.  Sending the
   NOTIFY through the the Authentication Service requires the SUBSCRIBE
   to have been routed through the Authentication Service, since the
   NOTIFY is sent within the dialog formed by the SUBSCRIBE.

7.9  Subscriber Processing of NOTIFY Requests

   The resulting NOTIFY will contain an application/pkix-cert body which
   contains the requested certificate.  The UA MUST follow the
   procedures in Section 10.3 to decide if the received certificate can
   be used.  The UA needs to cache this certificate for future use.  The
   maximum length of time it should be cached for is discussed in
   Section 10.1 .  The certificate MUST be removed from the cache if the
   certificate has been revoked (if a NOTIFY with an empty body is
   received), or if it is updated by a subsequent NOTIFY.  The UA MUST
   check that the NOTIFY is correctly signed by an Authentication
   Service as described in [2].  If the identity asserted by the
   Authentication Service does not match the AOR that the UA subscribed
   to, the certificate in the NOTIFY is discarded and MUST NOT be used.

7.10  Handling of Forked Requests

   This event package does not permit forked requests.  At most one
   subscription to this event type is permitted per resource.

7.11  Rate of Notifications

   Notifiers SHOULD NOT generate NOTIFY requests more frequently than



Jennings & Peterson     Expires August 20, 2005                [Page 10]


Internet-Draft              SIP Certificates               February 2005


   once per minute.

7.12  State Agents and Lists

   Implementers MUST NOT implement state agents for this event type.
   Likewise, implementations MUST NOT use the event list extension [19]
   with this event type.  It is not possible to make such an approach
   work, because the Authentication service would have to simultaneously
   assert several different identities.

7.13  Behavior of a Proxy Server

   There are no additional requirements on a SIP Proxy, other than to
   transparently forward the SUBSCRIBE and NOTIFY methods as required in
   SIP.  This specification describes the Proxy, Authentication service,
   and Credential service as three separate services but it is certainly
   possible to build a single sip network element that performs all of
   these services at the same time.

8.  Event Package Formal Definition for "credential"

8.1  Event Package Name

   This document defines a SIP Event Package as defined in RFC 3265 [4].
   The event-package token name for this package is:

         credential


8.2  Event Package Parameters

   This package defines the "etag" Event header parameter which is valid
   only in NOTIFY requests.  It contains a token which represents the
   SIP entity-tag value at the time the notification was sent.
   Considering how infrequently credentials are updated, this hint is
   very likely to be the correct entity-tag to use in the SIP-If-Match
   header in a SIP PUBLISH request to update the current credentials.

       etag-param = "etag" EQUAL token


8.3  SUBSCRIBE Bodies

   This package does not define any SUBSCRIBE bodies.

8.4  Subscription Duration

   Subscriptions to this event package can range from hours to one week.



Jennings & Peterson     Expires August 20, 2005                [Page 11]


Internet-Draft              SIP Certificates               February 2005


   Subscriptions in days are more typical and are RECOMMENDED.  The
   default subscription duration for this event package is one day.

   The Credential Service SHOULD keep subscriptions active for UAs that
   are currently registered.

8.5  NOTIFY Bodies

   The NOTIFY MUST contain a multipart/mixed (see [14]) body that
   contains both an application/pkix-cert body with the certificate and
   an application/pkcs8 body that has the associated private key
   information for the certificate.  The Content-Disposition MUST be set
   to "signal".

   A future extension MAY define other NOTIFY bodies.  If no "Accept"
   header is present in the SUBSCRIBE, the body type defined in this
   document MUST be assumed.

   The application/pkix-cert body is a DER encoded X.509v3 certificate
   [10].  The application/pkcs8 body contains a DER-encoded PKCS#8 [1]
   object that contains the private key.  contains the private key.  The
   PKCS#8 objects MUST be of type PrivateKeyInfo.  The integrity and
   confidentiality of the PKCS#8 objects is provided by the TLS
   transport.  The transport encoding of all the MIME bodies is binary.

8.6  Subscriber Generation of SUBSCRIBE Requests

   A Subscriber User Agent will SUBSCRIBE to its credential information
   for a period of hours or days and will automatically attempt to
   re-SUBSCRIBE before the subscription has completely expired.

   The Subscriber SHOULD SUBSCRIBE to its credentials whenever a new
   user becomes associated with the device (a new login).  The
   subscriber SHOULD also renew its subscription immediately after a
   reboot, or when the subscriber's network connectivity has just been
   re-established.

   The UA needs to authenticate with the Credential Service for these
   operations.  The UA MUST use TLS to connect to the server.  The UA
   may be configured with a specific name for the Credential Service;
   otherwise normal SIP routing is used.  As described in RFC 3261, the
   TLS connection needs to present a certificate that matches the
   expected name of the server to which the connection was formed, so
   that the UA knows it is talking to the correct server.  Failing to do
   this may result in the UA publishing its private key information to
   an attacker.  The Credential Service will authenticate the UA using
   the usual SIP Digest mechanism, so the UA can expect to receive a SIP
   challenge to the SUBSCRIBE or PUBLISH messages.



Jennings & Peterson     Expires August 20, 2005                [Page 12]


Internet-Draft              SIP Certificates               February 2005


8.7  Notifier Processing of SUBSCRIBE Requests

   When a Credential Service receives a SUBSCRIBE for a credential, the
   Credential Service has to authenticate and authorize the UA and
   validate that adequate transport security is being used.  Only a UA
   that can authenticate as being able to register as the AOR is
   authorized to receive the credentials for that AOR.  The Credential
   Service MUST digest challenge the UA to authenticate the UA and then
   decide if it is authorized to receive the credentials.  If
   authentication is successful, the Notifier MAY limit the duration of
   the subscription to an administrator-defined period of time.  The
   duration of the subscription MUST not be larger than the length of
   time for which the certificate is still valid.  The Expires header
   should be set appropriately.

8.8  Notifier Generation of NOTIFY Requests

   Once the UA has authenticated with the Credential Service and the
   subscription is accepted, the Credential Service MUST immediately
   send a Notify message.  The Notifier SHOULD include the current
   entity-tag value in the "etag" Event package parameter in the NOTIFY
   request.  The Authentication Service is applied to this NOTIFY
   message in the same way as the certificate subscriptions.  If the
   credential is revoked, the Credential Service MUST terminate any
   current subscriptions and force the UA to re-authenticate by sending
   a NOTIFY with its Subscription-State header set to "terminated" and a
   reason parameter of "deactivated".  (This causes a Subscriber to
   retry the subscription immediately.)  This is so that if a secret for
   retrieving the credentials gets compromised, the rogue UA will not
   continue to receive credentials after the compromised secret has been
   changed.

   Any time the credentials for this URI change, the Credential Service
   MUST send a new NOTIFY to any active subscriptions with the new
   credentials.


8.9  Notifier Processing of PUBLISH Requests

   When the Credential Service receives a PUBLISH to update credentials,
   it MUST authenticate and authorize this request the same way as for
   subscriptions for credentials.  If this succeeds, the Credential
   Service updates the credential for this URI, processes all the active
   certificate and credential subscriptions to this URI, and generates a
   NOTIFY request with the new credential or certificate.  If the
   Subscriber submits a PUBLISH requests with no body, this revokes the
   current credentials and causes all subscriptions to the credential
   package to be deactivated as described in the previous section.



Jennings & Peterson     Expires August 20, 2005                [Page 13]


Internet-Draft              SIP Certificates               February 2005


   (Note that subscriptions to the certificate package are NOT
   terminated, each subscriber to the certificate package receives a
   notification with an empty body.)

8.10  Subscriber Processing of NOTIFY Requests

   When the UA receives a valid NOTIFY request, it should replace its
   existing credentials with the new received ones.  If the UA cannot
   decrypt the PKCS#8 object with the private key, it MUST send a 493
   Undecipherable response.  Later if the user provides a new pass
   phrase for the private key, the UA can subscribe to the credentials
   again and attempt to decrypt with the new pass phrase.

8.11  Handling of Forked Requests

   This event package does not permit forked requests.

8.12  Rate of Notifications

   Notifiers SHOULD NOT generate NOTIFY requests more frequently than
   once per minute.

8.13  State Agents and Lists

   Implementers MUST NOT implement state agents for this event type.
   Likewise, implementations MUST NOT use the event list extension [19]
   with this event type.

8.14  Behavior of a Proxy Server

   The behavior is identical to behavior described for certificate
   subscriptions described in Section 7.13.

9.  Examples

   In all these examples, large parts of the message are omitted to
   highlight what is relevant to this draft.  The lines in the examples
   that are prefixed by $ represent encrypted blocks of data.

9.1  Encrypted Page Mode IM Message

   In this example, Alice sends Bob an encrypted page mode instant
   message.  Alice does not already have Bob's public key from previous
   communications, so she fetches Bob's public key from Bob's Credential
   Service:


   SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0



Jennings & Peterson     Expires August 20, 2005                [Page 14]


Internet-Draft              SIP Certificates               February 2005


   ...
   Event: certificate

   The Credential Service responds with the certificate in a NOTIFY.


    NOTIFY alice@atlanta.example.com  SIP/2.0
    Subscription-State: active; expires=7200
    ....
    From: <sip:bob@biloxi.example.com>;tag=1234
    Identity: "12dsfsdk2389403823cbed"
    Identity-Info: sips:billoxi.example.com
    ....
    Event: certificate
    Content-Type: application/pkix-cert
    Content-Disposition: signal

    < certificate data >

   Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the
   body using Bob's public key as shown below.  Although outside the
   scope of this document, it is worth noting that instant messages
   often have common plain text like "Hi", so that setting up symmetric
   keys for extended session mode IM conversations will likely increase
   efficiency, as well as reducing the likelihood of compromising the
   asymmetric key in the certificate.


    MESSAGE sip:bob@biloxi.example.com SIP/2.0
    ...
    Content-Type: application/pkcs7-mime
    Content-Disposition: render

    $ Content-Type: text/plain
    $
    $ < encrypted version of "Hello" >


9.2  Setting and Retrieving UA Credentials

   When Alice's UA wishes to publish Alice's public and private keys to
   the Credential Service, it sends a PUBLISH message like the one
   below.  This must be sent over a TLS connection in which the other
   end of the connection presents a certificate that matches the
   Credential Service for Alice and digest challenges the message to
   authenticate her.





Jennings & Peterson     Expires August 20, 2005                [Page 15]


Internet-Draft              SIP Certificates               February 2005


    PUBLISH sips:alice@atlanta.example.com SIP/2.0
    ...
    Content-Type: multipart/mixed;boundary=boundary
    Content-Disposition: signal

    --boundary
    Content-ID: 123
    Content-Type: application/pkix-cert


    < Public certificate for Alice >
    --boundary
    Content-ID: 456
    Content-Type: application/pkcs8

    < Private Key for Alice >
    --boundary

   If one of Alice's UAs subscribes to the credential event, the UA will
   be digest challenged, and the NOTIFY will include a body similar to
   the one in the PUBLISH section above.

10.  Security Considerations

   The high level message flow from a security point of view is
   summarized in the following figure.  The 200 responses are removed
   from the figure as they do not have much to do with the overall
   security.























Jennings & Peterson     Expires August 20, 2005                [Page 16]


Internet-Draft              SIP Certificates               February 2005


   Alice     Server              Bob UA
    |           | TLS Handshake    | 1) Client authC/Z server
    |           |<---------------->|
    |           | PUBLISH          | 2) Client sends request
    |           |<-----------------|    (write credential)
    |           | Digest Challenge | 3) Server challenges client
    |           |----------------->|
    |           | PUBLISH + Digest | 4) Server authC/Z client
    |           |<-----------------|
    |           |      time...     |
    |           |                  |
    |           | TLS Handshake    | 5) Client authC/Z server
    |           |<---------------->|
    |           | SUBSCRIBE        | 6) Client sends request
    |           |<-----------------|    (read credential)
    |           | Digest Challenge | 7) Server challenges client
    |           |----------------->|
    |           | SUBSCRIBE+Digest | 8) Server authC/Z client
    |           |<-----------------|
    |           | NOTIFY           | 9) Server returns credential
    |           |----------------->|
    |           |
    | SUBSCRIBE |   10) Client requests certificate
    |---------->|
    |           |
    |NOTIFY+AUTH|   11) Server returns user's certificate and signs that
    |<----------|       it is valid using certificate for the domain
    |           |

   When the UA, labeled Bob, first created a credential for Bob, it
   would store this on the the server.  The UA authenticated the Server
   using the certificates from the TLS handshake while the Server
   authenticated the UA using a digest style challenge with a shared
   secret.

   The UA, labeled Bob, wishes to request its credentials from the
   server.  First it forms a TLS connection to the server with provides
   integrity and privacy protection and also authenticates the server to
   Bob's UA.  Next the UA requests its credentials using a SUBSCRIBE.
   The Server digest challenges this to authenticate Bob's UA.  The
   server and Bob's UA have a shared secret that is used for this.  If
   the authentication is successful, the sever sends the credentials to
   Bob's UA.  The private key in the credentials may have been encrypted
   using a shared secret that the server does not know.

   A similar process would be used for Bob's UA to publish new
   credentials to the server.  The SUBSCRIBE would be a PUBLISH and
   there would be no NOTIFY.  When this happened, all the other UAs that



Jennings & Peterson     Expires August 20, 2005                [Page 17]


Internet-Draft              SIP Certificates               February 2005


   were subscribed to Bob's credentials would receive a new NOTIFY with
   the new credentials.

   Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the
   server.  The server sends the response in NOTIFY.  This does not need
   to be sent over a privacy or integrity protected channel, as the
   Authentication service described in [2] provides integrity protection
   of this information and signs it with the certificate for the domain.

   This whole scheme is highly dependent on trusting the operators of
   the Credential Service and trusting that the Credential Service will
   not be compromised.  The security of all the users will be
   compromised if the Credential Service is compromised.

   This specification requires the TLS session to be used for SIP
   communications to the Credential Service.  As specified in RFC 3261,
   TLS clients MUST check that the SubjectAltName of the certificate for
   the server they connected to exactly matches the server they were
   trying to connect to.  Failing to use TLS or selecting a poor cipher
   suite (such as NULL encryption) will result in credentials including
   private key being sent unencrypted over the network and will render
   the whole system useless.  Implementations really must use TLS or
   there is no point in implementing any of this.

   The correct checking of chained certificates as specified in TLS [11]
   is critical for the client to authenticate the server.  If the client
   does not authenticate that it is talking to the correct Credential
   Service, a man in the middle attack is possible.

10.1  Certificate Revocation

   If a particular credential needs to be revoked, the new credential is
   simply published to the Credential Service.  Every device with a copy
   of the old credential or certificate in its cache will have a
   subscription and will rapidly (order of seconds) be notified and
   replace its cache.  Clients that are not subscribed will subscribe
   when they next need to use the certificate and will get the new
   certificate.

   It is possible that an attacker could mount a DOS attack such that
   the UA that had cached a certificate did not receive the NOTIFY with
   its revocation.  To protect against this attack, the UA needs to
   limit how long it caches certificates.  After this time, the UA would
   invalidate the cached information even though no NOTIFY had ever been
   received due to the attacker blocking it.

   The duration of this cached information is in some ways similar to a
   device deciding how often to check a CRL list.  For many



Jennings & Peterson     Expires August 20, 2005                [Page 18]


Internet-Draft              SIP Certificates               February 2005


   applications, a default time of 1 day is suggested, but for some
   applications it may be desirable to set the time to zero so that no
   certificates are cached at all and the the the credential is checked
   for validity every time the certificate is used.

10.2  Certificate Replacement

   The UAs in the system replace the certificates close to the time that
   the certificates would expire.  If a UA has used the same key pair to
   encrypt a very large volume of traffic, the UA MAY choose to replace
   the credential with a new one.

10.3  Trusting the Identity of a Certificate

   When a UA wishes to discover the certificate for
   sip:alice@example.com, the UA subscribes to the certificate for
   alice@example.com and receives a certificate in the body of a SIP
   Notify message.  The term original URI is used to describe the
   original URI that was subscribed to.

   If the certificate is signed by a trusted CA, and one of the names in
   the SubjectAltName matches the Original URI, then this certificate
   MAY be used but only for exactly the original URI and not for other
   identities found in the SubjectAltName.  Otherwise, there are several
   steps the UA MUST perform before using this certificate.
   o  The From header in the NOTIFY message MUST match the original URI
      that was subscribed to.
   o  The UA MUST check the Identity header as described in the Identity
      [2] specification to validate that bodies have not been tampered
      with and that an Authentication Service has validated this From
      header.
   o  The UA MUST check the validity time of the certificate, and stop
      using the certificate if it is invalid.  (Implementations are
      reminded to verify both the notBefore and notAfter validity
      times.)
   o  The certificate MAY have several names in the SubjectAltName but
      the UA MUST only use this certificate when it needs the
      certificate for the identity asserted by the Authentication
      Service in the NOTIFY.  This means that the certificate should
      only be indexed in the certificate cache by the AOR that the
      Authentication Service asserted and not by the value of all the
      identities found in the SubjectAltName list.
   These steps result in a chain of bindings that result in a trusted
   binding between the original AOR that was subscribed to and a public
   key.  The Original AOR is forced to match the From.  The
   Authentication Service validates that this message did come from the
   identity claimed in the From and that the bodies and the From have
   not been tampered with.  The certificate in the body contains the



Jennings & Peterson     Expires August 20, 2005                [Page 19]


Internet-Draft              SIP Certificates               February 2005


   public key for the identity.  Only the UA that can authenticate as
   this AOR, or devices with access to the private key of the domain,
   can tamper with this body.  This stops other users from being able to
   provide a false public key.  This chain of assertion from original
   URI, to From, to body, to public key is critical to the security of
   the mechanism described in this specification.  If any of the steps
   above are not followed, this chain of security will be broken and the
   system will not work.

10.4  Conformity to the SACRED Framework

   This specification uses the security design outlined in the SACRED
   Framework [7].  Specifically, it follows the cTLS architecture
   described in section 4.2.2 of RFC 3760.  The client authenticates the
   server using the server's TLS certificate.  The server authenticates
   the client using a SIP digest transaction inside the TLS session.
   The TLS sessions form a strong session key that is used to protect
   the credentials being exchanged.

10.5  Crypto Profiles

   Credential Services SHOULD implement the server name indication
   extensions in RFC 3546 [8] and they MUST support a TLS profile of
   TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [9] and a
   profile of TLS_RSA_WITH_3DES_EDE_SHA.

   The PKCS#8 in the clients MUST implement PBES2 with a key derivation
   algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm
   of DES-EDE2-CBC-Pad as defined in RFC 2898 [12].  It is RECOMMENDED
   that this profile be used when using PKCS#8.

10.6  User Certificate Generation

   The certificates should be consistent with RFC 3280 [13].  A
   signatureAlgorithm of sha1WithRSAEncryption MUST be implemented.  The
   Issuers SHOULD be the same as the subject.  Given the ease of issuing
   new certificates with this system, the Validity can be relatively
   short.  A Validity of one year or less is RECOMMENDED.  The
   subjectAltName must have a URI type that is set to the SIP URL
   corresponding to the user AOR.  It MAY be desirable to put some
   randomness into the length of time for which the certificates are
   valid so that it does not become necessary to renew all the
   certificates in the system at the same time.

10.7  Compromised Authentication Service

   One of this worst attacks against this system is if the
   Authentication Service were compromised.  This attack is somewhat



Jennings & Peterson     Expires August 20, 2005                [Page 20]


Internet-Draft              SIP Certificates               February 2005


   analogous to a CA being compromised in traditional PKI systems.  The
   attacker could make a fake certificate for which it knows the private
   key, use it to receive any traffic for a given use, and then
   re-encrypt that traffic with the correct key and forward the
   communication to the intended receiver.  The attacker would thus
   become a man in the middle in the communications.

   There is not too much that can be done to protect against this.  A UA
   MAY subscribe to its own certificate under some other identity to try
   to detect whether the Credential server is handing out the correct
   certificates.  It will be difficult to do this in a way that does not
   allow the Credential server to recognize the user's UA.

   The UA MAY also save the fingerprints of the cached certificates and
   warn users when the certificates change resulting in a system that
   was secure other than an leap of faith when the certificate first
   arrives or is changed.

   The UA MAY also allow the user to see the fingerprints for the cached
   certificates so that they can be verified by some other out of band
   means.

11.  IANA Considerations

   This specification defines two new event packages that IANA is
   requested to add the registry at
   http://www.iana.org/assignments/sip-events It also defines a new mime
   type that IANA is requested to add to the registry at
   http://www.iana.org/assignments/media-types/application.

11.1  Certificate Event Package


   To: ietf-sip-events@iana.org
   Subject: Registration of new SIP event package

   Package Name: certificate

   Is this registration for a Template Package: No

   Published Specification(s): This document

   New Event header parameters: This package defines no
                                new parameters

   Person & email address to contact for further information:
     Cullen Jennings <fluffy@cisco.com>




Jennings & Peterson     Expires August 20, 2005                [Page 21]


Internet-Draft              SIP Certificates               February 2005


11.2  Credential Event Package


   To: ietf-sip-events@iana.org
   Subject: Registration of new SIP event package

   Package Name: credential

   Is this registration for a Template Package: No

   Published Specification(s): This document

   New Event header parameters: "etag"

   Person & email address to contact for further information:
     Cullen Jennings <fluffy@cisco.com>


11.3  PKCS#8


   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/pkcs8

   MIME media type name: application

   MIME subtype name: pkcs8

   Required parameters: None

   Optional parameters: None

   Encoding considerations: The PKCS#8 object inside this MIME type
                            MUST be DER-encoded.

                            This MIME type was designed for use with
                            protocols which can carry binary-encoded
                            data. Protocols which do not carry binary
                            data (which have line length or
                            character-set restrictions for example)
                            MUST use a reversible transfer encoding
                            (such as base64) to carry this MIME type.
                            Protocols which carry binary data SHOULD
                            use a transfer encoding of "binary".

   Security considerations: Carries a cryptographic private key

   Interoperability considerations: None



Jennings & Peterson     Expires August 20, 2005                [Page 22]


Internet-Draft              SIP Certificates               February 2005


   Published specification: See reference to PKCS#8 [1]

   Applications which use this media type: Any MIME-compliant transport

   Additional information:
     Magic number(s): None
     File extension(s): .p8
     Macintosh File Type Code(s): none

   Person & email address to contact for further information:
     Cullen Jennings <fluffy@cisco.com>

   Intended usage: COMMON

   Author/Change controller:
     the IESG


12.  Acknowledgments

   Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant
   help and discussion.  Many others provided useful comments, including
   Kumiko Ono, Peter Gutmann, Russ Housley, Magnus Nystrom, Paul
   Hoffman, Dan Wing, Mike Hammer, Lyndsay Campbell, and Jason Fischl.
   Rohan Mahy and Jonathan Rosenberg provided detailed review and text.

13.  References

13.1  Normative References

   [1]   RSA Laboratories, "Private-Key Information Syntax Standard,
         Version 1.2", PKCS 8, November 1993.

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

   [3]   Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [4]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [6]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:



Jennings & Peterson     Expires August 20, 2005                [Page 23]


Internet-Draft              SIP Certificates               February 2005


         Session Initiation Protocol", RFC 3261, June 2002.

   [7]   Gustafson, D., Just, M. and M. Nystrom, "Securely Available
         Credentials (SACRED) - Credential Server Framework", RFC 3760,
         April 2004.

   [8]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
         3546, June 2003.

   [9]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Security (TLS)", RFC 3268, June 2002.

   [10]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
         Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
         May 1999.

   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [12]  Kaliski, B., "PKCS #5: Password-Based Cryptography
         Specification Version 2.0", RFC 2898, September 2000.

   [13]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [14]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

   [15]  International Telecommunications Union, "Information technology
         - Open Systems Interconnection - The Directory: Public-key and
         attribute certificate frameworks", ITU-T Recommendation X.509,
         ISO Standard 9594-8, March 2000.

13.2  Informational References

   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851, July
         2004.

   [17]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
         Requirement for the Session Initiation Protocol (SIP)", RFC
         3853, July 2004.

   [18]  Gutmann, P., "Internet X.509 Public Key Infrastructure
         Operational Protocols: Certificate Store Access via HTTP",



Jennings & Peterson     Expires August 20, 2005                [Page 24]


Internet-Draft              SIP Certificates               February 2005


         draft-ietf-pkix-certstore-http-08 (work in progress), August
         2004.

   [19]  Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
         Protocol (SIP) Event Notification Extension for Resource
         Lists", draft-ietf-simple-event-list-07 (work in progress),
         January 2005.


Authors' Addresses

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/2
   San Jose, CA  95134
   USA

   Phone: +1 408 921-9990
   EMail: fluffy@cisco.com


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520
   US

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/



















Jennings & Peterson     Expires August 20, 2005                [Page 25]


Internet-Draft              SIP Certificates               February 2005


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 (2005).  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.




Jennings & Peterson     Expires August 20, 2005                [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/