Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)

From: [email-masked]
Date: Fri, 16 Aug 2002 11:22:48 EDT

In a message dated 8/15/02 12:11:04 PM Eastern Daylight Time, 
[email-masked] writes:

> Please help me understand:
> 
> >ISUP interworking absolutely requires authentication of the 
> >originator (SIP device or ingress gateway) by the egress GW.
> 
> Does this mean that I cannot use my SIP device to call someone who does
> not know me? I don't tink this is acceptable, tough it would probably
> block the telemarketers - highly desirable - but still not acceptable.
> 
> Do we have here the larger issue that IP-PSTN/ISDN interworking exposes
> PSTN/ISDN to IP-like attacks? If yes, than it should be dealt with
> outside the SIP-ISUP context. What do y'all think?
> 

[MAP] I'm refering to the SIP to ISUP interworking case, so it means that the 
gateway to the ISUP world needs to authenticate. Since the called party in 
this case is in the PSTN, they function just like they do today - they trust 
the PSTN service provider they get the call from.

What it means is that you can not use your SIP device if the egress gateway 
you try to connect through does not know you (or can't authenticate you). You 
certainly can't expect an egress gateway to use its resources to make a call 
if it can't bill you for it.

I'm speaking of the SIP to ISUP interworking point ("egress gateway"). Since 
it is going to use ISUP on the other side and I must presume that no service 
provider with an ISUP network would tolerate any one of the secrurity threats 
described in the draft, they would insist that security procedures MUST be 
done in that gateway. It seems that the only starting point for such security 
is to require authentication by the egress gateway. In my view, this can be 
one of two cases:

1. For a call originated by any random SIP user, authentication must occur 
after the INVITE arrives and before any IAM is sent into the ISUP world
2. For a call coming from another gateway, there should already be a security 
association, so the egress gateway can immediately send an IAM 
(authentication was already done).

Yes, the fact that IP-PSTN interworking exposes the PSTN (ISUP is the real 
concern) is maybe a larger issue. But I don't see dealing with it outside 
this context. It is a fundamental part of it.

Your concern about not being able to call someone who does not know you 
(making authentication hard) is exactly the problem I have with the SIP 
model. I fail to see how this approach (claiming that authentication is the 
solution to everything) can work in a global network. Has someone described 
an actual solution?

Mike Pierce
Artel

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 16 Aug 2002 11:24:08 -0500

Mike:

>Your concern about not being able to call someone who does not know 
>you (making authentication hard) is exactly the problem I have with the
SIP model. 

I don't think this has to do anything with technology or protocols.
Party A should be able to call party B, even if they have no trust
association previously established, subject to policy. Except for
unlisted numbers. This goes for both PSTN and SIP.

If party B is behind a gateway, on the PSTN side, you are raising
correctly the interesting issue who  should pay. I believe this is a
policy issue depending on the service. If party B is a call center, then
party B will pay. Other policies may just not accept SIP calls from
unknown sources, as you mention, but this MUST NOT be a protocol design
point, I believe.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 16, 2002 10:23 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)

[MAP] I'm refering to the SIP to ISUP interworking case, so it means
that the gateway to the ISUP world needs to authenticate. Since the
called party in this case is in the PSTN, they function just like they
do today - they trust the PSTN service provider they get the call from. 

What it means is that you can not use your SIP device if the egress
gateway you try to connect through does not know you (or can't
authenticate you). You certainly can't expect an egress gateway to use
its resources to make a call if it can't bill you for it. 

I'm speaking of the SIP to ISUP interworking point ("egress gateway").
Since it is going to use ISUP on the other side and I must presume that
no service provider with an ISUP network would tolerate any one of the
secrurity threats described in the draft, they would insist that
security procedures MUST be done in that gateway. It seems that the only
starting point for such security is to require authentication by the
egress gateway. In my view, this can be one of two cases: 

1. For a call originated by any random SIP user, authentication must
occur after the INVITE arrives and before any IAM is sent into the ISUP
world 
2. For a call coming from another gateway, there should already be a
security association, so the egress gateway can immediately send an IAM
(authentication was already done). 

Yes, the fact that IP-PSTN interworking exposes the PSTN (ISUP is the
real concern) is maybe a larger issue. But I don't see dealing with it
outside this context. It is a fundamental part of it. 

Your concern about not being able to call someone who does not know you
(making authentication hard) is exactly the problem I have with the SIP
model. I fail to see how this approach (claiming that authentication is
the solution to everything) can work in a global network. Has someone
described an actual solution? 

Mike Pierce 
Artel 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2002 16:35:59 -0400

Henry,

I believe that this problem extends to other realms such as in presence or 
in ENUM.  The fundamental problem is that one is attempting to make a 
decision about what to do with a request based on the trust that the sender 
of the request is who they purport to be.  If you are willing to 
communicate to an anonymous person, then you do not have this problem.

In the PSTN, we probably would not give out sensitive information to anyone 
who calls us, that we can't identify by ANI or some other somewhat trusted 
means.  But, we would expect to give out things like credit card numbers to 
the store that we called, because we can trust that the call got routed to 
where we dialed it.

In the SIP world, absent some additional protocol controls, I don't see how 
I can trust that the call went to who I sent it to or that a call comes 
from who it claims to come from.  Saying that we will authenticate, even 
when using strong crypto is meaningless unless we have a means to validate 
the keys used to electronically sign the message.  Yes, it may pass 
integrity checks.  Yes, it may have arrived from somewhere 
confidentially.  But, who am I communicating with?

A certificate chain that leads unbroken to some organization that I trust 
to follow proven procedures for validating users and managing certificate 
security, or in combination, or substituted with some other processes that 
can be shown to have some degree of reliability, is needed.  The cellular 
industry (ANSI-41 or GSM) has come up with a means of doing this work to 
some degree via their VLR/HLR infrastructure.  They are likely planning 
something for SIP-based systems.  They have been burned before and have 
learned that lesson.  But, I can't say that I get a warm fuzzy over what is 
being done elsewhere.  Not that there aren't service providers out there 
planning such security.  But, I would like to see how all these systems fit 
together into a coherent whole system.

This doesn't mean that one can not practice unsafe communications.  But, I 
hope it will be made clear to the average consumer when one can trust the 
"phone system" and when one can not.

Ultimately, this is protocol, even when some protocol is technical and some 
protocol is human process.

Mike

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 16 Aug 2002 16:02:52 -0500

Mike, 

Maybe we just stick with simple examples: A call center, or a doctors
office receives calls is good enough for now. They would like to receive
ALL calls. This has nothing to do with protocols, but is a matter of
service specific policy. This seems to be completely protocol
independent, ISUP, SIP or whatever. Or is it?

Henry

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Michael Hammer
> Sent: Friday, August 16, 2002 3:36 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sipping] new draft-ietf-sipping-isup-05 (Security)
> 
> 
> Henry,
> 
> > >you (making authentication hard) is exactly the problem I
> have with
> > >the
> >SIP model.
> >
> >policy issue depending on the service. If party B is a call center, 
> >then party B will pay. Other policies may just not accept SIP calls 
> >from unknown sources, as you mention, but this MUST NOT be a 
> protocol
> >design point, I believe.
> >
> >Henry
> >
> >security procedures MUST be done in that gateway. It seems that the 
> >only starting point for such security is to require 
> authentication by
> >the egress gateway. In my view, this can be one of two cases:
> >
> >world 2. For a call coming from another gateway, there
> should already
> >be a security association, so the egress gateway can
> immediately send
> >an IAM (authentication was already done).
> >
> >This list is for NEW development of the application of SIP Use 
> >[email-masked] for questions on
> current sip Use
> >[email-masked] for new developments of core SIP
> 
> 
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2002 18:19:29 -0400

Henry,

I think there are a couple levels working here.  One, is whether a 
malicious user is attempting to hack the PSTN network, affect another PSTN 
end-user terminal or its services, or whether a seemingly normal call is 
being used to deceive the end-user.

You seem to be pointing to the last case and saying that it is local policy 
for the end-user to decide through the content of the communication (where 
human validation could occur) whether to continue it or disconnect.

What I am trying to discern from your statement is what information does 
the policy you refer to use as input?  If you policy is based on any 
signaling parameters, then I would content that, absent some means of 
validating those parameters, your policy won't work.  Garbage-in, garbage-out.

 From the call center/doctor scenario put forth, I would assume you do not 
rely on any information inferred from the telephone network, but may have 
some means of validating the caller, i.e. through the call content the 
caller provides some information that enables the business at hand to be 
conducted.

If you are talking automated policy based on automated parameters, it 
depends on automated protocols.  If you are talking human policy based on 
human information provided, then no.  Is this making sense?

Mike

---

From: Al Varney <[email-masked]>
Date: Sat, 17 Aug 2002 10:17:34 -0500

At 04:02 PM 8/16/02 -0500, Henry Sinnreich wrote:

>ALL calls.

    Just as Web sites would like to receive ALL HTTP requests?  Well, not 
quite.  Some spend a lot of time and money to block DOS and distributed 
attacks on their sites.

    Call centers (even emergency call centers) receive lots of unwanted 
calls.  (You wouldn't believe the number of schoolkids dialing prank 
toll-free calls from coin phones.)  In some cases, the callers are tracked 
down and prosecuted for harassment, etc.

    Regardless of authentication/authorization, folks will attempt to use 
SIP in all the ways other IP-base services have been exploited.  These are 
easily imagined:  Spam e-mail becomes spam calls.  Unsolicited FAX 
advertising becomes unsolicited computerised voice mail ads.  Some kid 
cranks up "SIP Warrior" to tie up phone service at the local college, using 
credentials stolen from Henry Sinnreich's home SIP phone.  A group of 
anti-Internet activists use Trojan software to activate "SIP backdoor" in 
thousands of computers to flood WorldCom's customer service centers.  Folks 
more creative than I will, I'm sure, have even more creative ideas.

    But Draft-05 can't be expected to solve those issues, any more than the 
RFCs for HTTP or E-mail provide solutions to today's Internet security 
problems.

>  This has nothing to do with protocols, but is a matter of

    I agree.

    Even vendors and users of ISUP equipment have to deal with possible 
forms of attack (overload, malicious calls, theft of services, "war 
dialing", etc.) and support of means to aid in tracing down those who 
misuse the system.  A SIP-ISUP gateway has to deal with attacks of the IP 
world (DOS, DDOS, misuse of protocol, software bug exploitation, etc.) as 
well, and had better be prepared to aid in tracing down those misusing the 
system.

    The Draft needs to at least mention KNOWN security issues (related to 
SIP-ISUP interworking), even if it doesn't provide solutions.  Discussions 
of solutions might belong on this list (and/or others), but the Draft 
doesn't have to wait for those solutions.  Is REQUIRING authentication a 
solution beyond the Draft?

    Mike did raise some specific SIP-ISUP mapping security issues, and 
those need to be added or dismissed.

Al Varney

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 17 Aug 2002 15:41:36 -0500

Maybe we take this off the list and discuss at the IETF of in a
conference call...

Henry

> From: Michael Hammer [mailto:[email-masked]] 
> Sent: Friday, August 16, 2002 5:19 PM
> To: Henry Sinnreich
> >office receives calls is good enough for now. They would like to 
> >receive ALL calls. This has nothing to do with protocols, but is a 
> >matter of service specific policy. This seems to be 
> completely protocol 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Michael Hammer
> > > I believe that this problem extends to other realms such as in 
> > > presence or in ENUM.  The fundamental problem is that one is 
> > > attempting to make a decision about what to do with a 
> request based 
> > > on the trust that the sender
> > > In the PSTN, we probably would not give out sensitive 
> information to 
> > > anyone who calls us, that we can't identify by ANI or some other
> > > somewhat trusted
> > > In the SIP world, absent some additional protocol 
> controls, I don't 
> > > see how I can trust that the call went to who I sent it 
> to or that a
> > > call comes
> > > A certificate chain that leads unbroken to some 
> organization that I 
> > > trust to follow proven procedures for validating users 
> and managing
> > > certificate
> > > This doesn't mean that one can not practice unsafe 
> communications.  
> > > But, I hope it will be made clear to the average consumer when one
> > > can trust the
> > > Ultimately, this is protocol, even when some protocol is 
> technical 
> > > and some protocol is human process.
> > >
> > > Mike
> > >
> > >
> > > >correctly the interesting issue who  should pay. I 
> believe this is 
> > > >a policy issue depending on the service. If party B is a call 
> > > >center, then party B will pay. Other policies may just 
> not accept 
> > > >SIP calls from unknown sources, as you mention, but this 
> MUST NOT 
> > > >be a
> > > protocol
> > > >design point, I believe.
> > > >
> > > >Henry
> > > >
> > > >[MAP] I'm refering to the SIP to ISUP interworking case, so it 
> > > >means that the gateway to the ISUP world needs to authenticate. 
> > > >Since the called party in this case is in the PSTN, they 
> function 
> > > >just
> > > like they
> > > >1. For a call originated by any random SIP user, authentication 
> > > >must occur after the INVITE arrives and before any IAM is sent
> > > into the ISUP
> > > >Sipping mailing list  
> > > >https://www1.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listin> fo/sipping
> > > This list 
> is for NEW development of the 
> application of SIP Use

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2002 12:12:23 -0400

Henry,

Agreed, I started feeling uncomfortable outlining attacks.

Mike