asterisk users - Mar 2019 - pjsip: don't require authentication from remote i register to

On Fri, 2019-03-01 at 15:41 -0500, Joshua C. Colp wrote:
> 
> I don't understand what you mean. Your ITSP has stated that they
> don't want you to do authentication with them, so you can't.
They are implying, as I am understanding them, that somehow SIP packets
they send me shouldn't need to be authenticated because they are
associated (i.e. "identify"ed in pjsip nomenclature) with my
registration to them.  It all sounds suspect to me but that's what I am
understanding them to be saying.

Ultimately, if I have this endpoint and it's unauthenticated, does it
create a security risk?

I suppose anyone could forge a UDP packet as coming from their IP
address, and as it's "identify"ed by IP on my side and I would
accept
it without authentication being necessary.

But then I suppose they are only getting access to being able to
connect into an incoming dialplan context, so ringing extensions here,
but not being able to launch in and outbound (money costing) phone
call, at least without there being dialplan support to make outgoing
calls when calling in (i.e. like a calling card application or
somesuch, which should have it's own authentication anyway).
> If you are referring to the template - it's a template so by itself
> does not create an endpoint.
Yes, completely understood.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190301/4d02a88e/attachment.sig>

On Fri, Mar 1, 2019, at 4:51 PM, Brian J. Murrell wrote:
> On Fri, 2019-03-01 at 15:41 -0500, Joshua C. Colp wrote:
> > 
> > I don't understand what you mean. Your ITSP has stated that they
> > don't want you to do authentication with them, so you can't.
> 
> They are implying, as I am understanding them, that somehow SIP packets
> they send me shouldn't need to be authenticated because they are
> associated (i.e. "identify"ed in pjsip nomenclature) with my
> registration to them. It all sounds suspect to me but that's what I am
> understanding them to be saying.
> 
> Ultimately, if I have this endpoint and it's unauthenticated, does it
> create a security risk?
> 
> I suppose anyone could forge a UDP packet as coming from their IP
> address, and as it's "identify"ed by IP on my side and I
would accept
> it without authentication being necessary.
> 
> But then I suppose they are only getting access to being able to
> connect into an incoming dialplan context, so ringing extensions here,
> but not being able to launch in and outbound (money costing) phone
> call, at least without there being dialplan support to make outgoing
> calls when calling in (i.e. like a calling card application or
> somesuch, which should have it's own authentication anyway).
That's correct. You'd either need to retrieve the line parameter from
the outbound registration or forge the source IP address, and as you stated the
scope of what they can do is limited.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

On Fri, 2019-03-01 at 15:54 -0500, Joshua C. Colp wrote:
> 
> That's correct. You'd either need to retrieve the line parameter
from
> the outbound registration or forge the source IP address,
Can I eliminate the identify by IP address then, given that my ITSP is
supporting the line parameter?  Or make even better, require them both
to be identified?
> and as you stated the scope of what they can do is limited.
I guess this is just a risk that everyone lives with.  As a limited
scope risk, anyway.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190301/2f4da657/attachment.sig>