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

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

Network Working Group                                            D. Wing
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                              H. Kaplan
Expires:  May 18, 2008                                       Acme Packet
                                                       November 15, 2007


                     SIP Identity using Media Path
                    draft-wing-sip-identity-media-01

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 May 18, 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 which breaks
   that signature.

   This document defines a new identity mechanism which operates with



Wing & Kaplan             Expires May 18, 2008                  [Page 1]


Internet-Draft        SIP Identity using Media Path        November 2007


   SBCs and B2BUAs.  This new identity mechanism creates a signature
   over certain SIP headers and certain SDP lines, and uses both SIP
   signaling and the media path to perform its identity function.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   3.  Analysis of SIP-Identity with SBCs . . . . . . . . . . . . . .  4
     3.1.  SIP-Identity with SBCs . . . . . . . . . . . . . . . . . .  4
       3.1.1.  Validate the Signature . . . . . . . . . . . . . . . .  5
       3.1.2.  Destroy Existing Signature . . . . . . . . . . . . . .  6
       3.1.3.  Create New Identity  . . . . . . . . . . . . . . . . .  6
       3.1.4.  Sign the New Identity  . . . . . . . . . . . . . . . .  7
     3.2.  Transport Address as Identifier  . . . . . . . . . . . . .  7
   4.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Identity Media Signature . . . . . . . . . . . . . . . . . 10
     4.2.  Authentication Service . . . . . . . . . . . . . . . . . . 11
     4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Proof of Identity Techniques . . . . . . . . . . . . . . . . . 12
     5.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.2.1.  SRTP after DTLS optional . . . . . . . . . . . . . . . 13
     5.3.  ICE  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.3.1.  ICE Public Key SDP Attribute . . . . . . . . . . . . . 13
       5.3.2.  New STUN attributes  . . . . . . . . . . . . . . . . . 14
     5.4.  HIP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     7.1.  Device Disclosure  . . . . . . . . . . . . . . . . . . . . 15
   8.  Operational Differences from RFC4474 . . . . . . . . . . . . . 16
   9.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.2. ICE  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     10.3. Request without SDP  . . . . . . . . . . . . . . . . . . . 20
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     13.2. Informational References . . . . . . . . . . . . . . . . . 22
   Appendix A.  ToDo List . . . . . . . . . . . . . . . . . . . . . . 23
   Appendix B.  Changes From Previous Versions  . . . . . . . . . . . 23
     B.1.  Changes from 00 to 01  . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25




Wing & Kaplan             Expires May 18, 2008                  [Page 2]


Internet-Draft        SIP Identity using Media Path        November 2007


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.  The SIP message body typically contains the SDP.

   In cases where the originating, authenticating domain directly
   connect to the terminating, validating domain, RFC4474 has
   questionable value.  The reason is that in such cases TLS can simply
   be used for the communication between the edge proxies of each
   domain, which not only provides additional security properties (e.g.,
   encryption), but is also more efficient and protects all signaling
   messages.  The real value of RFC4474 lies in cases where SIP
   signaling crosses multiple domains, belonging to different
   organizations.  Unfortunately, in the presence of SBCs or B2BUAs that
   are in a different trust domain than the calling party or called
   party, SIP Identity provides the same security properties as using
   P-Asserted-Identity [RFC3325] between those same trust domains, if it
   succeeds at all.  In most cases it would probably fail, and force the
   UAC to re-send its request without any Identity mechanism if it
   wanted to establish communication.

   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, and not all the same SIP headers.  The remote endpoint is
   expected to validate the signature over the SIP headers and specified
   SDP attributes, 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 to ICE
   [I-D.ietf-mmusic-ice].  This mechanism is also extensible, in order
   to be usable by future mechanisms which need signed SDP attributes

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



Wing & Kaplan             Expires May 18, 2008                  [Page 3]


Internet-Draft        SIP Identity using Media Path        November 2007


3.  Analysis of SIP-Identity with SBCs

   This section examines how SIP Identity [RFC4474] operates with
   SBCs(Section 3.1) or certain back-to-back user-agents (B2BUAs), and
   how SIP Identity uses transport addresses as identifiers
   (Section 3.2).

3.1.  SIP-Identity with SBCs

   After an authorization agent signs a SIP request, the SIP request
   traverses SBC(s) operated by other trust domains and finally arrives
   at the destination domain.  If all of those intervening SBCs support
   SIP Identity, those SBCs will validate the request's signature,
   destroy the existing signature, create a new identity for the
   request, and sign the request's new identity.  These necessary SBC
   actions (described in detail below) provide the same identity
   assurance as using P-Asserted-Identity between trust domains.

   The functions of SBCs, and why they do what they do, is mainly
   detailed in [I-D.ietf-sipping-sbc-funcs].  Regardless of the
   architectural implications of their actions, the fact is their
   functions are often performed as a SIP request/response traverses
   across SIP domains.  Other B2BUAs in the path sometimes also perform
   functions which invalidate an RFC4474 signature.  With regard to
   RFC4474, the SBC functions which impact the signature are:

   o  Replacing IP addresses in SDP body parts

   o  Replacing the Contact URI

   o  Modifying the Call-ID

   o  Modifying the CSeq


















Wing & Kaplan             Expires May 18, 2008                  [Page 4]


Internet-Draft        SIP Identity using Media Path        November 2007


   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 rewrite the IP addresses in the SDP.  There may be
   an SBC in the Enterprise as well, however that SBC would own the
   appropriate Enterprise domain certificate and re-sign the request,
   and thus logically appear as the Enterprise User Agent

             +---------+ +---------+  +---------+  +---------+
             |SP1-SBC-1|-|SP1-SBC-2|--|SP2-SBC-1|--|SP2-SBC-2|
             +---+-----+ +---------+  +---------+  +-+-------+
                 |                                   |
                 |                                   |
             +--------------+                 +------+-------+
             |SIP User Agent|                 |SIP User Agent|
             | 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 numbers (e.g.,
   'sip:+17005551008@example.com;user=phone') or using a SIP URI (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:

3.1.1.  Validate the Signature

   Per RFC4474, the SBC would validate the incoming SIP request.  This
   requires a public key operation to be performed against the SIP
   request.

   [[computationally expensive.  Will use TLS or IPSEC instead (doesn't
   require public key operation for every SIP request), or will rely on
   ACLs or a dedicated link or dedicated network.]]

   This creates 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 or IPSEC to
   ensure the SIP signaling originated from the enterprise.  Since
   service providers do not allow Enterprises to be transitive domains,
   they only allow From-URI domains of the enterprise, and thus do not
   need a per-request 4474-style signature from the Enterprise at the
   first ingress hop.




Wing & Kaplan             Expires May 18, 2008                  [Page 5]


Internet-Draft        SIP Identity using Media Path        November 2007


3.1.2.  Destroy Existing Signature

   SBCs and B2BUAs typically modify the media transport addresses and
   thus invalidate the RFC4474 signature.  This prevents downstream
   systems from validating original signature.

   Because the original signature is invalidated 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.  Note this does not require
   malicious intent within the trust domain - a weak or mis-configured
   entry point into the trust chain of service providers compromises the
   entire trust chain.

3.1.3.  Create New Identity

   In order to generate a SIP Identity signature (in the next step), the
   SBC requires the private key associated with the domain of that From:
   address.  Because the SBC and the initiator of the SIP request are
   different entities, it is unlikely the SBC will possess the
   initiating domain's private key.  Thus, the SBC will have to create a
   new identity -- using its domain -- for the request, if it wants to
   provide RFC4474.

   The new identity creates difficulties with downstream whitelists,
   call routing, and reputation systems.  For example, downstream
   systems may sometimes see the identity +14085551212@example.com when
   the request is routed through certain SBCs, and may see a different
   identity, +14085551212@example.net, when the request is routed
   through different SBCs.  Such different routing might be done due to
   network outages or for cost savings (e.g., evening rates).  Due to
   these different identities, the domain name no longer has much
   meaning -- for E.164 telephone numbers, the user-part becomes the
   entire identity.  In some sense that's appropriate; if the user-part
   is truly a global-scope E.164 number, then the domain portion is
   essentially meaningless.  It might as well have been a tel-URI,
   except that making it a SIP-URI is more common and allows rfc4474 to
   be used.

   A SBC might receive an identity containing an E.164 phone number or
   containing a SIP URI.  When forming a new identity, the SBC performs
   different steps for each of those cases:






Wing & Kaplan             Expires May 18, 2008                  [Page 6]


Internet-Draft        SIP Identity using Media Path        November 2007


   E.164 telephone numbers:
      The SBC would remove the original domain name and substitute its
      own domain on the right-hand side.

   SIP URIs:
      Unlike E.164 telephone numbers, the SBC is not able to simply
      substitute its domain name for the enterprise's domain name due to
      user-part name collisions.  There is only one unappealing
      solution:  use the so-called escape-hack from email.  For example,
      the SBC could rewrite sip:john.doe@example.com to
      sip:john.doe%example.com@sp1.example.net.

3.1.4.  Sign the New Identity

   Finally, the SBC will sign the new identity, using the private key
   associated with the new identity.  This private key is known to the
   SBC (because it is the SBC's domain name).  This function incurs a
   public key operation for that SIP request.

3.2.  Transport Address as Identifier

   SIP Identity signs the SDP so that the IP address (contained in the
   SDP) provides identity.  From [RFC4474]:

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

   RFC4474 ties an identifier (IP address) with the identity (SIP
   "From:" address), which is counter to ongoing efforts in the IETF to
   split identifiers from identity (e.g., [I-D.ietf-hip-base],
   [I-D.farinacci-lisp], [I-D.carpenter-idloc-map-cons],
   [I-D.whittle-ivip-arch]).

   The presence of media relays (e.g., TURN [I-D.ietf-behave-turn]),
   which may be used by an attacker, means that relying exclusively on
   such identifiers is risky.  For example, if an attacker were able to
   cause re-use of the (signed) transport address within the replay
   window, the attacker can successfully impersonate the identity.

   Additionally, RFC4474's tying of identities to IP address causes a
   failure in certain NAT scenarios when the source transport address of
   arriving media does not agree with the SDP.  While not written down
   in a standard at this time, if both endpoints are using ICE
   [I-D.ietf-mmusic-ice], the ICE username and password (sent in SDP and



Wing & Kaplan             Expires May 18, 2008                  [Page 7]


Internet-Draft        SIP Identity using Media Path        November 2007


   signed by RFC4474) can be reliably used to establish identity.
   However, if either endpoint does not support ICE, the arriving media
   will be considered fraudulent because the arriving media does not
   match with the RFC4474-signed SDP.


4.  Operation

   The operation of SIP-Identity-Media is similar to RFC4474 and uses
   authentication service proxies much like 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.

   o  Several SIP headers and the Identity-Media header are all signed
      (as detailed in Section 4.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, TLS, ICE, or HIP over the media
      path.

   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.     |<=========tls, dtls, ice, or hip=========>|
          7.     |          |    :     |      :   |     validated
          8.     |          |    :     |      :   |     ring phone
                 |          |    :     |      :   |         |
                                 :            :

                          Figure 2: Message Flow




Wing & Kaplan             Expires May 18, 2008                  [Page 8]


Internet-Draft        SIP Identity using Media Path        November 2007


   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.

   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
            Identity- Media header with the attributes it wants signed,
            then have the auth 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, DTLS, ICE, or
            HIP), and performs that challenge.  Described in this
            document are identity challenges for TLS, DTLS, ICE, and
            HIP.






Wing & Kaplan             Expires May 18, 2008                  [Page 9]


Internet-Draft        SIP Identity using Media Path        November 2007


   Step 7:  All of the identity challenges (TLS, DTLS, ICE, and HIP)
            cause the exchange of either a certificate or a public key
            in 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.

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

   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



Wing & Kaplan             Expires May 18, 2008                 [Page 10]


Internet-Draft        SIP Identity using Media Path        November 2007


      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.

4.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 5), 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 4.1 are all signed by the authentication
   service.  The resulting signature is placed on the new Identity-
   Media-Signature header.






Wing & Kaplan             Expires May 18, 2008                 [Page 11]


Internet-Draft        SIP Identity using Media Path        November 2007


4.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 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-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 4.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 TLS, DTLS, ICE, or HIP session and validates that
   the (signed) certificate fingerprint presented in the 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.




Wing & Kaplan             Expires May 18, 2008                 [Page 12]


Internet-Draft        SIP Identity using Media Path        November 2007


5.2.  DTLS

   DTLS uses the same "fingerprint" attribute originally described for
   TLS.  The syntax is described in [I-D.ietf-sip-dtls-srtp-framework].

5.2.1.  SRTP after DTLS optional

   [[Discussion Point:  Is there interest in having identity without
   SRTP??]]

   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

   Of course, it would be desirable to more clearly indicate this
   somehow in SDP.  The example above collides with non-standard, but
   deployed, "best-effort" media encryption mechanisms.  SDP Capability
   Negotiation [I-D.ietf-mmusic-sdp-capability-negotiation] might be a
   useful consideration for this functionality.

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-CHALLENGE and PK-RESPONSE, in its SDP.  The syntax is a



Wing & Kaplan             Expires May 18, 2008                 [Page 13]


Internet-Draft        SIP Identity using Media Path        November 2007


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

   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
   public key used in the subsequent HIP exchange.  This can be utilized
   and signed exactly like the "fingerprint" attribute for TLS or DTLS.
















Wing & Kaplan             Expires May 18, 2008                 [Page 14]


Internet-Draft        SIP Identity using Media Path        November 2007


6.  ABNF

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

      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 6: ABNF for new SIP headers

   The following figure shows the syntax of the new SDP attribute
   containing the ICE public key.  This is used only by endpoints
   implementing the ICE proof of identity technique (Section 5.3).

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

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




Wing & Kaplan             Expires May 18, 2008                 [Page 15]


Internet-Draft        SIP Identity using Media Path        November 2007


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


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




Wing & Kaplan             Expires May 18, 2008                 [Page 16]


Internet-Draft        SIP Identity using Media Path        November 2007


   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.


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


10.  Examples

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














Wing & Kaplan             Expires May 18, 2008                 [Page 17]


Internet-Draft        SIP Identity using Media Path        November 2007


   (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 8: 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="

         Figure 9: SIP Headers Inserted by Authentication Service







Wing & Kaplan             Expires May 18, 2008                 [Page 18]


Internet-Draft        SIP Identity using Media Path        November 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).

   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 10: Example with ICE

   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 the ICE public key attribute 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=pub-key"
     Identity-Media-Signature:
      "jjsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qc
       efQBbHC00VMZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0Ssjcd
       VcunyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Jcqe="



Wing & Kaplan             Expires May 18, 2008                 [Page 19]


Internet-Draft        SIP Identity using Media Path        November 2007


           Figure 11: Headers Inserted by Authentication Service

10.3.  Request without SDP

   This example shows how a SIP request without SDP is signed.

   Message as sent by the UAC (lines folded for readability)

      MESSAGE sip:user2@example.com SIP/2.0
      Via: SIP/2.0/TCP user1pc.example.com;branch=z9hG4bK776sgdkse
      Max-Forwards: 70
      From: sip:user1@example.com;tag=49583
      To: sip:user2@example.com
      Call-ID: asd88asd77a@1.2.3.4
      CSeq: 1 MESSAGE
      Content-Type: text/plain
      Content-Length: 18

      Watson, come here.

                      Figure 12: Example with no SDP

   The authentication service would add the following headers to the
   above message:

     Identity-Info: <https://atlanta.example.com/atlanta.cer>
       ;alg=rsa-sha1
     Identity-Media:
       BPH="MZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxA"
     Identity-Media-Signature:
      "diOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qcjjsR
       bHC00VMZr2k+t6efQBVmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB09JcVc
       unyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVnqeSsjcd="

                         Figure 13: added headers


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.

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






Wing & Kaplan             Expires May 18, 2008                 [Page 20]


Internet-Draft        SIP Identity using Media Path        November 2007


12.  IANA Considerations

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

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


13.  References

13.1.  Normative References

   [I-D.ietf-behave-turn]
              Rosenberg, J., "Traversal Using Relays around NAT (TURN):
              Relay Extensions to Session  Traversal Utilities for NAT
              (STUN)", draft-ietf-behave-turn-04 (work in progress),
              July 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.ietf-sip-dtls-srtp-framework]
              Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing an SRTP Security Context using DTLS",
              draft-ietf-sip-dtls-srtp-framework-00 (work in progress),
              November 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.

   [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",



Wing & Kaplan             Expires May 18, 2008                 [Page 21]


Internet-Draft        SIP Identity using Media Path        November 2007


              draft-tschofenig-hiprg-host-identities-05 (work in
              progress), June 2007.

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-10 (work in
              progress), October 2007.

   [I-D.farinacci-lisp]
              Farinacci, D., "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-05 (work in progress), November 2007.

   [I-D.carpenter-idloc-map-cons]
              Carpenter, B., "General Identifier-Locator Mapping
              Considerations", draft-carpenter-idloc-map-cons-01 (work
              in progress), June 2007.

   [I-D.whittle-ivip-arch]
              Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
              Architecture", draft-whittle-ivip-arch-00 (work in
              progress), July 2007.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

13.2.  Informational References

   [I-D.ietf-sipping-sbc-funcs]
              Hautakorpi, J., "Requirements from SIP (Session Initiation
              Protocol) Session Border Control  Deployments",
              draft-ietf-sipping-sbc-funcs-03 (work in progress),
              April 2007.

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

   [I-D.ietf-mmusic-sdp-capability-negotiation]
              Andreasen, F., "SDP Capability Negotiation",
              draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
              progress), October 2007.






Wing & Kaplan             Expires May 18, 2008                 [Page 22]


Internet-Draft        SIP Identity using Media Path        November 2007


Appendix A.  ToDo List

   o  Add Table-2 of RFC3261

   o  re-use RFC4474 response code for failures, or invent new ones?

   o  describe what occurs if both SIP-Identity-Media and SIP-Identity
      are both used?


Appendix B.  Changes From Previous Versions

B.1.  Changes from 00 to 01

   o  Removed "Contact" header from signature.  SBCs need to change it.

   o  Removed "Call ID" header from signature.  This header often
      contains an IP address, so many SBCs change it.

   o  Removed "CSeq" header from signature.  This header is sometimes
      changed by SBCs and B2BUA's.

   o  include SDP attribute names in Identity-Media signature.  This
      allows any attribute to be signed.

   o  Old "Identity-Fingerprints" header renamed to "Identity-Media",
      and only attribute names are listed in it, not attribute values.

   o  Old "Identity-Media" header renamed to "Identity-Media-Signature".

   o  Described how to sign SIP requests without an SDP body part, and
      with a mix of SDP and non-SDP bodyparts.


Authors' Addresses

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

   Email:  dwing@cisco.com








Wing & Kaplan             Expires May 18, 2008                 [Page 23]


Internet-Draft        SIP Identity using Media Path        November 2007


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

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









































Wing & Kaplan             Expires May 18, 2008                 [Page 24]


Internet-Draft        SIP Identity using Media Path        November 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 & Kaplan             Expires May 18, 2008                 [Page 25]


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