Subject: [SPIRITS] draft-ietf-spirits-security-00.txt

From: Steve Bellovin <[email-masked]>
Date: Tue, 27 May 2003 19:41:48 -0400

<hats chair=off ad=off>
I've read through the security document; here are a few comments.

Section 2 says "interfaces in the PSTN ... are assumed to be secured
by the virtue of their being in a controlled network".  That isn't an 
acceptable line of reasoning.  Fortunately, PSTN security is out of 
scope for SPIRITS and the IETF; that sentence should be reworded to say 
just that.

3.1: A lot turns on the question of "authorization" -- what does each 
party have a *right* to do.  Requirement 3 gets this right; it's also 
crucial to Requirement 2 and probably 1.  Saying a "trust relationship
MUST exist" is imprecise.  Is it saying that the gateway is trusted -- 
i.e., authorized -- to make any SPIRITS request?  For Requirement 3, 
who must authorize the request, and on what grounds?  My answer would 
be that all users involved and the PSTN provider must authorize it -- 
the latter based on whether or not the customer has paid, the requestor 
to avoid false charges, and the subject of the request on privacy 
grounds.   Requirement 4 shouldn't say "MUST secure the notification",
since "secure" has many meanings.  Say "encrypt" or "provide 
confidentiality".

3.2 should add "the subscriber MAY encrypt requests"; the gateway and 
the PSTN MUST accepted encrypted requests.

3.3 should mention the types of authorization needed, plus the ability 
to encrypt messages and to receive encrypted messages.

4.1: a shared secret over what security channel?

4.2: Delete mention of IPsec unless you can satisfy the requirements of
draft-bellovin-useipsec.  Intra- or inter-domain has nothing to do with 
it.  sips: is good.  "Autonomous system" is a routing concept that's 
irrelevant here.  This document needs to mandate strong-enough security 
mechanisms for hostile environments; operators are always free to turn 
them off if their environment is safe.

4.4: S/MIME is end-to-end, and thus is stronger.

There's no Security Considerations section.  Such a section should 
address residual threats, as well as criteria for turning mechanisms on 
or off.

The client needs some trustworthy way of learning the address of its 
SPIRITS gateway.  This may be out of band; if so, say so.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 28 May 2003 10:11:57 -0500

Steve:

Thanks for the comments; much appreciated.  Lots of feedback inline;
I will rev the document once we have some more discussion on the
information contained inline.  It would be good to close it after
the Vienna IETF.

> scope for SPIRITS and the IETF; that sentence should be reworded to say 

Modified it.

> i.e., authorized -- to make any SPIRITS request?  

That hinges on who owns the SPIRITS gateway.  If it is owned by the
PSTN provider, then a trust relationship can be assumed between
the SPIRITS gateway and the SPIRITS client.  But if it is owned by
a third party, then SPIRITS client must necessarily challenge the
gateway.

My view on who owns the gateway leans in the favor of the PSTN
provider.  Since the gateway can act as a gatekeeper for the
SPIRITS client (and thus the entire PSTN), it probably makes sense
for the PSTN provider to own it.  The gateway can also act as a
protocol translator, for example, translating a SIMPLE presence-
related subscription for a tel URI to the detection points required
by the SPIRITS protocol.  Thus, all this appears to point to the
gateway being owned by the PSTN provider.  If that is the case,
then is requirement 2 in Section 3.1 okay?  Or should we add the
caveat that a trust relationship MUST exist if the gateway is
owned by the PSTN provider; otherwise, each request coming in MUST
be challenged.

> For Requirement 3, who must authorize the request, and on what 
> grounds?  My answer would  be that all users involved and the 
> PSTN provider must authorize it -- the latter based on whether or not 
> the customer has paid, the requestor to avoid false charges, and the 
> subject of the request on privacy grounds.

There are actually 4 cases of authorizing the request in
requirement 3:

(1) the subscriber (SIP entity sending the SUBS) is who she says
     she is,
(2) the subscriber (SIP entity sending the SUBS) has access to
     the resources that are being subscribed to,
(3) the notifier (PSTN account holder) is in good standing
     with the PSTN provider (i.e. is not delinquent in bill
     payment),
(4) the notifier (PSTN account holder) has authorized the
     subscriber (SIP entity sending the SUBS) access to the
     resources being subscribed to

It would appear that only case 1 is solvable by IETF-related
security standards.  Cases 2-4 require OOB policies between
the PSTN service provider and the PSTN account holder.  As
such, there would exist OOB means to do these kinds of
authorization, including as you suggest, whether the customer has
paid and analyzing the subject of the request.

Please correct me if I am wrong in my analysis.

> Requirement 4 shouldn't say "MUST secure the notification",

Done.  Reworded as:

    Requirement 4: The PSTN service provider MUST provide
    confidentiality of the notification requests by encrypting
    them.

> the PSTN MUST accepted encrypted requests.

Will add.

> to encrypt messages and to receive encrypted messages.

Will add.

> 4.1: a shared secret over what security channel?

I am open to suggestions -- two that come to mind are a password
established over a https:// URI, or a password send in US mail.

> it.  sips: is good.  

OK; will take out IPSec.

> "Autonomous system" is a routing concept that's irrelevant here.  

OK; will take it out.

> This document needs to mandate strong-enough security 

Will add one.

> SPIRITS gateway.  This may be out of band; if so, say so.

OK; will do.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216