Subject: [Sip] SIP Identity using Media Path

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jul 2007 11:55:54 -0700

As many of you are aware, the signature created by SIP-Identity
(RFC4474) breaks if an SBC or B2BUA modifies the SDP in the SIP body.
Typically these modifications include changing the m/c lines (to
direct the RTP media through the SBC itself, or through a transcoder),
or performing other adjustments of the SDP to interwork with bugs and
features of other SIP networks or other endpoints.

I just submitted a draft, "SIP Identity using Media Path", which
describes a mechanism that allows RFC4474-like signatures and also
allows SBCs and B2BUAs to modify the message's SDP.  Links to HTML
and plain text versions of the Internet Draft are below.

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

Please send comments on this draft to the SIP mailing list at
[email-masked].

-d

-----

HTML version: 
http://tinyurl.com/25539z
http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-sip-identity-med
ia-00.html

plain text version: 
http://tinyurl.com/2gldnv
http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-sip-identity-med
ia-00.txt

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 3 Jul 2007 00:26:54 +0200

Hi Dan,

Chapter 9 says:

"in order for the mechanism to work, SBC-type-of-entities must permit DTLS, TLS, ICE, or HIP messages to be exchanged in the media path."

A small question for clarification: at what point must this exchange (two-way, I assume) work? As soon as the UAS has received the INVITE?

Regards,

Christer

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 2. heinäkuuta 2007 21:56
> To: 'SIP Working Group'
> Cc: [email-masked]
> Subject: [Sip] SIP Identity using Media Path
> 
> Typically these modifications include changing the m/c lines 
> (to direct the RTP media through the SBC itself, or through a 
> transcoder), or performing other adjustments of the SDP to 
> interwork with bugs and features of other SIP networks or 
> other endpoints.
> 
> 
> I just submitted a draft, "SIP Identity using Media Path", 
> which describes a mechanism that allows RFC4474-like 
> signatures and also allows SBCs and B2BUAs to modify the 
> message's SDP.  Links to HTML and plain text versions of the 
> Internet Draft are below.
> 
> Abstract:
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jul 2007 16:04:54 -0700

> Chapter 9 says:
> 
> "in order for the mechanism to work, SBC-type-of-entities 
> must permit DTLS, TLS, ICE, or HIP messages to be exchanged 
> in the media path."
> 
> A small question for clarification: at what point must this 
> exchange (two-way, I assume) work? As soon as the UAS has 
> received the INVITE?

Yes.

The DTLS, TLS, ICE, or HIP exchange would need to occur
prior to displaying Caller-ID-like information to the
user -- otherwise, an attacker could spoof that Caller-ID
information.  It seems defective, to me, to display
Caller-ID information that was spoofed to only later
learn (after doing DTLS, TLS, ICE, or HIP) that the 
calling party had lied about their identity.  

There is some protection against such an attack that could
reduce this risk (the Date: header is signed, so the attacker
would need to obtain a relatively recent SIP request) -- that
protection might be sufficient in networks that block exchange 
of packets prior to 200 Ok.  If an attacker was able to
get ahold of such a SIP request, you would know it when the
attacker failed the DTLS, TLS, ICE, or HIP exchange, which
I suppose is better than nothing.

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 3 Jul 2007 15:31:42 +0200

Hi, 

>>Chapter 9 says:
>> 
>>"in order for the mechanism to work, SBC-type-of-entities must permit 
>>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path."
>> 
>>A small question for clarification: at what point must this exchange 
>>(two-way, I assume) work? As soon as the UAS has received the INVITE?
> 
>Yes.

As we know from our RTPSEC discussions, one of the issues of using
SBC-type-of-entities (or gates) is that you MAY NOT have end-to-end
media plane connectivity as soon as the INVITE has been sent.

Regards,

Christer

>The DTLS, TLS, ICE, or HIP exchange would need to occur prior 
>to displaying Caller-ID-like information to the user -- 
>otherwise, an attacker could spoof that Caller-ID 
>information.  It seems defective, to me, to display Caller-ID 
>information that was spoofed to only later learn (after doing 
>DTLS, TLS, ICE, or HIP) that the calling party had lied about 
>their identity.  
> 
>protection might be sufficient in networks that block 
>exchange of packets prior to 200 Ok.  If an attacker was able 
>to get ahold of such a SIP request, you would know it when 
>the attacker failed the DTLS, TLS, ICE, or HIP exchange, 
>which I suppose is better than nothing.
> 
> -d
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jul 2007 11:51:18 -0700

> >>must permit 
> >>exchange 

In such a situation, the authentication service will still be able 
to validate the signature.  This may be sufficient until or unless
replay attacks are causing havoc.  If It Ss Considered that replay
attacks are a small problem, then that's all you need to do and
breaking the media plane is fine.  However, as attackers get 
more sophisticated and capable of replay attacks, it will be 
necessary to use DTLS/TLS/HIP/ICE proof of possession of the 
private key.

One could also implement a system where edge SBCs perform
the DTLS/TLS/HIP/ICE validation on behalf of the endpoints;
this might be suitable for certain network (such as endpoints
that cannot or will not support DTLS/TLS/HIP/ICE themselves
but who need strong identity for phone calls for whitelists,
blacklists, and useful reptuation systems).

-d

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Jul 2007 08:37:32 +0100

Dan,

The mechanism described for ICE seems to provide an alternative to ICE's
password-based mechanism for correlating binding requests with
offer-answer exchanges. I have not seen any motivation for this
alternative.

John 

> Sent: 02 July 2007 19:56

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 01:45:34 -0700

> offer-answer exchanges.

It's not an alternative to ICE's username and password; the new 
attributes (PK-CHALLENGE, PK-RESPONSE) would be used in addition 
to the existing STUN attributes used by ICE's connectivity
checks.  The ICE username/password would still be used for
message integrity and to associate a flow with an endpoint's
SDP answer.

> I have not seen any motivation for this
> alternative.

The motivation is proving you know the private key 
associated with the public key.  It's only after that
proof that you can be assured the Invite wasn't captured
by an attacker, had its SDP replaced with the attacker's
IP address, and replayed to you.

All of the proof of identity techniques described in the
paper exchange a public key over the media path (HIP, DTLS-SRTP,
TLS) or in the SIP signaling path (ICE).  Then, over the media 
path, the remote party proves he knows the private key 
associated with that public key.  This proof of knowledge of
the private key is part of the handshake for HIP, DTLS,
and TLS; what the paper does is describe how ICE can do 
something similar.  The primary purpose of ICE in that
family of proof of identity techniques is to provide a 
modicum of SBC-survivable identity if RTP (or SRTP 
with Security Descriptions) is used.  Things are obviously
much more secure if DTLS-SRTP, TLS, or HIP are used,
as this ensures nothing is going to inject RTP packets
into the stream; using RTP can't ensure that.

(Crypto experts will point out there is a mafia fraud 
attack problem with the ICE technique as described 
in the paper.  That is true, but if you're not going 
to run SRTP using a secure keying mechanism you're 
suffering the same risk of someone injecting RTP into
your stream as the mafia fraud attack.)

-d

---

From: Hans Persson <[email-masked]>
Date: Wed, 04 Jul 2007 11:00:18 +0200

> and plain text versions of the Internet Draft are below.

It's nice to see work like this that tries to handle the reality of
installed networks instead of pretending that SBCs don't exist.

I'm not sure that I grasp this completely yet, but I'll let it simmer
for a while and give it another read later.

=== Comments ===

Section 3, figure 1:

This figure is a simplification, since many enterprises will have their
own SBCs on their borders:

    <--- Enterprise-A ---->
    clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+
                                                           |
    +------------------------------------------------------+
    |
    |                              <--- Enterprise-B ---->
    +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients

Section 3, "mailto URLs" para:

sp1.net and sp2.net (and, later in the document, sp3.net) are (or at
least could be) real domains that shouldn't be used.

Section 4.1, item about Contact:

How can the Contact header usefully be used in the signing process? An
SBC along the message path will happily replace it.

=== Editorial nits ===

In the text, RFC references are sometimes written "RFCxxxx" and
sometimes "RFC xxxx". Decide on one alternative.

Section 3, figure 1:

> +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+

SP1 has two SBC1. One of them should be SBC2.

Section 3, first para after figure 1:

> using a mailto URL (e.g., 'sip:[email-masked]')

Both here and a couple of paragraphs below (under "Mailto URLs:"), sip:
URLs are refered to as mailto URLs which sounds very strange.

Section 3, "mailto URLs" para:

> SP1 would validate the RFC4474 signature modify the SDP.

I can't make sense of this sentence. What should it mean?

> So that a
>      new RFC4474 signature can be created using its own public/private
>      key pair, SP1 needs to modify the From:  field. 

Rewrite this sentence to

>> SP1 needs to modify the From: field so that a new RFC4474 signature
>> can be created using its own public/private key pair.

> Unlike with E.164
>      numbers which are globally unique, the SP1 isn't able to

Remove the "the" in front of "SP1".

Section 4, second list item:

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

Detailed in what?

Section 4, para before figure 2:

> In practice, if the

The rest of this sentence has gotten lost somewhere. Please contact the
information desk.

Section 4, step 1:

> Step 1:  Originating endpoint prepares to send an Invite and chooses

"INVITE"

> then sends the Invite to its local SIP proxy.

"INVITE"

Section 4, step 2:

> into the new Identity-Media header.  The invite is forwarded

"INVITE"

Section 4, step 4:

> the Invite.  It validates the Identity-Media signature is
>            valid and was validates it was generated by the originating

"INVITE"

Insert "that" after "It validates". Change "was validates" to "validates
that".

Section 4, step 5:

> authentication service forwards the Invite to the endpoint.

"INVITE"

Section 4, step 6:

> challenge technique from the Invite, and performs that

"INVITE"

Section 4, step 7:

> public key.  The terminating endpoint validates the

Insert "that" after "validates".

Section 4, step 8:

> Step 8:  You can reliably and honestly indicate calling party
>            information ("caller-id") to the terminating endpoint, and
>            ring their phone.

Rewrite to 

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

Section 4.1, first para:

> "fingerprint").  The specific SDP attribute that are signed depends

"attributes"

Section 4.1, second para:

> The SIP headers that are signed are signed the same as done by

Remove the second "signed".

> the body is not signed.  They signed headers are:

"They" -> "The"

Section 4.1, item about Date:

> the weekday and month items case set as shown in BNF in RFC 3261.

Insert "the" before "BNF".

Section 4.2:

> The authentication service examines the SIP message body for the
>   application/sdp Content-Type.  For all such content-types found, the

"all such content-types" -> "all such message bodies"

Section 5, para 3:

> or HIP session and validates the certificate fingerprint presented in
> SIP signaling matches the certificate presented in the TLS, DTLS,

Insert "that" after "validates" and insert "the" before "SIP".

Section 5.2:

Newline missing after SDP example.

Section 5.3.1:

> subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP.  The syntax is a

"CHALLENGE"

Section 5.3.2.1:

> 5.3.2.1.  PK-CHALLANGE

"CHALLENGE"

Section 7.1:

Write the list items as complete sentences, i.e. start with capitals and
remove ", or" from the end of the first item.

> the device to manufacture a new self-signed certificate (or public

Insert "needs" after "the device".

Section 10.1:

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

"a the" -> "the"

"INVITE"

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210857   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

---

From: Hans Persson <[email-masked]>
Date: Wed, 04 Jul 2007 11:25:17 +0200

> > exchange (two-way, I assume) work? As soon as the UAS has 

I think this will have a much better chance of succeeding if the
specification requires this exchange to use the same source and
destination ports as the media that will later be sent on the same
channel. If not, an SBC may lock onto this stream and reject media from
other sources.

Hans

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Jul 2007 11:19:20 +0100

Dan,

Thanks for the explanation. However, I am still not certain I have quite
"got it" yet. Let me explain what I think it is doing, and you can
confirm or deny.

A sends an INVITE request with SDP offer containing ICE candidates and a
password. A's local proxy adds the Identity-Media header field. B
receives the INVITE request and knows, from the From and Identity-Media
header fields, that it has comes from A, and therefore that the password
has come from A. So if nobody has been able to eavesdrop on the INVITE
request, this gives proof of ownership of STUN requests demonstrating
possession of that password. Right?

However, the assumption that there is no eavesdropping is not a safe
assumption (even if SIPS is use, I think we are all familiar with its
limitations). By conveying a public key rather than a password,
eavesdropping is not a problem. Right?

More below.

John

> Sent: 04 July 2007 09:46
> To: Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] SIP Identity using Media Path
> 
[JRE] The Identity header field would prevent this (although the
Identity-Media header field does not).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 09:40:02 -0700

> installed networks instead of pretending that SBCs don't exist.

Thanks.

>     clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+

True.  I'll figure out a clearer way to diagram that.

> least could be) real domains that shouldn't be used.

Agreed; I may go with "sp1.example.net" and "sp2.example.net", 
although this is less clear than using unique top-level domain 
names.

> SBC along the message path will happily replace it.

I have removed that in -01 (which isn't yet published, of course).  There
was some thought it was necessary, but I agree it should be removed
from the signature.

On a similar note, I am considering removing CallId from the signature.
Oftentimes the Call Id value contains an IP address (in dotted decimal
or hex), and an SBC or B2BUA may also want to rewrite such a CallId.  I
have made a note of that in -01 so this can be discussed.

> === Editorial nits ===

Thanks for the list of nits - I'll get those cleaned up in -01.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 10:01:19 -0700

> channel.

Yes, that is how HIP's key exchange, TLS, DTLS-SRTP, and ICE
all function.

> If not, an SBC may lock onto this stream and reject 
> media from other sources.

Yes, I agree that will give the best chance.  Of course, it is
always possible for an SBC (or firewall) to block such messages 
anyway (as has been discussed on the RTPSEC mailer).

-d

---

From: Hans Persson <[email-masked]>
Date: Wed, 04 Jul 2007 19:13:54 +0200

> True.  I'll figure out a clearer way to diagram that.

Possibly it gets better if done up-down instead of left-right.

> although this is less clear than using unique top-level domain 

Perhaps it would be clearer to use for instance sp1.example.com,
sp2.example.net and sp3.example.org.

> have made a note of that in -01 so this can be discussed.

I thought about that as well, but apparently I forgot about adding it to
my mail. I think it would be a good idea to take Call-ID out as well.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

---

From: Hans Persson <[email-masked]>
Date: Wed, 04 Jul 2007 19:18:10 +0200

> anyway (as has been discussed on the RTPSEC mailer).

But that would at least mean that the SBC would have to look inside the
media stream to see that not everything in it is (S)RTP, instead of just
looking at the source and destination. 

It may happen, of course, but at least it's less likely. When it does
appear, it would require an SBC that can recognize the security
interchange for what it is and allow it to pass even though it isn't
media. I'm not sure if that can reasonably be done.

Hans

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 10:25:57 -0700

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, July 04, 2007 3:19 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]

Yes -- you could accomplish exactly that by only validating the
signature over the headers and not doing the HIP/ICE/DTLS-SRTP/TLS
media path validation.

However, this means you have transitive trust of all the SIP proxies
along the path.  It also means you don't think an attacker has captured
a valid, signed Invite, and is replaying it towards you.

> eavesdropping is not a problem. Right?

Right.  

(Although I have variously convinced myself there is still a mafia
fraud attack problem with the ICE technique, and have convinced myself
there isn't such an attack.  I'll need to leave that analysis until
later when I have sufficient time to write it up.  Today I think there
isn't a problem (because the public key is authenticated by A's 
signature, which prevents a man-in-the-middle from doing a mafia
fraud attack by replacing the A's public key with his own public
key.)

> Identity-Media header field does not).

Right.

To combat this attack, Identity (RFC4474) relies on IP address
and port numbers.  However, NATs, TURN, and SBCs reduce the 
value of the IP address and port numbers as a unique identifier
of a flow before the RFC4474 replay window has expired.

SIP-Identity-Media doesn't use IP addresses -- rather, it 
has the endpoints prove they know the private key associated 
with their public key.  This allows SBCs to rewrite m/c lines,
and also removes the risk, inherient in RFC4474, that an 
attacker will be able to get your recently-used transport 
address assigned to them by the same NAT or TURN server.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 10:27:12 -0700

> Possibly it gets better if done up-down instead of left-right.

I'll fire up Jave and draw circles.

> sp2.example.net and sp3.example.org.

That would work; thanks for the suggestion.

> my mail. I think it would be a good idea to take Call-ID out as well.

Ok, thanks.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jul 2007 10:34:00 -0700

> But that would at least mean that the SBC would have to look 
> inside the media stream to see that not everything in it is 
> (S)RTP, instead of just looking at the source and destination. 

Many SBCs, and some firewalls, include "RTP inspection".  They drop
packets that aren't RTP packets (such as ICE packets, DTLS-SRTP
packets [draft-ietf-avt-dtls-srtp], and RTCP packets
[draft-ietf-avt-rtp-and-rtcp-mux].

> media. I'm not sure if that can reasonably be done.

Unless or until another solution to providing Identity is proposed,
I think it'll be necessary.  Identity is important so 
that the industry can build reliable and useful whitelists, 
blacklists, and reputation systems -- which are all necessary for 
call routing and mitigating spam.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Jul 2007 18:37:38 -0400

Dan,

I just took a look at this. I have a few questions:

1) Because you only sign the selected attributes from the SDP, the rest 
is not secured. That seems like an acceptable restriction if you assume 
there will be a media-terminating SBC in the path.

But what about other body parts? I gather they won't be signed either. 
That seems like a potential problem as we start to identify need for 
various extra body parts.

2) What about "offerless" initial INVITEs?

3) What about messages that don't use SDP at all?

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Jul 2007 12:10:03 -0700

Paul Kyzivat wrote:
> Dan,
> 
> I just took a look at this.

Thanks.

> I have a few questions:
> 
> 1) Because you only sign the selected attributes from the 
> SDP, the rest is not secured. That seems like an acceptable 
> restriction if you assume there will be a media-terminating 
> SBC in the path.
> 

Right.

> That seems like a potential problem as we start to identify 
> need for various extra body parts.

That's a good point, which I hadn't considered.  

The existing SIP-Identity (RFC4474) could be used to sign such
SIP requests, so long as they don't contain any SDP bodyparts
(if they contain SDP bodyparts and RFC4474 signs them, you're
back at the problems with RFC4474 signatures being broken by
SBCs and B2BUAs).  So, this doesn't seem to be ideal.

What I would suggest, and can write up if it sounds sensical,
is to sign each individual non-SDP MIME part.  This would be
accomplished by creating two new SIP headers, "Identity-part",
which contains the Content-IDs of the non-SDP MIME parts
that are signed, and Identity-Part-Signature, which contains
the signature over those parts.

For example, if a SIP UA sent an Invite like this:

  INVITE ...
  From: [email-masked]
  To: [email-masked]
  Content-Type: multipart/mixed; boundary=X
  ...

  --X
  Content-Type: application/sdp
  
  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

  --X
  Content-Type: text/plain

  John, let's talk about the upcoming press release.

  --X--

The authentication service would add the SIP headers described in the
existing -sip-identity-media-00:

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

and I am proposing it would add the missing Content-Id headers (so that each
MIME part can be clearly identified) and two new SIP headers (Identity-Part,
Identity-Part-Signature).  The 
Identity-Part-Signature contains a signature over all of the MIME bodyparts
listed in the Identity-Part header (shown below with "$" on the left-most
column):

  INVITE ...
  From: [email-masked]
  To: [email-masked]
  Content-Type: multipart/mixed; boundary=X
  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="
  Identity-Part: ab111
  Identity-Part-Signature:
       "ncEjfecq2jefmceejcech3233rjfejncecjkeu3fjefje93jnakjjqknenceuHEc
        jfeqcnekueri283jfkjfcnencehutiujfe9383mjfejkequie839283jnecneqce
        q11jfjfkcaqncerEJCEJCMEQMCECEJKEFJEKFjejffke"
  ...

  --X
  Content-Type: application/sdp
  Content-Id: ab000
  
  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

  --X
$ Content-Type: text/plain
$ Content-Id: ab111
$
$ John, let's talk about the upcoming press release.
$
  --X--

Thoughts on this approach?

We might also consider using the authentication service's S/MIME keys (not
the UA's S/MIME keys), which may well be cleaner.

> 3) What about messages that don't use SDP at all?

Both of these situations would be handled in the same way RFC4474
(SIP-Identity) handles them:

For offerless invites, you would rely on Connected-Identity to provide the
assertion of the initiator's identity.

For messages with no SDP, you can sign non-SDP bodyparts (as I describe
above).  If the message has no body to sign, there isn't any magic we can do
using the media path to authenticate the message came from the claimed peer
-- because of course there is no media path.  Both RFC4474 and RFC3893 (AIB)
share this same problem.  When there is no body, all you can do is sign
headers (including the Date: header) in an effort to prevent replay attacks.
This is what SIP-Identity-Media, RFC4474, and RFC3893 (AIB) all do.

-d

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 12 Jul 2007 08:30:56 +0100

Hi,

> > my mail. I think it would be a good idea to take Call-ID out as
well.

I agree with this, but keep in mind that the call-id serves as a nonce
in RFC 4474. It might require introducing a new header/parameter to be
the nonce.

Regards,
Gilad

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Jul 2007 17:44:54 -0700

> > > > was some thought it was necessary, but I agree it should be
> > > > removed from the signature.
> > > >

Thanks for that reminder.  You're right, and I agree that having the
authentication service add its own nonce is the best way to do it; such
a nonce need only be a random number, as it's already qualified by the
authentication service's domain (and certificate).  Thus, SBCs won't
need to also destroy it.  I'll include that in my working revision
to sip-identity-media.

-d

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 13 Jul 2007 21:30:54 +0100

Hmmm... I have seen SBCs out there that remove the authentication header
as well and not all SBCs generate authenticate challenges (for example,
they rely on a softswitch later on to do it). Also, there is the issue
of a change in Nonce in the middle of the call when a new request gets a
challenge with "stale=true".

I'm not sure we can refrain from introducing a new value generated by
the SBC.

> Sent: Friday, July 13, 2007 3:45 AM
> To: Gilad Shaham; 'Hans Persson'
> Cc: [email-masked]; [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 13 Jul 2007 13:43:08 -0700

> Hmmm... I have seen SBCs out there that remove the 

You're referring to the RFC4474 Identity and Identity-Info headers?  Or to
something else?  Yes, I fully believe and expect SBCs and many B2BUAs would
remove those.  There isn't much harm in removing them, though, especially
for an SBC, because the SBC's modification of the SDP's m/c lines will
invalidate the RFC4474 signature anyway.

> as well and not all SBCs generate authenticate challenges 
> (for example, they rely on a softswitch later on to do it).

I don't follow; what do you mean by 'generate authenticate challenge'?

> Also, there is the issue of a change in Nonce in the middle of the 
> call when a new request gets a challenge with "stale=true".

What I intend on doing in the next version is extend Identity-Fingerprints
so it contains the nonce, something like this (highlighted with "<<"):

  ...
  Identity-Fingerprints:
      nonce=1234           <<<<<<<<<<

The contents of the Identity-Fingerprints header (which contains
the nonce generated by the authentication service and the 
a=fingerprint values from the SDP), is signed by the requestor's 
authentication service (if an enterprise, that would typically 
be your enterprise's authentication service; if you're using 
a service provider, it's your SP's authentication service).

-d

> > > > > my mail. I think it would be a good idea to take 
> Call-ID out as
> > > > > well.
> > > >
> > > > Ok, thanks.
> > > >
> > >
> > > in RFC 4474. It might require introducing a new 
> header/parameter to
> be
> > > the nonce.
> >

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 13 Jul 2007 22:04:53 +0100

Sorry, I misinterpreted what you meant in the previous response.  You
can safely ignore my last comment.

> Sent: Friday, July 13, 2007 11:43 PM

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 15:26:34 +0200

Hi Dan, 

>I have removed that in -01 (which isn't yet published, of 
>course).  There was some thought it was necessary, but I 
>agree it should be removed from the signature.
> 
>Oftentimes the Call Id value contains an IP address (in 
>dotted decimal or hex), and an SBC or B2BUA may also want to 
>rewrite such a CallId.  I have made a note of that in -01 so 
>this can be discussed.

An SBC can modify almost any header. Looking at chapter 4.1, I would say
that at least the To- and From headers are in the "risk zone" (EVEN if
you only use the addr-spec part).

The CSeq (at least the digit portion) may also be modified, for example
if there has been some "dialog piggybacked" requests sent between the
SBC and another entity, but not end-to-end. In that case the the SBC may
have to increase the CSeq before forwarding the request, if the digit
portion value has already been used in a request sent by the SBC in the
same direction.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2007 09:17:25 -0700

> An SBC can modify almost any header.

Yes.

> Looking at chapter 4.1, 
> I would say that at least the To- and From headers are in 
> the "risk zone" (EVEN if you only use the addr-spec part).

If the From header is modified, the identity is broken 
anyway.  Such modifications of the From header are discussed
in the Background section of draft-wing-sip-identity-media-00.

Allowing modifications of the To header creates the 
opportunity for an attacker to launch a replay attack by
substituting the To address and replaying the message 
until the Date: header is old enough that receiving 
authentication servers reject the Date: header out of 
hand.

> The CSeq (at least the digit portion) may also be modified, 
> for example if there has been some "dialog piggybacked" requests 
> sent between the SBC and another entity, but not end-to-end. In 
> that case the the SBC may have to increase the CSeq before 
> forwarding the request, if the digit portion value has already 
> been used in a request sent by the SBC in the same direction.

That seems like a good opportunity, within that trust domain 
between the SBC and the other entity, to use 
P-Asserted-Identity.

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 19:21:46 +0200

Hi,

>between the SBC and the other entity, to use

I am not sure I understand. How could the P-A-I header be used instead of the CSeq?

Regards,
 
Christer

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2007 10:40:08 -0700

> used instead of the CSeq?

The SBC that wants to interfere with the CSeq when doing 'dialog
piggybacking' can go ahead and do that.  Doing that will destroy 
the validity of the SIP-Identity-Media signature for the 'dialog 
piggybacked' request.  Because the SBC and the 'other entity' 
(which is receiving the 'dialog piggybacked' message) are both
in the same trust domain, they can use P-A-I between themselves.

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 19 Jul 2007 12:11:28 +0200

Hi, 

>>(two-way, I assume) work? As soon as the UAS has received the INVITE?

A little more on this.

As we have discussed before, you may not have two-way connectivity
before 200 OK.

Now assume that you will have two-way connectivity before you have even
sent the SDP answer. I am pretty sure what will not work with most SBCs.

Also, even if you don't have any SBCs, but you still have NATs, the
calling user often needs to send something in order to open the NAT
binding, and allow media plane traffic (including your identity
exchange) from the remote end. If you use ICE, or stand-alone STUN, you
will have an open NAT binding, but if your terminal opens the network
e.g. by sending dummy RTP packets, it will not be able to do so until it
has received the SDP answer.

So, I also think your solution requires support of ICE/STUN, and in the
case of ICE it also requires that the SBCs don't mess up the SDP so that
ICE will not be used.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2007 10:53:57 -0700

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Thursday, July 19, 2007 3:11 AM
> I am pretty sure what will not work with most SBCs.
>
> Now assume that you will have two-way connectivity before you 
> have even sent the SDP answer. 

I think you meant to say "now assume that you will _not_ ..."?

In the case of no media path, it would only be possible for the
authentication server, and the UA receiving the SIP request, to 
cryptographically validate the SIP headers and a very minor 
portion of the SDP (From:, Date:, and the header that we 
generate that copies the a=fingerprint attributes from the 
SDP, and the few other headers described in 
-wing-sip-identity-media).

This provides some protection against attackers, and works through
SBCs.  Specifically, this protects against attackers who were not
able to obtain a validly-signed SIP request.

However, only validating those SIP headers is inadequate if
an attacker has captured or otherwise acquired a validly-signed 
SIP request, modified the SDP (such that the signature is 
still valid), and re-injected that SIP request into a SIP 
proxy that forwards it to you.  In order to detect such a 
replay attack, you need to perform one of the media-path based 
tests that I describe in wing-sip-identity-media (DTLS-SRTP, 
HIP, ICE, TLS).

> has received the SDP answer.

* But if you haven't received the SDP answer, where are you sending
those dummy RTP packets (what is their destination IP address and 
UDP port)?

* If the NAT perform address-based filtering of incoming packets, 
it drop incoming UDP packets until the device behind the NAT
(the SIP UA, in our case) sends a packet to the IP address sending
the incoming packet.  The SIP UA would learn that IP address upon
receipt of the SDP answer.  Further, if the NAT is doing port
filtering of incoming packets, the SIP UA needs to know the UDP
port the external packet is arriving from, too (which also shows
up in the answer).  I point out the problem with port filtering
NATs because sending dummy UDP packets to the SBC's IP address 
is not sufficient for those kinds of NATs.  Similarly, if the 
NAT is symmetric (assigns a new UDP port for every new 
destination port or destination address the SIP UA sends to), 
sending dummy UDP packets won't be effective for symmetric
NATs, either.

> So, I also think your solution requires support of ICE/STUN, 
> and in the case of ICE it also requires that the SBCs 
> don't mess up the SDP so that ICE will not be used.

No, it does not.

For protection against simple From: spoofing, it is adequate to
simply validate the SIP headers and the signature.  For protection
against replay attacks, it is necessary for both SIP UAs (*) to
implement one of HIP, ICE, DTLS-SRTP, or TLS.  

  (*) The replay attack prevention and implementation of HIP, ICE
      (with the extension described in -wing-sip-identity-media),
      DTLS-SRTP, or TLS can be done by the SIP UA itself _or_ by 
      the SBC associated with the UA's signing domain -- such as 
      the Enterprise's SBC if the enterprise is signing the identity 
      ([email-masked], [email-masked]); or, if the SIP UA's 
      identity is signed by a Service Provider, the SBC operated by
      the service provider).

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 19 Jul 2007 20:08:39 +0200

Hi,
 
>>>>"in order for the mechanism to work, SBC-type-of-entities must 
>>>>permit DTLS, TLS, ICE, or HIP messages to be exchanged in the media 
>>>>path."
>>>> 

>>Now assume that you will have two-way connectivity before you have 
>>even sent the SDP answer.
> 
> 

What I meant to say was: Now you assume that you will have two-way
connectivity before you have even sent the SDP answer :)

>SDP, and the few other headers described in -wing-sip-identity-media).
> 

>>exchange) from the remote end. If you use ICE, or stand-alone 
>>STUN, you will have an open NAT binding, but if your terminal opens 
>>the network e.g. by sending dummy RTP packets, it will not be able to
do 
>>so until it has received the SDP answer.
> 

That is what I am saying: the user needs to get the SDP answer, so that
it can open the NAT binding (and allow incoming traffic)

>iltering of incoming packets, the SIP UA needs to know the UDP

Ok, so let me put it this way: any feature in your solution that, in a
NAT requirement, does require end-to-end connectivity before the SDP
answer has been sent requires at least STUN (not necessarily ICE) - or
some other mechanism which the NAT binding is opened without having the
remote SDP. And, if you use ICE, the SBCs must not modify the SDPs in a
way so that ICE is disabled.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2007 14:19:52 -0700

> connectivity before you have even sent the SDP answer :)

Thanks for clarifying.

This is how we meet our requirement to avoid clipping, and meet
the requirement of RFC3264 to have a bi-directional path for
sendrecv streams:

      "Once the offerer has sent the offer, it MUST be prepared to
      receive media for any recvonly streams described by that offer.
      It MUST be prepared to send and receive media for any sendrecv
      streams in the offer, and send media for any sendonly streams in
      the offer (of course, it cannot actually send until the peer
      provides an answer with the needed address and port information)."

This requirement is captured in section 3.1 and requirement 5 (R5) of 
draft-wing-media-security-requirements-04.txt.

> That is what I am saying: the user needs to get the SDP 
> answer, so that it can open the NAT binding (and allow 
> incoming traffic)

Yes, in cases with certain kinds of NATs which filter, it is 
necessary to receive the SDP answer.  In cases with certain
other kinds of NATs that don't filter (or where there is no
NAT), it isn't necessary to receive the SDP answer.

However, for reasons unrelated to SIP-Identity-Media, it is
important to verify the certificate in the SDP answer matches
the certificate exchanged over DTLS (or TLS, if doing comedia).
Otherwise, an attacker can send a well-timed DTLS ClientHello 
or TLS ClientHello which will fool the endpoint into exchanging
application-layer data (SRTP or TLS-encrypted application data)
with the attacker.  Such an exchange with an attacker is
undesirable.   Thus, to reduce call setup time, it's useful
to perform the DTLS/TLS exchange prior to receiving the SDP
answer.  But it isn't necessary to do so.  Certainly you
don't want to do anything with the data you receive until
you have validated the DTLS/TLS certificate.

> remote SDP. And, if you use ICE, the SBCs must not modify the 
> SDPs in a way so that ICE is disabled.

draft-wing-sip-identity-media does not require end-to-end media 
path connectivity before the SDP answer arrives at the offer.

draft-wing-sip-identity-media provides identity protection in 
two "phases", to handle simple attacks and to handle more 
sophisticated attacks.  The first phase is the SIP header
signing, which is validated entirely without any regard to the
media path.  The second phase uses the media path, and protects
against replay attacks (where an attacker obtained a signed
Invite, for example, and replays it in order to ring your phone
again and appear to be the original caller.)  To protect against
that replay attack, you need to make the caller prove they know
something that only they know.  In sip-identity-media, I am
making the caller prove that he knows the private key associated
with the certificate (TLS, DTLS) or public key (HIP, ICE) that
is going to be used for the TLS, DTLS, or HIP call setup.  If 
he proves he knows that private key, it is safe and reasonable
to display the caller id.  If he can't prove that, he is an 
imposter.  If he refuses to prove that (or the media path is
blocked), you run the risk that -- after the media path is 
opened -- you will do the DTLS/HIP/TLS/ICE exchange and at
that time you will discover the user is an imposter.  That
discovery will occur after the phone has been rung and 
answered.  To me, that is a poor time to discover an 
imposter.  It's better than what we have today, though, so
I guess it _is_ forward progress and I could live with an
implementation that discovered an imposter after the phone
is answered.  It is certainly better than what we have 
today.  If such imposters become commonplace, users will
complain to their network providers about the middle-of-the-
night call alerting, phone answering, and attendant "Whoops,
sorry, that was an imposter.  We will send him a big fat
bill.  Please resume sleeping" messages displayed on their
handsets.

-d

---

From: "Robins, Ellen" <[email-masked]>
Date: Tue, 31 Jul 2007 15:42:22 +1000

Dear all,
Please help to confirm which bandwidth parameter shall be used by Video
Terminal Client for a SIP Client to SIP Client call case, i.e. between 2
parties not a three-way conference.

   Bandwidth

   b=<modifier>:<bandwidth-value>

   o This specifies the proposed bandwidth to be used by the session or
     media, and is optional.

   o <bandwidth-value> is in kilobits per second

   o <modifier> is a single alphanumeric word giving the meaning of the
     bandwidth figure.

   o Two modifiers are initially defined:

   CT Conference Total: An implicit maximum bandwidth is associated with
     each TTL on the Mbone or within a particular multicast
     administrative scope region (the Mbone bandwidth vs. TTL limits are
     given in the MBone FAQ). If the bandwidth of a session or media in
     a session is different from the bandwidth implicit from the scope,
     a `b=CT:...' line should be supplied for the session giving the
     proposed upper limit to the bandwidth used. The primary purpose of
     this is to give an approximate idea as to whether two or more
     conferences can co-exist simultaneously.

   AS Application-Specific Maximum: The bandwidth is interpreted to be
     application-specific, i.e., will be the application's concept of
     maximum bandwidth.  Normally this will coincide with what is set on
     the application's "maximum bandwidth" control if applicable.

     Note that CT gives a total bandwidth figure for all the media at
     all sites.  AS gives a bandwidth figure for a single media at a
     single site, although there may be many sites sending
     simultaneously.

Thanks and kind regards / Ellen Robins
ViG Technology Manager
Services Enablers
Wireless Engineering & Operations
Telstra Operations
Telstra Corporation Limited
  
Ph 03 8627 8981
Mob 0428 309 250
Fax 03 9620 7864
Mail [email-masked] 

The information contained in this email message may be confidential. If
you are not the intended recipient, any use of, interference with,
disclosure or copying of this material is unauthorised and prohibited.
If you have received this message in error, please notify me by reply
email and then delete the message.