Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-00.txt

From: [email-masked]
Date: Thu, 12 Sep 2002 07:57:31 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Authentication, Authorization and Accounting 
                          Requirements for the Session Initiation Protocol
	Author(s)	: J. Loughney, G. Camarillo
	Filename	: draft-ietf-sipping-aaa-req-00.txt
	Pages		: 13
	Date		: 2002-9-11
	
As SIP services are deployed on the Internet, there is a need for
authentication, authorization and accounting of SIP sessions. This
document sets out the basic requirements for this work.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-aaa-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-aaa-req-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Sep 2002 11:24:24 +0300

Hello,

we have tried to make this new version of the SIP-AAA requirements draft
more protocol agnostic. We have tried to remove 3G specific stuff as
well.

Now the draft sets requirements on the SIP-AAA interface, leaving out of
scope host requirements and the like.

Feedback is appreciated,

Best regards,

Gonzalo

[email-masked] wrote:
>   ------------------------------------------------------------------------

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
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: AC Mahendran <[email-masked]>
Date: Fri, 20 Sep 2002 11:07:55 -0700

Gonzalo:

I have a question regarding the following requirement:

"The SIP-AAA interface MUST support accounting per media component (e.g., 
voice and video). The SIP-AAA interface MUST enable different parties to be 
charged per media component."

This requirement assumes the SDP contents are visible to SIP servers. But, 
with end-to-end encryption this might not be possible. So, is this 
requirement 3G specific?

thanks,
AC

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 23 Sep 2002 08:37:23 +0300

inline,

> with end-to-end encryption this might not be possible. So, is this

When we talk about the SIP-AAA interface, we talk about "SIP entities",
which may or may not be proxies. A SIP-PSTN gateway, which is a SIP UA,
can querry AAA before authorising a video call over the PSTN.

Regards,

Gonzalo

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 23 Sep 2002 21:44:28 +0300

a few comments:

i didn't understand this:

        CANCEL is a hop-by-hop request that can be generated by
        proxies. SIP servers receiving a CANCEL do not challenge
        it, as they would do with an end-to-end request. Instead,
        they check that the entity sending the CANCEL is the same
        as the one that generated the request being canceled.

how can a proxy verify without authentication which ua sent a cancel and
thus if that ua also sent the request being canceled?

   The scheme supported for the authentication between the SIP servers
   and the AAA infrastructure MUST be flexible enough to accommodate a
   variety of authentication mechanisms.

i think that there should be a requirement that the aaa scheme MUST
support authentication of requests where digest authentication is used
between the ua and the proxy and any other authentication mechanism that
is mandated by the current sip specs.  that is, it would not make sense
to select an authentication scheme that would require some new
authentication mechanism between the ua and the proxy.

regarding accounting, it looks like the weakest part of the document.
what should be accountable: dialogs, their duration, volume of data
send, sip protocol messages themselves, requests outside dialogs, etc?
real-time push or pull or accounting data between the aaa server and the
sip server, threshold setting requirements, etc?

-- juha