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

From: Michael Hammer <[email-masked]>
Date: Tue, 05 Feb 2002 10:03:23 -0500

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]
>Ph. +1 613 736 0961 (ESN 396 1490)
>

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Feb 2002 21:10:29 -0600

There are SIP mechanisms that allow servers to ascertain the identities of
remote users - just to pick one out of a hat, let's look at the Digest
authentication scheme. 

When the gateway receives an INVITE, it sends a challenge (401) in response.
The user retries the request with a Digest username and password
(corresponding to its account at this gateway operator's network). This
username and password could be used by the gateway to retrieve a particular
phone number and/or caller name corresponding to 'the subscriber in whose
name service is being requested', returning to Tom's original question. The
gateway could then use this information to populate a CgPN field and
whatever other ISUP fields it liked. It might even overwrite any telephone
number that happened to appear in the From field of the request with its own
data.

Or, the gateway could merely retrieve an account number for the user, and
record this number in some sort of event block/CDR that it cuts for this
call - in this instance it could send a common 'gateway number' rather than
an individual subscriber's number in the CgPN, if it were so inclined. If a
malicious trace were subsequently required, the gateway operator could find
the event block in question and provide the user's account information to
the authorities.

The point is, none of this requires any changes to SIP (or the SIP-ISUP
mappings) that I'm aware of.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, February 05, 2002 12:08 PM
> To: Sean Olson
> Cc: Tom-PT Taylor; [email-masked]
> Subject: Re: [Sipping] Status Check: Subscriber Identification
> 
> 
> Right, however that wasn't my question. The privacy draft, and in
> particular the Remote-Party-Id is intended to provide the identity
> information, however it does not specify the authentication 
> mechanism by
> which the identity is determined, which is why I asked Tom to clarify.
> 
> -- Flemming
> 
> Sean Olson wrote:
> 
> > Given the intended usage of this identifier, a
> > non-authenticated subscriber ID would not be
> > very useful.
> >
> > /sean
> >
> > --- Flemming Andreasen <[email-masked]> wrote:
> > > Do you mean authenticate the subscriber or simply
> > > provide an
> > > identification of the subscriber that subsequent
> > > hops can use ?
> > >
> > > -- Flemming
> > >
> > > 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
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > > Sipping mailing list
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > =====
> > Sean Olson <[email-masked]>
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send FREE Valentine eCards with Yahoo! Greetings!
> > http://greetings.yahoo.com
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
>

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 7 Feb 2002 03:02:49 -0500

I mean authenticate.  

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 7:36 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: Re: [Sipping] Status Check: Subscriber Identification

Do you mean authenticate the subscriber or simply provide an
identification of the subscriber that subsequent hops can use ?

-- Flemming

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

--
Flemming Andreasen
Cisco Systems

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 7 Feb 2002 03:02:50 -0500

I had this in mind, but was confused by the availability of the
Remote-Party-Id.  What we write into the interworking specification at SG 11
may be of the order of: "an authenticated subscriber ID is obtained by means
beyond the scope of this specification", or I may find that people insist on
more details.  I'll try to get away with the minimum.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 4:10 AM
To: 'Flemming Andreasen'; Sean Olson
Cc: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: RE: [Sipping] Status Check: Subscriber Identification

Jon Peterson
NeuStar, Inc.