Subject: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 05 Apr 2000 21:44:15 +0000

Jonathan Rosenberg wrote:
> 
> 
> "Donovan, Steven R." wrote:
> > 
> > One quick comment on the security section of this draft.  I 
> agree that it is
> > true that the security section in SIP that discusses 
> end-to-end encryption
> > of the SIP message body should be sufficient to meet the 
> security concerns
> > associated with carrying ISUP and QSIG message bodies.
> > 
> > I would, however, suggest that the following be added to the spec:
> > 
> > "Due to the potentially sensitive nature of the information 
> contained in
> > ISUP and QSIG message bodies, the UAC SHOULD perform 
> end-to-end encryption
> > on ISUP and QSIG message bodies."
> 
> Lets be careful here. It depends on the application of SIP-T. 
> For single
> provider networks among a set of  softswitches, its easy to 
> manage keys
> in such a way that e2e encryption is possible. For 
> multi-provider, wide
> area operation, e2e encryption is harder, and I'm reluctant to make it
> SHOULD. It requires the originator to know the key of the ultimate
> recipient before sending the request. Since the entity the 
> request will
> terminate on can't always be known ahead of time (due to forwarding or
> routing to a remote gateway), this requirement is overly strong.
>

I don't know, there are some pretty serious regulatory issues involved.  I'm
almost inclined to say that SHOULD is to weak and that if the encryption key
information is not available then the ISUP information SHOULD NOT be
included in the SIP message.

This doesn't break the call, it just weakens the interoperability between
the SIP and PSTN networks.  All of the information necessary for the call to
be re-originated from the SIP network to the PSTN exists in the SIP headers.
The only loss is some of the information carried in the ISUP message (caller
id, reason codes, etc.).  This is analogous to interoperability between an
SS7 ISUP network and a CAS network, where information is lost when the call
is handed off to the CAS network.  The calls still work, just with a limited
set of features.
 
If it is absolutely necessary to include the ISUP for all call related
features to work then the calling gateway can insist on use of the security
pre-condition mechanism defined in the manyfolks draft.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Apr 2000 01:19:29 -0400

"Donovan, Steven R." wrote:

> is handed off to the CAS network.  The calls still work, just with a limited

One of the premises we were aiming for with this work was that the
originating gateway did not need to know the terminating entity (gateway
or otherwise) before launching the call. If the terminating entity was a
gateway, the ISUP information could be used and transparency is
achieved. If the terminating entity was not a gateway, the ISUP is
ignored and everything still works. I still believe this to be a
valuable goal, and I'd like to consider other options besides abandoning
it.

My assumption is that the only sensitive information, per se, is the
calling name and number (at least as far as regulatory issues in the
PSTN go). Are there any others?

So, some possibilities:

1. We rely on hop by hop encryption. If the message hits a point where
the next hop is not over an encrypted transport, the sensitive
information (or the ISUP message in its entirety) is removed. This is
kind of bad, since the proxies then need to examine bodies.

2. Variant on (1); if the call hits a non-encrypted hop, an error is
generated, and the originating gateway relaunches the INVITE without
ISUP or with the sensitive information removed. We talked about this
during the security task force meeting - a caller preferences extension
that could request a proxy to reject the request if it crosses a trust
boundary.

3. The calling name and number are removed from the ISUP message (or set
to something innocuous), and the information is conveyed using the DCS
mechanisms for caller privacy.

Others?

> pre-condition mechanism defined in the manyfolks draft.

These preconditions are for security for the sessions (i.e., RTP), not
for SIP.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com