Subject: [dispatch] Identity Adhoc - Nov 9th: Notes available

From: "Mary Barnes" <[email-masked]>
Date: Mon, 9 Nov 2009 16:21:24 -0600

Hi all,

I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday:
http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc

Regards,
Mary.

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 10 Nov 2009 17:56:17 +0100

As a very brief summary:

- Unanimous Agreement that we do have a problem to be solved
- Next step is to work the requirements until we have better agreement
- Several folks indicated interest and willingness to be involved in
ongoing work

Cheers,
-Victor

On Mon, Nov 9, 2009 at 11:21 PM, Mary Barnes <[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

-- 
Victor Pascual Ávila

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 16 Nov 2009 20:31:03 +0100

I think it is worth mentioning and doublechecking a problem we touched
in this conversation, which is SIP servers modifying SDP to facilitate
NAT traversal. I think Jon P. has said this was unacceptable use-case not
good enough as motivation for work related to it, because it exposes
such calls to MiTM attacks. Is that right, Jon?

-jiri

Mary Barnes wrote:
> ------------------------------------------------------------------------
>

---

From: Jon Peterson <[email-masked]>
Date: Mon, 16 Nov 2009 12:45:28 -0800

I was not arguing against NAT traversal, actually. From the start of the 
SIP identity work, we considered support for NAT traversal as a 
requirement. Of course, the authors of RFC4474 assumed that something 
roughly like ICE would take over this role, and obviously the deployment 
situation is bit more complicated (we similarly hoped that GRUU would 
make it unnecessary for intermediaries to modify Contact headers, and so 
on). Regardless, I still believe we need to have a reasonable story for 
how an identity mechanism will accommodate NAT traversal.

To rehash arguments that have circulated in this discussion many times, 
one must distinguish the NAT traversal case from the "media steering" 
requirement that has motivated much of the re-examination of identity. 
RFC4474 signatures are applied not by the user agent (at least not in 
the typical case), but rather by a server operated by the user agent's 
administrative domain. The administrative domain can more or less modify 
signaling arbitrarily before adding an Identity header per RFC4474. 
Thus, some sort of intermediary that modifies SIP signaling for the sake 
of NAT traversal can work with RFC4474, provided that the intermediary 
acts before the Identity header is added.

While it can therefore be argued that RFC4474 does not rule out 
intermediary-based NAT traversal entirely, it does protect against any 
intermediary altering SDP once a request has left the originating 
administrative domain with an Identity header. The "media steering" use 
cases that challenge this design are predicated on an intermediary with 
no necessary relationship to the originating or terminating 
administrative domain unilaterally modifying SDP in transit, usually in 
order to force layer 3 routing of media to pass through one or more 
anchor points in a network - perhaps for the sake of drawing the traffic 
across a managed circuit with carefully-managed quality, or to 
facilitate lawful intercept, or what have you. It is that requirement 
which I have consistently argued is equivalent to exposing this 
mechanism to a man-in-the-middle attack. If we removed enough 
protections in the design of RFC4474 to enable media steering by "good" 
intermediaries, we are effectively also enabling any malicious entities 
to change those aspects of SIP requests as well.

I do not find the requirement for NAT traversal unacceptable, but I do 
consider the requirement for media steering highly dubious at best.

Jon Peterson
NeuStar, Inc

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 16 Nov 2009 13:20:37 -0800

>From the start of the SIP identity work, we considered support for NAT traversal as a
requirement.

In hindsight, this assumption does not include the case when NAT traversal for all
application layer protocols is taken care of by HIP, in which case SIP developers do
not have to worry about it:
"Basic HIP Extensions for Traversal of Network Address Translators"
http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09

HIP developers do the NAT traversal work and the problem discussed below do not arise.
HIP uses ICE as well.

Is there a way to convince the SIP standards community of the benefits of HIP?
Notable exception:
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-hip-bone-03.txt

Thanks, Henry

On 11/16/09 2:45 PM, "Jon Peterson" <[email-masked]> wrote:

Jon Peterson
NeuStar, Inc

---

From: Francois Audet <[email-masked]>
Date: Tue, 17 Nov 2009 00:06:03 +0200

So, in summary: SDP (and other) modification should only be done on a UA's behalf  by its administrative domain, otherwise, it's unsafe.

Seems reasonable to me.

We seem to recycle the same arguments over and over again....

On Nov 16, 2009, at 22:45 , Jon Peterson wrote:

> 
> I was not arguing against NAT traversal, actually. From the start of the SIP identity work, we considered support for NAT traversal as a requirement. Of course, the authors of RFC4474 assumed that something roughly like ICE would take over this role, and obviously the deployment situation is bit more complicated (we similarly hoped that GRUU would make it unnecessary for intermediaries to modify Contact headers, and so on). Regardless, I still believe we need to have a reasonable story for how an identity mechanism will accommodate NAT traversal.
> 
> To rehash arguments that have circulated in this discussion many times, one must distinguish the NAT traversal case from the "media steering" requirement that has motivated much of the re-examination of identity. RFC4474 signatures are applied not by the user agent (at least not in the typical case), but rather by a server operated by the user agent's administrative domain. The administrative domain can more or less modify signaling arbitrarily before adding an Identity header per RFC4474. Thus, some sort of intermediary that modifies SIP signaling for the sake of NAT traversal can work with RFC4474, provided that the intermediary acts before the Identity header is added.
> 
> While it can therefore be argued that RFC4474 does not rule out intermediary-based NAT traversal entirely, it does protect against any intermediary altering SDP once a request has left the originating administrative domain with an Identity header. The "media steering" use cases that challenge this design are predicated on an intermediary with no necessary relationship to the originating or terminating administrative domain unilaterally modifying SDP in transit, usually in order to force layer 3 routing of media to pass through one or more anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to facilitate lawful intercept, or what have you. It is that requirement which I have consistently argued is equivalent to exposing this mechanism to a man-in-the-middle attack. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively also enabling any malicious entities to change those aspects of SIP requests as well.
> 
> I do not find the requirement for NAT traversal unacceptable, but I do consider the requirement for media steering highly dubious at best.
> 
> Jon Peterson
> NeuStar, Inc
> 
> Jiri Kuthan wrote:

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 17 Nov 2009 09:27:22 +0100

Jon Peterson wrote:
> mechanism to a man-in-the-middle attack.

how is that different from a MiTM attacking SDP on the path from UA
to a 4474-enable proxy?

>   If we removed enough

I'm wondering if  RFC4474 can prevent MiTM as it is not  guaranteed to provide
end-to-end protection in the typical case.

> consider the requirement for media steering highly dubious at best.

Some while ago I would have thought that in this typical case there
are two administrative zones under respective control with a pipe in
between. Then it shall be manageable to put a SDP-manipulating closer
to UA than 4474 processing. In the meantime I think it became hard to
find a SIP path which in between two 4474 entities has nothing that
rewrites SDP.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 17 Nov 2009 09:27:34 +0100

> So, in summary: SDP (and other) modification should only be done on a UA's behalf  by its administrative domain, otherwise, it's unsafe.

Hi Francois,

I'm not quite yet sure what administrative domain means?

The picture I'm having in my mind is using say iptel.org service (located
in Central Europe in a facility administered by iptel.org's administrator)
from an IETF meeting (administered by the IETF team) to my family
(located within what a German ISP administers).

-jiri

>> While it can therefore be argued that RFC4474 does not rule out intermediary-based NAT traversal entirely, it does protect against any intermediary altering SDP once a request has left the originating administrative domain with an Identity header. The "media steering" use cases that challenge this design are predicated on an intermediary with no necessary relationship to the originating or terminating administrative domain unilaterally modifying SDP in transit, usually in order to force layer 3 routing of media to pass through one or more anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to facilitate lawful intercept, or what have you. It is that requirement which I have consistently argued is equivalent to exposing this mechanism to a man-in-the-middle attack. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively als
o enabling any malicious entities to change those aspects of SIP requests as well.

---

From: Jon Peterson <[email-masked]>
Date: Tue, 17 Nov 2009 04:20:26 -0800

>> The "media steering" use cases that challenge this design are 
>> predicated on an intermediary with no necessary relationship to the 
>> originating or terminating administrative domain unilaterally 
>> modifying SDP in transit, usually in order to force layer 3 routing 
>> of media to pass through one or more anchor points in a network - 
>> perhaps for the sake of drawing the traffic across a managed circuit 
>> with carefully-managed quality, or to facilitate lawful intercept, or 
>> what have you. It is that requirement which I have consistently 
>> argued is equivalent to exposing this mechanism to a 
>> man-in-the-middle attack.
I'm not sure how to answer your question except to say that it is a 
fundamental difference in the protection scope of the mechanism. The 
path between the user agent and the RFC4474-enabled proxy must be 
secured in some fashion, it's true, and there are a number of ways that 
security might be provided that can either allow for the presence of 
other intermediaries in the administrative domain or not, depending on 
the SIP deployment of the domain (RFC4474 does talk about this a bit). 
If those protections aren't in place, then of course any adversary can 
alter the signaling arbitrarily with fear of detection. Once an Identity 
header is in place, however, any subsequent modifications to the 
signaling that could lead to impersonation (in so far as the threat of 
impersonation is defined in the draft) are supposed to show up as 
violations. That's the protection that the Identity mechanism affords.

So the difference is that in one case, there's supposed to be security, 
and in the other case there isn't.
>>   If we removed enough
>> protections in the design of RFC4474 to enable media steering by 
>> "good" intermediaries, we are effectively also enabling any malicious 
>> entities to change those aspects of SIP requests as well.
No mechanism can "prevent" a man-in-the-middle, it can merely detect it. 
RFC4474 provides its protections within its defined scope, which is  
from an authentication service in the administrative domain to the 
terminating user agent. If the path between the originating user agent 
and the authentication service is insecure and vulnerable, as discussed 
above, then yes, RFC4474 doesn't provide end-to-end protection.
>>
>> I do not find the requirement for NAT traversal unacceptable, but I 
>> do consider the requirement for media steering highly dubious at best.
You are not the first one to make this observation, but I don't think 
this information is very useful in drafting the sorts of requirements in 
Mr. Elwell's document. The stated requirement for "media steering" 
assumes something much more specific than simply wanting to rewrite SDP. 
An intermediary that wants to rewrite SDP may have one of several 
relationships with the originating and terminating user agents or 
administrative domains. The "media steering" use cases invariably assume 
an entity acting unilaterally, without necessarily the knowledge or 
consent of either side of the transaction - it acts by virtue of being 
in the path of signaling, even if only as an ALG. If we design a 
security mechanism that allows an entity to act with that sort of 
impunity, it may facilitate some few beneficial services but it will 
also facilitate a variety of attacks. I believe we can do better - we 
can find ways to allow intermediaries to perform the services they'd 
like to perform without acting unilaterally. Certainly at the time 
RFC4474 was under development, we believed that mechanisms like 
session-policy would eventually provide a way for intermediaries to 
force user agents to conform with intermediary policy, including session 
dependent policy cases for SDP. If we're going to dedicate design energy 
to solving problems in this neighborhood, one could argue that solving 
for these building blocks first (allowing intermediaries to modify 
signaling in a collaborative manner rather than unilaterally) will make 
the path to an identity solution much, much easier. From a requirements 
perspective, this is much closer to what I'd like to see expressed than 
something like "media steering," which basically equates to reducing the 
protection space.

Jon Peterson
NeuStar, Inc.

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 17 Nov 2009 18:57:36 +0100

>> how is that different from a MiTM attacking SDP on the path from UA

What is all if it then good for if we don't have guarantee for e2e
integrity protectino and have quite likely (Though not lovely) chance
that ALGs will break even identity?

To me having a partial protection of SDP along the SIP path sounds
remarkably similar to the concept of partial pregnancy.

> alter the signaling arbitrarily with fear of detection. 

Even if there are other technologies (let's assume for a while that TLS
can be relied upon along the whole path) that can cover the whole path,
what's integrity in 4474 then good for?

> Once an Identity

I understand the benefit. The point is that Identity appears meaningful
even without that (to the point I know who is calling) and the cost is
that it breaks whenever there is an ALG in the path, which happens quite
frequently.

> So the difference is that in one case, there's supposed to be security, 

I'm worried that covering SDP along a piece of the path is not eliminating
MiTM attacks and therefore doesn't provide better security.

> above, then yes, RFC4474 doesn't provide end-to-end protection.

That's my problem -- we only have partial integrity protection  and for
this limited benefit  we don't get over ALGs.

> also facilitate a variety of attacks.

I'm afraid the attacks are there anyhow. Use of STUN, for example, exposes
the whole architecture to MiTM attack even if there is SDP protection
end-to-end in combination with hop-by-hop TLS encryption. TLS implementations
are for some reason quite rare. In other words if there is somone in position
to rewrite packets as sent from a UA, SDP protection between two proxy servers
will not stop him.

>  I believe we can do better - we

The problem I see is it reduces protection space but it does not reduce
the problem space. With TLS we could be getting protection along the whole
path on a hop-by-hop basis so the residual security risk is that
a legitimate SIP element on the path between 4474 issuer and verifier
changes SDP.

Why do you think that any negotiation consensus-producing facility would
fly better than adoption of the policy framework?

Or do you rather think along the lines of setting the user expectations?
(a la a new error code "18x hang up now and upgrade to nat-free IPv6
or media encryption, otherwise you will be in the middle of a call that
may be intercepted by parties with legitimitate as well as illegitimate
interest to do so" with obligation that all evil parties send this sort
of message...?)

OR advisory SDP protection which makes recepients alert of a change but
doesn't yet mandate the protocol stack to throw broken traffic away?

or a BCP that creates a VPN tunnel, producing security and consensus to
use some public address for public trAFFIC?

I really don't know what your suggestion above means.

The point is really as with NAT's IP address rewriting, there is SDP
rewriting and assuming in protocol design that these things don't
exist will probably do bigger harm (such as unusability of 4474)
then accepting it as matter of fact.

-jiri

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Nov 2009 12:28:56 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jon Peterson
> Sent: Monday, November 16, 2009 12:45 PM
> To: Jiri Kuthan
> Cc: [email-masked]
> Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available
> 
> 

"Highly dubious" = nobody really does it?

-d

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 17 Nov 2009 22:08:54 +0100

> "Highly dubious" = nobody really does it?

Network administrators have actually found it easier to rewrite SDPs
than to use other existing mechanisms.

Cheers,
-- 
Victor Pascual Ávila

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Nov 2009 15:08:49 -0600

Dan Wing wrote:
>Jon said:

People do highly dubious stuff all the time; they have unprotected sex, 
they jump out of perfectly good airplanes, they vote for Obama, they try 
for a single-handed Atlantic crossing in a 6 meter sailboat with no 
preparation, they try to implement RAI specifications from the RFC 
without parallel testing against existing systems, and so on.

The question is: Should we take the human urge to engage in highly 
dubious practies like traffic steering into account when we write an 
identity spec? If so, at what level of  dubiousness (or dubyaness, for 
the left-leaning) do we draw the line?

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Nov 2009 16:14:09 -0500

> the left-leaning) do we draw the line?

I'd been thinking the dubyaness was just a bad dream.
Thank you for disabusing me of that.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Nov 2009 13:20:33 -0800

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, November 17, 2009 1:09 PM
> To: Dan Wing
> Cc: 'Jon Peterson'; 'Jiri Kuthan'; [email-masked]
> identity spec? If so, at what level of  dubiousness (or 
> dubyaness, for the left-leaning) do we draw the line?

Said another way:  pragmatic versus academic.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Nov 2009 14:11:49 -0500

Forget the NAT traversal piece, or even media steering, and just tell me what signing the IP Address/port in the SDP buys you.  Not the whole SDP, just the IP/ports.  Imagine if the media IP/ports were in a SIP header, and tell me why we MUST sign that header to get "SIP Identity".

My claim is signing those IP/ports is neither necessary nor sufficient for the purposes of SIP Identity nor media identity.  It's an emperor with no clothes, except we end up getting the bill for the clothing.

It is not sufficient because it does not prove the authenticity and identity of the media.  And I don't just mean in an academic sense of "prove".  Not only can the media IP/ports still be spoofed and even intercepted - but nothing prevents me from just sending media from another address/port to get you to listen to my advertisement, instructions to call my number to "verify your credit card", or whatever.

Only a media-plane mechanism will be sufficient for media identity, such as DTLS-SRTP.

It is not necessary because, given a mechanism such as DTLS-SRTP (which *is* necessary for the property of media identity), signing the IP/ports is superfluous.  It's making the mistake of confusing IP with an identity, vs. a routing identifier. (ie, the argument HIP makes)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jon Peterson
> Sent: Monday, November 16, 2009 3:45 PM
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Nov 2009 22:31:12 -0700

If we all believe the only thing SBC rewrite is the IP and port of the  
media, I'm sure we can solve this in no time flat. Unfortunately, when  
a solution to solve that problem have been presented, it has become  
clear that SBC change much more than that.

Cullen <in my individual contributor role>

On Nov 18, 2009, at 12:11 PM, Hadriel Kaplan wrote:

>
> Forget the NAT traversal piece, or even media steering, and just  
> tell me what signing the IP Address/port in the SDP buys you.  Not  
> the whole SDP, just the IP/ports.  Imagine if the media IP/ports  
> were in a SIP header, and tell me why we MUST sign that header to  
> get "SIP Identity".
>
> My claim is signing those IP/ports is neither necessary nor  
> sufficient for the purposes of SIP Identity nor media identity.   
> It's an emperor with no clothes, except we end up getting the bill  
> for the clothing.
>
> It is not sufficient because it does not prove the authenticity and  
> identity of the media.  And I don't just mean in an academic sense  
> of "prove".  Not only can the media IP/ports still be spoofed and  
> even intercepted - but nothing prevents me from just sending media  
> from another address/port to get you to listen to my advertisement,  
> instructions to call my number to "verify your credit card", or  
> whatever.
>
> It is not necessary because, given a mechanism such as DTLS-SRTP  
> (which *is* necessary for the property of media identity), signing  
> the IP/ports is superfluous.  It's making the mistake of confusing  
> IP with an identity, vs. a routing identifier. (ie, the argument HIP  
> makes)
>
> -hadriel
>
>> "good"

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 19 Nov 2009 09:51:35 -0500

Sure, but I'm taking it one bite-size issue at a time, starting with the biggest bite. :) 

Some of the things SBC's change *should* fail a 4474-type signature I think.  And some of them are either not that commonly done, or are done in the originating or terminating domain anyway where changing them doesn't matter for the mechanism (e.g., transcoding).

-hadriel

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, November 19, 2009 12:31 AM
> To: Hadriel Kaplan
> Cc: Jon Peterson; Jiri Kuthan; [email-masked]

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 23 Nov 2009 09:23:04 +0100

Cullen Jennings wrote:
> media, I'm sure we can solve this in no time flat. 

I think there are certainly many who believe this is a reasonable thing
to do ....

> Unfortunately, when a
> solution to solve that problem have been presented, it has become clear 
> that SBC change much more than that.

... and it would be probably more efficient than trying to overload the work
with other interesting features.

what are the next steps then?

-jiri

>> Forget the NAT traversal piece, or even media steering, and just tell 
>> me what signing the IP Address/port in the SDP buys you.  Not the 
>> whole SDP, just the IP/ports.  Imagine if the media IP/ports were in a 
>> SIP header, and tell me why we MUST sign that header to get "SIP 
>> Identity".
>>
>> My claim is signing those IP/ports is neither necessary nor sufficient 
>> for the purposes of SIP Identity nor media identity.  It's an emperor 
>> with no clothes, except we end up getting the bill for the clothing.
>>
>> identity of the media.  And I don't just mean in an academic sense of 
>> "prove".  Not only can the media IP/ports still be spoofed and even 
>> intercepted - but nothing prevents me from just sending media from 
>> another address/port to get you to listen to my advertisement, 
>> instructions to call my number to "verify your credit card", or whatever.
>>
>> (which *is* necessary for the property of media identity), signing the 
>> IP/ports is superfluous.  It's making the mistake of confusing IP with 
>> an identity, vs. a routing identifier. (ie, the argument HIP makes)
>>
>> -hadriel
>>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Nov 2009 10:21:09 +0100

> [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
> Sent: 17 November 2009 21:09
> To: Dan Wing
> Cc: [email-masked]
[JRE] This is an important point. Those who stand to benefit from e2e (or end-domain-to-end-domain) authenticated identification are the end users and their domains. Intermediate domains do not benefit. Therefore any mechanism that is harder to deploy at intermediate domains without benefiting those intermediate domains will not be adopted.

John