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

From: [email-masked]
Date: Wed, 28 May 2003 10:23:00 -0600

Steve, Vijay,

In the interest of timely completion of the prtocol I would
like to propose to focus ONLY on the case where the GATEWAY
is owned and managed by the PSTN operator.
What do you think?

Regards,
Alec

> > 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?
> 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", since "secure" has many meanings.  Say
> > "encrypt" or "provide  confidentiality".
>
> Done.  Reworded as:
>
>     Requirement 4: The PSTN service provider MUST provide
>     confidentiality of the notification requests by
> encrypting
>     them.
>
> > 3.2 should add "the subscriber MAY encrypt requests";
> > the gateway and  the PSTN MUST accepted encrypted
> requests.
> Will add.
>
> > 3.3 should mention the types of authorization needed,
> > plus the ability  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.
> > 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.
>
> 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
> > 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.
>
> Will add one.
>
> > The client needs some trustworthy way of learning the
> > address of its  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
> _______________________________________________
> SPIRITS mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/spirits
>
_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 29 May 2003 09:27:48 -0500

> is owned and managed by the PSTN operator.

I don't have any problems with that; we can predominantly
assume that model in the I-D.

But to be safe, we should sprinkle in some verbiage that
suggests some form of authentication/encryption if the gateway
and SPIRITS client are not owned by the same entity.

- 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

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 29 May 2003 12:48:31 -0400

As someone who is so old as to remember the history, I will cast my vote in
support of Alec's intervention.

This "gateway" thing, as far as I am concerned, has been an abomination in the
first place, which was first created in PINT as a compromise between the ITU and
IETF parties to create a no man's land, sort of like a minefield along the
border between Hungary and Yugoslavia in the time of the Iron Curtain. (It has
been removed now.)

The real model has always been that the communications are maintained end-to-end
between an Internet host and the SCF. But then, by no means, would I want to
disturb previous agreements. They are documented, and they are--to the best of
my knowledge--architecturally sound.

This is why I believe that for all practical reasons we should assume that the
gateway is in the PSTN. It is much better to have less text than more,
especially when the "more" part relates to an irrelevant scenario never to be
implemented.

Igor

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 29 May 2003 12:05:21 -0500

Igor Faynberg wrote:
[...]
> This is why I believe that for all practical reasons we should assume 
> that the gateway is in the PSTN. It is much better to have less text 
> than more, especially when the "more" part relates to an 
> irrelevant scenario never to be implemented.

Igor:

I agree that for all practical reasons, the gateway is in the
PSTN (any way you slice and dice it, you will come out to
the same conclusion).  We can leave it at that.

Regarding the usuability of the gateway, I am now convinced that
unlike PINT, where its usability was limited, in SPIRITS it has
a useful place.  Initially, I viewed the gateway as merely a
proxy, but on talking to others, it seems that there is a useful
role for the gateway in SPIRITS.

Consider for instance commercial IM UAs (like MSN Messenger, which
does speak SIP) or others based on SIMPLE.  It is highly unlikely
that these UAs will concern themselves with subscribing to IN DPs in
order to create a presence-based subscription for a tel URI.
Chances are that they will simply use the mechanisms outlined in
<draft-ietf-simple-presence-10.txt> to subscribe for presence on
a PSTN line.  The gateway can actually step in at this time and
accept a plain SIMPLE presence subscription and turn it into the
various DPs that are available (and implemented) by the SCF it
is working with.  Thus, some actual form of protocol conversion
can be done by the gateway; in this case, turning vanilla
presence documents into a type acceptable by the SCF.

Does that make sense?

Thanks,

- vijay

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 29 May 2003 14:08:26 -0400

"Vijay K. Gurbani" wrote:
>...
>...

No, no, no! SPIRITS and PINT are the same thing, or more precisely, they are
mirror images of each other. Besides, no SPIRITS service (except maybe ICW) that
can really be implemented without what constitues a PINT service, nor could PINT
conference calling be implemented without SPIRITS.

The division between PINT and SPIRITS was division of work between two WGs. 

If any solution violates the architectural principles then I would be inclined
to say that the solution is wrong, and we must find the one that violates
nothing. (Because the alternative would be to restart the architectural work
from the beginning, which I think is unwarranted.)

This is not to say that a proxy may not be outside of the PSTN. Of course it may
(and has to)! But it should not have a function of the SPIRITS gateway then.

Igor