Subject: RE: [SIP] authentication at gateway

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 5 Jul 2000 21:45:52 -0500

My study of gateway capabilities has not revealed an answer to Serban's
question other than that authentication (via the scenarios described) is not
available in gateways today and is not likely to show up anytime soon if at
all.  IMO, the most likely solution is very much like #3 for the scenario
given.  An MCGP or Megaco compliant gateway can collect and report DTMF
digits in signaling separate from the media.  However, this requires the SIP
UAS to also "speak" one of these protocols (obviously, not a good solution
at all).  In networks where PSTN phones are served there is also likely to
be a Gateway Controller that provides an interface between the gateway and
SIP UA.   A practical and feasible approach is to extend the gateway's
MGCP/Megaco-based event detection and reporting to SIP UAs (for which at
least one solution has been proposed).  The application-specific prompts can
be provided by the application server and leave the gateway to performing
its "gateway" functions.  A SIP "only" (non MGCP/Megago specific) solution
for PSTN-phone event detection and reporting (as has also been proposed)
would allow the service to be agnostic to the endpoint type but may not map
to MGCP and Megaco.

Maybe we'll see a solution in the near future for all terminals (SIP, PSTN,
others?).

Bert

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Wednesday, July 05, 2000 6:02 PM
To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu
Cc: siplist
Subject: RE: [SIP] authentication at gateway

>I suggest that the appropriate
>"converged"
>architecture is to have authentication controlled from outside
>the gateway and to implement it via a SIP Proxy(like?)
>element in
>situations where we want the core service to be
>agnostic as to whether
>the endpoint is a gateway or a UA.

Exactly right!

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>Gardell, Steve
>Sent: Wednesday, July 05, 2000 6:42 AM
>To: 'Jonathan Rosenberg'; Serban Tatu
>Cc: siplist
>Subject: RE: [SIP] authentication at gateway
>
>
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto:[email-masked]]
>> Sent: Wednesday, July 05, 2000 12:01 AM
>> To: Serban Tatu
>> Cc: siplist
>> Subject: Re: [SIP] authentication at gateway
>>
>>
>> THe most likely scenario is one you left out: the
>prompting and
>> collection for the PIN are all performed by the originating
>> gateway. In
>> general, the entity demanding authentication will
>not know that the
>> request is through a gateway. I believe its unlikely
>the entity would
>> return 200 OK, or even a 401 with content. Rather,
>just a 401.
>>
>> So, upon receiving the 401, the gateway performs some local
>> operation to
>> get the username and password. Perhaps it plays out an
>> announcement and
>> collects the username/password; perhaps they are
>simply established
>> ahead of time and stored in a database - the gateway
>just fetches them
>> when prompted for authentication.
>>
>
>
>A practical issue with this approach is that gateways are often
>deployed in support of many different services that may have
>different authentication requirements. Placing all of the
>authentication smarts in the gateway makes it difficult to roll
>out new services. Now admittedly this is a "telco centric" view
>of the service world - I suggest that the appropriate
>"converged"
>architecture is to have authentication controlled from outside
>the gateway and to implement it via a SIP Proxy(like?)
>element in
>situations where we want the core service to be
>agnostic as to whether
>the endpoint is a gateway or a UA.
>
>
>> -Jonathan R.
>>
>> Serban Tatu wrote:
>> >
>> > Hi,
>> >
>> > How is authentication performed by a SIP-enabled gateway?
>> Let's say somebody on
>> > a PSTN phone wants to gain access to a service and
>> therefore has to provide a
>> > username/password. Some scenarios come to mind
>(<attention>newbie
>> > here</attention>):
>> >
>> > Scenario 1 (smart gateway):
>> >
>> > - SIP UAS at service side sends a 401 unauthorized as a
>> response to the INVITE.
>> > The response contains a voice prompt audio file (e.g.
>> <announcer_voice>Gimme
>> > username/password</announcer_voice>).
>> > - gateway is so smart that it knows how to play the prompt
>> and collect DTMF
>> > tones representing username and password, which it then
>> sends back encoded
>> > somehow to the service.
>> >
>> > Scenario 2 (not so smart gateway):
>> >
>> > - SIP UAS at service side sends back a 200 OK response to
>> the INVITE. The
>> > response contains the voice prompt as before.
>> > - gateway knows how to play the audio file, sends ACK,
>> media connections are
>> > open.
>> > - SIP UAS at service side then sends an INFO
>message with a
>> DTMF collection
>> > scheme (voice prompt could also be sent here).
>> > - gateway collects the tones and sends them back with
>> another INFO message.
>> >
>> > Scenario 3 (dumb gateway):
>> >
>> > - SIP UAS at service side sends back a 200 OK response to
>> the INVITE.
>> > - gateway and SIP UAS establish their media channels.
>> > - service then plays the whole authentication scenario
>> through the media
>> > channels. Gateway lets DTMF tones flow through the
>media path.
>> >
>> > Do any of these scenarios make any sense? It seems to me
>> that 1 and 2 are sci-fi
>> > given the current gateway solutions, while 3 might not be
>> possible because the
>> > gateway grabs the DTMF tones, or if it doesn't
>then it's an
>> ugly solution since
>> > signaling and media are all mixed together.
>> >
>> > Thanks,
>> > Serban
>>
>> --
>> Jonathan D. Rosenberg                       72 Eagle
>Rock Ave.
>> Chief Scientist                             First Floor
>> dynamicsoft                                 East
>Hanover, NJ 07936
>> [email-masked]                     FAX:
>(973) 952-5050
>> http://www.cs.columbia.edu/~jdrosen         PHONE:
>(732) 741-7244
>> http://www.dynamicsoft.com
>>
>>
>> _______________________________________________
>> SIP mailing list
>> [email-masked]
>> http://lists.bell-labs.com/mailman/listinfo/sip
>>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2000 23:59:17 -0400

You are merging a bunch of issues here which are really separate.

I agree that each service will have its own means of authenticating
users of that service. SIP already provides three ways of obtaining
authentication for requests - http basic, http digest, and pgp. If the
service wishes to use these mechanisms to authenticate subscribers, than
that is its decision. If the entity acting as UAC (gateway or
softswitch) cannot obtain information required to provide credentials,
then users through that gateway can't access those services. 

If an application wishes to authenticate through a media conversation,
this is also its choice. Doing so works just fine now with SIP, by
collecting DTMF or doing speech recognition or whatever, as part of the
media stream, using 183, for example, to establish early media. This
will alleviate the gateway from the "burden" of authentication from each
service, as requested, and do so in a manner which works for gateways,
PC clients, IP phones, or whatever, in a uniform fashion. These
mechanisms are not all that secure in reality (remember, this ain't the
PSTN anymore), but thats also a separate issue.

It is a separate and orthogonal issue as to whether the DTMF is carried
within SIP, and orthogonal and separate once again about whether SIP UAs
need to speak megaco in order to be controlled by a device providing
services. I have many comments on this issue, and it is on my todo list
to collect them and respond to the earlier thread on the subject. In any
case most of you can guess my feelings on mandating megaco in a SIP UA
in order to access services.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 07 Jul 2000 15:18:32 -0500

A SIP "only" (non
>MGCP/Megago specific) solution

There are several reasons why the service has to be agnostic of
the type of client. Such as for
1. the ease of introduction of new services and
2. any to any communications.

Client specific knowledge, such as MGCP inside is IMHO a very
bad architecture.

Henry

>From: Culpepper, Bert
>[mailto:[email-masked]]
>Sent: Wednesday, July 05, 2000 9:46 PM
>To: Henry Sinnreich; Gardell, Steve; 'Jonathan
>Rosenberg'; Serban Tatu
>Cc: siplist