Subject: [Sipping] Attempted summary of SIP-AAA discussion

From: [email-masked]
Date: Fri, 21 Feb 2003 20:19:38 +0200

Hi all,

So, it seems that there are the following needs:

1) Compatability with existing RADIUS infrastructure.

2) Support for Diameter for the 3G community
  (I believe both 3GPP and 3GPP2 will be using Diameter).

3) Some vague handwaving about Web Services.

It seems that there are some expired drafts on using
RADIUS for at least 2 of the AA's in AAA.  Expired
drafts don't usually count for much, however.

A way forward would be to have the authors of the expired
drafts to update them and re-submit them.  A solution
sufficient for 3G is in the works, so I have heard.
I have seen no concrete proposals for web services, so 
until I see one in a draft, I am going to discount it
entirely.

So, after all of the possible solutions are re-issued in
draft form, probably the SIPPING WG chairs, AAA WG chairs
and relevent IESG members could sort out how to go forward,
perhaps forming a small team to make recommendations on
how to procede.

I would like to say that at present, the SIP-AAA interface
is an unstandardized interface, so no matter what the
final protoocl solution is, everyone want to support the
standard will need to implement it from scatch, so backward
compatability may not be a huge barrier, as long as there
is some way to interwork with existing RADIUS servers and
NASes.

br,
John
_______________________________________________
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: Jari Arkko <[email-masked]>
Date: Fri, 21 Feb 2003 21:59:40 +0200

Thank you John for your summary. Let's stop the previous
thread and continue with the technical discussion -- I
think it was a fair question to ask who is going to deploy
what, but it doesn't sound very productive to start arguing
the details on who can speak for who, which deployment
examples should not be counted, specific other SDO plans, etc.

But back to the technical issues. I think the *needs* are
discussed in the requirements document (which I think could
still be improved *). The main solutions that have been proposed
are RADIUS, DIAMETER, and Web Services. These solutions
appear to be targeted at slightly different purposes, however,
and I suspect this is the root cause of the argument. Do
we just want a quick scheme to transport Digest authentication
from a SIP server to a central authentication box? If yes,
its very easy to explain why RADIUS looks so promising (even
if there are folks who don't its security).

Or do we want more, such as reliable accounting, ability for a
server to perform "user de-authorization", ability to carry many
pieces of information in standardized attributes, etc. (I think we
want these things). RADIUS doesn't have these features and
extending it to do them would result in something resembling
DIAMETER so if you want any of this DIAMETER looks like
a better solution.

By the way, I continue to wonder why we need to have
such a controversial debate when I suspect we might be able to
cater to the needs of both groups. One possible idea is that
the digest-carrying AAA protocol extension would be defined
using RADIUS attributes in a manner which makes it possible
run it over either basic RADIUS or DIAMETER NASREQ **). The
remaining AAA functionality for SIP would be covered only
in DIAMETER commands and AVPs, mainly because I suspect that
it can't be done in RADIUS. Is this a potential compromise?

Jari

*) One thing that wasn't clear from the requirements
specification was whether we expect to deal just with
SIP proxies, or do we have support also end systems, such
as some sort of a media server which not just runs SIP
but also offers some function?

**) Details to be worked out. One problem is that 3G
folks might actually want to get session keys back from the
authentication server as their auth methods generate these.
Perhaps this part could only be supported in DIAMETER.
RADIUS has key transport as well, but based on Microsoft's
vendor specific attributes, which are pretty outdated at
this point.

---

From: [email-masked]
Date: Sat, 22 Feb 2003 07:15:01 +0200

> drafts don't usually count for much, however.

what counts is that there are several implementations of the sterman
draft (both servers and proxies), which are in active use by sip service
providers.  

 > drafts to update them and re-submit them.  

i have asked the athors of the sterman draft to re-submit it, but for
some reason they have not done so.  perhaps running code is enough for
them.

 > is some way to interwork with existing RADIUS servers and

if sterman draft becomes an rfc, there is no need to re-implement
anything for digest authentication.  i agree that accounting requires
more work.

-- juha