Subject: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt

From: "Elwell, John" <[email-masked]>
Date: Sat, 17 Nov 2007 18:23:47 +0000

I think this is a very important draft. The problem it addresses is a
very real problem that not only stops RFC 4474/4916 being deployed
sensibly but also undermines the work on DTLS-SRTP.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 15 November 2007 21:00
> To: [email-masked]
> Subject: I-D Action:draft-wing-sip-identity-media-01.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : SIP Identity using Media Path
> 	Author(s)       : D. Wing, H. Kaplan
> 	Filename        : draft-wing-sip-identity-media-01.txt
> 	Pages           : 25
> 	Date            : 2007-11-15
> 
> 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
> 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.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wing-sip-identity-me
> dia-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in 
> the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-wing-sip-identity-media-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-wing-sip-identity-media-01.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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" <[email-masked]>
Date: Mon, 19 Nov 2007 07:57:54 +0100

Hi,

A few comments/questions.

First, SBC/B2BUAs (as well as gates, as discussed in another thread)
normally don't open the media path until they have received an SDP
answer, so I hope you take that into consideration. Chapter 9 says that
entities must allow messages to be exchanged, but it doesn't say WHEN.

Second, regarding chapter 4.1 and the SIP header/header fields that you
use for the identity, it would be nice if you could add some words about
why it's "safe" to use these headers. Have you done a "SBC market
survey", or what do you base the these-headers-will-not-be-modified
assumption on?

Third, regarding chapter 9, if you are going to rely on an ICE based
mechanism in an environement with SBC/B2BUAs, I think you need to
describe HOW SBC/B2BUAs they are assumed to deal with ICE. As studies
done e.g. in 3GPP has shown (I am happy to discuss this with you more in
detail in off-line), it gets a little tricky when you also have media
proxy type-of-functionality in the SBC/B2BUA. ICE could even be
terminated by the SBC. Simply forwarding STUN messages unchanged will
cause problems with the relexive address information. (I don't know
whether this issue is valid also if you use tls, dtls and/or hip)

Regards,

Christer

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 17. marraskuuta 2007 20:24
> To: sip; Dan Wing
> Subject: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
> 
> I think this is a very important draft. The problem it 
> addresses is a very real problem that not only stops RFC 
> 4474/4916 being deployed sensibly but also undermines the 
> work on DTLS-SRTP.
> 
> John 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 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.
> > 
> > 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.
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Nov 2007 10:59:03 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, November 19, 2007 1:58 AM
> To: Elwell, John; sip; Dan Wing
> Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
>
>
> Hi,
>

That's Brian Stucker's draft. :)

> survey", or what do you base the these-headers-will-not-be-modified

I don't think we need to do a market survey.  SBCs can modify any header or field, and even method.  That's not in debate.  What we're trying to do is sign as few headers/fields as possible to increase the chances of it working across SBCs, while at the same time providing strong identity.

The most contentious among these is undoubtedly the To/From addr-specs.  I know they get changed all the time.  That "works" when it's an E.164, as we describe earlier in the draft, and the SBC changing those can re-sign the request with its own domain's cert without breaking rfc4474.  But it doesn't work if the URIs are real email-style SIP-URIs.  In those cases the SBCs really can't change the domain portion, because it changes the fundamental identity of the caller/called.  If they do change it for such cases then that's not a problem we need to deal with in the draft, I think?

> whether this issue is valid also if you use tls, dtls and/or hip)

I don't think we need to describe that because ICE is only one of the proposed media-identity mechanisms?  ICE already says if a middle-box media relay is detected (ie, if m= line does not match any candidate lines), ICE is abandoned.  If an SBC wants to allow ICE it can do so by not relaying media (ie, not touching SDP) - but it could/would still change Contact/Call-id/etc. and thus would benefit from this draft.  If an SBC or any SIP hop wants to be ICE aware to such an extent as to become an ICE agent (ICE-lite or ICE-heavy), then it needs to understand STUN and not simply forward STUN messages unchanged, IMHO.  But I think the number of different things an SBC-type box could do given ICE is too big to tackle in this draft.  I mean what would we say?

I was not aware studies were done in 3GPP - it seemed like an obvious thing to me that ICE doesn't work very well in media-relayed environments. ;)  Some of the things media-relays do aren't solvable by an ICE approach (e.g., an SBC chooses a media address based on where the call gets routed to, which could be one of numerous address spaces, and may or may not be the public Internet address space).

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Nov 2007 20:40:50 +0100

Hi,
 
>That's Brian Stucker's draft. :)

Ok, but are you assuming some specific outcome of that draft?

Also, I am not sure whether Brian's draft covers B2BUAs, eventhough I guess much of the gate issues also apply to B2BUAs.

>I don't think we need to do a market survey.  SBCs can modify any header or field, and even method.  That's not in debate.  What we're trying to do is sign as few headers/fields as possible to increase the chances of it working >across SBCs, while at the same time providing strong identity.
>
>The most contentious among these is undoubtedly the To/From addr-specs. 

I agree, but I think the Date header could potentially also be an issue. For example, what happens if the UAC does not insert a Date header, but it is then inserted by an intermediate? How will the UAS know?

>I know they get changed all the time.  That "works" when it's an E.164, as we describe earlier in the draft, and the SBC changing those can re-sign the request with its own domain's cert without breaking rfc4474.  But it doesn't work >if the URIs are real email-style SIP-URIs.  In those cases the SBCs really can't change the domain portion, because it changes the fundamental identity of the caller/called.  If they do change it for such cases then that's not a >problem we need to deal with in the draft, I think?

Need to think a little more...

>I don't think we need to describe that because ICE is only one of the proposed media-identity mechanisms?  ICE already says if a middle-box media relay is detected (ie, if m= line does not match any candidate lines), ICE is >abandoned.

Yes. But, I am talking of middle boxes which actually are able to process ICE in a way so that it is not abandoned.

> If an SBC wants to allow ICE it can do so by not relaying media (ie, not touching SDP) 

There can be many reasons why an SBC wants to relay media, so you can't assume they will choose not to just because there is ICE...

>- but it could/would still change Contact/Call-id/etc. and thus would benefit from this draft.  If an SBC or any SIP hop wants to be ICE aware to such an extent as to become an ICE agent (ICE-lite or ICE-heavy), then it needs to >understand STUN and not simply forward STUN messages unchanged, IMHO.  But I think the number of different things an SBC-type box could do given ICE is too big to tackle in this draft.  I mean what would we say?

In one of the solution (which also seems to be the most preferable) studied in 3GPP the SBC will understand STUN. But, it will not forward STUN messages, but instead establish separate ICE sessions in each "direction". From a UA perspective it will look like end-to-end ICE, but it isn't. So, whatever information the UA sends in the STUN message will not reach the other UA.

>I was not aware studies were done in 3GPP 
>
>- it seemed like an obvious thing to me that ICE doesn't work very well in media-relayed environments. ;)

I believe it is possible to make it work, but it assumes that SBCs (at least those relaying media) are ICE- and STUN aware.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Nov 2007 15:59:12 -0500

> Sent: Monday, November 19, 2007 2:41 PM
> To: Hadriel Kaplan; Elwell, John; sip; Dan Wing

I am assuming that draft gets discussed, and whether the issues need to be fixed or not (and how) gets decided in its own context.  If it doesn't get addressed it still doesn't negate the need or usefulness of this draft, it just reduces the breadth of its applicability I guess.  But I take your point we should put some tie-in note.

> Also, I am not sure whether Brian's draft covers B2BUAs, eventhough I
> guess much of the gate issues also apply to B2BUAs.

The way I read it, it is really about any media-path middle-box (ie, B2BUAs, SBCs, P-CSCFs, etc.).  My guess is using the MIDCOM terminology was just a nice way to frame it in an IETF-defined manner, as very few devices actually really use MIDCOM per se, AFAIK.

> I agree, but I think the Date header could potentially also be an issue.
> For example, what happens if the UAC does not insert a Date header, but it
> is then inserted by an intermediate? How will the UAS know?

I believe per RFC4474 the authenticator (signer) can and must add a Date header if the UAC did not.  Since the Date header is included in the headers being signed, you'll know if a middle-man changed it because the signature would be invalid.

[I'm separating the ICE stuff into a different email]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Nov 2007 16:02:55 -0500

[separating ICE-specific bit into this thread]

> >I don't think we need to describe that because ICE is only one of the
> proposed media-identity mechanisms?  ICE already says if a middle-box
> media relay is detected (ie, if m= line does not match any candidate
> lines), ICE is >abandoned.
>
> Yes. But, I am talking of middle boxes which actually are able to process
> ICE in a way so that it is not abandoned.

If they are able to do so (and I don't disagree it is possible), then they need to figure out how to do so on their own.  ICE does not cover such boxes today, so I don't know why this draft should?  I mean it's not that I think it's wrong, I just don't know why it needs to be in this draft unless it changes how this draft works for ICE from the UAs' perspectives.  The question is, does it? [more on that below]

> There can be many reasons why an SBC wants to relay media, so you can't
> assume they will choose not to just because there is ICE...

Oh trust me I don't assume that at all.  ;)
I actually usually assume the inverse: the existence of ICE won't make the SBC stop relaying media at all, because they often relay media for very different reasons than ICE's reasons.

> In one of the solution (which also seems to be the most preferable)
> studied in 3GPP the SBC will understand STUN. But, it will not forward
> STUN messages, but instead establish separate ICE sessions in each
> "direction". From a UA perspective it will look like end-to-end ICE, but
> it isn't. So, whatever information the UA sends in the STUN message will
> not reach the other UA.

Yeah, and that's something I actually think should be taken to mmusic or behave as a draft, because it would be better to make it explicitly signaled.  STUN usage sans ICE has its advantages too, for example.

> I believe it is possible to make it work, but it assumes that SBCs (at
> least those relaying media) are ICE- and STUN aware.

Yeah but that's where I was saying "it would have to be ICE aware". :)

I think though the point you're trying to get to is if the ice-pub-key is signed, but some middle-box outside of the originating or terminating domain wants to terminate ICE/STUN, it can't.  Right?
I don't disagree that is the case.  But I think that's the right thing to happen.  You can't allow the mid-domains to change or remove the pub-key, because that obviously invalidates the assertion of media identity.

Actually, as I was about to write up a "here's how it could work" thing with regards to middle-boxes doing STUN, it occurred to me the ice-pub-key thing described in our draft is easily defeatible.  I'll email Dan about it to see if I'm missing something.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Nov 2007 21:13:32 -0800

...
> > >- it seemed like an obvious thing to me that ICE doesn't 
> > > work very well
> > in media-relayed environments. ;)
> >
> > I believe it is possible to make it work, but it assumes 
> > that SBCs (at least those relaying media) are ICE- and 
> > STUN aware.
> 
> I think though the point you're trying to get to is if the 
> ice-pub-key is signed, but some middle-box outside of the 
> originating or terminating domain wants to terminate 
> ICE/STUN, it can't.  Right?
> I don't disagree that is the case.  But I think that's the 
> right thing to happen.  You can't allow the mid-domains to 
> change or remove the pub-key, because that obviously 
> invalidates the assertion of media identity.

They can pass along the pub-key, and the encrypted information,
though.  This would make their ICE processing more complex.

The overall weakness with sip-identity-media's inclusion of
ICE as an identity assertion is that, in the end, anything
along that path could inject any RTP stream it wanted to
inject.  We can't fix that except to use SRTP and to use
end-to-end keying with SRTP (e.g., DTLS-SRTP).

> Actually, as I was about to write up a "here's how it could 
> work" thing with regards to middle-boxes doing STUN, it 
> occurred to me the ice-pub-key thing described in our draft 
> is easily defeatible.  I'll email Dan about it to see if I'm 
> missing something.

Yes, it is easy to defeat.  All you can really know is that,
at the time you sent the Connectivity Request, there really
was a viable media path to the other party.  But you have
no real assurance that the audio (or video) you are receiving
is from that party.  For that, we need authenticated RTP
which we get with SRTP and end-to-end keying of SRTP.

ICE is in sip-identity-media so that everyone can see how
we could build steps towards doing DTLS-SRTP, as the 
attackers get more sophisticated or as the threat of those
attackers gets more severe.  The end goal for sip-identity-
media is DTLS-SRTP, and not the ICE pub-key technique.  The
ICE pub-key technique is a stepping stone.  

Perhaps, after more people read the draft, we will conclude
that the ICE pub-key technique is not useful enough to 
retain because doing RTP afterwards results in too many
opportunities for attack.

-d

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Nov 2007 06:45:07 +0100

Hi,
 
Not specific to this topic, but I am getting a little worried about this "protocol overloading" I start to see.
 
ICE was done to solve user plane NAT traversal - nothing more, nothing less. Many people spent a lot of work before it reached ice-19.
 
But, now we want to start using ICE for functions it was not meant to. First people decided to deprecate ANAT and ICE instead - and now all this security negotiation stuff...
 
Take PRACK as an example. Initially it was meant simply to acknowledge reliable provisional responses. Then someone figured out that if you are using it for reliable provisional responses you can at the same time also throw in an SDP offer or answer. And, now we have the problems with PRACK and offer/answer (how to reject an offer in PRACK etc).
 
But, my main issue here is: do not assume the information you include in your STUN will be end-to-end.
 
Regards,
Christer

________________________________

From: Dan Wing [mailto:[email-masked]]
Sent: Tue 20/11/2007 06:13
To: 'Hadriel Kaplan'; Christer Holmberg; 'Elwell, John'; 'sip'
Subject: RE: ICE and draft-wing-sip-identity-media-01.txt

...

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Nov 2007 22:08:14 -0800

> Sent: Monday, November 19, 2007 9:45 PM
> To: Dan Wing; Hadriel Kaplan; Elwell, John; sip
> Not specific to this topic, but I am getting a little worried 
> about this "protocol overloading" I start to see.
>  
> ICE was done to solve user plane NAT traversal - nothing 
> more, nothing less. Many people spent a lot of work before it 
> reached ice-19.
>  
> But, now we want to start using ICE for functions it was not 
> meant to. First people decided to deprecate ANAT and ICE 
> instead - and now all this security negotiation stuff...
>  
> Take PRACK as an example. Initially it was meant simply to 
> acknowledge reliable provisional responses. Then someone 
> figured out that if you are using it for reliable provisional 
> responses you can at the same time also throw in an SDP offer 
> or answer. And, now we have the problems with PRACK and 
> offer/answer (how to reject an offer in PRACK etc).
>  

To prove identity across SBCs, all four identity proof 
techniques proposed in sip-identity-media (DTLS-SRTP, TLS, 
ICE with pub-key extension, and HIP) require information to 
be sent end-to-end.

Is there a way to prove end-to-end identity without sending 
information end-to-end?

-d

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Nov 2007 08:03:34 +0100

Hi, 

>>Not specific to this topic, but I am getting a little worried about 
>>this "protocol overloading" I start to see.
>>  
>>ICE was done to solve user plane NAT traversal - nothing more, nothing

>>less. Many people spent a lot of work before it reached ice-19.
>>  
>>But, now we want to start using ICE for functions it was not meant to.

>>First people decided to deprecate ANAT and ICE instead - and now all 
>>this security negotiation stuff...
>>  
>>Take PRACK as an example. Initially it was meant simply to acknowledge

>>reliable provisional responses. Then someone figured out that if you 
>>are using it for reliable provisional responses you can at the same 
>>time also throw in an SDP offer or answer. And, now we have the 
>>problems with PRACK and offer/answer (how to reject an offer in PRACK 
>>etc).
>>  

All I am saying is that there are proposed ICE mechanisms where STUN
would not be sent end-to-end.

Now, if we find out that those mechanisms don't work, we of course have
an issue with those mechanisms.

Regards,

Christer