Re: comments on draft-ietf-sip-dtls-framework

John,

I agree with your analysis. And yet in many contexts there
is a strong 
desire to display "phone numbers", because of
custom and limitations of 
protocols and devices. So there is a tendency to coerce a
sip URI into a 
phone number whenever it looks like that can be done.

I think these two views (your analysis and Cullen's) can
coexist in 
certain environments. Specifically, a UA that receives a
call with 
sip:+123456789example1.com as the caller identity can
assume this is 
equivalent to TEL:+123456789 *if* it has an agreement with
example.com 
that such an equivalence is true. This certainly isn't true
in general, 
but may be true in some important cases, expecially when the
domain 
belongs to a service provider.

	Thanks,
	Paul

Elwell, John wrote:
> Cullen,
> 
> I always thought that userdomain1 and userdomain2
are not equivalent -
> each domain has its own namespace for the user part. I
am not aware of
> anywhere that says this is untrue also for phone
numbers. I believe
> +123456789example1.com;user=phone and
> +1213456789example2.com;user=phone are not
equivalent. Also I
> understand you cannot just take a SIP URI that includes
a telephone
> number and say that this is equivalent to a TEL URI.  I
am not sure
> where I got this understanding from, because it does
not appear to be in
> RFC 3261 - perhaps from an old email thread.
> 
> So if somebody submits a request to +123456789example1.com;user=phone,
> it should be routed to domain example1.com, which then
will route it to
> the user to which it has assigned this identifier. It
has nothing to do
> with whether domain example1.comn owns the E.164 number
+123456789. On
> the other hand, if somebody submits a request to
TEL:+123456789, then
> that should indeed be routed to whoever
"owns" that E.164 number, which
> may or may not be example.com.
> 
> If an originating domain asserts +123456789example1.com;user=phone, and
> that assertion is carried through any intermediate
domains to the
> destination domain, and if that assertion is backed up
by cryptographic
> means, then the terminating user can have confidence
that the
> originating user is in domain example1.com. If media is
secured based on
> this assertion, the user can be confident that media is
secured to/from
> a user in example.com. Receiving an assertion from
mitm.net (even if
> this is a carrier with which the terminating user or
his/her
> organisation has a contractual relationship), on the
other hand, does
> not give the terminating user any such confidence that
he is talking to
> someone in example1.com.
> 
> The fact that the request originates at a user in
domain example1.com is
> the important thing here - whether that domain
"owns" E.164 number
> +123456789 is unimportant. SIP identity makes no such
claim, and such a
> claim is not needed in order to obtain the media
security properties we
> are seeking.
> 
> Of course, if a UAS effectively converts such a SIP URI
back to a TEL
> URI and displays it just as an E.164 number, without
displaying the
> domain part, this is the root of the problem (as
somebody remarked
> earlier in this thread). It gives the called user the
wrong information.
> 
> I thought the whole idea of the dtls-srtp work (and
indeed the whole RAI
> media security discussions) was to try to find a means
of achieving near
> end-to-end security for media. If we just blindly trust
the next hop
> domain, we might as well stick to something like SIPS +
Sdescriptions.
> 
> John
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffycisco.com] 
>> Sent: 25 November 2007 17:52
>> To: IETF SIP List
>> Subject: Re: [Sip] comments on
draft-ietf-sip-dtls-framework
>>
>>
>> On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg
wrote:
>>
>>> What this means is that when phone numbers are
in use, a MITM can  
>>> easily rewrite the From field. So if it was
sip: 
>>> 9739525060example.com they can rewrite to
sip:9739525060middle- 
>>> domain.com, insert a media intermediary and new
fingerprint and  
>>> resign. The called UA or terminating proxy will
verify that the  
>>> identity is valid (which it is) and the called
party is presented  
>>> with the caller ID, which is JUST the phone
number. So they don't  
>>> notice a problem at all.
>>>
>>> Thus, in practice, I fear dtls-srtp will easily
allow proxies and  
>>> SBCs on the chain to intercept and modify the
media stream, 
>> similar  
>>> to what they could do with sdescriptions. This
is really a problem  
>>> with sip identity itself that carries over
here. But I think this  
>>> issue needs to be mentioned and discussed. The
draft makes itself  
>>> out to be substantially more secu
>> This gets to exactly the heart of why I think there
is no need for  
>> the  draft-wing-sip-identity-media draft. Let's
talk about how trust  
>> is going to work with phone numbers as identifies
(ignoring that it  
>> is even SIP here).
>>
>> Say company some phone with the number +1 123
555-1111 makes 
>> a call -  
>> it is at company with a PBX, call them IBM, connect
to a telephony  
>> service provider, call them Sprint, and sends the
call to another  
>> called say AT&T, that hands the call to another
company PBX called,  
>> say Cisco, and we want to assert something about
the caller's phone  
>> number.
>>
>> There is no practical way for Cisco to know who +1
123 555-1111 was  
>> allocated to or for that person to prove they can
use it. What  
>> happens is that Cisco has a relationship with
AT&T and trust 
>> them not  
>> to deliver correct information. LIkewise AT&T
has contracts 
>> with some  
>> people as trusts Sprint. They may not trust every
telco they peer  
>> with in this form but for this example let's say
they do 
>> trust Sprint  
>> to correctly not lie if Sprint claims they can
verify the number is  
>> correct. (It's fine for Sprint to pass calls where
they do not claim  
>> to know the number is correct too). Now sprint does
know what 
>> numbers  
>> it allocated to IBM and has  contract with IBM so
Sprint can decide  
>> if  +1 123 555-1111 was OK or not.
>>
>> Now Identity gives us a way to realize all of this
that 
>> protects from  
>> attackers modifying things along the chain.  IBM
signs and 
>> the number  
>> as IBM and sends on to sprint. Sprint can use this
to decide if they  
>> believe this OK or not along with their policy
information. Now if  
>> sprint thinks it OK, they insert the assertion they
think it OK and  
>> hand to AT&T. AT&T looks at it and decides
that it was OK for 
>> sprint,  
>> then it is OK for them and inserts their assertion
that it OK and  
>> hands down to Cisco. Cisco looks for the AT&T
assertion and since it  
>> one of the carriers they trust, decides it is OK.
>> <bold> As far as I can tell, anything other
than this won't work for  
>> phone numbers </bold>. This means that the
PBX needs to require that  
>> the identity it trusts to sign numbers is some it
trusts -  
>> practically this means the one or more carriers
that it connects to.  
>> These carriers need to have their SBC (or proxies
if they used  
>> theses) insert an assertion about if the number is
OK or not.
>>
>> You might think there is something better than this
but really it is  
>> about who owns the namespace. If Sprint decides to
give the 
>> number +1  
>> 123 555-1111 to some other customer, say Acme, now
Cisco needs to  
>> consider any assertion from IBM that they are
555-1111 to be false.  
>> The only person that knows there was a change was
the namespace  
>> owner, Sprint in this case.  The number could even
be given to a  
>> different carrier.  This solution is the best we
can do given the  
>> constraints of the namespace allocation process. We
can do much  
>> better with the names like sip:fluffycisco.com
but that is a  
>> different topic.
>>
>> Encrypted media is all constrained by it is no good
having encrypted  
>> media to the attacker and the strength of the
security is limited by  
>> the strength of how well you know who you are
talking too. Here the  
>> DTLS keying fingerprint strength is exactly tied to
the identity  
>> strength. If someone had some other way to knowing
who they were  
>> talking too, such as SAS codes if that worked, then
you can 
>> use those  
>> too.
>>
>> The high point I am trying to make here is that you
always have to  
>> trust whoever controls the namespace and for the
case we are  
>> interested in here for phonenumbers, that implies a
certain trust of  
>> the carriers. This in turn means that the Cisco 
PBX in the example  
>> above needs to reject the signature of a phone
number from middle- 
>> domain.com.
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Re: comments on draft-ietf-sip-dtls-framework

Thread: Re: comments on draft-ietf-sip-dtls-framework