Subject: [Sip] Comments on draft-wing-sip-identity-media-01

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Nov 2007 17:29:30 -0800

$Id: draft-wing-sip-identity-media-01-rev.txt,v 1.1 2007/11/28 01:26:28 ekr Exp $

This draft seems to do two distinct things:

- One specify a variant of RFC 4474 which signs a lot fewer headers.
- Specify a set of mechanisms to cryptographically prove that a given media
  stream corresponds to a given SDP offer/answer.

As I understand it, the rationale for the first of these is that
SBCs will break RFC 4474 signatures and won't have the public
keys required to generate new ones. I'm not really a SIP expert,
but I thought that the party line was the SBCs were B2BUAs
and so whatever the identity of the SBC was was the UAC,
so if that SBC doesn't have the right credentials to sign
an RFC 4474 identity for "[email-masked]" then it shouldn't
be attesting to it. But again, I could be totally misunderstanding
3261, etc.

That said, as I read S 3.1.3, the SBC signs
"[email-masked]". I don't really understand
what the recipient of such an identity is to make of this,
since surely we wouldn't want anyone to be able to attest
to other people's identities like this. So, this means
that the relying party needs to have some list of the
form "the following SBC cert can sign for the following 
domains". How does this get communicated? Is this really
easier than giving the SBC the private key?

With regard to the second issue, I agree this is important,
but this is an orthogonal issue to which headers get signed,
right? In general, we certainly do want a way to tie media
to keying cryptographically, but as you note, DTLS-SRTP
already provides this. I don't quite see why you *always*
need this proof. What about requests that don't come
with media? Anyway, are you claiming this is also a problem
for RFC 4474?

-Ekr

_______________________________________________
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: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Nov 2007 07:07:29 -0500

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2007 8:30 PM
>

Yup, and thereby increase its chance of success.

>   stream corresponds to a given SDP offer/answer.

Yup, but it may need this second part to compensate for the first part. (for some cases)

> be attesting to it. But again, I could be totally misunderstanding

Yeah so this is going to go into a big black hole methinks, and like all good black holes, trying to shed light on it won't make things clearer. :)  I mean we would get into some philosophical debate about the meaning of "identity" and what "attesting to it" means.

I don't think we need to talk about this in the context of B2BUA's and the identity they do or don't represent, though.  Maybe we can just talk about the draft's mechanism as being palatable or not based on whether it addresses the same issues 4474 did, with similar benefits, in a reasonably secure a fashion, albeit in a different way?

So for example, comparing this mechanism to 4474, is it as legit?  What additional weaknesses does it create, and are they untenable? (I can think of a few, mostly MITM related of course)

> easier than giving the SBC the private key?

Actually that example was meant to demonstrate the unpalatable way to address the problem without this draft.  In other words, it's a "this is how crazy 4474 would become" type thing.  It wasn't about how the draft's proposed mechanism would work, nor how 4474 should work.  :)

> right?

I'll leave that to Dan, but I think you need this second issue addressed to explain why not signing the c=/m= is ok.

> In general, we certainly do want a way to tie media

You mean offer-less Invites?  Yes, that's already a problem for 4474.  If you mean for non-SDP requests (e.g., MESSAGE or SUB/NOT), the mechanism in this draft would sign that whole MIME body as 4474 did, except still sign fewer headers.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2007 08:37:03 -0500

> Yeah so this is going to go into a big black hole methinks, and like all good black holes, trying to shed light on it won't make things clearer. :)  I mean we would get into some philosophical deba…

I hope that isn't a black hole, because I think those issued *need* to 
be worked out.

This is like the elephant in the living room that nobody is willing to 
mention.

There may indeed be value in signing a set of headers that can survive 
passing through an SBC. But the pros and cons of that need to be discussed.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 10:09:18 -0800

...
> I'll leave that to Dan, but I think you need this second 
> issue addressed to explain why not signing the c=/m= is ok.

RFC4474 signs the SIP body (containing the SDP and 
containing the c=/m= lines) because RFC4474 ties the IP 
address and UDP port to the identifier (From: [email-masked]).

SIP-Identity-Media doesn't use the IP address and UDP port
as the identifier.  SIP-Identity-Media uses the DTLS-SRTP 
certificate as the identifier (or HIP, or an ICE extension,
or TLS).

> You mean offer-less Invites?  Yes, that's already a problem 
> for 4474. 

Right.  

(Perhaps sip-connected-identity can help with offerless 
Invites; I don't know.)

> If you mean for non-SDP requests (e.g., MESSAGE or 
> SUB/NOT), the mechanism in this draft would sign that whole 
> MIME body as 4474 did, except still sign fewer headers.

Right; this was a problem Paul Kyzivat pointed out in his
review of sip-identity-media-00.  sip-identity-media-01 will
sign the non-SDP body parts.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 10:14:43 -0800

...
> There may indeed be value in signing a set of headers that 
> can survive passing through an SBC. But the pros and cons 
> of that need to be discussed.

With SBCs, RFC4474 requires the SBC to create a new identity
and sign that.  sip-identity-media shows how this would work
with E.164s (it works alright if each hop is entrusted to 
validate and then re-sign the E.164 address with their own domain 
name) and how this would work with email-style addresses (it 
doesn't work at all).

Before we talk about SIP headers I think we need to decide if:

  *  re-creating E.164 identities at each hop okay

  *  we need email-style SIP identities to survive through SBCs?

as this is how RFC4474 operates with today's SBCs.

(Please see draft-wing-sip-identity-media-01, section 3, for
details.)

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 10:22:53 -0800

At Wed, 28 Nov 2007 10:09:18 -0800,
> address and UDP port to the identifier (From: [email-masked]).

Hmm... That's necessarily a pretty weak binding compared
to the digital signature, right? 

> certificate as the identifier (or HIP, or an ICE extension,

Sorry, I'm still not getting why this is necessary.

I get an INVITE and then I establish an RTP stream. If I care about
data origin authentication for the media , I should be using SRTP.
If I'm not, then I don't care much. That's true with both this
draft and RFC 4474. I still don't understand why this draft
always needs a cryptographic identity proof and RFC 4474 does 
not.

-Ekr

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Nov 2007 20:35:07 +0000

Ekr,

The point is, the Wing draft only helps if media is secured with SRTP.
The Identity-Media header field basically signs the fingerprint of the
UA certificate that will be used to negotiate the key for SRTP. So if
the Identity-Media header field provides cryptographic evidence that the
remote party is [email-masked], then any SRTP using a key derived
from the certificate whose fingerprint is signed by the Identity-Media
header field must be from [email-masked] (assuming you trust the
example.com domain - an assumption applicable equally to RFC 4474 and
Identity-Media).

John 

> Sent: 28 November 2007 18:23
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 13:19:06 -0800

At Wed, 28 Nov 2007 20:35:07 +0000,
> example.com domain - an assumption applicable equally to RFC 4474 and

But it seems to me that the same argument applies to RFC 4474, right?

I.e., the semantics of 4474 are: Here is a bunch of message data
sent by X. The semantics of Identity-media are: here is somewhat
less message data sent by X. Why does one need a proof of identity
and the other not?

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 14:51:32 -0800

> to the digital signature, right? 

I concur.
 
> always needs a cryptographic identity proof and RFC 4474 does 

Because SIP-Identity-Media is validating the identity of the
remote party, by making the remote party prove it knows the
private key associated with its DTLS/TLS certificate or
ICE/HIP public key.

RFC4474 doesn't.  RFC4474 only requires symmetric RTP, and 
only requires RTP packets arrive from the same IP address 
and UDP port as signed by RFC4474.  It is using the source
IP address to provide the identity.  With SBCs, which are
continually modifying the source IP address (when they
rewrite the m/c lines), you can only get a signature from
the closest SBC.  Which means you're trusting it.  It
trusted the SBC one hop away, which trusted the SBC the
next hop away, and so on, until we finally get back to
the real user agent that generated in the Invite.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 14:55:27 -0800

> sent by X.

RFC4474 also says that any RTP packets with the source address
in the RFC4474-signed SDP is from X.

> The semantics of Identity-media are: here is somewhat
> less message data sent by X.

Identity-Media also says that you can do a DTLS-SRTP, TLS,
HIP, or ICE (with extensions) handshake with the source address
in the SDP, and you can validate the certificate (or public
key) exchanged in that DTLS-SRTP/TLS/HIP/ICE exchange matches
the Identity-Media-signed a=fingerprint of X.

> Why does one need a proof of identity and the other not?

RFC4474 uses source transport address for proof of identity.
Identity-Media uses certificates (DTLS-SRTP/TLS) or public
keys (HIP/ICE).  

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 15:13:11 -0800

At Wed, 28 Nov 2007 14:55:27 -0800,
> in the RFC4474-signed SDP is from X.

Does it?

That's not my reading of the claimed security guarantees
offered by RFC 4474. Rather, I read them as saying
"whatever is in this message was said by the person
in whose name it was signed". Any conclusions one draws
after that seem separate to me. You could do something
useful with RFC 4474 even if no media was ever sent.

Indeed, when I read RFC 4474, you can use it for requests
which don't contain SDP at all, such as OPT. Am I just
smoking crack here?

> Identity-Media uses certificates (DTLS-SRTP/TLS) or public

Well, I understand that that's what you're doing. My point
is that i think that whether this service is valuable is
an independent question of whether one should trim the
set of headers and body values that gets signed.

I.e., if we think it's important to provide a cryptographic
binding of a media stream independent of SRTP (and I'm still
trying to work out what the semantics of that would be),
then we should do that in a way that's equally applicable to
RFC 4474.

But maybe I'm just confused.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 15:31:42 -0800

> useful with RFC 4474 even if no media was ever sent.

Sure.  But that would be silly.  Why would you go through
the effort of validating an RFC4474 signature, only to 
then accept RTP packets willy-nilly from some different
IP address and UDP port?

> which don't contain SDP at all, such as OPT. Am I just

You are correct, RFC4474 signs the body no matter what the
body contains.  I don't know what OPT is.

Identity-Media signs non-SDP bodies, too.
 
> trying to work out what the semantics of that would be),

My goal was not to create a cryptographic binding.  Rather,
that's the solution I came up with.  My goal was to allow 
"From: [email-masked]" to persist across SBCs, which RFC4474 
doesn't allow.

> then we should do that in a way that's equally applicable to

I don't know how to accomplish that with SBCs, other than
via my proposal.

> But maybe I'm just confused.

Email and a 10 minute presentation in SIP might not be the 
best way to explain things, too.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 16:10:50 -0800

At Wed, 28 Nov 2007 15:31:42 -0800,
> then accept RTP packets willy-nilly from some different

Well, that's not quite what I meant. 

Let me try to work through my reasoning, so we can see where
we disagree. 

The general purpose of RFC 4744 is to give the UAS confidence
that whatever requests it received came from the claimed
UAC. What it does with that information then depends on the
request type.

Let's not talk about INVITE for a second, but rather
BYE. Alice and Bob have a phone call in progress and Alice
sends Bob a BYE. Now, in order to avoid DoS attacks where
the attacker terminates connections in progress, Bob wants
Alice's BYE to have an RFC 4474 Identity and will reject
it without. Note that in this case, there's no requirement
to correlate anything with an RTP stream, and in fact
Alice may not send any RTP data after sending the BYE.
Bob just verifies it and shuts down the call. Do we agree
so far?

Now, let's address INVITE. Bob gets an RFC 4474 INVITE with
an SDP and before he's done anything else, he knows that
Alice wants to talk to him. Or rather, Bob's UAS does.
His phone starts ringing and Alice's name shows up in his
caller-id display. So, RFC 4474 has added value even before
we've received the first RTP packet. 

Assuming Bob decides to answer, his UAS sends an SDP answer to
Alice. If ICE isn't in play, then he's expecting to receive packets at
the address he specified in his answer, and if it's symmetric RTP,
then from Alice's claimed address.  And yes, I agree, that then he
should reject packets from other addresses, but I don't think that's
the same as saying that packets from that address *are* from Alice.
If you want that service, you need to use cryptography. 

> body contains.  I don't know what OPT is.

My bad, OPTION.

> Identity-Media signs non-SDP bodies, too.

Agreed. 

> "From: [email-masked]" to persist across SBCs, which RFC4474 

Right. But it seems to me that that goal is accomplished
simply by trimming the list of headers and SDP lines which
are signed and that the cryptographic binding solves something
different.

> best way to explain things, too.

Quite probably.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2007 17:03:18 -0800

> Bob just verifies it and shuts down the call. Do we agree

Agreed, RFC4474 provides additional protection for a BYE.

(RFC3261 section 15.1.2 requires the dialog of the BYE 
matches the dialog of the INVITE, which means an attacker
already needs to have collected the Call-ID, local tag,
and remote tag from the INVITE).

> If you want that service, you need to use cryptography. 

Ok.
 
> are signed and that the cryptographic binding solves something

This gets to 'why' RFC4474 decided to sign the SDP.  The
authors and SIP WG participants that decided on this might be 
able to better explain than me -- I wasn't involved in it.

But from my current understanding, it RFC4474 signs the
body to provide additional replay attack protection.  
Specifically, if an attacker could get a valid, signed Invite
from a victim, the attacker could replay it.  By including 
the SDP in the RFC4474 signature, the attacker would also 
need to obtain the same IP address and UDP port as the 
victim.  This is considered difficult to obtain; however, 
with NAPTs and TURN, it may be easier than hoped.  RFC4474
was also devised before Security Descriptions (RFC4568) or 
key-mgmt (RFC4567) were available, and certainly long 
before DTLS-SRTP.  At the time RFC4474 was written, the
signing the SDP to provide additional replay protection 
made good sense.  

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Nov 2007 03:38:39 -0500

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2007 8:03 PM
>

There was an email exchange and discussion in San Diego on this when Jonathan's identity-coexistence draft came out.
I believe the argument was it prevents a SIP MITM from very easily becoming a media MITM (or an end) by simply changing the m=/c= lines.  In other words it's better than not signing the SDP.

There was strong fear that allowing MITM to change m=/c= lines is significantly less secure than not, under the assumption that it's much harder to become a media MITM otherwise.  I agree with that sentiment in general I guess, though I personally think the value of identity signing is in From impersonation prevention, not media MITM prevention.  And I think if the extra signing fails the request then this thing won't be used and it loses any value. (The counter-argument was in such a case it really should fail or else it has no value)

> from a victim, the attacker could replay it.
[...snip]
> At the time RFC4474 was written, the

You don't need to sign the body to prevent replay - just 4474's signing of the SIP headers: To+From, Date, call-id and CSeq makes replay highly improbable.  It's one of the things that worries me a little about identity-media not signing the call-id and cseq.  It allows replay during the Date's window, against the same target.  So we said in section 8 that since the DTLS fingerprint is signed, then replaying isn't actually very useful anyway.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Nov 2007 03:55:06 -0500

> Sent: Wednesday, November 28, 2007 7:11 PM
>

Yes, and I agree identity-media would provide that same value, even if the SDP contained no DTLS and SRTP wasn't used at all.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Nov 2007 05:20:43 -0500

> Sent: Wednesday, November 28, 2007 6:32 PM
>

A minor note that only accepting RTP packets from the address in the signed SDP does not do much to stop a SIP MITM from easily becoming a media MITM, for at least one side.

Assume the following call flow:

          A                   B                   C
          |(1) INVITE         |                   |
          |(SDP c/m=A)        |                   |
          |------------------>|                   |
          |                   |(2) INVITE         |
          |                   |(SDP c/m=A)        |
          |                   |------------------>|
          |                   |           (3) 200 |
          |                   |        (SDP c/m=C)|
          |                   |<------------------|
          |           (4) 200 |                   |
          |        (SDP c/m=B)|                   |
          |<------------------|                   |
          |(5) ACK            |(6) ACK            |
          |------------------>|------------------>|
          |                   |                   |
          | Media A->B        | Media 'A'->C      |
          |..................>|..................>|
          |                   |                   |
          |        Media B->A |                   |
          |<..................|        Media C->A |
          |X<.....................................|

A sent a signed Invite through B to C.  B couldn't change it, but can easily change the 200 response's SDP.  So A ends up thinking B is the called party. When C sends media direct to A, A will ignore it for the reason you said and render B's media instead.  Meanwhile A also sends media to B, not C, leaving B free to send source-spoofed RTP to C and it's able to do that because it was able to read A's signed Invite and thus knows what to spoof with. (assuming no uRPF checking routers block such)

Of course B may have a hard time getting hold of C's media, but for spam purposes all that has to happen is for B to successfully get its media to be rendered by C.

And what's more, connected-identity RFC4916 does not stop this; if A is Alice calling C for Citibank, and B the Bad-guy in the middle, Citibank will send a signed UPDATE without SDP to Alice, and the Bad-guy can do the above attack and end up being the one talking to Alice.  Even if Citibank hangs up due to lack of media, Bad-guy will simply block the Bye and keep talking to Alice.

This isn't a biggie - just pointing out that 4474+4916 ain't perfect for MITM protection, even with SDP signing.  (It's really unfortunate responses couldn't be signed)

-hadriel