Re: [stir] Permitted spoofing

On 11.06.2013, at 22:41, Rosen, Brian wrote:

> This is not just MITM.
> 
> The bad guy just needs to receive any good call, and then use it to
> impersonate the person who called them.
> 
> I think we need the To, From, some form of call-id and a timestamp to get
> a decent signature.
Yes,
... confessed in my previous message already ;-)

> We don't have domains in this discussion - we have telephone numbers, so I
> think DANE can't help us.

 OK, but server authentication is definitely next.
DNS is the only way to reach these servers today. We are farther on the Internet than typical PSTN paradigms allow us to follow.

 SIP does not have decent server authentication and therefore one can pretend to be your telecom server of choice.

Willi

> 
> Brian
> 
> On 6/11/13 4:37 PM, "Wilhelm Wimmreuter" <wilhelm@wimmreuter.de> wrote:
> 
>> Guess this is MITM is the next VoIP issue to come up.
>> 
>> Both way authentication is not considered for VoIP because service
>> providers are trusted by default. ;-)
>> 
>> 
>> DANE WG with their DNSsec approach might be a solution for this MITM
>> issues as well?
>> 
>> 
>> BTWY:
>> We had nasty routing issues in pure PSTN as well. There the MITM could
>> pretend being a fixed network operator instead of a mobile operator to
>> "optimize" their business case on termination fees.
>> 
>> Willi
>> 
>> 
>> 
>> 
>> On 11.06.2013, at 18:12, Dave Crocker wrote:
>> 
>>> On 6/11/2013 6:03 AM, Rosen, Brian wrote:
>>>> MITM is a potential problem, which would be desirable to cut off, but
>>>> it's not the stated problem we're trying to solve.
>>>> 
>>>> There may be some number of service providers in the path that are
>>>> tolerant of the problem, but not really complicit.
>>> 
>>> 
>>> This could have a pretty substantial effect on design choices.
>>> 
>>> For example, session-based SSL authentication -- that is, without
>>> server validation (certs) -- permits MITM, which seems to be
>>> often/generally acceptable in terms of actual practice, although
>>> rhetoric claims otherwise.
>>> 
>>> But in general, I've had the impression that any effort at
>>> authentication or confidentiality comes with an expectation of
>>> resistance to MITM compromises.
>>> 
>>> d/
>>> 
>>> -- 
>>> Dave Crocker
>>> Brandenburg InternetWorking
>>> bbiw.net
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
> 