Subject: [Sipping] New version of the SIP-AAA reqs draft

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 10 Feb 2003 13:46:51 +0200

Hi,

we have released a new version of the SIP-AAA requirements draft. Based
on the feedback we have received, it seems that the draft now includes
all the requirements people had in mind. (Although further comments are,
of course, always welcome).

We will now try to get the work on the diameter-based solution going.

Regards,

Gonzalo

-------- Original Message --------
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-02.txt,.pdf
Date: Thu, 06 Feb 2003 09:30:09 -0500
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;
CC: [email-masked]

--NextPart

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-02.txt,.pdf
	Pages		: 14
	Date		: 2003-2-5
	
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-02.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-02.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-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sipping-aaa-req-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

--OtherAccess--

--NextPart--
_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Mon, 10 Feb 2003 20:19:29 -0600

> We will now try to get the work on the diameter-based solution going.

As has been mentioned here, 99.999% (five nines :-0>) of existing
implementations and deployment are RADIUS. After RADIUS come the web
services. 

I suggest therefore to start with RADIUS instead.

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Gonzalo Camarillo
> Sent: Monday, February 10, 2003 5:47 AM
> To: sipping
> Cc: John Loughney
> Subject: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> Hi,
> 
> we have released a new version of the SIP-AAA requirements 
> draft. Based on the feedback we have received, it seems that 
> the draft now includes all the requirements people had in 
> mind. (Although further comments are, of course, always welcome).
> 
> 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.
> 
> 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.
> 
> 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
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
> 
> --NextPart
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 13 Feb 2003 19:54:14 +0100

>I suggest therefore to start with RADIUS instead.

I'm sharing the same deployment experience and second the same plan: RADIUS.

-Jiri

---

From: [email-masked]
Date: Wed, 19 Feb 2003 07:35:27 +0200

> I suggest therefore to start with RADIUS instead.

i fully agree, juha

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 19 Feb 2003 00:03:36 -0600

I still would like to hear if people think a discussion with the AAA
architecture RG is a good way to get out of this impasse. Please browse
the work at http://www.aaaarch.org/charter.html

It appears there is enough push-back on DIAMETER in this WG that this
should be given some time for discussion at the next meeting. All
messages from the 'audience' favored RADIUS, contrary to the proposed
work agenda.

I have yet to hear an argument why some form of XML documents over some
secure transport, as in Web Services should not be the choice after
RADIUS.

Or are the authors so committed to a DIAMETER project that this
discussion is futile?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, February 18, 2003 11:35 PM
> To: Henry Sinnreich
> Cc: 'Gonzalo Camarillo'; 'sipping'; 'John Loughney'
> Subject: RE: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> Henry Sinnreich writes:
>

---

From: [email-masked]
Date: Wed, 19 Feb 2003 10:37:28 +0200

is there any open source diameter server implementations similar to
freeradius?  

is there a good number of commercial diameter server implementations for
me to choose from?

is there any open source diameter client libraries similar to
radiusclient?

is there any commercial diameter client libraries for me to choose from?

i don't mind using diameter for sip once answers to most of the above
questions is "yes".  as long it isn't, it makes no sense to base sip aaa
work on diameter.

-- juha

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 13:33:48 +0200

I don't think the AAA architecture RG is an engineering alternative
the SIP WG can consider, assuming we want to get this thing deployed
and running in a relatively short time period with many vendors
supporting it.

My preference is DIAMETER. I do agree that we probably need to
look at RADIUS compatibility as well. Perhaps this is the compromise
we need for us to continue? (I don't see a major technical obstacle
to the compatibility; the DIAMETER NASREQ application has been defined
to work with existing RADIUS NASes. If SIP AAA is defined with this
in mind, we can get at least some amount of functionality over
RADIUS. The main problem is perhaps finding standardized RADIUS
attribute numbers, of which we have almost run out... Also naturally,
some new functions of DIAMETER can not be realized through translation
to RADIUS, such as the what requirement 2.3.4 in the SIP AAA requirements
draft indicates. And I would reserve RADIUS mode mainly for
compatibility with old products, not as the mandatory-to-implement
feature in some future RFC. It is seen as the weakest component
in the security of planned network access systems, for instance.)

Perhaps I'm biased for being involved in the DIAMETER work myself.
However, I am also involved with some planned very large scale
applications of SIP, and those folks intend to use DIAMETER --
they are also building products in this space.

Finally, a few comments to the SIP-AAA requirements:

- The security requirements might be expanded a bit.
   Are proxies going to be needed? Is end-to-end
   security through proxies necessary for some reason?

- The document does not mention anything about reliability
   of AAA transactions, accounting in particular. I would
   think this is of high interest, as Allison also noted.

- Do we really need both cumulative and non-cumulative
   accounting?

- 2.4.2 and 2.4.3 are unclear to me. What is really
   required here?

- Section 3.2 example is a bit thin. I suspect there's
   more to it than this.

- John's address has a non-ASCII character.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 10:01:40 +0200

Jari

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 20 Feb 2003 17:36:13 -0600

> I don't think the AAA architecture RG is an engineering 
> alternative the SIP WG can consider,

It would be only fair to include the aaaarch folks in this discussion.
They have done serious work - applicable to the real world.

Thanks, Henry

> On Behalf Of Jari Arkko
> Sent: Wednesday, February 19, 2003 2:02 AM
> To: Henry Sinnreich
> Cc: [email-masked]; 'Gonzalo Camarillo'; 'sipping'; 
> 'John Loughney'
> Subject: Re: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> 
> I don't think the AAA architecture RG is an engineering 
> alternative the SIP WG can consider, assuming we want to get 
> this thing deployed and running in a relatively short time 
> period with many vendors supporting it.
> 
> My preference is DIAMETER. I do agree that we probably need 
> to look at RADIUS compatibility as well. Perhaps this is the 
> compromise we need for us to continue? (I don't see a major 
> technical obstacle to the compatibility; the DIAMETER NASREQ 
> application has been defined to work with existing RADIUS 
> NASes. If SIP AAA is defined with this in mind, we can get at 
> least some amount of functionality over RADIUS. The main 
> problem is perhaps finding standardized RADIUS attribute 
> numbers, of which we have almost run out... Also naturally, 
> some new functions of DIAMETER can not be realized through 
> translation to RADIUS, such as the what requirement 2.3.4 in 
> the SIP AAA requirements draft indicates. And I would reserve 
> RADIUS mode mainly for compatibility with old products, not 
> as the mandatory-to-implement feature in some future RFC. It 
> is seen as the weakest component in the security of planned 
> network access systems, for instance.)
> 
> Perhaps I'm biased for being involved in the DIAMETER work 
> myself. However, I am also involved with some planned very 
> large scale applications of SIP, and those folks intend to 
> use DIAMETER -- they are also building products in this space.
> 
> > architecture RG is a good way to get out of this impasse. Please 
> > browse the work at http://www.aaaarch.org/charter.html
> > 
> > I have yet to hear an argument why some form of XML documents over 
> > some secure transport, as in Web Services should not be the choice 
> > after RADIUS.
> > 
> > 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
> > 
> > 
> 
> 
>