[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-wing-sip-identity-media) 00

Network Working Group                                            D. Wing
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                              H. Kaplan
Expires:  September 6, 2012                                  Acme Packet
                                                           March 5, 2012


                     SIP Identity using Media Path
                  draft-wing-rtcweb-identity-media-00

Abstract

   This document defines a new SIP identity mechanism which creates a
   signature over a certain subset of SIP headers and certain subset of
   SDP lines.  This this mechanism works with trickling ICE candidates
   and works across zero or more Session Border Controllers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 6, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Wing & Kaplan           Expires September 6, 2012               [Page 1]


Internet-Draft        SIP Identity using Media Path           March 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Identity Media Signature . . . . . . . . . . . . . . . . .  6
     3.2.  Authentication Service . . . . . . . . . . . . . . . . . .  7
     3.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Proof of Identity Techniques . . . . . . . . . . . . . . . . .  7
     4.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  DTLS-SRTP  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     6.1.  Device Disclosure  . . . . . . . . . . . . . . . . . . . .  9
     6.2.  Modification of SDP  . . . . . . . . . . . . . . . . . . . 10
   7.  Operational Differences from RFC4474 . . . . . . . . . . . . . 10
   8.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




























Wing & Kaplan           Expires September 6, 2012               [Page 2]


Internet-Draft        SIP Identity using Media Path           March 2012


1.  Introduction

   SIP Identity [RFC4474] provides cryptographic identity for SIP
   requests.  It provides this protection by signing certain SIP header
   fields (Contact, Date, Call-ID, CSeq, To, and From) and the SIP
   message body.  This mechanism suffers from two problems.  First, it
   is inefficient when ICE candidates are trickled (as each update to
   the ICE candidate list would have to be signed and validated).
   Second, it breaks entirely if IP addresses are modified during SIP
   routing, such as by a Session Border Controller.

   To avoid these problems, a new mechanism is described in this
   document which provides cryptographic assurance of the endpoint's
   identity that works with ICE candidate trickling and works through
   most B2BUAs and through most SBCs.

   The mechanism described in this document signs only certain SDP
   attributes (rather than all SDP attributes) and certain SIP headers.
   The remote endpoint is expected to validate the signature and
   initiate a cryptographic handshake over the media path, which proves
   the session has been established with the "From:" party in the SIP
   header.  A mechanism to perform the handshake over the media path is
   shown using DTLS-SRTP and TLS.  This mechanism is extensible so that
   techniques other than DTLS-SRTP or TLS can be used.

   Readers of this document are expected to be familiar with
   "Enhancements for Authenticated Identity Management in the Session
   Initiation Protocol (SIP)" [RFC4474], which defines the Identity and
   Identity-Info header fields that are also used by this document.


2.  Notational 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 [RFC2119].


3.  Operation

   This document can utilize an authentication proxy, a concept
   originally introduced in [RFC4474].  The basic steps are:

   o  A new header, Identity-Media, is created containing the names of
      certain SDP attributes from SDP bodyparts, and containing a hash
      of non-SDP bodyparts.





Wing & Kaplan           Expires September 6, 2012               [Page 3]


Internet-Draft        SIP Identity using Media Path           March 2012


   o  Several SIP headers and the Identity-Media header are all signed
      (as detailed in Section 3.1), and the result is placed in
      Identity-Media-Signature.

   o  The receiving domain validates the signature, and if the request
      is an invitation to establish a media channel, performs a proof of
      identity validation using DTLS.

   The following figure shows how the Authentication Service and the
   media validation is performed.  The figure assumes the endpoints
   themselves perform the media validation.

                                 :  Service   :
                Enterprise-A     : Provider-1 :    Enterprise-B
                                 :            :
                          Auth.  :  B2BUA or  :  Auth.
             Endpoint-A  Service :    SBC     : Service  Endpoint-B
                 |          |    :     |      :   |         |
          1.     |--INVITE->|    :     |      :   |         |
          2.     |        sign   :     |      :   |         |
          3.     |          |-INVITE-->|-INVITE-->|         |
          4.     |          |    :     |      : validate    |
          5.     |          |    :     |      :   |-------->|
          6.     |<============= DTLS =====================>|
          7.     |          |    :     |      :   |     validated
          8.     |          |    :     |      :   |     ring phone
                 |          |    :     |      :   |         |
                                 :            :

                          Figure 1: Message Flow

   Step 1:  Originating endpoint prepares to send an INVITE and chooses
            the identity-challenge technique it supports, and indicates
            that in the SDP it generates.  Described in this document
            are identity challenges for DTLS.  It then sends the INVITE
            to its local SIP proxy.

   Step 2:  Originating endpoint's authentication service creates a new
            header, Identity-Media, containing certain attribute names
            from the SDP (e.g., "a=fingerprint", "a=ice-pub-key").  The
            authentication service then creates a signature over certain
            SIP headers (e.g., From, To) and this new Identity-Media
            header.  The resulting signature is inserted into the new
            Identity-Media-Signature header.  An Identity-Info header is
            added, pointing to this domain's certificate.  The INVITE,
            with these additional headers, is forwarded to the next
            administrative domain.
            [NOTE:  alternatively, we could allow the UAC to create the



Wing & Kaplan           Expires September 6, 2012               [Page 4]


Internet-Draft        SIP Identity using Media Path           March 2012


            Identity-Media header with the attributes it wants signed,
            then have the authentication server sign them and insert the
            signature header - this would be more flexible]

   Step 3:  The next administrative domain has an SBC (or B2BUA).  The
            SBC modifies or rewrites certain SDP fields.  Most typically
            an SBC will modify the "m" and "c" lines.  These
            modifications do not break the signature, so long as the SBC
            doesn't remove the headers Identity-Media, Identity-Media-
            Signature, or Identity-Info, and do not remove or alter the
            signed attributes from the SDP.

   Step 4:  The terminating endpoint's authentication service receives
            the INVITE.  It validates that the signature contained in
            the Identity-Media-Signature header, and validates that the
            signing certificate is owned by the originating domain from
            step 2.  This validation is done by using the certificate
            pointed to in the Identity-Info header, which MUST match the
            domain in the From:  address.

   Step 5:  If the validation was successful, the terminating endpoint's
            authentication service forwards the INVITE to the endpoint.

   Step 6:  The terminating endpoint chooses a compatible identity-
            challenge technique from the INVITE (TLS or DTLS-SRTP) and
            performs that challenge.  Described in this document are
            identity challenges for TLS and DTLS-SRTP.

   Step 7:  The TLS and DTLS-SRTP identity challenges cause the exchange
            of a certificate on the media path.  The terminating
            endpoint compares the certificate or public key with the
            fingerprint in the (signed) Identity-Media header
            (originally created in step 2).  If they match, the
            terminating endpoint completes the identity challenge
            exchange.  After completion, the originating endpoint has
            proven (to the terminating endpoint) that the originating
            endpoint knows the private key associated with the
            certificate (or public key) signed in step 2.  The
            terminating endpoint has now validated the identity of the
            originating endpoint.

   Step 8:  The terminating endpoint can reliably and honestly indicate
            calling party information ("caller-id") and ring the phone.








Wing & Kaplan           Expires September 6, 2012               [Page 5]


Internet-Draft        SIP Identity using Media Path           March 2012


3.1.  Identity Media Signature

   In RFC4474, a signature is formed over some SIP headers and over the
   entire body (which most typically contains SDP).  In this
   specification, some SIP headers are signed but only specific SDP
   attributes that provide cryptographic identity are signed (e.g.,
   "a=fingerprint" and its value).  The specific SDP attributes that are
   signed depends on which cryptographic identity technique(s) is used;
   see section Section 4.

   The SIP headers that are signed, for the signature placed into the
   Identity-Media-Signature header are:

   o  The AoR of the UA sending the message, or addr-spec of the From
      header field (referred to occasionally here as the 'identity
      field').

   o  The addr-spec component of the To header field, which is the AoR
      to which the request is being sent.

   o  The SIP method.

   o  [NOTE:  Contact, CSeq and Call-Id not included]

   o  The Date header field, with exactly one space each for each SP and
      the weekday and month items case set as shown in the BNF in
      RFC3261.  RFC3261 specifies that the BNF for weekday and month is
      a choice amongst a set of tokens.  The RFC2234 rules for the BNF
      specify that tokens are case sensitive.  However, when used to
      construct the canonical string defined here, the first letter of
      each week and month MUST be capitalized, and the remaining two
      letters must be lowercase.  This matches the capitalization
      provided in the definition of each token.  All requests that use
      the Identity-Media mechanism MUST contain a Date header.

   o  The Identity-Media header field value.

   The hash is formed of these elements:

      digest-string = addr-spec "|" addr-spec "|"
                      Method "|" SIP-date "|"
                      attrib-bodyhash-list

   The first addr-spec MUST be taken from the From header field value,
   the second addr-spec MUST be taken from the To header field value.

   The Identity-Info header points to where the authentication service's
   certificate can be retrieved from.



Wing & Kaplan           Expires September 6, 2012               [Page 6]


Internet-Draft        SIP Identity using Media Path           March 2012


3.2.  Authentication Service

   The authentication service examines the SIP message body to build the
   Identity-Media header.  For each message body found, in the order
   found:

   o  if the body part is application/sdp, the authentication service
      retrieves only the cryptographic attributes from the SDP (as
      described in Section 4), and appends that information to the
      Identity-Media header.

   o  otherwise, for all other body parts, the body part is hashed using
      SHA-1, and the first 96 bytes are appended to the Identity-Media
      header using "BPH=".

   For example, A SIP request with three bodyparts:  text/plain,
   application/sdp, and image/jpg, the Identity-Media attribute would
   contain a bodypart hash of the text/plain part, certain SDP attribute
   lines from the application/sdp bodypart (a=fingerprint in this
   example), and a bodypart hash of the image/jpg bodypart:

     Identity-Media: BPH="e32je3j23cjek3dz","a=fingerprint",
       BPH="8fj289r3i892381c"

   This Identity-Media header, along with the headers and portions of
   headers described in Section 3.1 are all signed by the authentication
   service.  The resulting signature is placed on the new Identity-
   Media-Signature header.

3.3.  Validation

   The validation service can be performed by the remote endpoint itself
   or by a device acting on behalf of the endpoint.  The validation
   service first checks the signature in the Identity-Media-Signature
   field.  If this is valid, the endpoint (or its validation service
   operating on its behalf) then initiates a TLS or DTLS-SRTP identity
   proof (Section 4).  This causes the originating endpoint to prove
   possession of its private key that corresponds to the certificate
   that was signed by the remote domain's authentication service.


4.  Proof of Identity Techniques

   Two technique is described below -- TLS and DTLS-SRTP.  Previous
   versions of this document had described other techniques (ICE, HIP,
   and ZRTP).  Both TLS and DTLS-SRTP cryptographically prove the
   identity signed by the authentication service in SIP is the same as
   the identity on the media path.



Wing & Kaplan           Expires September 6, 2012               [Page 7]


Internet-Draft        SIP Identity using Media Path           March 2012


   The authentication service creates a new Identity-Media header and
   places into that header those SDP attribute names associated with
   that technique.  The authentication service then creates a signature
   over specific SIP headers (see Section 3.1), and places that
   signature into the new Identity-Media-Signature header.  The SIP
   request is then sent outside of the originating domain.

   The receiving domain validates the Identity-Media-Signature.  If
   successful, the SIP request is forwarded to the end system.  The end
   system initiates a DTLS session and validates that the (signed)
   certificate fingerprint presented in the SIP signaling matches the
   certificate presented in the DTLS exchange.  If they match, and the
   DTLS exchange completes successfully, the local endpoint has
   validated the identity of the remote endpoint.

   Note:  Due to SIP forking, the calling party may receive many
   identity challenges, each incurring a public key operation to prove
   identity.  Mechanisms to deal with this are for future study.

4.1.  TLS

   TLS uses the "fingerprint" attribute to provide a hash of the
   certificate in the SDP.  The fingerprint attribute is defined by
   [RFC4572] for TLS.  This a=fingerprint line is included in the
   Identity-Media SDP attribute.

4.2.  DTLS-SRTP

   DTLS uses the same "fingerprint" attribute originally described for
   TLS, and handled identically to TLS.





















Wing & Kaplan           Expires September 6, 2012               [Page 8]


Internet-Draft        SIP Identity using Media Path           March 2012


5.  ABNF

   The following figure shows the syntax of the new SIP header fields
   using ABNF [RFC5234]

      identity-media        = "Identity-Media" HCOLON
                              attrib-bodyhash-list
      attrib-bodyhash-list  = attrib-bodyhash *(COMMA attrib-bodyhash)
      attrib-bodyhash       = quoted-attrib | quoted-bodyparthash
      quoted-attribute      = DQUOTE attribute DQUOTE  ; SDP "a=" line
      quoted-bodyhash       = "BPH" EQUAL DQUOTE bodyparthash DQUOTE
      bodyparthash          = 32HEXDIG

      identity-media-sig    = "Identity-Media-Signature" HCOLON
                              signature
      signature             = DQUOT 32HEXDIG DQUOT

      Identity-Info = "Identity-Info" HCOLON ident-info
                       *( SEMI ident-info-params )
      ident-info = LAQUOT absoluteURI RAQUOT
      ident-info-params = ident-info-alg / ident-info-extension
      ident-info-alg = "alg" EQUAL token
      ident-info-extension = generic-param

                    Figure 2: ABNF for new SIP headers


6.  Security Considerations

   [[some of RFC4474's security considerations also apply.]]

6.1.  Device Disclosure

   Although the mechanism described in this paper allows SBCs to be used
   with a cryptographic identity scheme, it does expose the identity of
   the user's certificate -- which is exposed by DTLS-SRTP itself.  If a
   unique certificate is installed on each user's device, the remote
   party will be able to discern which device is terminating the call.
   This problem is more pronounced when SIP retargeting occurs in
   conjunction with Connected Identity [RFC4916].

   If this isn't desired, there are two solutions:

   o  All devices under the control of the user will need to have the
      same certificate (and associated private key) installed on them.

   o  The device needs to manufacture a new self-signed certificate (or
      public key) for each call, and populate the appropriate SDP



Wing & Kaplan           Expires September 6, 2012               [Page 9]


Internet-Draft        SIP Identity using Media Path           March 2012


      attributes with that certificate (or public key).  This is
      possible because the identity service described in this paper does
      not require the same certificate or public key to be used on every
      call.

6.2.  Modification of SDP

   One issue with only signing specific SDP attributes is that a man in
   the middle can modify the un-signed SDP for nefarious purposes,
   beyond simply changing m=/c= lines.  In particular, an attacker could
   set the c= connection line used for DTLS-SRTP fingerprint to 0.0.0.0
   and the m= media line to port 0, essentially disabling that offered
   media session.  The attacker could also add a set of c=/m= lines for
   non-SRTP media, and thus make a non-SRTP offer with a perfectly valid
   identity signature.  Or an attacker could insert SDP capability
   negotiation attributes to create a best-effort type SRTP offer, with
   SRTP (rather than RTP) being the lowest preference.

   This draft prevents such downgrade attacks by requiring the called UA
   use DTLS-SRTP, HIP, ICE, or TLS on the media path to establish
   identity.  Thus, an attacker performing the attacks described above
   will not successfully fool the called UA because the (intended)
   victim will use DTLS-SRTP (or HIP, ICE, or TLS) on the media path,
   and the attacker does not possess the private key of the legitimate
   caller.


7.  Operational Differences from RFC4474

   RFC4474 imposes one public key operation for the authentication
   service and one for validation.  If Connected Identity [RFC4916] is
   used, only one additional public key operation is necessary for the
   header signature validation; the expense of the DTLS, TLS, or ICE
   public key operation has already been incurred by both parties and is
   not repeated.

   RFC4474 includes the Contact URI in the signed headers.  That is not
   required by this mechanism because it adds no security property, and
   will fail validation when crossing SBCs and B2BUA's.  It is of
   dubious security value because Via/Record-Route can be inserted for
   response interception regardless, and some requests don't contain a
   Contact anyway (e.g., MESSAGE).  It does not provide any replay/
   copy-paste protection either, for the same reasons.

   RFC4474 includes the CSeq in the signed headers.  That is not
   required by this mechanism because it adds little security, and will
   fail validation when crossing SBCs and B2BUA's in some cases.  It is
   of little security value because it provides no protection from cut-



Wing & Kaplan           Expires September 6, 2012              [Page 10]


Internet-Draft        SIP Identity using Media Path           March 2012


   paste attack for different targets, and although it would prevent
   replay attack within the same session, since the media key-related
   SDP portions are signed anyway, replaying the request will not do
   anything useful.

   RFC4474 includes the Call-Id in the signed headers.  That is not
   required by this mechanism because it adds little security, and will
   fail validation when crossing SBCs and B2BUA's in some cases.  It is
   of little security value because it provides no protection from cut-
   paste attack for different targets, and although it would prevent
   replay attack for the same target, since the media key-related SDP
   portions are signed anyway, replaying the request will not do
   anything useful.

   The mechanism described in this document has the following advantages
   over RFC4474:

   o  Only the edge network needs to create signatures on SIP requests
      -- not every intervening SBC,

   o  The original cryptographically-provable identity is preserved
      across any number of SBCs, B2BUA's, etc.

   o  SBCs, B2BUA's, and other "middle-boxes" in intermediate domains do
      not need to be upgraded or changed in order for the originating
      and terminating domains to use this new mechanism.


8.  Limitations

   For the identity procedure described in this document to function,
   every device -- including Session Border Controllers -- on the path
   MUST permit DTLS-SRTP on the media path.  Further, those devices MUST
   NOT interfere with the signed SDP attributes or the new SIP headers
   necessary for Identity Media to operate.

   For the technique described in this document to function, all on-path
   SIP elements -- SBCs, B2BUAs, and SIP proxies -- MUST NOT interfere
   with the signed headers.  The identity mechanism described in this
   document is not harmed if on-path SIP elements alter the SDP (e.g.,
   by deleting non-signed attributes, connection addresses, etc.).


9.  Examples







Wing & Kaplan           Expires September 6, 2012              [Page 11]


Internet-Draft        SIP Identity using Media Path           March 2012


9.1.  DTLS

   This example shows how two a=fingerprint lines in SDP would populate
   the Identity-Media SIP header field.  The following is an example of
   an INVITE created by the endpoint.

   (lines folded for readability)

      INVITE sip:bob@biloxi.example.org SIP/2.0
      Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
      To: Bob <sip:bob@biloxi.example.org>
      From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 314159 INVITE
      Max-Forwards: 70
      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Contact: <sip:alice@pc33.atlanta.example.com>
      Content-Type: application/sdp
      Content-Length: 147

      v=0
      o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1
      s=example2
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 54113 RTP/SAVP 0
      a=fingerprint:SHA-1
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
      m=video 54115 RTP/SAVP 0
      a=fingerprint:SHA-1
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

                        Figure 3: Example with DTLS

   The SIP proxy performing the Media Identity authentication service
   would then insert the following three SIP headers into the message.
   The Identity-Media header contains all of the SDP attribute lines
   that are signed and the Identity-Media header contains the signature
   of all of the relevant SIP headers and of the Identity-Media header.
   Lines are folded for readability:

     Identity-Info: <https://atlanta.example.com/atlanta.cer>
        ;alg=rsa-sha1
     Identity-Media: "a=fingerprint","a=fingerprint"
     Identity-Media-Signature:
      "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
       ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
       FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="



Wing & Kaplan           Expires September 6, 2012              [Page 12]


Internet-Draft        SIP Identity using Media Path           March 2012


         Figure 4: SIP Headers Inserted by Authentication Service


10.  Acknowledgements

   The mechanism described in this paper is derived from Jon Peterson
   and Cullen Jennings' [RFC4474], which was formerly a document of the
   SIP working group.

   Thanks to Hans Persson for his suggestions which improved this
   document.


11.  IANA Considerations

   [[This section will be completed in a later version of this
   document.]]


12.  Normative References

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

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, June 2007.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.














Wing & Kaplan           Expires September 6, 2012              [Page 13]


Internet-Draft        SIP Identity using Media Path           March 2012


Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com


   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Phone:
   Fax:
   Email:  hkaplan@acmepacket.com
   URI:






























Wing & Kaplan           Expires September 6, 2012              [Page 14]


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