Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er

From: "Dolan, Michael F (Mike)" <[email-masked]>
Date: Mon, 9 Jul 2001 22:23:15 -0500

Ashhar,

3GPP2 is planning to use DIAMETER to capture and share such call record data
across system boundaries.  The AAA broker approach works well in this
application.  Is it necessary to re-create that entire mechanism in SIP as
well (along with proper authentication, etc.)?

Mike Dolan

Lucent Technologies - Bell Labs
263 Shuman Blvd., Room 2D-229
Naperville, IL 60566-7050,  USA
* Office:  +1.630.979.1033
* Mobile:  +1.630.697.3549
* Email:   [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----Original Message-----
From: Ashhar Farhan [mailto:[email-masked]]
Sent: Friday, July 06, 2001 11:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [SIP] Authentication and billing through proxy/re-direct server

by now, it is well understood that some sort of recording of the calls made
by a third party call-logging system is a requirement for many operative
networks. therefore we need a way of propagating CDRs to a remote entity.
for this, we have three options available to us:
1) introduce a new type of request message.
2) use NOTIFY with CDR in the body.
3) use MESSAGE with CDR in the body.
my personaly preference will be to NOTIFY the remote call-logger.
this is the simpler part of the issue.

about authentication:
authentication of a client with the gateway is a requirement. this
requirement is not necessarily for the purposes of billing. for instance, an
enterprise gateway may want to provide access to only certain caller. or a
personal gateway run at home over the DSL where only some are allowed to
call.

at all these times, the gateway needs to authenticate the caller without any
secret-sharing between them. therefore, there is a clear need for the
participation of the registrar or some other authenticating service to do
this.
if A calls B. B asks C is A real? C says yes because i have his secret.

while we could demand that the callers obtain their PGP keys, this is not a
workable solution. we need a simple, effective solution for this within the
SIP functionality (correct me if i am wrong on this).

my suggestions are like this:

1) Caller A issues an INVITE for the gateway to the proxy server.
2) proxy server challenges A, receives the correct response.
3) proxy server now proxies the INVITE to the gateway with no
authentication.
4) gateway challenges the proxy. proxy responds back with the digest over
the message headers, gateway password and the nonce issued by the gateway
(as described in the SIP RFC).

the second scheme is completely within the SIP framework. i wonder if a
stateless implementation of this scheme is possible.

____________________________________________________
Buy Feng Shui Package for Rs. 151/- only, at
http://shopping.rediff.com/shopping/fengshui_mailer.htm

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 10 Jul 2001 06:38:31 -0500

>3GPP2 is planning to use DIAMETER

Other approaches at the AAA level such as using XML/SSL may be
preferable to Diameter.
Diameter would certainly make a very poor application policy server -
see <draft-gross-sipaq-01.txt >.

AAA should not be burdened with legacy from dial-up, but rather fit into
the W3C web services architecture.
What do you think?

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Dolan,
Michael F (Mike)
Sent: Monday, July 09, 2001 10:23 PM
To: Ashhar Farhan; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
serv er

Ashhar,

3GPP2 is planning to use DIAMETER to capture and share such call record
data
across system boundaries.  The AAA broker approach works well in this
application.  Is it necessary to re-create that entire mechanism in SIP
as
well (along with proper authentication, etc.)?

Mike Dolan

-----Original Message-----
From: Ashhar Farhan [mailto:[email-masked]]
Sent: Friday, July 06, 2001 11:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];

by now, it is well understood that some sort of recording of the calls
made
by a third party call-logging system is a requirement for many operative
networks. therefore we need a way of propagating CDRs to a remote
entity.
for this, we have three options available to us:
1) introduce a new type of request message.
2) use NOTIFY with CDR in the body.
3) use MESSAGE with CDR in the body.
my personaly preference will be to NOTIFY the remote call-logger.
this is the simpler part of the issue.

about authentication:
authentication of a client with the gateway is a requirement. this
requirement is not necessarily for the purposes of billing. for
instance, an
enterprise gateway may want to provide access to only certain caller. or
a
personal gateway run at home over the DSL where only some are allowed to
call.

at all these times, the gateway needs to authenticate the caller without
any
secret-sharing between them. therefore, there is a clear need for the
participation of the registrar or some other authenticating service to
do
this.
if A calls B. B asks C is A real? C says yes because i have his secret.

while we could demand that the callers obtain their PGP keys, this is
not a
workable solution. we need a simple, effective solution for this within
the
SIP functionality (correct me if i am wrong on this).

1) Caller A issues an INVITE for the gateway to the proxy server.
2) proxy server challenges A, receives the correct response.
3) proxy server now proxies the INVITE to the gateway with no
authentication.
4) gateway challenges the proxy. proxy responds back with the digest
over
the message headers, gateway password and the nonce issued by the
gateway
(as described in the SIP RFC).