Subject: RE: [Sipping] Status Check: Subscriber Identification

From: "Christian Huitema" <[email-masked]>
Date: Wed, 6 Feb 2002 13:20:05 -0800

> I would imagine a model where if Alice, as customer of SP A, move into
> B's territory, B sees that I'm really A's customer. Assuming A has a
> relationship with B (otherwise, you don't get roaming, regardless of
> authentication), B sends a request to A (with its signature) saying
> "Your customer Alice wants to roam in my network. Here's her signed
> admission request. Is this legit, has she paid her bills and do you
> trust her enough to allow her to roam?". A then either agrees or not.
If
> A does, A will pay B, and collect money from Alice. Thus, no need for
B
> to know Alice as an individual. None of this requires more technology
> than what's available off-the-shelf today.

Why should this be SIP's problem? There are already solutions for
roaming at the network level, e.g. combinations of media access control
(PPP, 802.1x) and AAA protocols (Radius). Money is actually being
collected that way today. When Alice roams into B, she only gets local
IP service because she can perform this authentication. Once she has IP
access, she can just as well REGISTER her new location with A's SIP
proxy -- using IPSEC or TLS if needed.

-- Christian Huitema

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Feb 2002 16:33:24 -0500

I should have made this clear, but as I said earlier, this is not a
SIP-specific problem and thus the solution should not be SIP-specific. I
don't think RADIUS does cross-domain authentication yet, but I haven't
followed the AAA stuff closely.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Feb 2002 07:57:50 +0200

> followed the AAA stuff closely.

there are several roaming service providers, such as gric and ipass,
that proxy radius requests between domains.

-- juha

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Feb 2002 09:13:22 -0500

> that proxy radius requests between domains.

From what you know, do they worry about carrier authentication?
Presumably, they could just set up IPsec tunnels between each other, as
the number of associations is finite.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Feb 2002 21:08:33 +0200

> the number of associations is finite.

they could use ipsec tunnels between the member radius servers and the
radius server of the clearing house, but i think that currently they
simply rely on the server/client password based authentication that is
part of the radius protocol.

-- juha

---

From: Michael Hammer <[email-masked]>
Date: Thu, 07 Feb 2002 14:54:49 -0500

What I gathered from this thread (using Michael Thomas model) is that:

O: originator
T: terminator
OP: originating proxy/registrar
TP: terminating proxy/registrar
IP: intermediate proxy
cr: credentials
au: authorization indicated by sender

In a bilateral scenario:

Forward path:
O--Ocr-->OP--Ocr,OPcr-->TP (HLR-like function)
Reverse path:
TP--TPcr,TPauOP,TPauO-->OP--TPcr,TPauOP-->0
meaning:
OP trust TP from authenticating TP (from TPcr) and embedded transitively
    trust O from receipt of authorization (TPauO)
TP trust OP from authenticating OP (from OPcr) and embedded transitively
    trust O (from Ocr)
O trust TP from authenticating TP (from TPcr) and embedded transitively
   trust OP (from TPauOP)

So the relationships are:  O to OP, O to TP, and OP to TP
which uses potentially three different security mechanisms.  The thread 
only addresses the OP->TP->O transitive trust case.  Other trust 
requirements are omitted.

This can be expanded to the clearinghouse case (Juha comment) by inserting 
the intermediate proxy into the forward and backward chain:
O-->OP-->IP-->TP-->IP-->OP-->O  and including the credentials for each 
along the path.  Now the trust chain (for trusting the subscriber only) is:
OP->IP->TP->O

Now add the actual call:  (forward and reverse path)
O-->OP-->IP-->TP'-->T'-->TP'-->IP-->OP-->0
where ' indicates domain of callee versus home domain of caller.
So now there needs to be trust between O, OP, IP, TP, TP', T'.

Repeat the above for every combination of roaming caller and callee.

We seem to be relying on three assumptions:
1)  The UA and a home proxy/registrar use the same mechanism.
2)  The proxies are able to find a common mechanism between any pair.
3)  A transitive trust chain is required with proxies vouching for UAs.

I need to read more on the current meaning of protocol elements and whether 
this provides the 'vouching' semantics that would provide this transitivity.
Otherwise, a visited proxy cannot trust the UA.  Nor can the callee or any 
other proxy on the path unless they share the same system as the requesting UA.

Mike