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

From: [email-masked]
Date: Wed, 06 Feb 2002 02:54:02 EST

On 5 Feb, Mike Hammer wrote:

> Tom,

> This problem of having to identify the customer before proceeding to 
> provide service is a characteristic of  mobile networks.  I suspect that a 
> similar authentication and authorization process will be required.  But, 
> that pre-supposes an infrastructure to handle that.  I would assume that it 
> would also support wired and wireless mobility.

> Yet, some of the drafts I have seen suggest that such infrastructure is 
> undesirable.  I think the group should decide whether they are serious 
> about this, then bite the bullet and get on with it.

> Mike

> At 09:33 AM 2/5/2002 -0500, Tom-PT Taylor wrote:

> >At one point in the thread "calling number blocking at sip/isup gateway" a 
> >few of us seemed to agree that it must be possible for the gateway to 
> >identify the subscriber in whose name service is being requested.  What if 
> >any is the intended SIP mechanism to meet this requirement?
> >
> >Tom Taylor
> >[email-masked]

It seems to me that the existance of an infrastucture must be assumed in order to handle authentication. It can't be done on a worldwide network supporting everyone without one. Yes, I know there are those who believe any assumed infrastructure is undesirable when one is talking about the Internet, but then, sometimes undesirable things are still necessary.

Mike

_______________________________________________
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 09:16:06 -0500

However, this infrastructure may have nothing whatsoever to do with SIP
or Internet telephony. For example, there is no reason you couldn't
reuse the personal certs that companies, universities, Internet2 and
various "public" CAs (Thawte, AT&T, Verisign, etc.) hand out, primarily
for email use. All of these infrastructures have limitations, as has
been amply discussed here and on the sip list, but the important point
is that "infrastructure" may (and probably should not be)
service-specific.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 06 Feb 2002 10:24:43 -0500

Granted.  But, then there is no guarantee that a user can be authenticated 
by anyone but the local service provider originally subscribed to.  At that 
point forget mobility.  The degree of universality of the supporting 
mechanism will restrict the universality of the service.  Think about what 
roaming looked like in the first version of mobile networks.

Mike

At 09:16 AM 2/6/2002 -0500, Henning Schulzrinne wrote:
> > It seems to me that the existance of an infrastucture must be assumed 
> in order to handle authentication. It can't be done on a worldwide 
> network supporting everyone without one. Yes, I know there are those who 
> believe any assumed infrastructure is undesirable when one is talking 
> about the Internet, but then, sometimes undesirable things are still necessary.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Feb 2002 10:46:09 -0500

In many cases, what I care about is to identify a small subset of
people. Except for malicious call tracing, I don't get much benefit of
knowing that Alice Smith (as opposed to somebody impersonating Alice
Smith), whom I have never met and don't know, calls. As long as
identities are cheap, negative filtering doesn't work. For positive
filtering, semi-closed user communities are not ideal, but workable.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 06 Feb 2002 11:04:48 -0500

OK, but what about billing and regulatory requirements?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Feb 2002 12:14:20 -0500

Regulatory issues are constantly changing (and it's not clear exactly
which apply to different services), so let me address the roaming aspect
of billing. (Local billing is obviously easier - your SP hands you a
suitably signed credential.) 

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. 

Substitute various clearing houses to avoid N^2 scaling issues.

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Feb 2002 13:55:27 -0600

You mean "the stuff we do authentication for"?

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Thu, 07 Feb 2002 15:36:39 -0500

Yes.  I am assuming that a service provider needs positive filtering (if I 
understand that) to determine when to permit signaling and bearer 
connections to proceed to use resources of their network.

Mike

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 8 Feb 2002 00:39:55 -0600

Well, I don't know about the other guys, but I tend to request
authentication headers (if not present, use 401/407 to get) rather than
trust any kind of calling-party-ID header to provide positive identification
of the user. That sort of implies that the authentication framework needs to
be either global or provide an attributable and verifiable transitive model
(Cisco's proxy said this guy was Mike Hammer, and I can prove Cisco's proxy
said it).

--
Dean

----- Original Message -----
From: "Michael Hammer" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "Henning Schulzrinne" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 07, 2002 2:36 PM
Subject: Re: [Sipping] Status Check: Subscriber Identification

> > > > > by anyone but the local service provider originally subscribed to.
At
> >that
> > > > > mechanism will restrict the universality of the service.  Think
about
> >what

---

From: Michael Hammer <[email-masked]>
Date: Fri, 08 Feb 2002 11:11:07 -0500

Dean,

Agree with you fully there.  The privacy draft unfortunately punts when it 
comes to how the authentication is done.  In looking at the authentication 
headers, is it possible to specify what header types are covered by the 
algorithm, or is that assumed to be every header except the authentication 
header and certain headers that get modified or new ones inserted along the 
signaling path?  I was looking in the bis draft to see which headers those 
were, but was having trouble finding it.

Mike

p.s.  In the privacy draft, I was amused by the sections titled Untrusted 
UAC Behavior and Untrusted UAS Behavior.  Seemed like those could be one 
sentence long:  "Same as Trusted UAx Behavior, but don't expect that any of 
the rules will be followed." :-)

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 08 Feb 2002 12:01:21 -0500

Michael Hammer wrote:

> comes to how the authentication is done.

That was a conscious decision motivated by the fact that authentication and
identity representation are two different things and there can be many different
ways of performing the authentication. The original apprach of defining just one
authentication mechanism was clearly not general enough here, so you either start
defining all possible mechanisms, or recognize that this is really a separate
problem that should be dealt with separately. We opted for the latter.

> In looking at the authentication

You probably didn't read them very carefully then since:
1. A trusted UA SHOULD include a calling party Remote-Party-Id whereas no such
requirement exists for an untrusted UA
2. A trusted UA has to apply the requested privacy for any Remote-Party-Id prior
to crossing a trust boundary, whereas an untrusted UA does not.

While you could cut down on the text here, experience shows that it doesn't
further correct implementation.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 14:27:54 -0500

I think people get bent out of shape on the privacy drafts because they
think it is trying to solve problems it doesn't. Practically speaking,
IMHO, the privacy R-PID provides a way for a domain with a trust
relationship with a user, to authenticate that user (using digest or
whatever), and then pass on that identity to other elements within the
domain for use. Similarly, if a request comes in and is not
authenticated, it provides a way to convey that as well. 

It can work between domains only if a trust relationship is there to
make sure that the proper interpretation and treatment are given to this
information. Generally, that won't be the case.

-Jonathan R.

Dean Willis wrote:
> > > > >people. Except for malicious call tracing, I don't get much
> benefit
> of
> > > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Michael Hammer <[email-masked]>
Date: Fri, 08 Feb 2002 16:31:36 -0500

>problem that should be dealt with separately. We opted for the latter.

I was able to infer that and have no problem with that.  I shouldn't have 
said "unfortunately".  I was simply noting that more pieces of the puzzle 
are needed to complete the picture.

>further correct implementation.

That got buried.

The problem I had in reading this draft related to the fact that trust 
involves two parties, where one is "trusting" and the other is 
"trusted."  If you look at Figure 3, it indicates that both UAs are 
trusted, but in describing the trust relationships below the diagram B) it 
indicates that there really is not any trust there.

The UA can add or not add protocol elements and perform actions on existing 
protocol elements based on whether it trusts the next hop.  (Perhaps it 
should be called "Trusting UA Behavior"?)  The proxy can trust the data it 
receives based on the ability to authenticate the information, either 
in-band or out-of-band, or based on a dependency like lower layer transport 
encryption used.

The actions you define above seem to be self-defining.  In other words, if 
the UA properly takes protocol actions X, Y, and Z, then it is acting in a 
trust-worthy manner.  If it doesn't, then it is not.  The proxy upon 
examining the message can see whether the syntax was properly formed.  But, 
additional verification is needed to determine whether the information is 
bogus or not.

The fact that early in the document it mentions that one proxy may not 
trust another proxy, yet there is no equivalent section present for 
"untrusted proxy behavior", means that it is possible to describe that in 
one section.

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 10 Feb 2002 01:50:27 -0600

Unfortunately, despite telling you "who" more precisely than the RPID
headers do at this time, digest authentication as currently practiced leaves
a lot lacking in the area of integrity protecting request headers, leaving
it open to a variety of extended replay attacks. There has been a lot of
work in this area (several drafts discussed at previoud IETF meeting) and we
currently have a design team in the SIP working group worrying away at the
problem.

--
Dean

----- Original Message -----
From: "Michael Hammer" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 08, 2002 10:11 AM
Subject: Re: [Sipping] Status Check: Subscriber Identification

benefit