Subject: RE: [MMUSIC] Question on sdp-new

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Oct 2005 15:26:01 +0100

Mark,

Thanks, but if I remember correctly, Cullen's document was to do with
different body types in a SIP message, e.g., S/MIME or MIME versions of the
same body or SDP and SDPng. I don't think it extended to different options
within the same body type.

John 

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]] 
> Sent: 13 October 2005 14:00
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Question on sdp-new
> 
> We should consider whether we want to standardize SRTP 
> inter-operation 
> with legacy RTP systems.  I recall reading a draft from 
> Cullen Jennings 
> that addressed this problem in SIP signaling using a 
> multipart/alternative MIME encoding of a SIP message.  This 
> reduces the 
> problem to the legacy RTP systems that also don't recognize 
> mulitipart-alternative SIP messages.  Cullen should correct me if my 
> summary is wrong.
> 
> Mark
> On Oct 13, 2005, at 4:10 AM, Elwell, John wrote:
> 
> > Would the following SDP be legal?
> >
> >    v=...
> >    o=...
> >    s=...
> >    c=...
> >    t=...
> >    m=audio 62986 RTP/SAVP 0 4 18
> >    a=rtpmap:0 PCMU/8000
> >    a=rtpmap:4 G723/8000
> >    a=rtpmap:18 G729/8000
> >    a=key-mgmt:.....
> >    m=audio 62986 RTP/AVP 0 4 18
> >    a=rtpmap:0 PCMU/8000
> >    a=rtpmap:4 G723/8000
> >    a=rtpmap:18 G729/8000
> >
> > Note that the two media have the same port and thus the 
> same transport
> > address. In 6.15 of sdp-new there is a list of conditions 
> in which two 
> > media
> > may use the same transport address. It is not clear to me whether 
> > condition
> > 3 is violated: "If two media sessions have the same 
> transport address, 
> > they
> > SHOULD operate under the same RTP profile.  The sessions MAY use two
> > different RTP profiles only if those profiles are specifically 
> > designed to
> > be compatible."
> >
> > Do the different transports (RTP/SAVP and RTP/AVP) constitute 
> > different RTP
> > profiles? If so, can we regard the two protocols as "designed to be
> > compatible"? Note that in a SIP context, if an SDP offer 
> contains the 
> > code
> > above, the offerer would need to be prepared to receive 
> either SRTP or 
> > RTP
> > on the same port until the SDP answer arrives, perhaps using the
> > authentication tag to distinguish SRTP from RTP.
> >
> > This form of SDP seems to be useful where the offerer is 
> prepared to 
> > accept
> > either SRTP or RTP (perhaps indicating to the user whether the 
> > resulting
> > audio is secure). By using the same transport address the answerer 
> > should
> > treat the two media as alternatives and presumably should 
> reject one of
> > them. By using two different transport addresses the media would be 
> > treated
> > separately and the answerer might accept both, which might 
> not be what 
> > is
> > wanted.
> >
> > Some clarification on this in the next version might be 
> useful (I note 
> > that
> > some comments have been raised so presumably a next version will be 
> > produced
> > at some stage).
> >
> > The problem of distinguishing between RTP and SRTP on the same port 
> > (or even
> > between different SRTP streams on the same port that use different 
> > keys as a
> > result of using different key management methods) could possibly be 
> > worked
> > around by assigning different payload type numbers, e.g.:
> >
> >    v=...
> >    o=...
> >    s=...
> >    c=...
> >    t=...
> >    m=audio 62986 RTP/SAVP 0 4 18
> >    a=rtpmap:0 PCMU/8000
> >    a=rtpmap:4 G723/8000
> >    a=rtpmap:18 G729/8000
> >    a=key-mgmt:.....
> >    m=audio 62986 RTP/AVP 97 98 99
> >    a=rtpmap:97 PCMU/8000
> >    a=rtpmap:98 G723/8000
> >    a=rtpmap:99 G729/8000
> >
> > However, I am not sure whether this would violate the 
> conditions for 
> > using
> > the same transport address. Also I am not sure of the 
> legality of using
> > dynamic payload numbers for encodings for which static 
> payload numbers 
> > exist
> > or whether this would be supported by products in the field.
> >
> > John
> >
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2005 11:07:35 -0400

> within the same body type.

No, it didn't. But the proposal was to have two different SDP bodies, 
one offering RTP and the other offering SRTP. We came to the conclusion 
that two bodies are needed because the SRPT offer/answer needs to be 
protected with S/MIME, and one can probably expect a UA that supports 
SRTP to support S/MIME. But you probably shouldn't expect all UAs to 
support S/MIME.

	Paul

---

From: Mats Näslund <[email-masked]>
Date: Fri, 14 Oct 2005 09:26:54 +0200

Hi,

Jumping in late here, sorry.

> SRTP to support S/MIME. But you probably shouldn't expect all UAs to 

It seems to me that it is not (only) the SRTP offer that needs to be
protected, but rather the combination of the two RTP/SRTP offers. If
this is not done, a "man in the middle" simply deletes the SRTP-part
(be it protected or not), leaving only plain RTP. This would be
a so-called bidding down attack.

Also, for terminals currently not supporting S/MIME one could consider
to instead implement MIKEY which would enable e2e protection
(together with the key mgmt extensions, even of multiple offers).

Best,

/Mats

>>> From: Mark Baugher [mailto:[email-masked]] Sent: 13 October 2005 
>>> 14:00
>>> To: Elwell, John
>>> Cc: [email-masked]; [email-masked]; [email-masked]; 
>>> [email-masked]
>>> inter-operation with legacy RTP systems.  I recall reading a draft 
>>> from Cullen Jennings that addressed this problem in SIP signaling 
>>> using a multipart/alternative MIME encoding of a SIP message.  This 
>>> reduces the problem to the legacy RTP systems that also don't 
>>> recognize mulitipart-alternative SIP messages.  Cullen should correct 
>>> me if my summary is wrong.
>>>
>>> Mark

-- 
--------------------------------------
Mats Näslund, PhD, Senior Specialist
Communications Security Lab
Ericsson Research
SE-16480 Stockholm, Sweden
Visiting adr: Torshamnsgatan 23, Kista
Phone/Fax: (+46 8) 58533739/4047020

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 09:10:49 -0400

Mats Näslund wrote:
>> one offering RTP and the other offering SRTP. We came to the 
>> conclusion that two bodies are needed because the SRPT offer/answer 
>> needs to be protected with S/MIME, and one can probably expect a UA 
>> that supports SRTP to support S/MIME. But you probably shouldn't 
>> expect all UAs to support S/MIME.
> 

The MiTM attack is considered an unavoidable consequence here, and one 
that is in some cases acceptable. The general situation is that X is 
calling Y. X has the capability for a secure media session, but doesn't 
know if Y does. X would like to have a secured conversation with Y, but 
if that is not possible, X would prefer an insecure conversation to no 
conversation.

Once the session is established, X and Y can tell if it is secure. (The 
"secure" indicator will light up on the phone.) So X and Y can adjust 
the contents of their conversation based on the security of the session. 
(X says: "Y - please call me back from a secure phone".)

A suficiently powerful MiTM can perhaps prevent a secure connection from 
ever being formed. But X and Y will be able to figure out that this is 
happening.

> (together with the key mgmt extensions, even of multiple offers).

As I understand it, this requires a security infrastructure that may not 
be available in many environments. I gather (and I am not an expert on 
this) that an advantage of sdescriptions is that it only requires 
special capabilities in the endpoints.

	Paul

>>>> recognize mulitipart-alternative SIP messages.  Cullen should 
>>>> correct me if my summary is wrong.
>>>>
>>>> Mark

---

From: Mats Näslund <[email-masked]>
Date: Fri, 14 Oct 2005 16:07:33 +0200

Hi Paul,

> know if Y does. X would like to have a secured conversation with Y, but

It seems to me X must at least have some "clue". Hoping to establish a
secure connection it seems X would need some "key" associated with Y.
Otherwise, there can't even be a hope of getting security. So, the
setting would be that X has (somehow) obtained a key associated with Y,
but has no idea what Y uses it for (or does not know if Y is able to use
it).

I guess the last (...) part is the most realistic scenario.

I am mainly asking if this situation is common enough to imply a
mechanism that has security issues, I'm not capable of judging
myself, so I guess I'll trust you if you say "yes".

> "secure" indicator will light up on the phone.) So X and Y can adjust

Yes, but if the light does not go "on", they will bascially not
know if they *could* have gotten security. If X can't be sure if Y
has SRTP or not, then it seems that Y cannot know if X was able
to offer security in the first place either.

> (X says: "Y - please call me back from a secure phone".)

The reason security works in GSM/UMTS/... etc is beacuse it is
"automatic". IMO, we shouldn't assume the *average* user is aware
or skilled enough to ask for a secure connection if he isn't even
sure if one could have been created.

> ever being formed. But X and Y will be able to figure out that this is

Aware and skilled users, sure...

Unfortunately, the trend today is to blindly click "accept" to all
security warnings...

> special capabilities in the endpoints.

Yes, but S/MIME also requires some sort of security infrastructure (PKI,
shared keys, etc), otherwise (some form of) man-in-the-middle is always
possible.

I am not saying alternatives aren't useful, I only wanted to raise
a "warning flag" that I didn't see was being discussed.

Cheers,

/Mats

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 10:55:02 -0400

> but has no idea what Y uses it for (or does not know if Y is able to use

No, it doesn't require that. X just does the signaling indicating its 
willingness to have a secure session. If all goes well, X ends up with a 
secure session with whoever it is that was reached, whether that is who 
X intended to call or not. The S/MIME may provide some indication of who 
that is, but there is no guarantee that it is anybody that X knows.

> myself, so I guess I'll trust you if you say "yes".

I am not a security expert, so don't trust me on security issues. I have 
been interested in this mostly with regard to the offer/answer 
mechanisms employed.

> to offer security in the first place either.

There are limits of what can be determined in general. But in practical 
cases I think this isn't a problem.

If Y is a stranger to X, then the situation is pretty grim. But then 
they must have pretty low expectations. If X and Y know each other then 
X may well know that Y has secure capabilities, at least sometimes. It 
may be possible to discuss the situation and compare notes even over an 
insecure line. If X and Y can determine that they are both using devices 
that *should* be capable of a secure call, and yet they are not getting 
a secure call, then they can conclude that someone is tampering.

> sure if one could have been created.

You say this, but only the "half call" is secure. If the other half goes 
someplace that is not secure, the call is not secure. When you call a 
PSTN phone from a GSM phone, somebody can still be tapping the twisted 
pair at the other end.

People will adapt to what is available. If when they buy the phone, it 
comes with a "secure" light, they will figure out what that means, if 
they care. Presumably it would be sold as a feature. It may be that the 
phone always *offers* the secure option, so it is only necessary to 
understand the light.

If all endpoints had secure media capability then we wouldn't be talking 
about this. It is precisely because they don't that it is an issue. That 
means not all calls are secure, so it becomes something a user needs to 
understand, to some extent.

	Paul

---

From: Mats Näslund <[email-masked]>
Date: Fri, 14 Oct 2005 20:50:52 +0200

> that is, but there is no guarantee that it is anybody that X knows.

OK, I think I see what you mean now. You are only concerned with
getting so-called "opportunistic" security (?)

I agree that non-authenticated set-up of SRTP will result in
this: X establishes security with "someone". And even if X establishes
security with Y, it could be that all traffic between them is
readable and modifiable by a man in the middle. (Typical
result of non-authenticated Diffie-Hellman.)

So, besides the fact that X will not know who is is talking to,
there's still the possibility that the SAVP is "peeled off"
by an attacker. So, IMHO, the result of all this *could*
be that

* if X,Y does end up using SAVP, there's no guarantee that X is
   talking to Y, and,

* even if Y really is Y, *and* supports SAVP, they may still end
   up using AVP.

To return to my original recommendation:

If the AVP and SAVP offer are protected together in "bundle" (by S/MIME,
or MIKEY, or what have you), then we can at least exclude the second
case. So even if X doesn't care if Y is Y or not, at least there's no
"bidding down" with this approach.

> been interested in this mostly with regard to the offer/answer 

I think I understand the use-case now, but I have to say that X
really has to keep his fingers crossed...

> If Y is a stranger to X, then the situation is pretty grim. But then 

Well, they typically need a trusted third party in this case.

>>> (X says: "Y - please call me back from a secure phone".)

In the man-in-the-middle scenario (that we seem to agree is possible),
it is pretty clear that this MITM can sit between X and Y and can
change "Y - please call me back from a secure phone" into whatever,
e.g. "I have no secure phone".

> You say this, but only the "half call" is secure. If the other half goes

Yes, but it's the "easy-listening" half. With a link that is very
prune to eavesdropping it would make very little sense to leave
to the average user detect if he is at risk and to also expect
him to act properly. How should we classify "the Internet" in this
regard?

> understand, to some extent.

I agree fully here. Opportunistic security is better than no security,
but my original remark remains: the AVP and SAVP offers SHOULD be
bundled and protected together. At least, it removes one vulnerability.

/Mats

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 15:16:12 -0400

Mats Näslund wrote:
>> willingness to have a secure session. If all goes well, X ends up with 
>> a secure session with whoever it is that was reached, whether that is 
>> who X intended to call or not. The S/MIME may provide some indication 
>> of who that is, but there is no guarantee that it is anybody that X 
>> knows.
> 
> 

I think opportunistic security would be a huge improvement over the 
current state of affairs, and may be more achievable than "better" security.

For those that want more, the call can be made with just the secure part 
of the offer. I can see some people (e.g. the President) who might 
prefer no call to an insecure call. But personally I would be happy to 
just get an indicator of whether I have a secure call or not.

> result of non-authenticated Diffie-Hellman.)

I think not. If the secure session is successfully established, then 
because of the S/MIME, X knows that it is talking to whoever is 
identified by the smime. The MiTM can't read or modify.

So X is securely talking to whoever it is that answered the call.

> "bidding down" with this approach.

Yes, this is true - this is more secure. But it means that you can only 
call those who support the securing of the bundle. If everybody does, 
then this is fine.

So this really comes down to what we can expect "everybody" to support.

You could just use SIPS for signaling, and trust everybody in the 
middle, and then the AVP and SAVP can both be offered without any added 
protection. But I don't think SIPS is universally supported either.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2005 16:18:48 -0700

> a so-called bidding down attack.

The only techniques to protect against that are to (a) S/MIME protect
the entire SIP body (that is, both the RTP and the SRTP offers), or 
(2) sip-identity protect the entire SIP body.  S/MIME protecting both
the RTP and SRTP offers is almost nonsensical, leaving us with 
sip-identity.

> (together with the key mgmt extensions, even of multiple offers).

MIKEY doesn't protect against the bid-down from SRTP to RTP that you
described in your first paragraph.

-d

---

From: Randell Jesup <[email-masked]>
Date: 15 Oct 2005 00:31:50 -0400

>the entire SIP body (that is, both the RTP and the SRTP offers), or 

        Protecting the entire body with S/MIME avoids modifications - but
doesn't avoid MITM B2BUA attacks, unless you have some form of
PKI/cert/identity in place or have some other way of authenticating the
other end.  (And a side-effect, complicates the ability to insert RTP
proxies to deal with firewalls or to use SBC's.  Not that everyone thinks
this is a bad idea. :-) And there still are ways to allow a proxy/SBC to
insert itself by adding a new part (multipart) without compromising
security.)

        In fact, this is what Zimmerman's new protocol (and his original
PGPhone) was designed for - a way to detect a B2BUA MITM attack by passing
very-hard-to-spoof identity data in the media channel.  PGPhone did this by
having users read a few words selected using a hash of the DH data.
Possible to spoof in theory, but hard.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Mats Näslund <[email-masked]>
Date: Sat, 15 Oct 2005 19:38:58 +0200

> the RTP and SRTP offers is almost nonsensical, leaving us with 

Maybe I was knocking down open doors, but I only reacted against
the statement that only the SAVP part was going to be protected,
raising a general "security warning".

I don't think I ever said S/MIME was the proper way to solve it,
at least I didn't mean to imply that.

> described in your first paragraph.

I was unclear, sorry: MIKEY will protect a batch of multiple
MIKEY offers, making it impossible to "strip" a stronger offer,
leaving only weaker ones. For instance, one of the offers might
be SRTP with "NULL" encryption. In principle I belive it would be
possible to extend the mechanism to also protect any possible AVP
offers together with the SAVP offers. Of course, it only works
for clients supporting MIKEY, just as S/MIME protecton only
works for clients supporting S/MIME.

/Mats

---

From: Mark Baugher <[email-masked]>
Date: Mon, 17 Oct 2005 12:46:43 -0700

> the RTP and SRTP offers is almost nonsensical, leaving us with

And what do you do with legacy endpoints that don't support 
sip-identity?

Mark

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Oct 2005 16:20:13 -0700

> And what do you do with legacy endpoints that don't support 

You can pretend such endpoints support RFC3261's S/MIME.  However,
there aren't any endpoints on the market -- to my knowledge -- which
do.  So there isn't a 'legacy' of endpoints that can be protected
from this attack, as neither S/MIME nor -sip-identity- are deployed.

-d

---

From: Mark Baugher <[email-masked]>
Date: Mon, 17 Oct 2005 16:41:45 -0700

> from this attack, as neither S/MIME nor -sip-identity- are deployed.

What is the advantage of sip-identity over s/mime for the problem  
that we are discussing on this thread?  I understand that problem to  
be signaling SRTP when some endpoints only support RTP.  The risk to  
signaling both SRTP and RTP is a bid-down attack.

Mark