[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 draft-wing-rtcweb-identity-media

Network Working Group                                            D. Wing
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                           July 1, 2007
Expires:  January 2, 2008


                     SIP Identity using Media Path
                    draft-wing-sip-identity-media-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 January 2, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The existing SIP identity mechanism (RFC4474) creates a signature
   over the SIP body, including the entire SDP.  As part of their normal
   operation, Session Border Controllers (SBCs) and SIP Back-to-Back
   User Agents (B2BUAs) modify various fields in the SDP, breaking the
   signature.

   This document defines a new mechanism to securely identify the
   originator of a SIP message while also allowing modification of the



Wing                     Expires January 2, 2008                [Page 1]


Internet-Draft        SIP Identity using Media Path            July 2007


   SDP by SBCs and B2BUAs.  This new mechanism creates a signature over
   certain SIP headers and certain SDP lines.  Proof of identity over
   the media path using DTLS, TLS, HIP, and an extension to ICE are
   described.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Media Fingerprint Signature  . . . . . . . . . . . . . . .  7
     4.2.  Authentication Service . . . . . . . . . . . . . . . . . .  9
     4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Proof of Identity Techniques . . . . . . . . . . . . . . . . .  9
     5.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  ICE  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.1.  ICE Public Key SDP Attribute . . . . . . . . . . . . . 11
       5.3.2.  New STUN attributes  . . . . . . . . . . . . . . . . . 11
     5.4.  HIP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     7.1.  Device Disclosure  . . . . . . . . . . . . . . . . . . . . 12
   8.  Operational Differences from RFC4474 . . . . . . . . . . . . . 13
   9.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.2. ICE  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   13. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18
















Wing                     Expires January 2, 2008                [Page 2]


Internet-Draft        SIP Identity using Media Path            July 2007


1.  Introduction

   SIP Identity [RFC4474] defines a mechanism to provide 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 body of the message.  RFC4474 also signs the SIP body,
   which typically contains the SDP, with this explanation:

      This mechanism also provides a signature over the bodies of SIP
      requests.  The most important reason for doing so is to protect
      Session Description Protocol (SDP) bodies carried in SIP requests.
      There is little purpose in establishing the identity of the user
      that originated a SIP request if this assurance is not coupled
      with a comparable assurance over the media descriptors.

   A weakness of RFC4474's approach is that SBCs and B2BUAs typically
   modify the media transport address and thus destroy the RFC4474
   signature.  Furthermore, even if such modification were not typical,
   the transport address by itself does not ensure media communication
   with the expected endpoint when NATs, Session Border Controllers, and
   media relays (e.g., TURN [I-D.ietf-behave-turn]) are considered as
   part of the end-to-end architecture.  This is because the transport
   address could be reused by a malicious party within the replay
   window.

   The mechanism described in this document provides cryptographic
   assurance of the endpoint's identity by signing certain SIP headers,
   much like RFC4474.  However, unlike RFC4474 which signs the entire
   SDP, the mechanism described in this document signs only certain SDP
   attributes.  The remote endpoint is expected to validate the
   signature over the SIP headers and to initiate a proof of possession
   test over the media path, which proves the session has been
   established with the "From:" party in the SIP header.  Mechanisms to
   perform this proof of possession are shown using DTLS and using a
   small extension ICE.

   Readers of this document are expected to be familiar with RFC4474,
   "Enhancements for Authenticated Identity Management in the Session
   Initiation Protocol (SIP)", which defines the Identity and Identity-
   Info header fields.  A future version of this document will have less
   reliance on RFC4474.


2.  Terminology

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



Wing                     Expires January 2, 2008                [Page 3]


Internet-Draft        SIP Identity using Media Path            July 2007


3.  Background

   SIP signaling has been evolving from direct UA-to-UA signaling to
   always signaling through proxies.  This has been driven primarily by
   technical reasons, such as NATs or firewalls that prevent direct UA-
   to-UA signaling.  While quite controversial in the IETF, Session
   Border Controllers are an aspect of SIP's evolution, and are driven
   by both technical reasons and market reasons.  The primary technical
   driver for SBCs is to police media traffic into a network so that
   only media that was appropriately signaled via SIP is permitted into
   the network, ensuring IP packets are sent only to/from the SBC which
   eases ACL configuration (among other things).  The primary market
   driver for SBCs is to hide business relationships -- this is, removal
   of Via headers and exposing only the IP address of the SBC to
   customers.

   The following diagram shows two service providers (SP1 and SP2), and
   each has an SBC at the edge of their respective networks.  Each of
   these SBCs would need to rewrite the IP addresses in the SDP.

           +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+
           |                                                     |
     [Enterprise-A]                                      [Enterprise-B]

     Figure 1: Two Service Providers with SBCs Between Two Enterprises

   Enterprise-A can populate the "From:" address in its SIP requests
   using E.164 telephone number URLs (e.g.,
   'sip:+17005551008@example.com;user=phone') or using a mailto URL
   (e.g., 'sip:john.doe@example.com').  The characteristics of each
   choice, as the message traverses the SBCs operated by another
   administrative domain (service providers) are described below:

   E.164 telephone numbers:
      SP1 would validate the RFC4474 signature and modify the SDP.  This
      breaks the RFC4474 signature created by the enterprise.  So that a
      new RFC4474 signature can be created using its own public/private
      key pair, SP1 needs to modify the From:  field.  SP1 would
      substitute its own domain on the right-hand side, and signs the
      message with its own private key.  SP2 would receive the SIP
      request from SP1, validate the signature, and perform a similar
      SDP modification, substitution, and resigning operation.
      Enterprise-B would receive the SIP request from SP2, validate its
      signature, and process the SIP request.







Wing                     Expires January 2, 2008                [Page 4]


Internet-Draft        SIP Identity using Media Path            July 2007


   mailto URLs:
      SP1 would validate the RFC4474 signature modify the SDP.  This
      breaks the RFC4474 signature created by the enterprise.  So that a
      new RFC4474 signature can be created using its own public/private
      key pair, SP1 needs to modify the From:  field.  Unlike with E.164
      numbers which are globally unique, the SP1 isn't able to
      substitute its domain name for the enterprise's domain name due to
      name collisions (that is, dwing@cisco.com cannot simply be
      rewritten as dwing@pacbell.net).  One unappealing technique is to
      resurrect the percent hack from email:  SP1 would rewrite the
      address to be 'sip:john.doe%example.com@sp1.net', sign it, and
      send it to SP2.  SP2 would validate the signature, modify the SDP,
      and rewrite the address to be 'sip:john.doe%example.com@sp2.net',
      sign it, and send it to Enterprise-B.  Enterprise-B would receive
      the SIP request from SP2, validate its signature, and process the
      SIP request.

   Both of these approaches share several weaknesses:

   1.  They create a natural incentive for the service providers to use
       transitive trust between themselves, rather than RFC4474, due to
       the computational expense of the per-call public key operations
       on each SIP request.  For similar reasons, there is a natural
       incentive for the service providers to not even validate an
       enterprise's RFC4474 signature but rather to rely on a contract
       or rely on TLS to ensure the SIP signaling originated from the
       enterprise.

   2.  Because the original signature is destroyed by the first SBC, no
       other network (SP2 nor Enterprise-B) can validate the original
       signature.  This means all downstream entities (in the example
       above, SP2 and Enterprise-B) are relying wholly on SP1 to
       validate the signature.  This creates transitive trust which is
       undesirable - a single bad actor or compromised system anywhere
       along the path can compromise the entire identity system.

   3.  If an enterprise is connected to different service providers, one
       call from the same identity at Enterprise-A might appear to be
       from +14085551212@sp2.net and the next call from the same
       identity, routed through a different service provider, would
       appear to come from +14085551212@sp3.net.  The terminating system
       would need to treat both From:  addresses as identical for
       purposes of call routing, whitelists, reputation systems, and so
       on.  This adds further complexity to system administration.

   Thus, we need a mechanism that allows Enterprise-B to
   cryptographically validate the identity of the remote party at
   Enterprise-A, even though intermediate SBCs have rewritten the media



Wing                     Expires January 2, 2008                [Page 5]


Internet-Draft        SIP Identity using Media Path            July 2007


   transport address and forced the media to pass through their
   networks.


4.  Operation

   The operation is very similar to RFC4474 and uses authentication
   service proxies exactly like RFC4474.  Rather than reproducing the
   text of RFC4474, this section describes only the differences from
   RFC4474.  The differences are:

   o  A new header is created containing certain SDP attributes

   o  This new header is signed in addition to the same set of SIP
      headers signed by RFC4474 (detailed in )

   o  Unlike RFC4474, the body of the SIP message (containing the SDP)
      is not signed

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

                                 :  Service   :
                Enterprise-A     : Provider(s):    Enterprise-B
                                 :            :
                          Auth.  :  B2BUA or  :  Auth.
             Endpoint-A  Service :    SBC     : Service  Endpoint-B
                 |          |    :     |      :   |         |
          1.     |--Invite->|    :     |      :   |         |
          2.     |        sign   :     |      :   |         |
          3.     |          |-Invite-->|-Invite-->|         |
          4.     |          |    :     |      : validate    |
          5.     |          |    :     |      :   |-------->|
          6.     |<=========tls, dtls, ice, or hip=========>|
          7.     |          |    :     |      :   |     validated
          8.     |          |    :     |      :   |     ring phone
                 |          |    :     |      :   |         |
                                 :            :

                          Figure 2: 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 TLS, DTLS, ICE, and HIP.  It
            then sends the Invite to its local SIP proxy.




Wing                     Expires January 2, 2008                [Page 6]


Internet-Draft        SIP Identity using Media Path            July 2007


   Step 2:  Originating endpoint's authentication service creates a new
            header, Identity-Fingerprints, containing certain lines of
            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, Call-Id) and this new Identity-
            Fingerprints header.  The resulting signature is inserted
            into the new Identity-Media header.  The invite is forwarded
            to the next administrative domain.

   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.

   Step 4:  The terminating endpoint's authentication service receives
            the Invite.  It validates the Identity-Media signature is
            valid and was validates it was generated by the originating
            domain in step 2.

   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, and performs that
            challenge.  Described in this document are identity
            challenges for TLS, DTLS, ICE, and HIP.

   Step 7:  TLS, DTLS, and HIP cause the exchange of a certificate or
            public key.  The terminating endpoint validates the
            certificate or public key has a fingerprint matching the
            Identity-Fingerprint header (originally created in step 2).
            If it does, the terminating endpoint completes the identity
            challenge exchange.  After completion, the originating
            endpoint has proven (to the terminating endpoint) that it
            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:  You can reliably and honestly indicate calling party
            information ("caller-id") to the terminating endpoint, and
            ring their phone.

4.1.  Media Fingerprint 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.,



Wing                     Expires January 2, 2008                [Page 7]


Internet-Draft        SIP Identity using Media Path            July 2007


   "fingerprint").  The specific SDP attribute that are signed depends
   on which cryptographic identity technique(s) is used; see section
   Section 5.

   The SIP headers that are signed are signed the same as done by
   RFC4474, with the additional signing of the Media-Identity header;
   the body is not signed.  They signed headers 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 callid from Call-Id header field.

   o  The digit (1*DIGIT) and method (method) portions from CSeq header
      field, separated by a single space (ABNF SP, or %x20).  Note that
      the CSeq header field allows linear whitespace (LWS) rather than
      SP to separate the digit and method portions, and thus the CSeq
      header field may need to be transformed in order to be
      canonicalized.  The authentication service MUST strip leading
      zeros from the 'digit' portion of the Cseq before generating the
      digest-string.

   o  The Date header field, with exactly one space each for each SP and
      the weekday and month items case set as shown in BNF in RFC 3261.
      RFC 3261 specifies that the BNF for weekday and month is a choice
      amongst a set of tokens.  The RFC 2234 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
      mechanism MUST contain a Date header.

   o  The addr-spec component of the Contact header field value.  If the
      request does not contain a Contact header, this field MUST be
      empty (i.e., there will be no whitespace between the fourth and
      fifth "|" characters in the canonical string).

   o  The fingerprints component of the Identity-Media header field
      value.

   In this specification, the Identity-Media header is signed instead of
   the message body.  The Identity-Media contains only certain SDP lines
   from the SDP body.



Wing                     Expires January 2, 2008                [Page 8]


Internet-Draft        SIP Identity using Media Path            July 2007


4.2.  Authentication Service

   The authentication service examines the SIP message body for the
   application/sdp Content-Type.  For all such content-types found, the
   authentication service retrieves the cryptographic attributes
   described in Section 5, concatenates them together, and inserts a new
   SIP header field called Media-Fingerprints containing a comma-
   separated list of those signed attributes.

   This new header, along with all the headers and portions of headers
   signed by RFC4474 (From, Call-ID, etc.), are all signed by the
   authentication service.  The resulting signature is placed on the new
   Identity-Fingerprints header.

4.3.  Validation

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


5.  Proof of Identity Techniques

   Four techniques are described below, TLS, DTLS, ICE, and HIP.  Each
   provides a means to cryptographically prove the identity signed by
   the authentication service in SIP is the same as the identity on the
   media path.

   Each of these techniques work similarly -- a fingerprint of the
   certificate (or, with ICE, the public key itself) is included in the
   SDP.  The authentication service creates a new Identity-Fingerprints
   header and places into that header those certificate fingerprints
   (or, with ICE, the fingerprint of the public key).  The
   authentication service then creates a signature over specific SIP
   headers (see Section 4.1), and places that signature into the new
   Identity-Media 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 (or an SBC
   operating on its behalf).  The end system initiates a TLS, DTLS, ICE,
   or HIP session and validates the certificate fingerprint presented in



Wing                     Expires January 2, 2008                [Page 9]


Internet-Draft        SIP Identity using Media Path            July 2007


   SIP signaling matches the certificate presented in the TLS, DTLS,
   ICE, or HIP exchange.  If they match, and the TLS, DTLS, ICE, or HIP
   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.

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

5.2.  DTLS

   DTLS uses the same "fingerprint" attribute originally described for
   TLS.  The syntax is described in [I-D.fischl-sipping-media-dtls].



      Note:  DTLS is only necessary to prove identity with DTLS; SRTP
      [RFC3711] does not need to be used afterwards.  Obviously, using
      SRTP provides significant benefits over continuing to use RTP,
      because an attacker can inject bogus RTP after a successful
      validation of identity which is quite undesirable.  The SDP for
      doing RTP after a DTLS exchange might be signaled in SDP by using
      "RTP/AVP" rather than "RTP/SAVP" (lines folded for readability):

     v=0
     o=- 25678 753849 IN IP4 192.0.2.1
     s=
     c=IN IP4 192.0.2.1
     t=0 0
     m=audio 3456 RTP/AVP 0 18
     a=fingerprint
       SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
     a=setup:passive
     a=connection:new
      Of course, it would be desirable to more clearly indicate this
      somehow in SDP, as there are existing "best-effort" media
      encryption mechanisms which overload the meaning of a=crypto and
      a=key-mgmt to mean RTP/SAVP, and other implementations may also
      overload a=fingerprint in a similar, undesirable, way.






Wing                     Expires January 2, 2008               [Page 10]


Internet-Draft        SIP Identity using Media Path            July 2007


5.3.  ICE

   ICE doesn't have inherent support for public/private keys.  If public
   keys were sent with other ICE attributes, there can be a real risk of
   an ICE connectivity check exceeding the MTU.  ICE lacks a mechanism
   to fragment such large messages.  It is also bandwidth inefficient to
   send multiple ICE connectivity checks containing public keys, either
   as retransmissions or with multiple candidates.  Thus, for ICE, the
   public key is sent in SDP and the public key's fingerprint is
   exchanged on the media path -- opposite of TLS, DTLS, and HIP.

5.3.1.  ICE Public Key SDP Attribute

   The offerer includes its public key, which it will use for the
   subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP.  The syntax is a
   BASE64-encoded version of the endpoint's public key.

   The new attribute is called "ice-pub-key", which may appear on the
   session level, media level, or both.

5.3.2.  New STUN attributes

   Two new STUN attributes are defined to carry the plaintext challenge
   and the encrypted response.

5.3.2.1.  PK-CHALLANGE

   This is sent in a STUN Binding Request, and contains the bits to be
   encrypted by the private key.  Up to 256 bits can be included in the
   challenge.  When a STUN Binding Request is received containing this
   attribute, the contents of the PK-CHALLENGE are encrypted using the
   private key, and the result is included in the PK-RESPONSE attribute
   of the Binding Response.

   The PK-CHALLENGE MUST be the same for each candidate address that is
   being tested for connectivity.  If this requirement is not followed,
   the peer will incur a public key operation for every ICE connectivity
   check, which is not reasonable or necessary.

5.3.2.2.  PK-RESPONSE

   This is sent in a STUN Binding Response from the offerer to the
   answerer, and contains the encrypted result of the PK-CHALLENGE.

5.4.  HIP

   In [I-D.tschofenig-hiprg-host-identities], a new attribute "key-
   mgmt:host-identity-tag" is defined which contains the hash of the



Wing                     Expires January 2, 2008               [Page 11]


Internet-Draft        SIP Identity using Media Path            July 2007


   public key used in the subsequent HIP exchange.  This can be utilized
   and signed exactly like the "fingerprint" attribute for TLS or DTLS.


6.  ABNF

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

      media-fingerprint      = "Identity-Fingerprints" HCOLON
                               fingerprints
      fingerprints           = fingerprint *(COMMA fingerprint)

      fingerprint            =  2UHEX *(":" 2UHEX)
                                ; Each byte in upper-case hex, separated
                                ; by colons.

      UHEX                   =  DIGIT / %x41-46 ; A-F uppercase

      identity-media         = "Identity-Media" HCOLON signature
      signature              = LDQUOT 32LHEX RDQUOT

                    Figure 4: ABNF for new SIP headers

   The following figure shows the syntax of the new SDP attribute
   containing the ICE public key:

     ice-pub-key        = token    ; BASE64 encoded public key

                   Figure 5: ABNF for new SDP attribute


7.  Security Considerations

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

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





Wing                     Expires January 2, 2008               [Page 12]


Internet-Draft        SIP Identity using Media Path            July 2007


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

   o  the device to manufacture a new self-signed certificate (or public
      key) for each call, and populate the a=fingerprint or a=ice-pub-
      key attributes, as appropriate.  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.


8.  Operational Differences from RFC4474

   RFC4474 imposes one public key operation for the authentication
   service and one for validation.  In addition to that, the mechanism
   described in this paper also requires an additional public key
   operation for the authentication service and an additional public key
   operation 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.

   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.


9.  Limitations

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


10.  Examples







Wing                     Expires January 2, 2008               [Page 13]


Internet-Draft        SIP Identity using Media Path            July 2007


10.1.  DTLS

   This example shows how two a=fingerprint lines in SDP would populate
   a the Media-Fingerprints 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=setup:active
      a=connection:new
      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 6: Example with DTLS

   The SIP proxy performing the Media Identity authentication service
   would then insert the following two SIP headers into the message.
   The Media-Fingerprints header contains all of the fingerprint lines
   and the Identity-Signature header contains the signature of all of
   the relevant SIP headers and of the Media-Fingerprints header.  Lines
   are folded for readability:

    Identity-Fingerprints:
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
    Identity-Media:
       "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
        ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
        FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="

         Figure 7: SIP Headers Inserted by Authentication Service



Wing                     Expires January 2, 2008               [Page 14]


Internet-Draft        SIP Identity using Media Path            July 2007


10.2.  ICE

   With ICE, the public key is exchanged in the signaling path (in SDP)
   rather than in the media path (as is done with TLS, DTLS, and HIP).
   The Media-Fingerprints header only needs to contain the fingerprint
   of the ICE public key that is in the SDP.

   This is the INVITE as it left the SIP user agent (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
      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      a=pub-key:ejfiwj289ceucuezeceEJFjefkcjeiquiefekureickejfeefe
        uirujejfecejejejkfeJJCEIUQQIEFJCQUCJCEQUURIE09dnjkeefjek
      m=audio 54113 RTP/AVP 0
      a=candidate:1 1 UDP 2130706431 192.0.2.1 54113 typ host

                        Figure 8: Example with ICE

   The SIP proxy performing the Media Identity authentication service
   would then insert the following two SIP headers into the message.
   The Media-Fingerprints header contains the fingerprint of the ICE
   public key (A3:EA:B3:...), and the Identity-Signature header contains
   the signature of all of the relevant SIP headers and of the Media-
   Fingerprints header (lines are folded for readability):

    Identity-Fingerprints:
      A3:EA:B3:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:08
    Identity-Identity:
       "jjsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qc
        efQBbHC00VMZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0Ssjcd



Wing                     Expires January 2, 2008               [Page 15]


Internet-Draft        SIP Identity using Media Path            July 2007


        VcunyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Jcqe="

           Figure 9: Headers Inserted by Authentication Service


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


12.  IANA Considerations

   This document will add new IANA registrations for new STUN
   attributes.

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


13.  Normative References

   [I-D.ietf-behave-turn]
              Rosenberg, J., "Obtaining Relay Addresses from Simple
              Traversal Underneath NAT (STUN)",
              draft-ietf-behave-turn-03 (work in progress), March 2007.

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

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [I-D.fischl-sipping-media-dtls]
              Fischl, J., "Datagram Transport Layer Security (DTLS)
              Protocol for Protection of Media  Traffic Established with
              the Session Initiation Protocol",
              draft-fischl-sipping-media-dtls-02 (work in progress),
              March 2007.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session



Wing                     Expires January 2, 2008               [Page 16]


Internet-Draft        SIP Identity using Media Path            July 2007


              Description Protocol (SDP)", RFC 4572, July 2006.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

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

   [I-D.tschofenig-hiprg-host-identities]
              Tschofenig, H., "Interaction between SIP and HIP",
              draft-tschofenig-hiprg-host-identities-05 (work in
              progress), June 2007.


Author's Address

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

   Email:  dwing@cisco.com




























Wing                     Expires January 2, 2008               [Page 17]


Internet-Draft        SIP Identity using Media Path            July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Wing                     Expires January 2, 2008               [Page 18]


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