Subject: AW: [Sipping] FYI: RADIUS & SIP

From: "Liess, Laura" <[email-masked]>
Date: Tue, 29 Jul 2003 22:14:04 +0200

>As I 
>understood it, the companies that have the embedded base of 
>RADIUS servers could continue to use them for SIP 

Current RADIUS does not support Digest Authentication, so you need a RADIUS extension as proposed in http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-sip-00.txt. 

There was no problem in using RADIUS together with Basic Authentication for SIP. Possibly the discussion you remember happened before the usage of Basic Authentication has been deprecated.

Laura     

>and the 
>entities deploying new DIAMETER based servers must be able to 
>interoperate with the RADIUS servers.  
>
>Kevin....
> 
>
>> -----Original Message-----
>> From: Liess, Laura [mailto:[email-masked]]
>> Sent: Friday, July 18, 2003 4:44 AM
>> To: [email-masked]; [email-masked]; [email-masked]
>> Cc: Dumler, Alexander; Wolff, Christian
>> Subject: AW: [Sipping] FYI: RADIUS & SIP
>> 
>> 
>> I think most carriers currently use some kind of RADIUS 
>> platform to do user authentication and they would like to 
>> reuse it in the future to authenticate their SIP customers. 
>> My colleagues who are responsible for the RADIUS Platform of 
>> the Deutsche Telekom (CC)are currently on vacation so I could 
>> not check with them now about how to answer this mail, but we 
>> already talked about this issue a number of times and my 
>> strong opinion is that "yes, Deutsche Telekom cares a lot 
>> about SIP and RADIUS". Reusing the existing RADIUS platform 
>> for SIP authentication is a strong requirement for the 
>> development of SIP services within the Deutsche Telekom.  
>> 
>> Laura (T-Systems/Deutsche Telekom Group)  
>> 
>> 
>> >-----Ursprungliche Nachricht-----
>> >Von: Henning Schulzrinne [mailto:[email-masked]]
>> >Gesendet: Freitag, 18. Juli 2003 09:45
>> >An: [email-masked]
>> >Betreff: [Sipping] FYI: RADIUS & SIP
>> >
>> >
>> >Bernard Aboba <[email-masked]> would like to know about 
>> >people and 
>> >companies that care about SIP and RADIUS (for authentication). 
>> >There is 
>> >an attempt afoot to rationalize RADIUS-related efforts within 
>> >the IETF, 
>> >but there seems to be a lack of representation from SIP 
>> folks, as per 
>> >the note to the radius-authors mailing list:
>> >
>> >"I was not clear about the need for SIP/RADIUS work. 
>> >Apparently there is
>> >ongoing deployment of I-Ds (e.g. the Sterman draft on RADIUS 
>> attributes
>> >for HTTP Digest Authentication), so perhaps standardization would be
>> >valuable in documenting what is in use. On the other hand, I 
>> >also heard 
>> >that "there
>> >isn't much commercial interest." Note sure what to make of 
>> >this, perhaps
>> >someone can clarify."
>> >
>> >Henning
>> >
>> >
>> >_______________________________________________
>> >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
>> >
>> 
>> _______________________________________________
>> 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
>> 
>

_______________________________________________
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: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jul 2003 08:29:25 -0700 (PDT)

> Yes, these are good proposals. I was wondering though about the
> unreliability of RADIUS AAA, given that ALL Internet dial-up services are
> using RADIUS. Were there any reports of compliants?

Yes, there are. I've personally seen RADIUS clients that do not implement
exponential backoff cause "congestive collapse" of the RADIUS servers
after a system-wide reboot.  If you've got several thousand NAS devices
and they retransmit once a second with no jittering and no backoff, this
will result in sufficient load that few RADIUS servers can handle it on a
sustained basis.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Jul 2003 22:28:38 -0700 (PDT)

> I have to agree with Laura Liess. In my compnay we have a huge installed
> base of RADIUS and I don't know anybody in the carrier community who would
> prefer to replace RADIUS with DIAMETER.

The question under discussion here is whether new RADIUS work is needed in
the IETF, and if so, what.  So far, there seems to be support for
working on the Sterman draft for digest authentication, as well as
the SIP accounting draft, and perhaps a document on RADIUS transport behavior that
would provide more reliable accounting.

Is this sufficient or is something else needed too?

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 31 Jul 2003 06:58:32 -0500

I believe this is an excellent proposal!

Though a firm believer in the supremacy of IETF technology, sometimes it
makes sense to import innovation on to the Internet from other areas. The
SIM card is certainly on top of the list for technologies where its creators
had their act well together. 

Thanks, Henry

Henry Sinnreich
MCI
400 International Parkway
Richardson, Texas 75081
USA

Have you disconnected the PBX?

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Michael Haberler
> Sent: Wednesday, July 30, 2003 11:55 AM
> To: Jonathan Rosenberg; Bernard Aboba
> Cc: Liess, Laura; [email-masked]; [email-masked]; 
> Dumler, Alexander; Wolff, Christian
> Subject: Re: AW: [Sipping] FYI: RADIUS & SIP
> 
> authenticating SIP users is very much like authenticating 
> mobile users in cellular networks, and the solution developed 
> for GSM - subscriber identity in a smart card - is IMV 
> somthing we would be well advised to carry over to SIP space.
> 
> The utility of SIM cards has been recognized for 
> Internet-side authentication like EAP-SIM based WLAN roaming, 
> in particular as there is an existing billing an 
> authentication machinery which one can plug into from the 
> Internet side. However, SIM cards could also be used in a 
> strictly Internet-only service provider context as well.  
> Plus, SIM-based authentication could be used as a bootstrap 
> mechanism for X.509 certficate distribution and therefore for 
> TLS mutual authentication.
> 
> There is a draft for SIP authentication with Authentication 
> and Key Agreement (AKA, 
> http://www.ietf.org/internet-drafts/draft-torvinen-http-digest
> -aka-v2-00.txt
> and predecessor) which adresses authentication with UMTS SIM 
> (USIM)cards. 
> These have superior security properties compared to plain SIM cards. 
> However, HTTP AKA cannot negotiate down to plain SIM 
> authentication, and very few operators use USIM cards, so if 
> we wait for USIM cards to be ubiquitious we might wait very long.
> 
> Therefore, there is more pressing need for authentication 
> with plain GSM SIM cards (about 900 million cards out 
> there!), and there is currently no standard way of using 
> those at the SIP level - although at  the WLAN level, this 
> has been adressed by EAP/SIM which gets around some of the 
> weaknessess of plain SIM authentication. However, the HTTP 
> EAP Digest draft apparently fell through, so we cannot 
> combine HTTP EAP and EAP/SIM.
> 
> So the area of work I see a need for is retrofitting EAP/SIM 
> authentication flows into Digest authentication to create a 
> strong interoperable HTTP SIM authentication method, and 
> appropriate RADIUS support to back it up. Also, the RADIUS 
> support behind HTTP AKA needs fleshing out.
> 
> my vision is to have both WLAN/LAN access and SIP 
> authenticated through the same SIM card. I see quite a market 
> potential for such a feature set.
> 
> -Michael Haberler
> 
> 
> 
> At 14:12 29.07.2003 -0400, Jonathan Rosenberg wrote:
> 
> >I know of several carriers with RADIUS infrastructures that 
> want to use 
> >them to support SIP. They are currently using expired I-Ds and 
> >proprietary attributes. As a result, I would strongly 
> advocate work on 
> >standardizing RADIUS usage with SIP.
> >
> >There are two areas of work that I see a need for:
> >
> >1. Digest authentication. The sterman draft
> >(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-
> sip-00.txt
> >) is used quite a bit, it seems. It would be nice to standardize on 
> >this.
> >
> >2. Prepaid calling. Many folks are using vendor proprietary radius 
> >extensiosn to support prepaid calling. It would be nice to 
> bring those  
> >forward and standardize on them.
> >
> >-Jonathan R.
> >
> >Bernard Aboba wrote:
> >
> >>Is there some particular set of draft(s) that you are 
> advocating work on?
> >>On Fri, 18 Jul 2003, Liess, Laura wrote:
> >>
> platform to 
> >>>do user authentication and they would like to reuse it in 
> the future 
> >>>to authenticate their SIP customers.
> >>>My colleagues who are responsible for the RADIUS Platform of the 
> >>>Deutsche Telekom (CC)are currently on vacation so I could 
> not check 
> >>>with them now about how to answer this mail, but we already talked 
> >>>about this issue a number of times and my strong opinion is that 
> >>>"yes, Deutsche Telekom cares a lot about SIP and RADIUS". 
> Reusing the 
> >>>existing RADIUS platform for SIP authentication is a strong 
> >>>requirement for the development of SIP services within the 
> Deutsche Telekom.
> >>>
> >>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
> >
> >--
> >Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> >Chief Technology Officer                    Parsippany, NJ 07054-2711
> >dynamicsoft
> >[email-masked]                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                     PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> >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
> >
>